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

2019年7月3日DevLOVE関西で話したこと

Transcript

2. (My KeyWord) 市⾕ 聡啓 仮説検証型アジャイル開発 正しいものを正しくつくる 越境 Ichitani Toshihiro
3. https://ichitani.com/ Profile
4. https://www.amazon.co.jp/dp/4802511191/ 6⽉14⽇発刊
5. https://www.amazon.co.jp/dp/4802511191/ 6⽉14⽇発刊 重版決定
6. 本⽇の内容 第1部 「正しいものを正しくつくる」本とは何か 第2部 アジャイル開発は2度失敗する
7. 第1部 「正しいものを正しくつくる」本とは何か
8. 書籍「正しいものを正しくつくる」を インセプションデッキに載せて紹介します。 ਖ਼͍͠΋ͷΛਖ਼ͭ͘͘͠Δ
10. Start with Why
11. 「カイゼン・ジャーニーで書けなかったことがある。」
12. われわれはなぜここにいるのか 「何をつくるべきか」の仮説検証から開発の在り⽅ までを⼀気通貫に扱う書籍が無い。 この領域は、5年以上⾃分が取り組んできたことであり 棚卸し、まとめることで価値を⽰せそうだ。 「⽇本発のアジャイル」をまとめたものが少ない。 ⽇本の現場で育ったアジャイルのカタチを⽰したい。
13. プロダクトづくりの傍らにあり、迷わぬよう。
14. エレベータピッチ [何の拠り所もない不確実性の⾼いプロダクトづくりに臨む]、 [プロダクトオーナーやプロダクトチーム、関係者]に向けて 書かれた [正しいものを正しくつくる] は、 [チームによるプロダクト開発のための本] です。 これは、 [構成がジャーニー(実践順)になっているため現実感があり] [⼀部分ではなく仮説検証から開発の在り⽅まで⼀気通貫している]。 輸⼊本と違って [⽇本の現場で磨かれた、⽇本発のアジャイルを扱っている]。
15. 選択の幅最⼤ （セットベース） 検証 計画 仮説⽴案 (モデル化) 検証 評価 価値探索 （正しいものを探す） MVP特定 開発計画 (リリースプラ ンニング) スプリントプ ランニング スプリント 開発 スプリント レビュー スプリント レトロスペクティ ブ MVP検証 アジャイル開発 （正しくつくる） 仮説キャンバス ユーザーインタビュー 検証キャンバス (プランニング付近に配置) ＜仮説検証型アジャイル開発の全容＞ ⽬的選択の段階 実体選択の段階 ⼿段選択の段階 次の検証計画 (価値探索)へ ユーザースストーリー マッピング 選択の振れ幅最⼩ （ポイントベース） 順序選択 体験による検証の必要性判断 かつ検証のための開発判断 検証の始点 検証活動 検証の終点 プロトタイプ ランディングページ 観察 アクティングアウト ※掲載⽤作図
16. プロジェクトコミュニティ (著者) 市⾕聡啓 (編集者) 村⽥さん 市⾕妻 (レビューア) 篠原さん (レビューア) ⿊⽥さん (レビューア) ⼩⽥中さん (レビューア) 吉村さん (レビューア) 沼⽥さん (レビューア) 増⽥さん
18. やらないことリスト カイゼン・ジャーニーの「物語」形式の踏襲。 ただし、内容⾃体が実践順に基づく「ストーリー」。 ⾃⾝が経験していないことを書く。 共著（単⾝ですべての⾔葉を背負うため）。 徹夜（健康のため）。
19. パッケージデザイン
20. LPが先⾏。”暗闇の中で光指す”
21. パッケージデザイン
22. 技術的解決策 「ぼっちでやる」苦しさと、楽しさ。 →苦労したのは1章4章。楽しみながら書いたのは3章。 縦書き。 →読み⼿の⽬⽟の動きを重⼒で邪魔しないようにする。 note、twitterで指を鍛える。 →どれほど忙しくても、⽇々⽋かさない。 増⽥さんとの対話。村⽥さんへの説明。 →レビューを通した対話が深い思考、説明責任が分かりやすさを求める。 執筆中は本を読まない。 →⽂字を読むのではなく、⽂字をつくることに専念。禁読。 「ざらざら」と「つるつる」に。 →リーン開発の現場、カイゼン・ジャーニーから受け継ぐ「圧倒的推敲」
23. 夜も眠れない問題 間に合わせること。 当初の⽬論⾒は2018年年末発刊だった。 2018年の夏、執筆全く進まず。 「4年かかったカイゼン・ジャーニーの悪夢」 バッファマネジメント導⼊。(3章参照) 年末に仕切り直し。全時間投⼊。 そして、平成と令和の境界で質の向上に専念。
24. タイトルをなかなか決められなかったため スケジュール上の予定は仮の「村⽥」感⾼まる。
25. 期間を⾒極める 8⽉-12⽉ 12⽉年末〜4⽉中旬 4⽉中旬〜5⽉末 5⽉29⽇ 推敲、そして推敲。 とにかく書く。 3⽉末からレビュー依頼。 4⽉増⽥レビュー戦線。 4⽉中旬、脱稿。 ⽴上げ失敗。
26. トレードオフスライダー Quality → Delivery → Scope → Cost 当然、質ファースト。 そして、ローンチタイミングを間に合わせること。 スコープは、多少調整。  ただし全体的に構想をはるかに越えるボリュームに。
27. 何がどれだけ必要か 市⾕1名、4ヶ⽉。 そして、⽀えて頂いた村⽥さん、妻、レビューアの皆さん！
28. 制作ジャーニー
34. 何が書かれているのか？
35. 第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 チームとともにつくる
36. 選択の幅最⼤ （セットベース） 検証 計画 仮説⽴案 (モデル化) 検証 評価 価値探索 （正しいものを探す） MVP特定 開発計画 (リリースプラ ンニング) スプリントプ ランニング スプリント 開発 スプリント レビュー スプリント レトロスペクティ ブ MVP検証 アジャイル開発 （正しくつくる） ※4章、5章 ※2章、3章 次の検証計画 (価値探索)へ 選択の振れ幅最⼩ （ポイントベース） 「なぜプロダクトづくりが うまくいかないのか」 ※1章 「ともにつくる」 ※6章
37. 1章→4章→5章→2章→3章→6章 1章→2章→3章→4章→5章→6章 理論的には 実践的には 理論を結論だけ⼤上段から伝えても「へー」に しかならない。 実際に⾃⾝が辿った実践の追体験で描きたい。 (仮説検証) (アジャイル開発) (仮説検証) (アジャイル開発)
38. 読み⼿の声
42. あとがき
43. プロダクトづくりにともなう不確実性を いかに乗り越えるか? 問いを⽴て、仮説を⽴て、チームととともに越境し ながら前進していくための実践の⼿引き。 エンジニア、デザイナー、プロダクトオーナーなど、 共創によるものづくりに挑むすべての⼈へ贈る、 勇気と希望の書。
44. 第2部 アジャイル開発は2度失敗する
45. アジャイル開発は ２度失敗する
46. Photo on VisualHunt 1
47. Photo on VisualHunt Do Agile Be agile
48. アジャイルな開発のプロセス的な特徴 少しずつ反復的に開発を進めることで 必要とする⼈から必要なフィードバックを得て 調整し続けられる開発 「インクリメンタル」(少しずつ) 「イテレーティブ」(繰り返し) つまり「早く(少しだけ)形にできる」やり⽅
49. 早く(少しだけ)形にできることの意義 フィードバックに基づく調整で、⽬的に適した ソフトウェアに仕⽴てられる 形にすることで早めに関係者の認識を揃えられる つくるものやチームについての問題早く気付ける チームの学習効果が⾼い 早く始められる 結合のリスクを早めに倒せる Time to market が短い サンクコストが⼩さくできる 開発チームのリズムを整えられる ① ② ③ ④ ⑤ ⑥ ⑦ ⑧ ⑨ https://www.slideshare.net/papanda/ss-79465986
50. https://blog.crisp.se/2016/01/25/henrikkniberg/making-sense-of-mvp 「早く少しだけ形にする」 の難しさとは？
51. 「どうやってやるのか」よりも 「教科書どおりにやれているのか」よりも 早く少しだけ形にして、 新たに「分かってきたこと」を 現実的にどうやって受け⽌められるように するのか？ (当然、様々な前提や制約がある中で、どうやって？)
52. 学びが次の不確実性を 連れてくる。 Photo on VisualHunt
53. Photo credit: Phil Roeder on Visualhunt.com / CC BY “理想的な状況”を 前提にただ置いたところで 前には進まない。
54. Photo credit: joiseyshowaa on VisualHunt.com / CC BY-SA トレードオフが 成り⽴たない現実に どう向きあうのか？
55. 変化を受け⽌められる余⽩をつくり その⼀⽅で短いタイムボックスの中 での確実性を⾼める。
56. 余⽩の戦略 スプリント強度を ⾼める戦術
57. 余⽩の戦略 全体への 共通理解を統べる作戦 スプリント強度を⾼める戦術 プロジェクト レベル 複数スプリント レベル 単⼀スプリント レベル
58. “プロジェクト” と “プロダクト” を ⼆項対⽴で捉えない。 ⼈の意識も貴重なりソース。 集中して成果をあげるためには、 適切なタイムボックス設計が必要。 問題は、プロジェクトでの局所最適で 全体の判断を誤ること。
59. Photo on VisualHunt 2
60. プロダクトオーナーと 開発チームの間にある境界線 Photo credit: gnportraits on Visualhunt / CC BY-NC-ND
61. Toshihiro Ichitani All Rights Reserved. 開発チームはスクラムの振る舞いを ㅟ ⾝につけられている。 開発チームとPOはPBLをはさんで コミュニケーションすることに最適化。 POが何をしていて、どうやってPBLを つくっているか開発チームが知らない。 「スプリントの空振り」が起きる。 プロダクトづくりの不吉なにおい PBL…プロダクトバックログ
62. Toshihiro Ichitani All Rights Reserved. Photo credit: Steven Penton on VisualHunt / CC BY プロダクトオーナーにかかる プレッシャーは重い
63. Toshihiro Ichitani All Rights Reserved. プロダクトオーナーに求められること プロダクトを形にするために必要な知識とスキル ソフトウェア開発の 基本的な知識 プロダクトバックログの 管理⽅法 受け⼊れテストの実施と テスト結果の活⽤ ユーザーテストによる フィードバック取得と 継続的な計測 プロジェクトマネジメント コミュニケーション設計 プロダクトがどうあるべきか の牽引のために チームとの協働のために プロジェクトを遂⾏するために 開発メンバーとの意思疎通 のために
64. Toshihiro Ichitani All Rights Reserved. https://www.slideshare.net/papanda/97-78212969 ご興味があればこちらもどうぞ
65. Toshihiro Ichitani All Rights Reserved. PBLを⽣み出すための仮説検証に ⻑けており⼗分な知識と経験がある しかも、プロダクトづくりの新しい 取り組みのタイミングで運良く 稼働が空いている！ "理想的なプロダクトオーナー" “理想的なプロダクトオーナー” とは 都合の良い概念でしかない
66. Toshihiro Ichitani All Rights Reserved. 間違ったものを 正しくつくる Do the Wrong things Right Photo credit: BeaLeiderman via VisualHunt.com / CC BY-NC-SA いくら型どおりに正しくつくっていても、 間違ったもの(⽬的に適さないもの)をつくっている限り ミッションは達成できない。
67. Toshihiro Ichitani All Rights Reserved. Photo credit: James Marvin Phelps via Visualhunt.com / CC BY-NC 開発チームからPO側への越境
68. Toshihiro Ichitani All Rights Reserved. プロダクトデザイナー型PO中⼼のフォーメーション ビジネス推進型PO中⼼のフォーメーション 要求の⾔語化、整理 ユーザーインターフェース の⽅針を決める ビジネスモデルの 設計 要求の⾔語化、整理 ユーザーインターフェース の⽅針を決める ビジネスモデルの 設計 プロダクト マネージャーによる 補完 UIデザイナーに よる補完 POの役割をチームで補完する
69. ケーススタディ もっとも”伝統”のモメンタムが かかりやすい組織と⾔えば？ 伝統的な組織ほどアジャイルへの移⾏は逆境
70. KASUMI GASEKI
71. 経産省の「シン・ミラサポ」プロジェクト をリニューアルしたい。 ・ミラサポとは、助成⾦、補助⾦(合せて⽀援策)の情報提供サイト  https://www.mirasapo.jp/index.html ・⽬的や資本⾦、地域などから検索することができる ・主に中⼩企業、⼩規模事業者向け ・プロジェクトモチベーション  - 助成⾦、補助⾦の情報が必要な⼈に伝えられていないのではないか？  - ミラサポをもっと使ってもらえるようなものにしたい  - アジャイル開発で⾏きたい 2018年後半〜2019年3⽉
72. https://www.slideshare.net/ codeforjapan/ss-146226314 https://www.slideshare.net/ papanda/ss-145501029 詳しくはこちら
73. チームのフォーメーション 私 開発チーム (プログラマー、デザイナー) 中企庁&経産省DXチーム PO (起案者)
74. 現実のPOはそもそもソフトウェア開発⾃体が ほぼ初めてということが少なくない いきなり”PO”としての振る舞いを求めたところでどうにもならない。 それを⾝につける時間もプロジェクトには無い。
75. Photo credit: h.koppdelaney on Visual Hunt / CC BY-ND プロダクトオーナー代⾏
76. チームのフォーメーション PO代⾏ 開発チーム (プログラマー、デザイナー) 中企庁&経産省DXチーム PO (起案者)
77. チームのフォーメーション 開発チーム (プログラマー、デザイナー) 中企庁&経産省DXチーム PO (起案者) 真っ当なプロダクトオーナー PO代⾏
78. チームのフォーメーション 開発チーム (プログラマー、デザイナー) 中企庁&経産省DXチーム PO (起案者) PBLリファインメント中⼼(啓蒙) PO代⾏
79. なぜ、プロダクトオーナーが 代⾏できるのか？
80. <Answer> 仮説検証を実施しているから 誰よりも想定ユーザーのことを理解している
81. 何をつくるべきなのか仮説を⽴て 最⼤限選択肢を保ちながら検証を 進め、誤りを除去していく。
82. 選択の幅最⼤ （セットベース） 検証 計画 仮説⽴案 (モデル化) 検証 評価 価値探索 （正しいものを探す） MVP特定 開発計画 (リリースプラ ンニング) スプリントプ ランニング スプリント 開発 スプリント レビュー スプリント レトロスペクティ ブ MVP検証 アジャイル開発 （正しくつくる） 次の検証計画 (価値探索)へ 選択の振れ幅最⼩ （ポイントベース） 仮説検証型アジャイル開発 「価値探索」 この活動がなければ何をつくるべきかが関係者の勘と経験にしか依らない。 開発チームもプロダクトどうあるべきという基準が持てない。
83. GuildHub https://lp.guildhub.jp/ https://www.amazon.co.jp/dp/4802511191/ 仮説キャンバスをオンラインでつくる 仮説検証型アジャイル開発の 全容
84. 繋がりをつくる 段階をつくる
85. 選択の幅最⼤ （セットベース） 検証 計画 仮説⽴案 (モデル化) 検証 評価 価値探索 （正しいものを探す） MVP特定 開発計画 (リリースプラ ンニング) スプリントプ ランニング スプリント 開発 スプリント レビュー スプリント レトロスペクティ ブ MVP検証 アジャイル開発 （正しくつくる） 次の検証計画 (価値探索)へ 選択の振れ幅最⼩ （ポイントベース） 繋がりをつくる 仮説検証とアジャイル開発の統合 時点での「基準」を⾒出し、育む
86. 段階をつくる 作らない、利⽤する、その上で作る 理解とプロダクトの段階の統合 Photo on VisualHunt まず競合や既存の⼿段を 代替して検証する 圧倒的にハリボテを つくる 圧倒的に分離して つくる (フロントエンドとバックエンド) … まだ何が必要なのか 検討ついていない 何が問題なのか分かって きた。新しい価値提案。 つくるものが⾒えてきた ので最⼩限範囲でつくる
87. ”段階のデザイン” + “変更容易性” = 適者⽣存の構造化戦略 Photo credit: Esthr on VisualHunt / CC BY-NC “今後の変更に耐えうる” 構造重視の設計 (フロントはそのまま、バックを刷新) 勝ち筋が⾒えてきた スケールに備えたい そろそろ フロント側を
88. プロダクトオーナー代⾏の遂⾏と責務 ・そもそも、POも「正解」を持っているわけではない。  そもそもプロダクトづくりには仮説検証が必要。 ・仮説検証を実施し、そこで得られた学びをチームで分かち合う。  当然、代⾏には仮説検証の練度が求められる。場数がモノを⾔う。  ドメイン知識の補完は、ドメインエキスパートに頼る。  (ただし、代⾏⾃⾝もドメインへの関⼼が無ければ成り⽴たない) ・実質的には「PO代⾏ ≒ PO」に他ならない。  代⾏には仮説検証の実施とともに、真正のPOを育成する仕事の  2つが同時に求められる。
89. PO代⾏観点でのコミュニケーションイメージ PO 開発チーム (プログラマー、デザイナー) 中企庁&経産省DXチーム 全員ステークホルダー 次期PO PBLの詳細化と受け⼊れ スプリントレビュー
90. …ということは これからはPO代⾏という役割が もっと増えていく？
91. Photo credit: afagen on Visualhunt.com / CC BY-NC-SA "プロダクトオーナー”の⺠主化
92. 向かうべきは「プロダクトオーナーの⺠主化」 ・「PO代⾏」は経験・スキルを補完するための便宜的な役割。  “代⾏”が永続的に必要なのは解決⼿段が間違っている。 ・仮説検証での学びからプロダクトの「基準」をつくり、チームに  宿すようにする。  基準はPOが唯⼀持っているものでも、PO代⾏が唯⼀持っている  ものでもない。チームで「プロダクトとしてどうあるべきなのか」  という基準を有し、チームの多様性でもって磨いていく。  そうして、価値発⾒の可能性を⾒出そう。 ・チームが仮説検証できるようにリードする=「仮説検証リード」  実践や解釈には練度が求められる。仮説検証リードが補完する。
93. 「役割による調整」から 「仮説検証による学びを 中⼼とした共創」へ
94. Photo on VisualHunt 3
95. https://www.amazon.co.jp/dp/4802511191/ 体験版はここまでです 続きは製品版でお楽しみください。
96. 「正しいものを正しくつくる」
97. https://note.mu/papanda0806/n/n9094d4b2e9dc “「正しいものを正しくつくる」という⾔葉が⼈に傾きを与える。 この⾔葉はそのまま読むのではなく、問いかけとして扱う。 すなわち「正しいものを正しくつくれているか？」と。それを他⼈ に向けるのではなく、⾃分⾃⾝に向ける。そうして、⾃分⾃⾝の在 り⽅、思考や⾏動を問い直すためにある⾔葉なのだ。⾃分で⾃分の 有りたい⽅向に向きあえているのか、気づくための⾔葉。”
98. 「正しいものを正しくつくれているか？」