# 正しいものを正しくつくる　第6章
## 第6章　ともにつくる　正しいものを正しくつくる
### 正しいものを正しくつくる　
検証は、プロダクトが成長する限り続いていく。
プロダクト作りは時間とコストがかかる。作らなくても行える検証はし尽くしてから、新たにプロダクトを作り出す。

仮説検証から体験可能なプロダクトづくりへの移行時に必要な3つの観点がある。
### プロダクトバックログの詳細化の段階設計
検証時点でのプロダクトバックログを、開発で使える粒度まで細分化する。粒度の段階として3段階ある。
#### 第一段階：機能仮説の段階
一番粗い粒度の仮説である。この段階での予算見立ての精度は粗くなるものの、当たりをつけるためには行うべきである。
具体的には、過去開発したプロジェクトでテーマ分類が同じまたは類似したものと比べて、相対的にどのくらいになるかを見積もる。
#### 第二段階：MVPを特定する段階
ユーザーストーリーマッピングを応用し、機能仮説からユーザーストーリー形式へと変換する。
規模を見立てることは、経験が不足していると難しいが、チーム内に**プロダクトオーナー代行**を設置する手もある。チームとのコミュニケーションに時間が取れない場合などに、主にエンジニアリング面の補完を行う。
一部プロダクトオーナーの権限を開発側が持つことで、煩雑な承認手続きが不要となる。一方で、代行の見立ての精度が甘いと、手戻りに繋がりかねない。**プロダクトオーナーと同じ基準に立つ必要がある。**
プロダクトオーナー代行設置の理由として、チームが分散し、リモートワークで開発するメンバーや、副業のような形態で関わるメンバーが増えてきたためである。
また、プロダクトオーナー代行には、仮説キャンバスレベルの意思決定を単独で決定すべきではない。
代行のような存在は、「プロダクトオーナーは一個人である」というスクラムの原則にそぐわない。だが、仮説検証による学びの共有ができれば、この原則は突破できる。

#### 第三段階：スプリント開発前夜（スプリントプランニングの段階）
第3章を参照。この範囲でタイムボックスに収まるか？

### 仮説検証の精度と頻度の戦略
仮説検証の精度と頻度は、仮説検証型アジャイル開発の「ジャーニー」の行方を決める要素となる。
関係者を納得させるためには、ジャーニーの度合いを可視化していく必要がある。
#### 頻度
プロダクトの構想がまだ固まっていない段階では、精度よりも頻度を重視する。最も早い検証は、作らないことである。ポイントベースの作り方に対して仮説検証型は格段に時間がかかるので、短時間でできるだけ多くの検証を行うことが必要である。
#### 精度
一通り最初の検証を終えたら、頻度よりも精度を重視する。作り込みが無駄にならないよう、ビジュアルイメージで伝える資料等から始めていき、段階的にプロトタイプを充実させていく。これを繰り返すことで、最も精密なプロトタイプ＝プロダクトとなる。

### わかったことを正しく作る
仮説検証型アジャイル開発の活動の中心にあるのは、「わからないものをわかるようにする。わかったものを形にする」ことである。そのわかったことを正しく作るようにする。
#### 「わかることを増やす＝正解にたどり着く」とは限らない
目標がわかりやすくなると、活動が本質から切り離され、作業になってしまいやすい。
また、人はわからないものよりも無意識的にわかりやすいものを選んでしまうため、わかりやすいものが正解とは限らない。
**事実と希望は区別する。**
#### 同調圧力・確証バイアスと戦う
わからないものをわからないままにする人は少なく、手短な解釈で分かったことにしてしまう多数派の意見に飲まれてしまう。チームではこうした同調圧力が起こりやすい。
**→論理の判断を求める。**
また、実現可能性が極めてまれであっても、自分たちが信じたい仮説を信じて疑わず、支持する情報のみを集めて反証を行わない。こうした確証バイアスも起こりやすい。
**→判断を急がず、一度保留して間を置く。**
#### あえてわからないものを増やす
わからないことに価値がない訳ではない。わかるものを並べて行き詰まったら、**あえてわからないものを増やしてみる。**
**守破離の「破」** にあたる。可能性を広げるためには、わからないものに手を伸ばさなければならない。
そしてこの際に、またしても乗り越えるべき壁が存在する。

### 視座・視野を越境する
これまで見てきた越境は、(1)プロダクトづくりの越境、(2)開発チームとプロダクトオーナーの越境の2つだった。
ここに3つ目の越境を加える。
#### 現状の理解から離れて、新たな理解の獲得へ進む
あえてわからないものを増やし、不確実性を上げる行為となるため、強い意志が必要となる。
より高いアジリティでの実験と、そこから得られる学習への適応が求められる。
これまで得た実践知を生かし、本質を変えずに中身を変えていく。自ら手段を作り出していく。
**3つ目の「越境」は自分たちの認識を変えることであり、視座と視野の位置・範囲を動かすことである。**

### 視座を動かす
視座＝目的にあたる。つまり **「どういう目的に立って対象を見るか」** である。
現状で手元にあるのは、プロジェクト（検証）の目的である。だが、この視座のみで意思決定を行なってしまうと、作業を終わらせる事が目的となってしまいがちである。
ビジネスのことばかり考えて、肝心なユーザー視点が置き去りになってしまうこともある。
課題仮説が意味をなさなかったり、最初の仮説にこだわってしまったり、それぞれの観点から理想を描いて行き詰まることもあり得る。

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

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

### 視座と視野を変えることでできること
視座と視野を変えて、事業の狙いから捉え直すことで、全く新しい課題仮説や状況仮説を生み出すことができる。出発地点では得られなかったり想定できなかったものになる。
また、プロダクトオーナーと開発チームの対立も、視座を変えてみることで可視範囲の面積が広まり、意思決定の新たな出発点を生み出すことができる。
どんなに素晴らしいプロダクトであっても、事業の側面から見て大幅に目標とかけ離れている場合、視座を事業の視点に合わせて気付かせて、納得を得られる。

**同じ視点で見ていても、視座が変われば見えるものも変わる。**

### 視座と視野に動きをもたらすフレーム
視座を動かすと一口に言っても、容易いことではない。視座は普通の役割に基づいて固定されやすい。
#### 視座が固定されてしまう場合
* 上位の視座での経験がなく、想像できない。→上位の立ち位置にある人と会話して、考えに触れる。何を優先基準として判断するか、その見立てを学ぶ。
* 経験にかかわらず、目の前のことに集中してしまう。クオリティを上げるためには当然集中せねばならないが、そうであるが故に、視座の転換は難しい。
#### 視座・視野転換のフレーム
難しい視座・視野の転換には、予め取りうる範囲の視座・視野の動き方を用意しておき、それを対象に当てはめる。
**＜越境のためのコマンド＞**
視座↑　1段階上げる
視座↑↑　さらに上げる（俯瞰）
視座↓　1段階下げる
視野↓↓　さらに下げる（詳細）
視野← 自分よりの関係者をひと回り大きく捉える
視野→ 相手よりの関係者をひと回り大きく捉える
視野←← 自分よりの関係者をさらに大きく捉える
視野→→ 相手よりの関係者をさらに大きく捉える
過去　過去から捉える
未来　時間軸を伸ばす

### 越境ができると、1人では手に負えなくなる
視座・視野をただただ広めればいいというものではない。
むしろ、**適切な視座・視野にチェンジし、場面ごとに適切な物差しで測れることが大切である。**
これが素早くできるようになれば、ボトルネックも解消する。
しかし、視座・視野を広げると、課題仮説や状況仮説がずれ、不確実性に再びさらされる。これらを解決するためには、とても一人では手に負えないことが多い。
改めてチームの存在が問われることになる。

### チームとともに作る
視座・視野を越境した状況で頼りになるのは、**チームの持つ多様性**である。
**多様性は、不確実性を高める一方で、その不確実性に適応する術でもある。**
不確実性に多様性を持って適応するチームが、様々な境界に分断されず「**共創する**」ことを支えるのは、**個々人の「越境」という価値観**である。

### 与えられた言葉だけで作る開発から、イメージと言葉で作る開発へ
「越境チーム」は、プロダクトオーナーが一人で仮説検証を背負い、その結果をチームに伝えるやり方から、**チームで見て、考え、作るという「ともに作る」やり方**へと変わる。
解釈の多様性は、仮説の多様性をもたらす。また、**他者の発見から学びを得る場・学び方自体を得る場**に変わる。
これまで言語のみに頼っていた開発では、プロダクトオーナー等に依存していると、その個人の想定を超えるプロダクトの製作は難しくなる。
こうした状況を脱却するため、**利用の現場にチームで出て、イメージを作り手に宿す。すべてを言語化するのではなく、発想の余地をあえて残す。**
プロダクトの振る舞いを最後に決定するのは作り手である。
作り手のアイデアも尊重した上で、お互いにイメージを共有しておく。

この方向性でプロダクト作りが進むと、 **開発と利用の現場の距離感はぐっと縮まる。** 現場でコードを書いて、現場で試したり、利用者の反応を見てその場で新たな仮説を試したりと、従来よりも遥かに機動的なプロダクト作りが可能となる。また、**距離が近いほど、実際のユーザーを巻き込むことになる。** 何度も足を運ぶと関係性は深まるし、ユーザーの協力が得られることもある。

### 一人の人間のようなチームへ
越境チームは、**だんだんと一人の人間のような状態**に近く。越境チームはあらゆる人間の機能を、チームで担う。
人間は自然に動きや感情が出る。同じように、**チームもそれぞれの活動を滑らかに繋ぎ、滞りなく実施し、チームも感情に向き合うことができるのがベストである。**

### ともに作る
いくらチームでも、あらゆる不確実性に対処できるわけではない。そのためには、**チームを超えた多様性の確保が必要である。**
チームの外側にまず置くべきは組織である。これまでの美談を持ち出す「これまでバイアス」に縛られず、目的のために動ける組織へと、越境する者への拡大へと話を広げる。
そして、同じ志を持つ組織外の**コミュニティ**という存在がある。彼らが多様性を担う時代に少しずつシフトしつつある。
**組織かどうかではなく、人と人との関係に向き合う必要がある。**
#### 取引の関係と共創の関係
* **取引の関係**　
約束された役務を果たすことで対価を得る関係。お互いに信用が問われる。相手が約束を守ってくれるかが問われる。
* **共創の関係**
貢献したい思いと、それに対する感謝がつなぐ、**相互信頼の関係である。主観的にお互いが安心できる関係性**と言える。越境チームには、こうした関係を目指すことで、人に価値を届けられるのではないかという期待がある。

**問いと向き合い続ける共創によるプロダクト作り**が、より普通のプロダクト開発となっていくはずだ。

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