![[PukiWiki]](image/pukiwiki.png "[PukiWiki]")
|
Books 人月の神話 |
この業界の聖書とでもいうべき「人月の神話(Frederic Phillips Brooks Jr.)」の読書メモです。でも黙示録22-18/19*1みたいなことは書いてないんで、あらすじを書いたり補足(ツッコミ)を入れても寿命が縮まったりすることはないでしょう。暇そうだからとデスマに投入されるおそれはあるかもしれませんが・・・
18章で筆者は同じように全体の論点整理をしているけど、微妙に視点が違うかな・・・
筆者は、工学書としてこの本を書いて、そういう視点で論点整理をしている。
小生は、お話としてこの本を読んで、そのあらすじをここに書き留めている。
本書で扱う問題の整理
プロジェクト失敗の原因
素材 + 設計 --(実現)--> 製品 素材と設計どちらがかけても製品はできない
1/3 計画 1/6 コーディング 1/4 単体テスト・結合テスト・疎通 1/4 システムテスト
例:
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
100人月のプロジェクトの人間関係のパス 100*99/2 生産性10倍の精鋭部隊10人の人間関係 10*9/2 -->同じ100人月相当の仕事をするのに、少数精鋭だと コミュニケーションのコストは1/100
| 役割 | 説明 |
| 執刀医 | 成果物を作る(デザイン・コーディング・ドキュメント・テスト) |
| 副執刀医 | 成果物を作る(執刀医の子分・分身・予備) |
| Doc編集 | 成果物を評価・手直し・整形して参照や参考文献をつける |
| PG事務 | 成果物の管理をする・配布をする |
| Unitﾃｽﾄ | 成果物のテスト準備とテストを行う |
| ﾂｰﾙ作成 | 成果物を作成するためのツール（治具）を作成する |
| 言語ｴｷｽﾊﾟｰﾄ | 実装上の相談を受ける。複数のチームを掛け持ち |
| 管理 | 人事・法務・機器管理を行う。法的にｸﾘﾃｨｶﾙなｼｽﾃﾑ開発でなければ、複数チームを掛け持ち |
・コミュニケーションコストを限定できる 各担当者は執刀医としかコミュニケーションをとらなくていいので 人間関係のパスは 7*6/2= 21 -> 6 に減少 ・おざなりにされがちな仕事(PG事務など)がきちんと行われる ・実際にプログラム製品を制作する執刀医・副執刀医が、プログラム製品制作に集中できる
| 概要設計 | 詳細設計 | 実装 | 結合テスト | 運用テスト |
| 執刀医 | 執刀医 | 執刀医 | 執刀医 | 執刀医 |
| 副執刀医 | 副執刀医 | 副執刀医 | ||
| 副執刀医 | ||||
| Doc編集 | Doc編集 | |||
| Unitテスト | Unitテスト | Unitテスト | ||
| ツール作成 | ツール作成 | |||
| 言語エキスパート | ||||
| 管理+秘書 | ||||
プログラミングシステムにはコンセプトの統一性が大事である
| アーキテクチャ | ねじを回して針を現在時刻にあわせる。針が文字盤を指したところが現在時刻 |
| インプリメンテーション | 振り子を使って針を進める・ゼンマイを使って針を進める・クォーツとステップモーターを使って針を進める・・・ |
| アーキテクチャ | ANSI FORTRAN IV |
| インプリメンテーション | PDP10用Fortranコンパイラ、System360用Fortranコンパイラ、Multics用Fortranコンパイラ、CP/M用Fortranコンパイラ・・・ |
アーキテクチャに機能を盛り込みすぎてしまった場合の対処法
「海へ持って行くクロノメーターは２個ではいけない。 １個だけにしておくか、さもなければ３個にしなければならない」
マニュアル修正のコスト < 誤った実装の修正のコストだから
誤った実装の修正コスト < マニュアル修正のコスト + 正しい実装の修正コスト * n
作業量の見積もりについて
(管理職の職位) (技術職の職位)
上級プログラマ 上級プログラマ
↑ ↑
主任プログラマ 主任プログラマ
↑ ↑
ﾌﾟﾛｼﾞｪｸﾄプログラマ ｽﾀｯﾌプログラマ
↑ ↑
準上級プログラマ管理職・技術職という区別を廃止した
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
ステップごとの洗練というプロセスは、予想外に混乱した詳細に直面した場合、
後戻りしたり、トップレベルを破棄し、全く最初からやり直すことをしない
という意味ではない。実際そういうことはしょっちゅう起こるものだ。
^^^^^^^^^
しかし、こうすれば、ひどいデザインを廃棄してやり直すべきタイミングと理由を
はるかに理解しやすい。多くの貧弱なシステムは、まずい基本デザインを化粧品で
塗り固めてすくい上げようとした結果の産物だ。トップダウンデザインでは、
こうした誘惑を少なくできる。提供バージョンは、提供バージョンの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
新機能 新機能 新機能 新機能 新機能新約聖書 使徒行伝15:10
ペテロ「私たちの先祖にも私たちにも背負いきれなかったような重荷を
なぜ今背負わせようとするのですか」第1章〜第15章の論点整理
[計画]−＋
↑ ↓
＋−[コーディング]−＋
↑ ↓
＋−[単体テスト]−＋
↑ ↓
＋−[結合テスト]−＋
↑ ↓
＋−[運用]
[計画]−＋
↓
[コーディング]−＋
↓
[単体テスト]−＋
↓
[結合テスト]−＋
↓
[運用]遅れているソフトウェアプロジェクトへの(単なる)要員追加は更に遅らせるだけだ
「われわれの作業にまつわる主要な問題は、本質的には技術的というより社会学 的な問題だ」 「マネージャの働きは、人々に作業をさせることではない。人々が作業できるよう にすることである」
manual.png
mills_plan.png
org.png
