この本は、ワークフローを構築するための実際のガイドではなく、開発の古典的な伝承と呼ぶことができます。 これは、ブルックスがOS / 360オペレーティングシステムで作業を整理しているときに遭遇した問題と、それらを解決するための彼のアプローチを反映しています。 ブルックス自身が指摘するように、結果は理想とはほど遠いものでした。 彼の目標は、正しい方法を教えることではなく、解決する必要のある問題を提起することでした。 1960年代以降の開発の変化を理解することは興味深いです。
IBMアーカイブからの写真
本自体について話す前に、コンテキストを理解する必要があります。 OS / 360プロジェクトが実際に何であったか、どのような目的で、どのような条件で開発されたか。
システム/ 360開発の歴史
1960年代初頭、IBMはコンピューター市場の絶対的なリーダーでした。 そのシェアは75％でした。 しかし、見通しはますますバラ色になりつつありました。 まったくすべてのIBMシステムは互いに互換性がありませんでした。 シリーズ1401、1620、7070などは完全に分離されました。 1401から1620に切り替えたい場合は、新しいプロセッサだけでなく周辺機器も購入してください。 ソフトウェアも書き直す必要があります。
クライアントにとって高価な喜びであり、誰もがこれを決定するわけではありません。 そして、IBM自身にとっては、状況は悪く見えました。 時代遅れの機器の生産をサポートし、それを設定できる専門家のスタッフを維持し、時代遅れの技術でクライアント側のエンジニアを訓練しなければなりませんでした。 同時に、あるシステムから別のシステムへの移行には、完全な再トレーニングが必要でした。 状況は、システムの多くが高度に専門化されているという事実、たとえばディスパッチシステムによって悪化しました。
そして、1961年1月、29歳のブルックスは次の8000シリーズのプロジェクトを発表しました。もちろん、新しいシステムは以前のものよりも優れていますが、1つでは同じです。 これは完全にユニークな別の複合施設であり、IBMへのサポートだけでなく、顧客への移行には数百万の費用がかかります。 明らかに、これは行き止まりです。 プロジェクトは終了し、Brooksはチームを率いて完全に新しいシステムを開発するよう招待されました。 しかし、誰も知らなかった。 一つのことは明らかでした-新しいシステムは、将来、ハードウェアとソフトウェアの両方のレベルで後方互換性を提供し、銀行、軍隊、科学者に適した汎用システムであるべきです。
Brooksが率いる25人のグループが形成され、Brooksは新しいシステムの計画を策定し始めました。 プロセスはゆっくりと進んでおり、それをスピードアップするために、経営陣はワーキンググループをニューヨーク郊外のホテルに移転することを決定しました。 そして彼らは来ました。 そして、この決定は青信号を与えられました。
ハードウェアとソフトウェアの複合体全体はシステム/ 360、オペレーティングシステムはOS / 360と呼ばれていました。 皮肉なことに、下位互換性の問題は、以前のシステムとの互換性を拒否することで解決されることになりました。
システムの開発は計画よりも大幅に長くかかり、その費用は6億2,500万ドルではなく、525億ドルでした。これは、1965年にロケット、宇宙飛行士、月面着陸を行うAppolloプログラムよりも少額です。 IBMの破産のリスクは非常に現実的でしたが、何も起こりませんでした。 システムの発表は1964年4月7日に行われ、最初の製品は1965年半ばにリリースされました 。 成功は途方もないものでした。 このシステムの枠組みで定められたコンポーネントの互換性の原則は、今日も守られています。 ちなみに、8ビットが標準バイトサイズになったのはSystem / 360の後でした。
ブルックスの主要声明
序文から第2版まで：「この本は、プログラムの開発の難しさに関する質問に対する遅ればせながらの回答です（1975年の「遅らせられた」！-著者のメモ）。 次の10年間、プログラミング方法はなくなり、その使用により開発の生産性が1桁向上します。他のすべての条件は同じです。
当たり前になったブルックスの主な声明の中で、次のことに注意することができます。
- ソフトウェア製品は、完成前であっても陳腐化に直面しています。
- 設計されているすべてのシステムの中で、2番目に危険なのは。 通常は、 再設計する必要があります。
- 最初のバージョンは破棄することを計画してください。ユーザーの期待を満たせないため、まだ実行する必要があります。
- ソフトウェアプロジェクトを工数で評価することはできません。 人月は誤った危険なエラーです。これは、月と人数を交換できると想定しているためです。
- 最高のプロのプログラマーは、弱者よりも10倍生産的です。
- ブルックスの法律：プロジェクトが期限に間に合わない場合、労働力を追加するとさらに遅れます。
これらは、本で引用されているすべての考えではありませんが、最も重要なようです。 214個すべてのステートメントを分析することは不適切です。特に、それらのステートメントの多くは非常に明白であるためです。 たとえば、少人数のアクティブなチームを用意するのが最善であるという事実については、議論することはできません。
ただし、これらのステートメントの関連性の変化は、ソフトウェア開発業界の変化を反映しています。
50年後の最初と2番目のシステム
ソフトウェア製品は完成する前に陳腐化し、2番目のシステムのアーキテクチャは悪くなり、ユーザーのニーズを満たさないため、最初のシステムは廃棄する必要があります。 賢明な何かが3度目にしか出ないことがわかったのですか？ いや ある意味では、ブルックスは正しいですが、私たちはそれをどのように扱うかを学びました。
ソフトウェア製品は 、5年間開発した場合、その完成前に必然的に陳腐化します。 これはまさにSystem / 360で起こったことです。 最新の開発アプローチはすべて、最小限ではあるが実用的に有用な一連の機能を備えていますが、最初のバージョンのクイックリリースを意味します。 ユーザーストーリーの同じ概念は、主に 、顧客のニーズのセット全体から、実装のための小さいながらも不可欠な部分を選択することを目的としています。 その後、製品を迅速にリリースしてフィードバックを得ることができます。
盲目的に行われた場合、 最初のバージョンは破棄する必要があります。 しかし、最初のバージョンが肥大化しすぎず、その開発の過程で実際のユーザーの希望が考慮される場合、すべてが非常にうまくいく可能性があります。 使用を開始すると、必然的に多くのコメントが表示されますが、最初のリリースの前にフィードバックを聞くと、完全に失敗する可能性が大幅に減少します。 製品を使用している限り、コメントの修正は問題ではありません。
2つ目のシステムのアーキテクチャは悪くなるでしょう 。 Brooksは、System / 360プロジェクトを2番目のシステムと見なしています。 IBMが以前に開発した専門プロジェクトは非常に優れていることが判明しましたが、360を使用してすべてを正しく行うことにしました。
建築上の決定はゼロから行われるのではなく、問題に対する答えです。 システムが進化的に発展する場合、これらの問題は現実的であり、非常に具体的です。 それらを分解して理解し、解決策を見つけることができます。 ゼロから始めて、ユーザーにとって本当に重要なものを見逃すのは非常に簡単です-誰もがすべてを予測することはできません。 ただし、建築家/アナリストの頭の中だけに存在し、現実とは関係のない架空の問題を解決するというtrapに陥ることは、同様に危険です。
2番目のシステム全体の問題は存在しますが、2番目のシステムを作成せずに回避することを学びました。 代わりに、リリースされた最初の製品は進化的かつ反復的に進化しています。 リファクタリング、移行、および下位互換性のサポートに費用がかかる場合がありますが、現実と連絡を取り合うことはたいしたことではありません。
最終的に、開発は技術開発によって加速されたのではなく、開発サイクルを短縮し、迅速なフィードバックを得たためです。
神話上の実月
ソフトウェアプロジェクトを開発するとき、人月で見積もりを操作することができないという事実に関して、ブルックスは少し不誠実です。 実際、 これはどのプロジェクトでも実行できません 。
プロジェクトのタイミングとリソースを計画するのは簡単です。 すべてのタスク、タスク間の依存関係、期限の見積もり、必要なリソースがわかっていれば、すべてが非常に簡単です。 怠laな人だけがそのような状況で計画の作成に対処することはできません。 しかし、この場合でも、プロジェクトをスピードアップするために人を延々と追加することはできません。 リソースの量に関係なく、最短時間を決定するクリティカルパスが常に存在します。 詳細については、 「ソ連のプロジェクト管理（1976）」および「クリティカルチェーン 」を参照してください。
残念ながら、計画に必要な条件が常に満たされるとは限りません。 この場合、正しい計画を立てることは不可能です。 個々のタスクのタイミングの見積もりでさえ、常に実際の経験から得られます。 しかし、そのような経験がない場合はどうでしょうか？ 靴ひもを結ぶ-ほんの数分、むしろ5〜7秒。 毎日靴ひもを結ぶことにより、私たちの経験から、明日同じ仕事をするのに必要な時間を正確に見積もることができます。 しかし、 片手で靴ひもを結ぶのにどれくらいかかるかを予測してみてください。 あなたの評価は実際の経験と一致していますか？ 奇妙な実験。 続きを読む-ロバートC.マーティン、 「効果的な推定（または：嘘をつかないように）」
私たちは、ソフトウェア開発だけでなく、今までやったことのない新しいイニシアチブを計画するのが非常に苦手です。 このような状況で、ブルックスはプロジェクト計画の作成と、System / 360の開発のタイミングとコストの見積もりを依頼されたときに気づきました。
ホテルのすべての主要な専門家をロックしても、大規模なソフトウェアプロジェクトの正確な計画を立てることはできません。 残念ながら、IBMの幹部はBrooksを絶望的な状況に追い込み、おそらく彼は後で本を書くように促しました。
ただし、短期計画は現実的です。 2〜4週間の反復を計画する場合、これはかなり正確に行うことができます。 時間の経過とともに、大きなタスクを小さなタスクに分解するスキルが開発され、小さなタスクの評価が容易になります。 さらに、常に一方向に作業することで、人は専門知識を蓄積します。 3か月前に完全に新しく見えたタスクは、空の指でしか評価できなかったため、最近のタスクと非常によく似ています。 したがって、それらの用語の推定値は類似しています。
もちろん、ソフトウェアプロジェクトを人月で評価することは不可能ですが、翌月の作業を計画することはかなり可能です。 そして、来月のこの計画は神話的ではなく、かなり正当化された、 事実に基づいたものになるでしょう。
小川が逃したもの
-ブルックス氏、あなたはプロジェクトに2年と6億2,500万ドルが必要だと言いました。2年半はすでに過ぎており、予算は2倍になりましたが、結果はありません。 ブルックス氏、会社全体の成功はプロジェクトの迅速な完了にかかっていることを理解していますか？ さらに20億ドルを提供し、さらに500人を雇用します。
「ブルックスさん、あなたの仕事は来年内に必要なすべての仕事を完了することです。」
もちろん、これが実際にブルックスに言われたかどうかはわかりませんが、これは非常によく起こった可能性があります。
ブルックスは、 経営陣のイニシアチブでリソースを追加しても長引くプロジェクトを加速できない理由を詳細に、そして詳細に説明します。 すべての作業を再計画し、新しい専門家を最新の状態にするために時間を費やし、開発ルールを浸透させる必要があります。 ブルックスは確かにこのすべてにおいて正しいですが、それはポイントではありません。
ブルックスの本当の問題は、彼のプロジェクトを完了するのに4年かかったということではなく、予算が50億ドルだっただけでなく、彼が正確にまたは時間内に前もって計画できなかったことです。 実際、彼は10回間違えました。 もちろん、ブルックスは開発を同じ10倍高速化する方法を探していますが、これは解決策ではありません。
ブルックスのサイトの誰も、プロジェクトのより正確で合理的な見積もりを出すことができませんでした。 もちろん、他の誰かが3年と20億ドルを言うことができます。その場合、エラーは少なくなります。 しかし、そのような「より正確な推定値」は、合理的な予測ではなく、成功した推測の結果です。
この本の主な矛盾は、ビジネスの観点から、プロジェクトにかかる時間とプロジェクトにかかるリソースを正確に知る必要があり、ブルックスはこれらの質問に答えることを余儀なくされたことです。 実際には、すべてが計画どおりに機能しなかったため、ブルックスは個人的な責任を感じています。 彼は約束しました、できる限りのことをしましたが、成功しませんでした。 しかし、あなたは認めなければならない、それは人が彼がおそらく満たすことができないだろうという約束をすることを要求することは完全に公平ではない。
プロジェクトの開始時に、プロジェクトの予算を10億ドルから60億ドル、期間を3年から7年とすることをブルックスが主張した場合、すべてが違った結果になり、より正確な見積もりを出すことは不可能です。 そして、IBMのリーダーシップは、これらの推定値を認識しました。
おそらく、プロジェクトを遅らせて予算を増やすことで起こりうるリスクを知って、会社の予算をより適切に計画することが可能でしょう。 これは、お金がすでになくなっているときに問題に遭遇するよりも優れています。 おそらく、プロジェクトの規模をできる限り縮小し、不確実性を減らし、リスクを軽減するような方法で、プロモーションと販売へのアプローチを変更する方法があるでしょう。 おそらく、エンジニアリング部門の能力を超えた何か他のことができれば、プロジェクトの成功に役立ちます。 しかし、当時、仕事へのアプローチにおけるこのような急進的な変化は、許容範囲を超えていました。 1960年代というまったく異なる時代がありました。