【読書メモ】 ステークホルダーが求めるものをどうやって作る？ by ゾンビスクラムサバイバルガイド
はじめに
最近、職場で「ゾンビスクラムサバイバルガイド 健全なスクラムへの道」という本の輪読会をしています。
この本の「第 5 章 症状と原因」で書かれていた、ステークホルダーが求めるものを作れていない原因とその解決策が非常にためになったので、いつものように読書メモという体でご紹介したいと思います。
読書メモ
なぜステークホルダーを巻き込む必要がある？
プロダクト開発において、なぜわざわざステークホルダーを巻き込む必要があるのでしょうか。
ゾンビスクラムガイドの表現を借りつつ言語化すると、
組織はプロダクトを世の中にリリースすることで存続することができるが、組織を存続させるためのプロダクトの価値が正しく届けられているかは、そのプロダクトにお金を払ったり、実際に利用している人に実際に聞くことでしか確認できないから
です。
ステークホルダーって誰？
本でも紹介がある通り、スクラムガイドでのステークホルダーの定義は、「プロダクトに利害のあるすべての人」です。
だいぶ抽象的ですね。
外部の顧客だけがターゲットになることが全てではないとのことで、意図的にこのような表現をしているそうですが、実際のところ、ステークホルダーとは誰なのでしょう。
この本では、ステークホルダーを見つけるために役立つ質問を紹介してくれています。
・この人は、普段からプロダクトを使っているか、または使う予定があるか？
・この人は、プロダクト開発にたくさんの投資をしているか？
・この人は、あなたのプロダクトが扱う課題の解決に時間もお金も投資しているか？
ゾンビスクラムサバイバルガイド 健全なスクラムへの道.
丸善出版, 2022年, p.50.
ステークホルダーとは、実際にプロダクトに時間とお金を投資して使ってくれる人のことを指すのですね。
おもしろいのは、社内のドメインエキスパートや仲介者、プロダクトに興味を持っているだけで私的な利害のない人たちのことをこの本では、はっきりと「オーディエンス」と言い切っていることです。
ステークホルダーをいつどうやって巻き込む？
上記の質問から自分たちが見つけるべき正しいステークホルダーがわかったことで、ではそのステークホルダーをいつどうやって巻き込むべきなのでしょうか。具体的に以下のときに巻き込むべきとありました。
プロダクトビジョン策定のとき
プロダクト開発のキックオフのとき
スプリントレビュー
バックログリファインメント
また、ステークホルダーとの会話にはプロダクトオーナーだけではなく、開発チームも関わるべきとはっきり書かれていました。
過去に読んだプロダクトマネジメントに関する本にも同じように、開発プロセスの早い段階で開発チームを会話に混ぜるべきと書かれていたので、これはプロダクト開発成功のための正解なのでしょう。
スクラムチーム全員が、ステークホルダーのことをよく理解する必要がある。
プロダクトオーナーはプロダクトに必要なことと並び順を決定するために、ステークホルダーグループとの会話に時間を費やすことは当然だが、その会話には開発チームも全員、同じように参加するべきである。
ゾンビスクラムサバイバルガイド 健全なスクラムへの道.丸善出版, p69.
そしてあらわになったゾンビ度合い
この本の第 5 章を読んで、早急に行動せねば、となりました。
自分のチームのゾンビ度合いがあらわになり、自分の不甲斐なさを痛感しました。
自分のチームの実態はこうでした。
開発チーム全員との対話がプロダクトオーナー ⇔ オーディエンス、ときにはステークホルダーがほとんど
プロダクトオーナー自身もステークホルダーとの会話が少ない
バックログリファインメントはプロダクトオーナーを含む開発チーム内でのみ開催してしまっている
これを受けて、早速ではありますが、小さくアクションを取っています。大胆にガラッとは帰れていませんが、簡単にできて効果の高そうなものから徐々に動いています。
以下が実際に行動したこと。
開発チーム内で仕様調整のためのミーティング（バックログリファインメントではなく、開発中の突発的なミーティング、大抵は Google Meet や Slack のハドルミーティングで開発メンバーが声をかける）などでステークホルダーに声をかけて、参加してもらえないか声をかける（案外すぐレスが来て、応じてもらえる）
新たに作る機能については、開発チームとステークホルダー全員でユーザーストーリーマッピングを実施
話はそれますが、チーム全員で輪読会をしたことで、開発チームがただコードを書くのに集中するのではなく、プロダクトの価値を最大化するために、もっとステークホルダーと会話をするべき、というマインドセットがインストールされたのも非常に良かったです。
スクラムで開発をするとどうしても、「スクラムイベントが多すぎて、開発の時間がとれない」という声が上がりがちですが、ミーティングの時間を取ってでもプロダクトの価値を大きくするために今議論すべき、という考えをエンジニアが持てたのも良かったです。