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

0.9K Views

October 31, 19

スライド概要

EOF2019で発表した内容。

シェア

またはPlayer版

埋め込む »CMSなどでJSが使えない場合

関連スライド

各ページのテキスト
1.

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

2.

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

4.

Profile https://ichitani.com/

5.

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

6.

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

7.

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

8.

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

9.

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

10.

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

11.

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

12.

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

13.

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

14.

プロダクトオーナーの視座を プロダクトの上限(ボトルネック)にしない Toshihiro Ichitani All Rights Reserved. Photo credit: Steven Penton on VisualHunt / CC BY

15.

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

16.

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

17.

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

18.

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

19.

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

20.

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

21.

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

22.

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

23.

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

24.

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

25.

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

26.

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

27.

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

28.

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

29.

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

30.

雁⾏陣開発

31.

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

32.

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

33.

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

34.

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

35.

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

36.

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

37.

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

38.

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

39.

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

40.

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

41.

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

42.

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

43.

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

44.

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

45.

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

46.

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