
#010 【実務活用編③】ベネフィット実現をどう測るか?KPI設計の実践
📌 このテーマのCGEITドメイン:Domain 3(ベネフィット実現・配点26%)
▼ #009 Domain4深掘り編はこちら
「このシステム導入、効果はありましたか?」
プロジェクト完了から半年後にこう聞かれて、答えに詰まる場面を何度も見てきた。「稼働しています」「利用者からは概ね好評です」。これは答えになっていない。
IT投資の効果を測れない組織には共通点がある。導入前に「何をもって成功とするか」を定義していないのだ。
CGEITのDomain 3「ベネフィット実現」は、IT投資がビジネス価値に繋がっているかを継続的に確認する仕組みだ。今回はこの概念を実務のKPI設計に落とし込む方法を整理する。
1.なぜIT投資の効果が測れないのか
IT投資の効果が測れない原因は、大きく3つある。
原因①:成功の定義が曖昧なまま始まる
「業務効率化のためにシステムを導入する」という目標では効果が測れない。「何が、どのくらい、いつまでに改善されれば成功か」が定義されていないと、後から評価のしようがない。
原因②:OutputをOutcomeと混同している
「システムを導入した」「機能が稼働した」「ユーザーが使い始めた」はすべてOutputだ。ビジネス価値としてのOutcome(売上向上・コスト削減・顧客満足度向上など)とは別物だ。多くの組織がOutputで効果測定を終わらせてしまっている。
原因③:効果測定の仕組みがプロジェクトと切り離されている
プロジェクトが完了した瞬間にチームが解散し、その後の効果測定を誰も責任を持ってやらない。ベネフィット実現はプロジェクト完了後も続くプロセスだが、その仕組みが設計されていない。
2.OutputとOutcomeの違いを再確認する
#005の用語解説でも触れたが、KPI設計の文脈で改めて整理する。
IT投資
↓
Output(アウトプット)
新システムの稼働・機能の実装・レポートの自動化
↓
Outcome(アウトカム)
業務処理時間の短縮・エラー率の低下・意思決定の迅速化
↓
Benefit(ベネフィット)
コスト削減・売上向上・顧客満足度向上・競争優位性KPIはOutputではなくOutcome・Benefitの層で設定する必要がある。「システムの稼働率99.9%」はOutputの指標であって、ビジネス価値を示していない。
3.ベネフィット実現のKPI設計:3つのステップ
ステップ①:ビジネス目標から逆算する
まず「このIT投資で最終的に何を達成したいか」というビジネス目標を明確にする。そこから逆算してOutcomeを定義し、それを測るKGI・KPIを設定する。
例:
ビジネス目標:「営業生産性を向上させる」
Outcome:「営業担当者1人あたりの商談数を増やす」
KGI:「営業1人あたりの売上を6ヶ月で20%向上」
KPI:「月間商談数:現状30件→目標45件(6ヶ月後)」
ステップ②:ベースラインを測定する
KGI・KPIを設定したら、導入前の現状値(ベースライン)を必ず記録する。ベースラインがなければ改善幅が測れない。これを省略するプロジェクトが驚くほど多い。
ステップ③:測定タイミングと責任者を決める
いつ・誰が・どのように測定するかを事前に決める。プロジェクト完了後6ヶ月・1年後に効果測定を行う「ベネフィットレビュー」の場を設計し、責任者を明確にする。
【補足】KGIとKPIの違いを整理する
KPI設計の話をすると、KGIとKPIが混同されているケースをよく見る。この2つを整理しておく。
KGI(Key Goal Indicator:重要目標達成指標)
Outcomeが達成されたかどうかを評価するための指標だ。「最終的に何が実現できたか」を測るゴールの指標であり、IT投資のビジネス価値そのものを示す。KPI(Key Performance Indicator:重要業績評価指標)
KGIの達成に向けた進捗や状況を途中で測るための指標だ。「今どこにいるか・正しい方向に進んでいるか」を確認するための中間指標であり、問題の早期発見と軌道修正に使う。
この関係性を一言で言うと、KGIは「ゴールへの到達確認」、KPIは「ゴールへの道中の健全性確認」だ。
ビジネス目標:「営業生産性を向上させる」
↓ Outcomeの達成をKGIで評価
KGI:「営業1人あたりの売上を6ヶ月で20%向上」
↓ KGIへの進捗・状況をKPIで測定
KPI:「月間商談数:30件→45件」
「提案書作成時間:平均3時間→1時間」
「システム利用率:80%以上」KGIだけ設定してKPIがないと、ゴールに届かなかった時に「なぜ達成できなかったか」の原因が追えない。KPIだけ設定してKGIがないと、活動の状況は見えるが「それがビジネス価値に繋がっているか」が曖昧になる。
ISACAのベネフィット実現では、KGIでOutcome・Benefitの達成を評価し、KPIでその進捗を継続的に確認するという2層構造で管理することが求められる。
【補足】実務で見る「良い例」と「悪い例」
実際のプロジェクトでよく見る2つのパターンを紹介する。
悪い例:OutputをKGIにしてしまっているケース
「管理会計の高度化」プロジェクト
・KGI:「事業部の業績管理項目にドリルダウン可能とし、月次でレポートの自動生成を実現する」
・KPI:「レポート作成時間を10時間→2時間に短縮」「ドリルダウン項目数:50項目以上」
一見良さそうに見えるが、これはOutputの目標だ。「ドリルダウンできるレポートが自動で出る」「作成時間が短縮される」はシステムが生み出す成果物であって、ビジネス価値ではない。
この設定では「システムは稼働しました。レポートも出ています」で終わり、半年後に「で、何が変わったの?」という問いに答えられなくなる。経営層からすると「便利なレポートができたのはわかった。だから何?」という反応になりがちだ。
良い例:OutcomeとBenefitまで定義しているケース
この設定では「管理会計が高度化されたことで、経営会議の質がどう変わったか」まで追いかけられる。ドリルダウン可能なレポートの自動生成はあくまでも手段であり、目的は経営の意思決定を変えることだと明確になっている。
「管理会計の高度化」プロジェクト
・ビジネス目標:「経営の意思決定スピードと精度を上げる」
・Outcome:「事業部別の収益構造を経営層がタイムリーに把握し、迅速な経営判断ができる状態にする」
・KGI:「月次経営会議での意思決定事項数を現状3件→6件に倍増(1年後)」
・KPI(Leading):「レポート配信タイミング:月末翌営業日までの達成率」「経営層のレポート閲覧率」「事業部長による数値確認の完了率」
・KPI(Lagging):「経営会議での意思決定件数」「意思決定までのリードタイム」「事業部別の収益改善率」
この設定では「管理会計が高度化されたことで、経営会議の質がどう変わったか」まで追いかけられる。ドリルダウン可能なレポートの自動生成はあくまでも手段であり、目的は経営の意思決定を変えることだと明確になっている。
2つのケースの違いを一言で言うと
悪い例はシステム部門が「何を作るか」を目標にしている。良い例はビジネス部門と一緒に「何を変えるか」を目標にしている。
IT投資のゴールは「システムを動かすこと」ではなく「ビジネスを変えること」だ。この視点を持ってKGI・KPIを設計することが、ベネフィット実現の出発点になる。
4.Leading IndicatorとLagging Indicatorを使い分ける
#005でも紹介したこの2つの指標は、KPI設計において特に重要だ。
Lagging Indicator(遅行指標)
すでに発生した結果を測る指標。売上・コスト削減額・顧客満足度スコアなどが該当する。最終的な成果を示すが、結果が出るまでに時間がかかるため、問題に気づいた時には手遅れになることがある。
Leading Indicator(先行指標)
将来の成果を予測する指標。現在の活動や行動を測るものが多い。例えば「営業訪問件数」は「売上」の先行指標になり得る。
実務での使い分け
IT投資のKPI設計では、両方をセットで設計することが重要だ。
例:受注管理システム導入の場合
Leading Indicator:システム利用率・データ入力の完了率・営業担当者のログイン頻度
Lagging Indicator:受注処理時間・受注件数・営業1人あたりの売上
Leading Indicatorで早期に問題を察知し、Lagging Indicatorで最終的な成果を確認する。この2段構えが、IT投資の効果を継続的に管理するための基本設計だ。
5.実務での落とし込み方
提案書への組み込み方
IT投資の提案書を作る際、以下の項目をセットで提示することを習慣にしている。
投資の目的(ビジネス目標)
期待するOutcome(具体的な変化)
KGI・KPI(Leading+Lagging)
ベースライン(現状値)
測定タイミングと責任者
この構成で提案書を作ると、経営層から「これなら投資対効果が追いかけられる」という反応が返ってくることが多い。
よくある抵抗への対応
「効果が数字で測れない投資もある」という声をよく聞く。確かに全ての投資を定量化できるわけではない。しかし定性的な目標でも「半年後にこの状態になっていれば成功」と言語化することはできる。完璧な数値化よりも、成功の定義を言語化することの方が重要だ。
締め:測れないものは改善できない
「このシステム導入、効果はありましたか?」という問いに自信を持って答えられる組織は少ない。しかしそれは測っていないからであって、効果がないからではないことも多い。
CGEITのDomain 3が示すベネフィット実現は、IT投資を「やりっぱなし」にしないための仕組みだ。測定できる形で成功を定義し、継続的に追いかける。この習慣がIT投資の質を上げ、経営からの信頼を築く。
あなたの組織では、IT投資の効果を導入前に定義していますか?
次回:#011【Domain2深掘り】ベンダー管理とITガバナンスの接点。
この連載の全記録はマガジン「誰も書かなかったCGEIT挑戦記」にまとめています。参考になったらシェアやフォローで広めていただけると嬉しいです。