記事を書いてる人：あまみ るい
業務改善提案書のテンプレートをダウンロードしたとき、「対象の範囲」という欄を見て手が止まった経験がある。
「部門名を書けばいいのか」「役割まで書くのか」「業務フローも必要なのか」——何を、どこまで書けばいいかが、どのテンプレートにも書いていないからだ。
実際、テンプレートに記載されているのは「対象業務・対象部署」という欄名だけで、それ以上の説明はない。迷うのは当然である。
僕がコンサルとして工場設備の開発・メンテナンス企業を支援したとき、「対象の範囲」に部門名だけが書かれた提案書を見たことがある。
部門長によるレビューで、「開発部門はどうするのか」「営業のエスカレーション対応はどうするのか」という指摘が次々と出てきた。「これは今回の対象か」「あれは含めるのか」という議論が終わらず、提案書の本題にたどり着けなかった。
あの場にいた担当者の表情は、今でも覚えている。
「対象の範囲」には、書くべき4つの要素がある。それを知っていれば、あの議論は起きなかった。
業務改善提案書の全体構成については、業務改善提案書の書き方【構成と通し方を完全解説】で解説している。この記事では「対象の範囲」に絞って説明する。
- 「対象の範囲」には「①対象の部門と役割」「②業務の全体概要」「③使用するシステム・情報」「④対象外」の4要素を書く
- 「対象外」を明示することで、上司からの指摘を「今回の改善に含めるか、別プロジェクトで扱うか」に仕分けられるようになる
- この欄の目的は決裁者の投資判断ではなく、部門長との方針合意——目的を正しく理解するだけで書くべき内容が決まる
業務改善提案書「対象の範囲」に書く4つの要素
まず前提を整理しておく。
「対象の範囲」は、決裁者（経営層）に投資を判断させるための欄ではない。部門長と方針を合意するための欄である。
部門長が「自分が責任を持って推進できる範囲か」を確認できることが、この欄の目的だ。
そのためには、次の4つの情報が揃っている必要がある。
- 誰が対象か（部門と役割）
- 何をしているか（業務の全体概要）
- 何を使っているか（システム・情報）
- 何は含まないか（対象外）
よくある「部門名だけ書いた提案書」と「4要素を書いた提案書」を比べると、この違いは明確になる。
| 項目 | NG（部門名だけ） | OK（4要素） |
|---|---|---|
| 部門と役割 | メンテナンス部門 | メンテナンス部門のうち、フィールドエンジニアとメンテナンスサポートの2役割 |
| 業務の概要 | （記載なし） | 現地対応→エスカレーション→回答→記録の4ステップ概要 |
| システム・情報 | （記載なし） | 顧客DB・商品DB・技術DB・メール/チャット |
| 対象外 | （記載なし） | 開発部門・営業部門およびそれらが受けるエスカレーション対応 |
「NGのほうが自分の書き方に近い」と思ったなら、次のステップで書き方を確認してほしい。
業務改善提案書「対象の範囲」の書き方：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で概要を示した業務を詳細化した欄である。
「目的」の書き方については、業務改善提案書「目的」の書き方｜中期経営計画と連動させる実践ガイドで解説している。
提案書全体の構成については、業務改善提案書の書き方【構成と通し方を完全解説】を参照してほしい。