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

Toshihiro Ichitani All Rights Reserved.
http://about.me/papanda0806
Ichitani Toshihiro
市⾕聡啓
ソフトウェア開発15年
SIer→サービス→受託→起業
仮説検証とプロダクト開発
ギルドワークス株式会社 代表
DevLOVE コミュニティ ファウンダ
⼀般社団法⼈ アジャイルチームを⽀える会 理事

Toshihiro Ichitani All Rights Reserved.
問い

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

Toshihiro Ichitani All Rights Reserved.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Toshihiro Ichitani All Rights Reserved.
⼀⽣かけて、
稲作、たかだか60回
ソフトウェア開発、たかだか300⼈⽉
Photo credit: Mariam S via VisualHunt / CC BY-NC-ND

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

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

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

Toshihiro Ichitani All Rights Reserved.
越境せよ。

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

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

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

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

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

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

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

Toshihiro Ichitani All Rights Reserved.
https://guildworks.jp/service/value
仮説検証アプローチ + プロダクト開発
ギルドワークスのアプローチ

Toshihiro Ichitani All Rights Reserved.
https://guildworks.jp/service/value/
仮説検証アプローチ + プロダクト開発
ギルドワークスのアプローチ
価値探索
仮説キャンバスでの仮説⽴案と検証によるupdateを中⼼として、
ユーザーインタビューでの探索、ユーザーストーリーマッピングでの
MVP(Minimum Viable Product)の特定を反復的に⾏う。

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

Toshihiro Ichitani All Rights Reserved.
仮説キャンバス
なぜこの事業をやるのか 顧客にどうなってもらいたいか
顧客が
気づいて
いる課題
顧客が
気づいて
いない
課題
課題解決
のための
現状⼿段
と不満
顧客に
出会う為
の⼿段
どのような
状況にある
顧客が
対象か
状況に
基づく顧客
の傾向
顧客に
もたらす
価値
顧客に
とっての
意味
ビジネスモデル
⾃社がやる
べき理由に
なる具体的
リソース、
状況
評価の指標
と基準値
提案価値を
実現する
⼿段

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

Toshihiro Ichitani All Rights Reserved.
https://guildworks.jp/service/value
仮説検証アプローチとプロダクト開発を
噛み合わせる

Toshihiro Ichitani All Rights Reserved.
https://guildworks.jp/service/value
仮説検証アプローチとプロダクト開発を
噛み合わせる
アイデア段階のため
何をつくるべきか
選択肢の幅は広い
仮説

Toshihiro Ichitani All Rights Reserved.
検証結果を踏まえて
何をつくるべきかの
選択肢は狭まる
エピック
https://guildworks.jp/service/value
仮説検証アプローチとプロダクト開発を
噛み合わせる
アイデア段階のため
何をつくるべきか
選択肢の幅は広い
仮説

Toshihiro Ichitani All Rights Reserved.
https://guildworks.jp/service/value
どうなれば完成と
いえるのか条件が定義
可能となるまで詳細化する
ストーリー
仮説検証アプローチとプロダクト開発を
噛み合わせる
アイデア段階のため
何をつくるべきか
選択肢の幅は広い
仮説
検証結果を踏まえて
何をつくるべきかの
選択肢は狭まる
エピック

Toshihiro Ichitani All Rights Reserved.
https://guildworks.jp/service/value
何をつくるべきかが分かるのは段階的
仮説→エピック→ストーリーと
詳細化・分割し、開発可能にする
どうなれば完成と
いえるのか条件が定義
可能となるまで詳細化する
ストーリー
仮説検証アプローチとプロダクト開発を
噛み合わせる
アイデア段階のため
何をつくるべきか
選択肢の幅は広い
仮説
検証結果を踏まえて
何をつくるべきかの
選択肢は狭まる
エピック

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

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

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

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

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

Toshihiro Ichitani All Rights Reserved.
キャンバス上で「分かっていないこと(仮説)」
「分かっていること(検証済)」を可視化する
仮説キャンバスによる仮説マネジメント

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

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

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

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

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