業務改善提案書を作っていて、「検証内容」の欄だけ手が止まる——。
僕が関わってきた現場でも、そういう場面を何度も見てきた。
「試してみます」「効果を確認します」と書いても、決裁会議で止まる。ネットで調べて、スモールスタート、Before/After比較、KPI設定と、勧められている書き方を丁寧に書いても「なんか違う」と返される。
「もっと具体的に」と言われるが、何をどう書けばいいか分からない。
そのまま〆切だけが近づいてくる。
この記事では、工場設備のメンテナンス部門への実際の提案書で使った検証表を、そのままコピーして使える形で3セット提供する。
フィールドエンジニアとメンテナンスサポートの2役割に対応した、「検証項目・判定基準・担当・測定方法」の4列構成だ。あわせて、勧められている書き方がなぜ決裁者の承認根拠にならないのかを、6つのNGとOK例で示す。
- 「検証内容」は、解決策が「推進者の想定」ではなく「数値で確認済みの事実」であることを決裁者に示すために書く
- 検証項目は役割別のKPIと1対1で対応させ、「自動で測れる定量指標」だけを設定する
- 感想で書く、Afterだけ測る、KPIと無関係な項目を入れる、撤退ラインのないスモールスタート、熟練者だけの検証、他部署への影響を見ない。この6つのNGを避けると、決裁者の不安を消す検証内容になる
業務改善提案書の検証内容テンプレート（コピペ用・全3セット）
以下は、工場設備メンテナンス企業への提案書で実際に使用した検証表だ。
役割ごとに3セット用意しているので、自社の状況に当てはめて使ってほしい。
フィールドエンジニアの事前準備検証
検証内容: フィールドエンジニアが訪問前に必要な情報を1時間以内に準備できること
| 検証項目 | 判定基準 | 担当 | 測定方法 |
|---|---|---|---|
| 事前準備の所要時間 | 1時間以内 | FE本人が記録 | 作業開始〜完了の時刻メモ |
| 顧客情報にアクセスできる | ○/× | FE本人が確認 | システムログイン記録 |
| 設備情報にアクセスできる | ○/× | FE本人が確認 | システムログイン記録 |
| 顧客の運用情報にアクセスできる | ○/× | FE本人が確認 | システムログイン記録 |
| 設備のメンテナンス履歴にアクセスできる | ○/× | FE本人が確認 | システムログイン記録 |
フィールドエンジニアの現場自己解決検証
検証内容: 現場でエスカレーション前に自己解決できること
| 検証項目 | 判定基準 | 担当 | 測定方法 |
|---|---|---|---|
| トラブル対応の自己解決時間 | 〔判定基準は自社で設定〕分以内 | FE本人が記録 | 問題発生〜解決時刻メモ |
| モバイル端末でシステムにアクセスできる | ○/× | FE本人が確認 | ログイン成否の記録 |
| トラブルの現象で情報を検索できる | ○/× | FE本人が確認 | 検索実施の有無を記録 |
| エスカレーション履歴を検索・参照できる | ○/× | FE本人が確認 | 参照成否の記録 |
メンテナンスサポートの一次回答検証
検証内容: サポート担当が一次回答または2次エスカレーション判断を行えること
| 検証項目 | 判定基準 | 担当 | 測定方法 |
|---|---|---|---|
| 一次回答または2次エスカレーション判断の所要時間 | 〔判定基準は自社で設定〕分以内 | サポート担当が記録 | 問い合わせ受信〜回答時刻の記録 |
| エスカレーション履歴を参照できる | ○/× | サポート担当が確認 | 参照成否の記録 |
「〔判定基準は自社で設定〕」と書いた箇所は、次の章で決め方を解説する。
業務改善提案書の検証内容：KPI・役割別・Go/No-Go基準の設計手順
テンプレートをそのままコピーしても、判定基準の数値が空欄のままでは使えない。
ここでは4つの手順で、自社の検証内容を仕上げる方法を解説する。
手順の全体像
- 「期待する効果」のKPIと対応させる
- 役割ごとに検証表を分ける
- 判定基準（Go/No-Go基準）を数値で決める
- 経験者・未経験者の両グループで検証する
KPIと対応させる
検証内容と「期待する効果」のKPIが噛み合っていないと、検証しても何も証明できない。
たとえば、KPIが「現場でのエスカレーション件数を月30件→15件に削減」であれば、検証すべきは「現場でエスカレーション前に自己解決できるか」だ。
KPIと直接つながらない検証項目は、どれだけ丁寧に設計しても決裁者には響かない。
まず「期待する効果」のKPIを書き出し、それぞれに対応する検証内容を1対1で割り当てるところから始めてほしい。
「期待する効果」の書き方については業務改善提案書「期待する効果」の書き方｜却下される5つのNGと決裁者・現場の2層KPIで解説している。
役割ごとに検証表を分ける
フィールドエンジニアとメンテナンスサポートは、検証内容も判定基準も測定方法もすべて違う。
一枚の検証表にまとめようとすると、担当者が「自分がやるべき項目はどれか」を探す手間が生まれる。
それだけで検証の精度が落ちる。
役割ごとに検証表を分けることで、各担当者が自分の確認項目だけを見ればいい状態になる。
ただし注意点が一つある。
現状の業務フローで困っていない役割は、検証に関わらせなくていい。
ただ、新しい業務フローで効果が得られるかどうかは、全役割で確認する必要がある。
判定基準を数値で決める
「使いやすいか」「スムーズにできるか」という判定基準は使えない。
決裁者が求めているのは「1時間以内に情報準備できた」か「できなかったか」という、二択で答えが出る基準だ。
テンプレートで言えば、「事前準備の所要時間」の判定基準は「1時間以内」。
「アクセスできる/できない」は○/×の2択。
どちらもシステムログや自己記録から取得できる数字を選ぶのが基本だ。
これがGo/No-Go判断基準であり、決裁者に「検証がNGなら横展開しない」という撤退ラインを示すことでもある。
撤退ラインが明示されていると、決裁者は「最悪でも傷が浅い」と判断でき、承認の心理的ハードルが下がる。
経験者・未経験者の両グループで検証する
経験10年のベテランFEだけが「1時間以内に準備できた」としても、それは解決策の効果ではなく個人の経験値かもしれない。
経験5年以上と経験2年未満に分けて検証表を記入させ、判定基準の達成率を比較する。
両グループで同等の結果が出れば、解決策の再現性が証明できる。
「誰がやっても同じ結果が出る」という証拠が、属人化しない業務改善の根拠になる。
業務改善提案書の検証内容でやりがちな6つのNGパターン
テンプレートを使っても、設計を間違えると検証は機能しない。よく勧められる書き方も、決裁者の問いに答えていなければNGになる。決裁者が知りたいのは「この改善で何が、どれだけ変わるのか」「効果が出なかったときにどこで止めるのか」の2点だ。実際の提案現場で繰り返し見た6つのNGを、OK例と対比して整理する。
NG1：感想・主観で書く（ポエム型）
NGの例：「システム導入後、現場から『作業が楽になった』『探す手間が減った』との声が上がっており、効果が確認されました」
「楽になった」は人によって基準が違う定性指標で、決裁者への報告材料にならない。感想を集めることを「検証」と呼んでいる時点で、何も証明していない。
OKの例：「事前準備の所要時間：1時間以内（○/×）。担当者本人がシステムログで確認」のように、二択か数値で判定できる定量指標だけを置く。
NG2：改善後しか測らない（After一本型）
NGの例：「システム導入後3ヶ月で計測したところ、事前準備の所要時間は平均45分でした」
導入前の数字がなければ、「元々45分だったのでは？」と言われた瞬間に反論できない。どれだけ良い結果が出ても「比較できない」で終わる。
OKの例：「検証開始前（〇月〇日）に現状の事前準備時間を担当者5名で実測。平均2時間10分と記録済み」のように、ベースライン（改善前の実測値）を先に記録する。計測の予定は提案書のスケジュール欄に組み込んでおく。
NG3：KPIに関係しない検証を入れる（迷子の検証型）
NGの例：「新システムの操作性についてアンケートを実施し、満足度80%以上を目標とします。また画面デザインへの評価も収集します」
KPIが「エスカレーション件数を月30件→15件に削減」なら、検証すべきは「エスカレーション前に自己解決できるか」だけだ。操作性や満足度はKPIと関係がなく、項目が増えるほど「それで何が証明されたのか」がぼやける。
OKの例：「KPI（エスカレーション件数削減）に直結する『現場自己解決時間』のみを検証項目とする」。KPIと1対1で対応しない項目は削る。
NG4：「スモールスタートで試します」で終わる（宣言型）
NGの例：「フェーズ1として3ヶ月間、営業部門で試験運用を実施します。効果が確認できれば全社展開を検討します」
「効果が確認できれば」の基準がない。何の数値がどこまで改善すれば「確認できた」なのかが不明で、効果が出なかったときにどこで止めるのかも分からない。決裁者の不安は「効果が出なかったときに損失がどこまで膨らむか」であり、この書き方ではそれが消えない。
OKの例：「フェーズ1終了時に『事前準備1時間以内の達成率80%以上』が確認されない場合は横展開しない」のように、撤退ラインを数値で書く。最悪でも傷が浅いと分かれば、承認の心理的なハードルが下がる。
NG5：熟練者だけで検証する
NGの例：「経験10年のベテランエンジニア3名で試験運用し、全員が1時間以内に準備できた」
ベテランは慣れで解決できてしまう。結果は解決策の効果ではなく、個人の能力の評価になる。
OKの例：経験5年以上と経験2年未満の両グループで実施し、判定基準の達成率を比べる。差が大きければ、解決策が熟練者向けになっている可能性があるので設計を見直す。
NG6：他部署への影響を見ない（部分最適型）
NGの例：「当部門の入力作業を廃止したことで、当部門の月間工数を10時間削減しました」
自部門の工数は減っても、その作業が他部署（経理部など）の確認作業に移っているかもしれない。決裁者が見ているのは組織全体のコストで、一部門の数字だけではない。
OKの例：「サポートチームへの問い合わせ件数に増加がないかを同期間で計測する」のように、他部署への副作用を検証範囲に入れる。
提出前に確認する「検証内容」6点チェックリスト
提案書を提出する前に、次の6点を確認してほしい。
- [ ] 「感じる」「思う」「声」といった定性指標が検証項目に入っていないか
- [ ] 改善前のベースラインを実測し、記録しているか
- [ ] 検証項目が「期待する効果」のKPIと1対1で対応しているか
- [ ] 「何の数値がどの値に達したら横展開、未達なら撤退」という条件を書いているか
- [ ] 経験者と未経験者の両方で検証する設計になっているか
- [ ] 自部門の改善が他部署に負荷を移していないかを確認する項目があるか
6点すべてが通れば、決裁者が承認の根拠にできる検証内容になる。
まとめ：業務改善提案書の検証内容は「決裁者の不安を消す設計書」
「検証内容」の欄は、単なる「試してみる」の記録ではない。
「推進者の想定ではなく、数値で確認した」という証拠が、決裁者の承認と実務メンバーの協力を得る土台になる。
テンプレートの検証表に「判定基準・担当・測定方法」を埋めることで、誰が何をどう確認するかが明確になり、検証が形骸化しない。スモールスタートもBefore/AfterもKPI設定も、それ自体は間違いではない。ただ、「何の数値がどうなれば横展開か、撤退か」が書かれていなければ、決裁者の不安を消す材料にはならない。
まずはこの記事のテンプレートをコピーして、自社の役割と数値に書き換えるところから始めてみてほしい。
検証内容と連動する「期待する効果」の設計については業務改善提案書「期待する効果」の書き方｜却下される5つのNGと決裁者・現場の2層KPIで解説している。
提案書全体の構成については業務改善提案書の書き方【構成と通し方を完全解説】を参照してほしい。