「SCRUM FEST Osaka 2024(2日目)」に参加してきました

• 2024/6/22
• https://www.scrumosaka.org//2024

プロダクトオーナーとその支援者による座談会

• Takahito Hirakawaさん
• Daisuke Kasuyaさん
• Kazunori Moritaさん
• Minoru YOKOMICHIさん

POって何する人

• プロダクト価値を最大化することに責任を持つロール
• うまく機能させるにはPOの決定を尊重する

声の大きいステークホルダーにふりまわされるPO

• 説明責任の大きい仕事
• やりたいことに熱意を持って動けることが大切
• データが有るならデータに従う
• 上の人の一声に問い返すことをしていないのでは
  • 下に落ちてくるほど何も言い返せない

どうやって価値を評価計測するのか？

• データ駆動で動きたいけどどうやって価値を測ればいいか

バックログの優先順位

• POだけで決めきれるものでもない
  • 開発視点の依存関係
• Product Prioritization Frameworks
• RICE
  • Reach
  • Impact
  • Confidence
  • Effort
• 工数をポイントとしてざっくりつけるように価値についてもポイントを付けてみてもいいのでは

リモートワークでの困りごと

• 良かったこと
  • ユーザインタビューしやすくなった
  • 商談のやりとりなどを録画して開発チームとかも見れる
• 困ったこと
  • 全員集まる会議でその場で意思決定しないといけなくなった
  • 忙しい人を捕まえに行くことができなくなった

ステークホルダーからロードマップを作ってと言われる

• 確約できないし変更が入るから作りづらい
• ロードマップを一本道で書く必要がない？
  • 分岐を作って書く
• なんで作れと言われる？
  • 信頼されてないから？
  • ビジネス的に期限を決める必要がある？
• 機能ベース？アウトカムベース？

SM/開発チームとの役割戦引き

• 全部自社だとぬるくなることがある？
  • SMが開発チームにヒアリングして溜め込ませないようにする
• 開発をどこまでディスカバリーに巻き込むか
  • 線引しすぎてもよくない
  • 巻き込みすぎてもコストがかかる
  • POが悩むところ
  • SMの腕の見せどころ
• 専任SM置いて客観視して見られる立場がいるのが大切

POのスキルセット

• 顧客理解
• 説明責任
• 熱量

あなたにピッタリの帽子を見つけよう！〜自分に合ったスタイルを発見するセッション〜

• Hiroshi Matsuoさん
• Daisuke Kasuyaさん
• Masahiro Taguchiさん

転職の苦労話と学び

• アジャイルコーチとかSMで募集してても意外とエンジニアリングスキル求められる
• ChatGPTに職務経歴書作らせるといい

防止の使い分け

• EMとSM
  • どっちを名乗ったほうが動きやすいかで使い分けるくらい？
• 肩書きが決まっちゃうとロールが決まっちゃう
• SMの仕事
  • 火を消す
  • けむりを見つけに行く
• バックログがきれいならなんとかなる

JISAの方から来ました〜SIerのアジャイルがどうなってきてるかこの辺で共有させてください〜

• Tomonori Fukutaさん
• Satoshi Yasunoさん
• Toshiyuki Andoさん

JISA

• 情報サービス産業協会
• SIerの企業などが入ってる
• JISAアジャイルコミュニティがある

JISAのアンケート

• 属性
  • 回答者は技術職が一番多くて次がマネージャー
  • 開発に携わってるのは7割
  • 社内向けが8割り程度
• アジャイルに関して
  • 言葉を知ってるのは8割
  • マニフェストを知ってるのは半分
    • やってる人でも6割しか知らない
  • 12の原則知ってるのはやってる人なら半分
  • 情報収集特に何もしてない割合が増えてる
    • 昔はやりたい人がやってた
    • 今は意思に関係なく放り込まれるケースが増えた？
  • 資格はもってないがほとんど
  • アジャイルの経験有無は3〜4割り程度
  • 経験プロジェクト数は1が半分で2が3割くらい
  • スクラム8割XP2割
  • 期待と効果
    • アジャイルコーチとSMは期待と効果のブレが小さい
  • アジャイル評価のメトリクス
    • スケジュール
    • 品質
    • 障害件数
  • 難しいところ
    • 人材
    • スキル
    • 顧客の理解
      • これは年々下がってる
  • やめた理由はプロジェクト終了がほとんど

エンジニアが転生して、異世界でアジリティを高めようとしたら最高だった件 シーズン２

• Kazunori Moritaさん
• Keiji Kikuchiさん
• Kentaro Masudaさん
• Masahiro Taguchiさん

大人数チームでの開発

• ゲームだとデザイン系の種類が多い
• 物量で押すから人数は増える
• GitHubだとassetの容量が足りない
  • 専用のサービスがある
• 振り返りで気がつくとプロダクトの話ばかりしている
  • プロセスの話だけしてるのもよくない
• ゲームはある程度属人性が必要

バックログ

• 段階を分けることがある
  • 仮作成/修正調整/本作成
• 一発で作れることはない
• 調整期間を設けてる
• 中間は仮でまず一通り通す
• 体験駆動で進める