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%”には、品質起因の手戻りが混ざりやすいです。対策として、テストは最後に集中させず、反復的に回すことが重要です。具体的には、回帰テストを自動化し、PR単位で動くようにする、重要機能はテスト観点をテンプレート化する、といった取り組みが効きます。

また、非機能（性能、可用性、セキュリティ）は「最後に一度確認」では不足しがちです。小さくても早めに負荷試験を当てる、権限モデルを先に固める、監査ログの要件を先に決める、といった前倒しが、終盤の伸びを抑えます。

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

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

90対90の法則が示すのは、終盤に作業が増えること自体よりも、終盤に増える作業を見積もりや計画に織り込めていないことの危険です。終盤に起きがちな作業（統合、例外系、性能、運用、セキュリティ）を最初から“作業として”扱うだけで、見積もりの精度は上がります。

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

開発は不確実性をゼロにできません。だからこそ、計画は一度作って終わりではなく、学習に応じて更新する必要があります。進捗の見え方が良いときほど、最後に向けて不確実性が残っていないかを点検し、危険信号（品質、統合、運用）が出たら早めに手当する姿勢が重要です。

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

終盤の伸びは、技術課題だけでなく「認識のズレ」でも起きます。受け入れ条件、責任分界、変更の扱い、リリース判断など、合意が必要な論点を早めに表に出し、決めるべきことを決める運用が、手戻りを減らします。

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

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

まとめ

90対90の法則は、ソフトウェア開発の終盤で作業が増え、完成までの時間が想定より伸びやすいことを皮肉った経験則です。終盤に増えるのは、統合、例外系、品質保証、性能、運用、セキュリティといった「見えにくいが不可欠な作業」です。対策としては、完成の定義（受け入れ条件）を明確にし、進捗を完成度で測り、リスクと品質を前倒しで扱うことが有効です。90対90の法則を正しく理解し、計画と運用に織り込むことが、結果的に効率と品質の両方を守る近道になります。