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