Se ha denunciado esta presentación.
Utilizamos tu perfil de LinkedIn y tus datos de actividad para personalizar los anuncios y mostrarte publicidad más relevante. Puedes cambiar tus preferencias de publicidad en cualquier momento.

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

EOF2019で発表した内容。

  • Inicia sesión para ver los comentarios

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

  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

×