---
title: 正しいものを正しくつくるへ至る道
tags: 
author: [市谷聡啓](https://convert.docswell.com/user/papanda)
site: [Docswell](https://www.docswell.com/)
thumbnail: https://bcdn.docswell.com/page/W47Z9W8673.jpg?width=480
description: なぜ、仮説検証型アジャイル開発へ辿り着くのか
published: July 31, 19
canonical: https://convert.docswell.com/s/papanda/5PRMLK-ss-159383674
---
# Page. 1

![Page Image](https://bcdn.docswell.com/page/W47Z9W8673.jpg)

正しいものを正しくつくる
へ⾄る道
なぜ、仮説検証型アジャイル開発へ辿りつくのか
Ichitani Toshihiro
市⾕聡啓


# Page. 2

![Page Image](https://bcdn.docswell.com/page/KYJ6KGPLJV.jpg)

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


# Page. 3

![Page Image](https://bcdn.docswell.com/page/5GJ5PVKMJ4.jpg)

Proﬁle
https://ichitani.com/


# Page. 4

![Page Image](https://bcdn.docswell.com/page/4LE33DZ9E5.jpg)

4刷
https://www.amazon.co.jp/dp/4798153346/


# Page. 5

![Page Image](https://bcdn.docswell.com/page/V8ED4PR8JG.jpg)

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


# Page. 6

![Page Image](https://bcdn.docswell.com/page/4V7PMNWW78.jpg)

GuildHub
何の⼿がかりも無いプロダクトーナーに
正しいものを正しくつくる
https://lp.guildhub.jp/
ベータ版が公開されたGuildHubを使って仮説キャンバスを作ってみる
https://qiita.com/navitime_tech/items/2cb0d674c8d3a5f8a6a6


# Page. 7

![Page Image](https://bcdn.docswell.com/page/L2JV9K89EQ.jpg)

ソフトウェア開発
Photo on VisualHunt.com


# Page. 8

![Page Image](https://bcdn.docswell.com/page/Z5EGZQ547L.jpg)

SoR
ソフトウェア開発
SoE
Photo on VisualHunt.com


# Page. 9

![Page Image](https://bcdn.docswell.com/page/V4JQLKZREP.jpg)

⼦供写真共有アプリ
SoR
ソフトウェア開発
SoE
仮想通貨
Photo on VisualHunt.com


# Page. 10

![Page Image](https://bcdn.docswell.com/page/DK74DP3QJ1.jpg)

⼦供写真共有アプリ
MaaS
VR
SoR
婚活
決済
ソフトウェア開発
従業員満⾜度 RPA
SI
SoE
仮想通貨
介護ロボット
Photo on VisualHunt.com


# Page. 11

![Page Image](https://bcdn.docswell.com/page/PLJ1Z91L7G.jpg)

⼦供写真共有アプリ
MaaS
婚活
SoR
決済
同じ”ソフトウェア開発”
ソフトウェア開発
VR
SI
なのか？
従業員満⾜度 RPA
SoE
仮想通貨
介護ロボット
Photo on VisualHunt.com


# Page. 12

![Page Image](https://bcdn.docswell.com/page/8GJW9Q8QJ2.jpg)

⾼まるプロダクトづくりの「多様性」
つくるプロダクトの多様 (“同じソフトウェアなのか？”)
= プロダクトへの期待が多様ということ
つくる技術の多様性
= 多様な期待に応えるためにそのすべも多様
つくる⼈間の多様性
= つくり⼿の働き⽅、働く場所も多様


# Page. 13

![Page Image](https://bcdn.docswell.com/page/W4EZ9W83E3.jpg)

働き⽅、働く場所の多様性の広がり
副業、複業の時代
・昼間はSIerや⼤企業。夜や⼟曜は副業でサービス開発。
・いきなりフリーランスというハードル以外の選択肢。
・何でもって正業、副業とするか⾒分けがつかなくなる (複業)
リモートワーク
・導⼊率11.5% (総務省、2018年7⽉調査)
・働く場所を問わない現場がこの5年で増えてきている。
・週1リモートのような部分適⽤も。


# Page. 14

![Page Image](https://bcdn.docswell.com/page/KY76KGPZ7V.jpg)

分断による6つの問題
副業
時間の分断
稼働時間帯
があわない
スクラムイベン
トができない
(同期しにくい)
同期
リモート
ワーク
経験の分断
稼働時間に
偏りがある
1PBI開発あたりの
コミュニケーショ
ンコスト⾼い
オーバー
ヘッド
集まる⼈達の経験
の幅が広くなる
仕事のやり⽅が
⼈によって
バラバラ
やり⽅
場所の分断
⾮⾔語コミュニケー
ションできない
相⼿の様⼦が
わからない
背景⾒えずタスク
指向になりがち
伝わる内容、
分量が
圧倒的に少ない
異常検知が
働きにくい
Whyが弱いため
間違いに気付き
にくい
内容分量
「コミュニケーションの分断」
によって⾼まる複雑性
異常検知
No Why
PBI…プロダクト
バックログアイテム


# Page. 15

![Page Image](https://bcdn.docswell.com/page/5G75PVK974.jpg)

多様性=プロダクト開発の
複雑性が不確実性を
連れてくる。
Photo on VisualHunt


# Page. 16

![Page Image](https://bcdn.docswell.com/page/V9J263W5ER.jpg)

「プロダクト開発=不確実性が⾼い」
ではない


# Page. 17

![Page Image](https://bcdn.docswell.com/page/5DEY91L67M.jpg)

不確実性 = 確実なことが⾔えない
つまり、分析や計画づくりによって確実性を
⾼められるならば「不確実性が⾼い」とは呼べない
=状況分析の解像度が粗いだけ
分析だけでは情報が⾜りず、解が算出できない。
ゆえに、仮説検証によって情報(理解)を増やし、
“確からしさ” を⾼める
=不確実性の⾼い状況へのスタンス
Photo on VisualHunt


# Page. 18

![Page Image](https://bcdn.docswell.com/page/2VJNL2L1E8.jpg)

不確実性に挑むべく、
我々が培ってきた実践知
Photo credit: Henry Sudarman on Visual hunt / CC BY-NC-ND


# Page. 19

![Page Image](https://bcdn.docswell.com/page/GYE9414Y73.jpg)

Do Agile
Be agile
Photo on VisualHunt


# Page. 20

![Page Image](https://bcdn.docswell.com/page/5GE8Q4QK7D.jpg)

プロダクトオーナー
開発チーム
スプリント
バックログ
プロダクト
スクラムマスター
バックログ
インクリメント
ステークホルダー


# Page. 21

![Page Image](https://bcdn.docswell.com/page/MLELX6XPER.jpg)

スプリント = 箱。箱を必要なだけ繋ぐ。
箱の⼤きさ(タイムボックス)の上限はチームで決めている。
スプリント
デイリー
スプリント
スプリント
プランニング
スクラム
レビュー
レトロスペクティブ
…
＋
スプリント
…
＋
スプリント
「(箱)の数は⾜りているか、あるいは余りそうか？」の⾒⽴てを、
スプリントを終えるたびに⾏う (“着地の予測&quot;)
…


# Page. 22

![Page Image](https://bcdn.docswell.com/page/54JML5L27W.jpg)

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


# Page. 23

![Page Image](https://bcdn.docswell.com/page/ZPJRK3K579.jpg)

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


# Page. 24

![Page Image](https://bcdn.docswell.com/page/NPEXL4LXEX.jpg)

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


# Page. 25

![Page Image](https://bcdn.docswell.com/page/63EKLZL97D.jpg)

早く形が⾒える、触れる
想像⼒頼みから体が使える
だから、圧倒的に学びが増える
Photo on VisualHunt


# Page. 26

![Page Image](https://bcdn.docswell.com/page/4L733D3975.jpg)

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


# Page. 27

![Page Image](https://bcdn.docswell.com/page/V87D4P48EG.jpg)

トレードオフが成り⽴たない現実
予算も、期間も、ギリギリの判断、局⾯では
トレードオフが効かない
(“来⽉ローンチできなければ次の予算|資⾦が獲得できない”)
予算、期間の制約が無い! 勝った!!
→ たいてい、グダる。
「お⾦と時間をあるだけ使う」 (パーキンソンの法則)
→「制約」を利⽤する。“期間制約を味⽅につける”
⼈の意識も有限のリソース。制約が集中を⽣む
Photo credit: joiseyshowaa on VisualHunt.com / CC BY-SA


# Page. 28

![Page Image](https://bcdn.docswell.com/page/4VJPMNMWJ8.jpg)

プロジェクト vs プロダクト ?
プロジェクト = タイムボックスの切り⽅の1つ
プロダクト = 成果物
⼆項対⽴の概念ではない
タイムボックスという時間的制約によって
⼈の意識と経営資源を集中投下し成果を⾼める


# Page. 29

![Page Image](https://bcdn.docswell.com/page/L2EV9K997Q.jpg)

変化を受け⽌められる
余⽩をつくりながら、
余⽩が無ければ変化を受け⼊れられない。
いかにして無いところに余⽩を作り出すか？
短いタイムボックスの中での
確実性は⾼める。
⻑い距離で確実なことは⾔えない。
でも、短い距離でなら？成果の確度を⾼められる。
Photo credit: Arenamontanus on Visualhunt.com / CC BY


# Page. 30

![Page Image](https://bcdn.docswell.com/page/Z57GZQZ4JL.jpg)

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


# Page. 31

![Page Image](https://bcdn.docswell.com/page/V4EQLKLR7P.jpg)

プロジェクトレベル
・調整の余⽩
・期間の余⽩
・受け⼊れの余⽩
余⽩の戦略
全体への
共通理解を統べる作戦
複数スプリントレベル
スプリント強度を⾼める戦術
スプリントレベル
・背⾻駆動開発
・状況をクリーンに保つ5つの条件
1. 受け⼊れ条件を定義している
2. ベロシティを計測し安定させている
3. 受け⼊れテストを実施している
4. 振り返りを実施しカイゼン継続
5. 実運⽤相当のデータが揃っている


# Page. 32

![Page Image](https://bcdn.docswell.com/page/DKJ4DPDQE1.jpg)

⾃分たちの活動に”作戦名”をつける
活動 = まとまった機能群の開発、カイゼン…
距離感としては
プロジェクト ＞ 複数スプリント ＞ スプリント
象徴的な名前付けで⽅針を分かりやすくする
(“期間制約を味⽅につける”)
Photo credit: mxmstryo on VisualHunt / CC BY


# Page. 33

![Page Image](https://bcdn.docswell.com/page/PLE1Z9ZLJG.jpg)

「つくる」のアジリティは⾼めれる。
⼀⽅、「つくるもの」は⼤丈夫か？


# Page. 34

![Page Image](https://bcdn.docswell.com/page/8GEW9Q9QE2.jpg)

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


# Page. 35

![Page Image](https://bcdn.docswell.com/page/W47Z9W9373.jpg)

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


# Page. 36

![Page Image](https://bcdn.docswell.com/page/KYJ6KGKZJV.jpg)



# Page. 37

![Page Image](https://bcdn.docswell.com/page/5GJ5PVP9J4.jpg)

仮説検証型アジャイル開発とは
選択と向き合うこと


# Page. 38

![Page Image](https://bcdn.docswell.com/page/V9E263657R.jpg)

選択を”段階”にすることで不確実性を対処する
選択の幅最⼤
仮説⽴案
（セットベース）
(モデル化)
検証
計画
価値探索
スプリントプ
ランニング
検証
開発計画
MVP特定
（正しいものを探す）
評価
⽬的選択の
段階
コンセプトの検証
(リリースプラ
ンニング)
（ポイントベース）
開発
アジャイル開発
（正しくつくる）
スプリント
レトロスペクティ
ブ
選択の振れ幅最⼩
スプリント
MVP検証
スプリント
レビュー
次の検証計画
(価値探索)へ
実体選択の ⼿段選択の 順序選択の
段階
段階
段階
ユーザーに
とって有⽤
かつ必要最
⼩限の範囲
の機能特定
機能設計、
プロダクトバックログ
UIデザイン、 のリファインメント
データ設計
例えば、⼿段選択の段階でコンセプトを
変える決定の影響の⼤きさは明らか


# Page. 39

![Page Image](https://bcdn.docswell.com/page/5D7Y9196JM.jpg)

ボトルネックは常に移り変わる。
プロセスからフォーメーションへ。


# Page. 40

![Page Image](https://bcdn.docswell.com/page/2VENL2D178.jpg)

ザ・プロダクトオーナー
ワールド
選択の幅最⼤
仮説⽴案
（セットベース）
(モデル化)
検証
計画
価値探索
（正しいものを探す）
評価
ザ・開発チーム
ワールド
スプリントプ
ランニング
検証
開発計画
MVP特定
(リリースプラ
ンニング)
選択の振れ幅最⼩
（ポイントベース）
スプリント
開発
アジャイル開発
（正しくつくる）
スプリント
レトロスペクティ
ブ
MVP検証
スプリント
レビュー
次の検証計画
(価値探索)へ
POは”つくる”に関⼼無く、開発チームは”考える”を丸投げの世界


# Page. 41

![Page Image](https://bcdn.docswell.com/page/GY7941GYJ3.jpg)

間違ったものを
正しくつくる
Do the Wrong things Right
いくら型どおりに正しくつくっていても、
間違ったもの(⽬的に適さないもの)をつくっている限り
ミッションは達成できない。
Photo credit: BeaLeiderman via VisualHunt.com / CC BY-NC-SA
Toshihiro Ichitani All Rights Reserved.


# Page. 42

![Page Image](https://bcdn.docswell.com/page/5G78Q4VKJD.jpg)

プロダクトオーナーの視座を
プロダクトのボトルネックにしない
Toshihiro Ichitani All Rights Reserved.
Photo credit: Steven Penton on VisualHunt / CC BY


# Page. 43

![Page Image](https://bcdn.docswell.com/page/ML7LX65P7R.jpg)

&quot;プロダクトオーナー”の⺠主化
PO⼀⼈の視座、視野から
チームの視座、視野へ
Photo credit: afagen on Visualhunt.com / CC BY-NC-SA


# Page. 44

![Page Image](https://bcdn.docswell.com/page/54EML532JW.jpg)

仮説検証をPOだけではなく
チームで⾏う


# Page. 45

![Page Image](https://bcdn.docswell.com/page/ZPERK3Q5J9.jpg)

プロダクトに関する基準をチームに宿す
検証結果と学びを共同所有する


# Page. 46

![Page Image](https://bcdn.docswell.com/page/NP7XL45X7X.jpg)

参画者の多様性でもって
プロダクトの不確実性に対抗する
Photo on VisualHunt


# Page. 47

![Page Image](https://bcdn.docswell.com/page/637KLZ69JD.jpg)

プロダクトづくりにユーザーを巻き込み
チームの視座、視野を⾼め広げる。


# Page. 48

![Page Image](https://bcdn.docswell.com/page/4LJ33D69J5.jpg)

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


# Page. 49

![Page Image](https://bcdn.docswell.com/page/V8JD4PV87G.jpg)

個⼈からチームへ、⾼まるのは
”これまでこうしてきたバイアス”、”同調圧⼒”
ボトルネックは⼈のマインドセットへ
Photo credit: jurek d. (Jerzy Durczak) on VisualHunt.com / CC BY-NC


# Page. 50

![Page Image](https://bcdn.docswell.com/page/4VEPMNVWE8.jpg)

⾃分たちの現状理解をアップデート(越境)し続ける
絶対的な正解など無い。(そんなことは多くの⼈が分かってる)
それを踏まえて、⾃分たちの思考や⾏動に誤りが
混⼊していないか、気づいていない事に気づきたい
Photo credit: Pro-Zak on Visual Hunt / CC BY-NC


# Page. 51

![Page Image](https://bcdn.docswell.com/page/L27V9KZ9JQ.jpg)

越境のための問いを得る
Photo credit: James Marvin Phelps via Visualhunt.com / CC BY-NC
Toshihiro Ichitani All Rights Reserved.


# Page. 52

![Page Image](https://bcdn.docswell.com/page/Z5JGZQ44EL.jpg)

⾃分たちが既存の思考や⾏動に最適化している
事実に気づきにくい (だから問いを⽤いる)
(問い)
⾃分たちの意識に
囚われない ”問い” で
思考や⾏動に向き直る
チームが”分かっている”
圏内


# Page. 53

![Page Image](https://bcdn.docswell.com/page/V47QLKGRJP.jpg)

不確実性の⾼い状況ほど
回答可能な問いにばかり答えていても発⾒が⾜りない
回答不可能な問いをあえて置く
Photo credit: Shandi-lee on Visualhunt.com / CC BY-NC-ND


# Page. 54

![Page Image](https://bcdn.docswell.com/page/DKE4DP5Q71.jpg)

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


# Page. 55

![Page Image](https://bcdn.docswell.com/page/PL71Z9WLEG.jpg)

正しいものを正しくつくる
へ⾄る道
なぜ、仮説検証型アジャイル開発へ辿りつくのか


