アジャイルが導入されたときプロマネは何をするか

以前、コミュニティの知り合いに

『プロジェクトマネージャはアジャイル開発でのロールはどこに位置付けられるか』

とい問いかけをしたことがある、

アジャイル開発、スクラムでのロールは、プロダクトオーナ、スクラムマスタ、スクラムチームの構造になる。

プロダクトオーナより上はビジネスオーナなどその組織の事業責任の役職がつくだろう。この辺りはその組織次第であるだろう。ただ、今回のテーマはプロジェクトマネージャはアジャイル開発でどこのロールに当たるかをスコープにしているため範囲外として棚にあげる。

内心、スクラムマスタはSEリーダ的な位置付けだと思っていたので、プロダクトオーナしかいないな、と思っていたら案の定、POだと言う。

その場に居た二人に尋ね、二人とも同じ見解であったので一つの見方としては受け入れられる考え方なのだろう。

ただ、どうしてプロジェクトマネージャ＝POかと言うと、『デリバリの責任を負うから』だと言う。確かにプロジェクトマネージャもプロダクトオーナもソリューション（製品やサービス）のデリバリ（リリース）の責任を負う。

そう言えば、プロジェクトマネージャと言えば『PMBOK』のPMIである。確か2015年くらいからagileの実務者認定をプレで始めていて、翌年くらいから正式に認定を始めていたような気がする。

気がすると言うのは、そのプレ認定のタイミングで認定を受けるかどうかを一瞬であったが考えたからである。ただ、そのときはagileなら『本家はCSMやCSPOだよな』と思い先送りした経緯がある。

あれから3-4年くらい経過していた。

CCRS（3年毎のPDUの更新）のタイミングで、そう言えばと思い『PMBOK Guide and Standards / Practice Guides』で『Agile Practice Guide』の日本語版をダウンロードしてざっと目を通してみた。

アジャイル実務ガイド (日本語版) (Project Management Institute)

PMIの文書の読みづらさは以前からであるが、もう少し監訳にリソースを使った方が良いのではないか。

PMBOK自体の読みづらさはある意味伝統になっているのでどうでも良いが、『Agile Practice Guide』もかなりのものである。

ここまでが前説である。

『Agile Practice Guide』でのプロジェクトマネージャの位置付けを見つけたところ、アンニュイな気分になったと言うか、元々、紐付けすること自体に意味があるのかと思っていたので想定の範囲内と言えば範囲内であった。

4.2.2アジャイル環境におけるプロジェクト・マネジャーの役割

多くのアジャイルなフレームワークや手法はプロジェクト・マネジャーの役割に言及していないため、アジャイル・プロジェクトにおけるプロジェクト・マネジャーの役割は不明なところがある。

引用　P37　PMI Agile Practice Guide

それはそうだ、としか言いようがない。誰も上手くいっていないやり方だと思って車輪を発明しようとしている側がわざわざ旧制度側の役割に紐付けするメリットはない。

あえて記載することで暗黙でそれをわかった上でこのガイドを読めといっていると思うのだがどうだろうか。

一部のアジャイル実務者は、自律型チームがプロジェクト・マネジャーの責任を引き受けるため、プロジェクト・マネジャーの役割は必要ないと考える。

引用　P37　PMI Agile Practice Guide

他のアジャイル界隈のエンジニアに尋ねてみると上記の『自律型チームだからはいらない』と同じようなことを言ってた。チームのコントロールはチームで行う自己完結だからプロジェクトマネージャの居場所はないと言うことだ。

しかし、実用的なアジャイル実務者や組織は、プロジェクト・マネジャーが多くの状況で重要な役割を担えることを認識している。これまでのプロジェクト・マネジャーとの決定的な違いは、役割と責任が幾分異なって見えることである。

引用　P37　PMI Agile Practice Guide

ただ、プロジェクトマネージャがやっていた、例えば調達管理などはアジャイル開発の3つの役割には含まれないと言う。そう言ったプロジェクトマネージャがやっていたプロジェクトを回すための管理業務は『役職者でやってください』と言うのだそうだ。

素早いリリースに専念するのはそれはそれで価値を産むのであるが、旧態のロールから見ればロールの再設計を同時にやらなければ、誰も拾わないから最終的に現場が混乱するだけなのではないかとも思う。

 こうして比べてみると、同じソリューションをリリースするプロジェクトを対極的にアプローチしていると思う。

プロジェクトマネジメント（網羅的・体系的）

↓

ソリューションデリバリ

↑

アジャイル（必要最小限・局所的）

やりたいことは同じだが、それを解決するアプローチの背景が違う。特にプロジェクトマネジメント側は、IT以外のプラント、建設、製薬開発、テレコムなどのプロジェクトコントロールを由来とするから失敗しないように様々な知見を持ち寄った集成となっている。だから網羅的であるし体系的だと表現している。その副作用として手続きは複雑である（が、テーラリングでスリム化できる）。

アジャイルは顧客の必要なソリューションデリバリだけにフォーカスするからあれもこれもという考え（msutのみでwantは入れない）だからプロジェクトマネジメントと比較すれば紐づかないところが出て当たり前だ。

ただ、自分としてはプロジェクトマネジメント とアジャイルを並べて紐づけることとは別の考えを持っている。

 元々、プロジェクトマネジメントは経営者からのプロジェクトのリスクモニタリングの仕組みであると考えている。

マインドセット（心理的安全性）

↑

ツール＆テクニック（テスト自動化・Circle CIなど）

↑

システム開発手法（ウォーターフォール型開発・アジャイル開発）

↑

プロジェクトマネジメント（プロジェクトのコントロール・モニタリング）

↓

経営（プロジェクトの継続・中止の判断）

このようにプロジェクトマネジメントをインタフェースとして位置付け、システム開発手法と経営を繋ぐ役割として、全体のロールを再設計すると実は収まりが良い。

このことに気づいている人はまだいない（一度も聞いたことがない）。

個人的には、ソリューションへの思いを持てるならPOに転換するのが良いと思うが、思いのないプロマネがPOをやるのだけは避けたい。

その上で、プロジェクトマネージャを単独で置くか、PMOと統合するかは組織で好きにすればいい。