「なぜ最初から品質工程の工数を積んでおかなかったのか」――リリース後の障害対応に追われ、当初見積の2〜3倍に膨らんだ保守費用を目の当たりにした経営層から、こう問われた情シス担当・PMは少なくないはずです。次回プロジェクトでは要件定義や設計レビューに工数を寄せたい。しかし社内提案では「品質工程はKPIが見えない」「早く出したい」との反対に遭い、なかなか合意が取れないのが実情ではないでしょうか。
こうした場面で引用される代表的な経験則が「1:10:100の法則」です。上流工程で1のコストで防げた欠陥が、下流に進むほど10倍・100倍と修正コストが膨らむ、というシンプルなメッセージは、経営層に「予防投資は割に合う」と伝える最短の言い回しになります。一方で、この法則は「本当に100倍なのか？」と反論を受けやすい題材でもあります。出典・数値根拠・限界を押さえていないまま提案に使うと、逆に説得力を失うリスクがあるのも事実です。
そこで本記事では、1:10:100の法則を「経営層への提案でそのまま引用できる形」に落とし込むことを目標に、次の4点を整理して解説します。第一に、法則のふたつの起源（データ品質分野とソフトウェア開発分野）と定義。第二に、品質コスト（COQ）のPAFモデルによる3層構造での位置づけ。第三に、IPAやSPI Japanなど国内の実測データを含めたフェーズ別コスト倍率。第四に、「本当に100倍か？」の反論への備えと、予防コストへ投資する意思決定の組み立て方です。
読み終えたときに、1:10:100を鵜呑みにするのでも切り捨てるのでもなく、「自社のプロジェクト規模と開発手法に合わせて、妥当な倍率で試算し、経営会議で使える論拠に組み替えられる」状態を目指します。
システム開発の費用を正しく理解するガイドブック――相場・見積チェックリスト・予算策定テンプレート付き
この資料でわかること
発注検討者がシステム開発の費用体系を正しく理解し、「この見積は適正か」「どのくらい予算を確保すれば良いか」を自分で判断できるようになること。
こんな方におすすめです
- システム開発の発注を初めて担当する方
- 複数社の見積もりを比較・評価したい方
- IT投資の社内稟議を通す根拠を固めたい方
入力いただいたメールアドレスにPDFをお送りします。
データの1:10:100の法則とは
1:10:100の法則は、「品質問題を防ぐコストを1とすると、発見・修正するコストは10、放置して失敗した際のコストは100になる」という経験則です。品質分野のふたつの潮流――データ品質管理とソフトウェア開発――で、それぞれ独立に近い形で提唱・引用されてきました。
1:10:100の法則の基本定義（予防1／発見10／失敗100）
もっとも簡潔な形は次の3層構造です。
- 予防コスト（1）: 品質問題が発生しないよう、設計・レビュー・教育・標準化などに投じるコスト
- 発見・修正コスト（10）: 発生した品質問題を、開発途中で発見して修正するコスト
- 失敗コスト（100）: 品質問題を放置したまま本番稼働し、顧客影響・信用失墜・再作業に至ったときのコスト
数値そのものは業界・規模・プロジェクト特性によって変動する経験則ですが、「後工程になるほどコストがべき乗的に跳ね上がる」という傾向を象徴的に示す点で、社内提案・意思決定の場で長く参照されてきました。
データ品質側の起源（Labovitz & Chang、TDQM）
1:10:100の法則を「予防1／修正10／放置100」という現在の形で明示的に提唱したのは、Boston University の George Labovitz と Yu Sang Chang とされています。1992年ごろの Total Data Quality Management（TDQM）研究の文脈で示され、以降データ品質管理（Data Quality Management）分野の標準的なフレームとして定着しました（Matillion "The 1:10:100 rule of data quality"、Andrew Jones "The 1:10:100 rule of data quality"）。
データ品質側の原意は、以下のような具体イメージです。
- 入力時点でエラーを防ぐ仕組み（バリデーション、マスタ整備、入力者教育）に $1 を投じる
- 誤ったデータをクレンジング・突合・修正で発見・訂正するには $10 かかる
- 誤ったデータを気づかないまま業務判断・請求・在庫・意思決定に使ってしまうと、後戻り・信用毀損・機会損失で $100 のコストが発生する
システム開発の文脈でも、要件定義の1文の解釈違い、テーブル設計のカラム型の齟齬など、「データを扱う仕組みの品質」が下流に伝播する構造は共通しています。
ソフトウェア開発側の類似則（Boehm 1976／McConnell）
一方、ソフトウェア開発分野では、Barry Boehm による初期の実測研究が、事実上の「1:10:100の法則」の起源と扱われています。Boehm は1970年代にTRWおよびIBMのウォーターフォール型プロジェクトを対象に、欠陥検出のタイミングと修正コストの関係を分析し、後工程での修正ほどコストがべき乗的に増えることを実証しました（TechWell "What Does It Really Cost to Fix a Software Defect?"）。
代表的な結果として、Boehm は大規模プロジェクトにおいて、要件定義（仕様策定）段階と比較して、保守段階での欠陥修正コストが約100倍に達するとしました。中小規模プロジェクト（1万行未満）ではその倍率は緩和され、約20倍という値が示されています。1981年の著書『Software Engineering Economics』でも同様の主張が展開され、以降ソフトウェア工学の分野で広く引用されるようになりました。
Steve McConnell も"An Ounce of Prevention"の中で、Boehm の実測データを踏襲する形で「上流で1時間かけて欠陥を防ぐ投資は、下流での多倍数のコスト削減に相当する」と論じており、これらの主張が総合されて「ソフトウェア開発版の1:10:100」として日本の実務にも紹介されてきました。
つまり、1:10:100の法則を厳密に扱う場合、データ品質側（Labovitz & Chang, 1992）とソフトウェア開発側（Boehm, 1976）は独立した起源を持つ経験則です。しかし両者は「上流で防ぐ方が圧倒的に安い」という結論において一致しており、システム開発の現場では実務上ひとつの経験則として扱われています。
品質コスト（COQ）の3層構造で読み解く
1:10:100を単発の数字として覚えても、経営層への説明では「なぜその数字なのか」を問われた瞬間に説明が詰まります。ここで有効なのが、品質分野で長く使われてきた品質コスト（Cost of Quality, COQ）の枠組み、とくにPAFモデル（Prevention-Appraisal-Failure）です（株式会社保全ラボ「品質コストのＰＡＦ法」、JMAC「品質コスト（cost of quality）」）。
PAFモデルは、品質にかかる費用を次の3種類に分類します。
- Prevention（予防コスト）: 不良を「発生させない」ための費用
- Appraisal（評価コスト）: 不良を「発見する」ための費用
- Failure（失敗コスト）: 不良が「発生してしまった」ときの費用（内部失敗・外部失敗）
1:10:100は、この3層のコスト構造を、システム開発の各フェーズに沿って象徴的に示したものと解釈できます。以下、それぞれを整理します。なお、品質管理の全体像（PDCAサイクル、SQuaREなど品質特性モデル、品質保証プロセス）についてはシステム開発における品質管理で解説していますので、COQと合わせて社内提案の背景資料として参照してください。
予防コスト（レビュー・教育・標準化）
予防コストは、そもそも欠陥が入り込まないための投資です。システム開発では次のような項目が該当します。
- 要件定義レビュー、設計レビュー、アーキテクチャレビュー
- コーディング規約・レビュー基準の整備
- 静的解析ツール・CI 環境の構築と維持
- チームメンバーへの技術教育、業務ドメイン知識のインプット
- 仕様書・設計書のフォーマット標準化、テンプレート整備
予防コストは「工数として見えやすい」一方で、防いだ欠陥は見えないため、経営層からは効果が理解されにくいのが典型的な悩みです。1:10:100の枠組みは、この「見えない予防効果」を「見えない失敗コストの回避」として翻訳する道具になります。
評価コスト（テスト・監査）
評価コストは、欠陥が入り込んだ場合にそれを検出するための投資です。
- 単体テスト、結合テスト、システムテスト、受入テスト
- テストコード・自動テスト・回帰テストの整備
- コードレビュー（欠陥検出目的のもの）
- 監査・品質メトリクスの測定
社内で「品質工程」と呼ばれるものは、多くの場合この評価コスト（≒テスト工数）を指しています。しかし、テストで見つけられる欠陥は限定的で、要件定義レベルの認識齟齬などは、下流のテストではそもそも検出できません。ここが「テストを増やせば品質は上がる」という誤解の分かれ目になります。
失敗コスト（内部失敗・外部失敗）
失敗コストは、欠陥がすでに発生してしまったときのコストです。次の2種類に分けられます。
- 内部失敗コスト: 開発中・テスト中に発見された欠陥の修正コスト（回帰テスト・データ移行・再ビルドなど）
- 外部失敗コスト: 本番リリース後に顕在化した欠陥のコスト（緊急対応・障害対応・顧客補償・信用失墜）
1:10:100 の「100」に該当するのは、この外部失敗コストの領域です。金額に見えるものだけでなく、営業への負担、経営判断のリスク、離職・士気低下といった「見えないコスト」までを含んで理解する必要があります。
PAFモデルの含意はシンプルです。予防コストと評価コストへの投資を厚くすれば、失敗コスト（とくに外部失敗コスト）が大幅に減り、総品質コストは下がる――これが総品質コスト最小化の考え方です。1:10:100の法則は、この関係を「予防1／評価10／失敗100」という覚えやすい倍率に落とし込んだものと理解すると、社内提案での位置づけがブレなくなります。
システム開発のフェーズ別・修正コスト倍率の実測データ
「経験則」だけでは経営層への説得材料としては弱いため、実測データで倍率を補強しておくと、稟議書の説得力が段違いに上がります。ここでは、国内・海外の代表的な実測値を並置します。
フェーズごとのコスト倍率テーブル
代表的な国内実測データをフェーズ別に整理すると、次のようになります。基本設計を1とした場合のバグ修正コスト倍率を、IPA（情報処理推進機構）のコストモデルおよびSPI Japan での発表事例から抽出しました。
フェーズ | 基本設計を1とした修正コスト倍率 |
|---|---|
基本設計 | 1 |
詳細設計 | 5 |
単体テスト | 10 |
結合テスト | 15 |
総合テスト | 20 |
稼働後（リリース後） | 200 |
つまり、要件定義や基本設計の段階で1人日で気づける欠陥を、リリース後まで持ち越すと約200人日相当のコストがかかる、という試算が実測ベースで示されています。「1:10:100」よりもさらに大きな倍率であることに注意が必要です。
IPA コストモデルによる国内実測値
上記の倍率は、IPA が公開した『先進的な設計・検証技術の適用事例報告書 2015年度版』に収録された「コストモデル」を使った品質・生産性向上事例（HS情報システムズ）から抽出したものです（IPA 先進的な設計・検証技術の適用事例報告書 2015年度版、SQiPソフトウェア品質ライブラリ「『コストモデル』を使った品質・生産性向上の取り組み」）。
このコストモデルの重要な特徴は、以下の2点です。
- 国内の実プロジェクトから抽出した実測値であり、日本の受託開発現場の実情に近い
- フェーズを細かく刻んで（基本設計/詳細設計/単体/結合/総合/稼働後）倍率を提示しており、7フェーズ相当の解像度がある
海外のBoehm実測値と比較したときに、「日本のプロジェクトでは倍率が違うのでは？」という反論に対して、この国内実測値を並べておくことで反論を無力化できます。
Boehm 1976 / 1988 論文の海外実測値
海外の代表的な実測値としては、前述の Boehm 1976 論文および1981年『Software Engineering Economics』における研究があります。TRW・IBM の大規模ウォーターフォール型プロジェクトを対象にした分析で、要件定義段階で発見・修正すれば1のコストで済む欠陥が、保守段階では約100倍に膨らむとされました。
一方、Boehm 自身が指摘しているように、プロジェクト規模により倍率は変動します。1万行未満の小規模プロジェクトでは、保守段階での修正コスト倍率は約20倍にとどまるという結果も報告されており、「1:10:100は絶対値ではなく、プロジェクト規模・特性に応じたスケーリングが必要な経験則」であるという理解が重要です（TechWell "What Does It Really Cost to Fix a Software Defect?"）。
国内実測（基本設計1 → 稼働後200）と海外実測（仕様1 → 保守100）を並置すると、フェーズ設定の違いはあるものの、いずれも「後工程で見つかると2桁のコスト増になる」という結論に収れんしています。この点を経営層への提案では、両方引用すると反論余地が大きく減ります。
なぜ後工程ほど修正コストが跳ね上がるのか
数字を提示しても「そもそもなぜそこまで上がるのか」を説明できないと、経営会議で追加質問に耐えられません。ここでは、修正コストが後工程ほど跳ね上がる4つのメカニズムを整理します。
上流の欠陥が下流に波及する
要件定義の段階での認識齟齬や仕様漏れは、その後の基本設計・詳細設計・実装・テストのすべてに影響します。たとえば、業務フローの理解不足に起因する要件定義の欠陥1件が、下流では以下のような複数箇所の修正を引き起こします。
- 設計ドキュメントの修正（基本設計書・詳細設計書の該当箇所すべて）
- 実装コードの修正（クラス設計・API 仕様・データベーステーブル定義まで及ぶ）
- テストケースの作り直し（単体・結合・システムテスト）
「上流の1つの欠陥」が下流で「複数の修正箇所」に分裂するため、コストがべき乗的に増加します。これがコスト増の第一のメカニズムです。
修正の副作用（回帰テスト・データ移行）
下流で修正を加えると、その修正自体が別の欠陥を誘発する可能性があります。この副作用への対応もコストに乗ってきます。
- 回帰テスト: 既存機能が影響を受けていないことを確認するテストの再実行
- データ移行: 本番データ・テストデータの整合性維持のための移行スクリプトの作成・実行
- ドキュメント更新: 仕様書・運用手順書・APIリファレンスなど、影響範囲のドキュメントすべての改訂
とくにリリース後の修正では、本番データを守りながら修正・移行する必要があり、修正そのものよりも「安全に修正するための周辺コスト」が大きくなります。
顧客影響と信頼失墜のコスト
リリース後の欠陥が外部に露出した場合、コストは開発工数の枠を超えます。
- 障害対応の緊急工数（土日・夜間対応）
- 顧客への謝罪・説明対応、営業・カスタマーサポートの稼働
- SLA違反による賠償、契約条件の再交渉
- ブランド・信用の毀損（次案件の失注、離職率上昇）
これらは金額に換算しにくい「見えないコスト」ですが、経営インパクトとしては開発工数の数倍〜数十倍に達する場合もあります。1:10:100の「100」は、この見えないコストを含めて考えたときの倍率であるという点を、経営層への説明では強調する価値があります。
修正が組織横断に及ぶ調整コスト
リリース後の欠陥修正は、開発チーム単独で完結しないケースが大半です。
- 顧客・利用部門との仕様変更調整
- 運用チーム・インフラチームとのリリース調整
- 監査・情報セキュリティ部門とのレビュー
- 経営層への報告と意思決定プロセス
組織横断の調整コストは、通常の開発フェーズでは発生しないため見積書には現れませんが、実際の修正フェーズでは大きな時間・工数を占めます。「開発の実装だけ直せば済む」という前提は、リリース後には成立しないのです。
システム開発の費用を正しく理解するガイドブック――相場・見積チェックリスト・予算策定テンプレート付き
この資料でわかること
発注検討者がシステム開発の費用体系を正しく理解し、「この見積は適正か」「どのくらい予算を確保すれば良いか」を自分で判断できるようになること。
こんな方におすすめです
- システム開発の発注を初めて担当する方
- 複数社の見積もりを比較・評価したい方
- IT投資の社内稟議を通す根拠を固めたい方
入力いただいたメールアドレスにPDFをお送りします。
1:10:100を過信しないための3つの注意点
裏返しになりますが、1:10:100を経営層への提案で使う際は、限界を先回りして提示することで、逆に法則の信頼性を高められます。ここでは3つの注意点を挙げます。
経験則であり、業界・規模で倍率は変わる
前述のとおり、Boehm 自身が「小規模プロジェクトでは倍率が緩和される」と示しており、1:10:100は絶対値ではありません。次のような要因で倍率は変動します。
- プロジェクト規模: 大規模ほど倍率が大きくなる傾向
- 業界特性: 金融・医療・公共など、失敗コスト（外部失敗）が大きい業界ほど倍率が跳ね上がる
- 契約形態: 一括請負契約か、準委任か、内製かで「失敗コスト」の帰属先が変わる
- 開発手法: ウォーターフォールかアジャイルかで、後工程の意味そのものが変わる
社内提案では「1:10:100を絶対値として引用する」のではなく、「自社のプロジェクト規模・業界特性に応じてスケーリングした試算を行う」姿勢が誠実です。たとえば、「自社の直近プロジェクトでは、リリース後修正の1件平均工数が要件定義段階に比べて約30倍だった」という自社実績と併記できると、説得力が段違いに増します。
アジャイル・DevOpsでは倍率が緩和されるという反論
1:10:100の原典（Boehm 1976）はウォーターフォール型プロジェクトの実測に基づいており、アジャイル・DevOpsの登場以降、「工程を短いイテレーションに分割することで、後工程の意味そのものが薄れ、倍率は緩和される」という反論が繰り返し提起されています。
実際、アジャイル文脈での近年の再検証研究では、「後工程での修正コストの倍率は、従来の1:10:100が示すほど大きくない」という結果も報告されています。ただし、ここで注意したいのは以下の2点です。
- アジャイルであっても、外部失敗コスト（顧客影響・信頼失墜）はイテレーション設計とは独立に発生する
- スプリント内で欠陥を検出しても、その欠陥がプロダクトオーナー・利用者の期待とのズレに由来する場合、手戻りの本質は上流の理解不足であり、これは依然として上流投資で予防すべきもの
したがって、開発手法がアジャイルであっても、「上流で理解を合わせるための投資が下流のコストを大幅に削減する」という構造は変わらない――これがアジャイル文脈での1:10:100の再解釈になります。
「発見の早さ」より「作り込まない仕組み」が本質
もう一段本質に踏み込むと、1:10:100の教訓は「早く発見しよう」ではなく、「欠陥を作り込まない仕組みを作ろう」と読むべきです。テストを増やすだけでは、上流の認識齟齬に起因する欠陥は検出できません。
- 要件定義の段階で、利用部門・顧客と認識を合わせるためのプロトタイピング
- 設計段階で、複数の設計者による相互レビュー、アーキテクチャレビュー
- 実装段階で、コーディング規約・静的解析・自動テストによる「ミスが物理的にできない仕組み」の整備
これらは「発見コスト（10）」ではなく「予防コスト（1）」の投資です。1:10:100の法則を経営提案で使う際は、「予防への投資は、発見への投資より効率が良い」という主張軸に落とし込むと、稟議のロジックが明確になります。
予防コストへ投資する意思決定の組み立て方
ここまでの整理を踏まえ、経営層への稟議書に組み込める「予防投資の意思決定フレーム」を提示します。
要件定義・設計工程の工数比率の目安
一般的なウォーターフォール型プロジェクトにおける工数比率は、業界データや教科書的な目安として次のような値が引用されることが多くあります。
- 要件定義: 全体工数の10〜15%
- 基本設計: 15〜20%
- 詳細設計: 10〜15%
- 実装: 20〜25%
- 単体テスト: 10〜15%
- 結合・システムテスト: 15〜20%
保守フェーズが膨らむプロジェクトの典型は、要件定義・基本設計の工数比率が10%未満に圧縮されているケースです。稟議書では、次回プロジェクトで要件定義・設計工程に何%の工数を追加で確保するかを明示的に定量化することで、「品質工程への投資」を KPI として測れる形にできます。工程別の費用相場・見積の内訳（人月単価・工程別工数配分の一般値）はシステム開発の費用相場と内訳で解説していますので、社内起案書での基準値として参照してください。
レビュー投資対効果の試算（1:10:100を使ったシミュレーション例）
具体的なシミュレーション例を示します。あくまで一つの試算例ですが、稟議書のたたき台として使えます。
- 前提: 中規模プロジェクト（総工数1,000人日、想定欠陥数100件）
- 予防投資なしの場合: 要件定義段階で発見できる欠陥は30%（30件）、残り70件が結合テスト以降で発見されると仮定
- 修正コスト: 30件×1人日 + 70件×15人日 = 30 + 1,050 = 1,080人日
- 予防投資ありの場合: 要件定義レビュー・設計レビューへの追加投資50人日により、要件定義段階で発見できる欠陥を60%（60件）に引き上げると仮定
- 修正コスト: 60件×1人日 + 40件×15人日 + 追加レビュー投資50人日 = 60 + 600 + 50 = 710人日
- 差分: 予防投資により約370人日の削減（総工数の約37%の削減効果）
倍率の設定は、前段で紹介した国内実測データや自社実績から選ぶことで、根拠のある試算に仕立てられます。数値を過度に楽観化せず、控えめな倍率（例: 15倍）でも十分に投資対効果が正になることを示せると、経営層は納得しやすくなります。
経営層向けの説明フレーム（追加投資 → 削減効果の逆算）
稟議書の構成は、次のような順で組み立てると、経営層に伝わりやすくなります。
- 課題提起: 直近プロジェクトでリリース後の修正費用が想定の2〜3倍に膨らんだ実績を提示
- 原因分析: 上記のうち、要件定義・設計段階で予防可能だった欠陥の割合を推定
- 経験則の引用: 1:10:100の法則（Labovitz & Chang / Boehm）と、国内実測値（IPAコストモデル）を並記
- 予防投資額の提案: 次回プロジェクトでの追加投資額を明示（例: 要件定義+50人日、設計レビュー+30人日）
- 削減効果の試算: 上記の投資により、リリース後修正費用がいくら削減されるかを試算
- KPI設定: 予防投資の効果を測るためのメトリクス（欠陥密度、フェーズ別欠陥検出率、レビュー指摘率）を提示
このフレームで重要なのは、「品質を上げる」ではなく「コストを下げる」という言い回しにすることです。予防投資は品質向上のための費用ではなく、将来の失敗コストを削減するための投資として位置づけると、経営層は投資判断として理解しやすくなります。
予防コストを高める具体的な打ち手
最後に、要件定義・設計・実装の各フェーズで実施すべき予防アクションを整理します。次回プロジェクトの稟議書と併せて、具体的な打ち手を提示できると、承認率が上がります。
要件定義レビュー・仕様の明文化
要件定義段階での欠陥が下流で最大の倍率に膨らむため、ここへの投資は最重要です。
- 利用部門・顧客との認識合わせのためのユーザーストーリー・ユースケース記述
- プロトタイピング・ペーパープロトタイプによる要件の可視化
- 業務フロー図・データフロー図による曖昧箇所の洗い出し
- 要件レビュー会（利用部門・開発チーム・PM・場合により経営層）の定期開催
- 「例外系」「エラー系」「性能要件」「セキュリティ要件」の明文化
要件定義書のレビューでは、「肯定的な合意」だけでなく「疑問点・懸念点の洗い出し」をゴールにすると、下流での認識齟齬を大幅に減らせます。
設計レビュー・アーキテクチャレビュー
設計段階では、実装前に技術的な意思決定を検証することが目的です。
- アーキテクチャ設計レビュー（外部有識者・別チームエンジニアを含めた第三者視点）
- インターフェース設計レビュー（API 仕様・データベーステーブル定義・画面遷移）
- 非機能要件の設計レビュー（性能・拡張性・可用性・セキュリティ）
- 設計ドキュメントのテンプレート標準化（レビュー観点の抜け漏れ防止）
設計レビューは「実装者への手戻り指示」ではなく、「実装前の意思決定の質を上げる場」として運営することがポイントです。
静的解析・自動テスト・TDD
実装段階での予防投資は、「人がミスできない仕組み」を作ることが本質です。
- 静的解析ツール（Lint、SonarQube、SAST）の CI 組み込み
- 自動テスト（単体テスト・結合テスト・E2Eテスト）の整備と CI/CD への統合
- TDD（テスト駆動開発）による「テストが書けない設計」の早期検出
- コーディング規約とレビュー基準の明文化、Pull Request テンプレートの整備
自動化された品質チェックは、初期投資こそかかりますが、プロジェクト全期間を通じた予防コストとして最も高い費用対効果を持ちます。
品質メトリクスの可視化（欠陥密度・レビュー指摘率）
予防投資の効果を経営層に説明し続けるためには、メトリクスの可視化が欠かせません。
- 欠陥密度: フェーズごとの検出欠陥数/工数、または千行あたりの欠陥数
- フェーズ別欠陥検出率: 上流での検出率が上がっているかの推移
- レビュー指摘率: 1回のレビューあたりの指摘件数と、指摘の質の変化
- リリース後障害件数の推移: 予防投資の最終的な効果指標
これらのメトリクスを月次・四半期でトラッキングし、次回稟議書での「予防投資の効果実績」として引用することで、品質投資は「見えないコスト」から「見える成果」に変わります。
まとめ ── 1:10:100を意思決定の羅針盤にする
1:10:100の法則は、システム開発の予防コスト・修正コストの意思決定を組み立てるうえで、便利で強力な羅針盤です。本記事の要点を3つに絞ってまとめます。
第一に、1:10:100は経験則として理解すること。Labovitz & Chang（1992）のデータ品質側とBoehm（1976）のソフトウェア開発側というふたつの起源があり、いずれも「予防コストが最も安く、後工程で発見・修正するほどコストがべき乗的に跳ね上がる」という結論に至っています。国内実測データ（IPAコストモデル：基本設計1 → 稼働後200）も同じ傾向を示しています。
第二に、品質コスト（COQ）の3層構造で語ること。予防コスト（Prevention）・評価コスト（Appraisal）・失敗コスト（Failure）というPAFモデルで分類することで、「品質工程 = テスト工数」という誤解を解き、予防投資の位置づけを構造化できます。
第三に、予防コストへの投資は経済合理的であること。要件定義・設計レビューへの追加工数は、稟議書上「品質を上げるための費用」ではなく「将来の失敗コストを削減するための投資」として位置づけると、経営層は投資判断として納得しやすくなります。倍率の設定は、国内実測データや自社実績から控えめに選び、それでも投資対効果が正になることを示すのが、稟議通過の近道です。
次のアクションとして、まずは自社の直近プロジェクトで発生した「リリース後修正費用」の実績値を棚卸ししてみることをおすすめします。要件定義・設計段階で予防可能だった欠陥の割合を推定し、その規模感を数字で把握するだけでも、次回稟議書のたたき台が具体的な形で見えてくるはずです。1:10:100の法則を、単なる知識ではなく「経営会議で使える意思決定の道具」として活かしていきましょう。
システム開発の費用を正しく理解するガイドブック――相場・見積チェックリスト・予算策定テンプレート付き
この資料でわかること
発注検討者がシステム開発の費用体系を正しく理解し、「この見積は適正か」「どのくらい予算を確保すれば良いか」を自分で判断できるようになること。
こんな方におすすめです
- システム開発の発注を初めて担当する方
- 複数社の見積もりを比較・評価したい方
- IT投資の社内稟議を通す根拠を固めたい方
入力いただいたメールアドレスにPDFをお送りします。
よくある質問
- 1:10:100の法則の「100倍」という数値は本当に正しいのですか？
「100倍」はBoehmの実測に基づく目安であり、プロジェクト規模により約20〜100倍まで変動する経験則で、絶対値ではありません。社内提案では倍率をそのまま引用せず、自社実績や国内実測データ（IPAコストモデル等）と併記して根拠を補強することをおすすめします。
- アジャイル開発でも1:10:100の法則は当てはまりますか？
アジャイルでは短いイテレーションにより倍率自体は緩和される傾向がありますが、顧客影響や信頼失墜といった外部失敗コストは開発手法によらず発生します。上流で認識を合わせる投資の重要性は変わりません。
- 経営層への提案で引用すべき1:10:100の法則の出典は何ですか？
データ品質分野のLabovitz & Chang（1992）とソフトウェア開発分野のBoehm（1976）という2つの独立した起源があります。システム開発の提案では、Boehmの実測データと日本の実情に近いIPAの国内実測値を併記すると反論を受けにくくなります。
- 自社プロジェクトに合わせた修正コスト倍率はどう試算すればよいですか？
直近プロジェクトのリリース後修正工数と要件定義段階での修正工数を比較し、自社実績ベースの倍率を算出します。国内実測データ（基本設計1→稼働後200）より控えめな倍率を採用すると、経営層への説明で過大主張と見なされにくくなります。
- 予防コストへの投資額はどのくらい確保するのが目安ですか？
一般的な工数比率の目安は要件定義10〜15%、基本設計15〜20%です。保守費用が膨張するプロジェクトはこの比率が10%未満に圧縮されがちなため、次回プロジェクトでの増加幅を人日単位で明示し稟議書に落とし込むことが有効です。
