[レポート] 本当に強いプロダクトを作るためのプロダクトオーナー支援のはじめかた Scrum Fest Sapporo 2020 #scrumsapporo

クラスメソッドもスポンサーとなっているスクラムフェス札幌 2020の­­本当に強いプロダクトを作るためのプロダクトオーナー支援のはじめかたレポートです。

概要

登壇

Yusuke Amano / ScrumMaster / Cybozu

スライド

セッション

＊一番下にQ&Aがあります。

• 翻訳レビューした
  • SCRUM MASTER THE BOOK
  • プロダクトマネジメント
  • この２冊はプロダクトオーナー(PO)をどう支援するかに役だった
• 安定してていいチームだが、ハイパープロダクティブ！って感じではない感じのチームがあった
• チームは価値を提供できてるだろうか
  • チームを見てたが、ユーザーに価値が届けられてるだろうかと考えた
• 問題の兆候
  • プロダクトバックログを見てもワクワクしない - 実際のユーザーにとってもそうじゃないか
  • 開発チームが淡々と開発してる - 開発チームはPBIを考えるのはPOの仕事だと思ってないか
  • POがビジョンや戦略を語る機会がない
  • ユーザーと話さない
• POの支援はどこだろう
  • プロダクトバックログの価値が高くなっていく - プロダクトの価値を高める
  • POの活動って知らなくない？と思った
  • PO研修では価値判断や成功の評価などは教えてくれない
• スクラムマスターにできるPO支援とは
  • POがアジャイルなチームとして一緒に取り組めるような支援はできる
• 具体例
  • POと話す
    • 開発チーム対POになることがあり、開発チームを守る事ばっかりになってしまう
    • パワフルクエスチョン 「今一番胃が痛い問題って何ですか？」
  • 「なぜ」を問う
    • やる理由、優先順位、戦略、なぜユーザーにとって重要なのか
    • 依頼、締切、売上の先にある目標に目を向けてもらう - チームのモチベーションにも有効 - 参考: モチベーション3.0
  • 必要無レベルの目標を言語化する、常に伝える
    • プロダクトビジョン - 一番長期
    • 事業戦略 - 半期に一回とかなどの話しだと見落としがち
    • 開発方針
    • スプリントゴール
  • POが学習・検証したいことのバックログを作る
    • POがアイデアを思いつく -> バックログに積む
      • だと一番コストがかかる開発で発生する無駄が大きくなる
    • ディスカバリーバックログ
  • アイデア問題 -> ソリューション検討 -> 実装 -> 検証
    • 実装に進むものが洗練されることになる
  • アイデアを検証する手段を持つ
    • インタビュー - 本当に問題はあるのか？
    • プロトタイピング - 紙、ツールを使うなどソリューションの検討
    • コンシェルジュ - 作るサービスを人手でやってあげる
    • ユーザビリティテスト - 触ってもらう
    • ログ分析 など - 検証
  • 開発チーム・デザイナと一緒に探索する
    • POがそもそもめっちゃ忙しいので開発チームと一緒にやる
    • チームにオーナーシップが芽生える -> メンバーも戦略やユーザーを理解したアクションがでてくる
  • スプリントビューで共通認識を作る
    • スプリントレビューの上手なPO
    • 共通認識を作るのがうまい
    • 学んだ事を共有する
    • デモだけじゃなく学んだこともインプットにする
    • POの意図をチーム、ステークホルダーと共有する
  • ステークホルダー支援
    • 話す - どう見えてますか？困ってる事ありますか？
    • ビジネスサイドがチームにどう伝えてよいか分からない
    • POステークホルダーも信頼関係ができる
  • #ScrumMasterWay スクラムマスターの成長
    • レベル１ 私のチーム
    • レベル２ 人間関係
    • レベル３ システム全体 - 会社全体
  • 改めて、プロダクトオーナ支援とは
    • #ScrumMasterWay レベル２
    • 価値提供システムを整えていく、働きかける
    • プロダクト指向の組織に近づく

Q&A

PO支援しててPOに言われたいちばん辛かった言葉はなにですか？

「君が言ってることは全然ピンとこない」 スタート地点が遠いなと思うが、状況に応じた受け止め方をしてるだけだと思ってる。

PO交代に直面したことはありますか？

直接的にはない。 メンバーだと、協力したいと思えない態度など他のメンバーが疲弊してる場合にマネージャーに相談する場合がある。

POが社内の他の部署の要望を持ってきてそのままチケットにしてプランニングに持ってきます。 他の機能との文脈とかとすこーし違う時などありどんなふうに対応したらいいかなぁと考えています。 POのその先のクライアント側にもアプロー チできたらいいんですが、その前にできることはありそうでしょうか？

基準（ゴール）をつくるのがよいのでは。 POは何の問題を解決するのかに着目してほしい。解決すべき問題なのか。

POはアイデアと切り離した方がいい？

アイデアは持ってても良いけど、固執しなくてよい。問題が解決されるならどんなソリューションでもよいはず。 その問題って本当にユーザーは感じてるの？っていう。作る必要なかったねってことに。皆にアイデアをもらってフィルタしてるくらいが上手く行ってそう。

まとめ

スクラムマスターやアジャイルコーチとしてプロダクトオーナーをどう支援についての良いヒントが詰まったセッションでした。 開発チームと同じようにPOやステークホルダーの話しを良く聞きくこと、早くなったとはいえ最もコストの掛かる開発に入る前の段階で、成果を産む確率の高いバックログにすること。ですね！