探索型のプロダクト開発を始めよう

16.3K Views

February 16, 24

#正しいものを正しくつくる #devsumi #プロダクト開発 #アジャイル #仮説検証 #OKR #プロダクト探索

スライド概要

デブサミ2024セッション

市谷聡啓

@papanda

スライド一覧

白と黒の魅惑

またはPlayer版

埋め込む »CMSなどでJSが使えない場合

ダウンロード

ダウンロード(pdf - 23.05MB)

関連スライド

これまでの仕事これからの仕事

これこれ仕事

市谷聡啓 230.1K

はじめてのアジャイル開発入門

agile

市谷聡啓 197.8K

シン・正しいものを正しくつくる (MVP Edition)

agile 仮説検証

市谷聡啓 78.1K

832イテレーション・ジャーニー

agile

市谷聡啓 41.8K

ナラティブ・プロトタイピング

narapro

市谷聡啓 39.1K

アジャイル開発は世界を変える夢を見るか

シンアジャイル

市谷聡啓 38.4K

各ページのテキスト

探索型のプロダクト開発を始めよう Ichitani Toshihiro 市⾕聡啓

プロダクトソフトウェア・期待 (仕様) 通りに動くこと・利⽤者の⽬的を果たし価値をもたらすこと・期待がはっきりしてるから・そもそも何と整合を取れば要件も仕様もあらかじめどんな価値があるのか決められる（前提）はっきりとはしていない・前提として必要なのは、要件定義であり仕様決定・前提として必要なのは、価値とは何か︖の仮説検証・「作る」→「使える」・「使う(試す)」→「作る」・担い⼿は、・担い⼿は、ソフトウェア開発チームプロダクトチーム Toshihiro Ichitani All Rights Reserved. 6

…なので、俺たちの “Scrum” でプロダクトオーナースクラムマスター開発者プロダクトバックログステークホルダーデイリースクラムスプリントスプリントプランニングレビュースプリントバックログスプリントインクリメントスプリントレトロスペクティブ正しくつくる︕

プロダクトオーナープロダクトえいやっ︕ バックログスクラムマスター開発者プロダクトバックログステークホルダーデイリースクラムスプリントプランニングスプリントバックログスプリントスプリントちゃんとスクラムレビューインクリメントスプリントレトロスペクティブ

10.

11.

12.

13.

14.

15.

16.

収益とは「結果」であるゆえに「結果」のみを⽬標に置き、諸活動を最適化してしまうと… 「バックミラー」だけを⾒て運転するようなものつまり、「遅⾏指標」による管理が強く、動きが遅い上に、肝⼼の「アウトカム」の⾏⽅が不明瞭になる (価値があるかではなく儲かるか) Toshihiro Ichitani All Rights Reserved. Photo credit: arty822 on VisualHunt 16

17.

18.

19.

20.

21.

22.

23.

24.

25.

26.

27.

28.

はるか遠い昔に得た情報を頼りに「プロダクト探索」に出よう。今の判断をしていないか︖ その事業判断、機能 “分かっている” ことだけ作り続けてもジリ貧になるいかに “分かっていない” ことに踏み込んで、情報・知識を得るか︖ 開発の根拠にしているユーザー情報はいつ得たもの︖ 探索とは、新たな学びを得ることプロダクト開発のうちのチームの「強み」とは何で、それは今でもあり⽅とやり⽅を最後に⾒直したのはいつだっけ︖ 通⽤してるんだっけ︖ Toshihiro Ichitani All Rights Reserved. 28

29.

「プロダクト探索」の歩き⽅ユーザー調査結果、チームのふりかえり記録、 Four keys などのプロダクト指標の計測結果ユーザーに関する「仮説」を⽴てる成果とは何かにむきあうチームに関する「仮説」を⽴てる探索活動(仮説検証)をバックログに積むプロダクトに関する「仮説」を⽴てるユーザー/チーム/プロダクトの3つの軸でOKRを⽴てるプロダクトチームユーザーバックログバックログバックログ仮説キャンバスで何がボトルネックか仮説⽴てる Toshihiro Ichitani All Rights Reserved. バックログ化することで探索を開発と運⽤と同じ運営で扱えるようにする 29

30.

「プロダクト探索」の歩き⽅ユーザー調査結果、チームのふりかえり記録、 Four keys などのプロダクト指標の計測結果そもそもの成果の定義活動が偏らないようにバックログ⾃体を分ける・ユーザー、チーム、プロダクトの3観点で⼗分か︖ ユーザーに関する・とはいえ「収益は」何で扱うか︖ (→KGI/KPI設定) ・「成果」と「収益」を混ぜ込まない「仮説」を⽴てるプロダクトチームユーザー成果とは何かにむきあうバックログバックログバックログ⽬標と評価指標を決める探索活動をチームに関する「仮説」を⽴てるバックログに積む・3観点で何が実現できれば良いか︖→ 具体的⽬標・到達度をどのようにして判断するか︖→評価指標プロダクトに関する・ゆえに、OKRがフィットする「仮説」を⽴てるユーザー/チーム/プロダクトの3つの軸でOKRを⽴てる (仮説検証) バックログ化することで探索を開発と運⽤と同じ運営で扱えるようにする最適化と探索を⾒分ける仮説キャンバスで何がボトルネックか仮説⽴てる・分かっている情報で改善/向上させること=最適化・実現のための⼿段⽅法が明らかではなく、せいぜい仮説が⽴てられること = 探索・どちらの⽬標もありだが最適化に圧倒されない Toshihiro Ichitani All Rights Reserved. 30

31.

「プロダクト探索」の歩き⽅ユーザー調査結果、チームのふりかえり記録、 Four keys などのプロダクト指標の計測結果活動が偏らないようにバックログ⾃体を分けるユーザーに関する「仮説」を⽴てるチームに関する「仮説」を⽴てるプロダクトに関する「仮説」を⽴てる仮説キャンバスで何がボトルネックか仮説⽴てる仮説⽴案のための「調査」・そもそも仮説を⽴てるための最⼩限の調査やプロダクトチームユーザー指標計測は⼀定必要。まずここから始める。バックログバックログバックログ・情報不⾜により「浅い仮説」となってしまう場合探索活動 (仮説検証)をは仮説⽴案を早々に切り上げて調査や計測に⽐重バックログに積むを置いたバックログから始める。仮説を磨く道具の使い分けバックログ化することで・ユーザーの仮説は仮説キャンバスやカスタマー探索を開発と運⽤と同じ運営でジャーニーマップで磨く扱えるようにする・チームの仮説はFrom(現状)〜To(理想)の2軸から Gapや可能性を⾒つける・プロダクトの仮説はバリューストリームマップでボトルネックの特定から始める・つまり、使う道具は3観点で異なる Toshihiro Ichitani All Rights Reserved. 31

32.

「プロダクト探索」の歩き⽅ OKR→仮説→バックログプロダクトチームユーザーバックログバックログバックログ探索活動(仮説検証)をバックログに積むバックログ化することで探索を開発と運⽤と同じ運営で扱えるようにする・ユーザー/チーム/プロダクトの観点で3つのOKRを設定し、その実現・到達のための仮説を⽴てる・ユーザー検証 (ユーザーインタビューやテスト等) やチームのための施策試⾏, 技術検証など必要な活動をバックログとして積み上げる探索もスクラムする・探索もスプリントによる検査適応を基本とする・開発や運⽤などのバックログやタスクと同様にチームのメインワークとして探索を取り⼊れる・他の活動との間で稼働量のバランスを取れるようにする。プランニングで同じ⼟俵の上に乗せる・探索もレトロスペクティブの対象にする Toshihiro Ichitani All Rights Reserved. 32

33.

34.

35.

36.

37.

同胞たちよ、 Photo on Visual hunt

38.

新たな成果をあげていくには新たな武器 (知識) は必要 “違い” が⾒分けられるか︖ 「学ぶこと」を置き去りにしたプロダクト開発は早晩⾏き詰まる

39.

「収益」とは「動⼒源」であって⽬的にはならないいつの間にか、ユーザー、チーム、プロダクトが置き去りになってしまう …ということにも気づかない “バックミラー” で駆動するプロダクト開発では早晩事故る

40.

「成果とは何か︖」から “むきなおり” を始めようユーザーを、チームをプロダクトを変える Now 成果=収益︖