システム導入においてプロジェクトをマネジメントすることが重要であることは言わずと知れたことですが、初めてシステム導入プロジェクトに参画した方だと、実際の具体的なアクションを想像するのは難しいと思います。そこで、本ブログではシステム導入の初心者の方向けに、何をどうやって「プロジェクトをマネジメント」していくのかをご紹介させていただきます。
プロジェクトマネジメントとは、「プロジェクトをどのように進めればゴールにたどり着けるのかを詳細に計画・管理をしていくこと」です。プロジェクトの具体的なゴールを定義づけ、そのゴールにたどり着くために「いつまでに、誰が、何を、どのように、実施するのか」を明確にし、プロジェクトを成功に導いていくための管理をしています。
ステークホルダー全員が同じ目的とゴールを共有しないと、各々が考えるゴールに向かって業務を遂行してしまうため、プロジェクトの失敗につながる可能性があります。
計画・タスクを策定することで、必要なリソースが具体的になりスケジュールの進捗管理や役割分担がスムーズでできるようになります。
プロジェクトを円滑に進めるために、コミュニケーションを密にとることが重要です。進捗状況やトラブルをいち早く認知することにつながります。
役割分担が曖昧であると責任の所在が不明確になる、報告・連絡・相談が遅れスケジュール遅延やリスクは発生し適切な対応策が取れずプロジェクトが失敗する可能性が上がります。
全て計画通りに進むプロジェクトは少ないため、発生する可能性が高いリスク・課題をあらかじめ想定し、発生時に適正な対策を実行できる体制を整える必要があります。
しかし、ただ計画・管理を実施するだけでなく、それらをどうのように定義づけたのかをステークホルダー全員が認識し納得した上で、プロジェクトを遂行する必要があります。そこで必要なのが「プロジェクトマネジメント計画書」です。
プロジェクトマネジメント計画書とは、「プロジェクトを実行、監視、コントロール及び終結する方法を記述した文書」です。もっと簡単に言うと、プロジェクトが間違った方向に進まないようにするための「道しるべ」です。筆者が初めてプロジェクトマネジメント計画書の作成に携わった時、「ここまで詳細に書くのか?!」と驚きましたが、いざプロジェクトが進行していくとそれでも足りずスケジュール通り進まないということがありました。経験豊富な人が集まり、皆が同じ志の元プロジェクトが進むのだから、詳細に計画をしなくてもいいだろうと高を括っていると後々痛い目に合うことがあるので、計画を甘く見ないことが重要です。
では、計画書の中身はどのような構成でどのくらいの粒度で書くべきなのでしょうか。
プロジェクトマネジメント計画書を作成する上で参考になるのが「PMBOK(Project Management Body of Knowledge)」です。PMBOKは通称「ピンボック」とよばれ、プロジェクトマネジメントに関する知識を体系的にまとめられている参考書のようなものです。現在ではプロジェクトマネジメントの標準として世界各国に浸透しています。そこで本ブログでは、PMBOKをベースとした計画書を解説します。
計画書は大きく「計画」と「管理」に分けられます。特に「管理」では、立てた計画の管理方法を詳細に記していきます。
1-1.プロジェクトの背景目的
1-2.スケジュール
1-3.実施体制
1-4.工程定義
1-5.会議体
1-6.成果物
2-1.コミュニケーション管理
2-2.進捗管理
2-3.課題管理
2-4.リスク管理
【1-1.プロジェクトの背景目的】
■目的
プロジェクトメンバー全員のベクトルを合わせるため
■必要性
プロジェクトにおける目的が明確かつメンバー全員で理解していないとプロジェクトのゴールがずれてしまい、失敗する確率が高くなります。
■内容
・プロジェクトに至った経緯
・現状の課題と目指すべき姿
・プロジェクトの方針
【1-2.スケジュール】
■目的
・プロジェクトの全体スケジュールを示し、どのように進んでいくかを明確化するため
・スケジュールの進捗状況を可視化し納期までに納品するため
■必要性
誰がいつ何をやるのかを明確に示すことによって、遅れや漏れが生じていないか確認ができるのでトラブルなどの予期せぬ事態になった際にいち早く対応できるようになります。
■内容
・マスタスケジュール
※マスタスケジュールとは?
プロジェクトの開始から完了まで見通したプロジェクトの全体像を示す「基本計画書」のことです。このマスタスケジュールはあくまで全体を俯瞰することが目的なので詳細なスケジュールを記載されていません。スケジュールに沿った詳細なタスク設計は、WBS(Work Breakdown Structure)で行われています。WBSでは、プロジェクトの目標中間地点である「マイルストーン」に合わせてタスクの詳細タスクを設計します。
【1-3.実施体制】
■目的
プロジェクトにおける業務範囲と責任の所在を明確にするため
■必要性
役割と指揮命令系統を定義することで、コミュニケーションルートが明確かつスムーズになるためプロジェクト運営不良による失敗を防ぐことにつながります
■内容
・体制図
【1-4.工程定義】
■目的
各工程内容を共通化し、成果物定義の認識相違を防ぐため
■必要性
ステークホルダーによって考え方は異なるので、何もしなければ各工程における成果物の定義にもズレや認識違いが生じます。プロジェクトを進行する上で認識齟齬や認識違いは失敗するリスクにつながるので未然に防ぐ必要があります
■内容
・各工程(キックオフ、要件定義、構築、結合テスト、受入テスト、データ移行、教育、プレ運用)の実施事項、内容、成果物、担当者を定義
【1-5.会議体】
■目的
ステークホルダーとのコミュニケーション方法を決め、プロジェクト運営を円滑に進めていくため
■必要性
プロジェクトを進行していく中で、たくさんの課題や欠陥が発生する可能性がある。それらを解決するためには、ステークホルダー同士のコミュニケーションが不可欠です。また、今後どのような会議があり、誰が参加する必要があるのかを計画段階で周知させることでプロジェクトへの参加意識を高めることにもつながります
■内容
・会議名、会議毎のアジェンダ・開催頻度・参加者を定義
【1-6.成果物】
■目的
成果物が完成するタイミングと成果物内容を定義することで、ステークホルダー同士の認識齟齬をなくすため
■必要性
成果物はプロジェクトにおけるお客様への納品物となるため、プロジェクト活動にかかる費用の対価とも言えます。クライアントに成果物を納品し、費用請求時に納品物が違うとならないように、計画の段階で認識合わせする必要があります。
■内容
・成果物と成果物の納品工程・作成社・承認先・掲載内容・承認基準を定義
【2-1.コミュニケーション管理】
■目的
ステークホルダーとのコミュニケーション方法を決め、プロジェクト運営を円滑に進めていくため
■必要性
プロジェクトを進行していく中では、たくさんの課題や欠陥が生じる可能性があります。それらを解決するためには、ステークホルダー同士がコミュニケーションをとることが不可欠です。そこでコミュニケーション方法やルートを定めることでスムーズに行えるようにする必要があります
■内容
・コミュニケーション種別(オンライン会議、報告連絡相談、プロジェクト管理)毎のコミュニケーションツール、コミュニケーションルートを定義
【2-2.進捗管理】
■目的
管理方法やルールを計画することで、プロジェクト進行時のステークホルダーの認識齟齬をなくすため
■必要性
作業計画と実際尾作業状況のズレを把握するためにどのように管理をするかをあらかじめ計画することで、誰もが迷わずに進捗の管理を行えるようになります
■内容
・スケジュール進捗管理とタスク管理毎の使用するツール、作成者、追加・更新・削除作業担当者、閲覧者を定義
【2-3.課題管理】
■目的
管理方法やルールを計画することで、プロジェクト進行時のステークホルダーの認識齟齬をなくすため
■必要性
プロジェクトで発生する課題を、誰もが見えるようにしていないと対応漏れやステークホルダー間の認識齟齬につながり、結果プロジェクト失敗につながってしまいます。
■内容
・課題管理方法、課題管理者毎の課題スコープ、運用方法、確認頻度を定義
【2-4.リスク管理】
■目的
リスク管理ルールを計画し、リスクが顕在化を防ぐため
■必要性
リスクが顕在化すると課題になります。前項の通り、課題はプロジェクト失敗につながるため、リスクが顕在化しないよう常にウォッチする必要があります。リスクの管理方法を設定しないと管理がおざなりになり放置されてしまうため、問題にすら気づかなくなり非常に危険な状態になります。
■内容
・リスク特定からリスク監視の工程ごとの実施内容、管理手法を定義
※リスク管理には一般的に、「リスク特定→リスク分析→リスクアセスメント→リスク対応策→リスク管理」のながれで実施されます。リスク特定では、その名の通り、プロジェクトで想定されるリスクを幅広く挙げます。挙げたリスクの想定される要員を分析します。リスクの要因をふまえリスクの優先度を測定します。優先度はプロジェクトに合わせて定義することが重要です。その後ドライバープレイヤーごとにとるべき対応策を検討し実施します。実施後、リスクに変化がないか継続にウォッチします。完全にリスクが顕在化しなくなった時点でリスク監視が終了されます。
計画時完璧だと思える計画書を作成しても、想定よりも定義づけが甘く認識齟齬が発生し、課題につながるケースがあります。筆者がPMOとして参加したプロジェクトでは、ステークホルダー同士でWBSに求める粒度が異なり、認識齟齬が発生しケジュール進捗管理が出来なくなりました。これは「言わなくてもこれぐらいの粒度で作成してくれるだろう」という甘さから起きたことだと考えられます。冒頭でも記述した通り、「こんなに細かく書くのか?!」というくらいがプロジェクト成功につながると実感しました。ステークホルダーへ向けてプロジェクトの解像度が高くなる計画書を作成することが重要です
参考資料
セールスフォース標準化推進ラボ(2024)『プロジェクト計画書の作成(3)k悪工程の作業計画~成果物/納品定義』
oboegakIT(2024)『プロジェクトマネジメントのコミュニケーション計画とは?会議体の種類とポイントを解説』
プロマネ研究室(2024)『プロジェクト計画書の作成方法・目次構成と記載するポイント』
CrewWorks(2024)『プロジェクト管理におけるドキュメント管理とは?書類の種類と実施方法・ツールを解説』
CrewWorks(2024)『文書管理システムのおすすめ13選を紹介!』
三井住友銀行(2024)『プロジェクトマネジメントとは?必要性や注意点、具体的手法についてご紹介』
アーツアンドクラフツConsulting & Solution事業部/アナリスト