AMAZON

 

この業界の聖書とでもいうべき「人月の神話(Frederic Phillips Brooks Jr.)」の読書メモです。でも黙示録22-18/19*1みたいなことは書いてないんで、あらすじを書いたり補足(ツッコミ)を入れても寿命が縮まったりすることはないでしょう。暇そうだからとデスマに投入されるおそれはあるかもしれませんが・・・

 

18章で筆者は同じように全体の論点整理をしているけど、微妙に視点が違うかな・・・
筆者は、工学書としてこの本を書いて、そういう視点で論点整理をしている。
小生は、お話としてこの本を読んで、そのあらすじをここに書き留めている。

 
 

初版の序文

  1. 筆者はOS/360の開発責任者だった
  2. OS/360は優秀なマシンだ
  3. しかしOS/360の開発プロジェクトはガタガタだった
  4. 本書でその原因を分析する

20周年記念増訂版の序文

  1. 初版で提案したことに対して、工学的な観点からの批判や賛成・ブラッシュアップが少ない
    そこで18章を追加して論点を整理してあげるので、ちゃんと工学的な観点から議論すること
    要は小生みたいに「お話」として読むなってこと(^^;)
  2. 19章は新しく書き下ろしたけど、長年象牙の塔に住んでいるもんで、実際の開発現場で起こっていることとはずれているかもしれない。

第1章 タールの沼

本書で扱う問題の整理

  1. 対象:プログラムシステム製品
    1. 二人のプログラマがガレージで作れちゃう(HPのこと?)お手軽プログラムの9倍複雑
      1. 製品化に3倍(一般化・テスト・文書化・メンテナンス)
      2. システム化に3倍(システム統合インタフェースの作成・結合テスト)
  2. プログラムシステム製品開発で何が起きているか
    1. タールの沼(複合的で複雑な要因)に落っこちる
    2. 多くの開発ではタールの沼からはい出てゴールまでたどり着くが、納期・予算を満たしたものは皆無
    3. 少数精鋭でいったらいいとか、大量動員で解決!とかそんな単純な問題ではない
  3. タールの沼とはざっくりいうと?
    1. プログラムシステム製品には完璧が要求されること
    2. 一般的な組織の弊害
      1. 権限と責任が釣り合わない(実績あげて奪い取れ by筆者)
      2. 他人の成果物に依存する(自分の作っているものは、Mr.Aのクソコードに依存する砂上の楼閣)
    3. デバックが収束しないし、デバック作業はつまらない
    4. 新しい機能を盛り込みすぎること
      1. 他社が宣伝しているコンセプト段階の「絵に描いた虎」と比較して陳腐にならないようにがんばりすぎて失敗
  4. で、本書で扱う問題とは?
    1. 現実のプログラムシステム開発に対する現実的な処方箋
      1. 入手可能なリソース
      2. 実際のスケジュール
    2. いってみれば本書はタールの沼の掛け橋

第2章 人月の神話

プロジェクト失敗の原因

  1. 見積もり精度が悪い
    1. システムプログラマは楽観的
      素材 + 設計 --(実現)--> 製品
      
      素材と設計どちらがかけても製品はできない
      1. 人間は設計の欠陥には気づきにくい(自分の間違えは見つけにくい)
      2. 工業製品では素材の物理的限界で実現の困難さに気づく
      3. システムプログラムでは、素材(プログラム言語)が柔軟なので、実現の困難さ(つまりは設計が腐っていること)に気づきにくい
    2. でもシステムプログラムは、タスクが複雑に絡み合っているので全部がうまくいくことはまず無いんだよね
       
      9割納期通りに終わるタスクが3つ直列にいるプロジェクトが納期通りに終わるのは
      0.9 * 0.9 * 0.9 = 0.7
       
  2. というかそもそも見積もりに対する定量的な基準がない
    1. お客さんが適当に作業完了予定を決めても、実際の完了はコントロールできない
    2. しょうがないからプロマネは、開き直って自分の勘をお客さんに堂々と言え
    3. 今はしょうがないけど、ちゃんとデータとって定量的に分析しろ
    4. ちなみに筆者の経験則では
      1/3 計画
      1/6 コーディング
      1/4 単体テスト・結合テスト・疎通
      1/4 システムテスト
  3. 人月という考えがそもそもイカンのぢゃ
    1. システムプログラムでは、タスクが連続していてなかなか分担できない → 人と月は交換可能でない
    2. 人を増やしてもコミュニケーションによる効率低下が起きる → 人と月は交換可能でない
    3. 教育・訓練が考慮されていない → 人と月は交換可能でない
      例:
      3人×4ヶ月=12人月 の仕事で、マイルストーンは1月ごとにABCD
      A完了まで6ヶ月かかったとすると...
      
      当初予定:
           1月   2月   3月   4月
            A     B     C     D
      |3人月|3人月|3人月|3人月|
      
      現状
           1月   2月   ?月   ?月   ?月
                  A     B     C     D
      |3人月|3人月|  ?  |  ?  |  ?  |
       
      ●よくあるデスマ:
      
      解決策:
           1月   2月               4月
                  A     B     C     D
      |3人月|3人月|  3? |  3? |  3? |
      
      当初の納期に間に合わせるため
      一月当たり
      3 * 3 / ( 4 - 2 ) =4.5人 -> 2人増員する
      
      3月にはどうなるのか?:
      
      新人2名に業務知識を教えるのに、古参1名が教師となって1月かかる
      とすると3人月よけいに工数がかかる
      更にタスク分割のやり直しやシステムテストの増加で1人月かかると
      
           1月   2月    3月               4月
                  A            B     C     D
      |3人月|3人月|進捗ナシ|  2? |  3? |  3? |
      
      当初の納期に間に合わせるため
      一月当たり
      8 / ( 4 - 3 ) = 8人 -> 3人増員する
      
      新人3名に業務知識を教えるのに・・・(TT)
      
       
      ●もっと悲惨なデスマ:
      
      解決策:
           1月   2月               4月
                  A     B     C     D
      |3人月|3人月|  6? |  6? |  6? |
      
      当初の納期に間に合わせるため
      一月当たり
      6 * 3 / ( 4 - 2 ) = 9人 -> 6人増員する
      
      3月にはどうなるのか?:
      
      新人6名に業務知識を教えるのに、古参2名が教師となって1月かかる
      とすると8人月よけいに工数がかかる
      更にタスク分割のやり直しやシステムテストの増加で1人月
      コミュニケーションによる効率低下で1月1人月かかるとすると
      
           1月   2月    3月               4月
                  A            B     C     D
      |3人月|3人月|進捗ナシ|  7? |  7? |  7? |
      
      当初の納期に間に合わせるため
      一月当たり
      21 / ( 4 - 3 ) = 21人 -> 12人増員する
      
      新人12名に業務知識を教えるのに・・・orz
       
    4. ブルックスの法則
       
      遅れているソフトウェアプロジェクトへの要員追加は更に遅らせるだけだ
       
  4. スケジュールが遅れたら、より少ない人数でより長い期間をかけるのが正解
  5. あるいは機能を削る

第3章 外科手術チーム

  1. 少数精鋭最高!
    1. プログラミングの世界では、人によって生産性が10倍違うのはザラ
    2. 少数精鋭はコミュニケーションのコストが格段に低い
      100人月のプロジェクトの人間関係のパス  100*99/2
      生産性10倍の精鋭部隊10人の人間関係     10*9/2
      -->同じ100人月相当の仕事をするのに、少数精鋭だと
         コミュニケーションのコストは1/100
    3. プログラムシステム製品のコンセプトの統制は少人数でないとできない
       
       
  2. でも大規模プロジェクトは少数精鋭でできない
    1. 精鋭を100人集めたら精鋭部隊でなくなる
      1. コミュニケーションのコストが大きくなる
      2. 人間10人を超えると何らかの組織(管理階級)が必要
      3. 総務・財務・機器管理などの開発サポートの専門職も必要になる
    2. 精鋭は稀少だから精鋭
       
       
  3. ぢゃあ実際の大規模プロジェクトではどうやったらいいか?(ミルズの方法)
    1. 実装と設計を分ける(これ重要)
    2. 設計は、人員をいくつかのチームに分けたチームの長(執刀医)が行う
      1. 少数精鋭
      2. コンセプトの統一性
      3. コミュニケーションコストの限定
    3. 実装は、独立した機能を持つチームによって行う
      1. チームの機能ごとに担当者を設定する
         
        役割説明
        執刀医成果物を作る(デザイン・コーディング・ドキュメント・テスト)
        副執刀医成果物を作る(執刀医の子分・分身・予備)
        Doc編集成果物を評価・手直し・整形して参照や参考文献をつける
        PG事務成果物の管理をする・配布をする
        Unitテスト成果物のテスト準備とテストを行う
        ツール作成成果物を作成するためのツール(治具)を作成する
        言語エキスパート実装上の相談を受ける。複数のチームを掛け持ち
        管理人事・法務・機器管理を行う。法的にクリティカルなシステム開発でなければ、複数チームを掛け持ち
         
      2. こうすることで
        ・コミュニケーションコストを限定できる
          各担当者は執刀医としかコミュニケーションをとらなくていいので
          人間関係のパスは 7*6/2= 21 -> 6 に減少
        
        ・おざなりにされがちな仕事(PG事務など)がきちんと行われる
        
        ・実際にプログラム製品を制作する執刀医・副執刀医が、プログラム製品制作に集中できる
         
        mills_plan.png
        ミルズの方法のイメージ図
         
  4. 俺様メモ
    1. 最初呼んだときには大時代的だと思った
    2. よくよく考えてみるとよく考えられていて現代にも適用できる
      1. 設計と実装を分けて執刀医は両方やるのはよい考え
        筆者はコミュニケーションのパスが小さくなることと、コンセプト(基本設計?)の 統一を利点にあげているが、
        日本では多くのプロジェクトが、実装できない人間が設計をやって、実装で泥縄対処->デスマになっていることを考えると、
        実装チームのリーダーが設計をやるのは魅力的
         
      2. ネットワークやGUI・ツールが進歩してもチームに必要な機能は変わらない
        PG事務などはCVS/VSS・編集はJavadoc+xOffice・テストはxUnitを使うなどで必ずし も1チームに1人を貼り付ける必要はなくなってきたが、そもそも 実装チームにはそういう機能が必要 だからそういうツールができたということを意識しないといけ ない。
         
      3. 工程による人員投入
        コアチーム(執刀医)は、プロジェクトの最初から最後までいて
        工程によって実装チームの人員を増やしたり減らしたりしたらどうだろうか?
         
        少なくとも執刀医は最初から最後までいて、設計と実装をやるべき!!!!
        要求仕様定義は、どちらかというと経営コンサル的なので別だけど、
        概要設計以降は、「実装できないから設計やる」は言語道断
         
        概要設計詳細設計実装結合テスト運用テスト
        執刀医執刀医執刀医執刀医執刀医
        副執刀医副執刀医副執刀医
        副執刀医
        Doc編集Doc編集
        UnitテストUnitテストUnitテスト
        ツール作成ツール作成
        言語エキスパート
        管理+秘書

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

プログラミングシステムにはコンセプトの統一性が大事である

 
  1. プログラミングシステムの目的 = コンピュータを使いやすくすること
    1. 「使いやすくなった」の定義
      • (機能の指定で節約できた時間)が (マニュアルを勉強したり・調べたり・記憶したりするのにかかる時間) より大きくなる
    2. 「使いやすくする」ためには?
      • システムの機能数が適切である
      • システムの操作が簡潔である
      • システムの操作が直感的である
    3. 機能数を適切にしたり操作を簡潔にすることは機械的に可能だが、システムの操作を直感的にすることは難しい
    4. そもそも「直感的なシステム」とは?
      • 複雑な処理を行う際の慣用的なコマンドの組み合わせがユーザの頭の中にすぐに思い浮かぶシステム
    5. 「システムの操作が直感的である」ためには?
      • 語義(基本コマンド)それぞれが同じ重みを持つようにする
      • 構文(基本コマンドの組み合わせ)の構造が同じ文法で表せるようにする
    6. では、「直感的なシステム」を作るには?
      • システムのデザイン(コンセプト)を一人もしくは少数の人間で作ればよい
  2. 現実のプロジェクトで「使いやすい」システムを作るには
    1. 3章で述べたようにアーキテクチャインプリメンテーションを慎重に分離する
    2. アーキテクチャインプリメンテーションの違い
      • 「アーキテクチャは何が起こるのかを語るのにたいして、インプリメンテーションはいかにして起こせるかを語る」
      • 時計の場合
        アーキテクチャねじを回して針を現在時刻にあわせる。針が文字盤を指したところが現在時刻
        インプリメンテーション振り子を使って針を進める・ゼンマイを使って針を進める・クォーツとステップモーターを使って針を進める・・・
      • FORTRAN
        アーキテクチャANSI FORTRAN IV
        インプリメンテーションPDP10用Fortranコンパイラ、System360用Fortranコンパイラ、Multics用Fortranコンパイラ、CP/M用Fortranコンパイラ・・・
    3. プログラミングシステムのアーキテクチャとは?
      • 実装者から見ればユーザーインタフェースについての完全かつ詳細な仕様書
      • 利用者から見れば一番詳細なマニュアル
    4. アーキテクチャを決めるのはアーキテクトに限るべし
      1. アーキテクトだけが良いアイデアを持っているというつもりはない
      2. 実現者や利用者から良いアイデアや新鮮なコンセプトが出てくるのはよくあること
      3. とはいえ、システムの使いやすさにとって「直感性」=「統一されたコンセプト」は命
      4. だからシステムの基本的コンセプトと相容れない優れた機能やアイデアは除外すべきである
      5. そういう機能やアイデアがたくさんあるようならコンセプトの方が間違っているので基本コンセプトからやり直せ
    5. 民主的にアーキテクチャを決めると・・・
      アーキテクチャとインプリメンテーションを厳密に区別しないプロジェクトでは
      • 思考と議論の大部分がアーキテクチャの決定に注がれる
      • インプリメンテーションには、死刑執行前に与えられる懺悔の時間くらいしか与えられない
  3. 貴族政治擁護想定問答
    少人数のアーキテクトチームでシステムの外部仕様を書こうとする場合に想定される想定問答
    1. そういう仕様書には機能が多すぎて、現実的なコストの検討がされない
      • これは実際に起こりうる問題
      • 第5章で述べる
    2. アーキテクトが創造的楽しみを独占して、実装者の創意工夫が閉め出されてしまう
      • これは妄想
      • インプリメンテーションも同等の創造的活動である
        読書メモ:腐ったアーキテクチャーに針の糸を通すような実装をして、Unitテストが通ったらソーっとパンドラの箱に封印して、後は自分がプロジェクトからはずれるまで出てこないことを祈る・・・なんてことも確かに創造的ではあるけど。著者のいっているのはそういうレベルの話ぢゃないんでしょうね(^^;
         
      • バッハのカンタータだってそうやってできた
    3. 仕様書がアーキテクトという細い管を通ってくる間多くの実装者がただ漫然と待っていなくてはならない
      • これは妄想
      • 一番良いのは仕様書が完成するまで実装者を雇わないこと
      • 実装者を雇っちゃった場合でもやらなきゃいけないことはいろいろある
        ・データフローや制御の流れを理解する
        ・アルゴリズムや技術的課題をクリアする必要がある
    4. 大人数でシステムのデザインをするよりも時間がかかるのでは?
      • 経験からいって、システムのデザインにかかる時間は同じ
      • インプリメンテーションやテストの時間は、コンセプトが統一されていた方が遙かに短くてすむ

第5章 セカンドシステム症候群

アーキテクチャに機能を盛り込みすぎてしまった場合の対処法

  1. デザインを切りつめる
    • これは顧客さえ納得すれば大きな問題は起きない
  2. インプリメンテーションを安く抑える
    • これはアーキテクトが実装者の領分に踏み込んでいるので感情的対立を生みやすく、巧く対処する必要がある
      1. アーキテクトは提案すべし
        インプリメンテーションに関しては実装者側に創意工夫および創造の責任があるのだから、アーキテクトは指示ではなく提案をしなければならない。
      2. 設計者は実装もできなきゃダメだよ
        自分が指定する仕様に対するインプリメンテーションの実現方法を一つ、いつでも提案できるようにしておく。また、目標を同様に満たす別の方法を受け入れられるようにしておく。
        読書メモ:それ以前の問題として、データフローのチェックもしていない仕様があるんですが・・・というか、そもそもデータフローという概念がない・・・まぁ、ここではそういう問題外の話をしているんぢゃなくて「ちゃんとやっているのになぜ失敗するんだろう」って話なのですが・・・
         
      3. こうした提案は、穏やかに非公式に行う。
         
        読書メモ:実現者の方では公式なメモに残しておいた方が良いですが・・・
         
      4. 提案された改善点は、率先して受け入れることができるようにする。
        実装者がアーキテクチャの変更を要求してくることがあるが、この場合には全体に大きな破綻が生じないようならば受け入れるべきである。 アーキテクチャとしてはたいしたことのない機能でもインプリメンテーションの段階では、予想外にコストが高くついたりするものだ。
  3. アーキテクチャに機能を盛り込みたくなるお年頃
    • 一度慎重に機能を絞り込んでプロジェクトを成功させたアーキテクトは、二度目に担当するプロジェクトにたくさんの機能を盛り込みたくなる = セカンドシステム症候群
    • セカンドシステム症候群を回避するには
      • 機能をシンプルに保つように意識する
        読書メモ:今日のKISSですな."Keep It Simple & Smart." / "Keep It Simple, Stupids."
        元は米海兵隊での合い言葉で、"Keep It Simple, Stupids."が元祖、後ソフトウェア業界で "Keep It Simple & Smart." といわれるようになった。
         
      • レスポンスタイムや占有メモリ領域に数値目標を立てる
      • 少なくとも二度システム開発を経験しているアーキテクトを上級アーキテクトに置く

第6章 命令を伝える

  1. 設計と実装をつなぐのはユーザマニュアル
    manual.png
  2. マニュアルの要件
    1. 設計・実装からの要求に従って変更が加えれられる。必ずバージョン管理すること
    2. 過不足なく正確に記述される必要がある
    3. 必要事項は繰り返されていて、それぞれが一致している必要がある
      • 利用者は一つの説明だけを参照するから
      • 某社のJ2EEコンテナのマニュアルようにたらい回しにするのはよくない・・・しかも「何らかの異常です」はまだ良い方で、たらい回しにされたあげく元のページに戻るなんてことも・・・
    4. 項目同士の重みづけ(章にするか節にするか)や順序などは全体で一貫していなければならない
      • これはマニュアルの読み易さにとって本質的な要件
      • マニュアル作りは少人数(せいぜい2人)でやるのが望ましい
    5. 制限事項(できないこと)についても記述されていること
  3. マニュアルの記述言語
    1. 自然言語と形式言語を組み合わせて使う
      • 形式言語(BNFなど)を使うと、完全であろうとするため設計と実装のギャップが目につきやすく結果として設計の誤りが補正される
      • 自然言語(英語など)は、定義に厳密さを欠けるが、なぜそのような設計になっているかを表現できる
    2. ただし、どちらかを標準、どちらかを補足として用いなければならない
      「海へ持って行くクロノメーターは2個ではいけない。
        1個だけにしておくか、さもなければ3個にしなければならない」
    3. 形式言語を利用するときの注意点
      • 形式言語はインプリメンテーションまで記述できるので、マニュアルに利用するときには外部仕様を定義しているのだということを意識しなければならない
      • 形式言語を使えば、既にあるインプリメンテーションから外部仕様を容易に定義することができる。互換機の開発はまさにそうして行われる
  4. 元々仕様にない使い方が慣用的に使われているときには、事実上の標準として取り込まなければならない
    • FM-8のYAMAICHIコマンドのようなものか
  5. マニュアルの修正
    • 週に半日、[アーキテクト全員]と[実現者の代表責任者]、[利用者(市場企画者)]でマニュアルを挟んでミーティングをする。大部分の決定や合意は週次ミーティングで為される
    • マニュアルの主要な凍結のタイミングで、週次ミーティングで積み残された些細な内容を吟味する
  6. 複数インプリメンテーション
    • 複数のインプリメンテーション(先行開発?)を行うことで仕様をより厳密にすることができる。
    • 通常、機械とマニュアルに齟齬があるときには、マニュアルを修正する。これは
      マニュアル修正のコスト < 誤った実装の修正のコスト
      だから
    • ところが、仕様を正しく実装した複数のインプリメンテーションがある場合には
      誤った実装の修正コスト < マニュアル修正のコスト + 正しい実装の修正コスト * n
  7. 電話の記録
    • 実現者とアーキテクトとの会話のやりとりを非公式なFAQとしてまとめておき、実現者や利用者で共有できるようにしておくとよい
  8. 製品テスト
    • 独立した製品テスト機関は、日々の敵であり最良の友であると考えよ
    • テスト担当者は、テスト計画を立てるときに、アーキテクチャとインプリメンテーションの結合点(つまりマニュアル)で、システムのデザインが適切に理解されていなかったり実現されていないことを指摘することができる
    • テスト計画は、システムのデザイン段階から表裏一体一緒に機能しなければならない
      某社のシステム開発でよく行われているように、製品実装後にテスト計画を立てると、設計段階での誤りを発見できない・・・何度も具申しているんですが・・・

第7章 バベルの塔はなぜ失敗に終わったか

  1. バビロンプロジェクト失敗の原因
    1. 表面的な理由ではない
      • 使命・目的がなかったから?NO
      • 要員が不足していた?NO
      • 材料が不足していた?NO
      • 時間が不足していた?NO
      • 技術力が不足していた?NO(技術的限界に突き当たる前にプロジェクトは放棄された)
    2. プロジェクト体制に根本的な原因があった
      • コミュニケーション不全
      • プロジェクトの指揮命令系統が考慮されていなかった
  2. 大規模プロジェクトにおけるコミュニケーション
    1. プロジェクト・ワークブックを作れ!
      • 全ての技術メモと、技術メモ同士の関係を木構造で整理したもの
      • 目的・外部仕様書・インタフェース仕様書・技術標準・内部仕様書・管理用備忘録など全てのドキュメントがワークブックに含まれる
      • ワークブックを通して情報の共有を図る
      • 全ての文書がワークブックの一部をなすために、技術メモの構成や記述をある程度統一できる
      • プロジェクト手引き書は最終的にマニュアルになる
    2. 非公式な問い合わせやミーティング(第6章)は、ワークブックへの共通理解のうえでなされる(あるいは共通理解がされていないという共通理解の上でなされる)
    3. ワークブックの配布
      • 初版本では、全プログラマが、ワークブックの全てを読むべきだとしていた。
      • 初版本では、「自分の担当以外は隠蔽されていた方がプロジェクトの生産性は高い」とするDLパルナスの主張を「失敗のレシピ」と読んでいた
      • 20周年記念増補版で増補された19章の中で、DLパルナスの方法が正しく初版の考え方は誤りだったと述べられている
      • 今ではDLパルナスの方法が当たり前、MVCなどの階層モデルや、Agileなどの漸近的開発、テスト駆動開発、UML・・・では、自分と関係ないところはインタフェースしか知らないで済むことが前提・・・なんですけどねぇ
  3. 大規模プロジェクトにおける組織に必要な要素
    org.png
  4. プロジェクトの主導権は誰が執るべきか
    1. 主任マネージャーと主任アーキテクトが同一人物の時
      • 3〜6人のプロジェクトではうまくいくが、大規模プロジェクトでは人間の処理能力を超える
      • 管理能力と技術能力は、直交するスキルなので、どちらも人に優れている事は難しい
      • 問題が起きたときに、問題に専念できないし相談も出来ない
    2. 主任マネージャーが主導し、主任アーキテクトが右腕となる場合
      • 主任マネージャが、技術的な決定権が主任アーキテクトにあることをプロジェクト要員に示せればうまくいく
      • 席順を工夫したり、ちょっとした権威を印象づける小物を与えることが効果的
      • 「プロジェクトマネージャーならば管理的才能に乏しい技術的天才を活用することぐらいは出来るはずだ」
    3. 主任アーキテクトが主導し、主任マネージャーが右腕となる場合
      • これもうまくいく方法
      • 第3章 外科手術チーム で紹介した「ミルズの方法」はこのやり方

第8章 予告宣言する

作業量の見積もりについて

  1. システム全体の作業量の見積もりについて
    1. プログラムシステム開発の労力をコーディング量から見積もってはならない
      • 2章で述べたように、コーディングは全体の労力の約1/6
      • だからといって、コーディングの労力を単純に6倍して全体の労力を見積もると、コーディング量の見積もりミスが6倍になって全体の労力に反映される。
    2. 開発対象のシステムの規模によって必要な労力は線形に増えない
      • 100m10秒で走れるからといって、10kmを17分で走れるわけではない
      • システムの規模が大きくなると、教育・コミュニケーション・手戻りなどが発生
      • (システム開発の労力) = (定数) * (規模)^n
      • nは、実績データにより、1.05〜1.2 や 1.5 という結果が得られている
  2. プログラミングの生産性
    1. プログラマは労働時間の50%しかコーディングしていない
      • 事務手続きや病気などで、年平均すると50%しかコーディングしていない
      • 見積もりの際にはこの点を注意すること
    2. 実現するシステムの複雑さによってプログラミングの生産性は違う
    3. プログラムシステムの規模や複雑さを考慮に入れれば、プログラミングの生産性はいろいろな研究でほぼ一定している(->定式化が可能?)
      • MULTICS開発のデータ
      • OS/360開発のデータ
      • '60を通じたIBMのデータ
      • '60を通じたAT&Tのデータ
    4. 高水準言語を使うことによってコーディングの生産性が数倍になることがある

第9章 五ポンド袋に詰め込んだ十ポンド

  1. プログラムのメモリ容量のコントロール。
    1. ビルの1フロアを占領するマシンのメモリ容量が2MBの時代の話
    2. 今日のようにメモリ容量と処理能力が有り余っている時代では、むしろ可読性やメンテナンス性の方が優先されるため、この章の内容は現代では時代遅れ
  2. 最後の節は普遍的な話
    1. 簡潔で余分なところがなくてスピードの速いプログラム
      • 地道なブレークスルーの結果
      • 奇策の結果ではない
    2. ブレークスルーをもたらすもの
      • データ構造の改良
      • アルゴリズムの改良
    3. データ構造こそプログラムの本質である
      • 制御コードから一歩引いて、データ構造を見直すことにより(設計・性能上の)問題を解決できる

第10章 文書の前提

  1. マネージャの仕事
    1. 計画を作成し実行すること
    2. 文書化された計画のみが明確で伝達可能
    3. マネージャの仕事 = 文書の管理・詳細化
  2. 文書化された計画とは?
    1. 決定事項を明確化したもの
      • マネージャにとって集中して問題に取り組むときに必要な道具
    2. 決定事項を他人に伝えられるようにしたもの
      • マネージャにとって問題点を明らかにし、議論をまとめるときに必要な道具
    3. 計画のデータベース兼チェックリスト
      • プロジェクトが今どこにいるのか?
      • どのような指示や方針の変更が必要か?
  3. 文書の前提---紙が怒濤のごとく押し寄せるさなか、少数の文書は、全てのプロジェクトの管理がそのまわりをめぐるような決定的な軸となる。そういう文書が、マネージャの主要な個人的な道具となる。
  4. 計画の文書化の要件
    • 何を
    • いつ
    • いくらで
    • どこで
    • だれが
  5. ソフトウェアプロジェクトのための文書
    • 何を:目的
      • 満たすべきニーズ、目標、必要となるもの、制約事項、優先順位
    • 何を:製品仕様書
      • 提案書 → マニュアル・内部仕様書・性能要件
    • いつ:スケジュール
    • いくら:予算
    • どこで:開発拠点
    • だれが:組織図(コンウェイの法則)
      1. システムをデザインする組織は、その組織のコミュニケーション構造そっくりのシステムを制作するように強いられる
      2. 組織図は最初のシステムデザインを反映するが、そのデザインはほとんどの場合正しくないので、組織は柔軟に変更できる必要がある

第11章 一つは捨て石にするつもりで

  1. 普通の工業ではパイロットプラントで理論を実証するが・・・
    1. 研究所ではうまく行く化学反応でも、一足飛びにはそれを使ったプラントを作れないことは、普通の工業では常識。パイロットプラントで実証する。
    2. ソフトウェア開発では、こうした教訓が未だに理解されていない
      • 次から次へとできたものを顧客に配布しているのが現実のプロジェクト
      • しかし、最初に完成したシステムは使い物にならない
      • 最高のプランニングでも一回で成功するほど計算し尽くされていない
  2. 一つは捨て石にするつもりで
    1. ソフトウェア開発でもパイロットシステムを作成して破棄せねばならない
    2. 廃棄するものを顧客に配布してもよいが、
      • 利用者に苦悩を課す
      • 制作者に混乱を与える
      • 顧客に修正を行うことを説明することが難しい
      • 顧客に悪印象を与える
    3. 一つは捨て石にするつもりでいなければいけない。どうしたってそうせざるを得ないから
  3. 変化に対応する
    1. 変化に対応する第一ステップは、変化を不運でやっかいな例外ではなく、日常的なものとして受け入れることだ。
    2. プログラマの仕事とは、目に見える具体的な製品より、むしろ利用者に対しニーズに適う満足を届けることだ(J・コスブローブ)
      • 利用者のニーズとニーズに対する認識の両方が、プログラムが作成され、テストされ、使用される中で、変化していく
      • 変化を全て取り入れずに閾値を設定する必要がある。プロジェクトが進むにつれて閾値を高くする必要がある
  4. 変化対して柔軟なシステム開発
    1. モジュール化・サブルーチン化・モジュール間のインタフェースの的確かつ完全な定義
    2. モジュールの標準的な呼び出し順序
    3. 変更を量子化する
      • バージョン管理とマイルストーンでの凍結
      • 反復テストの実施-変更が行われた場合は全てのテストを再実行する-
  5. 変化に対して柔軟な組織
    1. 管理職と技術職は同格でなければならない
      • 上級者は、グループを統率することと、技術的課題を解決することの両方ができなければならない(ときにはプログラミングすることを厭ってはならない)
      • マネージャには技術に関する再教育が必要で、上級技術者には管理職のトレーニングが必要
    2. 通常は管理職の方が高い権威を持っているので、企業として管理職と技術職が同格であることを示さねばならない
      • 技術畑と管理畑で同格の上級職の場合、オフィスは同じ広さで同じ設備になっていなければならない
      • 技術畑から管理畑へ移るときには「昇進」ではなく「配置転換」として発表し、「昇給」があってはいけない
      • 逆に管理畑から技術畑へ移るときには「降格」でないことを示すために、「昇給」が必要である
    3. IBMの場合
      (管理職の職位)           (技術職の職位)
      上級プログラマ           上級プログラマ
            ↑                       ↑
      主任プログラマ           主任プログラマ
            ↑                       ↑
      プロジェクトプログラマ       スタッフプログラマ
                    ↑          ↑
                  準上級プログラマ
    4. Xeroxの場合
      管理職・技術職という区別を廃止した
  6. システム完成後の変化
    1. プログラム配布後のメンテナンスには、開発費用の40%程度を見なければならない
    2. 二歩進んで一歩さがる
      • 初期のプログラムメンテナンスは、欠陥の修正が別の欠陥を生み出す(二歩進んで一歩さがる)
      • 反復テストによりある欠陥の修正によって別な欠陥が生み出されていない事をテストできる
      • 適切なモジュール化により、欠陥の修正が広範囲に影響することを避けることができる
    3. 一歩進んで一歩さがる
      • 長い間システムをメンテナンスし続けると、システムから秩序が失われ、やがて修正を加えても改善につながらなくなるときが来る(一歩進んで一歩さがる)
      • システムプログラムとは、エントロピー減少の過程。メンテナンスは、エントロピー増大の過程。
      • どんなに器用にメンテナンスしても、システムが手に負えなくなるほど複雑化するのを遅らせるだけで、やがてはシステムの全面的な刷新が必要になる。

第12章 切れ味のいい道具

  1. プログラミングツール
    1. プログラマは自分用の道具を持っているが、これはプロジェクトにとってよいことではない
      • プログラマ各個が違う道具を使うことによりコミュニケーションの妨げになる
      • 機械や使用言語が変わるとツールは使えなくなるので、個々人でつくるのは非効率
      • 汎用的なプログラミングツールを共同で開発・メンテナンスする方が効率的
    2. プロジェクトのプログラミングツール
      1. プロジェクト共通のツール
      2. チーム毎のツール (チーム毎のツールを共通チームでつくるのは一見効率的だがチーム毎にツール作成担当者をおいた方がプロジェクト全体から見て効果的)
  2. この章の残りの部分は、プロジェクトで用意する機器とタイムシェアリングの方針の話。
    1. 今日では個々人の開発端末が十分な計算能力を持っていて、デバックやコンパイル・本番環境のエミュレートができるので当時の手法は今日では昔話のたぐい。
    2. むしろ、今なお開発端末を単なるエディタとしてしか使わないプロジェクトが多い(バージョン管理すら使わない)。もうアホかバカかと・・・

第13章 全体と部分

  1. どのようにして「きちんと動く」システムを作成するか
    1. Henry IV part I:
      GLENDOWER 
       I can call spirits from the vasty deep.
      
      HOTSPUR 
       Why, so can I, or so can any man;
       But will they come when you do call for them?
      http://www-tech.mit.edu/Shakespeare/1henryiv/index.html
    2. プログラムを書くのは誰にでもできる。どのようにプログラムをテストし、サブシステムを結合し、テストに合格するシステムを作るのか?
  2. バグの少ないシステム仕様
    1. 製品コンセプトの統一
      • 多くのバグはサブシステム間のデータの受け渡しに関するもの
      • 製品のコンセプト(サブシステム間のインタフェースや受け渡されるデータ構造の設計指針をシステムとして統一する)をはっきりさせることにより、サブシステム間のデータの受け渡しに関するバグを減らすことができる
    2. 製品仕様を明確化する
      • 「重要な仕事は、製品を定義することだ。数多くの失敗は、まさしくそういう風に十分に詳述されることの無かった局面に関係している」(V.A.ビソーツキー AT&T)
      • 余分な飾りやテクニックの飛躍を廃して、全てを記述する
      • 曖昧な記述を排し、明らかにあっているか、明らかに間違っているか分かるようにする
    3. トップダウンデザイン
      • システムの仕様を徐々に洗練していくやり方(ウォーターフォール)
      • 要求仕様->概要設計->詳細設計->プログラミング
      • システム・サブシステム・モジュールの各設計段階で、要件(構造や機能)を明確に記述することができる
      • 各設計段階で構造上の欠陥をより明確にできる
         
        耳かっぽじってよく聞け
        ステップごとの洗練というプロセスは、予想外に混乱した詳細に直面した場合、
        後戻りしたり、トップレベルを破棄し、全く最初からやり直すことをしない
        という意味ではない。実際そういうことはしょっちゅう起こるものだ。
                  ^^^^^^^^^
        しかし、こうすれば、ひどいデザインを廃棄してやり直すべきタイミングと理由を
        はるかに理解しやすい。多くの貧弱なシステムは、まずい基本デザインを化粧品で
        塗り固めてすくい上げようとした結果の産物だ。トップダウンデザインでは、
        こうした誘惑を少なくできる。
    4. 構造化プログラミング
      • ダイクストラ(最短経路法を発見した人)の唱えた高級言語の設計指針
      • [逐次処理・条件分岐・ループ]のみでアルゴリズムを記述できるし、そうすべき
      • [goto]禁止。
      • 著者の Frederic Phillips Brooks Jr. は、「全てのGOTOを回避すべきだという学説の信奉者も現れるにいたっては、さすがに行きすぎのように思われる」と書いている
      • 今日for文中の break、continue。例外処理 try{}catch(){} などで一部GOTOは復活している。逆に言えば必要なGOTOは別の表現で用意されているので、今日「全てのGOTOを回避すべき」というのは真。(Javaにはgotoはない(Java言語の予約語だが機能は定義されていない))
  3. 仕様書をテストする
    • コードができあがるずっと前に仕様書は外部のテストグループに渡されてテストされるべき
    • 設計者自身が仕様書をテストすることはできない、
      「彼ら(設計者)は、分からないことははっきり言わない。(仕様書の)ギャップや曖昧な部分は、喜々として自分流に解釈しようとするのだ」(V.A.ビソーツキー AT&T)
  4. テストとデバックのテクニック
    1. システムテストには、デバック済みのコンポーネントを使う
      • コンポーネントにバグが残っているときに、そのバグが影響するシステムテストを予想して後回しにするのは愚かなこと。コンポーネントのバグがシステムにどのような影響を与えるのかは誰にも分からない。(スケジュールの遅れをもっともらしく見せることはできるかも・・・)
      • スケジュールが遅れているならば、次に述べる「足場」を利用したテストをすすめるべき
    2. 「足場」をつくる
      • ダミーコンポーネント : 完成していないコンポーネントの代わりに適当なデータを返すダミーコンポーネントを作成してシステムテストを行う
      • ダミーファイル : 完成していないコンポーネントが出力するファイルの代わりに適当な(そのコンポーネントが出力する典型的な)ダミーファイルを準備しておき、システムテストを行う。
    3. 変更を統制する・変更を量子化する
      • System360開発では、日々の変更には紫色のワイヤーを使い、マイルストーンではプロジェクトの責任者が黄色のワイヤーに置き換えた
      • CVSでいうところのブランチ
        提供バージョンは、提供バージョンのbug fixを行い、開発バージョンで新機能が盛り込まれる。
        新機能は、次のリリースで提供バージョンとマージされ、新たな提供バージョンと、
        開発バージョンの出発点となる。
                     bug fix    bug fix             bug fix
                       1.1       1.2                 3.1
                 +→---+---------+-----+    +→-----+------- (提供バージョン)
         0.9     ↑                     ↓    ↑
        --+--V1.0+                     +V3.0+
                 ↓                     ↑    ↓  
                 +→+---------+-----+--+    +→+-------+---- (開発バージョン)
                    2.1       2.2   2.3          4.1     4.2
                   新機能   新機能 新機能        新機能  新機能
    4. 一回に追加するコンポーネントは一つだけにする
      • コンポーネントが追加・変更されるたびに全てのテストをやりなおす

第14章 破局を生み出すこと

  1. スケジュールは、一度に一日ずつ遅れる
    1. スケジュールが壊滅的に遅れたのは、大変な不運が続けざまに起こった結果ではない。このような不運は対処可能だし、何より対処しようとする。
    2. 一つ一つの、スケジュールを半日か一日遅らせる事件・事故が積もり積もってプロジェクトは一度に一日ずつ一年遅れる。
    3. どのようにすれば、小さな失敗が、プロジェクト全体の破局に発展することを避けることができるのか
  2. マイルストーンは具体的に
    1. まず最初のステップとして、スケジュールそのものをつくらなければならない
    2. 次に、スケジュールのマイルストーンは、具体的(100%完成の成果物)でなければならない
      • マイルストーンが自分も欺けないくらい鋭利だと思えば、進捗をごまかそうとは滅多にしない
      • 好意的にいえば、ごまかそうとはまではしなくても、報告者側で表現をやわらげてしまい、上司はしばしば報告を報告者とは異なる意味に解釈してしまう
  3. クリティカルパスを明らかにする
    1. Google.jp:パート図で、プロジェクトのクリティカルパスを明らかにする
    2. パート図を見れば、自分たちの担当する作業がクリティカルパスにならないようにするため、どれだけ頑張らなければならないのか、どれくらい遅れを取り戻さなければならないのかを知ることができる。
  4. 第一線のマネージャは、二つの理由で問題が起きても、完全に自分に手が終えなくなるまで報告しない
    1. 報告した問題に見当はずれな方法で介入される可能性があると心配している
    2. 上司が自分の権限を縮小し、自分の抱えているうまくいきつつある他の計画を台無しにするのではないかと心配している
  5. プロジェクトの現状を共有するためには
    1. 状況検討のミーティングと問題対策のミーティングをはっきり分ける。
      • 現状を報告しているときに、頭越しに(ときには的はずれの)対処をされるならば、マネージャは状況を正直に報告しないだろう
      • 逆に、上司が状況報告を受け取ったとたんパニックに陥ったり、自分の頭越しに処理をしないことを知っていれば、マネージャは状況を正直に報告するものだ
    2. マイルストーンと実際の完了を表す一覧表を作成する。
      • プロジェクトの状況が具体的に共有される
      • 状況報告会では、なぜ遅れているのか?完了するのはいつか?どのような対策をとっているのか?どのような援助が必要か?という話ができる
  6. プロジェクトの進捗を管理するには、
    1. プラン&コントロールチームをつくる
    2. プラン&コントロールチームは、マイルストーンが満たされているかをコンポーネント・マネージャに問い合わせる事しかしない
      • 報告に従いマイルストーンを設定・改訂する
      • 報告に従いパート図を作成・更新・改訂する
    3. プラン&コントロールチームが進捗を管理し、報告資料を作成してくれるので、コンポーネント・マネージャはより本質的な問題に取り組むことができる
    4. プラン&コントロールチームは、ごくわずかな徐々の遅れを白日の下にさらし、危険な要素を指摘する。彼らは、一度に一日ずつ遅れて結局は一年失ってしまうことに対する早期警告システムである
    5. プラン&コントロールチームは、本質的に嫌われ役だが、プロジェクトが終われば感謝される。

第15章 もう一つの顔

  1. プログラムには、機械に対する命令の羅列という顔の他に、人間が理解するためのドキュメントとしての顔がある
  2. プログラムに必要なドキュメント
    1. プログラムを作るために(概要と詳細を記述することがポイント)
      1. このプログラム(モジュール)の目的
      2. 実行環境
      3. 入出力概要
      4. 処理概要
      5. 入出力フォーマット(副作用:ファイル、DB)
      6. オペレーション指示(返値:例外を含む)
      7. オプション(入力:API仕様)
      8. 実行時間・実行サイズ
      9. 処理結果の精度およびその検査方法
    2. テストケース
      1. 疎通テスト
      2. ホワイトボックステスト(境界値テスト)
      3. ブラックボックステスト(境界値テスト)
    3. メンテナンス情報
      1. プログラム構造図
      2. 使用されるアルゴリズムの完全な記述。全ての参考文献への参照。
      3. 使用されるファイルレイアウトの完全な記述。
      4. 処理フローおよびデータフロー
      5. 現時点でどのような修正が可能か、どのように修正すべきか、どのような修正をすべきではないかを制作者が思いのままに記述したもの(これは非常に有益)
  3. フローチャート(゚゚)イラネ
    1. 高級言語は、きれいに書けばフローチャートと同等かそれ以上の表現力を持つ
    2. フローチャートでは構造化されたプログラミングをうまく表せない。複数ページにわたるときはなおさら
    3. というわけでフローチャートは役に立たないし、そもそも誰もフローチャートを書いていない
      新約聖書 使徒行伝15:10
      ペテロ「私たちの先祖にも私たちにも背負いきれなかったような重荷を
              なぜ今背負わせようとするのですか」
  4. プログラムソースと設計書を統合するのはよいアイデア
    • この本の中ではPL/Iプログラム中にコメントの形で仕様書を書く方法が述べられている
    • 今日のJavadocやdoxygen

第16章 銀の弾丸などない / 第17章 「銀の弾丸などない」再発射

  • 1995年の20周年記念版で追加されたもの
    • 「第16章 銀の弾丸などない」は、1985年に発表された論文
    • 「第17章 『銀の弾丸などない』再発射」は、「銀の弾丸などない」に対する批判に対する批判
  1. 論旨
    • (ソフトウェア開発において)技術においても管理手法においても、それだけで10年間に生産性や信頼性と容易性での飛躍的な改善を一つでも約束できるような開発は一つとしてない
  2. 理由
    1. ソフトウエア開発の作業は、本質的作業と偶有的作業からなる
      • 本質的作業 = 顧客の要望を概念構造体として記述すること
      • 偶有的作業 = 概念構造体をプログラミング言語として記述すること
    2. 今日では本質的作業がソフトウェア開発の主要な作業
      • ソフトウェア構築において困難な部分は、この概念構造体の仕様作成とデザインおよびテストで、
      • 表現することやその表現に忠実かをテストすることではない
    3. ソフトウェア開発の作業効率を劇的に改善するには、本質的作業の効率を劇的に改善する必要があるが、本質的作業は人間が創造力を使って頭の中で行う作業なので、劇的な改善を行える方法はない
    4. ソフトウェア開発で「銀の弾丸」として提案されているもののほとんどは、偶有的作業の生産性改善に関するもの。良さそうなものもあればインチキなものもあるが、良さそうなものでも偶有的作業を漸進的に改善できるものであって、ソフトウェア開発作業全体を劇的に改善できるものではない
  3. ソフトウェア開発を改善するには?
    • 本質的作業の性質を分析し、それに対する漸進的な対策を行っていき徐々に改善していくしかない
    1. 本質的作業の性質1(複雑性)
      • 概要
        ・ソフトウェアは人類が扱うものの中でもっとも複雑。
        ・さらに複雑性が複雑性を呼び(ソフトウェアの規模に従い非線形に複雑性が増す)、信頼性・セキュリティを損ね、プロジェクト管理を困難にする。
      • 対処法
        ・購入できるものは構築しない。
        ・信頼性のあるコンポーネントを再利用する。
    2. 本質的作業の性質2(同調性)
      • 概要
        ・後でできたサブシステムは、古い(新らしいサブシステムから見れば理不尽な)インタフェースに従わなければならない。
        ・プロジェクトの最初にできたサブシステムのインタフェースを下手に変えると全体が破綻しかねない。
      • 対処法
        ・ソフトウェア要件の確立に際して、開発環境計画の一部として、迅速にプロトタイプ開発をおこない、評価すること
    3. 本質的作業の性質3(可変性)
      • 概要
        ・ソフトウェアには常に変更の圧力がかかる。
      • 対処法
        ・ソフトウェアの概念構造体はあまりに複雑で、人間の能力では誤りなしに一気に構築するには手に余るので、暫増的(インクリメンタル)開発を行う。
        ・ダミープログラムから始まり、徐々に機能を「育成」していく。プログラムは常に動いて動作を確かめられる状態にある。
        ・この方法は顧客の要望を的確に組み込める以上に、開発チームにやる気をもたらしてくれる
    4. 本質的作業の性質4(不可視性)
      • 概要
        ・ソフトウェアのは目に見えない
      • 対処法
        ・優れたコンセプトデザイナーの育成が必要
        ・多くの企業は、マネージャーの育成と処遇には熱心だが、コンセプトデザイナーの育成には不熱心。これはよろしくない。
        ・優れたコンセプトデザイナーには、優れたマネージャーと同等の処遇が必要
        ・教育や選抜に関しても企業として体系的に考える必要がある

第18章 「人月の神話」の命題 - 真か偽か

第1章〜第15章の論点整理

第19章 「人月の神話」から二十年を経て

  1. なぜ20周年記念版を出したか?
    • ソフトウェア業界は、20年前に書かれた30年前のソフトウェア開発に関する問題を未だに抱えている
    • 以下出版から20年を経て、当時主張したことを検証してみる
  2. コンセプトの完全性について
    • 利用者から見て整合性のとれたユーザインタフェースが重要である
    • Macintoshはゴージャスな方法でコンセプトの完全性を成し遂げ成功した
    • きわめて扱いにくいにもかかわらずコンセプトの完全性により成功しているのがMS-DOS
  3. アーキテクトの重要性について
    • コンセプトの完全性を成し遂げるためにアーキテクトが重要なことは変わっていない
    • アーキテクトは監督で、マネージャはプロデューサー
  4. ウォーターフォールは間違え
    1. 初版当時「一つは捨て石にするつもりでいなければいけない」と主張したが事はそれほど簡単ではない事に気づいた
    2. そもそもウォータフォールの本となった考えは、1970年のウィンストン・ロイスの論文
      [計画]−+
        ↑    ↓
        +−[コーディング]−+
                ↑          ↓
                +−[単体テスト]−+
                        ↑        ↓
                        +−[結合テスト]−+
                                    ↑    ↓
                                    +−[運用]
      • 設計と実装を分けるべきである
      • 前段階へのフィードバックを行う
      • フィードバックはコストとスケジュールの遅れを考え一段階前までとする
    3. 1975年に国防総省が軍事ソフトウェアの標準開発体系DOD-STD-02167を作るときに、上流へのフィードバックが無くなってしまった(今日のウォーターフォール)
      [計画]−+
              ↓
            [コーディング]−+
                            ↓
                    [単体テスト]−+
                                  ↓
                            [結合テスト]−+
                                          ↓
                                        [運用]
    4. ウォーターフォールは、以下の点で最悪の開発体系
      • ソフトウェア開発の誤りは、コーディング工程のみで起きることを仮定しているが、ソフトウェア開発でもっとも困難なことは、何をするものかを定義しテストすることで、定義されたものを実装しテストすることではない
      • 計画段階での誤りは運用段階まで顧客の目に触れない
    5. 「一つは捨て石にするつもりでいなければいけない」というのはウォーターフォールを前提とした記述
  5. インクリメンタル・モデルで開発すべき
    1. コーディング段階では、最初にダミーデータを組み込み徐々に機能を拡張していく。常に動くようにする
    2. マイクロソフトの「毎晩構築」アプローチは大きな成功をおさめている
    3. インクリメンタルモデル開発とプロトタイプ開発による検証が現状での最適解
  6. 人月の神話性について
    1. バリー・ベームの研究
      • プロジェクトにかける時間T = k * (人月C)^(1/3)
      • 最適なk = 2.5
      • Tを大きく見積もるとCはそのままにkが大きくなる(時間がたっぷりあるとサボる)
      • Tを小さく見積もってもkは小さくならずCが大きくなる(開発期間を削ると費用が大きくなる)
      • 統計上どんなプロジェクトも最適に見積もられた(k=2.5)期間の3/4以上早くは終わらない
    2. ブルックスの法則について
      • R.D.ストックは、プロジェクトの人員追加が与える負の作用を軽減するさまざまな方法を提案している
      • 箴言としてのブルックスの法則は、注釈付きで未だに有効
        遅れているソフトウェアプロジェクトへの(単なる)要員追加は更に遅らせるだけだ
  7. 結局はソフトウェア開発は人間の問題
    • デマルコとリスターの「ピープルウェア」
      「われわれの作業にまつわる主要な問題は、本質的には技術的というより社会学
        的な問題だ」
      「マネージャの働きは、人々に作業をさせることではない。人々が作業できるよう
        にすることである」
    • 実働部隊に権限を委譲することは、実働部隊の士気と生産性を高めて、中央の管理部門の権威を高める。(MS・IBM・ローマ教皇庁の例)
  8. これからのソフトウェア開発
    1. パッケージソフトやミドルウェアをコンポーネントとして利用する
    2. パッケージソフトやミドルウェアをメタ言語として、その上でより高次な概念構造体の構築に取りかかれるようになる
  9. これからのソフトウェア・エンジニアリング
    1. ソフトウェア・エンジニアリングは結局は複雑な人間の振る舞いに還元されるので、現状では電気工学や化学工業のような意味で、エンジニアリングと呼べないかも知れない
      • システムにむけてプログラムセットをデザイン、実現する方法が確立されていない
      • プログラムまたはシステムを、安定した、テスト済みで、文書完備のサポート付き製品になるようにデザイン、実現する方法が確立されていない
      • 大量の複雑性に対して知的制御を維持する方法が確立されていない
    2. 化学工業も20Cまでは、化学反応を大規模な工業として制御することができなかった。ソフトウェア開発に関しても、経験や理論を積み重ねて行きエンジニアリングとして確立させていくことが必要である。

Culture


*1 この書物の預言の言葉を聞くすべての者に、わたしは証しする。これに付け加える者があれば、神はこの書物に書いてある災いをその者に加えられる。また、この預言の書の言葉から何か取り去る者があれば、神は、この書物に書いてある命の木と聖なる都から、その者が受ける分を取り除かれる。

添付ファイル: filemills_plan.png 790件 [詳細] fileorg.png 813件 [詳細] filemanual.png 609件 [詳細]

トップ   編集 凍結解除 差分 バックアップ 添付 複製 名前変更 リロード   新規 一覧 単語検索 最終更新   ヘルプ   最終更新のRSS
Last-modified: 2006-02-15 (水) 01:34:30 (3082d)
ISBN10
ISBN13
9784061426061
Tex → Image Converter