# 正しいものを正しくつくる　第4章
## 第4章　アジャイル開発は2度失敗する　間違ったものを正しくつくる
### 第一の壁 アジャイル開発への移行に伴う数々の問題
反復的に開発する際の全ての箇所で課題を見つけることになる。
* 顕在的な問題
* バックログの深掘りが甘く、スプリントの成果がなかった。
* スクラムイベントに時間がかかりすぎる。
* レビューでコードがまともに動作しない。
* 潜在的な問題
* レトロスペクティブが実施できておらず、内省やチームとしての成長が乏しい。
* その他、うまくいっているようで、問題が発生している場合。

### 第一の壁を越える
* 小さく失敗することを繰り返し、少しずつカイゼンしていく。
* 朝会の「問題なし」が続くのはむしろ問題。チーム自身で制御不可能にならない程度に自己管理できる。
* アジャイル経験者を外部から招集する。

### 第二の壁　開発チームとプロダクトオーナーの見えない壁
プロダクトを作り終えた後、ユーザーに価値を届けようとして、思うような成果が上がらないことがある。
早ければ四半期も立たないうちに見切りがつけられることもある。
どれだけ余白の戦略をとって、バックログを細かく区切っていても、失敗するときは失敗する。
チームはやれるだけのことはやり、理想的なプロダクト作りが行えたはずだ・・・と思い込み、ミッションの境界線を勝手に引いてしまうと、延々と間違ったものを正しくつくる事になる。これらのミッションの境界線は、プロダクトオーナーと開発チームの間に引かれ、見えない壁を形成する。

### プロダクトオーナーの果たすべき役割
#### 「なぜこのプロダクトを作るのか」
Whyで始まるアジャイル開発の原点に立ち返り、新たな世界観の共通理解：ビジョンを形成する。
これが実現できなければ自分たちの存在意義が問われるのがミッションである。ビジョンを実現するまで繰り返し見定め・コミットする。
プロジェクトはミッション単位のタイムボックスで、資源の制約の中でチームの集中力を集め、ビジョンに近づくに連れてプロダクトは理想に近づく。
ミッションとは、「到着を重ねた時にビジョンにたどり着ける」ことを指す。スプリントゴール程は細かすぎないレベルであり、この構成にプロダクトオーナーの存在は欠かせない。
誰のどんな問題をどうやって解決するかをシンプルにまとめたもの、これがコンセプトとなる。ビジョン実現のためのアイデアのことである。要点を簡潔にまとめることが肝要で、トレーニング例としては「エレベーターピッチ」がある。

階層構造上から
* コンセプト
* ビジョン
* ミッション
* スプリントゴール
* プロダクトバックログアイテム

#### 「プロダクトの世界観を実現するために何を備えるのか」
* プロダクトが答えるべき要求（プロダクトバックログ）とは何か。
→ 要求の言語化・整理
* ユーザに届けて、使えるようにするには、インターフェースとしてどうあるべきか。
→ UIの方針決め
* プロダクト作りとその提供を持続可能にするために、どのようなビジネスモデルを描くか。
→ ビジネスモデルの設計

#### プロダクトを形にするために必要な運用スキルと知識
* ソフトウェア開発に関する基本的知識
* プロダクトバックログの管理手法
* 受け入れテストの実施と結果の活用
* ユーザーテストによるフィードバック取得と継続的な計画
* プロジェクトマネジメント
* コミュニケーション設計

### プロダクトオーナーの役割を補完する
以上に挙げた通り、プロダクトオーナーの役割は多岐にわたる。あらゆる能力の実戦経験を持つ人はあまりいないので、プロダクトオーナーに求められる機能を、チームで保管する必要がある。
具体的には
* ユーザー体験の分野に対し、デザイナーの支援を得る。
* ビジネスモデルの設計や計画立案などに対し、プロダクトマネージャーの支援を得る。

### チームとプロダクトオーナー間に横たわる2つの境界
プロダクトオーナーに求められる役割の特異性が見えない壁を作り出してしまう。
#### 「作る」と「作らない」の境界
開発チームは文字通りソフトウェアを「作る」ための組織である。一方でプロダクトオーナーはソフトウェアを「作らない」ことが多い。
* 境を深める背景１　エンジニアリングへの知識の度合いが小さい。モノづくりの基本的な制約が理解できないと、期待度にズレが生じてしまう。
* 境を深める背景２　スクラム理解への度合いが小さい。　スクラムというフレームワークの理解が足りなければ、お互いの振る舞いが噛み合わなくなる。経験がないのに立ち位置上突然プロダクトオーナーを任されてしまうと、齟齬が生じやすい。

→共通理解を育むアクティビティ（インセプションデッキ、ユーザーストーリーマッピング、バックログの受け入れ条件の設定、受け入れテストの実施）

#### アウトプットとアウトカムの境界
開発チームは「アウトプット（出力結果）」を生み出す。スクラムにおける改善の中で、アウトプットの効率を高めていく。一方、プロダクトオーナーが求めているのは「アウトカム（成果）」である。ユーザーに価値を感じてもらい、有用であると判断されるようにベストを尽くす。
アウトプットを生み出すことは、アウトカムに繋がるとは限らない。間違ったものをいくら正しく作ったところで、アウトカムにはならない。
「正しさ」には明確な答えがない。置かれている状況を把握し、最も分が良さそうな選択をすることしかできない。
→仮説検証　仮説は答えではなく、実体としては問いである。仮説検証を繰り返し、正確度を高めていく。→リーンスタートアップ

### 越境へ　越境は混沌を呼ぶ
* プロダクトオーナーは万能ではない。開発チーム側がプロダクトオーナー側に一歩踏み出さねばならない。
* アウトプットとアウトカムを分けるのではなく、共通のミッションである「実現したいことを形にする」ことを共有しなければならない。
こうした「越境」は、新たな混沌を呼び寄せる。混沌を防ぎ、効率的に動いていくためには、行動指針や意思決定のための「基準」が必要である。
基準＝プロダクトとして何が正しいのかという見立て。　基準作りとそのアップデートの活動を「仮説検証」と呼ぶ。

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