スクラムフェス金沢2025

初めてのプロダクトオーナー エンジニア出身者が挑む、価値最大化への挑戦と学び 1

わたしのこと ❏ 名前：岡島一樹 ❏ 所属：永和システムシステムマネジメ ント@福井県 ❏ 本業：エンジニア、受託開発のプロ ジェクトリーダー ❏ 趣味：運動、鉄道旅行 2

アジャイルアンギャ 2025/9/25-26 ルポの森@福井市 3

福井県ってどこ？ 金沢市 ルポの森 ↓ 福井市 4

本日お話すること ❏ タウンデジボとプロダクトオーナー ❏ チームが経験した苦い思い出 ❏ チームの学びと工夫 ❏ 本日持ち帰って頂きたいこと 5

本日の目標 エンジニアがPOやる際の 参考事例となれば良いな 6

タウンデジボと プロダクトオーナー

なぜプロダクトオーナーに？ 2年前に チームが発足 8

なぜプロダクトオーナーに？ ❏ 様々なアイデアの中からタウンデジボ（電子回覧板サービス） のプロジェクト化が決定 ❏ 受託開発を生業としてきた自分にとって初めての自社プロダクト ❏ プロダクトを企画の段階から考えれる機会は今しかない ぜひやりたい！ 9

プロダクトオーナーの役割 対外部 ❏ ❏ ❏ 対チーム 顧客・ユーザーの ❏ プロダクトビジョンの提示 ニーズの調査 ❏ プロダクトバックログの 顧客・ユーザー等との 作成 調整事 ❏ 優先順・リリース計画 その他諸々・・・ ❏ その他諸々・・・ 10

プロダクトオーナーの役割 ひとりで全部こなすのは難しい・・・ 11

わたしたちは役割を分けている 対外部 ❏ ❏ ❏ 対チーム わたし 顧客・ユーザーの ❏ プロダクトビジョンの提示 ニーズの調査 ❏ プロダクトバックログの 顧客・ユーザー等との 作成 会話 調整事 ❏ 優先順・リリース計画 その他諸々・・・ ❏ その他諸々・・・ 12

実証実験の開始が決定 ○○地区 実証実験フィールドの提供 ◎◎市自治会連合会 △△地区 タウンデジボの提供・サポート □□地区 (対応事項) タウンデジボの提供 (対応事項) 実証実験状況の 連合会全体への共有 (対応事項) 実証実験フィールドの提供＆評価 ・地域地区住民への実証実験の周知 ・タウンデジボの利用 ・タウンデジボの評価協力 ・モデル地区に対する実証実験の説明 ・タウンデジボの初期設定サポート ・タウンデジボの操作についてのサポート ・タウンデジボの改善 13 13

さきのこと × タウンデジボ 【企画開始】 ❏ 2023年11月：企画コンセプト検討 ❏ 2023年12月：開発開始 ❏ 2024年3月：デザインコンセプト確定 14

初めてのリリース Web版 スマホアプリ版 昨年6月リリース 15

これまでの主なリリース 【リリース】 ❏ 2024年6月：運営連絡機能 ❏ 2024年8月：運営連絡アンケート機能 ❏ 2024年10月：電子回覧板のメイン機能 ❏ 2024年12月：サブユーザー機能 ❏ 2025年3月：お気に入り機能 16

チームの決まりごと 通常リリースは週1回 ❏ 障害対応や レビューは毎日 ❏ 軽微な機能改善 ❏ 軽微な機能追加 ❏ 大きな機能も最大2ヶ月 毎日検証用のアプリ を作ってチームで レビュー 毎日フィードバック ❏ 1度に詰め込みすぎな い ❏ 細かいリリースの方が ユーザーの声を拾いや すい すべてが順調？ 17

チームが経験した 苦い思い出

チームが経験した苦い思い出 ❏ チーム立ち上げ時期の失敗 ❏ プロダクトバックログが設計みたいに見える ❏ 優先度の付け方に悩む 19

チームが経験した苦い思い出① ❏ チーム立ち上げ時期の失敗 ❏ プロダクトバックログが設計みたいに見える ❏ 優先度の付け方に悩む 20

最初のリリース計画の失敗 企画 PoC 開発 審査 1st ここで計画した 21

なぜその時期に？ ❏ 実証実験の開始が決まっていた ❏ 実証実験に協力してくれるユーザーの存在 ❏ 初めて組んだチームにも関わらず、 大きくはブレないだろうという根拠のない自信 22

結果はどうだった？ 1stリリースまでに かけた労力は計画の 約2倍 引用：プロジェクトマネジャーのための「プロセス設計術」 - プロジェクトの本質とはなにか：ITpro 全然足りなかった 23

• http://itpro.nikkeibp.co.jp/article/COLUMN/20131001/508039/

チームのスピードが上がらない 誰が見ても 順調とは思わない 24

何が起こっていた？ ❏ スマホアプリは難しい・・・ ❏ 完了しないタスクが続発 ❏ 平均はどんどん遅くなる ❏ チーム内のゆるい空気感 このまま進めても良い？ 25

チーム立ち上げ時期の失敗 予定通りにいかないことばかり 26

チームが経験した苦い思い出② ❏ チーム立ち上げ時期の失敗 ❏ プロダクトバックログが設計みたいに見える ❏ 優先度の付け方に悩む 27

プロダクトバックログが設計みたいに見える 過去の経験 ❏ ❏ ❏ 今回はどうか プロダクトバックログを書いてく ❏ やりたいことは明確 れないPO ❏ エンジニアとしての自分が やりたいことが自分でもよく分か ちらつく らないPO ❏ エンジニア目線で書き始める リファインメント、プランニング ❏ 設計書のようなPBIが完成 に時間がかかりすぎる 28

なにがいけないの？ ❏ エンジニアが考えなくなってしまう プランニングも効果的ではなかった ❏ 私の言葉を盲信してしまう ❏ 些細な気づきなどを見逃す この状態は健全？ 29

チームが経験した苦い思い出③ ❏ チーム立ち上げ時期の失敗 ❏ プロダクトバックログが設計みたいに見える ❏ 優先度の付け方に悩む 30

優先度の付け方に悩む タウンデジボのペルソナ 31

実際のユーザーはこんな人達 ❏ 年齢層は40代〜70代 ❏ ITリテラシーは高くない ❏ アカウント作成でつまづく人も このような人たちに対して 価値の高いこととは何？ 32

優先すべきこと 33

チームの学びと工夫

チームの学びと工夫 ❏ ハプニングは起こるもの ❏ やってほしいことではなく実現したい価値を ❏ 本当に価値のあることの見極め 35

チームの学びと工夫① ❏ ハプニングは起こるもの ❏ やってほしいことではなく実現したい価値を ❏ 本当に価値のあることの見極め 36

初期の見積もりはぶれて当然 こっち側にブレることが ほとんど 引用：プロジェクトマネジャーのための「プロセス設計術」 - プロジェクトの本質とはなにか：ITpro 37

• http://itpro.nikkeibp.co.jp/article/COLUMN/20131001/508039/

どうすれば良かった？ 明確な処方箋があるわけではないが・・・ 38

やってはいけないことをやらない ブレた原因 ❏ ほとんど何も見えてない時にリ ではどうする？ ❏ 初めて組む人たち リース計画した チームとしては未知数 ❏ 根拠のない自信 自分たちを過大評価しない ❏ 自分たちを過大評価 ❏ 見えないタスクを過小評価しない ❏ 品質の作り込みやユーザビリティ ❏ 計画通りいかないことを放置はし の改善タスクが足りない ない 39

この状態からどう巻き返した？ 40

筋トレっぽいことをした 41

チームの筋トレ Sprint5 Sprint6 Sprint7 Sprint8 Sprint9 Sprint10 Sprint11 Sprint12 Sprint13 Sprint14 Sprint15 Sprint16 Sprint17 10.00 12.67 13.33 13.33 12.67 12.00 11.00 12.67 15.33 19.33 19.00 21.33 22.33 計画 → 13 13 16 14 14 14 15 19 22 23 21 29 30 実績 → 14 13 13 12 11 10 17 19 22 16 26 25 30 50 63 76 88 99 109 126 145 167 183 209 234 264 技術的に慣れてきたら 少しだけ過剰に計画 達成できたら少しだけ負荷を上げる 42

筋トレの成果 43

何かしら対処する 計画通りいかないことを放置はしない 44

チームの学びと工夫② ❏ ハプニングは起こるもの ❏ やってほしいことではなく実現したい価値を ❏ 本当に価値のあることの見極め 45

やって欲しいことではなく実現したい価値を ❏ プロダクトバックログ一つ一つについて、ユーザーにとってどの ような価値があるのかをチームにしっかり伝える 引用：Agile Studio アジャイルプラクティスマップ：ユーザーストーリー 46

• https://www.agile-studio.jp/post/apm-user-story

やって欲しいことを言い過ぎない ❏ やり方についてあれこれ言わない ❏ POはタスクの価値についてしっかり検討 ❏ チームもPOに丸投げするのはダメ 47

結果 ❏ チームもユーザー視点に立てるようになってきた ❏ チーム全体がユーザーにとって価値のあるインクリメントになる か意識するようになる 48

チームの学びと工夫③ ❏ ハプニングは起こるもの ❏ やってほしいことではなく実現したい価値を ❏ 本当に価値のあることの見極め 49

機能追加ばかりが価値があるとは限らない ❏ ユーザー層は40代〜70代 ❏ ITリテラシーは高くない ❏ ユーザー登録でつまづく 50

もっとも価値が高かった対応 【世帯主】 ❏ 世帯の代表者 【サブユーザー】 ❏ 配偶者や親・子どもなど ご家族の方のこと 51

ご家族の方の参加方法（今まで） 【世帯主】 招待 【サブユーザー】 お互いの手数が多い 52

不評だった・・・ ❏ 家族ユーザーとサブユーザーがリンクしない →馴染みのない言葉で分かりにくいと不評 ❏ 世帯主の招待制だった →メニュー画面を開いて招待する導線が直感的じゃない 53

修正①呼び方の変更 サブユーザー 家族ユーザー 54

修正②家族が参加するための導線の変更 【1人目は自動的に世帯主】 【2人目以降は自動的に家族ユーザー】 シンプル化 55

効果抜群だった 約15% 約30% たったこれだけの対応 家族ユーザーの参加率が爆増 56

もっとも価値のあることとは？ ❏ 機能の追加よりも、シンプル化こそが最も価値が高い ❏ 今回の例以外にも動線のシンプル化は何度も実施してきた 今では単純な機能追加よりも優先度は高い ❏ ユーザビリティの向上で顧客満足度も向上する 57

本日 持ち帰って 頂きたいこと

エンジニアとしての視点を入れすぎない ❏ エンジニア視点を捨てることも時には大事 チームの領域を侵しすぎるとチームの成長を阻害するおそれ ❏ お互いのことを信頼して領域を侵しすぎない やり方（how）はチームにお任せが一番良い ユーザーの価値最大化のためお互いが行動できれば良い 59

プロダクトに合った価値の最大化を考える ❏ 機能追加だけが価値があることとは限らない ❏ シンプルさを追求することがタウンデジボには合っていた 1割の人だけが便利になる機能は目立たなくて良い ❏ 自分たちよがりではなくユーザーに合ったプロダクトの価値 を考えることが重要 60

スクラムだから実現できることがある ❏ 安定したリリースを繰り返して信頼を得ることがまずは重要 ❏ プロダクトは常に進化が必要 柔軟に、そして継続的に ユーザーにとって真に価値のあるインクリメント を届けることが大事 ❏ 柔軟なフレームワークだから実現できている 61

よいPOライフを！ 62