「ソフトウェアの仕様書は料理のレシピに似ている」について
Life is beautiful: ソフトウェアの仕様書は料理のレシピに似ているより。
しかし、私が一度働いたことのあるNTTの研究所では、ほどんど自らソフトウェアの開発をしたことの無い人達が詳細資料書を書き、それを外注に発注してプログラムを書かせる、というソフトウェアの作り方をしていた。学生時代からプロとしてソフトウェアを作っていた私は、新入社員にも関わらず「こんなやりかたじゃ良いソフトは作れません」と上司たちにくってかかったのだが、誰一人として理解してくれなかった。
確かに、こんなやりかたじゃ良いソフトは作れない。そして強い会社にはなれない。だから早く偉くなってこういうやり方を変えてみたいと思っている。（偉くなる前に本気で嫌になって出ていってしまうかもしれないけどｗ）
実際に世の中には上記のような事は往々にしてあるだろう。ただ、必ずしも全員がそうではないと私は信じている。自分の周りにも内製指向でちゃんとやっているグループもあるし、プログラムをちゃんと分かっておりコードがきちんと書ける奴もちゃんといる（ただそういう奴ほどどんどん辞めていっちゃうんだけど）。私も入社まもなくある開発の担当となった際には、発注先の担当の人と意気投合して、そっとプログラムの一部分を担当させてもらったこともあった（もう時効だよね？）。また作ってもらったソースはリポジトリに登録され次第、片っ端から読んで気に入らない箇所や、もっと効率化できると思う箇所は、その担当に連絡して修正してもらったりしていた。
マネージャが不要というわけでなく当然必要。だけど、管理する人にはプログラムの事が分かっておりちゃんとセンスが宿っていて欲しいと部下達は願っているはず。そういうセンスのある人の発言は説得力がある。指示が的確で合理的だからだ。プログラムに興味のない人がソフトウェア開発に携わることは本当に不幸だし、その人の負の波長が周りにも波及するので正直勘弁してもらいたい。
ちなみに私が良く開発の時に良くとった行動は以下のような感じ。
- 開発の最初は大枠の議論になので、その部分はまあ皆いろいろ口を出してくる。
- そして徐々に詳細設計となり、かなり深い実装レベルに話が及んでくると極端に発言する人が少なくなる。
- そして、ほぼ特定の数人に発言が集中する。（だってその数人しか理解できてないから。）
- その数人に声をかけてとりあえず飲みに行く（会議の場で既にシンパシーを受けているから大抵意気投合できるｗ）
あんまり参考になってないｗ。ただこの問題は本当に大切だとおもうので、実際の行動につながるように今後も考えて行きたいところ。子供が起きてきたのでここまでにしときますｗとりとめのないエントリーですみません。
