プロジェクトマネジメント・投資対効果

投資判断が難しい理由

AI関連の投資判断が難しいのは、効果の不確実性が高いからではありません。効果を測る基準が着手前に決まっていないことが多いからです。

通常のシステム投資であれば、削減できる作業時間や置き換えられる外注費が事前に見積もれます。AIの場合、精度が事前に確定しないため「やってみないと分からない」という説明が通り、それが効果測定の設計を後回しにする理由になります。

本章では、この構造への対処を扱います。核心は単純です。不確実なのは効果の大きさであって、測る基準は着手前に決められる。

ROI測定の考え方

何を「効果」として数えるか

AI導入の効果は4種類に分かれます。混ぜて語ると測れなくなるため、分けて扱います。

実務で最も多い誤りは、時間削減をAIの処理時間だけで測ることです。AIが5秒で下書きを作っても、確認と修正に10分かかるなら、効果は確認工程の設計で決まります。

費用側に含めるもの

費用は、利用料だけではありません。次を含めて計算します。

• API利用料または月額(第3章の見積もり手順)
• 開発・組み込みの工数(社内工数も金額換算する)
• データ整備の工数(第6章。最も見積もり漏れが起きる項目)
• 検証の工数(検証セットの作成、比較試験)
• 教育と周知の工数
• 稼働後の運用工数(監視、例外処理、モデル更新時の再検証)
• 保守費用(外部委託の場合)

初期費用だけで判断すると、稼働後の運用工数が計上されません。3年間の総額で比較するのが現実的な期間の取り方です。

KPIとKGIの設計

指標は「最終的に達成したいこと(KGI)」と「そこに至る過程の指標(KPI)」に分けます。AI案件では、この対応関係が崩れやすいので注意が必要です。

設計の原則を2つ挙げます。

1つ目。KPIには必ず「対象範囲の割合」を入れる。精度だけを見ると、全体の3割しか処理していない状態でも「精度92%」と報告できます。範囲と精度は常にセットで扱います。

2つ目。着手前に導入前の数値を実測する。これがないと、後から効果を示せません。「導入前の処理時間を測っていなかった」という理由で効果が証明できない案件は、実際に多く発生します。

予算計画と投資判断のプロセス

AI案件特有の予算上の性質が3つあります。

1. 変動費の比重が高い ― 従量課金では使用量に比例します。予算枠を決めるだけでなく、上限管理の仕組みが必要です(第4章)。
2. 初期費用が小さく見える ― 試作が安く作れるため、着手の敷居が低い。その結果、本番化の費用が別途必要になることが後で判明します。
3. 費用が下がる可能性がある ― モデルの単価は下がる傾向にあります。長期契約より、切り替えの余地を残すほうが有利な場合があります(第10章)。

実務的な進め方として、予算を2段階で承認する形が機能します。第1段階は検証のための小額(データ調査と比較試験まで)、第2段階は本番化のための本予算です。第1段階の結果を持って第2段階を判断すれば、「やってみないと分からない」問題が構造的に解決します。

ベンダー選定基準の作り方

選定基準は、提案を受ける前に作ります。提案を見てから基準を作ると、提案内容に合わせた基準になります。

基準に入れる項目

最後の2項目が抜けている選定が非常に多いです。納品物に設計資料と運用手順書が含まれないと、以後の変更を自社で行えません。そして受け入れ条件が定義されていないと、完了の判断ができません。

PoCから本番化への意思決定

PoCが本番に進まない問題は、判断の設計で解決できます。着手前に決めることと、報告時に出すことを分けます。

着手前に決める4項目

1. 比較対象の数値 ― 現状の処理時間・誤り件数を実測する。
2. 成功と判定する基準 ― どの指標がどこまで動けば進むのか。
3. 判定の期限と会議の日付 ― 日付を先に押さえる。
4. 中止する条件 ― どうなったら止めるのか。

4番目が最も重要です。中止条件が書かれていないPoCは止まりません。中止の判断が誰かの評価に結びつくためです。着手前に「対象範囲が○割に届かない場合は中止」と書いておけば、判断は個人の責任ではなく計画の実行になります。

報告時に必ず出す3項目

1. 対象範囲の割合と、対象外だった理由
2. 人の確認を含めた所要時間の変化
3. 本番化までの残作業と工数(権限・監視・例外処理・費用上限・保守・教育)

3番目が報告に含まれていれば、本番化の判断は具体的な工数の議論になります。含まれていなければ、「技術的には可能」という結論で終わります。

プロジェクト体制とステークホルダー管理

AI案件で特に注意が必要な体制上の論点を挙げます。

• 受け入れ判断者を明確にする ― 誰が完了を判定するのか。業務側の責任者が担うべきです。
• データ提供の責任者を置く ― データの取り出しと定義の確認は、情報システム部門と業務部門の両方に関わります。窓口を決めます。
• 現場の代表を体制に入れる ― 例外の情報は現場にしかありません(第7章)。
• 法務・情報セキュリティの確認時点を工程に入れる ― 完成後に確認すると手戻りが大きくなります。

とくに最後の項目は工程表の作り方に関わります。データの取り扱い条件と権限設計の確認は、開発の前に行うのが正しい順序です。

失敗プロジェクトに共通する要因

後から振り返って共通して挙がる要因を整理します。

右の列を見ると分かるとおり、いずれも着手前に確認可能な項目です。失敗の主要な要因は技術的な不確実性ではなく、確認の省略に集中しています。

自社開発・外部調達・パートナー協業の判断

作るか買うか組むかの判断枠組みです。次の4つの問いで整理できます。

1. この処理は自社の競争力に直結するか ― 直結するなら自社に知見を残す形を選びます。
2. 市販の製品で要件を満たせるか ― 満たせるなら調達が最も安い。カスタマイズが多いなら判断が変わります。
3. 維持できる体制があるか ― 自社開発では、変更・復旧ができる人が継続的に必要です(第10章)。
4. データを外に出せるか ― 出せない場合、選択肢が絞られます。

最後の行が実務では重要です。要件が固まっていない段階での自社開発は、作り直しの費用が最も高くつきます。市販の製品で試して要件を固め、必要になった部分だけ作るという順序が、総額では有利になることが多いです。