プロジェクト管理の全体解説 – 立上げ／計画／実行／コントロール／終結 - プロマネ研究室

・プロジェクトマネジメントとは
・プロジェクト立ち上げ
・プロジェクト計画
　- プロジェクト計画書を作成する理由
　- プロジェクト計画書に記載するもの
　- プロジェクト計画書の承認
　- キックオフミーティング
・プロジェクトの実行
・プロジェクトの監視・コントロール
・プロジェクト終結

プロジェクト計画

プロジェクト計画書は、プロジェクトの設計書です。
計画作成する範囲はプロジェクトにより異なりますが、計画書は必ず作成します。
作成方法の詳細は、別記事「プロジェクト計画書」でも解説しています。

プロジェクト計画書を作成する目的

プロジェクト計画書とは、プロジェクト遂行して目的達成するための設計書です。

コーディング作業で例えます。
一人で作る程度の簡単なツール程度であれば設計書は不要に感じるかもしれません。
ところがプログラムを複数人で作りこむ場合、仕様、製造ルール、作業順序などを他の作業者に説明したり、個別に指示をだす必要があります。
それらを全体整合取りながら、全て口頭で説明するのは困難です。
そのためプログラムを作成する前に設計書を作成し、何をどのように作るのか明確化します。

プロジェクト計画書も同様で、開発メンバやクライアントといったステークホルダーが同じゴールを目指し、ルールや作業順序を全員が理解するために必要です。
ステークホルダーが自分たちで好き勝手にルールを作ったら、チームとして機能しないですよね。

プロジェクト計画書を必要に感じていない人は、次のような経験をしていることが多いです。

いつも同じメンバで作業している（要員交代が少ない）
長く同じ現場で作業している（作業ルールが変わらない）
小規模案件が多い

改めて計画を作成しなくても、何となくプロジェクトを進められる経験をしていると、計画書作成が無駄に感じることがあります。
それで上手くいくのであればよいですが、ステークホルダーの交代、または現場の状況変化がおきたとき、途端にトラブルになる場合があります。
第三者がプロジェクト内容を理解するためにも、プロジェクト計画書は必要です。

プロジェクト計画書に記載するもの

プロジェクト計画書に記載する内容について説明します。
ここで挙げる項目を全て計画作成できれば、どのプロジェクトでも対応することができるでしょう。
しかし小規模案件のプロジェクトまで全部を作成するのは作業量的に難しいこともあります。

そこで小規模案件でも必ず作成する項目については（必須）をつけています。
※無いとプロジェクト着手できないものを対象としています

プロジェクト概要（必須）

プロジェクトの主要な要素をまとめた説明であり、第三者が読んでプロジェクトの目的や背景を理解するための情報を記述します。
プロジェクト名称、作業期間、契約形態などの基本情報を記載するのですが、プロジェクト難易度、要求されるセキュリティレベルを記載することもあります。

またプロジェクトの目的や狙い、背景について記述します。
これはプロジェクトの承認者だけでなく、開発に参画するメンバに対しても必要な情報です。
ステークホルダー内で目的が意思統一されることで、求めていたゴールにたどり着くことができます。

システム構成図（必須）

システムのシステムや機能間の全体像と、それらの疎結合を明確にします。
他システムとの連携を表現するため、仕様検討やテスト実施の調整でも使用します。
ここでは詳細な構成情報ではなく、全体の概要が理解できれば十分です。

このシステム構成図がないと何を作るのかイメージすることは難しく、メンバ間にプロジェクト説明することも、作業スコープを決めることもできません。

プロジェクト開始時点で決まっているべきですが、どうしても未確定の部分がある場合は、未確定であることと、確定時期を明記します。

体制図（必須）

体制図は、誰が、どのような役割なのか表現するための資料です。
この体制図には、チームや人ごとに役割を設定するのですが、それを線で結ぶことで指揮命令系統を示します。
この指揮命令系統がはっきりしていないと、別々の人から異なる指示が出る可能性があります。
それでは現場が混乱してプロジェクト活動に支障が出ます。
責任の所在を明確にするためにも重要なドキュメントです。

スケジュール・ベースライン（必須）

スケジュール・ベースラインは、マスタスケジュールのことを指します。
プロジェクトの工期やマイルストーンを設定し、プロジェクト進捗と比較する基準となるスケジュールを作成します。

このマスタスケジュールはプロジェクト計画に直結します。
WBSなど詳細スケジュールであればタスクの入れ替えなどで変更することはありますが、マスタスケジュールを変更する場合はプロジェクト計画変更という扱いになります。
上位層の承認が必要になってくるので、頻繁に変更することは出来ません。

詳細は別記事「スケジュール・ベースライン」を参照

スコープ・ベースライン

プロジェクトや工程における作業範囲や成果物を定義します。
作成したベースラインと比較して、要件追加や作業追加、仕様変更などの管理を行います。

スコープ・ベースラインを作成するには、ステークホルダーやシステム企画書など要求事項を洗い出して要求事項文書を作成します。
その要求事項を実現するために行う作業や成果物、受入基準、制約・前提条件を作成します。
ここで定義したスコープが変更される場合、予算やスケジュールなど様々なプロジェクト計画に影響が出ます。

詳細は別記事「スコープ・ベースライン」を参照

コスト・ベースライン

スコープとスケジュールをもとに、プロジェクトの予算設定を行います。

基本的にプロジェクト全体の予算はプロジェクト開始時点（プロジェクト憲章の作成時）には承認されているものです。
そのため、プロジェクト開始時に承認された予算の中で完了できるようにコストを調整します。

システム開発において、要件定義など工程を進めていかないと具体的な予算を出すことは出来ません。
そのため、受託開発の場合は要件定義や基本設計などの上流工程では準委任契約として、スコープが明確化されてから請負契約にすることが一般的です。

詳細は別記事「コスト・ベースライン」を参照

リスクマネジメント計画

プロジェクトのリスクを洗い出し、リスク回避策と発生時のアクションプランを計画します。
あらかじめ想定するリスクを抽出し、予防策、発生時の対処について計画を立てます。
プロジェクト開始されたらリスクが発生していないか観測し、発生時は計画に則り対処します。

ちなみにリスクとはプロジェクトに影響を与える不確実な事象を指すものであり、PMBOKでは悪いこと（ネガティブリスク）だけでなく良いこと（ポジティブリスク）もリスクとして扱います。
しかし、システム開発では悪い事象が発生したときのリカバリが重要になってくるので、ネガティブリスクを中心にリスク対策を計画します。

詳細は別記事「リスクマネジメント計画」を参照

品質マネジメント計画

プロジェクトや成果物の品質を確保するため、基準値と品質の作り込み方法を作成します。

品質とはプロジェクトで作成した成果物について、不具合がない等の精度を問うことが多いですが、それだけでなくプロジェクト運営それ自体の品質も問われます。
プロジェクトの進行プロセスに問題があれば、QCDを達成することが難しくなります。
それだけでなく作業効率が悪くなったり、チーム内の不和につながることもあります。

品質マネジメントでは、成果物を作成すること、またプロジェクト運営が正しく行われていることを確認し、必要あれば是正するように計画、運用します。

詳細は別記事「品質マネジメント計画」を参照

資源マネジメント計画

人材、設備、製品ライセンスなど、人的資源と物的資源の両方を管理します。
プロジェクトを進めるために必要な資源を特定し、確保やマネジメントを行うための計画・実行を行います。

またプロジェクトチームを効率よく運用するために、チーム育成を行ったり、チームメンバで対立が発生した場合の対処も含まれます。

詳細は別記事「資源マネジメント計画」を参照

コミュニケーションマネジメント計画

ステークホルダー間の情報連携を円滑にするため、会議体やコミュニケーションルールを策定します。
ステークホルダーが増えるほど、指数関数的に調整事項が増えるので、規模が大きくなるほど重要度が増します。

もしメンバ間で認識齟齬や情報連携不足が発生していると感じる場合、運用ルールを見直して情報を円滑に連携できる仕組みを構築します。

詳細は別記事「コミュニケーションマネジメント計画」を参照

調達マネジメント計画

外部業者からサービスや製品を調達したり、要員調達、システム開発を外部発注する場合のプロセスや契約締結に関する計画を策定します。

システム開発を発注する場合、提案のプロポーサルから入札、契約など一連の流れも計画を立てます。

ステークホルダーエンゲージメント計画

各ステークホルダーの期待値やプロジェクト関与状態を確認し、プロジェクト遂行するための関係構築する方法を定義します。
プロジェクトでは様々なステークホルダーがおり、必要な人が十分にプロジェクトへ参画しているかチェックします。
その参加が不十分と判断されるなら、より関与を深めてもらうための対策を取ります。

ちなみにステークホルダーの管理では、人の特徴や性格、考え方などセンシティブな情報を取り扱うこともあるため、不用意に人目につかないように管理するなど注意が必要です。

詳細は別記事「ステークホルダーエンゲージメント計画」を参照

プロジェクト計画書の承認

プロジェクト計画書を作成したら上司やプロジェクト責任者など、承認者に説明します。
ここでは技術論などプロジェクトの詳細ではなく、次のポイントを説明します。

プロジェクトの背景や目的
予算やスケジュールの根拠
体制図
システム構成（概要説明）
想定リスクと対策

承認者の関心はプロジェクト成功に向けてどこまで計画が練られているかにあります。
マネージャとして経験が浅い場合、承認者から多くの指摘を受けるかもしれません。
これは経営や上位マネジメントの視点で考えるべき点が不足していることが多いです。
それら指摘の背景や理由を理解することで、マネジメント能力を成長させる良い機会となります。

しかし、中には技術論にフォーカスしたり、文書の書き方や体裁など細かい点ばかり指摘する人もいます。
その結果、本来チェックすべき計画の方針確認が不足する場合があります。
その時は別の識者にチェックしてもらいましょう。