名著「アジャイルサムライ」を読んだ気になる1ページ
プログラマが読むべき本に必ず名前が上がる「アジャイルサムライ」をまだ読んでいない人に向けた、読んだ気になるまとめです。
書籍情報
書名「アジャイルサムライ - 達人開発者への道」
著者 Jonathan Rasmusson
1. アジャイル開発とは？
第一章「アジャイル」入門 〜アジャイル開発とは〜
アジャイル開発とは
アジャイル開発とは、「価値ある成果を毎週届ける」ことを大切にする。つまり、毎週テスト済みの動くプロダクトを顧客に見せること。
アジャイルでは、ウォーターフォール型と異なり、「分析（要件定義）」・「設計」・「実装」・「テスト」工程が連続的に取り組まれる。
そのために、必要なことは以下6つ。
1. 大きな問題を小さく分解する。
例：大きな問題「ウェブサイトの構築」
小さい課題「トップページ」「ユーザアカウント」「ブログ」「利用規約」…etc
2. 大事なことに集中すること。
すべてに対してドキュメントを必ず作らなければいけないわけではない。重要な課題、つまり顧客に成果を届けることに対して集中すること。
3. ちゃんと動くソフトウェアを届けること
「ちゃんと動く」とは、テスト済みの機能の事を指す。設計・開発・テストを回した機能を顧客に届ける。
4. フィードバックをもとめること
顧客に対して積極的なプロジェクトへの関わりを求めなければいけない。それはつまり、届けたソフトウェアに対してフィードバックを行うこと。プロジェクト終了直前の正式な受入試験で必死になってフィードバックを行われ時間に追われて実装をした経験があるだろうか。アジャイル開発では毎週成果を届けてフィードバックをもらう。軌道修正が早期に行えるのだ。
5. 進路を必要であれば変えること（プロジェクトは万物流転と心得る。）
当初の計画を守ることは絶対ではない。状況の変化に応じて柔軟に進め方も変える必要がある。
3つの真実を受け入れる
プロジェクトを経験した人なら必ず共感できてかつ二度と同じことを繰り返したくない3つのことについてプロジェクトの真実として受け入れることが出発点になる。
- プロジェクト開始時点にすべての要求を集めることはできない。
- 集めたところで、要求はどれも必ずといっていいほど変わる。
- やるべきことはいつだって、与えられた時間と資金よりも多い。
第二章 アジャイルチームのご紹介
アジャイルチームの特徴を解説している。
アジャイルチームは各人に明確な役割があるわけではない。それぞれが得意な分野を発揮して職能横断型に動いてチームとしてプロジェクトの成功に対して責任を果たしていく。
また、品質に責任をもつのは品質保証部門ではなくチーム自身。チームに所属する全員が確かな品質を達成する。
アジャイルチームにするコツ
1. 同じ職場で働く
意思疎通がしやすくなり信頼関係も築きやすい。
2. 積極的に深く関わる顧客
開発チームの質問に対して答えフィードバックを与えてくれる存在。助言・見識を提供し魅力的なプロダクトを作れるようにするのは顧客の仕事だ。
顧客に積極的に関わってもらうためには、継続的に成果を届け問題を解決できるチームであると思ってもらう。信頼貯金を増やして関係性を気づいていく。
顧客を巻き込むほどプロダクトはよくなっていく
自己組織的
目標を達成するために一歩下がって客観的に考えるチーム。
自己組織的なチームになるためには、以下を推奨している。
1. 自分たちで計画・見積もりを行うこと。当事者意識が生まれる。
2. 自分から動ける人を探す、他の誰かの指示を待つような人はチームにふさわしくない。
職能横断型チーム
顧客の要望に最初から最後まで応えられる開発チームのことを指す。
メンバーを探すには幅広い作業をこなすことを厭わないゼネラリストが望ましい。
プログラマなら、フロントエンド・バックエンド等技術全般に明るい人が候補になるし、
テスター・アナリスト（要求定義）なら、テストと要求定義を同じようにこなせる人物がいい。
また、曖昧な状況に抵抗がない人が望ましい。アジャイルプロジェクトでは、予め何もかもがしっかりきっちり整っていることはないから。
チームメンバーの相互理解に有用な4つの質問
1. 自分は何が得意なのか？
2. どういうふうに仕事をするか？
3. 大切に思う価値は何か？
4. チームメンバーは自分にどのような成果を期待してると思うか？
2. アジャイルな方向付け
第三章 みんなをバスにのせる
プロジェクトメンバーを同じ目標に対して向けるにはどうするべきか？アジャイルサムライは「インセプションデッキ」を推奨している。
「インセプションデッキ」は10のプロジェクトに対して手強い質問を投げかける。それに対してチームで一つの回答を作ることで一つの共通認識に対して開発メンバーを向けることに繋がる。
インセプションデッキの10の手強い質問
1. 我々はなぜここにいるのか？
2. エレベーターピッチ
3. パッケージデザイン
4. やらないことリスト
5. 「ご近所さん」を探せ
6. 解決案を描く
7. 夜も眠れない問題
8. 期間を見極める
9. 何を諦めるのか
10. 何がどれだけ必要か
これは最初に作って終わりではなく変更があるたびに修正をして最新にアップデートして全員が認識するものになる。
第四章 「全体像をつかむ」
第四章と第五章はインセプションデッキについての詳細を解説しています。
1. 我々はなぜここにいるのか？
プロジェクトを成功させたいと思うのであれば、まずは作ろうとしているものの背景にある「なぜ」を掴まなければいけない。理解するために大事なことは２つ、「自分自身で現場を確かめること」・「司令官の意図を把握すること」だ。
「自分自身で現場を確かめること」
自分自身が作ったシステムを利用する人たちと一緒に働いてみる。関係者エリアを見せてもらう。自分自身が顧客となってみる。
「司令官の意図を把握すること」
「司令官の意図」とは、プロジェクトや任務に関する目標や目的を簡潔な言い回しや声明・文書として表現したもの。
2. エレベーターピッチ
ごく短い間にアイデアの本質を伝える手法だが、新規プロジェクトを簡潔に定義する上でも大いに役に立つ。エレベータピッチにより以下が効能として現れる。
* 明快になる。
プロジェクトが何であり、誰のためのものなのか明快になる。
* チームの意識を顧客に向けさせる。
プロダクトは何を提供し、それを提供するのはなぜなのかに意識を向ける。プロダクトの強みとなぜそれに顧客が対価を支払うのか真剣に考える事ができる。
エレベータピッチのテンプレート
・[潜在的なニーズを満たしたり、抱えている課題を解決したり]したい、
・[対象顧客]向けの、
・[プロダクト名]というプロダクトは、
・[プロダクトのカテゴリー]である。
・これは[重要な利点、対価に見合う説得力のある理由]ができ、
[代替手段の最右翼]とは違って、[差別化の決定的な特徴]が備わっている。
例えば、自分が所属しているエスキュービズムという会社のOrangeオムニという製品で作ってみます。
・[一貫した顧客満足度の追求]をしたい、
・[小売業者]向けの、
・[Orangeオムニ]というプロダクトは、
・[オムニチャネルシステム]である。
・これは、[EC（オンラインショップ）・POSシステム（実店舗）を連携して顧客に対するリーチを行うこと]ができ、
・[現行のECシステム・POSシステム]とは違い、[オンラインショップと実店舗を一元データベースで管理する機能]が備わっている。
簡潔に書くのは難しいですね・・・。
3. パッケージデザイン
自分たちのプロダクトのための商品パッケージを作ってみる。そうすることで、「誰がどういう理由で買うのか。」をチームで話し合うきっかけとする。
Step1: プロダクトの効能をブレインストーミング
その製品の機能（フィーチャ）ではなくてプロダクトの効能が実際のお客様のとっての価値になる。それはつまり「そのプロダクトでどれだけ楽になるか。」だ。
Orangeオムニという製品の効能だと以下のような感じだろうか。
1. 在庫情報をリアルタイムで把握できて在庫管理が楽になる。（管理者視点）
2. スマホで欲しい商品を取り置きすることができる。（消費者視点）
3. 欲しい商品の店頭在庫を店に行く前に検索することができる。
///etc
これは、顧客と開発チームが一緒にブレインストーミングすることが望ましい。
4. やらないことリストを作る
やらないことリストを作ることで、何がプロジェクトのスコープ内で、何がスコープ外なのかを明確にする。
それによって開発チームが本当に重要なことだけに集中できるようにする。
- やる（解決すべき問題）
- やらない（今回は気にしない）
- あとで決める（後で「やる」か「やらない」かを決める）
5. 「ご近所さん」を探せ
プロジェクトでよくあることだが、プロジェクトの後半になるにつれて、一度も会ったことがない面々が出てきて要求が肥大化する。そういうプロジェクトの「ご近所さん」はプロジェクトの初期段階から味方につけておいたほうがいい。
言葉で言うのは簡単だがプロジェクトで見落としがちの真実は、プロジェクトコミュニティは考えているより常に大きいということ。誰が最終決定者なのかをプロジェクトコミュニティの大きさを正確に把握することが必要。
第五章 「具体化する」
6. 解決案を描く
システム概要図を描く、図として描くことでツールや技術に抱く期待をマネジメントする。
7. 夜も眠れなくなるような問題は何だろう？
事前にリスクについて話し合っておくことは今後のためになる。見積もりは楽観的すぎないかなど。
8. 期間を見極める
ざっくりとしたタイムラインを引く。
※プロジェクトの長さは期待値となる。ITプロジェクトの守備範囲は6ヶ月以内で6ヶ月以上は危険なプロジェクトと提唱されている。
9. 何を諦めるのか
品質・時間・スコープ・予算すべてに手を回すことはできない。何に対して諦める（優先順位をつける）かを合意を取る必要がある。
10. 何がどれだけ必要か
どれだけのチーム構成・工程・スケジュールが必要なのか具体的な説明をする。
第六章 「ユーザーストーリーを集める」
文書化の難しさ
ソフトウェアプロジェクトでは重厚な文書化を行い要求を捉えるプロセスを行うが実際にそれが有効であったことは少ない。変化への対応が遅れ、「顧客のほしいもの」ではなくただ仕様に合わせて作ることになる。
要件という言葉は「必要条件」なのか
プロジェクトで使用されている「要件」という言葉をアジャイルサムライは批判している。
「要件」という用語は、絶対不変であることや変化を受け入れることを食い止める意味合いを伝えている。
現実、顧客の欲しいものは変わりゆくものだから、プロジェクトにおいて「要件」という用語は誤っているようだ。
アジャイルな要望の集め方：ユーザーストーリー
アジャイルプロジェクトでは、開発チームに小さなインデックスカードを使うことを推奨している。
特徴1：顧客にとっての価値が書かれていること
機能要件だけでなく性能要件も顧客のワクワクする内容にしよう。
（例）
* ユーザーアカウントを作成する。
* 新規投稿がある際にメーリングリストに通知する。
* 現状１０秒かかるページの読み込み速度を2秒まで縮める。
特徴2：エンドツーエンド
ユーザーインターフェース・ビジネスロジック層・永続化層を機能単位でスライスするように切り出す。
特徴3：交渉の余地がある
顧客に対してユーザーストーリーごとにいくら支払うか交渉することができる。
特徴4：テストができる
ユーザーストーリのテストを書くことで開発チームにとって作業範囲・完了基準が明確になる。
特徴5：小さい、見積もれる
1週間・2週間程度のサイズに収まる見積もりができること。（1週間〜2週間の範囲をイテレーションと呼ぶ）
第七章 「見積もり」
概算見積もりなんてあてずっぽう、適当で楽観的。しかし、正確であることを目指さねばならない。
推奨されているのが、相対的な見積り。一つ基準となる機能開発を設定しそれに対する相対工数を計算する。
見積もり技法：三角推量
小・中・大の3種類にユーザーストーリーを分けてそれに対して見積もりポイントを設定する。
（例)
小：1pt ユーザーアカウントを設定する
中：3pt MasterCardを使えるようにする
大：5pt 返品交換と下取りに応じる
上記の例のように3つ例を分けて他のユーザーストーリーも小・中・大に分けて分類していく。
見積もり技法：プランニングポーカー
開発チームでそれぞれ上記のポイントに分けていく。1pt・3pt・5ptでそれぞれの開発チームに分けて話し合う。議論することで正確らしきポイントまで収束させていく。
第八章 アジャイルな計画作り
用語：マスターストーリーリスト
アジャイル開発では処理するべきToDoリスト（ユーザーストーリーリスト）をマスターストーリーリストと呼ぶ。
用語：ベロシティ
チームとしての開発の速さを意味する。
用語：イテレーション
アジャイルプロジェクトで成果をあげていくエンジンになるのが「イテレーション」になる。それは1週間・2週間全力疾走する短距離走のようなものになる。
1イテレーションが2週間だとすると、イテレーション数がリリースまでのスケジュールとなる。例えば、要求が増えマスタストーリーリストが増えた場合どうするか？
スコープを柔軟にしてリストの出し入れをしてリスト数を調整する必要がある。それは顧客に「どのストーリーをリストから外すか。」という厳しい交渉が求められる。
第九章 イテレーションの運営
2週間単位の全力疾走、分析と設計を必要なときに必要な分だけ行い早めにこまめにテストを行う。
そしてテスト済みの成果を顧客に毎週届ける。
イテレーション運営に有用な補佐
- ユーザーストーリー 概要説明・その機能（フィーチャー）で行うタスク・テスト条件を明記する。
- フローチャート システムがどういう動きをするのかを整理することで必要な手順を示すことができる。
- ペルソナ システムを使うユーザーの典型例、システムに人間味をもたせることができる。
イテレーションゼロ
開発が実際に始まる前にやるべきことはある。ソースコード管理の制定、ビルド自動化、開発環境・テスト環境の整備など。
カンバン
期間のあるプロジェクトではない運用・保守のような場合は「カンバン」を使用することが推奨される。
その他（テスト自動化・TDD）
自動化されたテスト、設計の継続的改善、コードのインテグレーション、顧客の語る言葉に合わせたコード
、継続的なリファクタリング、いつでもリリースに備える文化。
本著はアジャイル開発の概要の技術本のための本中にたくさん参考文献が引用されています。
アジャイルな開発には正解がないため自分のプロジェクトに導入するためにどうあるべきかは色々
参考にしてみてください。
参考図書
企画段階
キャズム
エレベーターピッチを書き上げるための参考図書
参考事例の際に引用されていた図書
ザ・トヨタウェイ
トヨタの2004年シエナの設計を北米向けに改善する際にチーフエンジニアが実際にシエナに乗って全米の州をすべて運転したエピソード。自分自身で現場にを確かめることの重要性を説いた。
アイデアのちから
サウスウェスト航空で機内食のメニューにサラダを入れるかについて議論していた際、「最格安航空会社である。」という司令官の意図を照らしてサラダを入れなかったというエピソード。