■本の情報
<書名> 人月の神話 新装版 狼人間を撃つ銀の弾は無い
<作者> フレデリック・P・ブルックス (1931-)
<発行日> 2002年11月 (ピアソン・エデュケーション)
以下黒字が本の要約、緑字が私の感想/補足説明です。 リンク先は用語に対する私の解説です。
■要約
「人月の神話」のタイトルが意味することは、『 ソフトウェア開発において、遅れているプロジェクトに人員を投入しても、そのプロジェクトをさらに遅らせるだけである (ブルックスの法則 )』という、
人月に対する幻想を打ち砕くことを意味しています (ここでの神話とは、広く信じられているが合理的根拠のないものという、ややネガティブな意味で使われています)。
プロジェクトが遅れる理由は、引き継ぎや教育に費やす期間によるロス、機能を細分化することによる検証のロスなどが発生するため。人と時間は等価交換ではない。
更にソフトウェアの性質は、複雑性、同調性(周りの環境にあわせる必要があること)、可変性、不可視性があることが、開発を難しくさせてプロジェクトが遅れる理由にもなっていると考えられます。
また、本著はソフトウェア開発を効率的に進めるための技術論だけではなく、あくまでも組織論として考えられていることが重要なポイントです。
ソフトウェア構築には、本質的作業(どういった概念のソフトウェアを作るかを考える事)と、偶有的作業(プログラミングすること)に分ける事ができるが、過去のソフトウェア生産性における進化のほとんどは偶有的作業の進化である。
しかし本質的作業を改善しない限り、ソフトウェア構築の飛躍的な改善は得られないとしている。本質的作業を改善するための重要な指針は以下。
① 購入できるものをあえて内製開発しない。
② ソフトウェア要件の確立のために、迅速なプロトタイピングを使用する。
③ 実行と使用とテストが行われるにつれて、より多くの機能をシステムに追加しながらソフトウェアを有機的に成長させる。
④ コンセプトデザイナーとマネージャーを同等に扱い、若手の素晴らしいコンセプトデザイナーを育てる
②③はアジャイル開発 、リーン開発 の考え方と同じであると考えます。
ソフトウェア開発においては、ウォーターフォールモデルよりアジャイル開発の方が向いているという流れが強まっていると、私自身感じております。
■私が興味深いと思った言葉25選
(1) 壮大なコンセプトをデザインするのは楽しいが、微細なバグを見つけ出すのはそれこそ単純労働である。
(2) あれほど長い間苦労してきた製品が完成時には時代遅れに見えてしまう。
(3) プロジェクトの遅延は突発的なものではなく、じわじわと遅延するものが多い。
(4) プログラマはみんな楽観主義ですべてうまくいくと思い込んでおり、その前提でスケジュールを組んでしまうが、全て成功する事などは稀である。
私自身の経験としては、決して楽観視しているのではなく、納期ありきでその日程を引かざるを得ない状況に立たされている事が多い。
「できません」といっても「できるように工夫しろ、知恵を絞れ」と上位層から言われるので致し方なく、納期通りにできる日程を引くのである。
(5) やる気を削ぐのは、取り返しがつかなくなるまで時間の損失をごまかし続けて、とめどなく遅れていくスケジュールである。
(6) 計画は全て仮のものとし、変更できるようにすべきとの主張があるが、これは行き過ぎだとしている。一般的な失敗は管理が足りないことに起因するもので、過剰だからではないからである。
(7) マイルストーンは具体的かつ明確で測定可能なイベントとしてナイフの刃の様な鋭さを持って定義しなければならない。
(8) 少数精鋭の開発チームの方が何百人もの二流のプログラマを抱えたプロジェクトよりも望ましいが、それでは非常に大規模なシステムを構築するには(一人当たりの生産性は良いかもしれないが)長い年月を要してしまう。
結果、時代遅れのものになっている恐れがある。これを解消するには、外科手術チームの様に完全に役割分担して各自がその仕事を全うするという案がある。
(9) ランス大聖堂の統合された建築様式は、何世代にもわたる建築家の自己犠牲によって成り立っており、全体が統一されたデザインとなる様に彼らはそれぞれ自分のアイデアを犠牲にした。
コンセプトの完全性こそシステムデザインにおいて最も重要な考慮点である。プログラムの書き方は人によって様々である。正解は無いのだから書き方を固定化する事を強要するべきではないという風潮が私の経験ではありましたが、
統一することそれ自体が美しいのであるというのを主張して、多少強引に共通化させるのも一案であると思いました。
(10) 同じようなシステムをもう一度作る開発の時には、余計な機能をつけすぎる傾向があるので十分注意する(セカンドシステム症候群)。
(11) マニュアルは正確さと一貫性が重要である。一貫性を保つためには一人かせいぜい二人で作成する必要がある。
(12) 自然言語は厳密さに欠けるが、構造の本質を示したり、協調させたり、何より重要なのはなぜかが説明できることである。
一方、形式的定義は厳密さが利点であるが解りやすさに欠ける。そのため、仕様書は形式的定義と散文による定義の両方で構成されることになるだろう。
(13) マネージャーの仕事は、計画を作成してそれを実現することだが、文書化された計画のみが明確で伝達可能だ。何を、いつ、いくらで、どこで、誰が、という事が構成された文書が必要である。
(14) 優れた文書の必要性と正当性について熱弁してきたが、成果は上がらなかった、これは実践しようという熱意の問題であると推測した。
(15) 利用者の目的それぞれに合わせて異なるレベルの文書が必要である。
(16) 文書化がはかどらない理由は、単なる怠慢や時間的圧力にあるのではなく、仮のものだと解っている決定事項の弁解の言質を取られたくないという思いからきている。
それも一理あるが、問題は組織の評価システムにある場合もある。評定システムが他者と競わせる様な勝ち負けが有るシステムの場合、文書化することは他の誰かのためにはなっても自分の利益に繋がらなく、逆に相対的な評価が落ちてしまうからである。
(17) ソースの中に文書を埋め込む形を推奨している。そういうプログラムを自己文書という。そうする事でプログラムの変更のたびに文書が更新され、文書作成の負担も減る。
(18) バベルの塔が失敗したのは、神様が人々の言葉を乱し、互いに言葉を通じなくさせたからである。それと同じように大規模なプロジェクトも緻密なコミュニケーションが無いと成り立たない。
(19) コミュニケーションを図るツールとして、プロジェクトの手引書なるものがあれば良い。手引書はいつでも誰もが容易に見れるようでなくてはならない。また、コミュニケーションはツリー構造ではなくネットワーク構造である。
(20) プログラマは自分専用の便利ツールをこっそり持っているものだが、それはプロジェクト開発においては馬鹿げている。それは、本質的問題はコミュニケーションであり、個人的なツールはコミュニケーションの妨げになるからである。
(21) 上司への報告は、情報展開か問題対策を相談するものなのかを区別して報告する。その上で状況を見える化し、事実を相手に伝わる様に報告する工夫をすること。
(22) 機能毎に細かく分割されたプログラムより、一体化したプログラムの方が必要なスペースは少なくて済む。
これは大きなジレンマを抱える問題である。一体化した方が確かに必要なスペースは少なくなるが、個別最適化された状態になり、再利用性が低下してしまう。
(23) 変化しないことはあり得ないのだから、変化は日常的な物として受け入れる。
(24) 当初は一つは捨て石にするつもりで構築せよという考えであったが、それは誤りであった。それはソフトウェアの構築はウオーターフォールを暗黙のうちに想定しているからである。しかし反復を想定しないウォーターフォールの開発自体がソフトウェアの開発に向いていない。
(25) 「全てのプログラマが(膨大な)全ての資料を見るべきだ」と考えていたが、今では、モジュールコードは適切に定義されたインターフェイスを使って隠ぺいするべきで、モジュールの内部は外側からは解らない様にするべきであると考えている。
何事にも、ホワイトボックス化が善でブラックボックス化は悪であるという風潮が私の会社にはあるが、思い切ってブラックボックス化して割り切るという考えを持つのに抵抗がでるとはずだが、私も一定のブラックボックス化は必要であると思う。