記事を書いてる人：あまみ るい
検証を終えたとき、担当者の顔には安堵と疲労が混ざった表情が浮かんでいた。
何週間もかけて現場に入り、数字を取り、メンバーにも協力してもらった。報告書もまとめた。数字もある。現場の声もある。「これで大丈夫なはずだ」と思いながら上司に提出した。
返ってきた言葉は、「なんか違うんだよね」だった。
何が違うのか、具体的には教えてもらえない。「もう少しヒアリングしてみて」と言われるが、何をヒアリングすればいいのかも分からない。時間をかけて書き直しても、また同じ反応が返ってくる。プロジェクトだけが止まっていく。
僕はこういう場面を、300社以上のコンサルティングの現場で繰り返し見てきた。
多くの場合、問題は「書き方が丁寧かどうか」ではない。検証結果の報告書には、見落とされがちな構造的なNGパターンが存在する。そのパターンのどれかに当てはまっているから、何度書き直しても「なんか違う」が繰り返される。
業務改善提案書の書き方全体については業務改善提案書の書き方【構成と通し方を完全解説】を参照してほしい。本記事では「検証結果」の書き方に絞り、よくあるNGパターンとOKサンプルを解説する。
- 検証結果が却下される原因は「書き方」でなく「5つのNGパターン」のどれかに当てはまっている。自分のパターンを特定することが最初の一歩。
- 5つのNGに共通する根本原因は「読み手が2人いる（決裁者と現場）」という設計視点の欠如にある。
- NGサンプルをOKサンプルに書き直すための具体的な変換ルールは、各パターンごとに1つ存在する。
業務改善提案書「検証結果」の書き方でやりがちな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人の読み手両方の問いに応答する構造を作る。
「なんか違う」と言われ続けてきた原因は、能力の問題ではなく設計の問題だった。
この2層構造の具体的な書き方については業務改善提案書「検証結果」の正しい書き方―決裁者と現場の両方を動かす2層構造で詳しく解説している。
提出前に使える「検証結果」の書き方セルフチェック
通る検証結果には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パターンを振り返る。
- NG1「ポエム報告」：数字なし・感想のみ
- NG2「Beforeデータなし」：改善前を記録していない
- NG3「cherry-picking」：成功例だけを抜き出す
- NG4「手動計測KPI」：現場に計測負荷をかけて形骸化する
- NG5「金額換算なし」：時間削減で止まって円に換算しない
5つはすべて「読み手が2人いる（決裁者と現場）」という設計視点の欠如から生まれている。セルフチェック3点を通過すれば、最低限この構造的な問題はクリアできる。
次の検証結果提出から、変えられる。
2層構造の正しい書き方は業務改善提案書「検証結果」の正しい書き方―決裁者と現場の両方を動かす2層構造で解説している。
業務改善提案書の他の項目の書き方は業務改善提案書の書き方【構成と通し方を完全解説】で確認できる。