# アジャイルサムライ　第Ⅰ部、第Ⅱ部
# 第Ⅰ部　「アジャイル」入門
## 第1章　ざっくりわかるアジャイル開発
### 1.1 価値ある成果を毎週届ける
1. **大きな問題は小さくする。**：粒度はなるべく小さく。
2. **本当に大事なことに集中して、それ以外は忘れる。**：価値に繋がらないものは捨てよ。全集中の呼吸。
3. **ちゃんと動くソフトウェアを届ける。**：テストをおろそかにしない。
4. **フィードバックを求める。**：フィードバックによる学びは、アジャイルの夜道を照らしてくれる。
5. **必要とあらば進路を変える。**：変更を恐れない。現実が変更できないなら、計画を変更せよ。スコープを柔軟にしておく。
6. **成果責任を果たす。**：仕事の質に責任を持ち、スケジュールを守り、お客様の期待マネジメントを行い、お客様の資金を扱う。
### 1.2～1.4　アジャイル開発のポイント
* 全員が全員アジャイル開発をするわけではない。**どうするかは自分次第。**
* お客様と一緒に信じることのできる計画を立てて仕事を進めていく選択→アジャイル開発。
* 完了はアジャイル開発で必要なあらゆる作業が完了し、**リリース可能である**ことを指す。
* **やり方は一つではない！**：唯一無二なる究極の手法は存在しない。スクラムやEX、リーンが全てではない。
* **自分の頭で考えるのをやめちゃダメ！**
#### ソフトウェア開発の3つの真実
* プロジェクトの開始時点で、**全ての要求を集めることはできない。**
* 要求はどれも**必ずと言っていいほど変化する。**
* やるべきことはいつだって、**与えられた時間と資金よりも多い。**

## 第2章　アジャイルチームのご紹介
### 2.1 アジャイルなプロジェクトはどこが違うのか
* **チームの役割分担がハッキリしていない。**：人それぞれ強みがある一方で、人は得意分野にこだわりすぎてしまう傾向にあるため。
* 開発工程は**途切れることのない連続的な取り組み**となる。：一度きりのウォーターフォール型VS連続的なアジャイル型
* **チーム一丸で成果責任を果たす**考えを重視する。：縦割り組織VS一丸となったチーム
### 2.2 チームをアジャイルにするためのコツ
* **同じ仕事場で働く。**：メンバーの**意思疎通や信頼関係向上**の効果があり、チームの生産性向上に欠かせない。仕事場が分散していても**ギャップを埋めるためにできる努力**はある。（全員で集まる機会をプロジェクトとして設ける等）
* 事例：ピクサー（ディズニー映画の一部を制作するアニメスタジオ）に対する、社員の仕事場の統一。
* **積極的に深くかかわる顧客（Engaged Customer）**：プロジェクトに積極的に参画し、質問やレビュー、フィードバックを行える顧客。**プロダクトオーナー**や、オンサイト顧客など。→こうした顧客になってもらうためには、**少ない期間で確実にカイゼンしたプロダクトを届ける実績を達成し、信頼を高める**必要がある。
* **自己組織化**：役割を人に合わせるのではなく、**人に合わせて役割分担を決める。** **当事者意識を持ち、自ら積極的に動ける人材**であれ。
* **成果責任と権限委譲**：アジャイルに働くチームに欠かせない要素の一つが、**適切な権限移譲**である。その上で初めて**成果責任を果たせる。**
* **職能横断型チーム**：メンバー全員であらゆることを解決できるチーム。複数のスキルを持つ**ゼネラリスト**が望ましいが、開発に足りていない要素は**スペシャリスト**で補う。

### 2.3 よくある役割分担
アジャイルチームは、**何を作るかを決める顧客（プロダクトオーナー）** と、**どうやって作るかを決める開発チーム**で構成されるのが一般的。
アジャイルのチームの役割は、誰かによってちゃんとこなされていれば、割り当ては特に気にしない。
* **顧客（プロダクトオーナー）**：あらゆる要求の「**真実の源**」である。問題領域の専門家であることが望ましい。何を作るかを決め、優先順位をつける。また、期日が迫る中で切り捨てる要求を決める。**顧客を直に巻き込むほど、プロダクトは良くなる。**
* **アナリスト（分析担当）**：顧客からの要件を整理し、詳細な分析を行い、ユーザーストーリー作成を手伝う。ツールを総動員して**ユーザーストーリーの本質を探っていく。**
* **プログラマ（コード作成担当）**：**質の高いソフトウェアを生み出すプロフェッショナル。** ユーザーストーリーから工数を見積もり、技術的な判断を下す。また、テストコードをたくさん書き、リファクタリングを行い、いつでもリリース・デプロイできるようにする。
* **テスター（テスト担当）**：**ユーザーストーリーが期待通りに動くか**を確かめる。全体像を抑えた上でテスト条件等を整える。
* **プロジェクトマネージャー（全体統括担当）**：顧客と開発チームをつなぐ役割。現状を常に確認し着地点を見定め、障害を取り除き、**プロジェクト全体の円滑化**を図る。
* **UXデザイナー（デザイン担当）**：**顧客に価値を届けるデザイン**を提供する。イテレーションを通じて少しずつデザインを完成させていく。
* その他の役割
* **アジャイルコーチ**：アジャイル開発の原則や考え方をチームに説明し、最後までやり遂げられるよう、浸透を後押しする。
* **スクラムマスター**：アジャイルコーチであり、プロジェクトマネージャーでもある。新しいチームを軌道に乗せる。
### 2.4 チームメンバーを探すコツ
* ゼネラリスト
* 曖昧な状況に抵抗が無い人
* 我を張らないチームプレイヤー

# 第Ⅱ部　アジャイルな方向づけ
## 第3章　みんなをバスに乗せる
### 3.1 プロジェクトがダメになるのはなぜか
* チームメンバーの**認識の相違**。→ゴールやビジョン、プロジェクトの状況や背景などをチームでよく話し合い、**認識を共有する。**
* **全員で話し合う前から前提が出来上がってしまっている。** →**ステークホルダーに情報を提供する。**

### 3.2~3.5　手強い質問とインセプションデッキ
物事の本質が分かっているかを確かめるには、**手強い質問**を投げかけると一目瞭然である。
この質問を、**プロジェクト（契約）の最初に行う**ことが大切である。これらの質問を10個の課題にまとめたのが、**インセプションデッキ**である。現在では多くの参考書に載っているインセプションデッキは、**ロビン・ギボンズが原型を考案**し、今読んでいる **「アジャイルサムライ」にて提唱された。**

インセプションデッキの背景には「**しかるべき人を同じ部屋に集め、プロジェクトにまつわる適切な質問をすれば、プロジェクトに対する期待を共有でき、認識を合わせることができる**」との考えがある。
従って、インセプションデッキには**ステークホルダーの参加**が重要である。
また、インセプションデッキはあくまでも出発点であり、そこから自分たちに合わせて改変していくことが大切である。

## 第4章　全体像を捉える　＜インセプションデッキのWhy部分＞

### 4.1 我々はなぜここにいるのか
* **背景にある「なぜ」をつかみ、このプロジェクトを行う意義を問う。最もシンプルで最も重要な問い。**
* 「なぜ」が理解するメリット
* **的確な判断**を下せる。
* 対立点やトレードオフの**バランス**をうまく保てる。
* 自分たちで考えられるため、**斬新な解決策**を生み出せる。
* 自分自身が**現場に行って確かめ**、「なぜ」を理解する。
* **司令官の意図**：**プロジェクトの目標や目的**を、簡潔な言い回しや文章で表現したもの。重要な決断を迫られる際の判断基準となる。
### 4.2 エレベーターピッチ
* **プロジェクトを30秒で説明せよ。** エレベーターに乗っている間に関係者に説明できるよう、**要点やメリットを端的にまとめる。**
* エレベーターピッチのメリット
* プロダクトが具体的に**何であり、誰に向けてのものなのかが明確**になる。
* プロダクトは**何を提供し、なぜ提供するのか。チームの意識を顧客に**向けさせることができる。
* **プロジェクトの核心が明確** となり、**本当に重要なことは何か**がすぐにわかる。
* テンプレート
* [解決すべき課題]したい
* [対象顧客]向けの、
* [プロダクト名]というプロダクトは、
* [プロダクトカテゴリ（○○システム等）]である。
* これは、[重要な利点・説得力のある理由]ができ、
* [最も大きな代替手段]とは違って、
* [最も差別化できる特徴]が備わっている
### 4.3　パッケージデザイン
* プロダクトをアピールする商品デザインのこと。
* 進め方
1. まずはブレインストーミングで、**ユーザーから見たプロダクトの価値**を明確にする。フィーチャー（機能）ではなく、その**効能（価値）** をアピールする。上位3つを選出する。
2. キャッチコピーを決める。
3. パッケージをデザインする。
### 4.4 やらないことリスト
* 開発における**実施事項、実施しない事項、あとで決める事項**を明確にする。これらをはっきりさせることで、無駄を省ける。
* リスト作成は、顧客と開発チームが合同で実施する。

### 4.5 「ご近所さん」を探せ
* クライアント、上司、協力会社etc…　プロジェクトに関わる人間を洗い出す。
* ご近所さんづくりの第一歩は**挨拶**から。
* **プロジェクトコミュニティは思っているよりも常に大きい。** プロジェクトに関わる存在に気を配り、積極的に良好な関係を築くべし。
* 具体的には、コアチームの他に、ガバナンス、セキュリティ、データベース、コンプライアンス等の管理者、法務、事業戦略部門etc...

## 第5章　具現化させる　＜インセプションデッキのHow部分＞
### 5.1 技術的な解決策
* 採用する技術やアーキテクチャを決定する。
* **期待のマネジメント**ができ、すれ違い防ぐことが可能である。
* 想定している**プロジェクトの境界とスコープが見える化**される。
* リスクを伝えられる。
* チームメンバーを選んだ時点でアーキテクチャを決定している。だからこそ、**技術的な得意分野は早めに表明しておく。**
### 5.2 夜も眠れない問題
* プロジェクトにおける不安点やリスクを洗い出す。
* **リスクについての話し合いは、プロジェクト成功に何が必要かを共有するための大切なプロセスである。**
* リスクを挙げるメリット
* 早い段階で課題を明らかにできる。
* その理屈はおかしいと表明できるチャンスである。
* 気持ちがすっきりする。
* このようなリスクが上がっている場合、危険度は高い。
* チームが同じ職場にいない
* 顧客を巻き込めていない。
* 自分の開発環境をコントロールできない。
* その他、プロジェクト成功に必要なものが足りない。
* 顧客も含めてブレインストーミングを行い、解決に取り組む価値のあるリスクと無いリスクに分ける。
### 5.3 期間を見極める
* 開発期間がどれだけ必要かを見積もる。
* 開発期間も**小さく考える**のが基本。
* 実例：ランディ・モットは、有名企業を渡り歩き、数々の実績を手にした。その実績に共通する秘訣は、**開発期間が6ヶ月を超えない**ことであった。
* ゴールが定まっていない大規模プロジェクトでは、要件が次から次へと舞い込み、やがて破綻する。**6ヶ月以上は危険すぎる。**
* 期限に集中しすぎて、インセプションデッキの課題の目的を見失わないようにする。
* プロダクトの長さのマネジメント
* 期日を軸に日付を調節する。
* 期日に幅（バッファー）を持たせる。
### 5.4トレードオフ・スライダー
* 予算・時間・品質・スコープ等の優先順位を確定させる。
* 予**算・時間・品質・スコープ**の4つがこの章では**四天王**とされるが、中でも**スコープはその他の3つを固定したうえで柔軟に調整可能である。**
* スコープを柔軟にする際は、**顧客にスコープの要望は諦めてもらう場合があるということに納得させる必要がある。**
* タスクが横並びになるような、**同率順位の設定は禁止**である。
* また、一言では表せない「**捉えどころのないもの**」についても、順位を決定づける。
### 5.5何がどれだけ必要か
* 人材・期間・コストなど、必要なリソースをまとめる。
* まずはどんなチームが必要かをまとめる。チームには名前を付けておくのが望ましい。
* 続いてチーム内の役割をまとめる。中でも **「顧客」は重要要素** であり、顧客の役割が文化として根付いていない多くの企業に対して、じっくりと説明する。**顧客自身が「覚悟」を持つ必要がある。**
* 次に、**最終判断を下すのは誰か**を明確にする。誰が決断するか分からなければまずい。後々の混乱を防ぐためにも、最終判断を下す人を予め決定し、ステークホルダーに示さなければならない。
* 次に、コスト面の見積もりである。
* **概算予算＝人数×月間の時間当たりコスト**
* 最後に、期限とコストのまとめスライドを仕上げる。
* いつ完了するか
* いくらかかるのか
* 重要なのは、**この時点での100%コミットは不可能だ**という事である。顧客やステークホルダーに説明の上、了承してもらう必要がある。

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