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

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

4. https://ichitani.com/
Profile

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

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で
バックエンドはfirebaseで
つくる
例えばフロントのvue.jsは
残し、バックエンドを
firebaseからRDBやGraphQL
前提に移管する

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

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

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

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

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

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

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

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

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

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