正しいものを正しくつくる / Do the Right things Right

Slide 1

Slide 1 text

No content

Slide 2

Slide 2 text

(My KeyWord) 市⾕聡啓仮説検証型アジャイル開発正しいものを正しくつくる越境 Ichitani Toshihiro

Slide 3

Slide 3 text

https://ichitani.com/ Proﬁle

Slide 4

Slide 4 text

https://www.amazon.co.jp/dp/4802511191/ 6⽉14⽇発刊

Slide 5

Slide 5 text

https://www.amazon.co.jp/dp/4802511191/ 6⽉14⽇発刊重版決定

Slide 6

Slide 6 text

本⽇の内容第1部「正しいものを正しくつくる」本とは何か第2部アジャイル開発は2度失敗する

Slide 7

Slide 7 text

第1部「正しいものを正しくつくる」本とは何か

Slide 8

Slide 8 text

書籍「正しいものを正しくつくる」をインセプションデッキに載せて紹介します。 ਖ਼͍͠΋ͷΛਖ਼ͭ͘͘͠Δ

Slide 9

Slide 9 text

No content

Slide 10

Slide 10 text

Start with Why

Slide 11

Slide 11 text

「カイゼン・ジャーニーで書けなかったことがある。」

Slide 12

Slide 12 text

われわれはなぜここにいるのか「何をつくるべきか」の仮説検証から開発の在り⽅までを⼀気通貫に扱う書籍が無い。この領域は、5年以上⾃分が取り組んできたことであり棚卸し、まとめることで価値を⽰せそうだ。「⽇本発のアジャイル」をまとめたものが少ない。⽇本の現場で育ったアジャイルのカタチを⽰したい。

Slide 13

Slide 13 text

プロダクトづくりの傍らにあり、迷わぬよう。

Slide 14

Slide 14 text

エレベータピッチ [何の拠り所もない不確実性の⾼いプロダクトづくりに臨む]、 [プロダクトオーナーやプロダクトチーム、関係者]に向けて書かれた [正しいものを正しくつくる] は、 [チームによるプロダクト開発のための本] です。これは、 [構成がジャーニー(実践順)になっているため現実感があり] [⼀部分ではなく仮説検証から開発の在り⽅まで⼀気通貫している]。輸⼊本と違って [⽇本の現場で磨かれた、⽇本発のアジャイルを扱っている]。

Slide 15

Slide 15 text

選択の幅最⼤（セットベース）検証計画仮説⽴案 (モデル化) 検証評価価値探索（正しいものを探す） MVP特定開発計画 (リリースプランニング) スプリントプランニングスプリント開発スプリントレビュースプリントレトロスペクティブ MVP検証アジャイル開発（正しくつくる）仮説キャンバスユーザーインタビュー検証キャンバス (プランニング付近に配置) ＜仮説検証型アジャイル開発の全容＞⽬的選択の段階実体選択の段階⼿段選択の段階次の検証計画 (価値探索)へユーザースストーリーマッピング選択の振れ幅最⼩（ポイントベース）順序選択体験による検証の必要性判断かつ検証のための開発判断検証の始点検証活動検証の終点プロトタイプランディングページ観察アクティングアウト ※掲載⽤作図

Slide 16

Slide 16 text

プロジェクトコミュニティ (著者) 市⾕聡啓 (編集者) 村⽥さん市⾕妻 (レビューア) 篠原さん (レビューア) ⿊⽥さん (レビューア) ⼩⽥中さん (レビューア) 吉村さん (レビューア) 沼⽥さん (レビューア) 増⽥さん

Slide 17

Slide 17 text

No content

Slide 18

Slide 18 text

やらないことリストカイゼン・ジャーニーの「物語」形式の踏襲。ただし、内容⾃体が実践順に基づく「ストーリー」。⾃⾝が経験していないことを書く。共著（単⾝ですべての⾔葉を背負うため）。徹夜（健康のため）。

Slide 19

Slide 19 text

パッケージデザイン

Slide 20

Slide 20 text

LPが先⾏。”暗闇の中で光指す”

Slide 21

Slide 21 text

パッケージデザイン

Slide 22

Slide 22 text

技術的解決策「ぼっちでやる」苦しさと、楽しさ。 →苦労したのは1章4章。楽しみながら書いたのは3章。縦書き。 →読み⼿の⽬⽟の動きを重⼒で邪魔しないようにする。 note、twitterで指を鍛える。 →どれほど忙しくても、⽇々⽋かさない。増⽥さんとの対話。村⽥さんへの説明。 →レビューを通した対話が深い思考、説明責任が分かりやすさを求める。執筆中は本を読まない。 →⽂字を読むのではなく、⽂字をつくることに専念。禁読。「ざらざら」と「つるつる」に。 →リーン開発の現場、カイゼン・ジャーニーから受け継ぐ「圧倒的推敲」

Slide 23

Slide 23 text

夜も眠れない問題間に合わせること。当初の⽬論⾒は2018年年末発刊だった。 2018年の夏、執筆全く進まず。「4年かかったカイゼン・ジャーニーの悪夢」バッファマネジメント導⼊。(3章参照) 年末に仕切り直し。全時間投⼊。そして、平成と令和の境界で質の向上に専念。

Slide 24

Slide 24 text

タイトルをなかなか決められなかったためスケジュール上の予定は仮の「村⽥」感⾼まる。

Slide 25

Slide 25 text

期間を⾒極める 8⽉-12⽉ 12⽉年末〜4⽉中旬 4⽉中旬〜5⽉末 5⽉29⽇推敲、そして推敲。とにかく書く。 3⽉末からレビュー依頼。 4⽉増⽥レビュー戦線。 4⽉中旬、脱稿。⽴上げ失敗。

Slide 26

Slide 26 text

トレードオフスライダー Quality → Delivery → Scope → Cost 当然、質ファースト。そして、ローンチタイミングを間に合わせること。スコープは、多少調整。ただし全体的に構想をはるかに越えるボリュームに。

Slide 27

Slide 27 text

何がどれだけ必要か市⾕1名、4ヶ⽉。そして、⽀えて頂いた村⽥さん、妻、レビューアの皆さん！

Slide 28

Slide 28 text

制作ジャーニー

Slide 29

Slide 29 text

No content

Slide 30

Slide 30 text

No content

Slide 31

Slide 31 text

No content

Slide 32

Slide 32 text

No content

Slide 33

Slide 33 text

No content

Slide 34

Slide 34 text

何が書かれているのか？

Slide 35

Slide 35 text

第1章なぜプロダクトづくりがうまくいかないのか 1-1 なぜ、プロダクトづくりに苦戦し続けるのか? 1-2 多様性がプロダクトの不確実性を⾼める 1-3 不確実性とのこれまでの戦い⽅ 1-4 アジャイル開発への期待と失望第2章プロダクトをアジャイルにつくる 2-1 アジャイル開発とは何か 2-2 スクラムとは何か 2-3 スクラムチーム 2-4 スクラムイベント 2-5 スクラムの成果物 2-6 ⾃分たちのアジャイル開発とどう向き合うべきか第3章不確実性への適応 3-1 アジャイル開発で乗り越えられない不確実性 3-2 共通の軸を持つ 3-3 余⽩の戦略 3-4 スプリント強度を⾼める戦術 3-5 全体への共通理解を統べる作戦第4章アジャイル開発は2度失敗する 4-1 チームは2度、壁にぶつかる 4-2 プロダクトオーナーの果たすべき役割 4-3 チームとプロダクトオーナー間に横たわる2つの境界第5章仮説検証型アジャイル開発 5-1 ⾃分たちの基準をつくる 5-2 正しくないものをつくらないための原則 5-3 仮説検証型アジャイル開発における価値探索 5-4 1回⽬のモデル化(仮説キャンバス) 5-5 1回⽬の検証(ユーザーインタビュー) 5-6 2回⽬のモデル化(ユーザー⾏動フローのモデル化) 5-7 2回⽬の検証(プロトタイプによる検証) 5-8 その他の検証⼿段 5-9 仮説検証の補⾜―本質、実体、形態第6章ともにつくる 6-1 正しいものを正しくつくる 6-2 視座、視野を越境する 6-3 チームとともにつくる

Slide 36

Slide 36 text

選択の幅最⼤（セットベース）検証計画仮説⽴案 (モデル化) 検証評価価値探索（正しいものを探す） MVP特定開発計画 (リリースプランニング) スプリントプランニングスプリント開発スプリントレビュースプリントレトロスペクティブ MVP検証アジャイル開発（正しくつくる） ※4章、5章 ※2章、3章次の検証計画 (価値探索)へ選択の振れ幅最⼩（ポイントベース）「なぜプロダクトづくりがうまくいかないのか」 ※1章「ともにつくる」 ※6章

Slide 37

Slide 37 text

1章→4章→5章→2章→3章→6章 1章→2章→3章→4章→5章→6章理論的には実践的には理論を結論だけ⼤上段から伝えても「へー」にしかならない。実際に⾃⾝が辿った実践の追体験で描きたい。 (仮説検証) (アジャイル開発) (仮説検証) (アジャイル開発)

Slide 38

Slide 38 text

読み⼿の声

Slide 39

Slide 39 text

No content

Slide 40

Slide 40 text

No content

Slide 41

Slide 41 text

No content

Slide 42

Slide 42 text

あとがき

Slide 43

Slide 43 text

プロダクトづくりにともなう不確実性をいかに乗り越えるか? 問いを⽴て、仮説を⽴て、チームととともに越境しながら前進していくための実践の⼿引き。エンジニア、デザイナー、プロダクトオーナーなど、共創によるものづくりに挑むすべての⼈へ贈る、勇気と希望の書。

Slide 44

Slide 44 text

第2部アジャイル開発は2度失敗する

Slide 45

Slide 45 text

アジャイル開発は２度失敗する

Slide 46

Slide 46 text

Photo on VisualHunt 1

Slide 47

Slide 47 text

Photo on VisualHunt Do Agile Be agile

Slide 48

Slide 48 text

アジャイルな開発のプロセス的な特徴少しずつ反復的に開発を進めることで必要とする⼈から必要なフィードバックを得て調整し続けられる開発「インクリメンタル」(少しずつ) 「イテレーティブ」(繰り返し) つまり「早く(少しだけ)形にできる」やり⽅

Slide 49

Slide 49 text

早く(少しだけ)形にできることの意義フィードバックに基づく調整で、⽬的に適したソフトウェアに仕⽴てられる形にすることで早めに関係者の認識を揃えられるつくるものやチームについての問題早く気付けるチームの学習効果が⾼い早く始められる結合のリスクを早めに倒せる Time to market が短いサンクコストが⼩さくできる開発チームのリズムを整えられる ① ② ③ ④ ⑤ ⑥ ⑦ ⑧ ⑨ https://www.slideshare.net/papanda/ss-79465986

Slide 50

Slide 50 text

https://blog.crisp.se/2016/01/25/henrikkniberg/making-sense-of-mvp 「早く少しだけ形にする」の難しさとは？

Slide 51

Slide 51 text

「どうやってやるのか」よりも「教科書どおりにやれているのか」よりも早く少しだけ形にして、新たに「分かってきたこと」を現実的にどうやって受け⽌められるようにするのか？ (当然、様々な前提や制約がある中で、どうやって？)

Slide 52

Slide 52 text

学びが次の不確実性を連れてくる。 Photo on VisualHunt

Slide 53

Slide 53 text

Photo credit: Phil Roeder on Visualhunt.com / CC BY “理想的な状況”を前提にただ置いたところで前には進まない。

Slide 54

Slide 54 text

Photo credit: joiseyshowaa on VisualHunt.com / CC BY-SA トレードオフが成り⽴たない現実にどう向きあうのか？

Slide 55

Slide 55 text

変化を受け⽌められる余⽩をつくりその⼀⽅で短いタイムボックスの中での確実性を⾼める。

Slide 56

Slide 56 text

余⽩の戦略スプリント強度を⾼める戦術

Slide 57

Slide 57 text

余⽩の戦略全体への共通理解を統べる作戦スプリント強度を⾼める戦術プロジェクトレベル複数スプリントレベル単⼀スプリントレベル

Slide 58

Slide 58 text

“プロジェクト” と “プロダクト” を⼆項対⽴で捉えない。⼈の意識も貴重なりソース。集中して成果をあげるためには、適切なタイムボックス設計が必要。問題は、プロジェクトでの局所最適で全体の判断を誤ること。

Slide 59

Slide 59 text

Photo on VisualHunt 2

Slide 60

Slide 60 text

プロダクトオーナーと開発チームの間にある境界線 Photo credit: gnportraits on Visualhunt / CC BY-NC-ND

Slide 61

Slide 61 text

Slide 62

Slide 62 text

Slide 63

Slide 63 text

Toshihiro Ichitani All Rights Reserved. プロダクトオーナーに求められることプロダクトを形にするために必要な知識とスキルソフトウェア開発の基本的な知識プロダクトバックログの管理⽅法受け⼊れテストの実施とテスト結果の活⽤ユーザーテストによるフィードバック取得と継続的な計測プロジェクトマネジメントコミュニケーション設計プロダクトがどうあるべきかの牽引のためにチームとの協働のためにプロジェクトを遂⾏するために開発メンバーとの意思疎通のために

Slide 64

Slide 64 text

Slide 65

Slide 65 text

Slide 66

Slide 66 text

Slide 67

Slide 67 text

Slide 68

Slide 68 text

Toshihiro Ichitani All Rights Reserved. プロダクトデザイナー型PO中⼼のフォーメーションビジネス推進型PO中⼼のフォーメーション要求の⾔語化、整理ユーザーインターフェースの⽅針を決めるビジネスモデルの設計要求の⾔語化、整理ユーザーインターフェースの⽅針を決めるビジネスモデルの設計プロダクトマネージャーによる補完 UIデザイナーによる補完 POの役割をチームで補完する

Slide 69

Slide 69 text

ケーススタディもっとも”伝統”のモメンタムがかかりやすい組織と⾔えば？伝統的な組織ほどアジャイルへの移⾏は逆境

Slide 70

Slide 70 text

KASUMI GASEKI

Slide 71

Slide 71 text

経産省の「シン・ミラサポ」プロジェクトをリニューアルしたい。・ミラサポとは、助成⾦、補助⾦(合せて⽀援策)の情報提供サイト https://www.mirasapo.jp/index.html ・⽬的や資本⾦、地域などから検索することができる・主に中⼩企業、⼩規模事業者向け・プロジェクトモチベーション - 助成⾦、補助⾦の情報が必要な⼈に伝えられていないのではないか？ - ミラサポをもっと使ってもらえるようなものにしたい - アジャイル開発で⾏きたい 2018年後半〜2019年3⽉

Slide 72

Slide 72 text

https://www.slideshare.net/ codeforjapan/ss-146226314 https://www.slideshare.net/ papanda/ss-145501029 詳しくはこちら

Slide 73

Slide 73 text

チームのフォーメーション私開発チーム (プログラマー、デザイナー) 中企庁&経産省DXチーム PO (起案者)

Slide 74

Slide 74 text

現実のPOはそもそもソフトウェア開発⾃体がほぼ初めてということが少なくないいきなり”PO”としての振る舞いを求めたところでどうにもならない。それを⾝につける時間もプロジェクトには無い。

Slide 75

Slide 75 text

Photo credit: h.koppdelaney on Visual Hunt / CC BY-ND プロダクトオーナー代⾏

Slide 76

Slide 76 text

チームのフォーメーション PO代⾏開発チーム (プログラマー、デザイナー) 中企庁&経産省DXチーム PO (起案者)

Slide 77

Slide 77 text

チームのフォーメーション開発チーム (プログラマー、デザイナー) 中企庁&経産省DXチーム PO (起案者) 真っ当なプロダクトオーナー PO代⾏

Slide 78

Slide 78 text

チームのフォーメーション開発チーム (プログラマー、デザイナー) 中企庁&経産省DXチーム PO (起案者) PBLリファインメント中⼼(啓蒙) PO代⾏

Slide 79

Slide 79 text

なぜ、プロダクトオーナーが代⾏できるのか？

Slide 80

Slide 80 text

仮説検証を実施しているから誰よりも想定ユーザーのことを理解している

Slide 81

Slide 81 text

何をつくるべきなのか仮説を⽴て最⼤限選択肢を保ちながら検証を進め、誤りを除去していく。

Slide 82

Slide 82 text

選択の幅最⼤（セットベース）検証計画仮説⽴案 (モデル化) 検証評価価値探索（正しいものを探す） MVP特定開発計画 (リリースプランニング) スプリントプランニングスプリント開発スプリントレビュースプリントレトロスペクティブ MVP検証アジャイル開発（正しくつくる）次の検証計画 (価値探索)へ選択の振れ幅最⼩（ポイントベース）仮説検証型アジャイル開発「価値探索」この活動がなければ何をつくるべきかが関係者の勘と経験にしか依らない。開発チームもプロダクトどうあるべきという基準が持てない。

Slide 83

Slide 83 text

GuildHub https://lp.guildhub.jp/ https://www.amazon.co.jp/dp/4802511191/ 仮説キャンバスをオンラインでつくる仮説検証型アジャイル開発の全容

Slide 84

Slide 84 text

繋がりをつくる段階をつくる

Slide 85

Slide 85 text

選択の幅最⼤（セットベース）検証計画仮説⽴案 (モデル化) 検証評価価値探索（正しいものを探す） MVP特定開発計画 (リリースプランニング) スプリントプランニングスプリント開発スプリントレビュースプリントレトロスペクティブ MVP検証アジャイル開発（正しくつくる）次の検証計画 (価値探索)へ選択の振れ幅最⼩（ポイントベース）繋がりをつくる仮説検証とアジャイル開発の統合時点での「基準」を⾒出し、育む

Slide 86

Slide 86 text

段階をつくる作らない、利⽤する、その上で作る理解とプロダクトの段階の統合 Photo on VisualHunt まず競合や既存の⼿段を代替して検証する圧倒的にハリボテをつくる圧倒的に分離してつくる (フロントエンドとバックエンド) … まだ何が必要なのか検討ついていない何が問題なのか分かってきた。新しい価値提案。つくるものが⾒えてきたので最⼩限範囲でつくる

Slide 87

Slide 87 text

”段階のデザイン” + “変更容易性” = 適者⽣存の構造化戦略 Photo credit: Esthr on VisualHunt / CC BY-NC “今後の変更に耐えうる” 構造重視の設計 (フロントはそのまま、バックを刷新) 勝ち筋が⾒えてきたスケールに備えたいそろそろフロント側を

Slide 88

Slide 88 text

プロダクトオーナー代⾏の遂⾏と責務・そもそも、POも「正解」を持っているわけではない。そもそもプロダクトづくりには仮説検証が必要。・仮説検証を実施し、そこで得られた学びをチームで分かち合う。当然、代⾏には仮説検証の練度が求められる。場数がモノを⾔う。ドメイン知識の補完は、ドメインエキスパートに頼る。 (ただし、代⾏⾃⾝もドメインへの関⼼が無ければ成り⽴たない) ・実質的には「PO代⾏ ≒ PO」に他ならない。代⾏には仮説検証の実施とともに、真正のPOを育成する仕事の 2つが同時に求められる。

Slide 89

Slide 89 text

PO代⾏観点でのコミュニケーションイメージ PO 開発チーム (プログラマー、デザイナー) 中企庁&経産省DXチーム全員ステークホルダー次期PO PBLの詳細化と受け⼊れスプリントレビュー

Slide 90

Slide 90 text

…ということはこれからはPO代⾏という役割がもっと増えていく？

Slide 91

Slide 91 text

Photo credit: afagen on Visualhunt.com / CC BY-NC-SA "プロダクトオーナー”の⺠主化

Slide 92

Slide 92 text

向かうべきは「プロダクトオーナーの⺠主化」・「PO代⾏」は経験・スキルを補完するための便宜的な役割。 “代⾏”が永続的に必要なのは解決⼿段が間違っている。・仮説検証での学びからプロダクトの「基準」をつくり、チームに宿すようにする。基準はPOが唯⼀持っているものでも、PO代⾏が唯⼀持っているものでもない。チームで「プロダクトとしてどうあるべきなのか」という基準を有し、チームの多様性でもって磨いていく。そうして、価値発⾒の可能性を⾒出そう。・チームが仮説検証できるようにリードする=「仮説検証リード」実践や解釈には練度が求められる。仮説検証リードが補完する。

Slide 93

Slide 93 text

「役割による調整」から「仮説検証による学びを中⼼とした共創」へ

Slide 94

Slide 94 text

Photo on VisualHunt 3

Slide 95

Slide 95 text

https://www.amazon.co.jp/dp/4802511191/ 体験版はここまでです続きは製品版でお楽しみください。

Slide 96

Slide 96 text

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

Slide 97

Slide 97 text

https://note.mu/papanda0806/n/n9094d4b2e9dc “「正しいものを正しくつくる」という⾔葉が⼈に傾きを与える。この⾔葉はそのまま読むのではなく、問いかけとして扱う。すなわち「正しいものを正しくつくれているか？」と。それを他⼈に向けるのではなく、⾃分⾃⾝に向ける。そうして、⾃分⾃⾝の在り⽅、思考や⾏動を問い直すためにある⾔葉なのだ。⾃分で⾃分の有りたい⽅向に向きあえているのか、気づくための⾔葉。”

Slide 98

Slide 98 text

「正しいものを正しくつくれているか？」