検証を終えたとき、担当者の顔には安堵と疲労が混ざった表情が浮かんでいた。
何週間もかけて現場に入り、数字を取り、メンバーにも協力してもらった。報告書もまとめた。数字もある。現場の声もある。「これで大丈夫なはずだ」と思いながら上司に提出した。
返ってきた言葉は、「なんか違うんだよね」だった。
何が違うのか、具体的には教えてもらえない。「もう少しヒアリングしてみて」と言われるが、何をヒアリングすればいいのかも分からない。時間をかけて書き直しても、また同じ反応が返ってくる。プロジェクトだけが止まっていく。
僕はこういう場面を、300社以上のコンサルティングの現場で繰り返し見てきた。
多くの場合、問題は「書き方が丁寧かどうか」ではない。検証結果の報告書には、見落とされがちな構造的なNGパターンが存在する。そのパターンのどれかに当てはまっているから、何度書き直しても「なんか違う」が繰り返される。
業務改善提案書の書き方全体については業務改善提案書の書き方【構成と通し方を完全解説】を参照してほしい。本記事では「検証結果」の書き方に絞り、よくあるNGパターンとOKサンプルを解説する。
- 検証結果が却下される原因は「書き方」でなく「5つのNGパターン」のどれかに当てはまっている。自分のパターンを特定することが最初の一歩。
- 5つのNGに共通する根本原因は「読み手が2人いる（決裁者と現場）」という設計視点の欠如にある。
- 書き直しは「決裁者向けROI版（金額換算・2シナリオ・撤退ライン）」と「現場向け行動基準版（Pass/Fail表・合意確認）」の2層で行う。
業務改善提案書「検証結果」の書き方でやりがちなNG5選
検証結果が却下される原因は5つのNGパターンに集約される。①ポエム報告、②Beforeデータなし、③cherry-picking、④手動計測KPI、⑤金額換算なし——このどれかに当てはまっているから「なんか違う」が繰り返される。
300社のコンサル経験と調査を通じて、検証結果が却下・放置されるパターンは5つに集約される。
①「ポエム報告」、②「ベースライン（Beforeデータ）欠如」、③「cherry-picking（都合の良いデータ抽出）」、④「手動計測KPI形骸化」、⑤「金額換算（ROI換算）なし」。
それぞれNGサンプル→なぜNGか→OKサンプルの順に解説する。「これは自分だ」と気づいた項目が、まず直すべき箇所だ。
NG1：「ポエム報告」（感想文パターン）
次の文章を見てほしい。
「フィールドエンジニアの作業効率が向上しました。現場のメンバーからも好評でした。今後の本運用に向けて引き続き取り組んでまいります。」
数字が1つもない。「向上」「好評」はすべて主観だ。
決裁者が検証結果に求めているのは「いくら削減できたのか」「何%改善したのか」という数値だ。「現場が喜んだ」という感想では、追加予算を下ろす根拠にならない。これが「ポエム報告」——自分では報告したつもりになっているが、決裁者には何も伝わっていない状態だ。
OKサンプルはこうなる。
「フィールドエンジニアの事前準備時間が90分から45分に短縮されました（50%削減）。人件費換算で月間○万円相当のコスト削減を確認しました。」
変換ルール: 「〜しました」「〜でした」という文末を見つけたら、必ず数字（絶対値・削減率・金額換算）に置き換える。
NG2：「Beforeデータなし」（比較不能パターン）
「検証後、スタッフ全員が業務をスムーズにこなせるようになりました。以前と比べて明らかに改善されています。」
「以前と比べて」とあるが、改善前の数値が記録されていない。
どれだけ良くなったかを証明できない報告書では、決裁者は投資継続の判断ができない。「以前のデータはどこにあるんですか？」と問い返され、その時点で取り返しがつかない。
改善着手後に気づいても、Beforeデータは取れない。これが「比較不能パターン」の致命的な点だ。
OKサンプルはシンプルだ。
「改善前（2月計測）：平均処理時間45分。改善後（4月検証）：平均処理時間28分。削減率38%。」
変換ルール: 検証を開始する日に「ベースライン（Beforeデータ）」を計測・記録しておく。後から気づいても絶対に取り返せない。これだけは先に必ずやる。
NG3：「都合の良いデータ抽出」（cherry-pickingパターン）
「ベテランのAさんとBさんの検証では、どちらも目標時間を達成しました。本運用への移行を推奨します。」
AさんとBさんが成功しても、他のメンバーが同様にできるかどうかは証明されていない。
上司が「本当にこの内容？」と言う背景には、「全員にできるのか」という疑念がある。意図せず好条件の結果だけを選んでしまう——これがcherry-pickingだ。悪意はない。でも意図せずやってしまうから厄介で、報告後に必ず「他のメンバーは？」と問い返される。
OKサンプルは全員の結果を出す。
「対象者5名の検証結果：目標達成3名（Pass）、要改善2名（課題：検索キーワードの工夫が必要）。Pass率60%。要改善2名への対処方針：UIの改修とマニュアル補足を実施予定。」
変換ルール: 全対象者の結果を「Pass/Fail」で一覧化する。要改善がある場合は対処方針もセットで書く。要改善を隠すより、対処方針を添えた方が信頼性は上がる。
NG4：「手動計測KPI」（形骸化パターン）
「KPI：各担当者が業務開始から完了までの時間をストップウォッチで計測し、日報に記録する。」
ストップウォッチで計測して日報に記録する——これは現場に新たな業務を追加することだ。
改善活動のために業務が増えるという矛盾が生じる。計測が面倒になれば記録が途絶え、データが取れなくなる。これが「形骸化」の典型的なメカニズムだ。
OKサンプルは計測を自動化する。
「KPI：システムのログイン記録とタスク完了スタンプ（自動記録）から処理時間を算出。担当者の手作業は不要。」
変換ルール: KPIは「システムから自動取得できる数字」を選ぶ。手動計測を求めるKPIは計測設計を見直す。現場に測定の手間を強いると、必ず形骸化する。
NG5：「金額換算なし」（数字止まりパターン）
「事前準備時間が90分から45分に短縮されました。削減率50%。目標の60分以内を達成しています。」
「45分短縮」「50%削減」は改善の事実を示している。ただし、これは決裁者が判断に使う情報ではない。
決裁者が最も知りたいのは「で、結局いくら削減できたの？」という金額（円）だ。時間削減をコスト削減（円）に換算しないと、追加投資の承認根拠にならない。数字はあるのに金額換算がない——これが「数字止まりパターン」だ。
OKサンプルは金額まで踏み込む。
「事前準備時間が90分→45分に短縮（50%削減）。45分×時給2,500円×月間対応件数40件×担当者数5名＝月間375,000円相当のコスト削減。年間換算：約450万円。」
変換ルール: 「時間削減」を「金額換算（ROI換算）」に変換する公式がある。削減時間（分）÷60×時給（円）×月間件数×人数＝月間削減額（円）。この計算を1行添えるだけで、報告書の説得力は別次元になる。
検証内容の設計段階からKPIの選び方については【テンプレあり】業務改善提案書「検証内容」の書き方と設計手順で解説している。
5つのNGに共通する根本原因——「読み手が2人いる」という設計欠如
5つのNGに共通する根本原因は「検証結果の読み手が2人いる」という設計視点の欠如だ。決裁者（ROIを求める）と現場メンバー（再現性を求める）は、検証結果に求めるものがまったく違う。この前提を持たずに報告書を書くと、どちらの読み手にも刺さらない内容になる。
NG5つを並べてみると、一見バラバラに見える。でも根っこは1つだ。
検証結果に「読み手が2人いる」という事実を意識していないこと——これが共通する構造的な原因だ。
僕はこの問題を「2読者設計の欠如」と呼んでいる。検証結果には決裁者向けROI版と実務向け行動基準版の2種類が必要で、1枚の報告書で両方を満たそうとすること自体が構造的な誤りだ。NG5つはすべてこの設計欠如から派生している。
設備メンテナンス企業の案件でこんなことがあった。検証レポートを提出した直後に、決裁者から「で、結局いくら削減できたの？」と言われた。同じ日に現場責任者から「うちのメンバーで本当にできたか確認させてほしい」と言われた。
どちらの反応も正しかった。でもその報告書は、どちらの問いにも答えられる構造になっていなかった。
300社のプロジェクトで責任者・推進者・推進チームと話をする中で、この構造が繰り返し現れることが分かってきた。
決裁者が検証結果に求めているのは「投資を継続・拡大できる根拠（ROI）」だ。現場メンバーが求めているのは「自分たちが本当にできた（再現できた）か」だ。この2つは別の問いであり、1枚の報告書で両方を満たそうとすること自体に無理がある。
NG5つがどちらの読み手の問いを外しているかを整理すると、こうなる。
- NG1・5（「ポエム報告」・「金額換算なし」）→ 決裁者への情報が欠けている
- NG3・4（「cherry-picking」・「手動計測KPI」）→ 現場への情報設計が欠けている
- NG2（「ベースライン欠如」）→ 両方に使えるデータ基盤が欠けている
OKサンプルでは各検証項目のPass/Fail記録と、Go/No-Go判断基準（撤退ライン）を明示することで、2人の読み手両方の問いに応答する構造を作る。
「なんか違う」と言われ続けてきた原因は、能力の問題ではなく設計の問題だった。
書き直しの手順：「決裁者向けROI版」と「現場向け行動基準版」の2層で書く
NGを直す方法は、検証結果を最初から2層に分けて設計することだ。2人の読み手が求める情報がまったく違う以上、「1枚で両方に伝わるはず」という期待を捨てるところから始める。
| 層 | 対象読者 | 目的 | 主な内容 |
|---|---|---|---|
| 決裁者向け（ROI版） | 経営層・決裁権限者 | 投資継続・本運用拡大の承認を得る | 金額換算の効果／2シナリオ／撤退ライン |
| 現場向け（行動基準版） | 現場メンバー・実務責任者 | 本運用への協力合意を得る | 検証内容ごとのPass/Fail／確信の確認 |
2層は別々の文書でも、同じ文書の別セクションでも機能する。書く順番は、①決裁者向け、②現場向け、③定性的な効果（補足）の3ステップだ。
ステップ1：決裁者向けは「3種類の数字＋2シナリオ＋撤退ライン」
効果は必ず3種類の数字で示す（NG1・NG5の対策）。
- 絶対値：事前準備時間 90分→45分（45分短縮）
- 削減率：50%短縮
- 金額換算：45分×時給〇円×月間対応件数×人数 ＝ 月間〇万円相当のコスト削減
さらに承認のハードルを下げるのが「2シナリオ」だ。
- 標準シナリオ：計画どおり全員がPass → 月間〇万円削減 → 〇ヶ月で投資回収
- 保守シナリオ：効果が目標の半分にとどまった場合 → 月間〇万円削減 → 〇ヶ月で投資回収
「最悪でも〇ヶ月で回収できる」という撤退ライン（Go/No-Go判断基準）を示すと、決裁者は「失敗しても傷が浅い」と判断できる。本運用への拡大条件も「検証で設定したKPIの80%以上を達成した場合」のように、事前に数値で決めておく。
ステップ2：現場向けは「検証内容ごとのPass/Fail表」
現場向けは、検証内容ごとに全員の結果をPass/Failで記録する（NG3・NG4の対策）。以下は設備メンテナンス企業での記録例だ。
| 検証内容 | 検証項目 | 結果 | 判定 |
|---|---|---|---|
| フィールドエンジニアが事前準備を1時間以内で完了できること | 準備時間（目標60分以内） | 平均45分 | ✓ Pass |
| 顧客情報にアクセスできる | 3名全員が確認 | ✓ Pass | |
| 顧客運用情報にアクセスできる | 2名確認・1名は検索に時間を要した | △ 要改善 | |
| フィールドエンジニアが現場でエスカレーション前に自己解決できること | 自己解決時間（目標30分以内） | 平均22分 | ✓ Pass |
| モバイル端末でアクセスできる | 3名全員が確認 | ✓ Pass | |
| トラブル現象で検索して探せる | 2名Pass・1名はキーワードの工夫が必要 | △ 要改善 | |
| メンテナンスサポートが一次回答できること | 一次回答の判断時間（目標15分以内） | 平均11分 | ✓ Pass |
時間などの数値は、ログイン記録やアクセス履歴のようにシステムから自動で取れるものを使う。「△ 要改善」は隠さず、対処方針とセットで書く。
ステップ3：定性的な効果は補足資料にする
「探す時間が減ってストレスが減った」のような定性的な効果は、検証結果のメインにしない。5段階の満足度アンケートなどを検証の前後で取り、「3.2→4.1」のように数値にして、ROIの補足として添付する。ここでも検証前のアンケートを取り忘れると比較できない。
本運用に移る前に、現場の合意を2点確認する
Pass/Fail表を共有したら、「報告」で終わらせず「合意の取得」として2点を確認する。①検証の結果に納得しているか、②本運用に範囲を広げてもKPIが改善できると確信を持っているか、だ。
設備メンテナンス企業の案件では、この場で「トラブル現象での検索精度を上げてほしい」という意見が出た。本運用の前にシステムを改善したことで、現場の抵抗なく全拠点に展開できた。なお、新しい仕組みが定着してKPIが安定するまでには3〜6ヶ月かかる。検証から3ヶ月で効果が出ないことだけを理由に失敗と判断しない。
提出前に使える「検証結果」の書き方セルフチェック
通る検証結果には3条件が必ず揃っている。①Beforeデータ（ベースライン）の取得、②金額換算（ROI換算）、③全対象者のPass/Fail記録——この3点を提出前に確認する。
NG5選を踏まえると、「通る検証結果」には必ず揃っている3条件がある。①ベースライン（Beforeデータ）の取得、②金額換算（ROI換算）による効果提示、③全対象者のPass/Fail記録と要改善対処方針——この3点だ。
提出前に以下のチェックリストで確認してほしい。1つでも×があれば、提出前に修正する。
- [ ] チェック1：Beforeデータと比較可能なAfterデータが数値で示されているか
→「感想」「〜と思われる」「〜しました」という文末が残っていないか確認する
- [ ] チェック2：改善効果が「金額（円）」に換算されているか
→「時間削減」「件数削減」だけで終わっていないか。「月間○万円削減」まで書けているか確認する
- [ ] チェック3：全対象者のPass/Fail一覧があるか
→「うまくいった事例」だけでなく、「要改善」の項目とその対処方針が記載されているか確認する
このチェックリストは、Go/No-Go判断基準として使える。3点をクリアした報告書は、決裁者にも現場にも「この内容なら判断できる」という状態を作る。
業務改善提案書の「期待する効果」を2層構造で書く方法は業務改善提案書「期待する効果」の書き方｜却下される5つのNGと決裁者・現場の2層KPI（実例つき）で解説している。
まとめ
今回紹介した5つのNGパターンを振り返る。
- NG1「ポエム報告」：数字なし・感想のみ
- NG2「Beforeデータなし」：改善前を記録していない
- NG3「cherry-picking」：成功例だけを抜き出す
- NG4「手動計測KPI」：現場に計測負荷をかけて形骸化する
- NG5「金額換算なし」：時間削減で止まって円に換算しない
5つはすべて「読み手が2人いる（決裁者と現場）」という設計視点の欠如から生まれている。セルフチェック3点を通過すれば、最低限この構造的な問題はクリアできる。
次の検証結果提出から、変えられる。
今すぐできる最初の一歩は2つだ。検証を始める前にBeforeデータを記録すること、そして検証内容ごとのPass/Fail表のフォーマットを用意しておくことだ。
業務改善提案書の他の項目の書き方は業務改善提案書の書き方【構成と通し方を完全解説】で確認できる。