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

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

Ichitani Toshihiro

市⾕聡啓 Beyond Agile

Toshihiro Ichitani All Rights Reserved.

http://about.me/papanda0806

Ichitani Toshihiro

市⾕聡啓

ソフトウェア開発15年SIer→サービス→受託→起業仮説検証とプロダクト開発

ギルドワークス株式会社代表 DevLOVE コミュニティファウンダ⼀般社団法⼈アジャイルチームを⽀える会理事

http://about.me/papanda0806


問い


我々は、⽬的に叶うプロダクトを適した⼿段でどれほどつくれているのか

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

ソフトウェア開発は何が確からしいかを探し

どう作るのが適しているかを繰り返し問い続けるしかない


間違ったものを間違いながらつくる

への終⽌符

＝アジャイル開発


間違ったものを間違いながらつくる

への終⽌符

＝アジャイル開発

なのか？


話した⽅が、早く分かる


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


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


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


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


型としてのスクラム

軽量、理解が容易、習得が困難



正しくつくる



スプリント開発ふりかえり

プロダクトオーナースクラムマスターチームステークホルダー

スクラムは正しいものを連れてきてくれるのか？

正しいものを？

正しくつくる


いくら型通りに正しく作っていても間違ったモノをつくる限り⽬的を果たすことは無い

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/

仮説検証アプローチ + プロダクト開発ギルドワークスのアプローチ



仮説検証アプローチ + プロダクト開発ギルドワークスのアプローチ

価値探索

仮説キャンバスでの仮説⽴案と検証によるupdateを中⼼として、ユーザーインタビューでの探索、ユーザーストーリーマッピングでの MVP(Minimum Viable Product)の特定を反復的に⾏う。


仮説仮説キャンバス

検証ユーザーインタビュー

検証ユーザーストーリー

マッピング


仮説キャンバスなぜこの事業をやるのか顧客にどうなってもらいたいか

顧客が気づいている課題

顧客が気づいていない課題

課題解決のための現状⼿段と不満

顧客に出会う為の⼿段

どのような状況にある

顧客が対象か

状況に基づく顧客

の傾向

顧客にもたらす

価値

顧客にとっての

意味

ビジネスモデル

⾃社がやるべき理由になる具体的リソース、

状況

評価の指標と基準値

提案価値を実現する

⼿段


ユーザーストーリーマッピング

ストーリーの優先度=重要かつ未検証



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




アイデア段階のため何をつくるべきか選択肢の幅は広い

仮説


検証結果を踏まえて何をつくるべきかの選択肢は狭まる

エピック




仮説


https://guildworks.jp/service/value/どうなれば完成といえるのか条件が定義可能となるまで詳細化する

ストーリー



仮説


エピック



何をつくるべきかが分かるのは段階的仮説→エピック→ストーリーと

詳細化・分割し、開発可能にする

どうなれば完成といえるのか条件が定義可能となるまで詳細化する

ストーリー



仮説


エピック



分かったことを正しくつくる

＝


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

分かったことを、正しくつくる


分かっていないこと

MVP

Minimum Viable Product (MVP) 実⽤的で最⼩限の範囲

分かっていないこと

分かっていること

MKP

Most Knowing Product (MKP) 分かっている最⼤限の範囲

= 検証のために必要な最⼩限の製品 (分かっていないことを分かるための⼿段)

= ユーザーにとって価値があると分かっている範囲で最⼤限の製品

学びを得ることと、価値提供を、混同しない

MVP vs MKP


「重いMVP」問題

つくる計測し決めるつくる

計測し決める

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


利⽤者の⽅をみた判断をするさがすさがす

さがすさがすさがすさがす

さがすさがすさがす

つくるさがすさがすさがす

学び

学び

学び

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


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

仮説キャンバスによる仮説マネジメント


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


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



分かったことを正しくつくる

＝


我々は、⽬的に叶うプロダクトを適した⼿段でどれほどつくれているのか

Photo credit: pagarneau via Visualhunt / CC BY-NC

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

Software