業務改善提案書「体制」で失敗する5つの書き方——承認後にプロジェクトが止まる構造的な原因

業務改善コンサルタントとして300社以上の企業でプロジェクト支援を行ってきた。その経験から言えることがある。体制欄の書き方に共通する5つのNGパターンが、承認後にプロジェクトを止める最大の原因になっている。

顧客先の推進者から、繰り返し聞いた声がある。「上司に提案書を出したら『なんか違う』と言われた」「一旦これで進めようと言われたが、予算の話になると他のプロジェクトが優先されて、この業務改善が動かなくなった」——こういう相談を、僕は何度も積み重ねてきた。

責任者・推進者・推進チームを一同に集めて話を聞いていくと、体制欄の書き方に共通した問題パターンが見えてきた。体制欄を書かなかったから失敗したのではない。「ちゃんと書いた」という感覚があるにもかかわらず、その書き方では達成できないことがある——これが問題の核心だ。

業務改善提案書の全体構成については業務改善提案書の書き方【構成と通し方を完全解説】もあわせて確認してほしい。

よくある「体制」の書き方——業務改善提案書で繰り返される5つのNGパターン

業務改善提案書の体制欄が承認後に機能しない直接の原因は、「個人名」「役割名」「層（6層構造）」という3要素のいずれかが欠けている点にある。 この欠如があると、「部署の誰かがやるだろう」という責任の空白が生まれ、プロジェクトは承認後も動き出さない。以下、5つのNGパターンとそれぞれの構造的な原因、OKへの修正例を示す。

NG1：部署名だけ書いて個人名がない体制

この書き方の問題点は「組織図の転記」に終わっており、誰がプロジェクトに責任を持つかが確定しない点だ。

NGサンプル

推進部門：メンテナンス部（フィールド課・メンテナンスサポート課）
責任者：メンテナンス部長

稟議制度に関する実務知見では、「承認者・関与者の名前が記録されないほど責任の所在が曖昧になる」という構造が繰り返し確認されている。僕はこれを「責任の空白」と呼んでいる。「部署の誰かがやるだろう」という意識が生じた瞬間、体制は実質的に存在しなくなる。

決裁者からすれば「本当に部長が責任を取るつもりがあるのか、それとも部下に丸投げなのか」が判断できない。承認後のキックオフで「誰が窓口？」という質問が出た瞬間、担当者が顔を見合わせる——こういう状況が、この書き方から生まれる。

OKサンプル

責任者：メンテナンス部長　田中◯◯
推進者：フィールド課　課長　鈴木◯◯
推進担当：フィールド課　◯◯、メンテナンスサポート課　◯◯

個人名が書かれると「この人がこのプロジェクトにコミットしている」という証拠になる。決裁者が「承認してよい」と判断できる根拠の一つになる。

個人名の問題が解決しても、次の落とし穴が待っている。名前は書いたが、その人が「何をする人か」が書かれていないケースだ。

NG2：役職はあるが役割名（プロジェクト上の役割）がない体制

名前があっても役割名がないと、メンバーは「呼ばれたから参加する受け身の参加者」のままになる。

NGサンプル

メンテナンス部長　田中◯◯
フィールド課　課長　鈴木◯◯
フィールド課　主任　◯◯
フィールド課　◯◯、◯◯

プロジェクト管理の国際標準である「RACI（Responsible：実行責任者／Accountable：説明責任者／Consulter：相談先／Informed：報告先）」は、PMI（プロジェクトマネジメント協会）が定めるPMBOKガイドをはじめ、世界標準として採用されている。RACIが機能するのは、役職名ではなく「このプロジェクトにおける役割名」が個人レベルで定義されているときだけだ。

役職名はその人の「会社内の立場」を示すが、このプロジェクトで「何をする人か」は示さない。課長が推進者なのか、単なる承認ルートの一人なのかがわからない。役割名がなければ「この課題は自分の範囲だ」という判断軸が生まれない。

OKサンプル

責任者：メンテナンス部長　田中◯◯
推進者：フィールド課　課長　鈴木◯◯
推進担当：
  ◯◯顧客担当：フィールド課　◯◯
  〇〇顧客担当：フィールド課　◯◯
推進メンバー：メンテナンスサポート課　◯◯、◯◯、◯◯

役割名があると「自分は◯◯顧客担当なので、その顧客からの問い合わせは自分が取りまとめる」という自律的な行動が生まれる。「誰に確認すればいいか」も全員に自然にわかるようになる。

名前も役割名もあるのに、それでも動かない体制がある。「誰が・いつまでに・何を」が体制図から読み取れないケースだ。

NG3：「誰が・いつまでに・何を」が体制図から読み取れない

体制欄に人名と役割名があっても、フェーズと期限が紐付いていなければ、承認後に誰も動き出さない。

NGサンプル

プロジェクトチーム：メンテナンス部・情報システム部
　　（各部署より数名参加）
推進スケジュール：別紙参照

PMI（プロジェクトマネジメント協会）が定めるPMBOKガイドでは、プロジェクト失敗要因のひとつとして「実行体制の曖昧さ（誰が・いつまでに・何をするかが不明確）」が挙げられている。僕が支援した現場でも、「ギャップは見えていたのに、誰が・いつまでに・どうやって埋めるかが決まっていなかったため、翌日から誰もそのギャップを追わなくなった」という事態を何度も目にしてきた。

「数名参加」では人数も名前も不明だ。「別紙参照」では誰が何をいつまでにやるかが体制欄から読み取れない。体制図は立派でも、各メンバーが自分の役割を理解していないため、会議で「やった感」が出るだけで実行フェーズに移行しない。

OKサンプル

推進担当（フェーズ1：現状調査）：
  業務フロー調査：フィールド課　◯◯（〇月末まで）
  システム要件整理：情報システム部　◯◯（〇月末まで）
推進担当（フェーズ2：実装）：
  業務ルール設計：フィールド課　◯◯
  システム設定：情報システム部　◯◯

フェーズ別に「誰が・何を・いつまでに」が体制欄から読み取れると、承認後すぐに各自が動き出せる。

名前・役割名・期限が揃っていても、体制図に「現場担当者がいない」ケースが残る。

NG4：経営層・管理者だけで固めた現場不在の体制

管理職とコンサルタントだけで体制を固めると、現場の担当者が「やらされる側」の意識のままになり、改善が定着しない。

NGサンプル

決済者：メンテナンス事業部長　◯◯
責任者：メンテナンス部長　◯◯
推進者：フィールド課　課長　◯◯
外部支援：コンサルタント　◯◯

PMBOKガイドおよび業務改善の実務において、プロジェクトが定着しない原因として「現場を無視したトップダウンの押し付け」が繰り返し記録されている。僕が関わった現場でも同様のパターンを何度も確認してきた。現場担当者が体制に組み込まれていない場合、「勝手に決められた」「実態に合わない」という拒絶が生まれ、導入したルールやシステムが形骸化する。

実務上の業務フローの抜け漏れが後から発覚し、スケジュールとコストが膨らむリスクもある。管理職だけで見えていなかった現場特有の手順が、後になって「実はこの工程も必要だった」と判明するパターンだ。

OKサンプル

決済者：メンテナンス事業部長　◯◯
責任者：メンテナンス部長　◯◯
推進者：フィールド課　課長　◯◯
推進担当：
  フィールド課　◯◯（現場業務フロー担当）
  メンテナンスサポート課　◯◯（現場連携担当）
推進メンバー：フィールド課　◯◯、◯◯、◯◯
外部支援：コンサルタント　◯◯

現場担当者・現場メンバーが体制図に名前で載っていることで「自分たちが決めた計画だ」という当事者意識が生まれる。

最後のNGパターンは、名前も役割も層も揃っているが、リソースの現実が見えていないケースだ。

NG5：既存業務を考慮しない過剰アサイン体制

全員が「兼務」と記載された体制は、誰もこのプロジェクトを優先できない構造を明示しているに等しい。

NGサンプル

推進者：フィールド課　課長　鈴木◯◯（通常業務との兼務）
推進担当：
  フィールド課　◯◯（通常業務との兼務）
  メンテナンスサポート課　課長　◯◯（通常業務との兼務）
推進メンバー：各課より数名（兼務）

決裁者からすれば「本当にこれが動くのか」という疑問が生まれる。「一旦これで進めよう」と承認を得ても、予算の話や決裁者への説明になると「他のプロジェクトが優先」されて、この業務改善が止まる——こういうケースが現場で繰り返される。

OKサンプル

推進者：フィールド課　課長　鈴木◯◯
  └ プロジェクト稼働時間：週◯時間（フェーズ1：◯月〜◯月）
推進担当：フィールド課　◯◯
  └ プロジェクト専任（フェーズ1期間中：通常業務は◯◯へ引き継ぎ）
推進メンバー：各課より◯名（月次ミーティング参加＋週◯時間稼働）

稼働時間や期間を体制欄に書くことで、「このプロジェクトにどれだけのリソースが確保されているか」が可視化される。決裁者が「実現可能な体制か」を判断できるようになり、承認後の優先度が下がりにくくなる。

業務改善提案書「体制」のNGをOKに変える——3つの記載原則

体制欄をOKに変える最短の方法は、「名前を書く」「役割名を書く」「6層で書く」の3原則を守ることだ。 300社以上の支援で確認してきたこの法則を、僕は「体制欄の3要素モデル」と呼んでいる。5つのNGパターンはすべて、この3要素のいずれかが欠けていたことで発生している。

原則1：名前を書く

決済者・責任者・推進者・推進担当・推進メンバー・関連部門担当の全員の個人名を書く。役職だけでなく個人名まで記載することで「この人がコミットしている」という証拠になり、決裁者が承認を判断しやすくなる。「この名前が体制欄にある」という事実が、丸投げでなくコミットの証明になるのだ。

原則2：役割名を書く

役職名ではなく「このプロジェクトにおける役割名」を書く。「推進担当」「◯◯顧客担当」のように、プロジェクト固有の役割を定義することで、メンバーが自分の担当範囲を自律的に判断できるようになる。

体制欄に名前と役割名を書いた提案書を配布したとき、翌日にあるメンバーが「自分は◯◯顧客担当なので、その顧客からの問い合わせは自分が取りまとめます」と自律的に動き始めた。誰かに指示されたわけではない。体制欄を見て、自分の役割を自分で定義したのだ。役割名が「自分の仕事の境界線」を教えてくれる。

原則3：6層で書く

体制欄の記載を始める前に、僕が支援現場で使ってきた「6層体制モデル」で抜け漏れを確認する。

決済者 → 責任者 → 推進者 → 推進担当 → 推進メンバー → 関連部門担当

この6層を上から順に確認してから記載を始めると、「現場担当者が入っていない」「関連部門の窓口が不明」という問題の大半が事前に解消できる。特にNG4（現場不在の体制）はこの6層チェックを行うだけで防げる。

体制欄を名前と役割名で書くべき理由については業務改善提案書の「体制」で名前を書くべき理由｜組織図との違いと当事者意識の設計原理で詳しく解説している。

体制欄の書き方チェックリスト——業務改善提案書の提出前に確認すべき5項目

業務改善提案書の体制欄を提出前に確認すべき5項目は、「個人名」「役割名」「現場担当者の有無」「全員の名前」「稼働リソース」だ。 この5項目が揃って初めて、体制欄は「承認後にプロジェクトが動き出す設計図」として機能する。

• [ ] 決済者・責任者・推進者の全員に個人名が書かれているか
• [ ] 推進担当・推進メンバーに役職名だけでなく「役割名」が書かれているか
• [ ] 現場担当者・現場メンバーが体制図に含まれているか
• [ ] ワーキンググループのメンバー全員（「数名」ではなく個人名）が記載されているか
• [ ] 稼働時間・専任／兼務の区別が体制欄から読み取れるか（または別紙スケジュールと紐付いているか）

体制欄が確認できたら、次は検証内容の設計に移る。【テンプレあり】業務改善提案書「検証内容」の書き方と設計手順で記載方法を確認してほしい。

まとめ

今回紹介した5つのNGパターンを整理すると、こうなる。

• NG1：部署名のみで個人名がない（→ 責任の空白が生まれる）
• NG2：役職名はあるが役割名がない（→ 受け身の参加者になる）
• NG3：誰が・いつまでに・何をするかが不明（→ 承認後に誰も動かない）
• NG4：経営層・管理者だけで現場が不在（→ 形骸化する）
• NG5：兼務前提の過剰アサイン（→ 他のプロジェクトに優先される）

NGをOKに変えるための「体制欄の3要素モデル」は、名前・役割名・6層構造の3つだ。

体制欄を正しく書いた提案書は、承認された瞬間にすでにプロジェクトが動き出す準備ができている。体制欄の書き方を変えれば、次の提案書は違う結果になる。