PMの役割と具体的な行動
おはようございます。
前回に引き続き、プロジェクトマネジメントについて、学んだことを整理してアウトプットしていこうと思います。
以下の書籍を中心に、部分的にネット検索を活用しながら学習を進めております。
PMが取り組むべき行動
PMBOK7において、以下の8つの活動を「プロジェクト・パフォーマンス領域」として定めています。
これらを深掘りしながら理解しておくことで、いざ自分がPMとなった時にどのような行動を取れば良いのかの道標になるのではと思っています。
1．デリバリー
プロジェクトの成果物が価値を提供して目標とする事業価値が得られるよう、価値や要求事項、スコープ、品質の定義などの活動を行います。
※スコープ：プロジェクトで作成する成果物の機能のことをプロダクトスコープ、成果物を作成するために行う作業のことをプロジェクト・スコープと呼ぶ。
2．開発アプローチとライフサイクル
成果物やプロジェクトへの要求などを考慮し、開発アプローチ（予測型、適応型、ハイブリッド型）の選択やフェーズやライフサイクルの定義などの活動を行います。
3．計画
プロジェクトを計画的に進められるよう、スケジュールや予算、各種資源、調達、コミュニケーションなどの計画に関連する活動を行います。
4．プロジェクト作業
プロジェクト・チームが効率的かつ効果的に作業を行えるよう、プロジェクト作業手順の最適化や各種資源のマネジメント、調達の実行、コミュニケーションのマネジメントなどの活動を行います。
5．測定
プロジェクトの事業価値の創出に向け、意思決定に役立つ信頼性の高い予測と評価を得るために、評価指標の選定や測定、情報の提示などの活動を行います。
6．ステークホルダー
ステークホルダーから協力が得られるよう、ステークホルダーの特定や理解・分析、対応決め、働きかけ（エンゲージメント）などの活動を行います。
7．チーム
プロジェクト・チームとして高い成果を生み出せるよう、メンバーやチームのマネジメントや育成・指導などの活動を行います。
8．不確かさ
プロジェクトを実施する環境は、不確実なこともあるため、それらを考慮した対応などの活動を行います。
ウォーターフォールとアジャイルの違い
これ以降は、上記の8つの活動の深掘りを進めていく中で、とりわけ整理して理解をより深めた方が良いと感じたポイントについて、ピックアップして書いて聞こうと思います。
まずは、ここ数年でホットなワードとしてよく登場する「アジャイル」について、従来の「ウォーターフォール」と比較しながら、主な違いを整理します。
概要・適したプロジェクトの特性
それぞれの開発アプローチについて、概要は以下の通りです。
●ウォーターフォール型
プロジェクト開始当初に要求事項を定義し、それに基づいて計画を作成、計画に沿って作業を進めていく。
プロジェクト開始時に要求事項を全て定義できる場合、要求事項を全て満たさなければ機能しない場合に有効なアプローチ。
●アジャイル型
ステークホルダーのフィードバックに基づき、要求事項や優先順位を見直し、定められた期間内に達成可能な作業を進めていく。
プロジェクト開始時に要求事項の不確かさと変動性が高い場合に有効なアプローチ。
ざっとしたイメージですが、業務システムやハードウェアとセットの組み込みシステムのような、当初から業務要件を明確にでき、その要件を満たさなければ意味をなさない場合はウォーターフォール型アプローチ、スマホアプリのような、容易にデリバリーができ、ユーザーの反応を見ながら品質を上げていくことが有効な場合はアジャイル型のアプローチを採用する、というのが私の感覚です。
スケジュール作成
次に、それぞれのアプローチにおけるスケジュール作成の違いについて、本書の説明がとてもわかりやすく、ハッとさせられたので書いておきます。
●ウォーターフォール
前提条件：スコープ（成果物の完成）、作業期間
決めること：作業期間内に終えるための要員数
●アジャイル
前提条件：作業期間、要員数
決めること：終えられるスコープ（成果物・フィーチャー）
ここに両者の明確な違いがあるなと感じています。
ウォーターフォール型に慣れ親しんだ私としては、プロジェクトを進める上で成果物が明確になっておらず、全てのバックログ（要求事項）を終えなくてもデリバリーして良いという前提が少し気持ち悪く感じてしまします。。
SEがブラックなのはウォーターフォール型のせい？
SIer、SEの仕事がとてつもなくブラックであった（今も？）背景には、従来のウォーターフォール型の開発プロセスがあるのではとも思っています。
正確なスケジュール見積もりが難しいことは誰もが知っている中で、納期と成果物が決められた中で開発を進めていくという一見理不尽にも感じる環境が生まれてしまうのも納得ですよね。
それに対してアジャイル型のプロセスであれば、あらかじめ作業期間と要員数が決められた中で、可能な範囲の成果物を作っていくアプローチになりますので、必然的にブラックな環境は減っていく方向になると思います。
パレートの法則で「2:8の法則」があるように、全体の品質の8割は、2割の機能が決めるといった解釈もできますので、必要最低限の機能を搭載した上で、残りは定められた期間内に可能な限り品質を高めていくような考え方はとても合理的に感じました。
まとめ
8つのプロジェクト・パフォーマンス領域について整理して見ました。
1つ1つの領域について、深掘りはまだまだ途中ですが、開発アプローチに触れただけでなかなかの文章量になってしまったのでここで一度区切りたいと思います。
次回以降で、他のパフォーマンス領域についてもとりわけ重要そうでアウトプットしておきたいことがあれば、別記事にしていこうと思います！
それでは。
この記事が気に入ったらサポートをしてみませんか？