トップ 差分 一覧 ソース 検索 ヘルプ RSS ログイン

人月の神話

このエントリーをはてなブックマークに追加

[ソフトウェア開発]

人月の神話

このページでは、フレデリック・P・ブルックスJRの名著、「人月の神話」の要約を載せる。

  人月の神話とは

  • システム開発について一定の言説をまとめたエッセイ、1975年発行
  • 著者はIBMの技術者である、主にIBM System/360を開発中に得られた知見・問題の解決方法をまとめている
  • IBM System/360の発売時期は1964年なので開発自体は1960年代の話となる
  • 少し昔の話となるが、現在のシステム開発と本質的に変わらない知見・問題について解を示している

  ブルックスの立場

  • ブルックスはIBMで働いた後、大学で教員の職に就いている
  • 「人月の神話」は大学で発表した論文のようなものである
  • 「人月の神話」は研究者の間で論争を呼んだらしく反響は大きかったようだ
  • 詳しくはWikipedia フレデリック・ブルックス
  • ウォーターフォール型の開発方式は間違いで、アジャイル型の開発が望ましいと主張している(本書の発行から20年後に)

  人月の神話のAmazonリンク

 人月の神話【新装版】

  目次と重要度の表

サブタイトル 概要 重要度
1 タールの沼 システム開発とハックの違い ○ 重要
2 人月の神話 スケジュールと人的リソースの投入についての一般的な誤解 ◎ 必須
3 外科手術チーム ソフトウェア開発チームの構成について ○ 重要
4 貴族政治、民主政治、そしてシステムデザイン 設計と実装の分離について ○ 重要
5 セカンドシステム症候群 継続開発時の設計方針について △ 普通
6 命令を伝える 仕様書の形式、会議体、電話などのエビデンス △ 普通
7 バベルの塔は、なぜ失敗に終わったか? 大規模プロジェクトにあるべき体制 ○ 重要
8 予告宣言する ソフトウェアの複雑性が人月を増大させる △ 普通
9 5ポンド袋に詰め込んだ10ポンド ソフトウェア開発におけるアルゴリズムの重要性 ○ 重要
10 文書の前提 ソフトウェア開発に必要な文書について △ 普通
11 1つは捨石にするつもりで プロトタイプ開発および変化に対応できる人材の重要性 △ 普通
12 切れ味のいい道具 生産性を上げるための方法と道具 △ 普通
13 全体と部分 バグを取り除く・バグを生まないための設計 ○ 重要
14 破局を生み出すこと スケジュールの遅れを防ぐには ○ 重要
15 もう1つの顔 詳細設計の是非・ソースコードのコメント ○ 重要
16 銀の弾などないーーソフトウェアエンジニアリングの本質と偶有的事項 魔法のようにすぐに役に立ちプログラマの生産性を倍増させるような技術や実践など無い ◎必須
17 「銀の弾などない」再発射 同上 ○ 重要
18 「人月の神話」の命題ーー真か偽か 本書の要約、とりあえずこれを読んでおくとよいかもしれない ○ 重要
19 「人月の神話」から20年を経て 回顧録 ○ 重要
20 50年間の不思議、興奮、それに喜び エピローグ ○ 重要

各章の要約

  タールの沼

システム開発とハックの違い

ブルックスは大規模システム開発をタールの沼に例えている。どんなに力強い獣でも、どんなに賢い獣でももがけばもがくほどタールにがんじがらめにされてしまう。大規模システム開発はそのようなものである。それをイメージしてか人月の神話の表紙は沼地にいる熊の挿絵である。

沼はよくわからないから沼なのである。分析が必要だ。ブルックスはまず大規模システム開発を分析して、以下の様な図を描いた

ファイルが存在しません。

プログラム
これは個人 or 少人数によるHackである。
プログラミング製品
プログラムの機能を誰にでも扱えるように文書化、機能を保証するために試験を実施したもの。プログラムをプログラミング製品にするには3倍の労力が必要である。
プログラミングシステム
プログラムひとつひとつをモジュール化、外部とのインターフェースを定めて連携可能にしたもの。プログラムをプログラミングシステムにするには3倍の労力が必要である。
プログラミングシステム製品
我々がめざすべき成果物。プログラムをプログラミングシステム製品にするには3×3倍=9倍の労力が必要である。
  • ブルックスはプログラミングシステム製品を作る楽しみ・苦しみを述べつつこの章を以下のように締めている

プログラム開発は、多くの人々が目的達成のため、もがき苦闘するタールの沼であるとともに、

また独自の喜びと苦悩を伴った創造的活動でもある。多くの人々にとって、喜びが苦悩よりはるかに

勝っているのであり、本書はそういう人のためのタールを渡る掛け橋を提供しようとするものである。

  人月の神話

スケジュールと人的リソースの投入についての一般的な誤解

ほとんどのソフトウェア開発プロジェクトの失敗の理由は時間的余裕の無さにある、なぜか?なぜいつも時間がないのか?

  1. 楽観主義からくる見積もり技術の欠如
  2. 人月の神話
  3. マネージャーに確固とした意志がなく、スケジュールについて強く主張できない
  4. スケジュールの監視ができていない
  5. 遅延発生時に要員を追加する

4の説明は他の章にゆずり、それ以外の点について述べる

楽観主義
人間が事物の作成者である場合、私たちのアイディアの不完全さや不整合性は、実現段階になって初めて明白になる。したがって、書くこと、実験すること、「考えつくすこと」が理論家にとって必須の修練ということになる。しかしソフトウェアは、その扱いが容易であるため(作成・修正・削除がハードウェアより簡単という意味)、そこから楽観主義が生じる。実際には、アイディアの不完全さや不整合性は、実現段階になって初めて明白になるため、そこまで簡単なことではない。あなたにも経験がないだろうか?設計段階で動くと確信していたのに、実はロジックが破綻していたなどということが。
人月の神話
見積もりとスケジューリングには「人月」という単位が使われる。これは1人の作業者が1月で行える仕事を指す。たいがいのプロジェクトでは全体の仕事量を人月で割って期間やコストを算出する、というのがざっくりとした人月の説明だ。ブルックスはこう述べる、「コストは実際に人数と月数の積に比例する。が、進捗はそうではない」。これが人月の神話の書名の由来である。神話という言葉からくる幻想的な雰囲気が無くなってしまったではないか。。。

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

マネージャーに確固とした意志がなく、スケジュールについて強く主張できない
ソフトウェアの開発マネージャは、それが破滅的な結果になることをわかっていながら得意先の希望する納期に合わせた間違ったスケジューリングを行ってしまう。これの解決策は、生産性やバグ発生率の数量化、見積基準などを開発し共有することである。(…編者注:ここのタイトルは「マネージャーに確固とした意志がない」ではなく「マネージャーにスケジュールを決める権限がない」のほうが良いかもしれない。ブルックスが示す解決策については、日本企業において発注者側の論理でしか使用されない可能性があることを示しておく。)
遅延発生時に要員を追加する
プロジェクトが走っている状態での補充要因追加はスケジュールを遅らせるだけである。理由は、補充要因への教育・訓練の期間(…それとコミュニケーションコスト)が大抵の場合考慮されないから。

  外科手術チーム

ソフトウェア開発チームの構成について
(開発時の労力)コストの大部分がコミュニケーションと、うまくコミュニケーションできなかったことにより発生するマイナス面の修復

→ そのため、システム構築はできるだけ少人数で行いたいと思うことにつながっていく

だが、少数精鋭チーム案には、非常に大きなシステム開発には時間がかかりすぎるという問題が出てくる。効率性とコンセプトの完全性のためにはデザインと製作は少数精鋭で行いたい。だが、大規模なシステムでは製品をタイムリーに発表できるように、できるだけ大量の要員を投入する方法が望ましい。

→ 少数精鋭か人海戦術か?そのジレンマを解消する折衷案が以下

ハーラン・ミルズによるチーム構成案

これは、システム開発をする際に作業の分担を人海戦術で行う(…みんなで分割して作業)のではなく、誰かが開発部位を切り分けてチーム内でそれを消化するためのチーム構成である。ただし、時代が時代なので少し古い。

ポジション 役割 ソフトウェア開発の歴史上思い当たる有名人物
執刀医(=チーフプログラマ) 機能設計とコーディングとテストを行う経験豊富な人物 カトラー
副執刀医 執刀医と同じように経験豊富なエンジニア、執刀医の方針に問題がないか意見を交わすことが目的(一人でやらせると暴走するかもしれないので)
管理者 就業管理などを行う。金銭・人員・設備の管理を行う
編集者 ドキュメント作成者
秘書×2人 プログラマの補助
プログラム事務係 この人がプログラムが書かれた穴あきのシートをコンパイル係に持って行ったりするらしい。古き時代のポジションで今はこれに当たる人はいないだろう
ツール製作者 開発環境周りの管理やデバッグ用のツールの作成を行う。このポジションは今でも必要だろう。
テスト担当者 プログラマが作成したソースのテストを行うためのテストケースを作成する
言語エキスパート プログラミング言語自体に精通した専門家、チームに必ず一人必要というわけではない 江添さん

  貴族政治、民主政治、そしてシステムデザイン

設計と実装の分離について

  セカンドシステム症候群

継続開発時の設計方針について

  命令を伝える

仕様書の形式、会議体、電話などのエビデンス

  バベルの塔は、なぜ失敗に終わったか?

大規模プロジェクトにあるべき体制

  予告宣言する

ソフトウェアの複雑性が人月を増大させる

  5ポンド袋に詰め込んだ10ポンド

ソフトウェア開発におけるアルゴリズムの重要性

  文書の前提

ソフトウェア開発に必要な文書について

  1つは捨石にするつもりで

プロトタイプ開発および変化に対応できる人材の重要性

  切れ味のいい道具

生産性を上げるための方法と道具

  全体と部分

バグを取り除く・バグを生まないための設計

  破局を生み出すこと

スケジュールの遅れを防ぐには

  もう1つの顔

詳細設計の是非・ソースコードのコメント

  銀の弾などないーーソフトウェアエンジニアリングの本質と偶有的事項

魔法のようにすぐに役に立ちプログラマの生産性を倍増させるような技術や実践など無い

  「銀の弾などない」再発射

同上

  「人月の神話」の命題ーー真か偽か

本書の要約

  「人月の神話」から20年を経て

回顧録

  50年間の不思議、興奮、それに喜び

エピローグ
お名前: コメント: