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

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

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