ともに考え、ともにつくる〜リーン・ジャーニー・スタイル〜

1. ともに考え、ともにつくる Ichitani Toshihiro 市⾕聡啓「リーン・ジャーニー・スタイル」のプロダクト開発

2. (My KeyWord) 市⾕聡啓仮説検証型アジャイル開発正しいものを正しくつくる越境 Ichitani Toshihiro

3. https://ichitani.com/ Proﬁle

4. 本⽇のテーマともに考え、ともにつくる不確実性⾼い⽬のプロダクトづくりの⽂脈での進め⽅

5. 対象の状況、切実な課題、適したソリューション分かっていることより、分からないことの⽅が多い

6. 選択の幅最⼤（セットベース）検証計画仮説⽴案 (モデル化) 検証評価価値探索（正しいものを探す） MVP特定開発計画 (リリースプランニング) スプリントプランニングスプリント開発スプリントレビュースプリントレトロスペクティブ MVP検証アジャイル開発（正しくつくる）次の検証計画 (価値探索)へ選択の振れ幅最⼩（ポイントベース）仮説検証型アジャイル開発不確実性⾼い⽬のプロダクトづくりの⽂脈での進め⽅

7. 仮説キャンバスによる仮説⽴案インタビューや観察を通じた状況の把握(エスノグラフィー) ⾏動フローベースで必要な仕組みの設計プロトタイプ制作と調整プロトタイプ検証仮説のupdate ※終結段階で仮説キャンバス及び必要な粗いプロダクトバックログが揃うモデル現実モデル現実

8. 分からないことを分かるようにする

9. 「分からないものを分かるようにする」戦略正しいものを正しくつくる分からないから選択肢を広く持つ → 決め打ちして間違えると時間的損失が⼤きい (時間あたりで得られる学びが少ない) 最も「分かる」のは想像ではなく現実に直⾯した時 → いかに現実に近い状況を(コスパ良く)つくるか「分かる」に使う距離(時間|予算)を段階的に → 学びを活かす「次」の設計=段階化 (サンクコストの最⼩化)

10. 選択の幅最⼤（セットベース）検証計画仮説⽴案 (モデル化) 検証評価価値探索（正しいものを探す） MVP特定開発計画 (リリースプランニング) スプリントプランニングスプリント開発スプリントレビュースプリントレトロスペクティブ MVP検証アジャイル開発（正しくつくる）次の検証計画 (価値探索)へ選択の振れ幅最⼩（ポイントベース）⽬的選択の段階実体選択の段階⼿段選択の段階コンセプトの検証ユーザーにとって有⽤かつ必要最⼩限の範囲の機能特定アーキテクチャ設計、 UIデザイン、データ設計順序選択の段階プロダクトバックログのリファインメント選択を”段階”にすることで不確実性を対処する例えば、⼿段選択の段階でコンセプトを変える決定の影響の⼤きさは明らか

11. 学習と意思決定の反復化かつ段階化不確実性への適応とは、選択を最適化するためにを⽬指すこと

12. 選択の幅最⼤（セットベース）検証計画仮説⽴案 (モデル化) 検証評価価値探索（正しいものを探す） MVP特定開発計画 (リリースプランニング) スプリントプランニングスプリント開発スプリントレビュースプリントレトロスペクティブ MVP検証アジャイル開発（正しくつくる）次の検証計画 (価値探索)へ選択の振れ幅最⼩（ポイントベース）ザ・プロダクトオーナーワールドザ・開発チームワールド ”考える” を⼀⼈のプロダクトオーナーがすべて背負う世界選択の最⼤化に反する

14. Photo credit: afagen on Visualhunt.com / CC BY-NC-SA "プロダクトオーナー”の⺠主化 PO⼀⼈の視座、視野からチームの視座、視野へ

15. 当然こうなるので仮説と検証を中⼼に置いてプロダクトの基準をする実体としては仮説キャンバス

16. 仮説検証をPOだけではなくチームで⾏うプロダクトに関する基準をチームに宿す (検証結果と学びを共同所有する)

17. 参画者の多様性でもってプロダクトの不確実性に対抗する Photo on VisualHunt

18. 多様性 ☓ 機動性プロダクトづくりに多様性を取り込む、では次に⽬指すことは？多様性によって広がる選択に最⼤限適応していく

19. ともに考え、ともにつくる重奏的仮説検証ジャーニースタイルフォーメーション・パターン適者⽣存型アーキテクチャ仮説検証プロセスチームアーキ

20. 重奏的仮説検証仮説検証の外在化第1段階 1⼈の解釈を⼀⽅的に伝える仮説キャンバスで仮説を外在化 (誰でも表明が出来る) (解釈を頭から取り出す) 仮説検証

21. 重奏的仮説検証仮説検証の重奏化第2段階 (それぞれが解釈し掛け合わせる) それぞれの中に仮説を持ち、共通の理解に対して掛け合わせる・多様なメンバー=多様な解釈への期待・検証を通じての仮説⽴案が前提・仮説検証の実施リードや解釈のメンター役は必要(仮説検証リード) 仮説検証

22. 重奏的仮説検証内部探索と外部探索の交差実践プロダクトレビュー PR プロダクトレビュー(内部探索) 全員参加で主要ユースケースのウォークスルー(実際に使う) プロダクトレビューの結果適宜仮説やupdate ユーザーテスト(外部探索) ⾃チームの仮説をユーザーに実際に提供して観察する →新たな仮説を得る仮説検証

24. ジャーニースタイルプロダクトづくりもチームも機動性を⾼めながら(混沌) それでいてきっちり着地はしたい(秩序) プロセス時間とお⾦とともに⼈の意識も有限なリソース延々と意識⾼く、あるいは集中し続けられるわけではないビジョンだけでは遠くすぎる (着地予測が不可能、意識も続かない) スプリントゴールだけでは⼩さすぎる (レンガを積み上げ⽉を⽬指す) 段階(ジャーニー)の設計ゆえに、タイムボックスの構造化で適応する

25. ジャーニースタイルプロセススプリント < 複数スプリント < ⽬的地 1週間まとまった単位のテーマに割り当てる期間事業上のマイルストーン段階(ジャーニー)の設計・到達したい⽬的地の把握から、逆算して必要なジャーニーを割り出す・各ジャーニーでの到達状態、指標の⽬標値を⾔語化、定量化する・ジャーニーを終える度にふりかえり、⽬的地にむきなおる。適宜、ジャーニーの延⻑(スプリント追加)、新しいジャーニーの追加を⾏う (スプリントは固定、ジャーニーは可変) MVPの完成製品の⾻格完成 (例) チームビルド

26. ジャーニースタイルプロセスタイムボックスも、バックログも構造化する可変領域を作ることで機動性を⾼める (⽅向性に基づく転回の容易さ) プロダクトバックログジャーニーバックログスプリントバックログ第1ジャーニーのバックログはここまで第2ジャーニーのバックログは始める時にリファインメントする (プロダクトレビューを挟む可能性が⾼い) 情報の粒度的にジャーニーバックログでプロダクトチームとステークホルダーでコミュニケーションしたいジャーニーバックログ単位でチームを結成するので、チームを増やすスケールポイントになりうる

28. フォーメーション・パターンチームミッションC ミッションB ミッションA 各ジャーニー毎に到達したい「ミッション」は異なる当然、ミッション実現に必要なチームの機能性も、⽅針も異なるジャーニーにあわせて、・チームのフォーメーション・チームのファースト(主義) を可変にする例)ジャーニーミッション「UIの改善」例)ジャーニーミッション「プロダクト改善後の評価」フロント開発メンバー多⽬検証メンバー多⽬フォーメーションとして「リード」を置く。例えば、フロントエンドリードはフロントエンドの開発の実装と意思決定、協働を先導するミッションに必要なリードを置く

29. 雁⾏陣開発

30. https://www.slideshare.net/papanda/ss-142143920 詳しくはこちら「雁⾏陣開発」 ※フォーメーションの⼀例

31. フォーメーション・パターンチームチームイズムを変えるジャーニーを進むにあたって、チームで何を優先するか？⽅針のうち、どの度合いを⾼めるか？ミッションに必要なファースト(主義)の選択を⾏う (ジャーニースタイルだからこそチームイズムを変えやすい) チームファースト⺠主的な在り⽅を、第⼀とする。合意による意思決定。チームの協働感を⾼める施策の実施に重点を置く。プロダクトファーストプロダクトで成果をあげることを第⼀とする。そのために必要なアウトプットを最優先にする。タスクファーストタスクの消化を最優先とする。コマンド&コントロールもしくは個⼈商店になりがち。⻑期化すると現場が塹壕化する。ファーストのパターン例

33. 適者⽣存型アーキテクチャアーキアーキテクチャの選択を、プロダクトに関する理解の深まりに合わせる。理解とは、状況の、課題の、解決策の何が分かったのか。分かった度合いに応じて「次に分かりたいこと」を構想し、そのためのアーキテクチャを選択する。 https://blog.crisp.se/2016/01/25/henrikkniberg/making-sense-of-mvp

34. 現実歪曲曲線もっともリアリティのある「分かる」は、想定ユーザーに現実のプロダクトそのものを使ってもらうこと。検証の計画づくりにあたっては、いかに「現実感のある」 (でも現実のプロダクトではない)⼿段で想定ユーザーの反応を⾒るかが焦点となる。

35. 適者⽣存型アーキテクチャアーキ圧倒的にハリボテをつくる圧倒的に分離してつくる (フロントエンドとバックエンド) まだ何が必要なのか検討ついていない何が問題なのか分かってきた。触れるもの提供。どんな機能性が必要なのか分かってきた。構造最適化現実歪曲曲線の進み⽅イメージ運⽤、スケールを想定し構造重視の設計例えばXDやfigmaでビジュアルプロトタイプを起す例えばフロントはvue.jsでバックエンドはfirebaseでつくる例えばフロントのvue.jsは残し、バックエンドを firebaseからRDBやGraphQL 前提に移管する

36. 適者⽣存型アーキテクチャアーキ現実を歪曲させながら(ユーザーにとってはほぼ現実)、検証結果からの「学びの継承」と前時代の遺構を利⽤した「構造転換」を⾏う例えばXDやfigmaでビジュアルプロトタイプを起す例えばフロントはvue.jsでバックエンドはfirebaseでつくる例えばフロントのvue.jsは残し、バックエンドを firebaseからRDBやGraphQL 前提に移管するデザインの知識継承フロントの構造継承

37. 適者⽣存型アーキテクチャアーキ実践あるプロダクトでの適者⽣存アーキテクチャ適⽤ 2018年試作を終了 ﬁgmaでビジュアル作り込み既に試作を⾏っていた為、ビジュアルのイメージがある。この段階で⼀度精緻なビジュアルプロトで徹底的な内部探索 HTML作成 + AtomicDesign 試作機による想定ユーザーでの検証は実施済。PSﬁtの⾒込みをつける。ただし学習の結果初期のデータモデルは破綻。 Vue.js + GraphQL ⼀旦HTMLベースで⼀通り画⾯をつくりコンポーネント設計を⾏う。構造転換が先々で⾏いやすように。 HTMLの仮組みをベースに Vue.jsでフロント開発を先⾏。フロントだけで動く形にしてさらに内部探検。遅れてバックエンドは構造転換しやすいようGraphQL

38. 適者⽣存型アーキテクチャアーキ Atomic Design→⾃チーム流の構造化当初Atomic Designでコンポーネント設計を⾏っていたが「定義上の正解は何？沼」にはまる。チームの外から定義を取ってつけようとするのではなくエンジニアとデザイナーの当事者でコンポーネント定義。補⾜・レイヤー構造をチームで定義、名前付けする・各レイヤーの責務をチームで決めること (特にロジックの責務を持ったレイヤーの認識揃える) ・CSSの構造をて定義したレイヤー構造に合わせる (ベースはFLOCSS) ・カタログ化はStorybookで

39. 適者⽣存型アーキテクチャアーキ GraphQLでのバックエンド構築補⾜新しい体験を実現するプロダクトほどデータ構造を決めきることができない(学びによって在るべきが頻繁に変わる) データ構造の転換の影響を出来る限り局所化したい。 Schema駆動開発 (フロントとバックの間はschemaの構造合意で充⾜) ・フロントとバックでそれぞれが独⽴して開発を進められる・バック側はデータ構造とAPIの差分を実装で埋められる・変更が発⽣する場合どう変更するのかをschemaに反映することでコミュニケーションミスを減らせる

40. 適者⽣存型アーキテクチャアーキプロダクト開発の環境保全補⾜ GitHub CircleCI Code Build Project EKS-cluster Production-Node- Group Staging-Node-Group Production- namespace Staging- namespace Demo-namespace CI/CDでプロダクト開発の環境を保全。ブランチ運⽤はgit feature ﬂow。機能リリースの先後を微細に管理。

41. 適者⽣存型アーキテクチャアーキ clickupでカンバン開発補⾜開発メンバーがそれぞれの状況によって分断しがち (リモートワーク、複業) 同期イベントを最⼩限にして(※1)、状態管理を強めに = カンバン (※1)同期イベントが少ない= プロダクトについての共通理解を育みにくい。だからこそプロダクトレビューの位置づけが重要。 (※2)Clickupのスロット管理がバックログの構造化に適している conﬁdential conﬁdential (※2)

42. ともに考え、ともにつくる重奏的仮説検証ジャーニースタイルフォーメーション・パターン適者⽣存型アーキテクチャ仮説⽴案プロセスチームアーキ

43. 結論「分からないものを分かるようにする」ために選択の幅を保ちつつ、仮説検証によって絞っていく (リーン製品開発のセットベースがベース) 選択の幅を広げるために、チームの多様性を指向する (同時にプロダクトについての理解(基準)を仮説検証で合わせる) 多様な学びに最⼤限適応するために、プロダクトづくりの機動性を⾼める (重奏的仮説検証、ジャーニースタイル、フォーメーションパターン、適者⽣存型アーキテクチャ)

44. リーン・ジャーニー・スタイルともに考え、ともにつくるプロダクト開発正解の無い世界でそれでも前に進むために。問いに向き合うジャーニーを続けよう。

45. 謝辞ともに考え、ともにつくるにあたるチームメンバーへ Takahashi Toshiaki Numata Keisuke Okada Takumi Matsuda Yasuaki Kutsu Hirokazu  Ogata Yuto Masuda Kyohei Abe Tadanori

ともに考え、ともにつくる〜リーン・ジャーニー・スタイル〜

Vous êtes en train de lire un aperçu.

Consultez-les par la suite

ともに考え、ともにつくる〜リーン・ジャーニー・スタイル〜

Plus De Contenu Connexe

Diaporamas pour vous (20)

Similaire à ともに考え、ともにつくる〜リーン・ジャーニー・スタイル〜 (20)

Plus par toshihiro ichitani (20)

Plus récents (20)