アジャイル開発はWhyから始まる
3.6K Views
December 15, 17
スライド概要
エンタープライズアジャイル勉強会2017年12月で話した内容
関連スライド
各ページのテキスト
アジャイル開発は Whyから始まる Agile Development Start with Why. Ichitani Toshihiro Toshihiro Ichitani All Rights Reserved. 市⾕聡啓
Ichitani Toshihiro 市⾕聡啓 ギルドワークス株式会社 代表 DevLOVE コミュニティ ファウンダ ⼀般社団法⼈ アジャイルチームを⽀える会 理事 ソフトウェア開発16年 SIer→サービス→受託→起業 仮説検証とアジャイル開発 0→1 http://about.me/papanda0806 Toshihiro Ichitani All Rights Reserved.
本⽇のテーマ アジャイル開発で良いプロダクトを作るためには 開発チームの外側で解決した⽅が良いことがある。 実現すべき価値とは何か「コンセプト」の観点 価値の実現の仕⽅「アーキテクチャ」の観点 このお話では前者の「コンセプト」の観点を扱います Copyright (c) 2017 Guild Works Inc.
質問 これから開発するプロダクトで 「ユーザーのどんな⽤事を⽚付けるのか」が あいまいな状態で開発を始めるとどうなるか？ Copyright (c) 2017 Guild Works Inc.
質問 これから開発するプロダクトで 「ユーザーのどんな⽤事を⽚付けるのか」が あいまいな状態で開発を始めるとどうなるか？ たいてい、むちゃくちゃになる Copyright (c) 2017 Guild Works Inc.
「何をつくるべきか分からない」のに始められる？ 何が起きるか？ 優先度が頻繁に変わる可能性が⾼い (例えば、スプリント毎に) そうなると…エピック(開発レディではない要求) を開発可能にするための作業負荷が⼀気に⾼まる アーキテクチャレベルから実現⽅法を考えないと。 でも、⽬の前にはもう次のスプリントが！ 新しいアーキテクチャと、既存のアーキテクチャ そして、既存コードとの整合性を取るために… Copyright (c) 2017 Guild Works Inc.
簡潔に⾔うと、右往左往する。 顧客開発(事業開発の⽅法論)をプロダクト開発 よりも極端に優先してしまうと、現実に起きる。 (作戦が⾜りていない) Copyright (c) 2017 Guild Works Inc.
ということは、何をつくるべきか 定めてから開発に着⼿しようって ことだよね？ Toshihiro Ichitani All Rights Reserved.
ということは、何をつくるべきか 定めてから開発に着⼿しようって ことだよね？ だからって、要件定義しろってことじゃあないよ。 そうなんだけど、ちょっと危ない誤解を招きそうなんで 補完すると、例えば「要件定義できっちり⽂書に落とし 込んでから開発しよう」ということを⾔いたい訳では ないよ。 むしろ、「何をつくるべきか」を明確に事前に⾔える ほど分かりやすいプロダクトをつくるような状況は 少くなってきているんじゃないかな。 Toshihiro Ichitani All Rights Reserved.
つくらずとも検証できるなら先にやろう。 ソフトウェア開発は「最もコストがかかる検証の準備」 になりやすい。だから、つくらずに検証できる⼿段が あるなら、開発する前に仮説検証するべきなんだ。 どのような検証に、どんな⼿段を⽤いるか？ 課題仮説検証 インタビュー ソリューション仮説検証 アンケート アテンション検証 プロトタイプ 体験を伴う検証 ランディングページ チャネル検証 動くソフトウェア ： Copyright (c) 2017 Guild Works Inc. ：
うーん。仮説検証と開発の関係が いまいちよく分からないなー。 Toshihiro Ichitani All Rights Reserved.
うーん。仮説検証と開発の関係が いまいちよく分からないなー。 これから、ゴールデンサークルを⽤いて説明するよ。 何を変えると、何がどうなるのか、ゴールデンサークルで 表現すると理解が深まるんじゃないかな。 ゴールデンサークルは、サイモン・シネック⽒が考えた 思考と⾏動と伝達のための有名なフレームワークなんだ。 「Whyから始めよ」という本も出ているよ。 Toshihiro Ichitani All Rights Reserved.
ゴールデンサークル Why How What Toshihiro Ichitani All Rights Reserved.
ゴールデンサークル 仮説検証 設計、プロセス 機能開発 Toshihiro Ichitani All Rights Reserved. ここが現場で⽇々⾏なう アジャイルソフトウェア開発 にあたる
What、How、Whyを⼀つ⼀つ⾒ていきましょう。 Copyright (c) 2017 Guild Works Inc.
What = ユーザーが必要とするプロダクトをつくること ユーザーの要求を満たすための機能をつくる活動 そのものにあたる (= 開発チームの⽇々の活動)。 では、開発ではWhyを意識しなくて良いのだろうか？ Whyにも粒度と具体性のレベルがある。 ⽇々の活動で開発チームが捉えるべき要求のレベルと 仮説検証で捉えている要求(=仮説)のレベルには開きが あるんだ。 Copyright (c) 2017 Guild Works Inc.
[補⾜] ⼈の理解って、段階がある。 要求の粒度、具体性、分割。 この⼿の話は「アジャイルソフトウェア要求」が参考になる。 「アジャイルソフトウェア要求」 https://www.amazon.co.jp/dp/B00IMRDXZW 重厚な匂いがする?(確かに本は厚い!) この通りの型にはめようとするじゃなくて、 「⼈の理解って、ざっくり理解と詳しく理解と、段階があるよね」 に気付けることが⼤事。興味がある⽅はSAFeもチェックしよう。 http://www.scaledagileframework.com/ Copyright (c) 2017 Guild Works Inc.
仮説、エピック、ストーリー。 …という名前付けが⼤事なのではなくて、粒度と具体性のレベル分 けや認識が出来ているかが⼤事。 アイデア段階のため 何をどうつくるべきか 選択肢の幅は広い 仮説 検証結果を踏まえて 何をつくるべきかの 選択肢は狭まる どうなれば完成と いえるのか条件が定義 可能となるまで詳細化する エピック ストーリー Toshihiro Ichitani All Rights Reserved.
仮説とは？ストーリーとは？ (仮説)キャンバスの各エリア の⼀つ⼀つが仮説。 ストーリーとは3段構成で 表現される⼀つ⼀つの要求。 「ユーザーストーリー駆動開発で⾏こう。」 https://www.slideshare.net/papanda/ss-41638116 Toshihiro Ichitani All Rights Reserved.
ゴールデンサークル 仮説検証 仮説レベル 設計、プロセス 機能開発 Toshihiro Ichitani All Rights Reserved. ストーリーレベル
あれ？エピック→ストーリーの 分割とか詳細化はどこでやるの？ Toshihiro Ichitani All Rights Reserved.
あれ？エピック→ストーリーの 分割とか詳細化はどこでやるの？ サークルのHow段階か、What段階で⾏なう まず、エピック→ストーリーの詳細化は、仮説検証の 段階ではやらない。 「機能開発の段階」(What)で⾏なうか、 「機能開発の前段階のプランニング」(How)で⾏なうかで 要求に対する開発の弾⼒性が異なることになる。 (後者の⽅がスコープが硬めになる) どちらが正ではなくて「どの程度変更を受け⼊れる開発 であるべきか」で決める。 Toshihiro Ichitani All Rights Reserved.
要求への開発プロセス弾⼒性 ケース1：How段階でストーリー化し、初期スコープをほぼ固定する (スプリントの成果に対するフィードバックの選択のみ⾏なう) 着地優先 ケース2：What段階でストーリー化する。適宜プランは⾒直す (ケース1よりもっと、変更の受け⼊れをプロセスとして織り込む) 探索優先 Toshihiro Ichitani All Rights Reserved.
Whatの次は、Howを⾒ましょう。 Copyright (c) 2017 Guild Works Inc.
ゴールデンサークル 仮説検証 設計、プロセス 機能開発 Toshihiro Ichitani All Rights Reserved. 初期の計画づくりも
How = 検証された価値を実現するための⼿段の検討 アーキテクチャの設計 プロセスのフレームを決める 初期のモデリング リリースプランニング インセプションデッキ 価値の実現⽅式の設計と、What(機能開発)をレディに するための諸活動。 (いわゆる「イテレーションゼロ」と呼ばれることも) Copyright (c) 2017 Guild Works Inc.
How to What Howレベルで⽅針が変わると、Whatへの影響は⼤きい 逆にWhatのやり⽅を変えるためにはHowから考え直す 例えば、スマホアプリをWeb Viewで作ってきたけども ある体験を実現する必要が分かり、ネイティブでの開発 (新しいHow)が必要になった、など。 Toshihiro Ichitani All Rights Reserved.
Why to How to What なので、Whyが変わると影響はさらに⼤きい。 新たなWhyを実現するためのHowの設計。Whatの⾒直し。 リーンスタートアップで 「ピボット」と呼ばれる レベルの転換。 価値仮説(Why)が変わるの だから場合によっては事業や サービスががらっと変わる レベル。 Toshihiro Ichitani All Rights Reserved.
[補⾜] WhatからWhyを問い直す 機能開発(What)の活動の結果、MVPがつくりだされる。 (MVP=実⽤的で最⼩限の範囲のプロダクト) MVPでの検証の⽬的は、その結果から価値仮説(Why)を 問い直すことである。後に残していたソフトウェアによる 最もリアルな検証にあたる。 MVPによる検証 MVP Toshihiro Ichitani All Rights Reserved.
ゆえに、Why(仮説検証)から始める 仮説検証 設計、プロセス 機能開発 Toshihiro Ichitani All Rights Reserved.
で、どうやるの？ Toshihiro Ichitani All Rights Reserved.
仮説検証の基本 Toshihiro Ichitani All Rights Reserved.
仮説検証の流れ 仮説検証を「分からないことを分かるようにする」ための 旅路(ジャーニー)と捉えて、活動の設計を⾏なう。 「検証プランニング→検証活動→結果分析」を繰り返し ⾏なう。検証活動の具体的な道具⽴ては、検証すべき テーマに基いて選択を⾏なう。以下はその⼀例。 検証の開始 検証のための ブリーフィング (初期計画) 第1回検証活動 第2回検証活動 検証の終結 想定顧客 インタビュー プロタイプ制作 プロタイプ検証 サービス仕様の 定義 Toshihiro Ichitani All Rights Reserved.
検証活動で具体的にどのような道具⽴てを扱うかは こちらのスライド参照といたします。 https://www.slideshare.net/papanda/ss-69585461 Copyright (c) 2017 Guild Works Inc.
なるほど〜。Why→How→Whatで 活動を進めていけばいいのね。 Toshihiro Ichitani All Rights Reserved.
なるほど〜。Why→How→Whatで 活動を進めていけばいいのね。 Why と How と Whatの重なりをつくる そうなんだけど、Whyフェーズ、Howフェーズ、 Whatフェーズとかいう考えで切っちゃうと⼤事な観点が 抜けちゃうんだ。それは、 「ソフトウェアとは少しずつ形になる中で、 どうあるべきかが分かったり、発⾒があったりするもの」 ということだ。なので、3つのレイヤーを分断するのでは なく、如何に重なりをつくるかが⼤事なんだ。 Toshihiro Ichitani All Rights Reserved.
What over How over Why 仮説検証段階で PO ☓ 開発者 による「プロトタイピング」 (プロダクトオーナー) 仮説検証段階で PO ☓ 開発チーム で「ユーザーストーリーマッピング」 設計、プロセス段階で PO ☓ 開発チームで「インセプションデッキ」 ユーザーストーリー マッピング Toshihiro Ichitani All Rights Reserved. インセプション デッキ
分けたり、重ねたり、ややこしい…。 そんなことできるのかな。 Toshihiro Ichitani All Rights Reserved.
分けたり、重ねたり、ややこしい…。 そんなことできるのかな。 少しずつ練度を⾼めよう ① Why、How、What それぞれの段階の練度を⾼める 例えば開発にスクラムを導⼊しよう、⻑期にわたる検証を始める前に DESIGN SPRINTを1週間やろう。 ② Why、How、What の重なりをつくる 例えば開発を始める前にインセプションデッキでPOを巻き込む。 POが⼀⼈でプロダクトバックログを出すのではなく、⼀緒にストーリー マッピングをやる。 ③ Why、How、Whatの⾏き来を早める Toshihiro Ichitani All Rights Reserved.
Why、How、Whatの⾏き来を 早めるってどういうこと？ Toshihiro Ichitani All Rights Reserved.
Why、How、Whatの⾏き来を 早めるってどういうこと？ 「考えたことが、そのまま⼿の動きに繋がる」感じ そのためにプロセスは、 アーキテクチャは、 検証はどうあるべきか？ (to be continued…) われわれはなぜアジャイルに向かうのか https://www.slideshare.net/papanda/ss-79465986 Toshihiro Ichitani All Rights Reserved.
[補⾜] クリティカル・メイキング ⼗分に考えつくしてからモノづくりを 始めるのではなく、⼿を動かしてものを つくる体験(Making)の中から、⾃分 なりの⽅法論、プロセスを⽣み出す 考え⽅。 Thing(モノ) から Thinkingすること から Thingking(シングキング)と⾔う 表現もされる。 エアビーアンドビー創業者を輩出 「美⼤のハーバード」の意外な授業 http://www.bnn.co.jp/books/8790/ https://forbesjapan.com/articles/detail/16355 Toshihiro Ichitani All Rights Reserved.
最後に。 Copyright (c) 2017 Guild Works Inc.
重なりをつくっていくためには 関係性の⾒直しや改善が必要。 「あなた 対 わたし」ではなく、 「⽬的 と わたしたち」の関係 重ねられる = 共創の関係 Toshihiro Ichitani All Rights Reserved.
楽しいジャーニーを。 Toshihiro Ichitani All Rights Reserved.