アジャイル開発におけるステークホルダーマネジメントの重要性
最近、とある企業でのアジャイル型のシステム開発の標準化に携わっている。 大きな企業は、そもそもの組織構造からアジャイル型のシステム開発には向かないと思ったので、その理由などを書いてみる。
そもそもアジャイル型の開発ライフサイクルは、ステークホルダーから要求を引き出す→製品へ実装する、というプロセスを納期・予算が許す限り繰り返すことで、ステークホルダーの要求に添ったプロダクトを開発する手法だ。このことから、ステークホルダーの関与はプロジェクトの成否を決める重要なファクターであり、PMBOKでいうステークホルダーマネジメント(コミュニケーションマネジメントもだが)が従来型に比べて重要になる。
大きな企業のシステム開発プロジェクトにおけるステークホルダー(としてアサインされる人)は、以下のような特徴が見られる。
業務の限られた一部しか知らない(業務の全体像を知っている人がアサインされたらラッキー)
多数の案件を抱えているため、常に忙しい。
これは大企業は分業や業務の外注を積極的に行っているためであり、企業の規模が大きいほどその傾向が強い。 大企業のシステム開発プロジェクトは、ステークホルダーは必然的に多くなり、各々が忙しいため、ステークホルダーマネジメントが難しくなる。 だからステークホルダーマネジメントがプロジェクトの要となるアジャイル型のシステム開発プロジェクトは難しい。
PMBOKを開いてみると、ステークホルダーマネジメントの中で、まずはじめに行うことは、ステークホルダーの特定となっている。 PMBOKによるとステークホルダーは内部ステークホルダーと外部ステークホルダーに分類でき、その内容は以下のとおり。
- 内部ステークホルダー
- スポンサー
- 資源マネージャ
- PMO
- ポートフォリオ運営委員会
- プログラムマネジャー
- 他のプロジェクトのプロジェクトマネージャ
- チームメンバー
- 外部ステークホルダー
- 顧客
- エンドユーザ
- サプライヤー
- 株主
- 規制当局
- 競合他社
これは、プロジェクトマネージャ視点からみたステークホルダーの分類であり、開発現場のメンバーからみると少し遠いと感じていた。実際、アジャイル開発の現場だと、ステークホルダーはエンドユーザだけだと思い込み、エンドユーザだけの要求に偏ってシステムの保守性がほぼ考慮されていないようなケースがあった。
少し古いが、IPAが公開している資料にKikuma Ringというものが紹介されている。開発現場やチーム目線だと、こちらの方がステークホルダーを意識しやすいのではないかと思った。