アジャイル開発はWhyから始まる

Toshihiro Ichitani All Rights Reserved.
アジャイル開発は
Whyから始まる
Ichitani Toshihiro
市⾕聡啓
Agile Development Start with Why.

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

Copyright (c) 2017 Guild Works Inc.
本⽇のテーマ
アジャイル開発で良いプロダクトを作るためには
開発チームの外側で解決した⽅が良いことがある。
価値の実現の仕⽅「アーキテクチャ」の観点
実現すべき価値とは何か「コンセプト」の観点
このお話では前者の「コンセプト」の観点を扱います

質問
これから開発するプロダクトで
「ユーザーのどんな⽤事を⽚付けるのか」が
あいまいな状態で開発を始めるとどうなるか？

質問
これから開発するプロダクトで
「ユーザーのどんな⽤事を⽚付けるのか」が
あいまいな状態で開発を始めるとどうなるか？
たいてい、むちゃくちゃになる

「何をつくるべきか分からない」のに始められる？
何が起きるか？
優先度が頻繁に変わる可能性が⾼い
(例えば、スプリント毎に)
そうなると…エピック(開発レディではない要求)
を開発可能にするための作業負荷が⼀気に⾼まる
アーキテクチャレベルから実現⽅法を考えないと。
でも、⽬の前にはもう次のスプリントが！
新しいアーキテクチャと、既存のアーキテクチャ
そして、既存コードとの整合性を取るために…

簡潔に⾔うと、右往左往する。
顧客開発(事業開発の⽅法論)をプロダクト開発
よりも極端に優先してしまうと、現実に起きる。
(作戦が⾜りていない)

ということは、何をつくるべきか
定めてから開発に着⼿しようって
ことだよね？

ということは、何をつくるべきか
定めてから開発に着⼿しようって
ことだよね？
だからって、要件定義しろってことじゃあないよ。
そうなんだけど、ちょっと危ない誤解を招きそうなんで
補完すると、例えば「要件定義できっちり⽂書に落とし
込んでから開発しよう」ということを⾔いたい訳では
ないよ。
むしろ、「何をつくるべきか」を明確に事前に⾔える
ほど分かりやすいプロダクトをつくるような状況は
少くなってきているんじゃないかな。

つくらずとも検証できるなら先にやろう。
ソフトウェア開発は「最もコストがかかる検証の準備」
になりやすい。だから、つくらずに検証できる⼿段が
あるなら、開発する前に仮説検証するべきなんだ。
課題仮説検証
ソリューション仮説検証
アテンション検証
体験を伴う検証
チャネル検証
インタビュー
アンケート
プロトタイプ
ランディングページ
動くソフトウェア
：：
どのような検証に、どんな⼿段を⽤いるか？

うーん。仮説検証と開発の関係が
いまいちよく分からないなー。

うーん。仮説検証と開発の関係が
いまいちよく分からないなー。
これから、ゴールデンサークルを⽤いて説明するよ。
何を変えると、何がどうなるのか、ゴールデンサークルで
表現すると理解が深まるんじゃないかな。
ゴールデンサークルは、サイモン・シネック⽒が考えた
思考と⾏動と伝達のための有名なフレームワークなんだ。
「Whyから始めよ」という本も出ているよ。

ゴールデンサークル
Why
How
What

仮説検証
設計、プロセス
機能開発
ここが現場で⽇々⾏なう
アジャイルソフトウェア開発
にあたる

What、How、Whyを⼀つ⼀つ⾒ていきましょう。

= ユーザーが必要とするプロダクトをつくること
ユーザーの要求を満たすための機能をつくる活動
そのものにあたる (= 開発チームの⽇々の活動)。
What
では、開発ではWhyを意識しなくて良いのだろうか？
Whyにも粒度と具体性のレベルがある。
⽇々の活動で開発チームが捉えるべき要求のレベルと
仮説検証で捉えている要求(=仮説)のレベルには開きが
あるんだ。

[補⾜] ⼈の理解って、段階がある。
要求の粒度、具体性、分割。
この⼿の話は「アジャイルソフトウェア要求」が参考になる。
https://www.amazon.co.jp/dp/B00IMRDXZW
「アジャイルソフトウェア要求」
重厚な匂いがする?(確かに本は厚い!)
この通りの型にはめようとするじゃなくて、
「⼈の理解って、ざっくり理解と詳しく理解と、段階があるよね」
に気付けることが⼤事。興味がある⽅はSAFeもチェックしよう。
http://www.scaledagileframework.com/

アイデア段階のため
何をどうつくるべきか
選択肢の幅は広い
検証結果を踏まえて
何をつくるべきかの
選択肢は狭まる
どうなれば完成と
いえるのか条件が定義
可能となるまで詳細化する
仮説エピックストーリー
仮説、エピック、ストーリー。
…という名前付けが⼤事なのではなくて、粒度と具体性のレベル分
けや認識が出来ているかが⼤事。

仮説とは？ストーリーとは？
(仮説)キャンバスの各エリア
の⼀つ⼀つが仮説。
ストーリーとは3段構成で
表現される⼀つ⼀つの要求。
https://www.slideshare.net/papanda/ss-41638116
「ユーザーストーリー駆動開発で⾏こう。」

仮説検証
機能開発
ストーリーレベル
仮説レベル

あれ？エピック→ストーリーの
分割とか詳細化はどこでやるの？

あれ？エピック→ストーリーの
分割とか詳細化はどこでやるの？
サークルのHow段階か、What段階で⾏なう
まず、エピック→ストーリーの詳細化は、仮説検証の
段階ではやらない。
「機能開発の段階」(What)で⾏なうか、
「機能開発の前段階のプランニング」(How)で⾏なうかで
要求に対する開発の弾⼒性が異なることになる。
(後者の⽅がスコープが硬めになる)
どちらが正ではなくて「どの程度変更を受け⼊れる開発
であるべきか」で決める。

要求への開発プロセス弾⼒性
ケース1：How段階でストーリー化し、初期スコープをほぼ固定する
(スプリントの成果に対するフィードバックの選択のみ⾏なう)
ケース2：What段階でストーリー化する。適宜プランは⾒直す
(ケース1よりもっと、変更の受け⼊れをプロセスとして織り込む)
着地優先
探索優先

Whatの次は、Howを⾒ましょう。

仮説検証
機能開発
初期の計画づくりも

= 検証された価値を実現するための⼿段の検討
How
アーキテクチャの設計
プロセスのフレームを決める
リリースプランニング
インセプションデッキ
価値の実現⽅式の設計と、What(機能開発)をレディに
するための諸活動。
(いわゆる「イテレーションゼロ」と呼ばれることも)
初期のモデリング

How to What
Howレベルで⽅針が変わると、Whatへの影響は⼤きい
逆にWhatのやり⽅を変えるためにはHowから考え直す
例えば、スマホアプリをWeb Viewで作ってきたけども
ある体験を実現する必要が分かり、ネイティブでの開発
(新しいHow)が必要になった、など。

Why to How to What
なので、Whyが変わると影響はさらに⼤きい。
新たなWhyを実現するためのHowの設計。Whatの⾒直し。
リーンスタートアップで
「ピボット」と呼ばれる
レベルの転換。
価値仮説(Why)が変わるの
だから場合によっては事業や
サービスががらっと変わる
レベル。

[補⾜] WhatからWhyを問い直す
機能開発(What)の活動の結果、MVPがつくりだされる。
(MVP=実⽤的で最⼩限の範囲のプロダクト)
MVPでの検証の⽬的は、その結果から価値仮説(Why)を
問い直すことである。後に残していたソフトウェアによる
最もリアルな検証にあたる。
MVP
MVPによる検証

ゆえに、Why(仮説検証)から始める
仮説検証
機能開発

で、どうやるの？

仮説検証の基本

仮説検証の流れ
検証のための
ブリーフィング
(初期計画)
想定顧客
インタビュー
プロタイプ制作
プロタイプ検証
サービス仕様の
定義
検証の開始第1回検証活動第2回検証活動検証の終結
仮説検証を「分からないことを分かるようにする」ための
旅路(ジャーニー)と捉えて、活動の設計を⾏なう。
「検証プランニング→検証活動→結果分析」を繰り返し
⾏なう。検証活動の具体的な道具⽴ては、検証すべき
テーマに基いて選択を⾏なう。以下はその⼀例。

検証活動で具体的にどのような道具⽴てを扱うかは
こちらのスライド参照といたします。

なるほど〜。Why→How→Whatで
活動を進めていけばいいのね。

Why と How と Whatの重なりをつくる
そうなんだけど、Whyフェーズ、Howフェーズ、
Whatフェーズとかいう考えで切っちゃうと⼤事な観点が
抜けちゃうんだ。それは、
「ソフトウェアとは少しずつ形になる中で、
どうあるべきかが分かったり、発⾒があったりするもの」
ということだ。なので、3つのレイヤーを分断するのでは
なく、如何に重なりをつくるかが⼤事なんだ。
なるほど〜。Why→How→Whatで
活動を進めていけばいいのね。

What over How over Why
インセプション
デッキ
ユーザーストーリー
マッピング
PO ☓ 開発者による「プロトタイピング」
PO ☓ 開発チームで「ユーザーストーリーマッピング」
PO ☓ 開発チームで「インセプションデッキ」
(プロダクトオーナー)
仮説検証段階で
仮説検証段階で
設計、プロセス段階で

分けたり、重ねたり、ややこしい…。
そんなことできるのかな。

少しずつ練度を⾼めよう
① Why、How、What それぞれの段階の練度を⾼める
例えば開発にスクラムを導⼊しよう、⻑期にわたる検証を始める前に
DESIGN SPRINTを1週間やろう。
分けたり、重ねたり、ややこしい…。
そんなことできるのかな。
② Why、How、What の重なりをつくる
例えば開発を始める前にインセプションデッキでPOを巻き込む。
POが⼀⼈でプロダクトバックログを出すのではなく、⼀緒にストーリー
マッピングをやる。
③ Why、How、Whatの⾏き来を早める

Why、How、Whatの⾏き来を
早めるってどういうこと？

Why、How、Whatの⾏き来を
早めるってどういうこと？
「考えたことが、そのまま⼿の動きに繋がる」感じ
われわれはなぜアジャイルに向かうのか
そのためにプロセスは、
アーキテクチャは、
検証はどうあるべきか？
(to be continued…)

[補⾜] クリティカル・メイキング
http://www.bnn.co.jp/books/8790/
⼗分に考えつくしてからモノづくりを
始めるのではなく、⼿を動かしてものを
つくる体験(Making)の中から、⾃分
なりの⽅法論、プロセスを⽣み出す
考え⽅。
Thing(モノ) から Thinkingすること
から Thingking(シングキング)と⾔う
表現もされる。
https://forbesjapan.com/articles/detail/16355
エアビーアンドビー創業者を輩出
「美⼤のハーバード」の意外な授業

最後に。

重ねられる = 共創の関係
重なりをつくっていくためには
関係性の⾒直しや改善が必要。
「あなた対わたし」ではなく、
「⽬的とわたしたち」の関係

楽しいジャーニーを。

アジャイル開発はWhyから始まる

Recommended

Recommended

More Related Content

What's hot

What's hot (20)

Similar to アジャイル開発はWhyから始まる

Similar to アジャイル開発はWhyから始まる (20)

More from toshihiro ichitani

More from toshihiro ichitani (20)

アジャイル開発はWhyから始まる