【プロマネ講座】プロジェクトの特徴を捉える

本noteでは、プロマネ講座として「プロジェクトの特徴の捉え方」を説明します。記事の分類としては「プロジェクト統合マネジメント✕基本概念」です。

なお初めての方はこちらの記事からお読みいただくのをオススメします。
プロジェクトマネジメント講座の全体像

---

◆変更履歴◆
2024.05.23　初版公開

---

プロジェクトの特徴とは何か

マネジメント観点でおさえておきたいプロジェクトの特徴とは、課題やリスクのタネを意味します。一例をあげます。

• 対象業務であるキャンペーン管理は社内に詳しい人がいない

• インフラは顧客のプライベートクラウドを指定されている

• 任命されたプロジェクトマネージャーはオフショア開発が初めてだ

• 連携先システムとの接続テストは環境制約で2週間のみ

これらは全て課題やリスクのタネであり、放置しておくとすくすく成長して問題となってしまうかもしれません。そうなる前に有効な対応策を検討し、プロジェクト計画に反映する必要があります。

特徴を捉えることが計画作成の第一歩

プロジェクトの特徴を各種計画に反映するまでのイメージフローです。

課題やリスクのタネと言いましたが、課題一覧やリスク一覧にだけ反映すればよいわけではありません。対策としてフィジビリティ検証をマスタースケジュールに追加しないといけないかもしれないですし、そのために体制を追加しコストも追加が必要になるかもしれません。何かしら対策をするということはプロジェクト計画全体に影響を与えることになります。

特徴を捉えてマネジメントにメリハリを

特徴を捉えたプロジェクト計画からは、「このプロジェクトはここが危ないからこんな対策をしてうまいこと進めるぜ」というPMの意思を感じます。PMの意思はメンバーにも伝わり、プロジェクトの危ない部分をみんなで注意しながら乗り越えていくので、あまり失敗することがありません。

一方で、特徴を捉えずに作成したプロジェクト計画は、システム構成/スケジュール/コスト/体制図といった資料の束にしか見えず、どこが危ない部分なのか、どこに注力すべきなのかがわかりません。そもそもPMが特徴を捉えきれていないこともあるので、プロジェクトの危ない部分についての対応策が盛り込まれていない場合もあります。このようなプロジェクトは苦戦してしまうことが多いですね。

プロジェクト計画を作成する前にプロジェクトの特徴を捉えるということは、非常に重要であり不可欠なことなのです。

プロジェクトの特徴の捉え方

プロジェクトの特徴は、本来PMがプロジェクト状況をよくみながら一生懸命洗い出すものなのですが、ゼロからやろうとするとなかなか大変です。そこで、特徴の洗い出しに使える基本的な考え方を紹介します。

これはプロジェクトを4つの要素に分解して、それぞれ新規性/特殊性の有無をチェックするというやり方です。新規性/特殊性がある部分はプロジェクトの危ない部分、つまり、プロジェクトの特徴となります。

各要素のチェックポイントを例示します。該当するものが4つ以上になってくると危険信号で、そのプロジェクトはかなり慎重に計画してマネジメントしていかないといけません。

---

業務の新規性/特殊性をチェック

利用者
・対象となる利用者業務の知識は十分あるか
・想定利用者の種類、権限、利用可能機能などに特殊な点はないか
バックオフィス
・対象となるバックオフィス業務の知識は十分あるか
・想定利用者の種類、権限、利用可能機能などに特殊な点はないか
法制度
・対象となる法制度の知識は十分あるか
・対象となる法制度が確定する時期、解釈が確定する時期は問題ないか
・顧客担当者は対象となる法制度を十分に理解できているか

システムの新規性/特殊性をチェック

言語
・使用する言語の知識/実績は十分あるか
・開発標準、コーディングルールは使えるものがあるか
プロダクト
・使用するプロダクトの知識/実績は十分あるか
・標準的ではない使い方をする箇所はないか
インフラ
・使用するインフラの知識/実績は十分あるか
・顧客のセキュリティ標準、インフラ利用標準に不明点はないか
他システム
・初めて接続する他システムはないか
・既存連携先システムでも初めてのインターフェース方式はないか

人の新規性/特殊性をチェック

顧客
・顧客の社内承認プロセス、システム開発ルールは把握できているか
・顧客担当者はシステム開発が初めてではないか
・仕様を確定する権限を持つ者が顧客担当者になっているか
PM
・対象領域（フロント/バック/インフラ）のPM経験があるか
・対象規模のPM経験があるか
・社内承認プロセス、プロジェクトマネジメントルールは理解しているか
PL
・対象領域（フロント/バック/インフラ）のPL経験があるか
パートナー
・対象業務やシステムの開発能力で未確認な部分はないか
・オフショア開発の場合、コミュニケーションルールは合意済みか
・プロジェクト期間中の増員余力はあるか

プロジェクト前提条件の新規性/特殊性をチェック

スケジュール
・プロジェクト期間が極端に短いなどの制約はないか
・テスト環境の都合でテスト期間が固定化されたり制限されたりしないか
・ビジネス的な理由でリリース日が固定化されたり予備日がとれないことはないか
コスト
・ビジネス的な理由で使えるコストに制限がないか
・計画変更時の追加コストについて制限がないか
品質
・他のプロジェクトに比べて品質要求が高くなっていないか
・テスト工程の品質基準を顧客から提示され遵守を求められていないか

---

どうでしょう、自分のプロジェクトの特徴を洗い出すことはできそうな気がしてきたでしょうか。

特徴から計画への反映

プロジェクトの特徴が捉えられたら、あとはそこから課題やリスクを抽出し、対応策をプロジェクト計画に反映するだけです。ここではイメージアップのために、いくつかの例を紹介します。

業務に新規性/特殊性がある場合

システムに新規性/特殊性がある場合

人に新規性/特殊性がある場合

プロジェクト前提条件に新規性/特殊性がある場合

これでプロジェクトの特徴のとらえ方、その特徴をプロジェクト計画に反映するイメージの説明は終わりとなります。プロジェクト計画の作成についてはまた別途説明しますが、計画作成前にプロジェクトの特徴を捉えることの重要性についてご理解いただけたら幸いです。

参考文献/参考サイト

なし