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

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

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

問い

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

60年前から変わらない
間違ったモノづくり

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

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

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

分かったふり開発
Photo via Visual Hunt

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

気持ち反復開発

「分からない開発」をするには
受託開発はさらに分が悪い
分からないことを
分からない⼈同⼠でつくる！

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

ソフトウェア開発は
どのような状況で
どのように作れば正しいか
という回答を持っていない

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

への終⽌符
＝
アジャイル開発

への終⽌符
＝
アジャイル開発
なのか？

http://agilemanifesto.org/iso/ja/manifesto.html

話した⽅が、早く分かる

動かした⽅が、早く分かる

協調した⽅が、早く⾏ける

⽬の前の事実に従う⽅が
早く⾏ける

アジャイル開発とは
「分かった」を早く増やす作戦

型としてのスクラム
軽量、理解が容易、習得が困難

正しくつくる

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

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

正しくつくる
Do the Wrong things Right = DWR
Photo credit: BeaLeiderman via VisualHunt.com / CC BY-NC-SA

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

仮説検証アプローチ
仮説の⽴案
仮説の検証
検証からの学び
学びの実装

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

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

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

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

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

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

越境せよ。

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

正しさとは何か？

正しさは、絶対的には存在しない
正しさは、相対的に存在する
正しさとは、⽬的への適合度合い

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

正しいものを探す

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

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

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

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

仮説
仮説キャンバス
検証
ユーザーインタビュー
検証
ユーザーストーリー
マッピング

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

ユーザーストーリーマッピング
ストーリーの優先度=重要かつ未検証

仮説検証アプローチとプロダクト開発を
噛み合わせる

噛み合わせる
アイデア段階のため
何をつくるべきか
選択肢の幅は広い
仮説

検証結果を踏まえて
何をつくるべきかの
選択肢は狭まる
エピック
噛み合わせる
仮説

どうなれば完成と
いえるのか条件が定義
可能となるまで詳細化する
ストーリー
噛み合わせる
仮説
エピック

何をつくるべきかが分かるのは段階的
仮説→エピック→ストーリーと
詳細化・分割し、開発可能にする
どうなれば完成と
いえるのか条件が定義
可能となるまで詳細化する
ストーリー
噛み合わせる
仮説
エピック

正しいものを
正しくつくる
Do the Right things Right = DRR
分かったことを
正しくつくる
＝

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

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

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

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

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

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

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

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

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

More Related Content

What's hot

Viewers also liked

Similar to 正しいものを正しくつくる

More from toshihiro ichitani

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