マネジメントはアジャイルを受けれられるか
PMBOKの第6版の目次を眺めて何気なく改めて思ったことはマネジメントという活動をコントロールする考え方の有無と捉え方の違いがあるな、ということです。
ぼんやりとした表現なので伝わりにくいと思いますが、書いている本人もまだ曖昧模糊としているのでこれから明瞭になればいいのだけれど。
コントロールとは
プロジェクトマネジメントのマネジメントとは、プロジェクトをコントロールすることをしたいのです。ただ、闇雲に何かをコントロールしたいのではなく、コントロールしたい対象に対してこれから起こることの期待値を予測し、その期待値が許容する範囲の中で収まるように制御をしたいのです。
予測とは
予測とはことの成り行きや結果を推し量ることです。結果を推し量るためには期待する結果が必要で、プロジェクトでは期待する結果を予測して表現した結果がプロジェクト計画です。
計画がなければ予測はあてずっぽうでしかありません。単なる期待、希望の類です。個人のイノセンスな願いであればそれもでいいのでしょうけれど営利企業ではそれでは事業継続が怪しくなるのでそうはいきません。
だから、事業が計画通りに拡大するように事業計画を立て、進捗をモニタリングしているわけですが。
計画とコントロール
計画を立て、期待値に収まるようにコントロールしたい。そこには計画したことを計画の期待する結果の許容範囲で到達すればいい。
プロジェクトマネジメントにはそうした力学が働いているとするならば、それを実現する手法としてのシステム開発手法はどれが適切か、と。
マネジメントの観点から言えば、期待する許容範囲で収まればどれでもいいのだけれど、プロジェクトマネジメントの考えの組み立て方と実現するシステム開発手法の適合性から言えば、ウォーターフォールが同様に計画を立て、計画通りに進めていくのでフィットするのは当然と言えば当然なのですが。
ゴールとは
一方、アジャイルはどうでしょうか。完了まで、例えばスプリントの中ではバックログの範囲の中でしか開発しない（割り込み案件がない）ので計画を立て、スプリントの中で期待値の範疇で納めるのであまり変わらないけれど、これをプロダクトとして全体噛んで俯瞰するとスプリント計画を作る際に実現したい要件が毎回再構成するのでプロダクトライフサイクルの観点ではゴールは、ウォーターフォールとは違う結果になっていても全く不思議ではないのです。
というか、変わります。
ここがマネジメントをする際にこれまでのマネジメントとは違う感覚を持たなければならないポイントです。
より、プロダクトにマネジメントが踏み込む必要がある、と思うのです。ウォーターフォールで作ってー、とはいかなよ、作ってーと言ったときと違うものが出てくるよ、その覚悟はしておく必要があるよ、と。
何せ、人は最初に見たものが正しいと思いがちです。同じ機能を実現していても、当初計画とその後に変わったものを並べれば、当初計画の方を正と脳内で補完してしまうので。
実現される付加価値への期待は基本的には同じです。実現手段と実現仕様が変わるだけなのですが。
