改めて、プロジェクトマネジメントをどうアプローチすれば良いかを考えている
ひと段落ついたので、改めて、プロジェクトマネジメントへどうアプローチすれば良いかを考えはじめている。
プロジェクトマネジメントへのアプローチと言いつつ、実際は、プロジェクトを回すマネージャ（＝プロジェクトでリーダーシップを発揮する人）が何から手をつけて行けば、プロジェクトを炎上させずにプロジェクトの目的を達成することができるか、である。
ペルソナ
対象読者のペルソナはこんな感じか。
- はじめてプロジェクトのリーダ役をすることになったエンジニア
- プロジェクトを一度も独力でキャリーしたことがないエンジニア
前提条件
ない方が良いが後から書き出すかもしれない。
例えば、『言語やプラットフォームは問わないが、何かしら開発経験を持っている』などは必要かもしれない。
ゴール
プロジェクトマネジメントをできるようになることが目的ではない。ここを間違えないように。あくまでも、プロジェクトの目的を達成することが目標である。
プロジェクトマネジメントは、プロジェクトをマネージする手法である。プロジェクトマネジメントの代表的な知識体系である『PMBOK』では開発方法まで言及していないことが証左である。
知識エリア
プロジェクトをいい感じにキャリーするために必要な知識エリアは4つある。
テーラリング
前述の4つの知識エリアが必要である。全部の知識エリアは必要だがその中の知識全部は使わない。必要なものだけ使う。必要なものだけ使うから、不要なものは知っていて、且つ、使わない判断をしなければならない。
取り扱う範囲
システム開発を受託や社内開発のイメージにするとシステム開発プロジェクトになるので、システム要件が提示された以降が範囲になりそうだ。
ただ、自社サービスの開発であれば、プロダクトマネジメントの要素が入ってくるので、範囲がぐっと広くなり、何を作るかからになる。
それでも、結局は、経営課題かビジネスモデルキャンバスのソリューションに当たるところがインプットになる。
その前のシステム要件や提供価値はビジネスオーナとしておく（がそれで良いか、あとで再考するかは考えどころ）
インプット
上述から、システム要件、提供価値がインプット。いずれにしろインプットは必要。自分でプロダクトを作る、何だかよくイメージできていない段階だとしても、ペーパーでモックを作るにしても、それを作るインプット（を作りながら形作るのかもしれないが）はあるのである。
手のつけ方
4つの知識エリアのどこから手をつけるか。これはこれから考える。
