# チーム・ジャーニー　（第2部）
# 第2部　僕らがプロダクトチームになるまで　-複数チームによるジャーニー-
## 登場人物
☆はカイゼン・ジャーニーに登場。追加登場人物も同様。
### ＜プロダクトチーム＞
太秦：主人公。プロダクトチーム全体のリーダーとなる。
#### ＜タスク管理機能（フォース）チーム＞
三条：チームリード。
鹿王院：プロダクトリード。
有栖：プロダクトオーナー。
常盤：チームメンバー。太秦とは昔のよしみがある。
嵯峨：チームメンバー。元リモートワークを行っていた。
壬生：チームメンバー。フリーランス。
#### ＜チャット機能（フィフス）チーム＞
御室：フィフスのリーダー。太秦の同期。
仁和：フィフスのサブリーダー。
音無：フィフスのプロダクトオーナー。
☆蔵屋敷：フィフス常駐のスクラムマスター。
#### ＜ドキュメント作成機能（シックス）チーム＞
宇多野：シックスのリーダー。太秦の同期。
鳴滝：シックスのプロダクトオーナー。
#### ＜ステアリングコミッティ＞
社：プロダクトチームのプロダクトマネージャー。
貴船：プロダクトチームのシニアプロダクトオーナー。

## 第9話　塹壕の中のプロダクトチーム
### ストーリー
社長号令で、3つのチームが一つのプロダクトチームを結成することになった。驚きと困惑の声が上がる中、太秦プロダクトリーダーを任される。
プロダクト全体のプロダクトマネージャーの社、3チームのプロダクトオーナーをまとめるシニアプロダクトオーナーの貴船と共に、エンジニアリング面で3チームの面倒を見ていくことになった。
当然ながら全員が困惑と不安に満ち溢れていた。各チーム自体は、それぞれのやり方で順調に回っている。にもかかわらず、それをまとめる術等知る由もなく、早々に道のりの険しさを味わうことになった。
### チームに情報が行き渡らない要因
* **経路設計の複雑性**
複数チーム化により、チームの中で行き渡される情報の経路が複雑になる。
* **解釈の多様性**
各チームメンバーの経験や知識の相違から、同じことを伝えても解釈にばらつきが生じてしまう。
### チーム価値を創出するために必要な情報
* **ユーザにとっての価値**
「ある状況」を変えるためのプロダクトが価値を持つ。
* **ビジネスにとっての価値**
事業の持続可能性が高いプロダクトが価値を持つ。
* **プロダクトにとっての価値**
プロダクト自体の持続可能性（変更可能性）が価値を左右する。
### 「情報」の種類
* **「原石」としての情報(What)**
そのままでは意味をなさない情報。背景や理由を仮説検証等で突き止め、ユーザやビジネスに必要な「知識」を得るために加工する必要がある。
* **「価値創出を促す」ための情報(Why, How)**
横断的なチームを動かすには、全チームが何を目指し、どういう優先度でどうやって作っていくかを共有する必要がある。
#### なめらかなプロダクトづくりを支援する情報
* **ミッション**：プロダクトチーム全体の達成したい目標。
* **戦略**：プロダクトチーム全体の戦略方針。
* **チーム・ミッション**：上記2つをもとに、各開発チームのミッションを立てる。
* **作戦**：チーム・ミッションを達成するための、ジャーニー単位での作戦。
### 情報設計とコンウェイの法則
プロダクトが大きくなると、1人では情報を受け止めきれなくなり、ボトルネックを生む。
そこで情報設計上の考慮すべき指針として、コンウェイの法則がある。「プロダクト設計は、組織のコミュニケーション構造を反映したものになる。」
人と人との協働には「取引コスト」が必要で、それを下げるために組織内外の境界を設けている。こうした取引コストが大きくならないようチーム内の活動を最適化した結果は、プロダクトに現れてくる。
#### 作戦の流通範囲の指針
作戦をどこからどこまで流すかはプロダクト次第だが、次の指針を押さえる必要がある。また、こうした境界の設計と同時に、**越境の働きかけ**も求められる。
* **全ての情報を全員で共同所有する。**
* **Why寄りの情報は広く（全体最適化）。How寄りの情報は狭く（個別最適化）。**
* **最前線のチームからの情報を全体に押し流す。**

## 第10話　チーム同士で向き合う
### 追加登場人物
#### ＜ドキュメント作成機能（シックス）チーム＞
☆七里：シックスのチームメンバー。カイゼン・ジャーニーでも登場。
### ストーリー
3チーム統合に向けたチーム同士の話し合いは進まず、互いに遠慮したり牽制したり。各チームが互いにチーム外の状況を意識しておらず、3回目のステアリングコミッティでも全く進捗が無かった。
そこで、まずはプロダクトチームを統括する社さんと貴船さんを含めてリーダー会を開き、共通運用するカンバンでタスクをトレースすることが決定した。リーダー会の成果は各チームに持ち帰りチームに共有し、また次のリーダー会で集まる際にチームの現況を報告してもらうことにした。また、リーダー経由のみでは流通経路が長くなりすぎるため、各チームのプロダクトオーナーとテクニカルリードにも、それぞれの役割同士で集まってもらうことにした。各役割別の話し合いの結果はリーダー会に持ち込まれる。こうしてチーム間の意思疎通を行う機会を設けた結果、次々と問題点が浮上してきた。すなわち、統合へ向けた一歩前進に成功したのだった。
### プロダクトオーナーと開発チームの数構成
プロダクトチームの中にいくつのプロダクトオーナーと開発チームがあるかによって、作戦が異なる。
* 1PO-1開発チーム　第1章で見てきた単一チームの開発チーム。
* 1PO-複数開発チーム　1POが複数の開発チームを担当する。POの経験と力量が左右する。
* 複数PO-複数開発チーム　複数の1PO-1開発チームが集まったもの。各開発チーム自体は部分最適化されているが、全体最適化には程遠いことが多い。情報共有のために、プロダクトオーナーの他に**プロダクトマネージャーを置き**、POの役割を分散する手法がある。
### 役割からの越境
リードは、ある状況で前進を先導する「役割」であり、柔軟に置き換えることが可能である。注力したいリードを定義し、適切な人材に任せる。リードがうまく働くためには、リードに必要なスキルの確保が必要である。スキルを上げるための投資や、外部からの専門家を招くなどしてスキルを高める必要がある。

### チームからの越境
チームから越境すべく、リーダー会をトップに、プロダクトオーナー会、リード会を通じて、各チームの状況をチーム横断的に把握していく。
但し、リーダー会は最高意思決定機関ではない。リーダー会の決定を一方的に伝達するのではなく、現場で得られた気づきや工夫及びその試行結果こそがプロダクトチーム全体に普及すべき内容である。
また、プロダクトチーム全体の動きを全員が眺められるよう、統一のカンバンを運用する。その際、各会にふさわしい粒度で話し合う必要がある。（トップのリーダー会に近づくほど粒度は荒く、各チームに近づくほど粒度を細かくして、認識を共有する必要がある。）
### コンポーネントチームとフィーチャーチーム
* コンポーネントチーム：リード役自体を別のチームとして切り出す。→仮説検証チームを別に置いて、その結果を開発チームに持ち込む。
* フィーチャーチーム：一つ一つのチームの独立性を高める。→仮説検証リード会によって文脈の共有が日常化し、結果に対する即応性が高まる。→相対的にコストが下げられる。
### アジャイル・ギルドモデル
フィーチャーチームを基本として、職能別に横断的なつながりを構成するマトリックス型組織。職能横断型なのが特徴で、各職能での意見交換は、専門性の維持向上に役立つ。

## 第11話　チームの間の境界を正す
### ストーリー
前話でのフィーチャーチーム化は効果を発揮し、チーム間の意見共有も活発化した。だがチーム内に目を向けると、他チームからの依頼が仕事の大部分を占めるようになっていた。チームの新規開発速度が落ち、メンバーも疲れ切っているようであった。また、依頼がチーム窓口を介さず個人に行く場合もあり、チーム全体での依頼管理が機能していなかった。太秦はすぐにチームメンバーを招集し対策を練る事に。
具体的には次の内容でまとまった。
* 開発班と運用班（他チーム依頼引き受け）分散案は却下。（メンバーへの不公平感が高まる恐れがあるため。）
* スプリント毎に他チームからの依頼を受け付ける**可変のバッファを設定**し、依頼量に応じて次のスプリントのバッファを調整する。
* **依頼の一次受付を担うメンバーを輪番制**とし、負荷分散を図る。輪番制は1スプリントにつき2人で回すことで、1人が依頼でパンクする事の無いように配慮する。
* 依頼一次受付は、自チームが作るタスク管理ツールで依頼専用スレッドを立ち上げ、タスクURLを送信してもらう。
* チームはコードをできる限り共同所有し、輪番制の効率を上げる。
* 開発タスクと比較した優先度については、チーム内でインセプションデッキを組んだうえでルールを策定する。
* 依頼側（他チーム）と引き受け側（自チーム）双方の優先度の要望を組んだうえで最終決定権を自チームに持たせる。
こうした向き合い方と判断基準を各チーム同士ですり合わせるべく、コミュニケーションを振り返る場を設けることにした。

### WIP制限と逆コンウェイの法則
チーム外から流れる情報量を制御し、チームで同時に処理を進めていける数にまで制限することを**WIP(Working In Process)制限**という。チームで取り掛かれるタスク量を決定しておき、状況に応じて数を増減させる。
また、チームが受け取れなかった情報は処理がなされず滞留し、在庫として膨れ上がる。こうなると整理のコストの増加や、依頼を頼んでも一向に進まない状態となってしまう。そこで、**逆コンウェイの法則**で、**できるだけチーム内で仕事が完結する**ようにチームを分割する。こうすることで、**他チームとの依存度割合を下げて、チーム単体の機能性を上げられる。**
### 境界へのチームの向き合い方
1. **リソース配分に意志を込める。**：何に時間を使うのかを予め決めておく。各チームのミッションとそれ以外の時間で**割合を決めておき、スプリントやジャーニー単位で割合を調節する。**
2. **番頭の輪番化**：他チームからの依頼処理番を固定してしまうと直接的なミッションへの貢献性が薄れてしまうため、**スプリントごとや曜日ごとに番頭を回していく。** タスクは一日で終わる分量が望ましい。また、特定の人物にしか状況が分からない **「トラックナンバー1」問題のリスクを避け、全員が対処できる状況を作る必要がある。** 但し、メンバーの属人性を排除するのではなく、何かが起きた時に別の人が対応できるようにすることが望ましい。
3. **順序付けの基準を合わせる。**：プロダクトチーム**全員が、依頼とミッションの順位付けの共通基準を持つ**ことで、効率的な両立が可能となる。
4. **チーム外部への表明**：**チームが依頼を受けられるスタンス等を外部に表明しておく**ことで、途中で追加の話し合いをすること無くやり取りできる。また、スタンスはチームごとに異なっても良い。
5. **チーム間の振り返り** ：チームメンバーで振り返りを行い、チーム間の問題やカイゼンについて議論する。
※1.~4.は単体のチームがとる工夫であり、この作戦では対処できない状況に直面することもある。したがって、そもそもの流量を下げる等といったプロダクトチーム全体での取り組みが必要である。

## 第12話　チームの境界を超えてチームを作る
### 追加登場人物
#### ＜横断チーム＞
☆万福寺：巨漢のプログラマー。通称和尚。
### ストーリー
3チームの統合作業は遅れており、特にフィフスチームの遅れが顕著であった。開発チームが不要な機能を多く作り顧客離れを招いていた。プロジェクト失敗の危機的状況下で、太秦は横断チームの結成を決意する。フォースチームから常盤と嵯峨をフィフスチームに兼任で送り込み、後は外部から賄うこととした。しかし、社が連れてきたのは新人に近いメンバーが数名で、効率は上がらず。逆にフィフスチームと横断チームでタスクを押し付けあい確執が生まれてしまった。
そこで、より顔の広い七里さんに助っ人獲得を依頼。横断チームの**常盤と嵯峨の二人は専任とし、フォースチームから独立させた。** 当然引き抜かれるフォースチームのベロシティは激減するが、統合しなければ各チームごとの開発も水の泡になるとの思いから、横断チームを統合作業へと集中させた。さらに七里さんが**強力な助っ人・万福寺（通称和尚）** を連れてきたことで一気に作業は加速した。最初のスプリントを終えた太秦は、フィードバックから即座にフォーメーションを変更。バックログを片付けるプロダクトリードに和尚と常盤を置き、嵯峨を抜け漏れ拾いやチーム連携を行うチームリードに回した。慣れないフィフスチームの環境への調和と開発支援は、フィフスチームのエース仁和が担当し、モブプログラミングを多用した。こうしてフィフスチームの課題は予定よりも早めに終了した。
太秦にチームの窮地を救われたリーダーの御室は、借りを返さんとばかりに、続くシックスチームの統合作業に仁和を送り込むことを了承した。フィフスチームのプロダクトオーナー代行を務めていた蔵屋敷は太秦に「チームとは何かをだいぶ知ったようだな」と評価の言葉を掛けたのだった。
### 横断チーム
横断チームは、フィーチャーチームで引き受けきれないタスクや、どのチームで開発するのか判然としないタスク等が山積する混乱を解消するためのチームである。
具体的には以下の型に分かれる。
* 専門特化型チーム：メンバーの専門スキルで固めたチーム。専門性の分散を防ぎ、まとまった成果を上げるためのチーム。
* 状況特化型チーム：プロジェクトの重要ミッション達成のための特化型チーム。ミッション達成までの期間限定で結成する。
一方で、こうした横断チームはフィーチャーチームとの確執を生みやすく、タスクの押し付け合いが発生しがちである。
また、既存チームと横断チームを兼任する場合、稼働バランスが難しく、思うように横断チームとして活躍できなくなる。
兼任か専任かはミッションに対する効率性の選択で決定する。（兼任…リソース効率上昇、専任…フローの効率上昇）
チームの士気を崩さないように、ミッションまでのジャーニー単位で作戦を見定める。

### 状況特化型チームの運用
* 既存チームが主管の場合：既存チームに状況特化型チームが入り込む形となる。バックログやゴールデンサークル、スクラムイベント等は既存チームと同じものを利用する。
* 状況特化型チームが主管の場合：チーム自体は独立して存在し、既存チームと連携して情報共有を行う。バックログ等はそれぞれのチームで別で持つ。
確執を生まないようにするため、どちらの場合でも、両チームでミッションに対する向き直りを行う。「我々はなぜここにいるのか？」を問い直し、高い視座から最適化を行う。
なお、専門特化型チームでは稼働余力が残ることがあるが、意味もなく予定を詰めて時間を浪費（パーキンソンの法則）しないよう、急な支援要請のために空けておく。

## 第13話　チームとチームをつなげる
### 追加登場人物
#### ＜その他チームに関わるメンバー＞
☆西方：蔵屋敷の代行として登場。カイゼン・ジャーニーでもスクラムマスターとして登場。
### ストーリー
3チームの統合ミッションを乗り越えた太秦達は、元の体制に戻った。だが、フォースはプロダクトバックログが大量に残り、フィフスやシックスのメンバー間の対立は続いたままであった。
そんな中行われたステアリングコミッティで、シックスが開発中のファイル管理機能を、フォースがこの1ヶ月で制作してしまっていたことが発覚した。フォースが作った目玉機能は完全に裏目に出て、機能を捨てることを命じられたほか、シックスのリーダー宇多野との亀裂はより深まった。
チームの目標(KPI)がバラバラで、どこを目標にしているのか、何を作っているのかが分からず、迷走していた。こうしたチームでは対象ユーザもバラバラ。**そこでチーム間で対象ユーザを統一するため、全チーム合同でユーザーストーリーマッピングを行い、目標を合わせていくことにした。** これを提案したのは、蔵屋敷の代行でやってきた西方であった。
### バラバラのユーザーを一人のユーザーにする
ユーザーに対する認識がチーム間で異なると迷走する。バラバラのユーザーを「一人のユーザー」にすることで、チームをまとめる求心力になる。
ユーザーストーリーマッピングを行うタイミングは、主に2パターンに分かれる。
* プロダクトがまだなく、ユーザーに関する共通理解をつくりたい時
* プロダクトがあり、ユーザー体験の最適化を進めたい時
以下がユーザーストーリーマッピングの順序となる。
1. 大まかな行動や状況を書き出す。
2. 状況に対応する行動を細かく出していく。
3. 行動に伴い発生する問題・不具合を書き出す。（プロダクトがある場合は、障害となる部分を書き出す。）
4. 問題や障害の解決策を挙げる。
5. 現状の行動フローから理想的な行動フローを書く。（プロダクトがまだない時のみ）
#### ユーザーストーリーマッピングのメリット
* 「自分たちがいかに想定ユーザーのことを知らないか」を知ることができる。
* チームは何をしなければならないか、課題が見えてくる。
### 課題とカンバン
**チームで追っていくべき課題は、カンバンで全チームが共有できるようにする。** また、各チームのアウトプットが横断的にまとまるには、**アウトプット統合のタイミングが定まっている必要がある。** 事前に**チームが目指す同期タイミング（マイルストーン）** を決定しておき、線表上で表しておくのが良い。
### チームの価値指標の計測
* **スループット**：ある一定の期間あたりに創出できた価値の数を表す。各チームごとに計測し、チーム全体でまとめて記録する。スループットが落ちると、問題が生じているチーム・箇所がすぐに分かるようになる。
* **価値創出までのリードタイム**：課題やアイデアの発見から、実際に形になりユーザーに届くまでの時間を表す。
* **価値の仮説検証**：届けようとしている価値自体は仮説にすぎないため、実際にユーザーにどう受け止められたのか、ユーザーに価値を持ってもらえているのかを検証する。この価値の検証がうまくいけば、プロダクトとして成功と言える。

## 第14話　クモからヒトデに移行するチーム
### 追加登場人物
＜テスト管理ツール開発チーム（ゼロチーム）＞
☆浜須賀：チームリーダー。カイゼン・ジャーニーでは新米だった。相変わらずコードの話になると別人になる。
☆万福寺：通称和尚。12話の助っ人は、ゼロチームから引き抜かれていた。
マイ日坂：明るい女性メンバー。
☆ウラット：プロダクトオーナー。タイ出身。
### ストーリー
テスト管理ツールを開発する通称ゼロチームが合流した。新メンバーが紹介される一方、社はプロダクトマネージャーを解かれ、貴船が兼務することになった。
以降、チーム運営が難しくなっていった。複数チームと話すプロダクトリーダー太秦への負担が重くなる一方、貴船は遅れているシックスチームのコンサルタントを外部に委託。レビューコードの質を担保し、申請的なドキュメントを書いて承諾されなければならなかった。貴船はこうしたやり方を他チームも行うよう要請した。しかし、そのまま他チームのプラクティスを取り入れても意味がない。困った太秦の前に蔵屋敷が現れた。
蔵屋敷は貴船が要望していたプロセスの標準化を中止し、**QAに専門特化した横断チームの結成**を行った。また、太秦をプロダクトリーダーから降ろして、QAチームで話し合う形に変更した。**中央集権型（クモ型）から、分散協調型（ヒトデ型）へと転換した。** また、貴船はプロダクトマネージャーを解かれ、社長がつとめることになった。
### 詳細と俯瞰を行き来する
現場目線と組織目線、それぞれに寄りすぎてしまうと、意思決定を誤りかねない。そこで、現場の人間は組織目線から俯瞰してみる、組織の人間は現場目線から詳細を見つめるようにした方が良い。現場と組織の中間的立ち位置で行き来を繰り返すメンバーを「マネジメントリード」と呼ぶ。
#### マネジメントリードの働き方
1. 自分のやるべきタスクを片付ける。
2. チームの目の前からやらなければならないタスクを片付ける。
この順番に行うのが大切。
### 意思決定を立体の中で泳がせる
意思決定は、前提に対する複数の選択肢から一つを決定するもので、 **前提の前提、そのさらに前提を考慮したうえで意思決定を行うとより深まる。** また、**時間軸を加えて、過去や未来を見据えた上で判断を行う**と、正しい判断を行いやすい。
### 先導者はやがて「自分」を手放す
初期のころは、リーダーによる中央集権的なクモ型組織によってチームが引っ張られていく。しかし、**リード役がある＝逆にリード以上の速度では進めない。** そのため、各チームが自律的に動けるようになったあとは、**全体のリーダーではなく各チームリーダーによる合意と意思決定がトップとなる。** こうした分散協調のヒトデ型組織になれば、各チームがそれぞれのスピードで動けるようになる。
### 大切なのは「ともにつくる」
標準化はチームを崩壊させる原因となり、個別化は共通理解に乏しい。そこで、**プロダクトをともにつくる協同化の試みが大切である。**
まずは働く場所や時間をともにして、そこからモブワーク等の共に仕事をするところまでもっていく。共に教えあうことで、自分の理解がより深まり、成長できる。
## 第15話　ミッションを「越境する」チーム
### 追加登場人物
**＜社長＞**
☆江島：カイゼン・ジャーニーの主人公。今回は社長として太秦達に接する。
### ストーリー
プロダクトマネージャーになった社長の江島は、次々とプロダクトバックログを突っぱねていった。社長はこれまで見たいな状況が続いたらプロダクトチームを解散すると言い出し、スプリントを一度止めてプロダクトバックログの見直しを求めた。
そこから苦闘がはじまった。開発チーム主体でプロダクトバックログを見直すもダメで、続いてチーム全体で作戦を立てるも通らず。社長から提示されたプロダクトバックログをフォースチームがこなすと、チームごとのアウトプット差が明確になりお叱りを受ける。チーム自体がジャーニースタイルを見失い迷走していった。
落ち込む太秦に社長が声をかける。**「君の持ち場はどこにあるのか。」「私たちは同じものを見ることができているのか。」「私にもどうするべきか正解があるわけではない。自分たちで分からないことを分かるために何ができるかだ。」**
太秦は社長のありもしない「正解」を当てに行っていることに気づき、問われた問いにこたえるべく、最大の難関を超えていく決意をするのであった。
### 自分たちの視座と視野を自在にする
正しいものを正しくつくる 第6章 にまとめた内容から拝借。

#### 視座を動かす
視座＝目的にあたる。つまり **「どういう目的に立って対象を見るか」** である。
現状で手元にあるのは、ジャーニーの目的である。だが、この視座のみで意思決定を行なってしまうと、他の視点が置き去りになってしまう。

こうした時は、「**プロダクト上の視座**」に目線を動かすことが大切である。それは、「**事業の目的**」に目を向けることである。
目的への立ち返りは、基準を見失った時に戻ってくる手立てでもある。ピボットするかどうか悩んだ場合でも、「事業の目的」という基準に戻ってくることで、それに応じた判断が可能となる。
事業の目的では判断が難しいときは、さらに遡って「組織の目的」に目を向ける。組織の理念・組織の目的に合った道を選ぶ。
* 社会
* ↑に貢献：組織
* ↑に貢献：事業
* ↑に必要：プロダクト
* ↑に必要：ジャーニー

#### 視野の広狭
視野＝範囲にあたる。「**ある視座に立ったときに、何を見るのか**」である。
**誰を対象とするのか**を決定するのが視野である。
* ユーザー：ユーザーから関係者は広がっていく。彼らの思惑や課題を捉えなければならない。また、事業によっては想定ユーザーが複数にのぼる場合もある。
* 顧客：ユーザーの課題を捉えていても、構想が顧客の方向性と合致していなければ意味がない。
* 運用：安定して滞りのないサービス提供が必要である。
* 作り手・自分自身：自分自身の振る舞いをどう変えるか。

#### 視座と視野を変えることでできること
視座と視野を変えて、事業の狙いから捉え直すことで、全く新しい課題仮説や状況仮説を生み出すことができる。出発地点では得られなかったり想定できなかったものになる。
また、プロダクトオーナーと開発チームの対立も、視座を変えてみることで可視範囲の面積が広まり、意思決定の新たな出発点を生み出すことができる。
**視座や視野が変われば見えるものも変わる。**
また、こうした視座・視野の偏りを作らず、自分たちの意思で行き来できるのが理想である。但し、それは非常に難しい。
* 役割による固定化：役割分担に最適化しすぎてしまい、視座や視野の転換が難しくなる。→プロダクトオーナーの民主化（第1話を参照）
* 現状の最適化：仕事の質を上げるためには当然現状を最適化をせねばならないが、そうであるが故に、視座や視野の転換は難しい。
#### 視座・視野転換のための考え方
* **多次元からの捉え**：視座・視野の考え方以外にも、目的・手段、長期・短期、俯瞰・詳細、感性・理性、他者・自者等の**相反する観点を行き来し、多次元から考える**ことで、方針がハッキリとする。また、これらの観点には**個人差があるため、チームで臨むことで多様性を武器にできる。**
* **自分たちに問う**：「我々はなぜここにいるのか」等の自分に向き合って問い直す時間も非常に大切である。**問に向かうことで、自分たちが気づいていないことに気づける可能性があるためである。** また、「正しいものを正しくつくれているか」等の、**答えのない問いに向き合い続ける**ことも必要である。

## 第16話　ともに考え、ともに作るチーム
### ストーリー
社長室から戻ってきた太秦は、みんなをまた疲弊の淵に追い込んでしまうのではと心配した。しかし、チームメンバーは頼もしかった。メンバーのポジティブな言動に太秦は救われた。さらに御室と宇多野も加わって、最後のジャーニーへと進んでいくのだった。
最後のジャーニーは、ユーザーを巻き込んだ検証（仮説検証）でユーザーの意見を取り込み、さらにこれまで関わってきたチームの知見や発想も織り込みつつ、プロダクトの在り方自体を変えるものであった。
太秦は、自チームや他チームのメンバー、さらにチーム外の利用者にまで知見を広げることで、一人の限界を超えられた。支えてくれたメンバーへの感謝の気持ちと共に、「ともに考え、ともにつくる」境地に至ったのだった。
### 仮説検証
正しいものを正しくつくる　第5章②を参照
#### 現実歪曲曲線の上を行け
仮説検証は、いかに時間的、費用的リソースをかけずにリアリティのある反応を得られるかにかかっている。
現実歪曲曲線は、リソースが拡大するほどリアリティが高まっていく、歪曲した曲線である。この曲線より上の部分で検証すると効果が高い。
#### 多様性重視の重層型仮説検証
仮説検証をまずジャーニーに分け、ジャーニーごとに重視する検証を変え、検証活動の濃淡をつける。多様な視点で検証が可能となる。
そのためには、まずは仮説を外在化（見える化）して、チームメンバーで共有する必要がある。課題仮説（本質を捉える）、機能仮説（実体を捉える）、UI仮説（形態を捉える）の3つの仮説の理解をそろえた上で、仮説検証にあたる。検証の結果、再び個々人で仮説が浮かんでくる。これを先ほど外在化した仮説にぶつけていくことで、1人では形作れない仮説構造にしていくことを仮説構造の重層化という。
### ともに考え、ともにつくる
ジャーニーの先には「目的地」があるが、最終ゴールではなく、そこに至った時には通過点となっている。
チームジャーニーは困難が伴うが、越境はたった一人からでも始められる。

###### tags: `読書`