探索型のプロダクト開発を始めよう

11.5K Views

February 16, 24

スライド概要

デブサミ2024セッション

シェア

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

関連スライド

各ページのテキスト
1.

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

2.

市⾕ 聡啓 Ichitani Toshihiro チーム、部署、事業、組織でのアジャイル適応⽀援 (株式会社レッドジャーニー) 特に専⾨は 「仮説検証、アジャイル開発、組織アジャイル」 この数年の取り組み ⾏政でのアジャイル、⼤企業DX・組織変⾰ (製造・製薬ほか多数) 地域DX (地域企業のコミュニティ) Toshihiro Ichitani All Rights Reserved. 2

3.

Toshihiro Ichitani All Rights Reserved. 3

4.

プロダクト開発とは何か︖ Toshihiro Ichitani All Rights Reserved. 4

5.

ソフトウェアを作ること︖ Toshihiro Ichitani All Rights Reserved. 5

6.

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

7.

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

8.

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

9.

間違ったものを 正しくつくる Do the Wrong things Right Photo credit: BeaLeiderman via VisualHunt.com / CC BY-NC-SA Toshihiro Ichitani All Rights Reserved.

10.

何をもって “正しい” のか︖ Toshihiro Ichitani All Rights Reserved. 10

11.

“プロダクトを作る” はアウトプット⽌まり チーム アウトプット (プロダクト) Toshihiro Ichitani All Rights Reserved. 11

12.

”プロダクトを届ける” だけでもダメ チーム アウトプット (プロダクト) ユーザー 使えている︖ 役に⽴っている︖ Toshihiro Ichitani All Rights Reserved. 12

13.

“アウトカム” が発⽣しているかどうか チーム アウトプット (プロダクト) ユーザー アウトカム プロダクトの利⽤によって ⽬的を果たし成果となる Toshihiro Ichitani All Rights Reserved. 13

14.

アウトカムとは収益のこと︖ Toshihiro Ichitani All Rights Reserved. 14

15.

収益とは「動⼒源」である プロダクト作りを持続・発展させるために必要 それゆえに「⽬的」そのものにはならない Toshihiro Ichitani All Rights Reserved. 15

16.

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

17.

前をみよう。 それは、成果を捉え直すということ。 Toshihiro Ichitani All Rights Reserved. Photo via Austin Ban via VisualHunt.com

18.

プロダクト開発における「成果」とは︖ 3つ考えられる ︖︖︖ ︖︖︖ ︖︖︖ Toshihiro Ichitani All Rights Reserved. 18

19.

プロダクト開発における「成果」とは︖ ユーザーに価値や意味がもたらされる状態 ユーザー プロダクトを利⽤する⼈が 必要な⽬的を果たせること ︖︖︖ ︖︖︖ Toshihiro Ichitani All Rights Reserved. 19

20.

プロダクト開発における「成果」とは︖ その価値実現が持続可能であること︕ ユーザー プロダクトを利⽤する⼈が 必要な⽬的を果たせること チーム プロダクト プロダクトを提供し続けられる 利⽤可能でユーザーに価値を チームであること。つまりチームが 提供できること。つまりプロダクトが 健全であること 健全であること Toshihiro Ichitani All Rights Reserved. 20

21.

チームとプロダクトの健全性なくして プロダクトの持続的な提供はできない ゆえに、ユーザー/チーム/プロダクト 健全性を保つことが「成果」と⾔える Toshihiro Ichitani All Rights Reserved. 21

22.

でも…チームもプロダクトも ⽬的ではなく「⼿段」なんじゃない︖ Toshihiro Ichitani All Rights Reserved. 22

23.

でも…チームもプロダクトも ⽬的ではなく「⼿段」なんじゃない︖ ⾮プロダクト的思考 Toshihiro Ichitani All Rights Reserved. 23

24.

チームが疲弊しきっていて、 ユーザーの嬉しさを考えることができる︖ プロダクトが負債で⾝動き取れずで、 価値提供を約束し続けられる︖ アウトカム ユーザー チーム プロダクト Toshihiro Ichitani All Rights Reserved. 24

25.

ユーザー/チーム/プロダクトの 健全性を維持するためには︖ 3者に共通するのは常に⼀定同じではなく 「変化する」ということ Toshihiro Ichitani All Rights Reserved. 25

26.

ゆえに、問い直し続けたいのは 今、採⽤している判断は いつの根拠に依るものか︖ いつ得た事実を元に判断しているのか︖ Toshihiro Ichitani All Rights Reserved. 26

27.

はるか遠い昔に得た情報を頼りに 今の判断をしていないか︖ その事業判断、機能 開発の根拠にしている ユーザー情報はいつ 得たもの︖ プロダクト開発の あり⽅とやり⽅を うちのチームの「強み」 とは何で、それは今でも 最後に⾒直したのは いつだっけ︖ 通⽤してるんだっけ︖ Toshihiro Ichitani All Rights Reserved. 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.

どのくらい準備して、探索始めるべき︖ どのくらい稼働するか、とか決め事が 結構ありそうなんだけど… Toshihiro Ichitani All Rights Reserved. 33

34.

どのくらい準備して、探索始めるべき︖ どのくらい稼働するか、とか決め事が 結構ありそうなんだけど… 最適化の罠 (ちゃんと考えないうちは進めない問題) Toshihiro Ichitani All Rights Reserved. 34

35.

まず、探索バックログの 最初の1つを積むところから︕ いままでやったこと無いことは始めるのだから 最初から効率よくスマートになんていかない むしろ、スクラムに乗せるのは2周⽬、3周⽬で マチュリティを⾼めていくのが狙いなのだから Toshihiro Ichitani All Rights Reserved. 35

36.

⾃分たちが熱意を持てるものを まず1つ選んで、始める ことを薦めます Toshihiro Ichitani All Rights Reserved. 36

37.

同胞たちよ、 Photo on Visual hunt

38.

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

39.

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

40.

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

41.

同胞たちよ︕ Photo credit: nunodantas on Visualhunt.com / CC BY-NC-SA

42.

ここ(デブサミ)は 20年の時を刻んできた場所だ https://codezine.jp/devsumi/2003 Toshihiro Ichitani All Rights Reserved. 42

43.

僕らは デブサミの度に “世界” を変えてきた と思う Toshihiro Ichitani All Rights Reserved. 43

44.

デブサミが世界を 変えるのではない Toshihiro Ichitani All Rights Reserved. 44

45.

デブサミが世界を 変えるのではない デブサミから帰っていく ﹅ ﹅ ﹅ ﹅ ﹅ おのおのが⾃分の世界を ﹅ ﹅ ﹅ おのおのとして変えてきたんだ Toshihiro Ichitani All Rights Reserved. 45

46.

だからね、 Photo credit: Risto Kuulasmaa on Visualhunt

47.

「成果」を誰かに 決めてもらうだけの世界線は 終わらせよう。

48.

⾃分のハンドルは ⾃分で握れ Toshihiro Ichitani All Rights Reserved. 48

49.

Our Journey Continues ! Photo on Visual hunt