業務改善提案書「検証結果」の正しい書き方―決裁者と現場の両方を動かす2層構造

検証が終わったとき、正直ほっとした。

あれだけ時間をかけて現場と調整して、データを取って、ようやくレポートをまとめた。設備メンテナンス企業を支援していたその案件では、フィールドエンジニアの事前準備時間の短縮から、現場での自己解決率の向上まで、きちんと確認が取れていた。

レポートを提出した直後、決裁者はこう言った。

「で、結局いくら削減できたの？」

同じ日に、現場責任者からはこう言われた。

「うちのメンバーで本当にできたか、もう少し確認させてほしい」

両方の反応は、よく考えれば当然だった。でも当時の僕は、どちらの問いにもすぐには答えられなかった。

検証結果には、読み手が2人いる。決裁者と現場メンバーは、検証結果に求めるものがまったく違う。1枚の報告書で両方を満足させようとすると、どちらにも刺さらない内容になる。

これは「書き方の問題」ではなく、「設計の問題」だ。

業務改善提案書の全体的な構成については、業務改善提案書の書き方【構成と通し方を完全解説】を参照してほしい。本記事では「検証結果」の項目に絞って、2層構造の設計と書き方を解説する。

検証結果が「感想文」になる、2つの構造的な理由

検証結果が感想文になる原因は2つある。①数字で証明していない、②読み手が2人いることを意識していない。この2つが重なるとき、検証結果は決裁者の投資判断にも現場の合意形成にも使えない文書になる。

最初に書いた報告書を今でも覚えている。

「フィールドエンジニアが1時間以内に事前準備を完了できました。現場からの反応も良好でした」

これが典型的な感想文だ。

感想文には数字がない。改善前との比較がない。決裁者が投資判断に使える情報がない。「作業が早くなった」「現場が楽になった」という言葉は、書いた本人の主観にすぎない。

決裁者が最も知りたいのは「いくらコストが削減できたか（円）」だ。効果を「金額」に換算して示さなければ、次の予算は下りない。

「で、それで何円節約できるの？」

現場責任者からも「1名のエンジニアはできたが、他のメンバーも同様にできるかどうか確認したい」と言われた。どちらの指摘も正しい。でも僕は最初の報告書で、どちらの問いにも答えられる構造を作っていなかった。

感想文になってしまう理由は、「数字を書かなかった」だけではない。もう一つ、より根本的な原因がある。

それは、検証結果の「読み手が2人いる」という事実を意識していないことだ。

決裁者は「投資判断に必要な根拠」を求めている。金額換算されたコスト削減額、回収期間の見通し、最悪のシナリオでも損失が限定されるという根拠——これが揃って初めて、承認の判断ができる。

一方、現場メンバーが求めているのは別のものだ。「自分たちが本当にできた（再現できた）か」という確認だ。業務改善の担当者はこの2つの需要の違いに気づかず、どちらかの言語で1本の報告書を書いてしまう。

そして提出後に「で、いくら？」「本当にできたの？」という問いを受け、なぜ通じなかったのか分からないまま終わる。

検証内容の設計段階から読み手を分けておく方法については、【テンプレあり】業務改善提案書「検証内容」の書き方と設計手順で解説している。

業務改善提案書の検証結果：「2層構造」の全体ロードマップ

感想文問題の解決策は、検証結果を「決裁者向けROI版」と「実務向け行動基準版」の2層に分けて設計することだ。2人の読み手が求める情報がまったく異なる以上、1枚の報告書で両方を満たそうとすること自体に無理がある。

解決策はシンプルだ。検証結果を最初から2層に分けて設計する。

2層は別々の文書でも、同じ文書の別セクションでも機能する。どちらでもいい。重要なのは、「1枚で両方に伝わるはず」という期待を捨てることだ。

設備メンテナンス企業の案件では、次のように分けた。

決裁者向けには「フィールドエンジニアの事前準備時間の短縮による人件費換算額」と「エスカレーション削減による対応コスト削減額」を提示した。実務メンバー向けには「3名のエンジニアが実際に1時間以内で準備を完了できたか（全員Pass）」「現場でモバイル端末からアクセスできたか（2名Pass・1名要改善）」を記録した。

この2つを同じ報告書に並べて提出したとき、決裁者からも現場責任者からも、初めて「分かった」という言葉が返ってきた。

なお、「期待する効果」の段階で2層の設計を行っておくと、検証結果との整合性が取れやすい。業務改善提案書「期待する効果」の書き方——決裁者用と実務担当者用を分けないと承認されないも合わせて参考にしてほしい。

書き方の実践：決裁者・実務・定性の3ステップ

検証結果の書き方は3ステップで進める。①決裁者向け（金額換算と2シナリオ提示）、②実務メンバー向け（Pass/Fail記録）、③定性的効果（補足資料として添付）の順だ。各ステップを省略すると、どちらかの読み手が「判断できない」状態のままになる。

決裁者向け検証結果を書く

効果を表現するときは、必ず「3種類の数字」を使い分ける。

• 絶対値：事前準備時間 90分→45分（45分短縮）
• 削減率：50%短縮
• 金額換算：45分×時給〇円×月間対応件数×人数 ＝ 月間〇万円相当のコスト削減

数字だけでは不十分だ。決裁者の承認ハードルを下げるには、「2シナリオ」の提示が有効だ。

• 標準シナリオ：計画通り全員がPass → 月間〇万円削減 → 〇ヶ月で投資回収
• 保守シナリオ：効果が目標の半分にとどまった場合 → 月間〇万円削減 → 〇ヶ月で投資回収

「最悪でも〇ヶ月で回収できる」という撤退ライン（Go/No-Go判断基準）を明示することで、決裁者は「失敗しても傷が浅い」という安心感を得られる。本運用への拡大条件として「検証で設定したKPIの80%以上を達成した場合」のように、事前に数値で定義しておくとよい。

一点、必ず守ってほしいことがある。

検証開始と同時に、ベースライン（Beforeデータ）を記録しておくことだ。「検証後に気づいたら、改善前のデータがなかった」という事態は想像以上に多い。改善前の数値がなければ、どれだけ改善できたかを証明できない。検証を始める前に現状を数値で記録する——これが検証結果を書く上で最も重要な準備だ。

実務メンバー向け確認結果を書く

実務メンバー向けは、検証内容ごとにPass/Failを記録した表を作る。

以下は設備メンテナンス企業の実際の記録例だ。

KPIを設計するときのポイントがある。「ストップウォッチで計測して記録してください」というKPIは絶対に避けること。測定自体が現場の新たな業務になり、必ず形骸化する。ログイン記録やアクセス履歴など、システムから自動取得できる指標を選ぶのが鉄則だ。

定性的な効果は補足として位置づける

定性的な効果——「情報を探す時間が減ってストレスが減った」「チームの連携が取りやすくなった」——は、検証結果のメインにしない。

アンケートで数値化して、ROIの補足資料として添付するのが正しい位置づけだ。eNPS（従業員ネット・プロモーター・スコア）や5段階評価の満足度アンケートを、検証開始前と終了後の両方で取得して比較する。

「改善前のアンケートスコアが3.2だったのが、検証後に4.1に上がった」という形で示せれば、定量的なROIを補強する材料になる。ただし、決裁者が投資を判断する根拠はあくまで「円（金額換算）」だ。定性的なデータはその判断を後押しするものとして添付する。

ここでも、検証前のアンケートを取り忘れると比較できなくなる。Beforeの取得を忘れないこと。

実務メンバーの合意確認と本運用への移行判断

実務メンバーの合意を確実に得るには、確認すべき内容を2点に絞る。①「検証結果に納得しているか」と②「本運用に範囲を広げてもKPIが改善できると確信を持っているか」だ。この2点を確認せずに本運用へ移行すると、現場の不満を抱えたまま展開することになる。

検証結果をまとめたら、実務メンバーへの確認を「結果の報告」ではなく「合意の取得」として設計する。

確認する内容は2点だ。

一つ目は「検証の結果に納得しているか」だ。Pass/Failの記録を共有し、「△（要改善）」の項目についての認識を合わせる。数字を提示するだけでは不十分で、「この結果をどう受け止めているか」を実務メンバー自身の言葉で確認することが重要だ。

二つ目は「本運用に範囲を広げてもKPIが改善できると確信を持っているか」だ。

設備メンテナンス企業での案件では、検証終了後に実務メンバー全員に「この仕組みを本運用で全拠点に展開してもKPIが改善できると思うか」を確認する場を設けた。一部のメンバーから「トラブル現象での検索精度をもう少し上げてほしい」という意見が出た。本運用移行前にシステム改善を実施した結果、現場抵抗なく展開できた。この確認がなければ、不満を抱えたまま全拠点に広げることになっていた。

もう一点、覚えておいてほしいことがある。新しい仕組みが現場に定着し、KPIが安定して改善されるまでには、最低でも3〜6ヶ月かかる。「検証から3ヶ月で効果が出なかった」という理由で失敗と判断するのは早すぎる。本運用への移行判断は、決裁者へのROI提示と実務メンバーの合意、両方が揃った時点で行う。

まとめ

検証結果の目的は2つだ。

一つは「決裁者が投資を継続・拡大できる根拠を提供すること」。もう一つは「実務メンバーが本運用に向けて合意できる状態を作ること」。

この2つの目的を同時に達成するために、「決裁者向けROI版」と「実務向け行動基準版」の2層構造が必要になる。

今すぐ着手できる最初の一歩は2つだ。まず、検証開始前にBeforeデータ（ベースライン）を記録する。次に、検証内容ごとのPass/Fail表のフォーマットを用意する。この2つを準備しておくだけで、検証結果の報告は大きく変わる。

業務改善提案書の他の項目の書き方は、業務改善提案書の書き方【構成と通し方を完全解説】で確認できる。