測らない選択が、意図せず選ばれる

効果を測らないという判断は、たいてい明示的には行われません。着手前に測る基準を決めなかった結果として、あとから選ばれてしまいます。

測定を避けることが誰かの利益になる場面は確かにあります。しかし多くの場合、測らない選択は意図的に選ばれるのではなく、測る仕組みがないために自動的に選ばれます。この違いは対処に影響します。仕組みを置けば、多くの型は消えます。

型1 ― 効果を「やってみてから」定義する

着手前に効果の定義がないと、結果の解釈が事後に決まります。この状態で起きることを挙げます。

効果の定義が事後になると起きること
起きること具体的な形
都合のよい指標が選ばれるAIの処理時間だけを測り、確認工程を含めない
比較対象が推計になる導入前の所要時間を「おそらく○分」として計算する
対象範囲が示されない全体の3割の処理について「40%短縮」と報告する
費用の範囲が狭くなるAPI利用料のみを計上し、整備・検証・運用工数を含めない
成功と判定される失敗の定義がないため、失敗にはならない

最後の行が本質です。成功の定義がない状態では、失敗の定義も存在しません。結果として、効果の出ていない施策が継続します。

対処は1つです。着手前に「導入前の数値」を実測すること。これがあれば、後から指標をずらすことが困難になります。実測は多くの場合、数日で終わります。

型2 ― KPIを事後に緩和・すり替える

目標を設定していても、達成が難しくなった段階で指標が変わることがあります。すり替えの形を挙げます。

  • 対象範囲を狭める ― 「全業務」から「定型パターンのみ」へ。数値は達成されますが、当初の効果は得られていません。
  • 指標そのものを変える ― 「処理時間の短縮」から「利用者の満足度」へ。測りにくい指標に移ります。
  • 期間を延ばす ― 「6か月で」から「段階的に」へ。判定の時点が消えます。
  • 活動量に置き換える ― 「削減時間」から「利用件数」へ。手段の実施が成果になります。
  • 定性的な記述に移る ― 「○%短縮」から「業務の質が向上」へ。

対処 ― 変更を記録する

指標の変更を禁止する必要はありません。前提が変わればKPIの見直しは妥当です。必要なのは変更したことと理由を記録することです。

記録があれば、次の2つが可能になります。

  1. 当初の目標が達成されたのか、目標が変わったのかを区別できる
  2. 目標設定の精度そのものを、次回に向けて改善できる

記録がないと、変更は「最初からその目標だった」という形になります。これは組織の学習を止めます。

型3 ― 費用の範囲を狭く取る

投資対効果の分母である費用が、実際より小さく計上される型です。省かれやすい項目は表の第9章に一覧がありますが、とくに次の3つが外れます。

  1. データ整備の工数 ― 自社負担になるため、ベンダーの見積もりには現れません(第6章)。
  2. 検証の工数 ― 検証セットの作成、比較試験、稼働後の回帰テスト。
  3. 運用工数 ― 監視、例外処理、モデル更新時の再検証、参照データの更新。

3番目が最も見落とされます。運用工数は毎月発生するため、3年間で見ると初期費用を上回ることがあります。

⚠ 危険信号

投資判断の資料に「3年間の総額」が示されていない場合、比較の期間が揃っていません。初期費用が小さい選択肢が有利に見え、運用工数の大きい構成が選ばれることがあります。加えて、社内工数が金額換算されていない場合も同じ効果が生じます。自社の人が動く工数は、費用として計上してください。

型4 ― 「技術的には可能」で報告を終える

PoCの報告が動作の説明で終わる型です。表の第9章で述べたとおり、判断に必要なのは動作ではありません。

報告に含まれるべき3項目を再掲します。

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

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

対処は報告書式の変更です。「本番化までの残作業と工数」の欄を作り、その欄が埋まらない案件は着手しないという運用にすると、この型は構造的に消えます。

型5 ― ベンダー選定基準を提案後に作る

選定基準を提案を受けた後に作ると、提案内容に合わせた基準になります。この順序の問題は、意図的な操作がなくても生じます。提示された情報が判断の枠組みを規定するためです。

現れる形を挙げます。

  • 比較表の項目が、そのまま選定基準になる(第3章)
  • 示されなかった項目(バージョン固定、移行のしやすさ、データの学習利用)が基準から落ちる
  • 実演で強調された機能の重みが大きくなる
  • 自社の要件のうち、どの候補も満たさない項目が基準から外れる

対処は順序を変えることです。提案依頼の前に、自社の要件と評価項目を文書化します。表の第9章に評価項目の一覧があります。この作業は半日程度で、提案の比較が格段に容易になります。

型6 ― 中止条件がないまま継続する

本書で繰り返し現れる型です。中止条件が決まっていないと、次のことが起きます。

  • 効果が出ていない施策が継続する
  • 次の案件に予算と人が回らない
  • 中止の判断が個人の責任になるため、判断が遅れる
  • 中止の理由が記録されず、次の案件で同じ壁に当たる(第8章)

対処は着手前の1行です。「対象範囲が○割に届かない場合、または確認を含む所要時間が導入前を上回る場合は中止」と書いておくだけで、中止は計画の実行になります。

現場のシーン架空の例

朝凪精機の十月の取締役会資料には、経理課の請求書処理の効果として「年間1,200時間削減」と載っていました。その翌週、経理課長が自ら推進室に来て、四月に作った算定の内訳を示します。導入後はAIの読み取り時間(1枚数秒)だけを計上し、確認と直しの時間は含まれていませんでした。導入前の1枚20分も、実測ではなく担当者の見込みでした。月末の残業が減らないため、九月の1か月、確認込みで一枚ずつ時間を記録すると1枚平均14分で、削減は年約360時間、報告の3割程度でした。ただ、記録を見た情報システム課の倉田が、時間を食っているのは読み取りではなく確かめ方だと突き止め、手順を変えれば決まった書式の請求書の確認は半分近くに縮む見込みが立ちました。実測がなければ、この改善の余地は見えませんでした。

この章の確認質問

  1. 「導入前の数値を実測した記録はありますか」 ― 稼働後には測れません。
  2. 「対象範囲は全業務の何割ですか」 ― 精度の数値と必ずセットで。
  3. 「確認工程を含めた合計時間はどうなりますか」
  4. 「3年間の総額はいくらですか。社内工数は金額換算されていますか」
  5. 「本番化までの残作業と工数は、どこに書かれていますか」
  6. 「KPIを変更した場合、変更と理由は記録されますか」
  7. 「選定基準は提案を受ける前に作りましたか」
  8. 「中止する条件は文書になっていますか」

8問のうち、1問目と8問目が最も安く効きます。どちらも着手前にしか実行できません。稼働後に「導入前の数値」を測ることはできず、進行中の案件に中止条件を後から設定するのは政治的に困難になります。