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