人月の神話―狼人間を撃つ銀の弾はない (1)
続いての勉強の本はこちら。すでに古典と言っていい一冊です。内容的に古いですし、訳語自体も正直こなれた訳ではなく、しかも若干言い回しが古い感じで読みにくいところはありますが、今だに読み続けられているからには何か訳があるのでしょう。
基本的には大規模ソフトウェア開発をするときの進め方や注意点などを、著者の経験(IBMのシステム/360)をもとに語っている、ケーススタディー的な内容。
全部で20章近くありますが、各章それぞれ１０ページからせいぜい２０ページと、短い内容が多いため、細切れの時間でも読みやすいのはいいですね。全体的にたとえ話の話が多いため、ところどころ引用しつつ勉強。ちなみに新装版の方を使っています。
プログラム開発を失敗に導くタールの沼
規模の大小、また大量動員あるいは少数精鋭であろうとも、開発チームは次から次へとタールでがんじがらめになってしまう - p4
本書はまさに、このような「タールの沼」がどのような所にあって、どのように回避するかを述べている本になります。
まず最初の大きな点は、タイトルにもなっている「人月」という部分。この「人月」という単位、乱暴に言うと、たとえば10人月の場合、1人×10か月でも10人×１か月でもともに１０人月になってしまいます。実際には人が増えればコミュニケーションコストもかかり、同じになるわけはありません。しかし、そういうことを忘れてしまう魔力がこの「人月」という単位にはあることになります。
優秀な開発チームというのは優秀な外科チームと同じ
つまり、メンバー一人一人が問題を切り分ける代わりに、一人が執刀してほかのメンバーはそれを助け、こうかと生産性が上がるようにするのである。 - p28
ここで言っているのはいわゆる「チーフプログラマ制」というやつです。この方式を導入しているチームも多いようですが、元はこういうところにあったのですね。
ここでの内容はつまり、多くの人が同じように引っ張っていくチームより、一人が引っ張っていき、周りはサポートに徹した方が、結果としてプロジェクトはうまくいくということです。「船頭多くして船山に登る」というやつですね。どうしてもでしゃばりたくなるのが人の性のような気がしますが、成功のためにはそれを抑えることも必要ということ。
そのためには一種の独裁（貴族政治）も必要であるということも言っています。
コミュニケーションの大切さ
小規模開発と違って、大規模開発で問題になってくる部分は「コミュニケーション」です。そのためには、ミーティングや手引書が非常に大事であると解説されています。この本は古いため必ずしも現代の最良というわけではありません。現代ならwikiやなんかがその代りになるのでしょうか？
要は文書にしておき、それを軸にコミュニケーションをとることで、早く確実にコミュニケーションがとられるようになるということじゃないかと思います。
次回は
「文書の前提」あたりからです。
