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