# 正しいものを正しくつくる 第3章
## 第3章　不確実性への適応　正しくつくる
### アジャイル開発における不確実性についての課題
#### 合意形成の課題：暗黙的な期待を放置したままでは合意形成にならない。
4つの期待：QCDS(品質、コスト、ローンチタイミング、機能の範囲（スコープ）)
ソフトウェアの6つの品質基準（機能性、信頼性、使用性、効率性、保守性、移植性）
4つの期待+デザインと学習についての期待が加わる。
* デザインの期待：ビジュアルに対する期待。見た目の問題は**主観の影響が大きい**ため、すり合わせが必要になる。
* 学習の期待：プロダクトづくりのやり方そのものを試したいという期待。
##### 暗黙的な期待とは？
期待が十分に表明されておらず、暗黙的になっている部分である。**能動的に働きかけて確かめる必要がある。**
プロダクトづくりに関わる当事者が自分の期待を自覚している場合は**対話による言語化**を行う。
一方で、していない場合は潜在的な期待となるため、**見える化のためのワークショップ（インセプションデッキ等）** を行う必要がある。
逆に期待は表明されているが、自分の期待を自覚していない場合もあるため、問い直しや確認も必要である。

このような期待の存在を捉えて共通認識としていくことを「**期待マネジメント**」と呼ぶ。
リスクマネジメントと共に、**状況に応じて適切なマネジメント**をとらなければならない。

#### 学びから生まれる課題：不確実性への対処から得られる学びが新たな不確実性を生む。
価値検証等で得たフィードバック（学び）を経て、それに対処するためには、新しい不確実性と向き合わねばならない。
基本的には、機能に対する期待と、時間に関する期待はトレードオフの関係にあるが、現実にはトレードオフが成り立たない場合もある。
さらに、**学びが進むと期待も明確になってくる。** その期待を最初から理解するのは難しく、後になって期待外れという事例も起こりうる。
**時間と機能の期待は、トレードオフの関係には無いと考えた方が良い。**

### 期待マネジメントを達成するための戦術
#### 共通の軸を持つ
まずはチーム全体で、目指すべき目標である「ミッション」を共有する。
こうした、チームが自律的に動けるようなミッション駆動の在り方を「ミッションコマンド」という。
#### インセプションデッキ
10個のアジェンダに対しチームでまとめていき、**潜在的な期待を見える化する。**
＜Why部分＞
* 我々はなぜここにいるのか：このチームで仕事をする意義を問う。最もシンプルで最も重要な問い。→ミッション　複数ある場合は最重要のものを。
* エレベーターピッチ：このプロジェクトを30秒で説明せよ。エレベーターに乗っている間に上司に説明できるよう、要点やメリットを端的にまとめる。
* やらないことリスト：開発における実施事項、実施しない事項、あとで決める事項を明確にする。これらをはっきりさせることで、無駄を省ける。
* パッケージデザイン：ユーザーから見たプロダクトの価値をはっきりさせる。
* 「ご近所さん」を探せ：クライアント、上司、協力会社etc…　プロジェクトに関わる人間を洗い出す。
＜How部分＞
* 夜も眠れない問題：プロジェクトにおける不安点やリスクを洗い出す。
* 技術的な解決策：採用する技術やアーキテクチャを決定する。また、関係者が概要をつかむために言語化する。期待のすれ違いが起こらないようにする。
* トレードオフ・スライダー：予算・時間・品質・スコープ等の優先順位を確定させる。横並びにならないよう、順位を
* 期間を見極める：開発期間がどれだけ必要かを見積もる。
* 何がどれだけ必要か：人材・期間・コストなど、必要なリソースをまとめる。
#### いつ期待マネジメントを行うか
早ければ早いほど良い。特にコアメンバーの意思は根幹となる。
また、変化に対応できるよう、インセプションデッキの見直しの時間が必要である。

### 余白の戦略
時間と機能の期待がトレードオフにならない場合、どうしても時間や追加費用をかけざるを得ない。
そこで、全体のプランニングにおいて、予備の時間をあらかじめ確保しておくのが「余白の戦略」である。
余白には3種類（調整の余白、期間の余白、受け入れの余白）がある。
#### 調整の余白
**プロダクト要求範囲の広さでコミットし、実現する機能の度合いの深さで調整する。**
× 広さも深さもコミット→範囲も機能度合いも固定され、変化に対応できない。
× 深さでコミット→機能の深さは可変となるが、時間切れ・予算切れ時に広さを満たしていない恐れがある。
　広さがコミットできないため、成果物完成責任が無い準委任契約となるが、この場合、
　個々人の裁量となるため、要求範囲に届かないことが十分起こり得る。
○ 広さでコミットすれば、要求範囲が明確になる。ユーザとしての価値提案の中核がハッキリするため、集中すべき箇所が分かる。
一方で深さについては、オプションとして要求に加え、最低要件で合意できればOK。
##### ユーザーストーリーマッピング
ユーザーが製品を利用して何を期待しているか、及びその理由についてを、シーンごとにユーザーストーリーとしてまとめ、ユーザーの行動と課題を明確にするものである。
前提として、「ユーザー」がどのような存在なのかを検証しておくことが大切である。
ユーザーが意識的に行う行動、無意識のうちに行う行動、強制される行動を書き出す。その行動から課題を上げる。
課題解決に必要なユーザーストーリーを抜き出す。複数のユーザーストーリーのうちいずれでも課題解決につながるものはオプションに回す。
抜き出したユーザーストーリーは、優先度順に並び変える。1回目はユーザーに対する重要度で、2回目はユーザーに体験してもらいたい優先順位で並び変える。
各シーンごとに、優先順位がトップであるものをまとめて、MVPの製作範囲とする。
ユーザーストーリーマッピングは対話で行い、参加者の認識を段階的に整えていく。
また、複数人で行う事で、ユーザーの解釈を複数持たせられる。→広さに対する抜け漏れを防ぐ。
ここで深さを規定するのは難しいため、一度ユーザーストーリーマッピングが終わってから検討する。
#### 期間の余白
**プロジェクトの期間にバッファを含める。**
ローンチまでの短期間化が進む中でバッファを設けるのは容易ではない。
プランニングの規模見積もり時、ユーザーストーリーの大きさをチームで決定する。（プランニングポーカーを良く用いる。）
チームで決定すると、個人の見積もりに左右されず、共通理解も得られる。
但し、バッファをユーザーストーリー単位や見積もりを行う人単位で決めてしまうと量が膨れ上がるため、プロジェクト全体を通じてバッファを設定する。
バッファを確保しつつ、シビアに期間を見積もってリリースプランニングを行う。
バッファは追加タスクごとに、空白スプリントを消化する形で利用する。
バッファの日数管理も極めて重要である。バッファの残りが一定程度以下になると、再度共有を行うと良い。
#### 受け入れの余白
追加の要件に対しては、バックログとは別に**アイスボックスで凍結させて**おき、余裕がある場合にのみ実行できるようにする。
但し、要件がオプションであることの関係者による同意が前提である。

### スプリント強度を高める戦術
**不確実性に対し、余白だけで対応することには限界がある。** 例えばリモートワークでの会議では、言語以外の要素が乏しく、少ない情報で開発を進めなければならない。このように、余白で対処できない不確実性もある。
そこで、スプリントをやり抜くために、確実性の確保を行う必要がある。各スプリント前には確実性を確保しておき、余白で不確実性を受け止めながら、目の前のスプリントは確実に実行できるよう仕切る。
#### ダニエル・キムの成功循環モデル
関係の質（チーム関係の構築）→思考の質（考え方・知識）→行動の質（適した行動）→結果の質（高品質な製品）
#### プロジェクトの背骨を作る
プロダクトバックログが「骨格」ならば、最も核となる機能が「背骨」である。この背骨部分を最初の数スプリントで部分的に作って繋げていき、そこから追加要件を肉付けしていく形をとる。同時にプロダクトに対する制約やガイドライン、定義モデル等、開発の基本的な進め方も「背骨」段階で定義しておく。
早期にかつ質の高いアウトプットが求められる。
#### プロダクト作りをクリーンに保つ
プロダクト作りをきれいに保つためには、以下の5要件が求められる。
1. 受け入れ条件を定義している。
プロダクトバックログごとに、受け入れられる条件を示したもの。
条件をクリアできなければ仕様を満たしているとは言えない。
プロダクトオーナーによって行われることが多いが、開発者に適した言語の細分化はほとんど行われず、難しい。
2. ベロシティを計測し、安定させている。
チームの1スプリントでどこまで開発できるかを示す値。最初は分からないので仮置きでOK。データがたまってきたらベロシティを測定して、スプリントのゴールを見定める際の基準とする。基本的にスプリントを消化する毎に増加または安定する。もし乱高下している場合は、プロダクトに何らかの問題が発生している可能性が高い。原因を調査して取り除く。（原因の例として、バックログの規模見積もりの正確性が低い、タスク・リスクの抜け漏れ等が考えられる）
ベロシティを安定させるためには、バックログアイテムをできるだけ細かくする。
また、規模は絶対的な数値（例：5日間）ではなく、基準のバックログアイテムを「1」とし、これと比較して何倍の期間が必要…と相対的に見積もる。絶対値は基準の「1」の期間がどのくらいかを求める際に用いる。細かいバックログアイテムほど定めやすい。
3. 受け入れテストを実施している。
1の受け入れ条件に則り、受け入れ条件を満たすかのテストを行う。テストはレビューの後に行う。→認識の相違があれば次スプリントですぐに齟齬を解消できる。
テストケースは自動化が望ましい。そこでテストコードをいつ書くかが問題となる。
①コード実装前、②コード実装後、③書かないの3つが考えられる。判断基準としては、要求の安定度がある。必要なものの検証のためのテストか、振る舞いが期待通りであるか確かめるテストかで、大きく意味合いは異なる。要求が安定するならば①、安定せず検証の意味が大きいならば③、その中間が②となる。
4. 振り返りを実施し、カイゼンし続けている。
**理想を追う限り、「問題が無い」ことは無い。**　レトロによるカイゼンの意義はここにある。
Start/Stop/Continue　Start…始めた方が良いこと　Stop…やめた方が良いこと　Continue…続けていくべきこと
5. 実運用相当のデータがそろっている。
スプリント強度を高めるには、**「考慮していかった。後でやろう。」をいかに無くすか**が大切である。
開発期間の後半になればなるほど、考慮漏れの手戻りは致命的となる。
実運用のデータが不足していると、後半に手戻りが見つかる可能性が高まる。手戻りのリスクを無くすためにも、データの取得が望ましい。
また、データによって理解度を深めた開発につながるメリットもある。
但し、データの取得は関係者の理解が必要不可欠である。後回しにされることも多いため、プランニング時に利点を伝えて説得する必要がある。

### 全体の共通理解を統べる作戦
#### OODAループとレベル
OODAループとは、不確実性が極めて高い場合に用いられる意思決定モデルの一つである。
Ovserve（観察）、Orient（適応）、Decide（意思決定）、Act（行動）の順で、各行為の相互作用によって形成される。
このループを参考にした具体的な振る舞い方を3つのレベルで紹介している。
##### 個人レベル
SAR（Share（共有）、Assert（表明）、Reflect（振り返り））を指針とする。
考えや行動を共有し、そこから自分の意見を述べる。また、それを自ら振り返り、自らカイゼンしていく。
自律的なチームを目指すためには、これらのサイクルを自律的に行う必要がある。
##### チームレベル
線表ベースでのコミュニケーション
１枚の表に開始からリリースまでの全体計画を収め、日付、スプリント、スプリントで扱う項目、重要事項を記述したもの。
どういう計画でどんな展開状況にあるのかを理解するために、線表は最適である。
細かな開発計画ではなく、大まかな期間の感覚をつかみ、チームや関係者の暗黙的なものも含めた意思を反映させ、見える化するためにある。
##### ファシリテーターレベル
開発に携わる者それぞれの相互理解には、多大な意識とコストを要する。
そこでこれを円滑に行うため、ファシリテーターは意識的な働きかけや感情の言語化、場づくり等を行う。
**ファシリテーターはプロダクトづくりの演出家**である。
#### 作戦を考える上での留意事項
上記の各作戦には、名前を付けた方が良い。チームの士気が上がり、会話に上りやすくなる。
また、作戦には期限性を持たせる。作戦適用期間が終了したら、チームで評価を行い、カイゼンを次の活動に生かす。

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