本記事について
当サイトを閲覧いただきありがとうございます。 本記事はシリーズ『生成AI時代のアーキテクチャ超入門』の「ソリューションアーキテクチャ」カテゴリ第4弾として、見積もりとROIについて解説する記事です。
技術だけで語るアーキテクトは半人前、数字で語って一人前。本記事ではFP法/ストーリーポイント/TCO/ROI/NPV/IRR・初期コストvs運用コスト・段階投資の判断、AI時代の見積もり精度向上まで、技術と経営の橋渡しに必要な数値の道具を扱います。
本記事のテーマについてさらに詳しく知りたい方は『世界一わかりやすい IT業界のしくみとながれ』も参考にしてみてください。
そもそも見積もりとROIとは何か
家計の大きな買い物を想像してください。車を買うとき、「車両価格だけでなく保険・税金・ガソリン代・駐車場代を5年分で計算し、通勤時間短縮の価値と比較する」──これが個人版のROI(投資対効果)です。
IT プロジェクトの見積もりとROIも同じ構造です。初期費用だけでなく運用費用を含めた総コスト(TCO)を算出し、得られるビジネス効果と比較することで、投資する価値があるかを数字で判断します。
もし見積もりとROIがなければ、「技術的に正しい」だけでは経営層の承認を得られず、プロジェクトが始まりません。技術と経営の共通言語は数字です。
なぜ見積もりとROIが必要か
経営判断の土俵に乗る
予算・人員・期間の判断は全て数字で行われます。「技術的に正しい」だけでは承認されず、投資対効果の数字が必要です。
優先順位が明確になる
複数のプロジェクト候補がある時、ROI が最も高いものから着手するのが合理的です。数字がないと感情論になります。
完了後の評価ができる
プロジェクト完了後に「成功か失敗か」を判断するには、当初の想定と実績の比較が必要です。ROI 未設定だと検証できません。
費用の構成要素
プロジェクト費用は初期費用 + 運用費用の2本立てで考えます。初期だけで判断すると、運用コストで赤字になるパターンが頻発します。
| 費用区分 | 内容 |
|---|---|
| 初期費用(CapEx=Capital Expenditure、資産購入のための投資) | 設計・開発・ハードウェア・ライセンス |
| 運用費用(OpEx=Operating Expenditure、運用経費) | クラウド料金・保守・ライセンス更新 |
| 人件費 | 社内人員の工数 |
| 研修費 | 利用者・運用者の教育 |
| 機会費用 | 他プロジェクトを後回しにする損失 |
| リスク費用 | 失敗時の損失見込み |
3〜5年のTCO(総所有コスト)で見積もるのが現代的で、初期だけでは見えない運用コストを含めます。
効果の構成要素
効果は定量効果と定性効果に分かれます。定量効果は数値化でき、定性効果は数値化しづらいが重要度は高いです。
| 効果区分 | 内容 |
|---|---|
| コスト削減 | 業務時間削減・人件費減 |
| 売上増加 | 新規顧客・客単価増 |
| リスク低減 | 事故・違反の回避 |
| 業務品質 | ミス削減・顧客満足 |
| スピード | 意思決定の迅速化 |
| 戦略的価値 | データ活用・DX 基盤 |
業務時間削減はほぼ全プロジェクトで効果に数えられるため、最も使われる効果です。時給換算して計算します。
ROIの計算式
シンプルな ROI 計算は以下です。複雑な指標もありますが、経営層に説明するなら単純な式が通りやすいです。
3年ROI 100%以上が一般的な承認ラインです。200%なら回収後に倍返しの意味になります。
NPV(正味現在価値)
時間価値を加味したROIです。「今の100万円と3年後の100万円は価値が違う」という考え方で、将来のキャッシュフローを割引現在価値に換算します。
NPV = Σ( 各年のキャッシュフロー / (1+割引率)^n ) - 初期投資
割引率 5% なら:
3年後の100万円 ≒ 今の86万円
大規模・長期プロジェクトでは NPV が使われます。割引率は企業ごとに決まっており、通常は5〜10%が使われます。
Payback Period(回収期間)
何年で投資額を回収できるかを示す指標です。NPV より直感的で、経営層に刺さりやすいのが特徴です。
| 回収期間 | 評価 |
|---|---|
| 1年以内 | 極めて有利 |
| 2〜3年 | 標準的な承認範囲 |
| 4〜5年 | 慎重に検討 |
| 5年以上 | 戦略的価値が必要 |
3年以内の回収が一般的な目安で、これを超えると追加の説明が求められます。
見積もり手法
工数見積もりの主要手法は以下です。1手法ではなく複数組み合わせ、結果を比較して精度を上げます。
| 手法 | 内容 |
|---|---|
| 類推見積もり | 類似案件との比較 |
| ファンクションポイント法 | 機能数で算出 |
| COCOMO | 行数・複雑度で算出 |
| ボトムアップ | 作業を積み上げ |
| 三点見積もり | 楽観・悲観・最可能値 |
| プランニングポーカー | アジャイル・相対見積もり |
アジャイルプロジェクトはプランニングポーカー + Velocityが実務的です。絶対値ではなく相対的な複雑度で見積もります。
見積もりのバッファ
見積もりは必ずズレる前提で、バッファ(余裕)を積みます。新規性・不確実性に応じて、20〜50%のバッファを見込みます。
| 不確実性 | バッファ |
|---|---|
| 既存技術・類似案件 | +10〜20% |
| 新技術・未経験 | +30〜50% |
| 研究要素あり | +50〜100% |
| PoC段階 | 計算不能・柔軟運用 |
「見積もりピッタリ」は不可能で、初期見積もりが1.5倍になるのは珍しくありません。バッファを計上しないのは見積もり失敗の典型です。
ROI算出の具体例
社内申請ワークフローのデジタル化を例に ROI を計算してみます。具体的な数値計算はアーキテクトの基本スキルです。
【投資】
・初期開発費: 500万円
・年間運用費: 100万円 × 3年 = 300万円
・合計投資: 800万円
【効果】(3年間)
・月500時間 × 時給3000円 × 12ヶ月 × 3年 = 5400万円
・業務ミス削減: 年50万円 × 3年 = 150万円
・合計効果: 5550万円
【ROI】
(5550 - 800) / 800 × 100 = 594%
Payback: 約6ヶ月
数字で示せば経営判断は一瞬です。曖昧な「業務効率化」では承認されません。
定性効果の扱い
数値化しづらい効果をどう扱うかは、ROI 計算の難所です。無理に数値化するか、定性効果として並列表記するか、判断が必要です。
| 定性効果 | 扱い |
|---|---|
| 従業員満足度 | 離職率低下で金額換算 |
| ブランド価値 | PR 効果・広告費換算 |
| セキュリティ強化 | 違反時のペナルティ回避 |
| 戦略的優位 | 競合比較・市場シェア |
| データ基盤 | 将来の AI 活用価値 |
定性効果を無理に全部数値化すると説得力が落ちるため、「数値化できる効果 + 定性効果のリスト」の二部構成が現実的です。
TCO(総所有コスト)
ライフサイクル全体のコストを Total Cost of Ownership と呼びます。初期購入価格だけでなく、運用・保守・廃棄・機会費用を含めた総額で比較します。
| TCO構成要素 | 内容 |
|---|---|
| 初期費用 | ハードウェア・ソフト・開発 |
| 運用費用 | 人件費・電気・ネットワーク |
| 保守費用 | ライセンス更新・パッチ |
| 更新費用 | 定期リプレース |
| 廃棄費用 | データ移行・廃棄処理 |
「安物買いの銭失い」を防ぐのが TCO分析です。初期費用は安くても運用コストが高ければ、長期的には割高です。
判断基準①:プロジェクトの性質
ROI 分析の深さはプロジェクト性質で変わります。戦略的投資は定性面も重視され、単純な ROI だけでは判断できないことがあります。
| プロジェクト | ROI重視度 |
|---|---|
| 業務効率化 | 非常に高い(コスト削減効果重視) |
| 新規事業 | 中(売上増の不確実性) |
| インフラ刷新 | 中(TCO 重視) |
| セキュリティ対応 | 低(リスク低減が主) |
| 規制対応 | 計算不要(やらない選択肢なし) |
判断基準②:組織文化
経営層の判断スタイルで ROI の出し方が変わります。数字好きな経営なら詳細な計算、ビジョン重視なら定性も強調。
| 文化 | 推奨 |
|---|---|
| 数字重視 | NPV・IRR・Payback の三点セット |
| バランス | ROI + 定性効果 |
| ビジョン重視 | 戦略的価値を前面・ROI は補足 |
ケース別の選び方
業務効率化プロジェクト(社内申請・RPA等)
RPA等の業務効率化は、単純 ROI + 時間削減の金額換算 + 3年TCO で評価。「月X時間削減 × 時給 × 12か月 × 3年」で数値化が直球、Payback を前面に。バッファは+20%で十分、見積もりは類推 + ボトムアップの二本立て。
新規事業・B2Cサービス
NPV + Payback + 定性効果のリスト。売上予測は楽観/悲観/最可能値の三点見積もり、初期は PoC 予算枠で承認 → 結果を見て本格投資。不確実性高いためバッファ+50%、早期撤退の判断基準も設定。
インフラ刷新・クラウド移行
5年TCO 比較 + 6R 分析 + リスク低減効果。オンプレ維持 vs クラウド移行の総額比較、電気代・運用人件費・ハード更新まで含める。セキュリティ強化・災害対応の定性効果も並列記載。
規制対応・セキュリティ強化
違反時のリスク金額 + 対応コストの比較 + やらない場合の損失。ROI は計算不要(やらない選択肢なし)、「個人情報漏洩で最大X億円の損失回避」を前面。TCO より規制要件の充足度で判断。
見積もり精度・ROIの数値Gate
※ 2026年4月時点の業界相場値です。テクノロジー・人材市場の変化で陳腐化するため、定期的にアップデートが必要です。
見積もりはズレる前提でバッファを積むのが鉄則。以下が業界定番の目安値です。
| 項目 | 推奨値 | 理由 |
|---|---|---|
| バッファ(既存技術・類似案件) | +10〜20% | 標準的な不確実性 |
| バッファ(新技術・未経験) | +30〜50% | 学習コスト想定 |
| バッファ(研究要素あり) | +50〜100% | PoC 先行が前提 |
| Payback Period | 3年以内 | 一般的な承認ライン |
| 3年ROI | 100%以上 | 回収+利益の最低ライン |
| TCO評価期間 | 3〜5年 | 運用コストを含める |
| 定性効果の扱い | 並列記載 | 無理な数値化は信頼低下 |
| 見積もり手法 | 複数併用 | 類推+ボトムアップの二重化 |
| NPV割引率 | 5〜10% | 企業標準による |
| クラウド運用費/売上比 | 5〜15% | 業種により変動 |
ピッタリ見積もりは嘘、幅で正しく外れるのが誠実です。「3000万円〜4500万円、バッファ50%」で提示すれば4200万円で着地すれば「想定内」と評価されます。
見積もりは「幅で正しく外れる」精度を装うと信頼を失います。
やってはいけないこと
見積もりで事故る典型パターン。どれもプロジェクトを葬る代償を払います。
| 禁じ手 | なぜダメか |
|---|---|
| ピッタリ見積もりで提示 | バッファなしは必ずズレる、初期3000万円が12億円になる自治体事例の定番 |
| 初期費用だけで判断 | 運用費で逆転、TCO(3〜5年)で評価 |
| 見積もりを1手法だけで出す | 類推+ボトムアップの二重化で精度向上 |
| 定性効果を全て無理に数値化 | 信頼を失う、並列記載が誠実 |
| 既知のROIだけで承認を目指す | 新規事業はNPV + シナリオ分析必須 |
| バッファなしで新技術プロジェクト着手 | 見積もりは必ず1.5倍になる、+30〜50%のバッファ必須 |
| 規制対応案件にROIを計算 | やらない選択肢がない、リスク金額で比較 |
| AI活用効果を計上しない | 業務時間削減30%等が直接ROIに影響 |
| 見積もりを一度決めたら変更しない | 現代は継続的再計算、PoC 先行で精緻化 |
| 人月単価を古い市場価格で計算 | AI 時代で激変、最新相場で再計算 |
2013年 Healthcare.govローンチ失敗(当初9400万ドル見積もりが20億ドル追加投入、1年間医療政策停滞)、日本自治体基幹刷新プロジェクト(当初3億円18か月が12億円48か月、議会承認やり直し)──ピッタリ見積もりの代償の典型事例です。
見積もりはズレる前提で設計。ピッタリ当てるより幅で正しく外れる方が誠実です。
| 「ROIが高ければ必ず承認される」と過信 | 他プロジェクト比較・予算制約で落ちる、経営アジェンダとの整合が重要 | | 「見積もりは正確に出すべき」とピッタリ出す | 正確な見積もりは不可能、幅で正しく外れるのが誠実 |
AI判断軸
| AI有利 | AI不利 |
|---|---|
| AI前提の短期見積もり | 従来の人月見積もり |
| 継続的な再計算 | 一度決めた予算固執 |
| 速いPoC → 判断 | 大規模ウォーターフォール |
| AI活用の効果も計上 | 従来比だけで評価 |
- TCO(3〜5年)で比較する — 初期だけでは見えない運用コストを含める
- ROI計算は単純式 + Payback — 経営層に刺さるのはシンプルな指標
- バッファを必ず積む — 不確実性に応じて20〜100%、ピッタリは失敗
- AIで見積もり前提を更新 — 人月ベースは時代遅れ、PoC 先行で再計算
AI時代の見積もりは「人月」から「タスク単位」に変わる
従来の見積もりは「この機能を作るのに何人月かかるか」が基本単位でした。AI時代にはこの前提が崩れています。同じ機能でも、AIツールを使いこなせるエンジニアとそうでないエンジニアで生産性が3〜10倍異なるため、人月ベースの見積もりが精度を失っています。
代わりに有効なのはタスク単位見積もりです。機能をタスクに分解し、各タスクについて「AIで自動化可能か」「人間の判断が必要か」を分類します。AI自動化可能なタスクは工数を大幅に圧縮して計上し、人間判断が必要なタスクは従来通りの工数を見積もります。
この分類作業自体にもAIを活用できます。過去のプロジェクトのタスク一覧をAIに入力し、「現在のAIツールで自動化可能なタスクを分類せよ」と指示すれば、見積もりの初期ドラフトが短時間で完成します。
注意点として、AIによる工数圧縮効果を過大に見積もると、バッファが不足して従来型の「ピッタリ見積もり」と同じ失敗に陥ります。AI活用の効果は控えめに30〜50%の圧縮として計上し、残りをバッファとして確保するのが安全です。
AIコスト(LLM API費用)をROI計算に含める
AI活用プロジェクトのROI計算で見落とされがちなのが、LLM APIの利用コストです。開発フェーズではエンジニア1人あたり月額50〜200ドル程度のAPI費用が発生し、本番サービスにAI機能を組み込む場合はリクエスト数に比例してコストが増加します。
ROI計算では以下を追加項目として含める必要があります。
- 開発時のAIツール費用: GitHub Copilot、Claude等のサブスクリプション × 人数 × 月数
- 本番運用のAPI費用: リクエスト単価 × 想定トラフィック × 月数
- ベクトルDB・GPU基盤の費用: RAGや推論を自前で動かす場合のインフラコスト
一方で、AI活用による工数削減効果もROIのプラス側に計上します。開発期間短縮・保守工数削減・障害対応時間短縮などを金額換算し、API費用との差分が純粋なROI改善幅になります。「AIを使えば安くなる」と単純に考えるのではなく、新規コスト項目も含めたTCOで比較することが誠実な見積もりです。
決めるべきこと — 自分のプロジェクトでの答えは?
以下の項目について、自分のプロジェクトの答えを1〜2文で言語化してみてください。曖昧なまま着手すると、必ず後から「なぜそう決めたんだっけ」が問われます。
- 費用構成(CapEx・OpEx・人件費)
- 効果の定量化(時間削減・売上増)
- ROI計算方式(単純ROI・NPV・Payback)
- 見積もり手法(ボトムアップ・類推等)
- バッファ率(不確実性に応じた余裕)
- TCOの期間(3年・5年・7年)
- 定性効果の扱い(並列記載 or 数値化)
筆者メモ — 「見積もり破綻」でプロジェクトが中止された事例
見積もりの甘さがプロジェクトを葬った事例は、SI業界で繰り返し語り草になっています。
2013年のオバマケア Healthcare.gov ローンチ失敗は、見積もりと実装能力の乖離が招いた象徴事例です。米国政府の医療保険取引所サイトは、当初見積もり約9400万ドルで2013年10月ローンチ予定でしたが、複雑な既存システム連携の見積もりが甘く、ローンチ日に同時接続数千人でシステム停止。2014年までに推定20億ドルを追加投入して復旧させました。「見積もりの楽観が一国の医療政策を1年止めた」ことを突きつけた事件です。
もう一つ、日本国内の地方自治体基幹システム刷新プロジェクトでは、当初3億円・18か月と見積もったところ、要件変更の累積で最終的に12億円・48か月となり、調達改定と議会承認のやり直しで追加1年ロスした、という事例がよく報告されます。バッファを積まずに「ピッタリ見積もり」で発注した結果、変更が発生するたびに予算・納期・議会承認が全て崩れる──という負のスパイラルに入りました。
どちらも見積もりはズレる前提で設計しなかった代償を示します。ピッタリ当てることを目指すより、幅で正しく外れる方が結果的にプロジェクトは平和に着地する、という実務的真実を教える事例群です。
この記事に関連する記事
https://senkohome.com/arch-intro-solution-overview/ https://senkohome.com/arch-intro-index-solution/ https://senkohome.com/arch-intro-solution-nfr/
まとめ
本記事は見積もりとROIについて、TCO・3点見積もり・バッファ・ROI・Payback・NPV・定性効果・AI時代の前提激変まで含めて解説しました。如何だったでしょうか。
TCOで比較し、Paybackで刺し、バッファで誠実に、AI前提で再計算する。これが2026年の見積もり・ROIの現実解です。
次回は「PoC設計」について解説します。Go/No-Go基準・期間設定・効果検証の作法と、「永遠に終わらないPoC」を防ぐための数値Gateを掘り下げる予定です。
シリーズ目次に戻る → 『生成AI時代のアーキテクチャ超入門』の歩き方
本記事で扱った内容の詳細は AWS 料金計算ツール も合わせて参考にしてください。
それでは次の記事も閲覧いただけると幸いです。
📚 シリーズ:生成AI時代のアーキテクチャ超入門(78/89)
