# いちばんやさしいアジャイル開発の教本
市谷聡啓
新井剛
小田中育生　共著
## 1. アジャイル開発の世界
アジャイル開発を取り巻く世界
* ITビジネスの変化：DX対応、売り切りからサブスクリプションへ、UX（ユーザ体験）、コト消費など
* ユーザとの対話：SoE(アプリ系)とSoR（基盤系）を組み合わせ、SoI（顧客インサイト）の向上につなげる。
* 技術の変化・進化の速さに対応し、細かくリリースを繰り返すものが多い。
* 迅速な変化への対応と、細かくスプリントを繰り返すアジャイル開発の長所と重なる。

## 2. なぜアジャイル？(Why Agile)
* ウォーターフォール型の特徴
* 一方通行の開発：前工程に間違いが無い前提。無駄な開発や手戻りが多い。フィードバック不足。
* 開発期間の圧迫：前工程の遅れが後工程に響きやすい。
* 不確実性のもみ消し：ウォーターフォール型は確実さを重視し、後半に変更できない。
* 組織の人間関係：対話での情報伝達に時間がかかる。
* アジャイル開発の特徴
* スプリントを回す：計画を立て、細かくリリースを行う工程を何度も繰り返す。期間ごとにレビューやフィードバックがある。
* 開発効率の向上：心理的な安全性が担保され、開発効率も上昇する。
* 不確実性を許容する：後半の工程からでも要求変更を歓迎し、不確実性に向き合うしなやかなチームに。
* 組織の人間関係：お互いに尊重しあい、同じ立場に立って意見交換する。

* アジャイルで本当に必要な行動
やるべきことに集中し、不要なものは作らないという取捨選択

## 3. アジャイル開発がもたらす変化
* 最も効果的・効率的な意見交換「対話」：相手の価値観を尊重し、信頼が深まり、意見交換が活発となる。
* 動くソフトウェア：リリースは「動く最低限のソフトウェア(MVP:Move Viable Program)」
* 顧客とともに：顧客との意見交換が積極的になり、課題を共有できる。
* 変化に対応する：意思決定をなるべく遅らせ、様々な可能性を考えて開発。時には柔軟に方針転換。
* 職能横断型チーム：各部門のスペシャリストを集め、互いの意見をぶつけ合い協働する。
* 自己組織化チーム：チームが統一のビジョンを持った上で、自ら判断できる力を持ったチームが理想的なチーム。
* アジャイルの成長戦略：足りないスキルは自ら身につける。スプリントで得た反省を生かし、カイゼンできるチームへ。
* YAGNIの原則：You Ain't Gonna Need It. 機能は実際に必要になるまでは追加しない。
* KISSの原則：Keep it simple,Stupid!　シンプルな設計が成功のカギ。
* スピードと質の両立：短期間での開発は、相互作用で両方が高まる。
* すべてはチーム次第：チームがいかに自己組織化チームとなるか、スキルと意思決定が結果を左右する。

## 4. アジャイル開発のコンセプト
* チーム
自己組織化された、職能横断型チーム。インクリメンタル（少しずつ、漸進的）に成長する。
スクラムの役割分担は、全員でプロジェクトに応じて決める。
アクティビティを行い、チームメンバーが共通して理解する。
（プロジェクト→インセプションデッキ、チームメンバー→ドラッガー風エクササイズ、約束事→ワーキングアグリーメントなど）
活動の場を準備する。（環境、ツールなど）
* プロセス
イテレーティブ（反復的）なプロセス。
スプリントプランニングで、週の作業予定を全体で共有する。
プロダクト制作中の不確実性は、プロジェクト全体で受け止め、確実性はスプリント単位で高める。
スプリントレビューは、プロダクトの評価を行う時間。プロダクトの現状を受け止め、カイゼン策や対応を練る。
スプリントレトロスペクティブは、チーム全体でスプリントを振り返る時間。チームも立派な成果物！
* プロダクト
インクリメンタル（少しずつ、漸進的）に形成される。
必要な変更を素早く行えるようプロダクト開発を行う。（品質維持の難しさ）
システムの全体像を見失わないようにする。
ユーザ視点に立ち返り、機能別のユーザ行動フローを作成し見える化する。

## 5. アジャイル開発を始める
はじめてのアジャイルに必要なのは、目標や状況の「見える化」と、仲間とともに「一緒に取り組む」である。
a.「見える化」
* タスクの見える化（Trello:カンバンを参照）
スプリントバックログで、タスクの優先順位（緊急性の高さ、重要度の高さで判断）をつける。
実行予定（TO DO）、実行中（Doing）、待機中（Waiting）、完了（Done）の4つのタスクボードで進捗管理を行う。
タスクは簡潔に、要点をまとめる。
* 日常の見える化（朝会）
昨日実行した事柄、今日実行予定の事柄、困っていることの3点を毎朝チームで共有する。同じ時間、同じ場所で実施するのがポイント。
* やったことの見える化（レトロスペクティブ）
KPT（Keep:続けること、Problem:問題点、Try:カイゼン策）等の方法で行う。感謝も見える化できればベスト！
b.「一緒に取り組む」
* ペアプログラミング
片方がコードを書き、もう一人がレビューを行う、2人1組での開発方法。
c. プラクティスを習慣化する
継続的にプラクティスに取り組むことが、チームを育てる。

## 6. 上手なカイゼン策
* 継続的インテグレーション
バージョン管理ツールなどで統合を自動化し、常にリリース可能な状況にしておく。不具合があると通知が行くようにする。
その結果、無駄な時間が減り、安定した品質のプロダクトをリリースできる。
* テスト駆動開発（TDD）
はじめにテストコードを書き、Red→Green→リファクタリングになるようコードを記述・修正する。この手順を繰り返す。
不具合を早期に見つけることができ、結果的に手戻りが少なくなる。
* チーム共有時間の形骸化対策
朝会が時間の無駄だと思ったり、犯人捜しを恐れて意見を言えなくなる可能性がある。朝会を飛ばしたり、聞き方を変えて心理的なハードルを下げる方法がある。
レトロスペクティブが暗いと感じたときは、FDL（Fun!：楽しかったこと、Done!：完成できたこと、Learn!：学んだこと）を用いると成功体験のイメージを残すことができる。
* 見える化をうまく行うには
定期的に棚卸を行い、不必要な情報を見分けて整理する。
* 成長に停滞感を感じたら
流れのスピードアップや役割を超えて乗り越えるパターンの2つがある。
* カンバン（業務プロセスを一連のレーンとして見える化したもの）
全タスクに着目するため、チームの意識が向かい、全体を最適化しやすい。
* モブプログラミング
他のメンバーも含め一斉に1項目を開発する。確認依頼などの手間がかからない。
* プロダクトバックログリファインメント
プロダクトオーナーが、バックログのメンテナンスを同時に行い、技術的な視点や全体俯瞰などの抜け漏れや曖昧性を減らすことができる。
* アジャイル開発にあった契約
アジャイル開発は、成果物の完成責任を負う請負契約ではなく、作業を請け負う準委任契約がベスト。柔軟な仕様変更を受け入れることができる。
* 余白の戦略
顧客側にあえて時間的・機能的余白を提示することで、仕様変更などに対応できる時間が増える。
* プラクティスを開発する
現場にあった解決策を自ら見つけていき、積極的に改善を行っていく。
* 既存組織との融合
最初は小さな部分から始めていき、だんだんと仲間を増やしていく。問題やトラブルにあえて焦点を置き、カイゼン策を提示するのもよい。

## 7.　アジャイル開発の理解を深める
* アジャイル開発の誤解を解消する。
アジャイル開発を社内で理解してもらうに当たり、ウォーターフォール型との対立が生じやすい。
* タスクVS目的
ウォーターフォール型では、要件定義や設計等の工程等の「タスク」（Whatの考え方）を重視しやすい。対して、アジャイル開発は目的（Whyの考え方）を重視しやすい。両者で対立すると論争になるため、まずは目的（Why）から考えて、適切なHowやWhatを選択する手法をとる。
* コストと納期
ウォーターフォール型は、決められた納期までに決められたコストで作成するのに対し、アジャイル型は、相手の求める価値を探索しながら、試行錯誤して作成する。
決して安さや早さを保証するわけではないが、継続的なフィードバックにより、ユーザの価値ある成果物を作成しやすい。
* 見積もりと計画
ウォーターフォール型は最初のインプットでできる限りの見積もりを立てる。対するアジャイル工程の見積もりは、機能で細分化した全体の見積もりと、必要なタイムボックス（インプット→アウトプットのスプリント）の見積もりを用いる。全体の見積もりは、機能数とチームの練度によって、大まかなタイムボックス数を算出する。
タイムボックスの見積もりでは、必要な機能数をスプリントで回す。また、スプリントはリリースプランニング、スプリントプランニング、デイリースクラムでスプリント毎、一日毎に計画を立てる。→計画との誤差が把握しやすく、繰り返すごとに見積もりがハッキリとしてくる。
* ドキュメント
アジャイル開発ではウォーターフォール型で必要なドキュメントを書かないと思われがちだが、必要に応じて作成する。ドキュメント作成の目的(Why)は何を作るか（What）とどのように作るか（How）を明確にするためである。アジャイル開発は動くソフトウェアで合意形成を行うため、ドキュメントはそれを補完する役割を持つことが多い。大切なのは、成果物に関わる全ての人がシステムの内容を共有できることである。
* 要件定義
ウォーターフォール型は最初にまとめて要件定義を行うが、アジャイル開発は最初に全体を把握するための要件定義を行い、その後にスプリント毎に要件定義を行う。チームの練度とプロダクトの複雑さによって、要件定義をどこまで深くするかが決まる。（初めてのチームやプロダクトが複雑→詳細な要件定義が必要）
* 設計
ウォーターフォール型は要件定義と開発の間に組み込まれるが、アジャイル開発では全体（プロジェクト単位）と部分（スプリント単位）に分けて設計を行う。不確実性が高い状態では変化に対応するため、できるだけ全体の決定を遅らせて調整する。
* テスト
ウォーターフォール型は開発工程の後に位置し、フェーズ毎（結合度の大きさで区別。）に行うが、アジャイル開発では、タイムボックス（スプリント）毎にリリースを行うため、同様にタイムボックス毎にテストを行う必要がある。主なテスト手法である4象限のテストは「ビジネス面」「技術面」「チーム支援」「プロダクト批評」の4つの観点からテスト分類を行う。また、テストは可能な限り自動化・自働化を行う。
* 全体
アジャイル開発を企業に適用するには、これまでとの考え方の変化（失敗から学びを得て適用する）がチームや集団で浸透しなければならない。まずは1人から始め、徐々にチームや組織に広げていく。また、守→破→離の考え方が大切になってくる。

## 8.　アジャイル開発はあなたから始まる
アジャイル開発は失敗の歴史である。主に契約形態、他の現場プラクティスの適用、経験者不足・偏りにより、失敗している。自分自身の感覚を大切にして、取り組んでいく必要がある。
また、他のアジャイル開発者と交流し、学びを広げるのも一つの手である。特定の役割に起因するものでもない。自分自身の意思が固まったならいつでも「越境」していくべきである。
###### tags: `読書`