---
title: アジャイル開発は2度失敗する。
tags: 
author: [市谷聡啓](https://www.docswell.com/user/papanda)
site: [Docswell](https://www.docswell.com/)
thumbnail: https://bcdn.docswell.com/page/8GEW9QQZE2.jpg?width=480
description: https://devlove.doorkeeper.jp/events/93088 でお話した内容
published: July 01, 19
canonical: https://www.docswell.com/s/papanda/58NVEZ-2-152930603
---
# Page. 1

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

アジャイル開発は
2度失敗する。
プロダクトをつくるとはどういうことなのか、
あるいはアジャイルその先について
Ichitani Toshihiro
Toshihiro Ichitani All Rights Reserved.
市⾕聡啓


# Page. 2

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

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


# Page. 3

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

Profile
https://ichitani.com/


# Page. 4

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



# Page. 5

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

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


# Page. 6

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

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


# Page. 7

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

1
Photo on VisualHunt


# Page. 8

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

Do Agile
Be agile
Photo on VisualHunt


# Page. 9

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

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


# Page. 10

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

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


# Page. 11

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

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


# Page. 12

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

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


# Page. 13

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

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


# Page. 14

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

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


# Page. 15

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

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


# Page. 16

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

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


# Page. 17

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

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


# Page. 18

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

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


# Page. 19

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

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


# Page. 20

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

2
Photo on VisualHunt


# Page. 21

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

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


# Page. 22

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

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


# Page. 23

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

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


# Page. 24

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

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


# Page. 25

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

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


# Page. 26

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

仮説検証型アジャイル開発
選択の幅最⼤
仮説⽴案
（セットベース）
(モデル化)
検証
計画
価値探索
（正しいものを探す）
評価
スプリントプ
ランニング
検証
開発計画
MVP特定
(リリースプラ
ンニング)
選択の振れ幅最⼩
（ポイントベース）
スプリント
開発
アジャイル開発
（正しくつくる）
スプリント
レトロスペクティ
ブ
MVP検証
スプリント
レビュー
次の検証計画
(価値探索)へ


# Page. 27

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

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


# Page. 28

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

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


# Page. 29

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

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


# Page. 30

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

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


# Page. 31

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

3
Photo on VisualHunt


# Page. 32

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

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


# Page. 33

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

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


# Page. 34

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

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


# Page. 35

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

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