実際には99ルール
コードの最初の90％は、開発時間の最初の90％を占めています。コードの残りの10％は、開発時間の残りの90％を占めています。
— Tom Cargill、Bell Labs
それは実際にはどういう意味ですか？そのプログラマーはかなりの量の仕事をしていて、彼らは自分たちから180％を提供しているのか、それとも？
次のように想像してみてください。ソフトウェアの開発を始めると、比較的短時間で大量のコードを書くことができます。この新しいコードは、膨大な量の新しい機能を追加できます。問題は、多くの場合、その機能が「完了」とはほど遠いこと、バグ、小さな変更（小さなビジネスの場合）などがある可能性があることです。したがって、ソフトウェアはほとんどのユースケースをサポートしているため、ほぼ完了した（90％が完了した）ように感じるかもしれません。しかし、ソフトウェアにはまだ作業が必要です。このルールの要点は、ソフトウェアがほぼ完了したように感じられるにもかかわらず、そのソフトウェアを適切に動作する状態にするための作業量は、「ほぼ完了した」状態に達するのと同じくらい大きいということです。これは、バグの修正に時間がかかることは多いものの、多くのコードが生成されないためです。
問題は、ほとんどの開発者がソフトウェアを「ほぼ完了」状態にすることを見積もっていることです。これは、ソフトウェアが費やす総作業量を実際に見積もるのに比べて比較的単純だからです。
これは、悲しいことに今日でも起こっている一般的なシナリオへの参照です。
- チームは、すべてのコードを記述するために必要な作業量を見積もる（つまり推測する）ように求められます。
- プロジェクトは、「時間と予算を守る」という内部および外部からの多くの圧力を受けて進行します。
- したがって、プロジェクトのかなりの割合で、「目標どおり」が報告されます。多くの場合、これは、簡単なタスクを最初に選択して、適切な進捗状況を確認することでさらに悪化します。
- その後、ある段階で、現実を受け入れなければならない重要なポイントに到達します。プロジェクトは予定どおりに完了せず、リリース日が（多くの場合）押し戻されます。
「90％」は任意の数字ですが、ポイントはよくわかります。推定は推測であり、おそらく間違っている（多くの場合、非常に間違っている）ため、人間の性質により、ほぼ常に推定が不足しているため、問題が発生します。
次のような別のバージョン（「90-90ルール」とも呼ばれます）を聞いたことがあります。
機能の90％を実装した後も、他の90％を実装する必要があります。
どちらのバージョンも、ソフトウェア製品を開発するための労力を正しく見積もることの難しさと、人々が陥りがちな一般的な落とし穴を示しています。
- 見積もりが必要で本質的に推測しているときに統計をそこに捨てる（「私は80％完了している」）
- 作業量を犠牲にして、作成するコードのアルゴリズムの複雑さに焦点を合わせる（一般的なタスクに必要な労力を過小評価する）
- 足りないステップ（「見えないところ、気になっていない」）
- 既存のコードを維持および変更するための労力を過小評価している
- ボイラープレート/「接着剤」コードに必要な労力を過小評価
このルールは、80-20ルールを補足します。現在、80-20ルールにはさまざまな解釈がありますが、私が最も気に入っている2つは次のとおりです。
- 最初の80％の製品開発は、20％の労力を費やします。
- エラーの80％はコードの20％にあります。
実際には、これは次のことを意味します。開発は開始され、最初の遅延に気付く特定のポイントまで進みます。遅延にはさまざまな性質があります。
- 品質管理が不十分で、バグが発生する
- 顧客が途中で考え出した追加の要件（およびこの理由は複数の場合もあります）
- 最初から要件が不明確で、以前の開発の一部が削除されます（これは、回帰バグにもつながる可能性があります）
- 不明確な範囲、人為的ミス、または予期しない状況による初期の過小評価。これらの予期しない状況は、病気の葉、辞任、ハードウェア障害、または極端な場合には火山の噴火（アイスランドでの火山噴火のために現場で飛行することができなかったためにプロジェクトを遅らせる必要があったため）です。
結論として、実際に到達するよりも目標に近づく方がはるかに簡単です。
私は Wikipedia の説明を非常に啓発的に見つけます：
これは、ソフトウェア開発プロジェクトの悪名がそのスケジュールを大幅に超過していることへの苦痛な言及の合計で最大180％になります（ソフトウェア開発作業の見積もりを参照）。プログラミングプロジェクトの簡単な部分と困難な部分への時間の大まかな割り当てと、多くのプロジェクトの遅延の原因の両方を、難しい部分を予測できないこととして表します。つまり、プロジェクトを機能させるには、予想以上に多くの時間とコーディングが必要です。
それは実際にはどういう意味ですか？そのプログラマーはかなりの量の仕事をしていて、彼らは自分たちから180％を提供しているのか、それとも？
いいえ、プログラマーは常に単位時間あたり同じ量の作業を行います。見積もりは過小評価のコストとオーバーランに関するものです。 180％は、プロジェクトが最終的に費用となる時間と金額です。
おおまかに言って、「あなたが考えるのに2倍の時間がかかるだろう」と「もう手遅れになる（締め切りが迫っている）までは、うまくやっていると思うだろう」という意味です。
これが実際に意味することは、人々は自分自身に嘘をつくということです。
プログラマーが「90％完了している」と言った場合、それは機能を構築するための努力の90％が費やされたことを意味します。
プロジェクトマネージャーが「私たちは90％完了しているので、誰かに完了してもらうだけです」と言った場合、予算の90％が完了していることを意味します（おそらく50％完了しています）。これは、お金がなく、期待が高く、態度が悪いクライアントです。
違いは、プロジェクトを完了するためにコーディング機能よりも多くの労力が必要なことです：qa、バグ修正、コピー編集、デプロイメント。
これらはプロジェクトで管理する必要があり、プロジェクトマネージャーの責任です。これは、多くの場合、「プロジェクトの完了」の半分に過ぎないことを理解するためだけに「90％の機能が完了」するように惰性で動く新しいPMを驚かせます。