プロジェクトマネジメント個人的まとめ
はじめに
プロジェクトの大まかな流れ
１つのプロジェクトの開始から終了までの流れは大きく以下の４つの段階に分かれます。この各フェーズで適切な人（プロジェクトの大きさなどにもよりますが、部内の小さいなプロジェクトであればラインの上司などです。以降では、分かりやすく上司と言い換えます）への承認をもらい、次のフェーズへ進みます。
- 立ち上げ：プロジェクトの大まかな内容に関し上司の合意を得ます
- 計画：プロジェクトの目標を達成するための具体的な計画を作成します
- 実行：プロジェクトの進捗をモニターし、生じた課題に応じてQCD（Quality, Cost, Delivery）やスコープをコントロールします
- 完了：事後の振り返りを行い、成果物に関して検証し、次のプロジェクトに役立てます
立ち上げフェーズ
立ち上げ期の目的は、「プロジェクトの大まかな内容に関し上司の合意を得る」ことです。
ここではプロジェクトの成果物のサービスやものがニーズがあるのかの大まかな検討を行ったのちに、「よしやろう」となれば上司へ提案しプロジェクトの内容に関し合意を得ます。細かい作業の手順や日程、担当分けなどは計画段階で行いますので、承認先の上司が意思決定できるレベルの大まかな内容を決めれば十分です。
また、プロジェクトでは新しい独自性のある取り組みを実施するので、ユーザに直接フィードバックをもらうまでは本当にニーズがあるか分からないことの方が多いです。そのため、不確実な要素が多い立ち上げ期では詳細を詰めずに、あくまで大きな概要の合意をとり、計画段階や実行段階で変更する可能性が高いあくまで目安の内容であることを上司に理解してもらうことも重要です。
具体的には以下の２つの作業を行います。
- 事前に大まかなニーズの検討を行う
- プロジェクトの大まかな内容に関し適切な人の合意を得る
1. 事前に大まかなニーズの検討を行う
ニーズの検討自体を１つのプロジェクトや計画/実行フェーズとして実施することもあると思いますが、事前に簡単な内容でも良いので想定ユーザーなどの関係者（ステークホルダー）へヒアリングを行いましょう。 各関係者の意見を分析することで背景に関する理解を得て、少しでも説得力のある背景、目的を描けるはずです。
2. プロジェクトの大まかな内容に関し適切な人の合意を得る
合意を取る内容としては以下の内容を盛り込みます。プロジェクトの大きさや内容を考えて必要であれば追加/削除します。
- 背景を整理する
- 目的/目標を設定する
- 大まかなスケジュールを決める
- 予算を算出する
- リスクを予測し、対処法を考える
2-1. 背景を整理する
プロジェクトの存在意義を示すチャンスやリスクを事実ベースで整理します。 意義があるテーマを設定できると参画するメンバーの貢献意識も高まります。
プロジェクトを実施することによるチャンスとリスクは様々な観点で整理しましょう。分析のフレームワークとしては、PEST分析、SWOT分析、3Cなどで整理されることもありますが、１つのフレームワークに固執して考えるというよりは既存のフレームワークを参考にしながら複数の視点から整理します。 例えば、組織の強みや弱みや政治、環境、技術、社内事情、顧客、競合他社、組織ミッションなどです。
それらを組み合わせながら、プロジェクトの存在意義（なぜ自分達が取り組むべきなのか？）を示します。
2-2. 目的/目標を設定する
目的には、最終的にプロジェクトが実現したい姿/状態を示します。 目指している状態を分かりやすい端的な文章と絵や動画、完成イメージなどを用いて分かりやすい形にします。Tipsのエレベーターピッチなどのツールを使用すると、考えている仮説を分かりやすく端的に伝えることができますし、事前に検証することが可能です。
目的や必要性は関係者が納得でき、自信を持って説明できることが理想ですが、実際は中々浸透しません。企画する際の１回限りで終わらず可能な限り多くのタイミングで必要性や目的を伝え続けましょう。変革のためにはまず認知してもらうことが必要です。
目標に関しても可能な限り具体的な内容を記載しましょう。ユーザーや関係者間で目指している方向性が異なる場合は、後々追加の作業が発生しスケジュールの大きな変更につながります。また、目標は初期目標、中間目標、最終目標のように段階を分けて設定します。これは長すぎるプロジェクトはメンバーのモチベーションを維持できないためです。初期目標が達成できたら、それがどれだけ小さなことであってもそれを一緒に祝いましょう。
また、プロジェクトが扱う範囲が広くなりがちな場合は、やることとやらないこと、後で決めることを明確にしましょう。 ここで上司と合意をとっておくことで、後々鶴の一声で発生する開発をできるだけ避けることができます。
2-3. 大まかなスケジュールを決める
プロジェクトリーダーが勝手なスケジュールを作らないように、この段階でも技術の専門家に軽く相談をして大まかなスケジュールを立てます。また、スケジュールと一緒に上記で作成した初期/中間/最終目標などのマイルストーンも一緒に整理します。ここでは大まかに作ることが重要です。実際の詳細の計画は計画段階や実行段階で明らかになっていきます。そのため詳細の日程は考えるだけ無駄です。
2-4. 予算を算出する
プロジェクトを実施する上で必要だと思われる予算を示します。 プロジェクトの成功基準は「効果＞かかった費用」なので、費用対効果を定量化する必要があります。
費用にはサービス量などの使うお金だけではなく、開発にかかる人の工数なども込みで算出します。また、いくつかフェーズを区切る場合はフェーズごとにかかる費用の概算を出すとより良いです。
2-5. リスクを予測し、対処法を考える
プロジェクト発足段階で考えられるリスクをチームでリスト化してみましょう。 リスクを考える主な観点としては、スコープ、品質、コスト、納期、リソースに対するリスクを考えていきます。また、Tipsの抵抗の6階層やチェンジマネジメントの視点からも考えてみることも役に立ちます。
リスクをリスト化した後に、リスクに影響度、発生確率の２つの基準で優先順位をつけます。特に優先順位が高いリスクに対して対応方法を考えます。対応方法としては、「回避・低減・移転・受容」の4つがあり、ケースバイケースで使い分けます。詳細の手順は計画段階の章で説明予定です。
リスクマネジメントは計画段階や実行段階でも継続的にチームで取り組むものです。立ち上げ期は上司やメンバーと合意しておきたい大きなリスクを中心に考えておくと良いでしょう。
立ち上げ期のまとめ
改めて立ち上げ期の目的は、「プロジェクトの大まかな内容に関し上司の合意を得る」ことです。
上記ではTipsまで含めると大変な内容になってしまいますが、プロジェクトの内容や組織/上司の性質に応じて適宜省略しながら企画書を作成してください。細かい作業の手順や日程などは計画段階で行いますので、承認先の上司が意思決定できるレベルの内容で十分です。
各会社の目標を見ても似たり寄ったりなところを考えてもアイディアや思いつきに価値はないですが、実際に形にしていくための仮説検証の行動に価値はあります。 小さな問題から初めて企画を立ち上げてみるところから始めてみましょう。
計画フェーズ
計画フェーズの目的は、「プロジェクトの目標を達成するための具体的な計画を作成する」ことです。
立ち上げフェーズでは以下の内容が含まれる場合がありました。
- 背景を整理する
- 目的/目標を設定する
- 大まかなスケジュールを決める
- 予算を算出する
- リスクを予測し、対処法を考える
計画フェーズでは立ち上げフェーズと一部重複した内容も含みより具体的な詳細の計画を作成します。そのため、立ち上げ期でどこまで実施しているか次第で以下の内容は省略等してください。計画を策定できたら追加で必要な予算やリソースなどの依頼事項などに対して合意を取るために、再度上司へ相談し承認をとりましょう。
ここでは、以下の内容を含むプロジェクト計画書を作成することを想定します。
- 目的、目標をまとめる
- 大日程の中でマイルストーンを明確にする
- 成果物とスコープを決める
- 要求事項を整理する
- 体制図を作る
- コミュニケーションの取り方を決める
- 作業計画を立てる
- 予算を算出する
- リスクマネジメントを行う
1. 目的、目標をまとめる
立ち上げ期に合意をとった「2. 目的/目標を設定する」をまとめます。目的や必要性を伝えることは関係者のモチベーション向上にも繋がりますし、より多くの関係者に認知してもらえるようにします。計画書のタイミングでも必要性や目的を伝え続けましょう。
2. 大日程の中でマイルストーンを明確にする
立ち上げ期の「2-3. 大まかなスケジュールを決める」で合意をとった大日程とその中にマイルストーンを記載します。マイルストーンは最終的に目指すべき成果物から逆算して日程を決めます。
3. 成果物とスコープを決める
プロジェクトが生み出す成果物が何かを整理します。成果物は、最終的に出来上がる製品やサービスだけでなく、実現されるべき状態なども含まれます。以下の成果物は曖昧な表現だと認識が合わなくなる可能性が高くなるので、可能な限り完了や成功を判断できる基準や内容を具体的に記載します。
- 最終的に出来上がるべき製品やサービス
- 最終的に実現するべき状態
- プロジェクト終了時に始めるべき別のプロジェクトや定常業務
- など
また、プロジェクトでカバーしない内容や技術などをプロジェクトで扱わないもの（スコープ外）としてまとめておきます。この段階でスコープに関して合意を取ることで、プロジェクトに必要なことだけに集中して取り組むことができます。「やらないこと、後で決めること」をリストにまとめておきましょう。
4. 要求事項を整理する
プロジェクトの関係者やプロジェクトにより影響を受ける人、与える人たち、ユーザーなどに根掘り葉掘りインタビューを行うことで、プロジェクトが満たすべき要求事項を整理します。インタビューを行うことでステークホルダーとの認識違いを修正できることもありますし、プロジェクトの存在をいろいろな人に知ってもらうことで支援してくる人や認識していない課題を見つけることができるかもしれません。
要求事項としては以下を考えましょう。それぞれの要求事項が関係者全員が合意しているようにします。
- ビジネス要求事項：組織として解決したい課題
- ステークホルダー要求事項：ステークホルダーからのニーズ
- ソリューション要求事項：上記要求事項を満たす製品やサービスの機能や特長
- 移管および準備状況への要求事項：製品が完成した後の移管する際に必要なもの
5. 体制図を作る
プロジェクトの体制図を作成します。また、体制表と同じ場所に各メンバーの役割、責任、権限を文章としてまとめた表なども整理します。
6. コミュニケーションの取り方を決める
メンバー間や外部の関係者、上司などへの報告の頻度や内容、方法を事前に決めておきます。毎回決める度に調整に時間がかかるので、時間の節約のためにも決めておきましょう。
7. 作業計画を立てる
7-1. WBS
計画はまずWBS（Work Breakdown Structure）でプロジェクトを小さな作業に分解します。作業を階層的に細かく分解することで、１つ１つの作業をメンバーが取り組みやすい粒度にします。
WBSは階層的に作業を分解していきますが、分解の仕方は以下のようないくつか切り口があります。「ユーザーストーリーの各フェーズ」ごとに分けることは、各作業の意義を理解しながら作業を実施することにつながるメリットもあります。また、各切り口ごとの作業はPMだけでは分からないので、各担当のメンバーが集まってブレストを行いながら下の階層の作業を列挙していきます。
また、最下位の作業に関しては、「〇〇（成果物）を××する」と表します。「××する」は作業が完了したかどうかの判断基準となります。
- ユーザーストーリーの各フェーズ
- 成果物
- 組織単位
- 作業時期
- 製品の構造
- テリトリー
- など
7-2. ガントチャート
作業の見積もりを行います。見積もりの仕方としてはいくつかありますが、過去の実績や似たようなプロジェクト、専門家の判断などで決めることが多いです。他にもPERT（Program Evaluation and Review technique）に基づき、（悲観値 + 4*最頻値 + 楽観値）/6として求める場合もあります。
見積もりを決定後、作業間の依存関係を基にネットワーク図を作ります。その後、プロジェクトの開始から終了までに最も長い時間を要する経路を特定します。この経路こそが、プロジェクトで厳密に管理すべきクリティカルパス（最重要の経路）です。クリティカルパス上ではバッファを全て後ろに集め、プロジェクトバッファとして管理します。また、クリティカルパス上にない経路の作業に関しても、その経路上のバッファを全て後ろに集め合流ファッファとして管理します。
最後に、上記のスケジュールを横軸に時間、縦軸に作業を列挙とした表（ガントチャート）を作ります。
8. 予算を算出する
作業計画を基に立ち上げ期の「2-4. 予算を算出する」で合意をとった予算を更新します。また更新したもので上司に再度合意を取ります。
9. リスクマネジメントを行う
プロジェクトで生じるリスクをチームでリスト化してみましょう。 リスクを考える主な観点としては、ビジネス上、スコープ、品質、コスト、納期、リソースに対するリスクを考えていきます。
リスクをリスト化した後に、リスクに影響度、発生確率の２つの基準で優先順位をつけます。特に優先順位が高いリスクに対して予防対策と発生時対策を考えます。対応方法としては、「回避・低減・移転・受容」の4つがあり、ケースバイケースで使い分けます。
リスクマネジメントは計画段階だけでなく実行段階においても継続的にチームで取り組むものです
例えば、チーム内での定例などで毎回聞くようにするだけでも効果はあると思います。継続的に取り組める形で実施しましょう。
計画フェーズのまとめ
上記を計画書にまとめた上で上司へ承認を得て、実行フェーズへ進みます。計画段階まで行うと少しホッとしますが、実行フェーズでも気を抜かずにプロジェクトの目的を達成するまで前に進み続けましょう。
実行フェーズ
プロジェクトの進捗をモニターし、生じた課題に応じてQCD（Quality, Cost, Delivery）やスコープをコントロールします。また、適宜ステークホルダーへ状況の共有を行います。
完了フェーズ
事後の振り返りを行い、成果物に関して検証し、次のプロジェクトに役立てます。最終的な実績データを集め、文書にまとめ記録に残しましょう。また、最後に振り返り会を行い、各メンバーがプロジェクトから得た気づきや教訓を共有し、有意義な振り返りを行いましょう。
参考文献一覧
分類は適当です。読んだ本の中で特に参考になった本を抜粋してます。
プロダクトマネジメント
[1]INSPIRED 熱狂させる製品を生み出すプロダクトマネジメント
[2]Lean Analytics ―スタートアップのためのデータ解析と活用法
[3]プロダクトマネジメント ―ビルドトラップを避け顧客に価値を届ける
プロジェクトマネジメント
[1]プロジェクトマネジメント知識体系ガイド（PMBOKガイド）第7版＋プロジェクトマネジメント標準
[2]改訂7版 PMプロジェクトマネジメント PMBOK®ガイド対応
[3]PMBOKガイド®第7版対応 アジャイル型プロジェクトマネジメント
[4]ザ・ゴール
[5]クリティカルチェーン
アジャイル
[1]エンジニアリング組織論への招待 ~不確実性に向き合う思考と組織のリファクタリング
[2]SPRINT 最速仕事術――あらゆる仕事がうまくいく最も合理的な方法
UX
[1]UX戦略 ―ユーザー体験から考えるプロダクト作り
[2]一人から始めるユーザーエクスペリエンス
[3]マッピングエクスペリエンス ―カスタマージャーニー、サービスブループリント、その他ダイアグラムから価値を創る
Discussion