だいぶ昔の話。ソフトウェア企業に入社した初日に、外国人のマネージャーから Welcome to the industry! （この業界へようこそ！）と歓迎された。
いやいや、私は新卒じゃなくて社会人経験あるんですよ、と答えると、いったい何をやっていたんだと聞かれたので、自分でプログラムを書いたり、論文を書いたりといったことをする研究職ですよ、と答えると、 It doesn't count （そんなものはカウントしない）と、笑いながら一蹴された。
内心、少しむっとしたが、反論する根拠も英語力もないので、この会話はこれで終わった。しかし、 Welcome to the industry! という言葉は強く印象に残った。今までだってプログラムはたくさん書いてきたんだから、「この業界」だからって何が違うんっていうんだ？
そんな風に思いつつ、最初の1週、2週間が過ぎていくと、Welcome to the industry! という言葉の意味がだんだんわかってきた。
まず第一にコードベースの規模が違う。個人でコードを書く場合、私の感覚だと数千行もあれば、十分に大きいプログラムだが、大勢のエンジニアで開発が行われているコードベースだと、桁がいくつも違ってくる。規模がでかいとコードベース全体を細かく把握することは不可能なので、大まかに何がどの辺にあるかを覚える、あるいは、必要に応じて随時調べる、みたいな方法に切り替える必要がある。
その上、コードベースが巨大だと、複雑性がとんでもないことになっている。複雑性を抑えるためにエンジニアは多大な労力を払っているにも関わらず、である。ソフトウェアを正しく設計すれば、複雑性は十分に小さく抑えられるはずだ、なんて話は教科書的には正しいかもしれないが、実際問題として、複雑性の増加が避けられるとは思えない。
たとえば、 製品に致命的な問題があり一刻も早く修正する必要がある、という状況の場合、時間がかかるきれいな方法ではなくて、とりあえずの修正を入れることは合理的な選択だ。こういった技術的負債は後日、取り除かれることが期待されるが、諸々の理由により後回しにされたり、あるいは、後からよくみてみると、実はきれいな方法なんてなかった、なんてこともある。
一方、汚いハックで性能が大幅に向上する方法が見つかった場合、このハックを入れるのは、おそらく得策だ。以前に読んだインタビューで、シェフが、私は農薬を使ったリンゴの方が無農薬のリンゴよりおいしいならば私は農薬をとる、みたいな発言をしていたが、それと少し似ている。
さらに、コードベースが巨大だと正しい場所（コアライブラリとか）で問題を解決すると大工事になるので、自分がいじっている辺りの適当な場所（UIのロジックのど真ん中とか）で、手っ取り早く問題を解決してしまう、あるいは、そうせざるを得ない、なんてこともめずらしくない。
古いライブラリを新しいライブラリで置き換えるプロジェクトの途中で、似たようなライブラリが2つ混在するということもよくある。しかも、諸々の理由により、置き換えプロジェクトが頓挫して、2つのライブラリがそのまま残ってしまうこともある。その間に3つ目が登場することは言うまでもない。
などなど、複雑性がたまっていく理由を挙げるときりがないが、ポイントは、エンジニアリング上の間違った判断だけではなく、合理的な判断の積み重ねによっても、複雑性というものは蓄積しまう、ということだ。
この結果、一見簡単そうな変更が激しい yak shaving [1] に陥る、という事態が多発する。高度に複雑化したソフトウェアは、一見簡単そうな変更に対して、予測不可能な問題、それも芋づる式のもの、をとかく引き起こしやすいものなのだ。ここでくじけずに根気よく毛を刈り取るのが、ある意味、腕の見せ所だったりする。
チームワークという側面も私にはカルチャーショックが大きかった。チーム開発では、必然的に、チームメンバーと一緒に物事を進めるための協調性が要求される（そもそも協調とかが苦手だからプログラミングにはまったような気がするのだが）。
その上、自分のチームから少し離れた領域のコードについて、誰がどの部分に詳しいか、みたいな人的な情報が大事だったり、しかも、そういったキーパーソンとの関係を構築していくことが開発を円滑に進めるための要だったりして、一人でコツコツ系のプログラミングとはだいぶ趣が異なる。
もうひとつ、プライオリティという概念も、個人的には、それまであまり意識することがなかったものだ。製品開発では、役に立つ製品をユーザに提供することがプライオリティであり、何をやるべきかはこれを元に決定される。
個人の趣味的なプロジェクトでは、コードのクリーンアップなり、瑣末な機能の作り込みに好きなだけいそしんでいてもいいが、製品開発では、それをやるべきなのか？ということが常に問われる。しかも、そのプライオリティは状況によって急に変わったりする。
以上、まとめると、くだんのマネージャー氏が言わんとしていた「この業界」というものは、コードベースが巨大で複雑で、激しい yak shaving が日常的に発生して、チームワークを巧みにこなしつつ、刻々と変わるプライオリティに応じてやるべきことを粛々と実行していく、というところであって、そういうところで長年やってきた歴戦のエンジニアからすると、研究職でプログラムを一人で書いてました、という若造に対して It doesn't count と失笑するのは仕方がない、と後から考えて、納得したのであった。
[1] http://0xcc.net/blog/archives/000196.html