今回は一年近くプログラマーとして働いた感想を書きます。
去年社会人として働き始めて、いろいろ経験しましたので、ここに書いてまとめようと思います。
社会人なら誰でも経験する悩みというよりも、特にプログラマー(SE)に経験するだろうことを書こうと思います。
自分用のメモでもありますが、この長ったらしい文章が誰かに響いて共感してくれたら望外でしかありません。
もし、長いなと思いましたら、「まとめ」だけを読んでください。
はじめに
私は去年の4月にITの会社に入って、プログラマーとして働き始めました。どうしてこの道に進んだのか。それ以前に、そもそも研究の道に行くか就職の道に行くか悩んだ挙句、どうして就職の道を選んだのか。その経緯はまたいつかということで省略します。そして就職活動してITに行った理由は、
- ロシアの女の子にPythonをやりなさいと勧めらたから、少しだけプログラミング言語をかじっていて、AIの会社でアルバイトしたことがあるから
- 圏論を勉強していて圏論は関数型プログラミングに応用されていると事実は知っているけれども、どうやって応用されているのか知りたくなって、具体的なプログラミング言語(特にHaskell)を勉強したいから
さて、それでも「就職先はITにしよう」と漠然としか思っておらず、どのような分野があるのか全然わかりませんでした。
大企業に就職するにはめんどくさい試験をパスしなければならないため、面接一発で入社できるような会社を選びました。何をやるかもよくわかりませんでしたが、受かった会社の中で一番給料が高いということだけで選びました。面接の時に「ウチは客先常駐でSEとして仕事をする」と言われました。客先常駐というのは大手企業のプロジェクトに参加して仕事をするというものです(結局受けた会社はすべて客先常駐だと思います)。要は派遣です。このような派遣の雇われプログラマーとして働くことに対して、当初私は好意的でした。それは次の理由からです。
- プロジェクト毎に新しい技術や新しいプログラミング言語を扱わざるを得ないため、いろいろなことを学ぶことができるから。
- 1つの企業文化に染まることなく、いろいろな経験ができるから。
- ある職場で人間関係で失敗したとしても、すぐに別の職場で新たな人間関係を築けるから。
1 道楽としてのプログラミング
プログラマーとして働いている現在の状況を話す前に、もう少しだけ入社前のことを書かせてください。入社前のことをちゃんと書けば、その後の現実とのギャップをより明確にできるからです。
プログラマーとして働く前に、少しだけプログラミングを勉強していました。それは主に数学(特に整数論)のプログラムを作るためです。プログラミングの楽しさや魅力はそのときの原体験に基づいています。
1.1 原体験
以下、プログラミングで遊んでいたときの思い出を語ります。それはある素数を取得するプログラムです。
1.1.1 動機
私はあるとき、こう思いました。「素数の中で、その数値を全て入れ替えてもまた素数となるものは果たしてどのぐらいあるのだろうか?」と。ここで素数とは1とそれ以外では割り切れない数です。例えば、2, 3, 5, 7, 19, 23, 37, 73です。逆に素数でない数は4(= ), 6 (=
), 91(=
)です。ある素数にたいしてそれを構成している数を入れ替えてもまた素数になるような素数はあるのか。そのような素数を循環素数(Cyclic Prime Numbers)としましょう(実はこのような素数を 置換可能素数(permutable prime)と呼ぶらしいです)。例えば、37は3と7で構成されていて、それを入れ替えた数つまり73もまた素数です。ですので37は循環素数です。対して19は素数ですが、入れ替えた数91は素数ではありません(91 =
)。ですので、19は循環素数ではありません。
このような循環素数は一体何桁まであるのかと素朴に思いました。それを調べようと始めは手作業でおこなっていました。3桁までは手作業でできましたが、4桁をおこなおうとするとめんどくさくなりました。
「うーん。人間の手でおこなうにはあまりにも煩雑すぎる...。プログラムを書いてPythonに実行させよう」と思いつきました。これが循環素数のプログラムを書く動機でした。
1.1.2 構想
そこでプログラムでどうやればいいか考えました。まずどういうプロセス(アルゴリズム/ロジック)なのか。それは手作業でおこなっていたまんまです。つまり、
- ある桁内の素数を取得する(エラトステネスのふるい)
- その素数の中から、1,3,7,9のみで構成されている素数を取得する(ただし5は追加する)
- 5以外の奇数で構成された素数を一つずつ選び、それを循環させて新たな数を作り出す。それがまた素数であるかどうか確認する。
エラストテネスのふるいとは素数を見つけるための有名なアルゴリズムです。
次にどういう機能(関数)が必要なのか考えます。それは主に
- 素数リストを取得する関数(エラストテネスのふるい)
Prime(60) = [2, 3, 5, 7, 11, 13, 17, 19, 23, 29, 31, 37, 41, 43, 47, 53, 59] - 素数リストから5以外の奇数のみでできている素数リストを取得する関数
CPN_c_Prime(60) = [3, 5, 7, 11, 13, 17, 19, 31, 37] - あるリストの文字を入れ替える関数
permutation_func(['1', '2', '3']) = [['1', '2', '3'], ['1', '3', '2'], ['2', '1', '3'], ['2', '3', '1'], ['3', '1', '2'], ['3', '2', '1']]
です。
1.1.3 コーディング
あとは上のロジックを実現させるだけです。エラストテネスのふるいはどうやって作ればいいのか、5以外の奇数のみで構成されている素数をどのように作ればいいのか。そもそもある数がどの数で構成されているのかということをどうやって判定すればいいのか。文字の入れ替え関数は自分で作らなくてもすでにモジュールとして提供されているから、それを使えばいい。----構想をもとに、そういうことをいろいろネットでいろいろ調べながらコーディングしました。それはそれで大変な作業ですが技術的な問題に過ぎません。
コーディングができたと思ったら、テストをおこないます。バグが生じているかどうかテストします。最初はそれぞれの関数だけを調べて(単体テスト)、それがうまく行ったら繋げてみて全体がうまく行くか調べます(結合テスト)。「なんでこうなるんだ」とバグと格闘して、「そうか! これか! こんなしょぼいミスを犯していたのか!!」とわかって解決できたときはかなりのドーパミンが流れます(それがいいことなのかわかりませんが)。
1.1.4 成果
こうして目的の循環素数を見つけるプログラムができました。そして4桁以降の循環素数を調べました。結局、7桁か8桁ぐらいまでできましたが、あまりにも計算量が大き過ぎてそれ以上の桁数を調べることはできませんでした。しかし8桁までの素数の間には3桁以上の循環素数は見つかりませんでした。「その桁までには新たな循環素数は存在しない」ということがわかりました。
のちに調べたら、循環素数991の次は1が19桁続く素数でした(1111111111111111111)。しかし、手作業では実質的に不可能なことを自分でプログラムを作って、可能にしたことに大きな達成感がありました。
1.1.5 プログラミングの魅力
プログラミングの魅力はなんと言っても動機→構想→実行→実現のこの全過程です。1つでも欠けたならば、楽しさは減ります。
動機はきっかけにすぎません。どうしてわざわざ循環素数なんてものを調べようと思ったんだと思われる方が大半でしょう。私も今ではそう思いますが、その当時は調べたいなと思ったことは確かです。
最も重要なのは構想力です。プログラムを実現するにはどのような機能が必要なのか。そこにはそれなりの理屈が存在します。
Q. どうして5以外の奇数で構成されている素数を判定しなきゃならないの?
A. それは2桁以上の循環素数の必要条件がそうだから。
Q. どうして数をその構成されている数に分解させる関数が必要なの?
A. それは素数を循環させて別の数を作り出すため。そして必然的に分解された数値をもとに戻す結合の関数も必要になる。循環させて作った新たな数がまた素数であるかどうかを判定しなければならないから。
このように理屈を立てること。理屈を理解すること。これこそがプログラミングの最も重要なことです。そして理屈を作ることがとても楽しいのです。
コーディングも楽しいといえば楽しいですし重要ですがコーディングなんかプログラミングの一部に過ぎません。
「こうしたい」という願望が実現されたらそれはそれでとても嬉しいです。達成感があります。しかしすぐに欲が出てきます。「もっと効率的なプログラムを作るにはどうしたらいいのだろうか?」と。自分で作りましたから自然と創意工夫をします。しかもそれは単なるコーディングのみの工夫ではなく全てにたいしてです。「そもそもロジックがよくないのではないか。例えば、素数を循環させるプログラムにおいて、同じ文字がある場合は回数を減らすことができるのではないか。113という素数ならば6通りの循環をする必要はなく、2回の循環で十分だ。それじゃあ、どうやればいいのか...。5以外の奇数で構成された素数のリストに対して、すべての要素を調べる必要はない。[3, 7, 11, 13, 17, 19, 31, 37]とあるならば、31や37まで調べる必要はないはずだ。ではどうすれば調べる回数が最小限に抑えられるだろうか...」
そして、自分で作って工夫しますから、自分よりも遥かに優れたものを見ると「すごいな」とか「悔しい」という感情が自然と生じます。例えば、あるとき私はユークリッド互除法という2つの数の最大公約数を取得するプログラムを書きました。コーディングはかなりの行数でしたが、のちにそのプログラムをたった一行で書いているのを見て「くそ!」と思いました。
他にもプログラミングの魅力はありますが、それはいつかまた書きたいと思います。しかし今回、必要なことは大体こんな感じです。
2 職業としてのプログラミング
入社後研修を受けて派遣先が決まりました。そこで大規模開発という業務が始まりました。それはどうだったか。 恐ろしくつまらなかったです。 プログラミングの魅力が何一つなかったからです。
参画したプロジェクトの動機は最悪わからなくてもいいです。社会をよりよくしたいとか体裁ではほざくでしょうが、所詮その企業の金儲けに過ぎません。それはどうでもいいです。自分以外の動機からプログラムを作成することは我慢できます。それが仕事ですから。それで私はお金をもらっていますので。その会社の動機に付き合わされるのは問題ありません。
ですが、我慢ならないのはそんなことではなく、プログラムの設計に関われないということです。普通、あるプロジェクトに新規から参加することはありません。すでにあるプロジェクトに途中から参加します。これまであるプログラムに対して新しい機能を追加するという作業です。そのために設計書を読んで、どういう目的でプログラムが作成されるのか、どういう流れでできているんだと理解しようとしても、容易にはできません。「どうしてこんな機能が必要なんだ?」としばしば思いますが、理由を聞かされても意味不明です。それはそうで全体の流れ(思想)がわかっていないから当然です。かと言って、既存のソースコードを全部理解しようとしたら、それは時間的に無理です。個人でプログラミングをしていたときは全体の仕組みを完全に理解して作業を行なっていましたが、大規模開発ではすべての仕組みを完全に理解することは不可能ですし、する必要もありません。それでも自分以外の人が作った関数やファイルを使って作らなければなりません。「完全に仕組みを理解できなくても、全体の流れを理解してなんとかやっていく」という能力が必要であることを痛感しました。
あるとき、どういう機能が備わっているのかもわからない関数を担当者から提供されたとき、私はどういう仕組みなのか中身のソースコードをもらっていないので、どう使えばいいのかもどんな機能なのかもわからず手を拱いて(こまねいて)いました。しかし、先輩はその関数名と引数名から推察して「この関数はこんな感じじゃないの」と理解しました。それで実際、うまくいきました。それを見て「とてもじゃないけど、こんな超能力者には俺は到底なれないや。こんなことできなきゃならないなら、俺はこの業界は無理だ。さっさと辞めよう」と思いました。実際、辞めかけました。
2.1 派遣は惨め
私は派遣先で仕事をしています。その派遣もどこに行くか、どの程度そこで働かされるかは、当然ながら会社が決めます。自分で決めることはできません。勤務先が近くになるかもしれませんし、僻地になるかもしれません。3ヶ月とか半年で別の職場にということはあまりなく、一年ぐらい同じ場所で働かされます。最低でも今入っているプロジェクトが終わるまでは次に行けません。自分の要望がそのまま通ることはあり得ず、どこにどのくらい働くかは運任せです。
さらに言うと、働かされる環境はお客様である客先にすべて依存されます。例えば、客先が災害対策を怠っていてたならば、こちら側は何もできずに災害に巻き込まれます。最近のご時世を鑑みれば、コロナ対策に対して在宅勤務となるのかそれとも出社しなければならないかの判断は客先が決めます。我々派遣の分際では----ましてやその中の一兵卒である私は----何も決めることはできません。その指示に否が応でも従わざるを得ません。
もっとも、自分の意思が通らず、上に従わざるを得ない惨めさは大企業の人たちも同じかと思います。大企業の新人でも上司の指示に従わざるを得ませんし、現場のマネージャー(プロジェクトマネージャー)も、上の決定に従わざるを得ません。
コロナ騒動のとき、プロジェクトチームはいつ在宅勤務に移行しようか予定を立てていました。「この日からこの日までを在宅勤務お試し期間にして、この日に会社に来て、在宅勤務はどうだったか話し合って、再来週あたりから在宅勤務が大丈夫な人たちから徐々に在宅に切り替えよう」と。このように着々と進んでいたにもかかわらず、急に「来週から全員、在宅勤務にしろ」との通達が来ました。そのとき、マネージャーは狼狽していました。「ふざけんなよ! こっちは在宅勤務に移るための予定を作っていたのに、急に来週からって! 現場を混乱させんなよ!」といった感じです。
組織で働く現場の人は大変だなと思いました。上の人たちがしっかりとした戦略と責任を持っていなければ組織はダメなんだなと思いました。
2.2 余計な作業が増える。
さて、これまで個人作業でおこなっていたプログラミングは集団作業でおこなわれるようになりました。つまりプログラミングに社会性が付与されました。すると、個人でプログラミングをしていたときには生じず、大規模開発で初めて生じた余計な作業が増えました。
2.2.1 コーディング規約・設計書の作成・シークエンス図の作成
例えば、コーディング規約です。自分で作っていたときはコードが正しければよかったのですが、書き方や変数名は自分さえわかればいいので、適当に書いていました。しかし、大規模開発ではそのプロジェクトで決まっている書き方に従わなければなりません。
他にも設計書の作成やシークエンス図の作成があります。この関数はこのような機能であるといったことをWordでまとめなければなりません。プログラムの流れを把握するシークエンス図というものも書かなければなりません。個人でやっている場合ならば、関数の機能やデータ構造は適当に自分用のメモにまとめれば十分ですし、プログラムの流れなんかはすべて自分の頭の中に入っているので、問題ありません。ですが、それも集団になれば通用せず、ちゃんとまとめなければならず作業が増えます。
2.2.2 レビュー
コーディングの作成や設計書の作成などには、上の人(プロジェクトリーダー)に了承を得なければなりません。それがレビューです。これが一番めんどくさいです。いかにも社会的です。レビューを出すためにレビュー表を作るのはめんどくさいです。レビューの返信も「コーディングが設計書と合っていません。このようにしてください」や「これだと安全性が保証されていませんので、修正お願いします」というものならばいいのですが、「このコーディングだと将来修正が加えられたとき、修正が面倒になるので、将来修正しても修正しやすいコーディングに変更してください」や「設計書の文言がわかりづらいため、直してください」などと指摘を受けて、それを直して、また指摘を受けて、また直して...。それでプロジェクトリーダーに承諾を得るまで繰り返します。
百歩譲って、コーディング規約を守ることは認めます。たとえ自分で作ったコードであってもしばらく見返したら「何書いてんだ?」と思うことがありますから、適切な関数名や引数名にしたりして見やすく書くことは個人の作業でも重要です。さらに、設計書の作成やシークエンス図の作成も認めます。結局、人間は忘れるものですから。しかし、個人の場合、その設計書やシークエンス図をどう書こうとも別に問題はありません。体裁も気にする必要はありません。しかし、社会性が生じたならば、そうはいかず責任者の承諾を得るまで、修正を加えられます。余計なレイアウトにこだわったり文言に文句を言われたりされて、お客様(クライアント)のご要望に沿わなければなりません。この作業がとてもめんどくさいです。
2.3 考え方: 目的論的計画的行動
作業は他にもあります。それは予定表の作成です。これまで個人で作っていた場合、「いつまでに完成しなければならない」とか、「いつまでにこの機能を作らなければならない」といった制約はありません。自分の好きな時に好きなだけコーディングすればいいからです。しかし、大規模開発の場合--というか仕事の場合--そうはなりません。納期という期限があります。そのため、それに間に合うように全体の予定(スケジュール)が立てられます。そこから、逆算して、半年後までにはこれをやらなければならず、3ヶ月後までにはこれをやらなかればならず、1ヶ月後までにはこれをやらねばならず、1週間後までにはこれをやらねばならず、だから今日までにこれをやらねばならない、と明確な作業目的をもって、仕事をしなければなりません。このような計画的な行動はもしかしたら合理的なのかもしれません。しかし、私はこのような計画的行動に全然慣れていませんでした。というよりもこれまで一度たりとも計画的に行動したためしがありません。今までは興味の赴くままに好きなことを好きなだけやっていたからです。受験の時ですらもです。
あるとき上司から「今後の作業予定を立てて」と言われたとき、安易に立てました。課題項目が100個あって、それを10日間でおこなわなければならないため、「1日10件課題をクリアする」としました(本当の件数は忘れました。話を簡単にするために件数と日数は適当です)。しかし、上司からは「そんな決め方じゃダメだ。まったくスケジュールになっていない。課題にもそれぞれレベルがあるのだから、レベルに合わせてスケジュールを組まなければ意味がない」と言われました。しかし、こっちから言わせれば「そもそもまだ作っていないものに対して『これくらいでできる』なんて確証なんか得られるはずがない。どこで躓くのかなんか最初からわかるわけないんだし、そもそも『この項目はこれくらいの作業内容だ』なんて見積もることなんかできるわけがない」と思いました。思っただけで実際、口は出しませんでしたが(というかできない)。
ですから、このような予定を立てて、予定をこなすために課題をクリアするような目的論的考え方や作業ができずに苦しかった(今でも課題)です。
つくづく思いますが、学校での勉強とは、その教科自体ではなく、それをおこなう行為や習慣の形成なのだということです。
数学や歴史などの内容自体が直接役に立つということは、社会に出ればあまりないのかもしれません。しかし、嫌々ながらでも勉強をしたり、学校に行くために毎朝ちゃんと起きて支度したり、つまらない話をじっと我慢したり、テストのために、計画的に勉強したりする---- そのような一連の習慣こそが社会に出て役に立つのであり、その習慣の形成こそがあのつまらない学校での勉強の目的なのだろうということです。というよりも社会がそのような習慣を求めているから、学校ではその習慣を身につけさせようと生徒を訓練しているのだと思います。
ただ、勉強だけではどうしても個人プレーの習慣しか身につきません。勉強は個人作業が基本だからです。勉強は人と何か一緒になって作業するというのがあまりない分、その点を学習させるのが本来ならば部活だと思います。チームとして必要な習慣を--何も考えずに上の人の命令には従うことや上の人たちを敬うことなどを--形成するために部活はあるのかと思います。学校での生活習慣と社会でのそれとの唯一の差はお金が出るかどうかです。テストができてもコンテストで優秀な成績を収めても、お金は一切もらえません。与えられるはせいぜい名誉ぐらいでしょう。
3 堕落: 局所最適化のクズに成り下がる
まとめると、職業としてのプログラマーは
- 納期までに仕上げるために、スケジュールを立てて、それをもとに行動しながら、
- 訳もわからないプログラムを書かなければならず、
- さらにこれまでになかった余計な作業が増えて、お客様の気の済むまで働かされる
大変な仕事だと思いました。
私は計画的に物事がおこなえません。それでノルマの期限が切れたら、怒られます。すると、本日のノルマを少しでも達成するために、必然的に残業せざるを得なくなります。しかし、作業時間が増えても集中力はもはやありませんから、作業効率は圧倒的に悪くなります。このようにして個人は組織で働くことにより作業効率が悪くなります(少なくとも私は)。
さて、少しでもノルマを達成しようとするとどう考えるでしょうか。それは 局所最適化を目指すということです。つまり、自分の与えられた仕事をいかにして最も効率的にこなすかということだけを考えるということです。例えば、レビュー表の指摘に対しても「はいはい、そうやればいいですよね。わかりました」と、その指摘の正誤を一切考えず、言われた通りにさっさとこなすようになります。上から言われたことをただただ実行すればいい。それが正しいのかどうかなんか考えている暇はない。今の作業を早く終わらせることが唯一の目的となります。
自分で全てプログラムをやっていたら、すべて自分の責任です。ですので、全体において創意工夫をおこないます。つまり全体最適化を目指します。それで、もしもうまくできなかったら悔しいです。しかし、もはや、自分のやっていることは自分のことではありませんので、与えられた仕事においていかに楽に、いかに上の人が気にいることをやるかという局所最適化を目指す態度に変わりました。それは自分の仕事しか考えないクズへと化しました。
さらに言いますと、次のような「言い訳」も思いつくようになりました。
「俺はただ自分の『役割』を真っ当にこなしているだけだ。そもそもプログラムの全体像なんか俺は把握できないし、そういう全体の最適化はプロジェクトリーダーとか上司とか上の人たちがちゃんと考えているでしょ? その全体の認識のもとで末端の俺に指示しているんでしょ? 俺はその指示通りに動いているだけだ。むしろ、全体のことに責任を取らないならば、プロジェクトリーダーとして失格だろ(サッカーで喩えようと思いましたが、私はサッカーのことを全く知りませんので省略いたします)。」
精神的に向上心のないものはバカではない。それはもはや人間ではなく単なる生きる屍に過ぎない。そんな奴は生きるに値しない。---- そう思っていたこの私自身がこのようにして向上心のかけらもない組織の歯車の一つに成り下りました。それが1年プログラマーとして働いた末路です。
おわりに: 若干の希望、または解決策
この堕落した不甲斐ない自分が嫌になり、去年の末に本気で辞めようと思いました。最悪の状況に比べれば、少しずつですがコツを掴み始めました。これからどうするかはまだわかりません。休日に好き勝手にプログラミングを勉強しているときはやっぱり楽しいです。すべて自分で作れるので。今のところ、大規模開発の楽しいところなんか一つも見当たりません。本当に「金がもらえる」だけです。
最後に、私が思った「若干の希望」を述べて終わりにします。生き抜くための方法と言えばいいでしょうか。知恵と言ったら大袈裟ですが。
一つは 同じ会社の同僚ではない、同業者の知り合いを持つべしということです。
一般的な仕事の悩みならば、同業者でなくても家族や友人などに相談できます。そこで共感してもらって慰めてもらえるでしょう。しかし、その業界にしかわからない特有の悩み事は話そうと思っても、なかなか話せません。話してみてもあまり共感されません。
その点、同業者ならば同じ悩みを共有していますので、共感してくれます。ただ、同業者で自分が知っている人は基本的に同じ職場の同僚ぐらいだけだと思います。連中に相談しても悪くはないと思いますが、「上司がどうの」とか陰口を言うにはちょっと憚れます(はばかれます)。弱みを握られるかもしれません。ですので、同じ会社の人ではない同業者と知り合って、その人に相談すべきです。
問題は「それではいかにして同じ職場ではない同業者と知り合えるのか」ということです。私は幸に大学時代の唯一の親友がいて、彼に話を聞いてもらいました。それで少し慰められました。しかし、すべての人が必ずしも同じ職場ではない同業者と知り合えるとは限りません。可能性の一つは研修中に知り合った人たちです。もう一つは、幸に現代にはSNSがありますので、そのようなツールを使って知り合うことは難しくないでしょう。
もう一つはどんなプロジェクトにもいつか終わりが来るということです。
これは至極当たり前のことですが、この認識はとても大事なことです。
そしてこの考え方はこれまで私が考えたこともなかった意外な発想でした。というのも、今まで「終わり(終焉)」というものは悪い意味でしか捉えていなかったからです。永遠なものに憧れている私にとって、終わりがあるということは永遠ではないということですので、終わりが来るというのは寂しさであったり、絶望にも似た思いがありました。しかし、「終わりがあるから頑張れる」といういい意味で捉え直すと、終わりがあることは嬉しいことであり、終わりが希望となることがわかりました。
達成感を得るために終わらせるのではなく、終わらせるために終わらせる。そうやって仕事を一つずつすれば少しは楽になるのかなと思います。
まとめ
入社前(思っていたこと):
プログラミング: プログラムはすべて個人で作っていた。それは
- 願望: プログラムを作る動機があり、
- 計画: どのようにプログラムを作ればいいのか、どのような機能が必要なのかと構想して、
- 実行: 構想をもとにコーディングに落とし込んだり、テストしてバグを見つけたりする
- 実現: そして実際に願望していたプログラムが実現して、成果が出る
という全過程をすべて一人で担っていた。そしてこの全過程こそがプログラミングの魅力である。
生活態度: 無計画で好きなものを好きな時に熱中していた。
会社: いろいろな技術やいろいろな言語を身につけて、いろいろな企業文化やいろいろな人と巡り合って、いろいろな人脈ができるだろう。
入社後(現実):
プログラミング: プログラムは集団で作る。それは
- プログラムの全体像もわからないまま、他人のプログラムを使って、プログラムを書かなければならず、
- コーディング規約を守ったり、設計書を作成したりするなどの社会的な作業が増えて、
役割が分担される。そしてプログラミングの魅力は消え失せ、退屈な作業となる。
生活態度: 納期までに仕上げるために、スケジュールを立てて、それをもとに行動しながら、今日のノルマをクリアするような目的論的行動をしなければならない。
会社: 自分は会社の都合でどこにどの程度働かされるかはわからない。さらに会社も大企業に雇われの身なので、大企業の方針に従わざるを得ない。人脈なんか作れない。
結果: 局所最適化のクズに成り下がる。
僕から以上
