コミュニケーション計画の書き方とテンプレート｜会議体一覧と報告ルールの例

コミュニケーション計画とは、プロジェクトの中で「誰が・何を・いつ・誰へ・どの手段で伝えるか」をあらかじめ決めて文書にしたものです。 会議の一覧、報告の締め切り、困ったときの相談先が1か所にまとまっていると、参加したばかりの人でも初日から同じ動き方ができます。

この記事では、架空の「社内の備品予約システム刷新」を題材に、計画書の目次、会議体一覧、報告ルール、エスカレーション基準の4点をそのまま使えるひな形として載せます。表はMarkdownと、表計算ソフトに貼れるタブ区切りの両方を用意しました。進捗報告書や議事録の書式そのものには踏み込まず、全体の取り決めに絞ります。

確認環境：Ubuntu 24.04 / Python 3.11.15（判定コードを実行）、Mermaid 11.14.0（@mermaid-js/mermaid-cli と Chromium でフロー図のコードを描画）。

コミュニケーション計画の早見表

コミュニケーション計画書の目次（ひな形）

次の目次をそのまま見出しにして書き始められます。

コミュニケーション計画書

1. この文書の目的と対象範囲
   1.1 目的
   1.2 対象（期間、チーム、関係する部署）
   1.3 関連する文書（プロジェクト計画書、体制図、課題管理表）
2. 関係者と連絡先
   2.1 体制と窓口の一覧
   2.2 不在時の代理
3. 会議体
   3.1 会議体一覧
   3.2 会議の進め方（招集、資料の事前共有、欠席時の扱い）
4. 報告ルール
   4.1 定期の報告
   4.2 随時の報告
5. エスカレーション
   5.1 判定基準（レベル1〜3）
   5.2 連絡の経路と期限
6. 連絡手段の使い分け
   6.1 手段ごとの用途と返信の目安
   6.2 件名・チャンネル名の規則
7. 文書の保管
   7.1 フォルダ構成
   7.2 ファイル名の規則
   7.3 閲覧できる範囲
8. 改訂のルールと改訂履歴

会議体一覧の書き方と記入例

会議体一覧で大切なのは、「入力（持ち寄るもの）」と「出力（決まるもの・残るもの）」を書くことです。この2列があると、会議の前に何を準備し、終わったときに何が残っていればよいかが全員に伝わります。

会議体一覧のテンプレート（タブ区切り）

主催と開催方法の列を加えた完全版です。コピーして表計算ソフトのA1セルに貼ると、列に分かれて入ります。

No  会議体 目的  頻度・時間   主催  参加者 入力（持ち寄るもの）  出力（決まるもの・残るもの）  議事録担当   開催方法
1   運営会議    範囲・費用・日程に関わる判断と、節目の承認   月1回・60分 青木部長（議長）    スポンサー、発注責任者、プロジェクトマネージャー、各リーダー  月次の状況報告、変更の申請、レベル3の課題   承認・差し戻しの記録、判断事項の一覧  PMO担当   対面とオンラインの併用
2   週次定例    進み具合の確認と、チームをまたぐ課題の調整   週1回（火曜10:00）・45分    プロジェクトマネージャー    各リーダー、利用部門の窓口、運用担当  週次の進捗報告、課題管理表、リスク一覧 対応者と期限つきの課題、翌週の予定   各リーダーの輪番    オンライン
3   朝会  当日の作業と困りごとの共有   毎営業日（9:30）・15分  開発チームのリーダー  開発チーム全員 タスクボード  当日の担当、レベル1の課題の対応者   記録はタスクボードの更新で代える    オンライン
4   仕様検討会   画面・機能の仕様を利用部門と決める   週1回（木曜14:00）・60分    設計リーダー  利用部門の窓口、設計担当、テスト担当  仕様の案、質問一覧、試作の画面 確定した仕様、持ち帰り事項と回答期限  設計担当    対面
5   変更検討会   変更の申請を評価し、採否の案を作る   申請があった週（金曜15:00）・30分    プロジェクトマネージャー    設計リーダー、開発リーダー、利用部門の窓口   変更の申請書、影響の見積もり  採否の案（費用・日程が動くものは運営会議へ）  PMO担当   オンライン
6   品質確認会   工程の完了条件を満たしたかを確認する  工程の終わりごと・60分    品質担当    プロジェクトマネージャー、各リーダー、運用担当 レビューとテストの集計、残っている課題 次工程へ進む判断、条件つきの場合は条件と期限  品質担当    対面
7   移行準備会   切り替えの手順と当日の体制を固める   稼働2か月前から隔週・45分  移行リーダー  運用担当、利用部門の窓口、既存の保守担当    移行手順書の案、リハーサルの結果    確定した手順、当日の連絡網   移行担当    オンライン
8   振り返り    進め方の良かった点と改善点を出す    工程の終わりごと・60分    プロジェクトマネージャー    チーム全員   課題管理表、各自のメモ 続けること・変えることの一覧  輪番  対面

会議体を決めるときの判断表

会議の進め方として書いておく取り決め

• 招集は主催が行い、議題と入力資料の場所を前営業日までに通知する
• 欠席者は、入力資料への意見を事前にチャットで出す。代理を立てる場合は判断を任せる範囲を伝える
• 決定事項は「決めたこと・担当・期限」の3点で読み上げて確認してから終わる
• 2回続けて議題がない会議は、頻度の見直しを週次定例で相談する

報告ルールの早見表（何を・いつまでに・誰へ・どの手段で）

報告ルールは、締め切りを曜日と時刻まで書くと、守れたかどうかを誰でも判断できます。

保管場所の列を加えたタブ区切り版です。

No  何を  いつまでに   誰が  誰へ  どの手段で   保管場所
1   日次の作業状況 毎営業日 9:30 の朝会まで 各担当 チームリーダー タスクボードの更新   タスクボード
2   週次の進捗報告 毎週月曜 17:00  各リーダー   プロジェクトマネージャー    所定の様式を共有フォルダへ   01_報告/週次
3   月次の状況報告 運営会議の3営業日前  プロジェクトマネージャー    運営会議の参加者    資料を共有フォルダへ置きメールで通知  01_報告/月次
4   課題の登録   気づいた当日中 気づいた人   担当リーダー  課題管理表に1行追加  課題管理表
5   リスクの追加・見直し  気づいた週の週次定例まで    各リーダー   プロジェクトマネージャー    リスク一覧を更新    リスク一覧
6   変更の申請   変更検討会の2営業日前 申請者 プロジェクトマネージャー    変更の申請書  03_変更
7   議事録 会議の翌営業日 12:00   議事録担当   参加者と欠席者 共有フォルダへ置きチャットで通知    02_議事録
8   決定事項の周知 決定の翌営業日 プロジェクトマネージャー    関係するチーム全員   チャットの告知用チャンネル   決定事項一覧
9   質問・確認の依頼    回答希望日の3営業日前 依頼者 相手の窓口   質問一覧に登録しチャットで通知 質問一覧
10  障害・不具合の一報   気づいてから30分以内 気づいた人   チームリーダーとプロジェクトマネージャー    電話またはチャットの緊急用チャンネル  課題管理表
11  休暇・不在の連絡    前営業日まで（急な場合は始業前）    本人  チームリーダー チャットと予定表    予定表
12  成果物の完成連絡    完成した当日  作成者 レビュー担当  レビュー依頼の登録   成果物一覧

連絡手段の使い分け

「チャットで決まったことは管理表へ転記する」を1行入れておくと、あとから経緯を探す時間が短くなります。

文書の保管場所とファイル名の例

備品予約システム刷新/
├── 00_計画/        プロジェクト計画書、コミュニケーション計画書、体制図
├── 01_報告/
│   ├── 週次/       20261005_週次報告_開発.xlsx
│   └── 月次/       202610_月次報告.pptx
├── 02_議事録/      20261006_週次定例_議事録.md
├── 03_変更/        CR-012_予約上限の変更.md
└── 04_管理表/      課題管理表、リスク一覧、質問一覧、決定事項一覧

ファイル名は 「日付8桁_会議名または種別_補足」 の順にすると、名前順に並べるだけで時系列になります。

エスカレーション基準（3段階の判定表）

エスカレーションは、担当者の範囲で決めきれない事柄を、決められる人へ早めに上げることです。「何日遅れたら」「どこまで影響したら」を数字と範囲で決めておくと、上げるかどうかで迷う時間がなくなります。

判定のルールは次の3つです。

• 日数と範囲のうち、高いほうのレベルを採る（遅れが2日でも他チームに及ぶならレベル2）
• 見通しが立たなければ1段上げる（レベル1は2営業日、レベル2は次の週次定例まで）
• 迷ったら上のレベルで報告する。報告を受けた側がレベルを下げるのは構いません

レベル 遅れの日数   影響の範囲   報告先 期限  手段  扱う場
レベル1    1〜2営業日  チーム内で吸収できる  チームリーダー 当日中 チャット    朝会
レベル2    3〜5営業日  他チームの作業に及ぶ  プロジェクトマネージャー    翌営業日まで  課題管理表に登録して口頭で補足 週次定例
レベル3    6営業日以上、またはマイルストーンが動く    範囲・費用・稼働日、利用者、情報の取り扱いに及ぶ    運営会議の議長 当日中 電話（つながらなければチャットで要点を残す）  臨時の運営会議

判定の流れ（Mermaidのフロー図）

flowchart TD
    S[問題に気づく] --> Q1{利用者への影響や<br>情報の取り扱いに<br>関わるか}
    Q1 -- はい --> L3[レベル3<br>当日中に運営会議の議長へ電話<br>臨時の運営会議を開く]
    Q1 -- いいえ --> Q2{マイルストーンが<br>動くか<br>または遅れが6日以上か}
    Q2 -- はい --> L3
    Q2 -- いいえ --> Q3{遅れが3日以上か<br>または他チームの<br>作業に影響するか}
    Q3 -- はい --> L2[レベル2<br>翌営業日までにプロジェクトマネージャーへ<br>課題管理表に登録し週次定例で扱う]
    Q3 -- いいえ --> L1[レベル1<br>チームリーダーへチャットで共有<br>朝会で対応を決める]
    L1 --> C{2営業日で<br>見通しが立ったか}
    C -- いいえ --> L2
    C -- はい --> E[課題管理表を更新して完了]
    L2 --> C2{次の週次定例までに<br>見通しが立ったか}
    C2 -- いいえ --> L3
    C2 -- はい --> E
    L3 --> E

上から順に「影響が大きいもの」を先に確かめる形にしています。遅れの日数だけを先に見ると、日数は小さいが利用者に関わる事柄を見落としやすいためです。

判定をコードで確かめる

基準があいまいでないかは、短いコードに書き直すと確かめられます。次の judge.py は、上の判定表をそのまま関数にしたものです。

"""エスカレーションのレベルを判定する（遅れの営業日数と影響の範囲から）。"""


def level(delay_days: int, cross_team: bool = False,
          milestone: bool = False, user_or_info: bool = False) -> int:
    if user_or_info or milestone or delay_days >= 6:
        return 3
    if delay_days >= 3 or cross_team:
        return 2
    return 1


CASES = [
    ("画面の修正が1日遅れ", dict(delay_days=1)),
    ("単体テストが2日遅れ、結合テストの開始に影響", dict(delay_days=2, cross_team=True)),
    ("API開発が4日遅れ", dict(delay_days=4)),
    ("データ移行の準備が6日遅れ", dict(delay_days=6)),
    ("遅れは1日だが受け入れ開始日が動く", dict(delay_days=1, milestone=True)),
    ("遅れはないが利用者の予約データに誤り", dict(delay_days=0, user_or_info=True)),
]

for text, args in CASES:
    print(f"レベル{level(**args)}: {text}")

実行結果：

レベル1: 画面の修正が1日遅れ
レベル2: 単体テストが2日遅れ、結合テストの開始に影響
レベル2: API開発が4日遅れ
レベル3: データ移行の準備が6日遅れ
レベル3: 遅れは1日だが受け入れ開始日が動く
レベル3: 遅れはないが利用者の予約データに誤り

2行目は遅れが2日でも他チームに及ぶのでレベル2、5行目は遅れが1日でもマイルストーンが動くのでレベル3になります。文章の基準をコードにできるなら、人が読んでも判定がぶれにくい基準だと言えます。

エスカレーションの一報に書く5項目

【レベル2】API開発の遅れ（予約登録）
1. 何が起きているか：予約登録APIの開発が計画より4営業日遅れている
2. 影響：結合テストの開始（10/19）が最大3営業日ずれる見込み
3. 原因（分かっている範囲）：承認の流れの仕様が10/2に変わり、作り直しが出た
4. 対応案：A案 担当を1名追加して10/19開始を守る／B案 開始を10/22に変更する
5. 判断してほしいことと期限：A案・B案の選択を10/8の週次定例までに

事実・影響・対応案・判断の期限がそろっていれば、受けた側はすぐに動けます。原因が分かっていなくても、分かっている範囲で先に送ります。

作り方の手順（5ステップ）

運用でつまずきやすい点と直し方

よくある質問

Q. 小さなプロジェクトでも計画書は必要ですか？ A. 3〜5人の規模なら、会議体一覧・報告ルール・エスカレーション基準の3つの表を1ページにまとめるだけで十分に役立ちます。目次の全章を埋める必要はありません。

Q. コミュニケーション計画はプロジェクト計画書の一部にしてもよいですか？ A. 構いません。プロジェクト計画書の1章として書き、表が大きくなったら別紙にする形が扱いやすいです。別の文書にする場合は、互いの文書名を「関連する文書」に書きます。

Q. エスカレーションの日数はどう決めればよいですか？ A. 余裕日数（遅れても全体の終了日が動かない日数）を目安にします。余裕が5日ある工程なら、その半分ほどの3日でレベル2、余裕を使い切る6日でレベル3、という決め方ができます。

Q. 利用部門や他社の人にも同じ計画書を渡しますか？ A. 会議体一覧と報告ルールのうち相手に関わる行と、エスカレーションの窓口を抜き出した版を渡すと読みやすくなります。チーム内の朝会や休暇連絡の行は外します。

まとめ

• コミュニケーション計画は「誰が・何を・いつ・誰へ・どの手段で」を決める文書。目次のひな形から書き始められる
• 会議体一覧には入力と出力を書く。準備するものと、終わったときに残るものが伝わる
• 報告ルールの締め切りは曜日と時刻まで。守れたかどうかを誰でも判断できる
• エスカレーションは遅れの日数と影響の範囲で3段階。高いほうのレベルを採り、見通しが立たなければ1段上げる
• 基準をコードに書き直せるかで、あいまいさを点検できる
• チャットで決まったことは管理表へ転記し、保管場所とファイル名の規則をそろえる
• キックオフで説明し、1か月後に見直す。体制が変わったら連絡先と代理を更新する

株式会社RJC ― SI事業・SES事業・AI駆動開発。RJCは一緒に成長を楽しめる会社です。