プロジェクト計画書（５）
続いては、コミュニケーション計画について記述していきます。
この章の内容については、品質管理ほど難しいものではありませんが、重要な内容となります。
多くのプロジェクトが失敗する原因の一つにコミュニケーションミスが挙げられます。
これはお客様とのコミュニケーションだけではなく、内部メンバーとのコミュニケーションなども含まれます。
特に、小規模プロジェクトでは、要員も少なく管理工数も限られているため、コミュニケーションのフローやルールを明確にせず曖昧なまま管理しているケースが散見されます
たしかに小規模でも中規模と同様の管理をすることは難しいと思いますが、プロジェクト成功のために最低限のルールを定義しておきましょう。
本サイトで提供する各種テンプレートをご利用いただければある程度管理の効率化が図れると思いますので、ぜひご活用ください。
３．コミュニケーション計画
本章では、以下の内容を記述します。
参考
- 会議体、コミュニケーションツール
- 各種管理（課題管理、品質管理、コスト管理、進捗管理、仕様管理）報告のルール、様式、報告ルートなど
3-1.会議体
まずはプロジェクトの会議体を定義します。
プロジェクトの規模や特性から必要な会議体を定義して、お客様をはじめ関係各社様とのスケジュール調整を実施します。
最近では、プロジェクトのキックオフを含め、すべてリモート会議で完結してしまうプロジェクトも出てきております。
開催方法については、WEBの場合は、WEB会議システムを誰が用意して、招待するかなどあらかじめ決めておきましょう。
会議は必ず、目的と役割、資料/成果物は明確に定義しておきましょう
目的が曖昧な会議や、こういう会議も必要かもしれないというのは時間の無駄になることが多いので注意が必要です。
画像はクリックすると拡大表示されます。
会議体一覧のサンプルは、以下のリンクからどうぞ。
-
-
参考会議体一覧（テンプレート）
本記事では、Creative Content Lab Tokyo（クリエイティブコンテンツラボトウキョウ）が作成した会議体一覧のテンプレートをご提供しております。 プロジェクト発足時にプロジェクト内で ...
続きを見る
3-2.コミュニケーションツール
続いて、プロジェクトで利用するコミュニケーションツールの定義を行います。
お客様や関係各社とのコミュニケーション方法として検討するべきは、まずは会議体での利用するWEB会議システムがあります。
①会議システム
Webex、Microsoft Teams、ZoomやGoogleなどお客様と協議の上、利用するものを決定しましょう。
会議では、資料の共有やシステムの画面操作を説明することが多いため、画面共有の機能は必須となります。
②進捗管理ツール
進捗管理では、redmineやbacklog等のサービスのガントチャートなどを使って管理したり、Excelなどでの管理を行うことがありますが、
どのように進捗を可視化し、管理・推進していくのかを合わせて定義しましょう。
③文書管理ツール
文書管理については、redmineやBacklogを使って、コミュニケーション、進捗、文書管理を同時に行うプロジェクトも多いと思います。
お客様によっては、お客様に認めてもらっていないクラウドサービス上に文書をアップロードするのは禁止という場合もありますので、クラウドサービスを利用する場合には、事前にお客様の許可をいただき、文書の管理方針も提示するようにしましょう。
費用や機能をよく比較して、プロジェクトに合ったサービス/プランを検討しましょう
タスク・課題管理については、私もよく利用しているBacklog（バックログ）がお勧めです。
お客様や関係各社とタスク・課題の共有やファイルを共有することができ、プロジェクト管理には欠かせない機能がたくさんあります。
無料でお試しできますので、使ってみたいという方はこちらの記事を参考にしてください。
-
-
参考Backlog（バックログ）を使ってタスクやプロジェクト管理を効率化しよう
Backlogのご紹介 今回は、クリエイティブコンテンツラボトウキョウがお勧めするお勧めのタスク管理ツールであるBacklogをご紹介いたします。 Backlogは単純にタスクを管理するだけではなく、 ...
続きを見る
3-3.課題管理・報告について
次に、課題管理方法や報告ルールについて記載します。
参考
- 報告対象：課題報告対象（業務課題、技術課題、プロジェクトQCDに関する課題）
- 内容：報告対象に対して、具体的にどのような観点、内容で報告するのか定義します。
- 様式：報告様式を定義します。
- 報告ルート：報告ルートをフロー図等で記載。誰から誰に対して報告するのか、誰がレビュー/承認するのか明確にします。
- ※チームメンバー→チームリーダ（内部Review）→PM（内部承認）→お客様窓口→お客様上位層（承認）
3-4.品質管理・報告について
次に、品質管理方法や報告ルールについて記載します。
品質管理に関しては、前の章で具体的にどのような品質管理を行うのか記述しているため、ここでは、主に報告ルールについて記述します。
誰が管理して、どういうルートで報告、承認するのかを定義しましょう。
※報告内容のサンプルは近日公開予定
3-5.コスト管理・報告について
コスト管理（原価）に関しては、請負でプロジェクトを受注した場合には、主に社内のプロジェクト管理として、原価管理を適正に行いプロジェクトが赤字にならないようにコントロールする必要がありますが、要件定義は準委任契約で工数ベースでの請求となるケースも多いと思います。
またアジャイル型の開発で、一貫して工数での費用請求となる場合もあるかと思います。
この場合、お客様は、常に予定していた原価に対して、今予定通り進んでいるのか、超過が発生する見込みがあるのかどうかを非常に気にされます。
適切なコスト管理を行い、可視化することでお客様にも説明しやすく安心していただけます。
そのためには、EVMでの管理が一番適しているかと思います。EVMとは、Earned Value Management(アーンドバリューマネジメント)の略称です。
プロジェクトの原価（主に人件費）で進捗管理をする手法となります。プロジェクトマネジメント手法の一つとなります。
EVMの具体的な管理方法については、別途説明しますが、プロジェクトのコストの現状と将来の見込みを正しく早期に把握し、適時お客様へ報告するための方法を定義しておきましょう。
3-6.進捗管理・報告について
次は、プロジェクトの進捗管理・報告ルールに関しての内容となります。
プロジェクト計画の段階では、プロジェクトの進捗管理に関して、どのような管理手法でどのように報告するか検討しましょう。
基本的には、お客様視点で考え、まずはマスタスケジュールに対して、遅延が発生していないかを第一に報告するようにしましょう。
マスタスケジュールについて変更が必要な場合は必ず関係各社含め、遅延の原因と対策（リカバリー策）を提示し、その上で、マスタスケジュールの変更の必要性を説明し、各社調整の上、合意ができたら変更可能となります。
自社の都合で勝手に変更して、事後報告すると大きな問題となりますので特に注意しましょう！
報告ルート等に関しては、コスト管理や品質管理と同様となります。
※報告内容のサンプルは近日公開予定
3-7.要求仕様管理（変更管理）
最後は、要求仕様の管理・報告に関しての計画を記載します。
要求仕様は、お客様から提示されるRFP以外にも要件定義工程でユーザへヒアリングしている最中にも追加や変更が発生するため、まずはプロジェクト開始段階で要求仕様の一覧を作成しておき、要件定義フェーズ中でもそれを活用して、追加・変更を管理するようにしましょう。
追加・変更の場合には、いつ誰がどういう理由で追加・変更となったのか経緯がわかるようにしておくことが重要です。ま
た都度追加・変更が発生していることを週次の定例会でお客様に提示し、共通認識を持ったうえで進めることが重要となります。
くれぐれも勝手に追加・変更と判断して、最後にこの分の金額が追加となりますというような事後報告だけはしないように気を付けましょう。
お客様はその追加・変更も含めて今の金額（工数）の中でやってもらえると思っていたという認識齟齬が発生し、問題かするケースが多いです。
（最悪の場合、訴訟にまで発展するケースもあります）
要求仕様の管理については、いろんな管理方法があると思いますが、ここではExcelテンプレートを使った管理手法をご紹介します。
画像はクリックすると拡大表示されます。
まず整理にあたっては、ある程度業務やシステム単位で領域を定義するところから始めましょう。
領域ごとにそれぞれ担当者が異なり、利用するシステムも異なってくるはずです。
領域の定義が完了したら、それぞれの担当者へのヒアリング内容やRFPの内容に基づき、現状の課題・問題点を抽出します。
そのあとは、課題・問題点に対する対策や改善効果（費用対効果を具体的に定量や定性的な観点とすること）を記載します。
そのあとは、業務への影響度や優先度の定義等を検討しますが、これは要件定義フェーズ以降でも構いません。
まずこの時点でお客様からヒアリングした要求仕様がもれなく記載されていることが重要となります。これをベースとして、要件定義を実施し、要求仕様の変更や追加、取消などを管理していくことになります。
テンプレートの各項目について記載する内容は以下となります。
参考
- 要求仕様No.：要求仕様を特定するための一意の番号を採番します。プロジェクトによっては、業務領域の識別子をもうけて、識別子＋シーケンスのようにしているところもありますが、プロジェクトに合わせて自由に定義してください。
- 業務領域：業務領域もしくはシステムごとに領域を定義してください。担当者が異なったり、システムの利用が異なるなど、抱えている課題が異なるような単位で定義するとよいでしょう。
- 業務プロセス：業務領域内での大きな業務工程の定義を記載します。通常、業務プロセスごとに発生する課題・問題点は異なります。
- 課題・問題点：各業務プロセスで発生している課題・問題点を記載します。現状どのようになっていて、本来どうあるべきかという視点で考え、現状とあるべき状態の差が課題となります。
- 課題に対する対策：洗い出した課題・問題点に対して、どのようにアプローチするのか、対策を検討しその結果（案）を記載します。フィジビリティ検証や、要件定義を進める中でよりよい対策がないか検討するためのベースとなります。
- 改善効果（費用対効果）：課題に対する改善対策を行った場合に見込まれる改善効果を具体的に定義します。可能であれば定量的に記載し、具体的な数値でどの程度の改善が見込めるのか記載することが望ましいです。難しい場合には、定性的に記載します。
- 業務影響度：課題・問題が業務に与える影響度を選択します。
- 優先度：基本的に対応優先度は、業務へのインパクトが高いものとなりますが、費用対効果を勘案し、[業務インパクトが高いｘ費用対効果の高い]が最優先での対応となります。
- 対応方針：システムでの対応か、業務改善による対応か、両方による対応、もしくは対応不可を判断します。
- 依頼者、依頼日：誰がいつ依頼した内容となるのか、これも重要な情報となるため必ず残すようにしましょう。
- 要求分類：プロジェクト発足時の当初要求なのか、新規要求、要求変更、取消を判断するための項目となります。
- 承認者、承認日：要求仕様の対応方針及び、要求分類（追加、変更、取消）について必ずお客様に承認をいただき、承認者と日付を残すようにしましょう。
要求仕様管理一覧のサンプル（テンプレート）が必要な方は、以下のリンクからどうぞ。
-
-
参考要求仕様管理一覧（テンプレート）
本記事では、Creative Content Lab Tokyo（クリエイティブコンテンツラボトウキョウ）が作成した要求仕様管理一覧のテンプレートをご提供しております。 プロジェクト発足時点でお客様の ...
続きを見る
３．品質計画まとめ
以上でプロジェクト計画におけるコミュニケーション計画に関する説明が終了となります。
以降は、セキュリティ管理や標準化の内容などとなるため、基本的には自社内の管理規定やお客様から提示されている規定に準拠して記載する内容となります。
プロジェクトキックオフや計画段階で資料として記載する内容はこれまでご説明してきた内容が主な記載事項となります。
テンプレートをベースにプロジェクトに合わせてカスタマイズし、自分が使いやすいテンプレートとして保存しておくとよいでしょう。