業務改善提案書のテンプレートをダウンロードしたとき、「対象の範囲」という欄を見て手が止まった経験がある。
「部門名を書けばいいのか」「役割まで書くのか」「業務フローも必要なのか」——何を、どこまで書けばいいかが、どのテンプレートにも書いていないからだ。
実際、テンプレートに記載されているのは「対象業務・対象部署」という欄名だけで、それ以上の説明はない。迷うのは当然である。
僕がコンサルとして工場設備の開発・メンテナンス企業を支援したとき、「対象の範囲」に部門名だけが書かれた提案書を見たことがある。
部門長によるレビューで、「開発部門はどうするのか」「営業のエスカレーション対応はどうするのか」という指摘が次々と出てきた。「これは今回の対象か」「あれは含めるのか」という議論が終わらず、提案書の本題にたどり着けなかった。
あの場にいた担当者の表情は、今でも覚えている。
「対象の範囲」には、書くべき4つの要素がある。それを知っていれば、あの議論は起きなかった。
業務改善提案書の全体構成については、業務改善提案書の書き方【構成と通し方を完全解説】で解説している。この記事では「対象の範囲」に絞り、よくある書き方のどこが足りないかと、4要素の書き方を完成例つきで説明する。
- よく見かける書き方（部署名だけ・業務の開始点〜終了点・件数や人数）は、部門長との合意に必要な情報が抜けているアンチパターン
- 「対象の範囲」には「①対象の部門と役割」「②業務の全体概要」「③使用するシステム・情報」「④対象外」の4要素を書く。そのまま使える完成例つき
- この欄の目的は決裁者の投資判断ではなく部門長との方針合意。「対象外」を明示すると、上司からの指摘を「今回の改善に含めるか、別プロジェクトで扱うか」に仕分けられる
よくある「対象の範囲」の書き方が部門長に通らない理由：3つのアンチパターン
業務改善提案書の書き方を調べると、「対象の範囲」の記載例として主に3つのパターンが出てくる。
パターン1：5W1HのWhereとして部署名を書く
「○○本部 ○○部 ○○課」と組織図の階層をそのまま書く方法だ。わかりやすいようで、実際には「その部署の誰が、どの業務を担っているのか」が見えない。
パターン2：業務の開始点〜終了点で境界を定義する
「問い合わせ受付から請求書送付まで」のように、業務の始まりと終わりを書く方法だ。範囲を示す意図は正しいが、「誰が」「何を使って」という情報がない。
パターン3：定量的なボリュームを補足する
「月間200件の申請処理」「営業職3名が従事する工程」のように件数や人数を書く方法だ。規模感を伝える目的では有効だが、これだけでは部門長は判断できない。
これらはいずれも「決裁者に投資判断してもらうための書き方」を参考にした例だ。業務の規模感を伝える目的では有効だが、部門長とのスコープ合意には情報が足りない。「誰が対象か（役割）」「業務の流れ」「使うシステム」「対象外」が書かれていないため、レビューのたびに都度確認が必要になる。
よくある書き方を1つのNGサンプルにまとめると、こうなる。
【NG】よくある「対象の範囲」の書き方例
■ 対象部署
第一営業部 営業一課
■ 対象業務
顧客訪問後の「商談報告」および「日報作成」
■ 対象範囲
商談終了後のデータ入力から、上長による承認・CRMへの反映まで。
※月間約120件・営業3名が従事。このNG例の問題は一言で言うと、部門長が「誰が」「どのような流れで」「何を使って」「どこまでが今回の対象か」を判断できないことだ。
業務改善提案書「対象の範囲」に書く4つの要素
まず前提を整理しておく。
「対象の範囲」は、決裁者（経営層）に投資を判断させるための欄ではない。部門長と方針を合意するための欄である。
部門長が「自分が責任を持って推進できる範囲か」を確認できることが、この欄の目的だ。
そのためには、次の4つの情報が揃っている必要がある。
- 誰が対象か（部門と役割）
- 何をしているか（業務の全体概要）
- 何を使っているか（システム・情報）
- 何は含まないか（対象外）
よくある「部門名だけ書いた提案書」と「4要素を書いた提案書」を比べると、この違いは明確になる。
| 項目 | NG（部門名だけ） | OK（4要素） |
|---|---|---|
| 部門と役割 | メンテナンス部門 | メンテナンス部門のうち、フィールドエンジニアとメンテナンスサポートの2役割 |
| 業務の概要 | （記載なし） | 現地対応→エスカレーション→回答→記録の4ステップ概要 |
| システム・情報 | （記載なし） | 顧客DB・商品DB・技術DB・メール/チャット |
| 対象外 | （記載なし） | 開発部門・営業部門およびそれらが受けるエスカレーション対応 |
前の章のアンチパターンに近い書き方をしていたなら、次の4ステップで書き直してほしい。
業務改善提案書「対象の範囲」の書き方：4ステップ
Step 1：対象の部門と役割を書く
部門名だけでは不十分な理由は、1つの部門が複数の業務を担っているからだ。
「メンテナンス部門」と書いても、その中に「フィールドエンジニア」と「メンテナンスサポート」という2つの役割があれば、どちらが今回の改善対象なのかが読む人によって変わってしまう。「自分たちは関係ない」「自分たちも含まれる」という認識のズレは、レビューの場で表面化する。
書き方は「部門名：役割名（その役割の一言説明）」の形式が最もシンプルで伝わりやすい。
■ メンテナンス部門
- フィールドエンジニア：お客様の工場現場で設備をメンテナンスする
- メンテナンスサポート：フィールドエンジニアが対応方法がわからない場合に、
問い合わせを受けて対応方法を回答する役割の説明は、業務の詳細を書く必要はない。「誰に何をする人か」を一文で書くだけで足りる。
自分の部門であれば「○○部 ××課」と置き換えて書けば、そのまま使える形式だ。
Step 2：業務の全体概要を書く
「業務の詳細は別ページの現状の業務フローに書く」ため、このページで書くのは全体概要だけでよい。
読んだ人が「ざっくりこういう流れなのか」と把握できる粒度が目安だ。矢印（→）でつなぐ形式が最も読みやすい。各ステップは「誰が何をする」の一文で書き、補足事項は括弧書きで追記する。
フィールドエンジニアが現地対応
→ 対応方法がわからない場合、フィールドエンジニアからメンテナンスサポートにエスカレーション
※現状は開発部門・営業部門に直接問い合わせるケースも発生している
→ メンテナンスサポートが対応方法を調査し、フィールドエンジニアに回答
→ フィールドエンジニアが現地対応を実施
→ 対応終了後、フィールドエンジニアが対応内容を記録矢印でつなぐだけなので、書くハードルは低い。5〜7行で全体像が伝わる形を目指せばよい。
Step 3：使用するシステム・情報を書く
「システム・情報」の欄には、対象の役割が業務の中で実際に使うものを書く。
デジタルのシステムに限らず、製造現場であれば工具や設備が中心になる場合もある。「今回の改善でどこを変えるか」の検討対象になるものを選んで書けばよい。
- 顧客データベース：顧客情報、設備の設定情報、運用情報
- 商品データベース：商品の仕様書、メンテナンス手順書
- 技術データベース：現地対応のノウハウ
- メール・チャット：エスカレーション履歴書き方は「システム・情報名：その内容（何のデータが入っているか、何に使うか）」の形式で一覧化する。ITシステムだけでなく、紙の帳票や工具が重要な業務であれば、そちらを書いてかまわない。
Step 4：対象外を書く
「対象外」を書くことが、この4ステップの中で最も効果が大きい。
対象外を書く最大の目的は、部門長との合意の境界線を引くことだ。
業務上は関連があっても、部門長の管理外にある組織・業務は対象外として明記する。これを書かないと、レビュー時に「あの部署はどうするのか」という指摘が際限なく続く。
対象外に書くのは「業務上は関係するが、今回の改善では取り上げない組織・業務」である。
- 開発部門・営業部門（部門長の管理外のため）
- 開発部門・営業部門がメンテナンスサポートからエスカレーションを受けて対応する業務「対象外：理由」の形式で1〜3行書くだけで、レビューの議論が格段に整理される。
4要素で書いた「対象の範囲」の完成例
4つのステップで書いた内容を1枚にまとめると、次のようになる。冒頭のNGサンプルと比べると、部門長が「誰が」「どのような流れで」「何を使って」「どこまでが今回の対象か」を一度で判断できることがわかる。
【OK】4要素を使った「対象の範囲」の書き方例
■ 対象の部門と役割
メンテナンス部門
- フィールドエンジニア：お客様の工場現場で設備をメンテナンスする
- メンテナンスサポート：フィールドエンジニアが対応方法がわからない場合に
問い合わせを受けて対応方法を回答する
■ 業務の全体概要
フィールドエンジニアが現地対応
→ 対応方法がわからない場合、フィールドエンジニアからメンテナンスサポートに
エスカレーション（現状は開発部門・営業部門に直接問い合わせるケースも発生）
→ メンテナンスサポートが対応方法を調査し、フィールドエンジニアに回答
→ フィールドエンジニアが現地対応を実施
→ 対応終了後、フィールドエンジニアが対応内容を記録
■ システム・情報
- 顧客データベース：顧客情報、設備の設定情報、運用情報
- 商品データベース：商品の仕様書、メンテナンス手順書
- 技術データベース：現地対応のノウハウ
- メール・チャット：エスカレーション履歴
■ 対象外
- 開発部門・営業部門（部門長の管理外のため）
- 開発部門・営業部門がメンテナンスサポートからエスカレーションを受けて対応する業務情報量は増えるが、4つの見出しに沿って埋めるだけなので難しくない。自分の部門名・役割・システムに置き換えれば、そのまま使える。
業務改善提案書「対象の範囲」のよくあるつまずきと回避策
4つのステップを理解した上で、実務で起きやすい3つのつまずきポイントを整理しておく。
つまずき1：部門名だけ書いて役割を書かない
「メンテナンス部門全体が対象なのか」「一部の担当者だけなのか」が不明になり、部門長から「うちの部門全員の話をするのか」と聞かれる。
回避策はシンプルだ。Step 1で示した「部門名：役割名（一言説明）」の形式で、役割まで必ず書く。
つまずき2：業務の全体概要を省く
部門長が「この改善はどのくらいの業務に影響するのか」をイメージできず、「もう少し詳しく説明してほしい」という返答が来る。提案書の読み合わせが長くなる原因になる。
「現状の業務フロー」は別ページに詳細を書くが、「対象の範囲」には矢印形式の全体概要を必ず入れる。5〜7行程度で足りる。
つまずき3：対象外を書かない
「では開発部門の対応はどうなるのか」「営業からのエスカレーションも変えるのか」という指摘が出るたびに、その場で都度判断することになる。合意の根拠が提案書に残らない。
「業務上関係するが、今回は扱わない」ものを「対象外」として1〜3行書くだけで解決する。上司からの指摘が「今回の改善に取り込む話か、別のプロジェクトで扱う話か」を仕分ける判断軸にもなる。
まとめと次のステップ
「対象の範囲」に4つの要素を書き終えた時点で、提案書全体の「誰に・何を・どこまで・何は含まない」が一枚に収まった状態になる。部門長との合意の土台ができた、ということだ。
工場設備会社のメンテナンス部門での支援を経て、「対象の範囲」を正しく書いた提案書に対する部門長レビューは明らかに変わった。「この範囲で進めよう」「この指摘は別の機会に取り上げよう」という会話が成立するようになり、提案書が議論の地図として機能し始めた。
次に書くべきは「目的」または「現状の業務フロー」だ。「目的」は「対象の範囲」で定めた業務に対して何を達成したいかを書く欄。「現状の業務フロー」はStep 2で概要を示した業務を詳細化した欄である。
「目的」の書き方については、業務改善提案書「目的」の書き方で解説している。
提案書全体の構成については、業務改善提案書の書き方【構成と通し方を完全解説】を参照してほしい。