Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

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

5,837 views

Published on

EOF2019で発表した内容。

Published in: Software
  • Be the first to comment

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

  1. 1. ともに考え、ともにつくる Ichitani Toshihiro 市⾕聡啓 「リーン・ジャーニー・スタイル」の プロダクト開発
  2. 2. (My KeyWord) 市⾕ 聡啓 仮説検証型アジャイル開発 正しいものを正しくつくる 越境 Ichitani Toshihiro
  3. 3. https://ichitani.com/ Profile
  4. 4. 本⽇のテーマ ともに考え、ともにつくる 不確実性⾼い⽬のプロダクトづくりの⽂脈での進め⽅
  5. 5. 対象の状況、切実な課題、適したソリューション 分かっていることより、分からないことの⽅が多い
  6. 6. 選択の幅最⼤ (セットベース) 検証 計画 仮説⽴案 (モデル化) 検証 評価 価値探索 (正しいものを探す) MVP特定 開発計画 (リリースプラ ンニング) スプリントプ ランニング スプリント 開発 スプリント レビュー スプリント レトロスペクティ ブ MVP検証 アジャイル開発 (正しくつくる) 次の検証計画 (価値探索)へ 選択の振れ幅最⼩ (ポイントベース) 仮説検証型アジャイル開発 不確実性⾼い⽬のプロダクトづくりの⽂脈での進め⽅
  7. 7. 仮説キャンバスによる仮説⽴案 インタビューや観察を通じた 状況の把握(エスノグラフィー) ⾏動フローベースで 必要な仕組みの設計 プロトタイプ制作 と調整 プロトタイプ検証 仮説のupdate ※終結段階で仮説キャンバス及び  必要な粗いプロダクトバックログが揃う モデル 現実 モデル 現実
  8. 8. 分からないことを分かるようにする
  9. 9. 「分からないものを分かるようにする」戦略 正しいものを正しくつくる 分からないから選択肢を広く持つ → 決め打ちして間違えると時間的損失が⼤きい   (時間あたりで得られる学びが少ない) 最も「分かる」のは想像ではなく現実に 直⾯した時 → いかに現実に近い状況を(コスパ良く)つくるか 「分かる」に使う距離(時間|予算)を段階的に → 学びを活かす「次」の設計=段階化   (サンクコストの最⼩化)
  10. 10. 選択の幅最⼤ (セットベース) 検証 計画 仮説⽴案 (モデル化) 検証 評価 価値探索 (正しいものを探す) MVP特定 開発計画 (リリースプラ ンニング) スプリントプ ランニング スプリント 開発 スプリント レビュー スプリント レトロスペクティ ブ MVP検証 アジャイル開発 (正しくつくる) 次の検証計画 (価値探索)へ 選択の振れ幅最⼩ (ポイントベース) ⽬的選択の 段階 実体選択の 段階 ⼿段選択の 段階 コンセプトの検証 ユーザーに とって有⽤ かつ必要最 ⼩限の範囲 の機能特定 アーキテクチャ 設計、 UIデザイン、 データ設計 順序選択の 段階 プロダクトバックログ のリファインメント 選択を”段階”にすることで不確実性を対処する  例えば、⼿段選択の段階でコンセプトを 変える決定の影響の⼤きさは明らか
  11. 11. 学習と意思決定の反復化かつ段階化 不確実性への適応とは、選択を最適化するために を⽬指すこと
  12. 12. 選択の幅最⼤ (セットベース) 検証 計画 仮説⽴案 (モデル化) 検証 評価 価値探索 (正しいものを探す) MVP特定 開発計画 (リリースプラ ンニング) スプリントプ ランニング スプリント 開発 スプリント レビュー スプリント レトロスペクティ ブ MVP検証 アジャイル開発 (正しくつくる) 次の検証計画 (価値探索)へ 選択の振れ幅最⼩ (ポイントベース) ザ・プロダクトオーナー ワールド ザ・開発チーム ワールド ”考える” を⼀⼈のプロダクトオーナーがすべて背負う世界 選択の最⼤化に反する
  13. 13. Toshihiro Ichitani All Rights Reserved. Photo credit: Steven Penton on VisualHunt / CC BY プロダクトオーナーの視座を プロダクトの上限(ボトルネック)にしない
  14. 14. Photo credit: afagen on Visualhunt.com / CC BY-NC-SA "プロダクトオーナー”の⺠主化 PO⼀⼈の視座、視野から チームの視座、視野へ
  15. 15. 当然こうなるので 仮説と検証を中⼼に置いて プロダクトの基準をする 実体としては仮説キャンバス
  16. 16. 仮説検証をPOだけではなく チームで⾏う プロダクトに関する基準をチームに宿す (検証結果と学びを共同所有する)
  17. 17. 参画者の多様性でもって プロダクトの不確実性に対抗する Photo on VisualHunt
  18. 18. 多様性 ☓ 機動性 プロダクトづくりに多様性を取り込む、では次に⽬指すことは? 多様性によって広がる選択に最⼤限適応していく
  19. 19. ともに考え、ともにつくる 重奏的仮説検証 ジャーニースタイル フォーメーション・パターン 適者⽣存型アーキテクチャ 仮説検証 プロセス チーム アーキ
  20. 20. 重奏的仮説検証 仮説検証の外在化 第1段階 1⼈の解釈を⼀⽅的に伝える 仮説キャンバスで仮説を外在化 (誰でも表明が出来る) (解釈を頭から取り出す) 仮説検証
  21. 21. 重奏的仮説検証 仮説検証の重奏化 第2段階 (それぞれが解釈し掛け合わせる) それぞれの中に仮説を持ち、 共通の理解に対して掛け合わせる ・多様なメンバー=多様な解釈への期待 ・検証を通じての仮説⽴案が前提 ・仮説検証の実施リードや解釈の  メンター役は必要(仮説検証リード) 仮説検証
  22. 22. 重奏的仮説検証 内部探索と外部探索の交差 実践 プロダクト レビュー PR プロダクトレビュー(内部探索) 全員参加で主要ユースケースの ウォークスルー(実際に使う) プロダクトレビューの結果 適宜仮説やupdate ユーザーテスト(外部探索) ⾃チームの仮説をユーザー に実際に提供して観察する →新たな仮説を得る 仮説検証
  23. 23. ともに考え、ともにつくる 重奏的仮説検証 ジャーニースタイル フォーメーション・パターン 適者⽣存型アーキテクチャ 仮説検証 プロセス チーム アーキ
  24. 24. ジャーニースタイル プロダクトづくりもチームも機動性を⾼めながら(混沌) それでいてきっちり着地はしたい(秩序) プロセス 時間とお⾦とともに⼈の意識も有限なリソース 延々と意識⾼く、あるいは集中し続けられるわけではない ビジョンだけでは遠くすぎる (着地予測が不可能、意識も続かない) スプリントゴールだけでは⼩さすぎる (レンガを積み上げ⽉を⽬指す) 段階(ジャーニー)の設計 ゆえに、タイムボックスの構造化で適応する
  25. 25. ジャーニースタイル プロセス スプリント < 複数スプリント < ⽬的地 1週間 まとまった単位のテーマ に割り当てる期間 事業上の マイルストーン 段階(ジャーニー)の設計 ・到達したい⽬的地の把握から、逆算して  必要なジャーニーを割り出す ・各ジャーニーでの到達状態、指標の  ⽬標値を⾔語化、定量化する ・ジャーニーを終える度にふりかえり、  ⽬的地にむきなおる。適宜、ジャーニー  の延⻑(スプリント追加)、新しいジャー  ニーの追加を⾏う  (スプリントは固定、ジャーニーは可変) MVPの完成 製品の⾻格完成 (例) チームビルド
  26. 26. ジャーニースタイル プロセス タイムボックスも、バックログも構造化する 可変領域を作ることで機動性を⾼める (⽅向性に基づく転回の容易さ) プロダクトバックログ ジャーニーバックログ スプリントバックログ 第1ジャーニーのバックログはここまで 第2ジャーニーのバックログは始める時に リファインメントする (プロダクトレビューを挟む可能性が⾼い) 情報の粒度的にジャーニー バックログでプロダクト チームとステークホルダーで コミュニケーションしたい ジャーニーバックログ単位で チームを結成するので、チー ムを増やすスケールポイント になりうる
  27. 27. ともに考え、ともにつくる 重奏的仮説検証 ジャーニースタイル フォーメーション・パターン 適者⽣存型アーキテクチャ 仮説検証 プロセス チーム アーキ
  28. 28. フォーメーション・パターン チーム ミッションC ミッションB ミッションA 各ジャーニー毎に到達したい 「ミッション」は異なる 当然、ミッション実現に必要な チームの機能性も、⽅針も異なる ジャーニーにあわせて、 ・チームのフォーメーション ・チームのファースト(主義) を可変にする 例)ジャーニーミッション 「UIの改善」 例)ジャーニーミッション 「プロダクト改善後の評価」 フロント開発メンバー多⽬ 検証メンバー多⽬ フォーメーションとして「リード」 を置く。例えば、フロントエンド リードはフロントエンドの開発の 実装と意思決定、協働を先導する ミッションに必要なリードを置く
  29. 29. 雁⾏陣開発
  30. 30. https://www.slideshare.net/papanda/ss-142143920 詳しくはこちら 「雁⾏陣開発」 ※フォーメーションの⼀例
  31. 31. フォーメーション・パターン チーム チームイズムを変える ジャーニーを進むにあたって、チームで何を優先するか? ⽅針のうち、どの度合いを⾼めるか?ミッションに必要な ファースト(主義)の選択を⾏う (ジャーニースタイルだからこそチームイズムを変えやすい) チームファースト ⺠主的な在り⽅を、第⼀ とする。合意による意思決定。 チームの協働感を⾼める施策 の実施に重点を置く。 プロダクトファースト プロダクトで成果をあげるこ とを第⼀とする。そのために 必要なアウトプットを最優先 にする。 タスクファースト タスクの消化を最優先とする。 コマンド&コントロールもしく は個⼈商店になりがち。⻑期 化すると現場が塹壕化する。 ファーストのパターン例
  32. 32. ともに考え、ともにつくる 重奏的仮説検証 ジャーニースタイル フォーメーション・パターン 適者⽣存型アーキテクチャ 仮説検証 プロセス チーム アーキ
  33. 33. 適者⽣存型アーキテクチャ アーキ アーキテクチャの選択を、プロダクトに関する理解の 深まりに合わせる。 理解とは、状況の、課題の、解決策の何が分かったのか。 分かった度合いに応じて「次に分かりたいこと」を構想 し、そのためのアーキテクチャを選択する。 https://blog.crisp.se/2016/01/25/henrikkniberg/making-sense-of-mvp
  34. 34. 現実歪曲曲線 もっともリアリティのある「分かる」は、想定ユーザーに 現実のプロダクトそのものを使ってもらうこと。 検証の計画づくりにあたっては、いかに「現実感のある」 (でも現実のプロダクトではない)⼿段で想定ユーザーの 反応を⾒るかが焦点となる。
  35. 35. 適者⽣存型アーキテクチャ アーキ 圧倒的にハリボテを つくる 圧倒的に分離して つくる (フロントエンドとバックエンド) まだ何が必要なのか 検討ついていない 何が問題なのか分かって きた。触れるもの提供。 どんな機能性が必要なのか 分かってきた。構造最適化 現実歪曲曲線の進み⽅イメージ 運⽤、スケールを想定し 構造重視の設計 例えばXDやfigmaで ビジュアルプロトタイプ を起す 例えばフロントはvue.jsで バックエンドはfirebaseで つくる 例えばフロントのvue.jsは 残し、バックエンドを firebaseからRDBやGraphQL 前提に移管する
  36. 36. 適者⽣存型アーキテクチャ アーキ 現実を歪曲させながら(ユーザーにとってはほぼ現実)、 検証結果からの「学びの継承」と前時代の遺構を利⽤した 「構造転換」を⾏う 例えばXDやfigmaで ビジュアルプロトタイプ を起す 例えばフロントはvue.jsで バックエンドはfirebaseで つくる 例えばフロントのvue.jsは 残し、バックエンドを firebaseからRDBやGraphQL 前提に移管する デザインの知識継承 フロントの構造継承
  37. 37. 適者⽣存型アーキテクチャ アーキ 実践 あるプロダクトでの適者⽣存アーキテクチャ適⽤ 2018年 試作を終了 figmaで ビジュアル作り 込み 既に試作を⾏ってい た為、ビジュアルの イメージがある。 この段階で⼀度精緻 なビジュアルプロト で徹底的な内部探索 HTML作成 + AtomicDesign 試作機による想定 ユーザーでの検証は 実施済。PSfitの⾒ 込みをつける。 ただし学習の結果 初期のデータモデル は破綻。 Vue.js + GraphQL ⼀旦HTMLベースで ⼀通り画⾯をつくり コンポーネント設計 を⾏う。 構造転換が先々で⾏ いやすように。 HTMLの仮組みをベースに Vue.jsでフロント開発を先 ⾏。 フロントだけで動く形に してさらに内部探検。遅れ てバックエンドは構造転換 しやすいようGraphQL
  38. 38. 適者⽣存型アーキテクチャ アーキ Atomic Design→⾃チーム流の構造化 当初Atomic Designでコンポーネント設計を⾏っていたが 「定義上の正解は何?沼」にはまる。 チームの外から定義を取ってつけようとするのではなく エンジニアとデザイナーの当事者でコンポーネント定義。 補⾜ ・レイヤー構造をチームで定義、名前付けする ・各レイヤーの責務をチームで決めること   (特にロジックの責務を持ったレイヤーの認識揃える) ・CSSの構造をて定義したレイヤー構造に合わせる (ベースはFLOCSS) ・カタログ化はStorybookで
  39. 39. 適者⽣存型アーキテクチャ アーキ GraphQLでのバックエンド構築 補⾜ 新しい体験を実現するプロダクトほどデータ構造を決め きることができない(学びによって在るべきが頻繁に変わる) データ構造の転換の影響を出来る限り局所化したい。 Schema駆動開発 (フロントとバックの間はschemaの構造合意で充⾜) ・フロントとバックでそれぞれが独⽴して開発を進められる ・バック側はデータ構造とAPIの差分を実装で埋められる ・変更が発⽣する場合どう変更するのかをschemaに反映する  ことでコミュニケーションミスを減らせる
  40. 40. 適者⽣存型アーキテクチャ アーキ プロダクト開発の環境保全 補⾜ GitHub CircleCI Code Build Project EKS-cluster Production-Node- Group Staging-Node-Group Production- namespace Staging- namespace Demo-namespace CI/CDでプロダクト開発の環境を保全。 ブランチ運⽤はgit feature flow。機能リリースの先後を微細に管理。
  41. 41. 適者⽣存型アーキテクチャ アーキ clickupでカンバン開発 補⾜ 開発メンバーがそれぞれの状況によって分断しがち (リモートワーク、複業) 同期イベントを最⼩限にして(※1)、状態管理を強めに = カンバン (※1)同期イベントが少ない= プロダクトについての共通理解を 育みにくい。だからこそプロダク トレビューの位置づけが重要。 (※2)Clickupのスロット管理が バックログの構造化に適している confidential confidential (※2)
  42. 42. ともに考え、ともにつくる 重奏的仮説検証 ジャーニースタイル フォーメーション・パターン 適者⽣存型アーキテクチャ 仮説⽴案 プロセス チーム アーキ
  43. 43. 結論 「分からないものを分かるようにする」ために 選択の幅を保ちつつ、仮説検証によって絞っていく (リーン製品開発のセットベースがベース) 選択の幅を広げるために、チームの多様性を指向する (同時にプロダクトについての理解(基準)を仮説検証で合わせる) 多様な学びに最⼤限適応するために、プロダクトづくりの 機動性を⾼める (重奏的仮説検証、ジャーニースタイル、フォーメーションパターン、 適者⽣存型アーキテクチャ)
  44. 44. リーン・ジャーニー・スタイル ともに考え、ともにつくるプロダクト開発 正解の無い世界でそれでも前に進むために。 問いに向き合うジャーニーを続けよう。
  45. 45. 謝辞 ともに考え、ともにつくるにあたるチームメンバーへ Takahashi Toshiaki Numata Keisuke Okada Takumi Matsuda Yasuaki Kutsu Hirokazu
 Ogata Yuto Masuda Kyohei Abe Tadanori

×