人月の神話

提供: Yourpedia
移動: 案内、 検索

『人月の神話』（にんげつのしんわ）は、フレデリック・ブルックスが著したソフトウェア工学とソフトウェアプロジェクト管理の書籍である。著者の中心的な主題は「遅れているソフトウェアプロジェクトへの要員追加はさらに遅らせるだけだ」 (フレデリック・P・ブルックス Jr.、滝沢徹、牧野祐子、宮澤昇、2002年、p.23) 。

概要

本書では「ブルックスの法則」とともに、セカンドシステム症候群を説明し、またプロトタイピングを支持することを説明している。

「人月」はソフトウェア工学で特定のソフトウェアを実装するのに必要となる工数として、人と時間との単純な掛け算という形で表現した単位である。 例えば 5人が 3ヶ月かかってソフトウェアを実装する場合 15人月の工数ということになる。

ブルックスの考察は、彼がオペレーティングシステム OS/360 の開発をしていた時期の IBM での自分自身の経験が基になっている。 ブルックスは、スケジュールが遅れているソフトウェアプロジェクトに誤って要員を追加してしまったのである。

プロジェクト管理者がソフトウェアプロジェクト管理において繰り返し何度もこのような誤りを犯すという傾向があるため、ブルックスは自分の本について次のような皮肉を述べている。

この本は「ソフトウェア工学のバイブル」と呼ばれている。なぜなら誰もがこの本を読んでいるが、誰もこの本で述べていることを実践しないからである。

最初に刊行されたのは1975年。1995年に20周年記念版として再刊された。 20周年記念版では、『銀の弾などない——ソフトウェアエンジニアリングの本質と偶有的事項』という論文 (エッセイ) と著者による解説が、収められている。 1977年に出版された日本語訳の書籍では『ソフトウェア開発の神話』という書名であった。 1996年、2002年に出版された日本語訳の書籍では『人月の神話 狼人間を撃つ銀の弾はない』の書名であった (ISBN 978-4-89471-665-0) 。

本書の表紙と第1章「タールの沼」には、タールの沼と複数の獣たちの絵が描かれている (参照: #問題の所在—表紙とタールの沼) 。 また、本書の二十周年記念版で新たに追加された第16章「銀の弾などない」の扉には、狼人間の絵が描かれている。

本書の目次

2002年に出版された日本語訳の書籍より目次を記す。 なお第16章から第19章は、二十周年記念版で新たに追加された章である (初版には無かった章である) 。

人月の神話——狼人間を撃つ銀の弾はない

問題の所在—表紙とタールの沼

本書が対象とする問題の所在を説明するために、本書の第1章の冒頭の文章を引用する。 なお、本書の表紙と第1章「タールの沼」の扉には、タールの沼と複数の獣たちの絵が描かれている。

太古の昔から、タールの沼に落ちた巨大な獣が死にもの狂いで岸に這い上がろうとしている光景ほど鮮烈なものはない。恐竜やマンモス、それに剣歯トラがタールに捕らえられまいとしてもがく様が目に浮かぶ。激しくもがけばもがくほどタールは一層絡みつき、どんなに力強い獣でも、また賢く器用な獣でも、ついには沈んでいってしまう。
大規模システムプログラム開発は、過去十年以上もの間そうしたタールの沼のようなものだった。そして多くの強大な獣たちがその中へ乱暴に突き落とされてきた。たいていは稼働システムを作り、這い上がってきたものの、目標とスケジュール、それに予算にかなったものはほとんどなかった。
規模の大小、また大量動員あるいは少数精鋭であろうとも、開発チームは次から次へとタールでがんじがらめになってしまう。問題を引き起こす原因は一つだけではないように思われる。原因が一つだけなら、足のどれか一本くらいはタールから抜けるはずだ。だが、同時かつ相互に影響し合う要因が重なり合っているのなら、動きがどんどん遅くならざるをえない。この問題が執拗でやっかいなのは誰にとっても驚異であり、その本質を理解することは困難である。しかし、問題を解決しようというならば、理解するように努めなくてはならない。
（フレデリック・P・ブルックス Jr.、滝沢徹、牧野祐子、宮澤昇、2002年、p.4）

本書で述べられている見解

ブルックスが本書で述べている見解を説明する。

人月の神話
詳細は本書の第2章を参照。「人月」について誤って認識している人々が多い。人月とは見積りとスケジューリングに使われる仕事の単位である。「コストは実際に人数と月数の積に比例する。が、進捗はそうではない。したがって、仕事の大きさを測る単位としての人月は、疑うべき危険な神話なのだ。人月とは、人と月とが互いに交換できるという意味だからである。」 (フレデリック・P・ブルックス Jr.、滝沢徹、牧野祐子、宮澤昇、2002年、p.14) システムプログラム開発においては人と月を交換してもお粗末な結果しか得られないだろう。
スケジュールが遅れているソフトウェア開発プロジェクトにさらにプログラマを追加すると、そのプロジェクトはさらに大幅に遅れる。これを「ブルックスの法則」という。この大幅に遅れることの原因は、新しく参加するプログラマがプロジェクトについて学ぶ時間が必要となること、およびプログラマが増えることでコミュニケーションのオーバーヘッドが増えることである。N 人の人々が自分たちの間でコミュニケーションをとる場合 (階層的な組織を構成していないものと考える) 、N が増加すると、彼らの生産量 M は減少する。生産量 M が負の量になることさえ起こりうる (例えば、ある日の終業時点における全ての残務作業量が、その日の始業時点における全ての残務作業量よりも大きい場合——たくさんのバグを作りこんでしまった場合など) 。
  • グループ内のコミュニケーション量の公式: n(n − 1) / 2
  • 例: 50人のプログラマ -> 50(50 − 1) / 2 = 1225 のコミュニケーション経路
「人数を多くして月数を減らしても実行可能なスケジュールは得られない。時間的余裕のないことが原因でうまくいかなかったソフトウェアプロジェクトは、それ以外の原因で失敗したプロジェクト全部を合わせたものよりも多いのである。」 (フレデリック・P・ブルックス Jr.、滝沢徹、牧野祐子、宮澤昇、2002年、p.23) 遅れているソフトウェアプロジェクトへの対応は次の2つのいずれかが適切であろう。
  • スケジュールを立て直す。新しいスケジュールではたっぷり時間をとって仕事が慎重にそして完全にできるようにして、今後スケジュールのしなおしをしなくても済むようにする。
  • 仕事を縮小する。現実には、この対応が一番とられやすい。開発チームがスケジュールの遅れを見つけた場合、遅延による二次コストは非常に高いため、これが唯一とりうる手段となる。マネージャにとって唯一の対応策は、仕事を正式に慎重に削減してスケジュールし直すことである (マネージャが能動的に対応策をとらなかった場合、性急なデザインと不完全なテストが行われてしまうことになる) 。
(フレデリック・P・ブルックス Jr.、滝沢徹、牧野祐子、宮澤昇、2002年、p.21、一部改変)
スケジュールとシステムテスト
ブルックスは過去数年間、次の目安を使ってスケジュールを上手に運用してきた。
  • 1/3 計画 (詳細でしっかりした仕様を作成することを含む)
  • 1/6 コーディング
  • 1/4 単体テストおよび初期システムテスト
  • 1/4 すべてのコンポーネントを統合して行うシステムテスト
テストにはスケジュールの 1/2 を充てることが望ましい。しかしテストにスケジュールの 1/2 を充てていないプロジェクト、システムテストに充分な期間を割り当てていないプロジェクトが、ほとんどであるのが現実である。特にシステムテストに充分な時間を割り当てないと、スケジュールの最後になってようやく人々がスケジュールに問題があると気づくという、悲惨な結果をもたらす。システムテストにおけるスケジュールの遅延はコストが非常に高くつく。システムテストに充分な時間を割り当てることがきわめて重要である。
外科手術チーム
詳細は本書の第3章を参照。外科手術チームは手術の間は一人の外科医が指揮をとり、指揮をとる外科医自身が最も重要な作業を行い、その間チームの他のメンバーは指揮をとる外科医を補助するかあるいはそれほど重要でない作業を行う。外科手術チームと同様に、一人の「優秀な」プログラマに重要なシステムコンポーネントの開発を担当させ、チームの残りのメンバーは時に応じて必要なものを提供することで、ソフトウェアプロジェクトを進める方法がある (ハーラン・ミルズによる案) 。この方法は理にかなったことであるようである。ただしこの方法を5000人年の規模のような非常に大規模なプロジェクトに適用する場合は、次の「コンセプトの完全性」で述べるアーキテークチャと実装を分離する技法が必要となる。またブルックスは、「優秀な」プログラマは平凡なプログラマと比べて5倍から10倍の生産性がある (サックマン、エリクソンおよびグラントによる調査研究より) と、述べている。
コンセプトの完全性
詳細は本書の第4章を参照。利用者にとって優しいシステムを開発するために、システムはコンセプトの完全性を備えなければならない。システムにおけるコンセプトの完全性は、アーキテークチャと実装を分離することによってのみ達成できる。ただ一人の主席アーキテクト (あるいは少数のアーキテクト) が、利用者の利益を代表して行動し、システムにより行われることと行われないことを決定する。誰かが「非常に気の利いた」考えを思いついても、その考えがシステム全体の設計に継ぎ目無しに適合するのでなければ、システムに含めることは却下される。事実として、利用者にとって優しいシステムを確実に開発するために、システムは、その本来の能力に対して、提供する機能が少ないこともありうる。要点は次に述べるとおりである。すなわち、システムが利用者が使うに際して複雑すぎる場合、システムの機能の多くは使われないという結果になる。なぜなら、それらの機能を習得するための時間がある人など、いないからである。
セカンドシステム症候群
詳細は本書の第5章を参照。ソフトウェア開発者が設計する「セカンドシステム」は、そのソフトウェア開発者がそれまで設計したもののうち最も危険なシステムである。なぜならそのソフトウェア開発者が、ファーストシステムで (固有の時間的制約により) 取り入れることを見送った全ての追加機能を、取り入れる傾向があるからである。このため、セカンドシステムの設計に着手するとき、ソフトウェア開発者はセカンドシステムに機能を取り込み過ぎないことを心がけるべきである。
進捗の追跡
問い: 大規模なソフトウェア開発プロジェクトは、どのようにして1年の遅れがでるのか? 答え: プロジェクトの1日を考えればわかる。多くの方面において増加する遅延が蓄積して、全体として大幅な遅延という結果になってしまう。細かい粒度でのそれぞれのマイルストーンごとに継続的に注意することが、各水準の管理 (マネジメント) では必要である。
マニュアル
主席アーキテクトが作成したアーキテクチャは、システムのための明記された仕様であり、マニュアルとしての形をとる。マニュアルは、システムの外部仕様を詳細に記述していなければならない。ここで詳細に記述するとは、すなわち利用者がシステムを使う際に目にする全てのことを記述するということである。マニュアルは、実装を担当するチームおよび利用者から意見が寄せられたときには、改訂するべきである。
パイロットシステム
新しくシステムを開発するときには、開発チームは使い捨てのシステムを設計することになるであろう (使い捨てのシステムを設計するということは、意図して行う場合もあれば、意図せずして行ってしまう場合もある) 。こうして開発されたシステムはパイロットプラントとしての役割を果たす。すなわちパイロットシステムなのである。パイロットシステムを開発すると、後にシステムを完全に設計し直して再度開発せざるを得ないことが明らかになる。こうして二度目に開発されたシステムは、パイロットシステムより洗練されている。この二度目のシステムを顧客に提供するべきである。なぜならパイロットシステムを提供することは、顧客を無理やりつらい目に遭わせるだけであり、おそらくはシステムの評判を失わせ、ことによるとシステムを開発し提供した企業の評判もひどく傷つけるという、結果になるであろうからである。
形式に即した文書
全てのソフトウェアプロジェクト管理者は、形式に即した文書の小さな中核となるセットを作成するべきである。この形式に即した文書の小さなセットは次の役割を果たす。
  • プロジェクトの目標群に向けた道標
  • プロジェクトの目標群をどのようにして達成するかについての道標
  • 目標群の達成を担当する人物を明らかにする
  • 目標のそれぞれについて、達成することを予定している時期
  • 目標のそれぞれについて、必要となる費用 (コスト)
形式に即した文書の小さなセットはまた、プロジェクトの遂行に不整合があることも明確に示す。こうした不整合は、形式に即した文書の小さなセットが無い場合は、その存在を認識することが難しい。
プロジェクトの見積り
ソフトウェアプロジェクトの時間の見積りをするときには、コンパイラ (製品としての品質水準をもつソフトウェア) を開発することは、アプリケーションソフトウェアを開発することよりも、3倍難しい作業であるということを憶えておくべきである。そしてシステムプログラム (オペレーティングシステム、製品としての品質水準をもち且つシステムとして統合されたソフトウェア) を開発することは、コンパイラを開発することよりも、さらに3倍難しい作業である。適切な高水準プログラミング言語を使うと、プログラマの開発生産性が大幅に向上する可能性がある。そしてまた、1週間の作業のうち何時間を、技術的な問題に取り組むことに費すかについて、心に留めておくべきである。このことは管理に費す時間や技術的ではない問題 (会議や療養休暇など) に費す時間について考えることよりも、重要なことである。
コミュニケーション
大失敗を回避するために、ソフトウェアプロジェクトで作業をしている全てのチームは、できる限り多くの方法 (電子メール、電話、会議、事務連絡票) で互いに連絡をとり続けるべきである。プログラマは何かを仮定するべきではない。プログラマは自分が実装する機能についてあいまいなところがあれば、仮定するのではなく、アーキテクトに機能の意図するところを明確にするために質問をするべきである。全く見当はずれの仮定をして実装を続ける前に。
コードの凍結とシステムのバージョン
ソフトウェアは目に見えない。そのため新しいシステムの多くのことは、新しいシステムの一定の部分が完成して利用者がそれを使うようになって、初めて明らかになる。利用者が新しいシステムを使うことで、そのシステムについて深く理解することができるであろう。利用者がシステムを理解することで、利用者がシステムに対して要求していたことを変えることもあり、利用者がシステムに対する要求についての認識を変えることもある。システムは、それゆえ、利用者により変更された要求を満たすために、変更されるべきである。こうした変更は、ある時点までのみ可能である。さもなければ、システムはけっして完成することはないであろう。ある日から、システムに対するこれ以上の変更は拒まれる。そしてコードは凍結される。全ての変更要求は、そのシステムの次のバージョンまで遅らされる。
切れ味のいいツール
プログラマがそれぞれ自分自身の特別なツールのセットを使うことはすべきではない。プロジェクトでは指定されたツールを作る担当者をおくべきである。ツール作成担当者は、プロジェクトチームが行っている仕事のために高度にカスタマイズされたツールを作成する。例えば、仕様を基にしてコードを生成するコードジェネレータなどである。また、システム全体で使われるツールは、共通ツールチームで開発するべきである。共通ツールチームは、プロジェクト管理者の監督下におかれる。
ソフトウェア開発の費用を低減する
ブルックスは、ソフトウェア開発の費用を低減するための技法として、本書では2つ挙げている。
  • プログラマは、システムのアーキテクチャが完成した後にのみ、プロジェクトに参加させるようにして良い (システムのアーキテクチャを完成させるには何ヶ月かかかることが多いが、しかるべき時より早くプロジェクトに参加したプログラマは、何もすることが無いかもしれない) 。
  • ソフトウェア全てを開発せずに、可能な場合は「すぐに手に入る」ソフトウェアを購入する。
銀の弾などない——ソフトウェアエンジニアリングの本質と偶有的事項
詳細は同項目を参照。ブルックスが1986年に発表した論文で、『人月の神話』の20周年記念版に第16章として収められた。「銀の弾丸」として魔法のようにすぐに役に立ちプログラマの生産性を倍増させるような技術や実践 (特効薬) は、今後10年間 (1986年の時点から10年の間) は現れないだろう。ソフトウェア開発の複雑性には、「本質的な複雑性」と「偶有的な複雑性」とがある。ソフトウェア開発者はこれまで高水準プログラミング言語、タイムシェアリングシステム、統一されたプログラミング環境により、偶有的な複雑性の多くをやっつけてきた。しかし一方で現在 (1986年) のプログラマは彼らの時間の大部分を本質的な複雑性に取り組むことに費している。
次のことを提案する。
  • 購入できるものをあえて構築しないようにするための大市場の利用。
  • ソフトウェア要件の確立に際し、開発循環計画の一部として、迅速なプロトタイピングを使用すること。
  • 実行と使用とテストが行われるにつれて、より多くの機能をシステムに追加しながら、ソフトウェアを有機的 (系統的) に成長させること。
  • 若い世代の素晴らしいコンセプトデザイナーを発掘し、育てること。
(フレデリック・P・ブルックス Jr.、滝沢徹、牧野祐子、宮澤昇、2002年、第16章、P.166)
「銀の弾などない」再発射
詳細は銀の弾などない#「銀の弾などない」再発射を参照。ブルックスが『銀の弾などない』の9年後に同論文について省察した論文で、『人月の神話』の20周年記念版に第17章として収められた。『銀の弾などない』で主張した、銀の弾はないという見解は、変わらない。オブジェクト指向プログラミングの手法は成長が遅かったが、少しずつ成果が出つつある。
「人月の神話」から二十年を経て
ブルックスが『人月の神話』の初版を出版してから20年後に同書についての省察などを書いたエッセイで、『人月の神話』の20周年記念版に第19章として収められた。『人月の神話』の初版を書いた当時も正しかったし現在もあい変わらず正しいこと、今になってみると間違っていたなと思うこと、もう時代遅れになっていること、ソフトウェアエンジニアリングにおいて本当に新しいこと、などについて書かれている。なお「コンセプトの完全性」は正しかったと述べている。また「パイロットシステム」について書いたことは誤りであったと述べている (理由は本書を参照) 。

関連項目

参考文献

  • The Mythical Man-Month : essays on software engineering, Brooks, F. P., Addison Wesley, 1975, ISBN 978-0201006506
  • The Mythical Man-Month : essays on software engineering (Anniversary Edition with four new chapters), Brooks, F. P., Addison Wesley, 1995, ISBN 978-0201835953
    • 『人月の神話 狼人間を撃つ銀の弾はない』 (原著発行20周年記念増訂版) 、フレデリック・P・ブルックス Jr.、滝沢徹 (訳) 、牧野祐子 (訳) 、宮澤昇 (訳) 、星雲社、アジソン・ウェスレイ・パブリッシャーズ・ジャパン、1996年、ISBN 978-4795296756
    • 『人月の神話 狼人間を撃つ銀の弾はない』 (原著発行20周年記念増訂版、新装版) 、フレデリック・P・ブルックス Jr.、滝沢徹 (訳) 、牧野祐子 (訳) 、宮澤昇 (訳) 、ピアソン・エデュケーション、2002年、ISBN 978-4-89471-665-0

外部リンク

「http://ja.yourpedia.org/mediawiki/index.php?title=人月の神話&oldid=158283」から取得