90対90の法則とは？ 10分でわかりやすく解説

ソフトウェア開発では、「実装がほぼ終わったはずなのに、なぜか終盤が一番長い」という現象がよく起きます。90対90の法則は、その“終盤の伸び”を皮肉った経験則です。この記事では、この法則が起きる理由を具体的に分解し、見積もりや進捗管理でどう織り込むべきか（＝何を判断できるようになるか）を整理します。

90対90の法則とは

90対90の法則の定義

90対90の法則（Ninety–ninety rule）とは、ソフトウェア開発の現場で語られる経験則の一つで、最初の90%の機能を実装するのに全体期間の90%を要し、残り10%の完成にさらに全体期間の90%がかかると表現されることが多いものです。合計が180%になるという表現自体が、「終盤の予想が外れてスケジュールが膨らみやすい」という状況を、比喩的に表しています。

ここで言う「90%」「10%」は厳密な計測値ではありません。“見た目の進捗”と“実際の完成度”が終盤で乖離しやすいことを強調するための比喩です。仕様書や画面上では完成に見えても、リリース可能な品質に仕上げる段階で、想定外の作業が増えやすいという警句として理解すると、実務に結びつけやすくなります。

90対90の法則が生まれた背景

開発の序盤は、機能の骨格を作るフェーズが中心になりやすく、進捗が分かりやすい傾向があります。一方、終盤では、テスト、バグ修正、性能調整、運用設計、セキュリティ確認、ドキュメント整備など、「動いているように見える状態」から「壊れにくく、戻せて、説明できる状態」へ仕上げる作業が増えていきます。これらは成果物が見えにくい割に、手戻りが発生しやすい点が特徴です。

さらに、複数の機能が結合した段階で初めて露見する不具合も増えます。連携の境界、例外系、同時実行、権限といった問題により、単体では動いていた機能が、統合環境では破綻することも珍しくありません。その結果、「残り10%」に見えていた部分へ、想定外の調整や修正が集中しやすくなります。

90対90の法則が示唆する難しさ

90対90の法則は、「ソフトウェア開発は作った瞬間に終わるのではなく、使える状態に仕上げて初めて完成する」という点を突いています。たとえば、次のような“最後の10%”が積み重なりやすくなります。

• 例外系の埋め：入力の揺れ、欠損、想定外の順序、タイムアウト、再送など
• 統合時の不整合：APIの前提違い、データ形式・桁・文字コード、リトライ設計
• 非機能要件：性能（ピーク時）、可用性（フェイルオーバー）、保守性（運用手順）
• セキュリティ：権限分離、監査ログ、秘密情報の扱い、脆弱性対応
• 品質の担保：回帰テスト、環境差異、リリース手順、ロールバック

この法則は、終盤の遅れを「努力不足」と単純に片づけないための視点でもあります。遅れの原因が複雑性や不確実性、品質要求にある場合、対策もそれらに直接向き合う形で設計する必要があります。

90対90の法則が目立ちやすい状況

90対90の法則は、あらゆる開発で必ず起きるものではありません。条件が重なった場合に、特に顕著になります。自分のプロジェクトがどれに当てはまるかを把握することが、対策の出発点になります。

大規模で複雑なシステム開発

規模が大きくなるほど、モジュール間の依存関係や状態遷移が増え、統合の組み合わせが爆発的に増えます。特に、複数チーム・複数ベンダー・複数環境が関わる場合、責任分界や前提条件のズレが終盤に表面化しやすくなります。統合テストで初めて見える不具合が増え、調整が連鎖的に発生するのが典型例です。

要件が曖昧なまま進むプロジェクト

要件が曖昧でも、序盤は「とりあえず動くもの」を作れます。しかし終盤になると、誰が何をもってOKとするのか、つまり受け入れ条件が固まっていないことが明らかになります。その結果、仕様変更という形で“完成の定義”が動き、完成に近づくほど手戻りが増える状態になりやすくなります。

新技術・未経験領域を含むプロジェクト

新しい基盤や未知の性能要件、外部仕様が不安定なサービス連携などは、序盤には見えないリスクを抱えがちです。PoCでは動いても、本番の負荷や権限、監査、運用を前提にすると成立しないことがあります。終盤で再設計や迂回策が必要になり、90対90の“後半90%”が現れやすいパターンです。

進捗の見せ方が「作業量」中心のプロジェクト

実装タスクの完了数といった作業量だけで進捗を測ると、「統合」「品質」「運用」といった要素が後回しになりがちです。その結果、終盤に“実装以外の作業”が雪だるま式に増えていきます。進捗は、作業量ではなく、受け入れ可能な状態にどれだけ近づいているかで測る必要があります。

90対90の法則への対策

要件定義の明確化とスコープ管理

まず重要なのは、「完成」の定義を早い段階で固めることです。機能要件だけでなく、受け入れ条件まで具体化すると、終盤での論点が減ります。

また、変更はゼロにできません。だからこそ、変更を歓迎するか抑えるかではなく、変更の扱い方を決めます。変更要求をバックログ化し、優先度や影響範囲、期限への影響を見える形で共有したうえで、合意して進める運用が現実的です。

進捗を「完成度」で測る運用に切り替える

90対90の罠は、「できたつもり」の積み重ねで起きます。対策として、各機能について次のような完了条件を明示すると、終盤への偏りを抑えられます。

• 単体テスト・結合テストが通っている
• 例外系（入力不正、タイムアウト、リトライ）が定義されている
• 監査ログ・運用ログが出力される
• 運用手順（設定変更、復旧、ロールバック）が記載されている

「実装完了」ではなく「受け入れ可能」を完了とすることで、後半に残りがちな“見えない作業”を前倒しできます。

リスク管理とコンティンジェンシープラン

終盤に伸びる原因の多くは、未知のリスクが最後にまとめて表面化することです。開始時に起こり得ることを洗い出し、影響と確率を整理したうえで、起きた場合の手当（代替案、段階リリース、機能フラグ）を準備します。

リスクを「技術」「運用」「外部依存」に分け、責任者と観測指標を決めておくことで、終盤のトラブルを突然の出来事にしにくくなります。

品質管理とテスト工程の強化

90対90の“後半90%”には、品質起因の手戻りが混ざりやすくなります。そのため、テストは最後に集中させず、反復的に回すことが重要です。回帰テストの自動化や、重要機能のテスト観点をテンプレート化するといった取り組みが効果を発揮します。

また、性能や可用性、セキュリティといった非機能要件は、「最後に一度確認する」だけでは不十分です。早い段階で小さく検証を重ねることで、終盤の伸びを抑えられます。

90対90の法則から学ぶ教訓

ソフトウェア開発は「最後に難しくなる」前提で設計する

90対90の法則が示しているのは、終盤に作業が増えること自体よりも、その作業を見積もりや計画に織り込めていない点の危うさです。終盤に起きがちな作業を最初から作業として扱うことで、見積もりの精度は高まります。

プロジェクト管理は「計画」よりも「更新」が重要

開発の不確実性は避けられません。計画は一度立てて終わりではなく、学習に応じて更新するものです。進捗が良く見えるときほど、不確実性が残っていないかを点検し、危険信号があれば早めに手当する姿勢が求められます。

コミュニケーションと合意形成が“最後の10%”を左右する

終盤の伸びは、技術課題だけでなく認識のズレからも生じます。受け入れ条件や責任分界、変更の扱い、リリース判断といった論点を早めに表に出し、合意しておくことが、手戻りを減らします。

継続的な改善と学習で“法則”を弱められる

90対90の法則は、避けられない宿命ではありません。見積もりの前提と実績を振り返り、次のプロジェクトに反映することで、終盤の伸びは抑えられます。重要なのは、この法則を言い訳ではなく、改善のための観測と学習の題材として扱うことです。

まとめ

90対90の法則は、ソフトウェア開発の終盤で作業が増え、完成までの時間が想定より伸びやすいことを皮肉った経験則です。終盤に増えるのは、統合、例外系、品質保証、性能、運用、セキュリティといった見えにくいが不可欠な作業です。完成の定義を明確にし、進捗を完成度で測り、リスクと品質を前倒しで扱うことが、結果として効率と品質の両立につながります。