はじめに
アジャイル開発に限ったことではないが、ステークホルダーの洗い出しについて記事を書こうと思う。
意外とステークホルダーをちゃんと明記して、チームメンバ全員の認識として共有しているプロジェクトって少ないように思えるためだ。
ステークホルダーは株主や競合他社なども含めるが、この記事では開発側で意識すべきステークホルダーに観点を絞った内容を記載していく。
そもそもステークホルダーを適当にしか認識していなかったら？
こうなります。
例１）
POのA氏に合意を取ったから開発着手して良いだろう！
・開発メンバに仕様を詰めてもらう
・細かい仕様も含めてOK！
・設計もOK！
→さあ開発だ！というところで、PO以外の部署からNGを食らって開発中断。。
本当に萎えるでしょうぅぅ
例２）
PO含め、他の関係部署からも合意をもらう
・開発着手！
・コーディング終わり！疎通確認終わり！
・PRレビューも終わり！
・テストも終わり！
→さあリリース準備だ！というところで、設計の承認が通っていないとことで、この段階で設計承認会議に参加。。
設計でNGを食らって手戻り。。。
これも本当に萎えるでしょうぅぅ
ステークホルダーマネジメントの失敗事例を箇条書きで挙げると以下となる。
- 攻撃的なコミュニケーションになってしまう
- 若手社員が顧客最優先の姿勢で社内調整を強引に進めた結果、同僚との信頼関係が崩壊し、プロジェクトが停滞。
- 配慮不足の態度
他部署への敬意を欠いたマーケターが、頻繁に衝突を起こし、最終的にプロジェクトから外された。 - リスク共有の遅れ
リリース遅延時にリスクを早期報告しなかったため、プロジェクトが破綻。 - 要件定義の不備
ユーザーと開発者間の期待値ギャップが埋まらず、コスト増大や機能漏れが発生。
ステークホルダーを把握するのはなぜ必要なの？
失敗例から分かる通り、当然と言えば当然ですが個人開発でない限り開発には"色んな人"が関わってきます。
開発を進める上で、その"色んな人"に確認を取る必要があるわけです。
当然だろうぅ？と思うかもだけど、ここ出来てなくて痛い目に遭うプロジェクトは結構あるんだぜ。。。
特に大きなプロジェクトで、関係者がいっぱい、関係している会社がいっぱいのところとかは特にね。
社内のステークホルダーに確認する必要がありそうな内容としては、例えば以下となる。
仕様確認、設計の方式確認
デザイン、分析、性能系、テスト系、
また、調査・検討した結果のレビューが必須な場合もある（DB設計、ディレクトリ/クラス設計、保存の仕方(アプリで持つの？サーバで持つの？他サービスと連携するの？とかね)
要件や仕様確認
特に要件や仕様について合意をとるべき相手をよく確認しておこう
開発を進める上での承認フロー
プロジェクトやサービスによってこの辺りは大分変わってくるが、
リリースまでに必要な承認フローをよく理解し、承認をもらう担当者を抑えておこう
（無駄なプロセスもあるケースもあるが、改善するにしても抑えておく必要があるのでここもよく理解しておく）
技術的に困った場合の相談先
迅速に開発を進めていく上で技術的に困った場合の相談先も抑えておく。
相談先の例）チームメンバー、有識者、テックリード、PLやGLなど
開発を進める上でのステークホルダーを洗い出すためには？
開発を進める上での開発フローや承認フローを明確化できていないと、関係者が洗い出せない。
そのため、まずは開発フローや承認フローを洗い出すことが必要となる。
※細かい部分で言えば、新しいツールの導入方法、アクセス権の申請方法なども抑えておき承認先も抑えておく
ステークホルダーの洗い出しを行う際に気をつけるべき点
- 直接・間接の分類：
ステークホルダーを「直接的関係者」（プロジェクトメンバー、承認者、クライアントなど）と「間接的関係者」（外部組織、規制機関など）に分けることで、漏れを防ぎます。 - 役割と影響度の明確化：
単なる名前のリストではなく、各ステークホルダーの役割やプロジェクトへの影響度を明記し、全員で共有します。 - 関心と権力の分析：
ステークホルダーごとに関心度と権力を評価し、優先順位をつけて対応計画を立てます。
社内のステークホルダーの例
・自分の所属する開発チームのメンバー
開発メンバ、PL/UL, GL, PO, PM, テックリード, レビュアー、有識者など
・他Unitや他チームの開発メンバ
自分のUnitやチーム内のメンバだけでなく、関係がありそうな他Unitや他チームの担当者も挙げておく
・開発以外のチームメンバ
開発以外で関係がありそうな担当者を挙げておく
例）デザイナー、QA担当、営業担当、法務担当 etc...
・エンドの顧客（特に開発側に問い合わせなどが降ってきそうな顧客）
・役員
最後に
ステークホルダー特定の最も重要なステップは、包括的なリストアップです。
開発を進める上でプロジェクトや企業活動に影響を与える、または受ける可能性のある全ての関係者を網羅的に洗い出すことが基盤となります。
この初期段階で重要な人物や団体を見逃さないことが、後続の分析や改善、また効率的な開発につながる鍵となります。
以上