# 正しいものを正しくつくる　第1章,2章
## 第1章　なぜプロダクトづくりが上手くいかないのか
アジャイル的な技術、プロセス、チーム、コミュニケーション…こうしたものは10年前と比べて劇的に進歩した。
しかし、プロダクト作成に伴う苦労や、費やす時間やコスト、荒ぶる感情はそれほど減っていない。
* 誰にとっても何が正解かわからないものを作る難しさ
* 不確実性の中で決められない・分かっていないことを実現する難しさ
の２点が、アジャイルチームを苦しめる要因になる。

### プロダクト自体の多様性
#### SoR(System of Record)
* 動作の信頼性が求められる。
* 期待通りの動作をさせるために、要件定義を入念に行い合意する。
* 要件定義の整合性を担保するために、仕様書を作成する。
* 決められたものを正しく作る。→ウォーターフォール型
#### SoE(System of Engagement)
* 顧客との関係性を育む。
* 顧客のことを良く知るほど、正確性が高まる。
* 不特定多数が対象で、「正しい動作」を定義しにくい。
* 「こうあると良いのではないか」という仮説を検証する。
* 短期間で少しずつフィードバックを得て前進する→アジャイル型
#### プロダクト作成技術の多様性
フロントエンドからバックエンドまで、新技術が次々と生まれている。

### 作り手側の多様性
#### 開発チーム内の役割
プロダクトオーナーからデザイナー、プログラマーまで様々な役割を持つ分、お互いの役割の理解が得にくく、意見が衝突しやすい。「役割」という境界。
他にも経験、働き方等、様々な多様性が、不確実性を生じやすくする。

### 要件定義とは何か
#### 要件定義と多様性
要件定義は「何を作れば良いのか」を明確にする。
ただ、その要件定義の表現スタイルは多様性が生まれる。
そこで、以下の3点を混同しないようにする必要がある。
* 要求：「こうしたい。こうありたい。」という希望。
* 要件：「要求」を実現するための条件。
* 仕様：「要件」を満たすための詳細な条件。
要件定義の表す意味自体も多様性を持つ。
こうした要件定義は顧客がリードしてきたが、技術の進化や変化のキャッチアップが難しくなり、ベンダー側と共に行う事が多い。
ゆえに、ベンダーにはよく業務を知り要件定義がこなせるかどうかが重視された。

### 不確実性を抑え込む作戦と課題
旧来の不確実性の抑え方には問題点がある。
1. 要件定義で確実性を高める。
要求に基づいて行うため、確実性は高まる。…正しい条件を決められたならば。
開発前時点で分からない、作っていくうちに分かるものもあり、プロジェクトを大きく混乱させやすい。
2. 合意を重視する。
要件定義で顧客との間で合意したものとし、開発を進めていく。
スピード感は上がるが、後からの追加・不足要求に応えられず、結果的に手戻りやプロジェクト中止に陥る可能性がある。
3. 合意形成を遵守する。
合意形成を変化させないことで合意形成に則った形で最後まで進めていく。
こちらも、合意形成を変更できないため、後から分かったことに対応できない。

### アジャイル開発への期待と失望
**誰も正解かわからないので、あたりをつけながら、間違う前提を念頭に置きつつ、関係者の間で合意形成しながら進める。→アジャイル開発**
#### アジャイル開発の特長
* 短い開発サイクルで合意形成をしながら進む。
* MVPを実際のユーザに使ってもらいフィードバックを得て不確実性を解消する。
* ユーザが必要としているものを開発する。
* **プロダクトを必要とする人と、作り手との間で利害と思いが一致するやり方・あり方。**

#### アジャイル開発の困難さ
スクラムガイドは「軽量・理解が容易・**習得は非常に困難**」とある。
なぜ習得が困難なのか？
* アジャイル開発は経験主義であり、実践経験が乏しいため。
* プロダクトバックログの粒度の認識が異なり、出来上がった製品と顧客の想定とのズレが生じやすいため。
* レトロで課題が分かっても、次のスプリントに組み込めない。組み込む余地がない。
こうした困難が重なり、チームに失望感が生まれ、経営層からストップをかけられてしまう。

## 第2章　プロダクトをアジャイルに作る
### アジャイル開発とは何か
アジャイル開発の成り立ちは、言葉よりも手法が先。
2001年に、手法を編み出した17名が協議し、4つ価値、12の原則を記した[アジャイルソフトウェア開発宣言](https://agilemanifesto.org/iso/ja/manifesto.html)が誕生した。
また、詳細な開発方法に関しては一概に同意できるものではないとする「不同意の同意」に関しても同意された。
#### 4つの価値
* プロセスやツールより、**個人と対話**を。→人と人の相互作用、相互理解。
* 包括的なドキュメントよりも、**動くソフトウェア**を。→ドキュメントの作成自体は目的ではない。ドキュメントだけでは正しい判断や意思決定ができない。
* 契約交渉よりも、**顧客との協調**を。→駆け引きよりも調和による意思決定の方が効率的。
* 計画に従うことよりも、**変化への対応**を。→目の当たりにした事実をもとに計画を立て直す。

### スクラムとは何か
スクラムとは、経験主義に基づくプロセスのフレームワークである。（[スクラムガイド](https://www.scrumguides.org/docs/scrumguide/v2017/2017-Scrum-Guide-Japanese.pdf)）
スクラムは、経験をもとにアレンジするものである。（×標準プロセスのようなマニュアル化　×他者の成功経験をそのまま取り入れる）
#### 3つのコンセプト
* **透明性**：情報の見える化のために必要な振る舞いを、チーム全体で共有し理解している。
* **検査**：頻繁に作業や成果物を検査し、問題点を洗い出す。
* **適応**：検査によって洗い出された問題点に、素早く適応する。
#### 5つの価値基準
* **確約**：ミッションの達成に各々が役割を果たすことを確約する。
* **勇気**：問題を見逃さず、チームで共有する勇気を持つ。
* **集中**：スプリントの活動は集中して取り組む。全集中の呼吸で。
* **公開**：抱えている課題を隠さず公開する。
* **尊敬**：関わる全ての人々へ尊敬の念を持つ。

### スクラムチーム
スクラムチームは**自己組織化**され、**機能横断的**なチームでなければならない。
* **自己組織化**：ミッション実現に向かうための選択を自分たちで決定し行動できる度合い。
* **機能横断**：チームの外側に頼らずに仕事を成し遂げられる編成である。
#### スクラムチームメンバー
* **プロダクトオーナー**：プロダクトの価値向上に責任を持つ。開発チームに対し、製品に対するバックログの項目を絶えず提供する。
* **開発チーム**：プロダクトの完成に責任を持つ。バックログを理解し、リリース可能なプロダクトに形作っていく。規模は3～9人が理想的。
* **スクラムマスター**：理想的なスクラムの実施を促し、その支援に責任を持つ。経験豊かなスクラムマスターの加わりで、チームとしての経験を底上げする。
* スクラムマスターが求められる役割
* チームが抱える問題を認識し、共有する。
* チーム外部との認識の相違を解消する。
* プロダクトオーナーと開発チームとの認識の相違を解消する。

### スクラムイベント
#### スプリント
**スプリント**は、**タイムボックス**という時間の上限が固定された枠組みの集合体を、スプリントプランニング→デイリースクラム→スプリントレビュー→スプリントレトロスペクティブの順で1つにまとめたもの。このスプリントを繰り返して開発を行う。
なお、1スプリントは1ヶ月以内とする。（不確実性を上げないため）
ローンチまでに必要なスプリント数を数え上げるのは、計画の見える化として大切である。
また、プロダクトオーナーは、開発の見込みが立たない場合や生じた変化にゴールが対応できない場合、スプリントを途中で中止することができる。事実上のプロジェクトの中止を意味する。プロジェクトは反復して続くので、この時の学びは次のプロジェクトに生かすことができる。
#### スプリントの各項目の果たす役割
* **スプリントプランニング**
　　* スプリントの「目的」を明確にする。
　　* 実施するプロダクトバックログアイテムを選択し、実現計画を立てる。
　　* 1スプリントにおける開発実績であるベロシティをもとに進度を考える。
　　* ファイブフィンガーは、バックログアイテムを実現できるかの意思表示が手軽に行える。
* **デイリースクラム**
* 1日の計画を検査する。バッチサイズが小さいスクラムと言える。
* 昨日の実績（検査）、今日の予定（計画）、問題点（問題提起）を伝える。
* **スプリントレビュー**
* 関係者全員が参加し、成果をデモンストレーションする。
* あらゆる立場から見た改善点を共有し、フィードバックを受ける。
* このフィードバックを受けて、ローンチタイミングを予測し直す。（着地のタイミングの修正）
* **スプリントレトロスペクティブ**
* スプリントで分かったことを棚卸しして、カイゼンに生かす。
* より生産性が高まるよう、楽しい会にする必要がある。

### 成果物
* **プロダクトバックログ**
プロダクトの実現要件をまとめたもの。いわゆる合意した要求一覧である。
粒度が大きくスクラムでは構造的に扱いにくいため、内容や難易度の詳細別に分類しておく。
プロダクトバックログアイテムの詳細化は、開発チームとプロダクトオーナーが協力して行う。
* **スプリントバックログ**
開発チームが主導で管理する、スプリント単位でのバックログ。デイリースクラムで行えたかどうかを判別できるよう、粒度を1日単位でとり、内容を詳細化する。
* **インクリメント**
動作するプログラムのこと。常に動作し、スクラムチームが決めた「完成」の要件を満たす必要がある。

### アジャイル導入のパターン
1. 自分たちで勉強会を開き、知識を得る。
2. 外部の勉強会で知識を深める。
3. 自分たちで始めてみる。
4. 外部から経験者を招いて始める。
どのパターンも、**小さく始める**ことが肝要である。（規模・適用量）
### ゴールデンサークル　Whyから始める
ゴールデンサークルは、思考と行動のフレームワークで、**目的(why)→手段(how)→具体的な行動や製品(what)** の順に行動する。
whyから始める考え方は、自分たちのありたい開発に向き合うためにある。

### アジャイルに作る9つの意義
アジャイル開発は**インクリメンタル（漸進的）** でかつ**イテレーティブ（反復的）** でなければならない。
こうした開発には9つの意義がある。
1. フィードバックに基づく調整で、**目的に適したプロダクト**に仕立てられる。
2. 形にすることで、早めに関係者の認識を揃えられる。
3. 作るものやチームについての問題に素早く気づける。
4. **チームの学習効果が高い。**
5. 早く作り始められる。
6. 結合のリスクを早めに倒せる。
7. **Time to Market（市場に届くまでに必要な時間）** が短い。→MVPによる早いサイクルによる検証と早期の収益化。
8. サンクコスト（中止になり無駄となった費用）を最小限にできる。
9. 開発チームのリズムを整えられる。

### HowとWhat
* How→スクラム・カンバン・XPなど。一つ一つにWhyをぶつけてみることが大切。
* What→型との**Diff（差分）を理解**して、その扱いをどうするかを決定する。（メンバー配置、テスト環境、新技術等）これもWhyからそれないように。

※学習だけで一喜一憂せず実践してみる。実施には組織の協力が必要である。

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