プロダクトオーナーの煩悩: サラリーマンPOの目から見たインセプションデッキのおもいで

| 3 min read
Author: kazuya-nakamura kazuya-nakamuraの画像

この記事は夏のリレー連載2024 5日目の記事です。

はじめに

#

中村です。社内開発でプロダクトオーナーをやっていました。(前回執筆直後に離任)
開発現場での悩みや気づきなど、当時をふりかえりつつわりと赤裸々に書いていきます。

まず前提として宣言します。当案件、私のPO在籍期間(2021年~2023年)時点では、あまりスクラムとして円滑に回っていませんでした。故にナレッジ、事例としての公開に二の足を踏んでいた(だってカッコつけたいじゃん)のですが、それも含めて透明性と腹をくくり公開に踏み切りました。同様の悩みを抱えるチームにとって 人体実験 少しでも参考になれば幸いです。

ちなみに本記事の元ネタ時点(2022年後半ごろ)でのチームの状況です。

  • プロダクト
    • 社内利用ツールを内製開発(2020年~継続中)
    • 最低限の基本機能開発してリリース。業務移行しつつ徐々に増築中
    • 基盤はEKSを利用したマイクロサービスアーキテクチャ
  • チーム構成
    • Dev:常任2名+スポット数名(新卒・中途採用社員などのトレーニング道場を兼ねる)
    • PO(私):開発部門出身。認定スクラムマスター(CSM)資格保有。各利用部門の要求をとりまとめる。顧客案件アジャイルコーチとの兼務
    • SM:認定スクラムマスター(CSM)資格保有。本格的なスクラムマスターは本案件がほぼ初めて

それでは、今回のテーマは『インセプションデッキです』です。

背景

#

繰り返しとなりますが、当時(今も)わたしはコンサルティング部門所属のいち会社員です。そのためPOをまっとうするには、いろいろ頼りない状態でした。

  • 権限・裁量…ほぼ皆無(ヒラ社員)
  • 業務知見…開発を通して部分的に理解できてきた
  • マイクロサービス…開発を通して概要は掴めてきた
  • スクラム…認定スクラムマスター(CSM)資格は取得した。 あとは見様見真似

正直、当時SMからステークホルダーを一堂に集めてのインセプションデッキの開催を提案されたときは、まったく効果をイメージできていませんでした。「まぁ、アジャイルサムライにも書いてあるし、経験として一度やってみてもいいんじゃないですかねぇ…」的な。

しかし結論から言えば、インセプションデッキはPO…ひいてはチームが「スクラムチーム」として欠けていた知識や裁量を補完する場として、欠かせないイベントとなりました。

  • ステークホルダーの重要な要求
  • ステークホルダー総意としての大局的な決断(意思決定)
  • 要求の背景となる業務知識や要求への熱量
  • ディスカッションを通したスクラムチームとステークホルダーの仲間意識、一体感

各イベントへの現在の目線での所感

#

POとして2年ほど活動し、離任して1以上年経った現在の目線で、当時のインセプションデッキを見返しながら箇条書きで所感を書き出してみました。記述は当時の実施順です。

なお、ここではエレベーターピッチ自体のやり方については言及しません。アジャイルサムライ他、書籍やWeb等の豊富な解説にお任せします。

グラウンドルール

#
  • アイスブレイクとして「悪くはなかった」
  • 常識レベルのルールが出るにとどまっていた。が、表明自体が大事かも
  • 例)
    • ミュートしない。環境音OK
    • 気軽に発言
    • 現実の背景から意見や要望を表明する前に諦めない
    • 解決案のない課題提起OK。解決案をみんなで考える

エレベーターピッチ

#
  • 正直、皆が興奮するようなピッチに出会えたことはない
  • ニッチなニーズを一点突破する斬新でシンプルな製品なら有効だろうと想像できるけれど、利用者が多岐にわたる業務アプリに対してはどうだろう…
    • 各部門のニーズを組み合わせたような複合的で曖昧なピッチに「まとまる」
      • とはいえ、各事業部門ごとにニーズが割れるので、集約しすぎると参加者数や声の大きさが勝ってしまうおそれ
    • 「やらないことリスト」と内容が被っているような…

トレードオフスライダー

#
  • 必須オブ必須①
  • PBIの優先度やスコープコントロールの判断材料として、幾度となく見返した
  • 納期や予算(≒人員追加)についてマネジメントの(その場限りでない)コミットメントを得られることは、チームにとって非常に心強かった
  • 品質について、ビジネスと開発での相違を明確にできた
    • ビジネス側の「高品質」は機能が要求を満たしていること、故障していないこと
    • 開発側の品質は保守性(のためクリーンな設計、コード)まで指す

やらないことリスト(やること・やらないこと・あとで決めること)

#
  • 今四半期で追加される主要なPBIの元ネタ、前四半期の残(キャリーオーバー)PBIの棚卸としてとても役に立った
  • 事業部同士の駆け引きと、落としどころの「合意」の場
    • エレベーターピッチの椅子はひとつしかないが、こちらは幅のある「相対的な優先度」なので公平性・納得感が大きい
    • ここでの意思決定をベースラインに、POの裁量内でPBIの内容や順序を「微調整」するのがPOの仕事
      • POにスクラムガイドが想定するような裁量や(大局的な)決断力が不足する本案件では、心強い羅針盤となった

ご近所さんを探せ

#
  • 必須オブ必須②
  • 要求の聞き込みやコミュニケーションラインの改善に不可欠
  • 当時はインセプションデッキの最後に行っていたが、初日にやるべきだと今は思う
    • 重要な(インセプションデッキに呼ぶべき)ステークホルダーの見落としが最後に発覚したら目も当てられない
    • 本開発で遭遇しなかったのは単なる不幸中の幸い
  • 描くのは「体制図」ではなく「人物相関図」
    • スクラムチームを中心に、プロダクト(プロジェクト)に影響する公式・非公式な人間関係をすべて書き出す
      • コミュニケーションライン
      • 誰が何を知っているのか
      • 決定権ははどこ
      • 利害関係

まとめ

#

時間の経過と、当時記憶が飛ぶほどガムシャラだったこともあり、いくらかの記憶違いや美化は入っているかもしれません。
一方、当事者でなくなったことで、当時は見えていなかったことへの気づきもありました。

ひとつ結論として言えることは、「インセプションデッキ、ぜひやりましょう」
ただし、多忙なステークホルダーを長時間拘束するので、効果的なデッキの選択やキッティングは必要そうです。そこはSMの腕の見せ所ということで…。

次回に続く

#

第1回から1年以上空いてしまいました。次は年内に公開できればと思います。

豆蔵では共に高め合う仲間を募集しています!

recruit

具体的な採用情報はこちらからご覧いただけます。