---
title: ともに考え、ともにつくる 〜リーン・ジャーニー・スタイル〜
tags: 
author: [市谷聡啓](https://www.docswell.com/user/papanda)
site: [Docswell](https://www.docswell.com/)
thumbnail: https://bcdn.docswell.com/page/GYE941KZ73.jpg?width=480
description: EOF2019で発表した内容。
published: October 31, 19
canonical: https://www.docswell.com/s/papanda/ZL3G35-ss-188798246
---
# Page. 1

![Page Image](https://bcdn.docswell.com/page/GYE941KZ73.jpg)

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


# Page. 2

![Page Image](https://bcdn.docswell.com/page/5GE8Q42Y7D.jpg)

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


# Page. 3

![Page Image](https://bcdn.docswell.com/page/MLELX629ER.jpg)



# Page. 4

![Page Image](https://bcdn.docswell.com/page/54JML58V7W.jpg)

Profile
https://ichitani.com/


# Page. 5

![Page Image](https://bcdn.docswell.com/page/ZPJRK35W79.jpg)

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


# Page. 6

![Page Image](https://bcdn.docswell.com/page/NPEXL4KVEX.jpg)

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


# Page. 7

![Page Image](https://bcdn.docswell.com/page/63EKLZ557D.jpg)

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


# Page. 8

![Page Image](https://bcdn.docswell.com/page/4L733DK175.jpg)

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


# Page. 9

![Page Image](https://bcdn.docswell.com/page/V87D4P3KEG.jpg)

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


# Page. 10

![Page Image](https://bcdn.docswell.com/page/4VJPMN43J8.jpg)

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


# Page. 11

![Page Image](https://bcdn.docswell.com/page/L2EV9KXN7Q.jpg)

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


# Page. 12

![Page Image](https://bcdn.docswell.com/page/Z57GZQV5JL.jpg)

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


# Page. 13

![Page Image](https://bcdn.docswell.com/page/V4EQLK6L7P.jpg)

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


# Page. 14

![Page Image](https://bcdn.docswell.com/page/DKJ4DP45E1.jpg)

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


# Page. 15

![Page Image](https://bcdn.docswell.com/page/PLE1Z942JG.jpg)

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


# Page. 16

![Page Image](https://bcdn.docswell.com/page/8GEW9QX2E2.jpg)

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


# Page. 17

![Page Image](https://bcdn.docswell.com/page/W47Z9W6473.jpg)

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


# Page. 18

![Page Image](https://bcdn.docswell.com/page/KYJ6KG2GJV.jpg)

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


# Page. 19

![Page Image](https://bcdn.docswell.com/page/5GJ5PV2XJ4.jpg)

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


# Page. 20

![Page Image](https://bcdn.docswell.com/page/4LE33DK4E5.jpg)

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


# Page. 21

![Page Image](https://bcdn.docswell.com/page/V8ED4P35JG.jpg)

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


# Page. 22

![Page Image](https://bcdn.docswell.com/page/4V7PMN4D78.jpg)

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


# Page. 23

![Page Image](https://bcdn.docswell.com/page/L2JV9KXGEQ.jpg)

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


# Page. 24

![Page Image](https://bcdn.docswell.com/page/Z5EGZQRD7L.jpg)

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


# Page. 25

![Page Image](https://bcdn.docswell.com/page/V4JQLKVXEP.jpg)

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


# Page. 26

![Page Image](https://bcdn.docswell.com/page/DK74DPM2J1.jpg)

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


# Page. 27

![Page Image](https://bcdn.docswell.com/page/PLJ1Z98K7G.jpg)

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


# Page. 28

![Page Image](https://bcdn.docswell.com/page/8GJW9QZPJ2.jpg)

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


# Page. 29

![Page Image](https://bcdn.docswell.com/page/W4EZ9W16E3.jpg)

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


# Page. 30

![Page Image](https://bcdn.docswell.com/page/KY76KGLL7V.jpg)

雁⾏陣開発


# Page. 31

![Page Image](https://bcdn.docswell.com/page/5G75PV1M74.jpg)

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


# Page. 32

![Page Image](https://bcdn.docswell.com/page/V9J2631RER.jpg)

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


# Page. 33

![Page Image](https://bcdn.docswell.com/page/5DEY91Z57M.jpg)

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


# Page. 34

![Page Image](https://bcdn.docswell.com/page/2VJNL234E8.jpg)

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


# Page. 35

![Page Image](https://bcdn.docswell.com/page/GYE9419473.jpg)

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


# Page. 36

![Page Image](https://bcdn.docswell.com/page/5GE8Q49V7D.jpg)

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


# Page. 37

![Page Image](https://bcdn.docswell.com/page/MLELX6WRER.jpg)

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


# Page. 38

![Page Image](https://bcdn.docswell.com/page/54JML59P7W.jpg)

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


# Page. 39

![Page Image](https://bcdn.docswell.com/page/ZPJRK3GY79.jpg)

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


# Page. 40

![Page Image](https://bcdn.docswell.com/page/NPEXL4X4EX.jpg)

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


# Page. 41

![Page Image](https://bcdn.docswell.com/page/63EKLZWP7D.jpg)

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


# Page. 42

![Page Image](https://bcdn.docswell.com/page/4L733D1475.jpg)

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


# Page. 43

![Page Image](https://bcdn.docswell.com/page/V87D4PX5EG.jpg)

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


# Page. 44

![Page Image](https://bcdn.docswell.com/page/4VJPMNPDJ8.jpg)

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


# Page. 45

![Page Image](https://bcdn.docswell.com/page/L2EV9K2G7Q.jpg)

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


# Page. 46

![Page Image](https://bcdn.docswell.com/page/Z57GZQLDJL.jpg)

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