One is too many

『ひとつでは多すぎる』をモットーに色々挑戦したい。 ライフログ(旅・自然)メイン

【本】知っておいて損はない「人月の神話」

今年は、2019 PHPer会議に参加しました。(もう数ヶ月前のことですが)

登壇者が「銀の弾丸などない」をよく使われていたのが印象に強く残っていました。

 

この言葉は、フレデリックブルックスが1986年に著した、ソフトウェア工学の広く知られた論文が出典となっています。

 いつどんな状況にも対応できる、解決に役に立つ特効薬はないという意味を示しています。

 

エンジニアに携わる者として、多種多様な技術からの選定やベストプラクティスの追求はとても大切です。ただ、何でもできる万能なものはなく、たいてい一長一短です。

そのときどき、必要な要件に合わせ比較検証するのは苦労しますよね^^;

 

PHPer会議をきっかけに、フレデリックブルックスの本に興味を持ち「人月の神話」を読んでみました。

 

端的にまとめると、プロジェクトの成功法ではなく、失敗パターンを知ることができました。プロジェクトはいかにして失敗するか、うまくいかない兆候はどういうところにあるかという知見を得られました。

 

いくつか、個人的にふむふむと思ったところを紹介します。

スケジュールに時間的余裕のないことが原因でうまくいかなかったソフトウェアプロジェクトは、それ以外の原因で失敗したプロジェクト全部を合わせたものよりも多い。

「時間的余裕」は大事ですよね。余裕のない、急かされるプロジェクトは嫌だ、というのは誰しも思うところです。急かされると、慎重さ・緻密さを欠く可能性が高まります。システムに致命的な欠陥が見つかったりするのも、時間的余裕のなさから来るのではないかと思います。

 

後、「納期は絶対変更できない、でも要求する機能は実装しろ」というプロジェクトにあたった場合は最悪です。納期に間に合った体になっているのもの、品質がボロボロで、受け入れ不可。稼働延期決定、急いで作られたため、コードは目も当てられないほどの惨状だった、なんて経験もあります。。

 

あと1・2ヶ月は時間に余裕を持たせて、スケジュールの再調整が行われていれば、ひどいシステムにはならずに済んだのではないかと思いました。

 

ブルックスの法則ー遅れているソフトウェアプロジェクトへの要因追加は、さらにプロジェクトを遅らせるだけである。

 人を追加したら、一人のところを二人にしたら、半分の時間で作業が終わると思っているマネージャが存在するのが怖いです。たいてい、後から入った人へ教育・フォロー、レビュー等していたら、どう考えても2倍の成果はでないですよね。。

 

人海戦術のごとく、人をたくさん入れたら、元からいた人がフォローしきれるはずもなく。元からいた人はフォローで手一杯になるか、フォローがかなり手薄になります。後から入った人は理解に時間が必要です。元からプロジェクトにいた人に、質問が殺到し、順番待ちができているのを見たことがあります。そうなるとどうなるでしょうか。

質問しにくい→質問せず独自に走り出す人が出はじめる→見当違いな方向へ進んでもリカバリが後々になる→オワタ。。

 

人の追加は計画的に行いたいものです。

 

 仕事の大きさを測る単位としての人月は、疑うべき危険な神話なのだ。人月とは、人と月とが互いに交換できるという意味だからである。

 人と月が交換可能になるのは、多くの作業者間でコミュニケーション(意思疎通)を図らなくとも、仕事が分担できる場合だけである。

Slerでよく使われているであろう人月という言葉があります。システム開発は、人が増えるほどコミュニケーションを図るための労力に時間を割かれます。

 

単純に分割できる仕事、例えば小麦を刈り取る場合、どれくらいの広さがあって、一人あたりに割り振るという場合は、人と月が交換可能です。相互コミュニケーションなく、独立して作業を進められます。

 

しかし、システムはたいてい複雑に絡み合っているため、分割したとしても、相互コミュニケーションは欠かせません。そうなると、人月は、全然あてにならない見積もり手法だなと思いました。

 

「人月の神話」も、銀の弾丸ではないですが、知っていることで避けられる

失敗があるのではないかと思いました。

システムに携わる方には一読の価値があると思います。

人月の神話【新装版】