正しいものを正しくつくる

7.7K Views

September 16, 16

スライド概要

2023年1月14日 update

2016年10月25日 PMCONF発表
http://pmconf.jp/

2016年09月16日 デブサミ関西2016発表
http://event.shoeisha.jp/devsumi/20160916/

シェア

またはPlayer版

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

関連スライド

各ページのテキスト
1.

正しいものを 正しくつくる Beyond Agile Ichitani Toshihiro 市⾕聡啓

2.

問い Toshihiro Ichitani All Rights Reserved.

3.

我々は、 ⽬的に叶うプロダクトを 適した⼿段で どれほどつくれているのか Toshihiro Ichitani All Rights Reserved. Photo credit: amortize via Visualhunt.com / CC BY-NC-SA

4.

Toshihiro Ichitani All Rights Reserved.

5.

60年前から変わらない 間違ったモノづくり Toshihiro Ichitani All Rights Reserved.

6.

テーブルの端から端までの クラスファイル 天井から地⾯まで 届くWBS 1時間を超える朝会 Toshihiro Ichitani All Rights Reserved. 「リーン開発の現場」オーム社刊

7.

間違ったものを 間違いながらつくる Do the Wrong things Wrong = DWW Photo credit: jaumescar via Visual Hunt / CC BY-NC-SA Toshihiro Ichitani All Rights Reserved.

8.

DWWな、サービスづくり 想定ユーザーは実在するのか 想定課題を持っているのか 課題解決ができるのか そもそもその課題は解決に 値するものなのか…に答えていない 分かっていないことが多い中で 昔ながらのフェーズゲート開発 要件定義フェーズ→外部設計フェーズ→… Toshihiro Ichitani All Rights Reserved.

9.

分かったふり開発 Photo via Visual Hunt Toshihiro Ichitani All Rights Reserved.

10.

DWWな、業務システムづくり 個別最適化された業務を維持する ための「前と同じで」開発 ⽬的が関係者で共通認識化していない 声の⼤きい⼈基準の意思決定 閉塞感を打破するためのキーワード 「アジャイルの導⼊」 そして、抵抗 Toshihiro Ichitani All Rights Reserved.

11.

気持ち反復開発 Photo via Visual Hunt Toshihiro Ichitani All Rights Reserved.

12.

「分からない開発」をするには 受託開発はさらに分が悪い 分からないことを 分からない⼈同⼠でつくる︕ Photo via Visual Hunt Toshihiro Ichitani All Rights Reserved.

13.

⽬的に叶っているかどうか 怪しいモノを 間違ったやり⽅で 開発し続けられるほど 事業に許される時間も ヒトの⼈⽣も⻑くない Photo credit: peretzp via Visualhunt.com / CC BY-SA Toshihiro Ichitani All Rights Reserved.

14.

プロダクト開発は どのような状況で どのように作れば正しいか という回答を持っていない Toshihiro Ichitani All Rights Reserved. Photo via Visual Hunt

15.

プロダクト開発は 何が確からしいかを探し どう作るのが適しているか を繰り返し問い続けるしかない Toshihiro Ichitani All Rights Reserved. Photo via Visual Hunt

16.

間違ったものを 間違いながらつくる = への終⽌符 アジャイル開発 Toshihiro Ichitani All Rights Reserved.

17.

間違ったものを 間違いながらつくる = への終⽌符 アジャイル開発 なのか︖ Toshihiro Ichitani All Rights Reserved.

18.

Toshihiro Ichitani All Rights Reserved. http://agilemanifesto.org/iso/ja/manifesto.html

19.

話した⽅が、早く分かる Toshihiro Ichitani All Rights Reserved. http://agilemanifesto.org/iso/ja/manifesto.html

20.

動かした⽅が、早く分かる Toshihiro Ichitani All Rights Reserved. http://agilemanifesto.org/iso/ja/manifesto.html

21.

協調した⽅が、早く⾏ける Toshihiro Ichitani All Rights Reserved. http://agilemanifesto.org/iso/ja/manifesto.html

22.

⽬の前の事実に従う⽅が 早く⾏ける Toshihiro Ichitani All Rights Reserved. http://agilemanifesto.org/iso/ja/manifesto.html

23.

アジャイル開発とは 「分かった」を早く増やす作戦 Toshihiro Ichitani All Rights Reserved. http://agilemanifesto.org/iso/ja/manifesto.html

24.

型としてのスクラム プロダクトオーナー スクラムマスター チーム ステークホルダー プロダクトバックログ デイリースクラム 動くソフトウェア 2week 反復 スプリントレビュー 次の スプリントへ スプリントバックログ スプリント開発 ふりかえり 軽量、理解が容易、習得が困難 Toshihiro Ichitani All Rights Reserved.

25.

型としてのスクラム 軽量、理解が容易、習得が困難 Toshihiro Ichitani All Rights Reserved.

26.

型としてのスクラム 正しくつくる Toshihiro Ichitani All Rights Reserved.

27.

型としてのスクラム 正しいもの を︖ プロダクトオーナー スクラムマスター チーム ステークホルダー 正しくつくる スプリント開発 ふりかえり スクラムは 正しいものを連れてきてくれるのか︖ Toshihiro Ichitani All Rights Reserved.

28.

いくら型通りに 正しく作っていても 間違ったモノを つくる限り ⽬的を果たすことは 無い Photo credit: Rich B-S via Visualhunt / CC BY Toshihiro Ichitani All Rights Reserved.

29.

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

30.

間違ったものを正しくつくる 間違っているか︖という問い⾃体が 存在しない(こういうもんだ) 当然だが、プロダクトオーナーが 正解を持っているわけではない 確からしさを探し求めるための 仮説検証が無い、経験が無い Toshihiro Ichitani All Rights Reserved.

31.

仮説検証アプローチ 仮説の⽴案 学びの実装 仮説の検証 検証からの学び Toshihiro Ichitani All Rights Reserved.

32.

理想的なプロダクトオーナー 仮説検証に⻑けており⼗分な 知識と経験がある しかも、新規事業や新規サービス づくりのタイミングで運良く 稼働が空いている︕ “プロダクトオーナー” とは、 都合の良い概念でしかない Toshihiro Ichitani All Rights Reserved.

33.

⼀⽣かけて、 稲作、たかだか60回 ソフトウェア開発、たかだか300⼈⽉ 新規事業、年間でたかだか1つ2つ︖ 1⼈が新規事業に携われる数とは︖︖ Toshihiro Ichitani All Rights Reserved.

34.

スクラムの中だけでは 正しいものを探せる芽はない スクラムが押し込んだ “プロダクトオーナー”の向こう側に 正しいものを探す可能性がある Toshihiro Ichitani All Rights Reserved.

35.

忠誠を誓う対象は、 アジャイルでも、 エヴァンジェリストの⾔うことでも、 会社の上司でも、 ユーザーでもない。 ⽬的に忠誠を誓う。 ⽬的のために、 Toshihiro Ichitani All Rights Reserved.

36.

越境せよ。 Toshihiro Ichitani All Rights Reserved.

37.

正しいものを 正しくつくる Do the Right things Right = DRR Toshihiro Ichitani All Rights Reserved.

38.

正しさとは何か︖ Toshihiro Ichitani All Rights Reserved.

39.

正しさは、絶対的には存在しない 正しさは、相対的に存在する 正しさとは、⽬的への適合度合い Toshihiro Ichitani All Rights Reserved.

40.

Start with Why 何のために やる Whyを実現 する⼿段 具体的な アクション Why How What ゴールデン・サークル Toshihiro Ichitani All Rights Reserved.

41.

正しいものを探す Toshihiro Ichitani All Rights Reserved.

42.

正しいものを探すためのアプローチ① 顧客開発 スティーブン・G・ブランク⽒が提唱する⽅法論。 ⼈、資⾦、時間を投⼊したにも関わらず必要とされないプロダクトを 開発してしまったという従来型の事業開発の失敗を回避するプロセス。 「顧客の声」を聞きながら進めていくモデル。 顧客発⾒ 顧客実証 (価値検証) (成⻑検証) 顧客開拓 組織構築 ピボット (軌道修正) 従来の事業開発である、 ①組織構築(営業体制、開発体制)→②顧客開拓(営業)→③顧客実証(販売)→④顧客発⾒(ニーズ充⾜) とは逆の流れが「顧客開発」 顧客が発⾒できた後(仮説の検証後)に、組織をつくる。 Toshihiro Ichitani All Rights Reserved.

43.

正しいものを探すためのアプローチ② リーンスタートアップ スティーブン・G・ブランクの顧客開発モデルをベースに エリック・リース⽒が実践したプロダクト開発の⽅法論。 「Minimum Viable Product(実⽤最⼩限のプロダクト)」による 仮説検証を⾏う。プロダクトの全てを想定で作りきってしまう のではなく、検証による学びを積み重ね、ユーザーに必要と されるプロダクトに近づいていく考え⽅。 Idea 学習 構築 (Learn) (Build) Data Code 計測 如何にしてBuild-Measure-Learnのサイクルを 無駄なく、素早く回すかに集中する。 (Measure) Toshihiro Ichitani All Rights Reserved.

44.

事業やプロダクト作りのための 仮説検証型アジャイル開発 選択の幅最⼤ (セットベース) 検証 計画 仮説⽴案 (モデル化) 価値探索 スプリント プランニング 検証 (正しいものを探す) 評価 仮説検証 選択肢を⼗分に 広げた後に絞る MVP特定 開発計画 (リリースプラ ンニング) 選択の振れ幅最⼩ (ポイントベース) スプリント 開発 アジャイル開発 (正しくつくる) スプリント レトロスペク ティブ MVP検証 スプリント レビュー アジャイル 構想を早く形にして フィードバックを得る 次の価値探索へ

45.

仮説キャンバス 仮説 ユーザーインタビュー ユーザーストーリー マッピング 検証 検証 Toshihiro Ichitani All Rights Reserved.

46.

仮説キャンバス Toshihiro Ichitani All Rights Reserved.

47.

ユーザーストーリーマッピング ストーリーの優先度=重要かつ未検証 Toshihiro Ichitani All Rights Reserved.

48.

事業やプロダクト作りのための 仮説検証型アジャイル開発 選択の幅最⼤ (セットベース) 検証 計画 仮説⽴案 (モデル化) 価値探索 スプリント プランニング 検証 (正しいものを探す) 評価 仮説検証 選択肢を⼗分に 広げた後に絞る MVP特定 開発計画 (リリースプラ ンニング) 選択の振れ幅最⼩ (ポイントベース) スプリント 開発 アジャイル開発 (正しくつくる) スプリント レトロスペク ティブ MVP検証 スプリント レビュー アジャイル 構想を早く形にして フィードバックを得る 次の価値探索へ

49.

事業やプロダクト作りのための 仮説検証型アジャイル開発 選択の幅最⼤ (セットベース) 検証 計画 仮説⽴案 (モデル化) 価値探索 (正しいものを探す) 評価 アイデア段階のため 何をつくるべきか 選択肢の幅は広い 仮説 スプリント プランニング 検証 MVP特定 開発計画 (リリースプラ ンニング) 選択の振れ幅最⼩ (ポイントベース) スプリント 開発 アジャイル開発 (正しくつくる) スプリント レトロスペク ティブ MVP検証 スプリント レビュー 次の価値探索へ

50.

事業やプロダクト作りのための 仮説検証型アジャイル開発 選択の幅最⼤ (セットベース) 検証 計画 仮説⽴案 (モデル化) 価値探索 スプリント プランニング 検証 MVP特定 (正しいものを探す) 評価 選択の振れ幅最⼩ (ポイントベース) アイデア段階のため 検証結果を踏まえて 何をつくるべきか 何をつくるべきかの 選択肢の幅は広い 選択肢は狭まる 仮説 開発計画 (リリースプラ ンニング) エピック スプリント 開発 アジャイル開発 (正しくつくる) スプリント レトロスペク ティブ MVP検証 スプリント レビュー 次の価値探索へ

51.

事業やプロダクト作りのための 仮説検証型アジャイル開発 選択の幅最⼤ (セットベース) 検証 計画 仮説⽴案 (モデル化) 価値探索 スプリント プランニング 検証 MVP特定 (正しいものを探す) 評価 アイデア段階のため 何をつくるべきか 選択肢の幅は広い 仮説 開発計画 (リリースプラ ンニング) 選択の振れ幅最⼩ (ポイントベース) 検証結果を踏まえて 何をつくるべきかの 選択肢は狭まる エピック スプリント 開発 アジャイル開発 (正しくつくる) スプリント レトロスペク ティブ MVP検証 スプリント レビュー 次の価値探索へ どうなれば完成と いえるのか条件が定義 可能となるまで詳細化する ストーリー

52.

探索と適応のための組織能⼒ 何をつくるべきかが分かるのは段階的 仮説→エピック→ストーリーと 仮説検証とアジャイル 詳細化・分割し、開発可能にする 選択の幅最⼤ (セットベース) 検証 計画 仮説⽴案 (モデル化) 価値探索 スプリント プランニング 検証 MVP特定 (正しいものを探す) 評価 アイデア段階のため 何をつくるべきか 選択肢の幅は広い 仮説 開発計画 (リリースプラ ンニング) 選択の振れ幅最⼩ (ポイントベース) 検証結果を踏まえて 何をつくるべきかの 選択肢は狭まる エピック スプリント 開発 アジャイル開発 (正しくつくる) スプリント レトロスペク ティブ MVP検証 スプリント レビュー 次の価値探索へ どうなれば完成と いえるのか条件が定義 可能となるまで詳細化する ストーリー

53.

正しいものを 正しくつくる = 分かったことを 正しくつくる Do the Right things Right = DRR Toshihiro Ichitani All Rights Reserved.

54.

分かったことを、正しくつくる 正しいかどうかの判断は難しいが 分かっているかどうかは判断できる いかに早く、安価に、分かることを 増やせるかで検証⼿段を選ぶ 検証と価値提供の分離。 検証するためと、価値提供のための プロダクトは質もスコープも異な る。 Toshihiro Ichitani All Rights Reserved.

55.

MVP vs MKP 学びを得ることと、価値提供を、混同しない Minimum Viable Product (MVP) Most Knowing Product (MKP) 実⽤的で最⼩限の範囲 分かっている最⼤限の範囲 = 検証のために必要な最⼩限の製品 (分かっていないことを分かるための⼿段) = ユーザーにとって価値があると 分かっている範囲で最⼤限の製品 分かっていないこと 分かっていること 分かっていないこと MKP MVP Toshihiro Ichitani All Rights Reserved.

56.

「重いMVP」問題 つくる 計測し 決める つくる 計測し 決める MVPが重たくなりがち (ファーストリリース から事業がはじまってしまう) = つくる→はかる→わかるのリードタイムが ⻑くなる = コンセプト負債が⾼まる(検証ができない まま事業運⽤が進んでしまう問題) Toshihiro Ichitani All Rights Reserved.

57.

利⽤者の⽅をみた判断をする さがす さがす 学び さがす さがす さがす つくる 学び さがす さがす さがす さがす さがす さがす 学び さがす 利⽤者へ価値提供をはじめる(事業開始)時に 利⽤者と市場を失望させても良いことない 早く、短く、何度も実験した後につくる (当然QCDSの制約との整合性は取る) Toshihiro Ichitani All Rights Reserved.

58.

間違ったものを間違いながらつくる そもそもまともなプロダクトが完成しない Toshihiro Ichitani All Rights Reserved.

59.

間違ったものを正しくつくる 分かっていないことを分かっている前提で 作ってしまう Toshihiro Ichitani All Rights Reserved.

60.

正しいものを 正しくつくる = 分かったことを 正しくつくる Do the Right things Right = DRR Toshihiro Ichitani All Rights Reserved.

61.

正しいものづくりに 正解は無く 問いのみがある Toshihiro Ichitani All Rights Reserved. Photo via Visual Hunt

62.

我々は、 ⽬的に叶うプロダクトを 適した⼿段で どれほどつくれているのか Toshihiro Ichitani All Rights Reserved. Photo credit: pagarneau via Visualhunt / CC BY-NC