アジャイルサムライ

第1章 ざっくりわかるアジャイル開発

「価値ある成果を毎週必ず届ける」

大きな問題は小さくする

本当に大事なことに集中して、それ以外のことは忘れる

ちゃんと動くソフトウェアを届ける

もっと早く、もっとこまめに。もっとたくさんテストする

フィードバックを求める

必要とあらば進路を変える

現実ではなく計画を変える

成果責任を果たす

仕事の質に責任を持つ

スケジュールを守る

お客さんの期待をマネジメントする

身銭を切る覚悟でお客さんの資金を扱う

アジャイル開発の原則

顧客満足を最優先し、価値のあるソフトウェアを早く継続的に提供します。

アジャイルな計画の立て方

ユーザーストーリーに顧客（プロダクトオーナー）が優先順位をつけて、開発チームが見積もる

開発チームがベロシティを実測

現実が計画にそぐわなくなったら、計画を変える

用語

ToDoリストのこと

タスクのこと

対象のソフトウェアで顧客が実現したいフィーチャ（ユーザーから見た価値・機能）の概要

サイクルを回す期間

1〜2週間

1回のイテレーションで完了させられるストーリーの量

顧客に隠し立てをせず、誠実に仕事を進めるのがアジャイル

顧客が十分な情報を得た上で、スコープ、予算、期日について判断する

「完了」とは、フィーチャを届けること

リリース可能な状態にすること

アジャイル開発の原則

動くソフトウェアこそが進捗の最も重要な尺度です。

3つの真実を受け入れよう

プロジェクトの開始時点にすべての要求を集めることはできない

要求とは発見されるもの

集めたところで、要求はどれも必ずといっていいほど変わる

変化を受け入れ、必要に応じて計画を変更しつつ前へ進もう

やるべきことはいつだって、与えられた時間と資金よりも多い

優先順位の高いものからこなしていくしかない

やり方がたった1つなんてことはない

自分の頭で考えるのをやめない

第2章 チーム

典型的なアジャイルチームはどんな姿をしているのか

自分のチームをどう編成すればいいか

チームにメンバーとして参加するにあたり、どんな心構えで仕事に臨めばいいのか

アジャイルプロジェクトの特徴

役割分担がはっきり分かれていない

プロジェクトの成功に寄与することなら何だって協力する

肩書きも役割も関係ない

開発工程が連続的

分析、設計、実装、テストなどすべての工程が独立していない

チームが一丸となって成果責任を果たす

チームをアジャイルにするためのコツ

同じ仕事場で働く

顧客に積極的に参加してもらう

「これから2週間で何かしらお客さまの課題を解決します」と宣言する

少しずつ信頼貯金を増やすところから始めよう

アジャイル開発の原則

ビジネス側の人と開発者は、プロジェクトを通して日々一緒に働かなければなりません。

自己組織化

チームとして最善の成果をお客さんに届けられるよう、各人のスキルを活かしながら力を合わせる

自分たちのプロジェクトだという当事者意識を持つ

指示待ちではだめ

アジャイル開発の原則

最良のアーキテクチャ・要求・設計は、自己組織的なチームから生み出されます。

意欲に満ちた人々を集めてプロジェクトを構成します。環境と支援を与え仕事が無事終わるまで彼らを信頼します。

アジャイルチームの役割分担

顧客（何を作るかを決める）

顧客をじかに開発へ巻き込めば巻き込むほど、プロダクトはよくなっていく

開発チーム（どうやって作るかを決める）

職能横断的なメンバーで構成

メンバーは複数の帽子（役割）をかぶらなければいけない

プロジェクトを始めるときにこんな質問をしてみたらどうだろう

自分は何が得意なのか？

自分はどういうふうに仕事をするか？

自分が大切に思う価値は何か？

チームメンバーは自分にどんな成果を期待できるか？

アジャイルチームに向いている人

ゼネラリスト

いろんな帽子をかぶる必要がある

曖昧な状況に抵抗がない人

我を張らないチームプレイヤー

人と分かちあうことをためらわず、お互いに学びあって成長することを心から楽しめるような人

第3章

プロジェクトを始める前に必要なこと

ゴールやビジョン、プロジェクトの状況や背景についてチームでよく話し合っておくこと

ステークホルダーに情報を提供すること

「しかるべき人をみんな同じ部屋に集めて、プロジェクトにまつわる適切な質問をすれば、自分たちのプロジェクトに対する期待を共有して、認識を合わせることができるはずだ」

作成に参加するのにふさわしいのは誰か？プロジェクトに直接関係する人なら誰にでも資格がある

作成期間：数日〜2週間程度

第4章 「なぜ」

1. 我われはなぜここにいるのか？

自分自身が現場で確かめる

「司令官の意図」をつかむ

短く簡潔にするのは難しく時間がかかる

3. パッケージデザインを作る

フィーチャそのものではなく、フィーチャの効能をアピールする

開発チームと顧客が一緒になってブレインストーミングする

キャッチコピーを決める

パッケージをデザイン（制限時間15分）

4. やらないことリストを作る

何をやるのかと同じくらい、何をやらないかが重要

やる、やらない、あとで決める（図P64）

5. 「ご近所さん」を探せ

プロジェクトコミュニティは考えているよりも常に大きい

チーム全員でブレインストーミング

会社に長く在籍しているメンバーがいると助かる

第5章 「どうやって」

6. 解決案を描く

アーキテクチャの図を描いて共有する

フレームワークを使う場合は採用できるか検討する

7. 夜も眠れなくなるような問題は何だろう？

リスクを話し合うのは良いこと

次の条件に当てはまるプロジェクトはうまくいかない

チームが同じ仕事場にいない

顧客を巻き込めない

自分の開発環境をコントロールできない

その他、必要だと思うものが何かしら揃っていない

プロジェクトの開始時点というまだ余裕のある段階で、率直に話し合っておいた方がいい

ブレインストーミングでリスクを洗い出す

取り組む値打ちのあるリスクとそうでないものに分類する

願わくばわたしに、変えることのできない物事を受け入れる落ち着きと、変えることのできる物事を変える勇気と、その違いを常に見分ける知恵とをさずけたまえ

8. 期間を見極める

プロジェクトの期間は短い方がいい

6ヶ月以内が望ましい

自分たちの見積もりを踏まえて、ステークホルダー向けに大まかな計画を立てる

お客さんにコミットメントだと思われちゃいけない

9. 何を諦めるのかをはっきりさせる

フォース四天王

時間

タイムボックス

固定する

予算

固定する

品質

固定する。常に高い水準を保ち続けなければなない

スコープ

柔軟に扱う

トレードオフ・スライダー

顧客に、四天王の優先順位をつけてもらう

「捉えどころのないもの」を忘れるな

トレードオフ・スライダーで目に見えるようにしておく

10. 何がどれだけ必要なのか（期間・費用）

「顧客」の役割をきちんと認識してもらう

バスの運転手（最終決定権者）をはっきりさせておく

プロジェクトで一番お金がかかるのは人件費

メンバー数に時間あたりのコストを掛ける

ただし100%コミットメントはできない

最初のリリース（図P92）

自分だったらどんな提案を見たいか

プロジェクトの最初に手ごわい質問をすること

プロジェクトが始まる前に関係者の方向性を揃える

第6章

文書化は難しく、うまく機能することがない

誤解を招きやすい

アジャイル開発の原則

情報を伝えるもっとも効率的で効果的な方法はフェイス・トゥ・フェイスで話をすることです。

アジャイルサムライは「要件」を信じない

用語として間違っている

必須条件でも必須でもないものが多い

インデックスカードに、フィーチャの本質を捉えたキーワードを書く

技術擁護を避け、顧客にとっての価値を書く

エンドツーエンドになる

独立している

交渉の余地があるようにする

テストできる

小さい、見積もれる

誰の　＜ユーザーの種類＞として

何を　＜達成したいゴール＞をしたい

なぜ　なぜなら＜理由＞だからだ

ストーリー収集ワークショップ

フィーチャを幅広く集める

小さくて具体的なエンドツーエンドの機能にする（1〜5日で実装できるサイズ）

顧客の要求を書き出す時間よりも、顧客と要求について話し合う時間をもっと増やすべき

真の狙いを見失わない

文書化を目的にしてはいけない

第7章

見積もりは当てずっぽう

最大で4倍の誤差があるかもしれない

前もって正確に見積もるなんて無理

アジャイルサムライが採用する手法

日にちではなくポイントで見積もる

見積もりの数値と営業日を対応させないようにするため

数値の単位に意味を持たせず、ただ相対的な大きさを表す

（営業日は絶対的な大きさを持ってしまう）

「理想日」で見積もる流派もある

見積もり技法

三角測量

基準のストーリーを決めて相対サイズで見積もる

見当がつかないストーリーがあったら、スパイク

見積もれる程度にさまざまな調査を実施（長くても数日以内）

プランニングポーカー

まず開発チームのメンバーが各自見積もる

みんなで見せ合って、相違があれば話し合う

再度見積もる…のサイクルを繰り返す

数字は1と3、ときどき5があれば十分

第8章

4つの基準

顧客にとって価値ある成果を届けられる計画

わかりやすくありのままを伝える、誠実な計画

約束したことを守り続けられる計画

必要に応じて変更できる計画

アジャイルな計画づくりとは、チームの開発速度を計測して、その速度をもとにプロジェクトの完了時期を見通せるようにすること

イテレーション数 = 作業量の合計 / チームの予想ベロシティ

ただし、実現可能性は未知数

やるべきことが多すぎる事態に直面したら？

やることを減らす

最初に立てた計画にこだわらず、計画のほうを変える

スコープを調整する

新しいストーリーを追加するときは、必ず既存のストーリーを一つ削除する

アジャイル開発の原則

要求の変更はたとえ開発の後期であっても歓迎します。変化を味方につけることによって、お客様の競争力を引き上げます。

計画づくり

計画の土台

顧客が優先順位をつけて、開発チームが見積もる

長さは、1ヶ月〜6ヶ月程度の期間でこなせるぐらい

6ヶ月後の状況なんかわからない

リリース

お客さんにとって意味のある単位でストーリーをまとめたもの

リリースの単位

MMF (Minimal Marketable Feature Set)

Minimal：最小であること

Marketable：市場価値があること

アジャイル開発の原則

シンプルさ（ムダなく作れる量を最大限にすること）が本質です。

2. プロジェクトの規模・期間を見極める

3. 優先順位をつける

一番重要なストーリーから実装していく

4. チームのベロシティを見積もる

個人の生産性を計測するのではない

最初は推測するしかない

イテレーションを3〜4回こなせば落ち着いてくる

最初の見積もりは控えめに

5. 期日を仮極めする

期日固定

スコープで調整

フィーチャセット固定

期日で調整

スコープも柔軟にしておく

縦軸：残っている作業の総量（ポイント）

横軸：時間（イテレーション）

イテレーションごとの残作業量を記録していく

プロジェクトの状況を可視化できる

どれだけ仕事を完了させたのか

どれだけ仕事が残っているのか

チームのベロシティ

いつ頃すべてを完了させられそうか

バーンアップチャート

プロジェクトを途中からアジャイルにすることはできる

現場で実践する

お客さんが新しい要求を発見したら

期日を延ばす？スコープで調整する？

決断するのはお客さん

中立的な立場で話をし、決断に必要な情報を提供する

思っていたほどは速く進んでいないとき

開発速度が上がらないという事実について話し合う

お客さんに選択肢を持たせる

悪い知らせは早めに伝えるのがアジャイル開発の流儀

隠し立てすることなく誠実な態度で臨むのが最善の戦略

第9章

アジャイルなイテレーション

期間を固定したタイムボックス（1〜2週間）

アジャイルプロジェクトで具体的に成果をあげていくためのエンジン

通常、イテレーションの途中では作業対象のストーリーを変更しない

1. 分析と設計

「分析」は、必要な分だけを、必要なときに

「ここまでやればいい」という絶対的な基準はない

プロジェクトやチームによって異なる

必要なときとは、実装の1つ前のイテレーション

フローチャート

ペルソナ

ユーザーを役割ごとに簡単に説明したり、典型的な姿として描いたりしたもの

具体的に解決したい課題を抱えている

デザイン

ペーパープロトタイプ

テスト条件を書き出す

お客さんにどんどん聞く

2. 開発・作業

ペアプログラミングの効果

ちゃんと動くソフトウェア

自動化されたテストを書く

設計を継続的に発展させていき、改善し続ける

ちゃんと動くソフトウェアであり続けるために、コードを継続的にインテグレーションする

顧客がシステムについて語る言葉に合わせてコードを書く

イテレーション・ゼロ

開発の段取り

バージョン管理セットアップ

ビルドの自動化

コードの共同所有

チームがコードを所有する

3. テスト

いつでも受入テストできるようにすること

トヨタが開発した情報伝達システム

組立てラインでのパーツ補充の工程を調整する仕組み

WIP にできる数に上限がある

後回しにした作業には優先順位をつける

イテレーションが不要

運用など

「アジャイルである」とは、チームの役に立つことなら何でもやるということ

第10章

アジャイルプロジェクトに欠かせない取り組み

期待をマネジメントすること

フィードバックを得ること

顧客と定期的に顔を合わせてプロジェクトの現状をレビューしてもらう習慣をつけたい

イテレーションごとに4つのミーティングを定期的に開催することを習慣づける

今回のイテレーションの作業に備える（ストーリー計画ミーティング）

ジャストインタイム分析の結果を確認する

分析を終えていないストーリーに着手しない

今回のイテレーションのフィードバックを得る（ショーケース）

今回のイテレーションで実装したストーリーを本物のコードでデモする

直接操作してもらって本物のフィードバックを得る

次回のイテレーション計画を立てる（イテレーション計画ミーティング）

開発チームと顧客が一緒になって、次回のイテレーションの作業を計画する

チームのベロシティ確認、次に取りかかるストーリー整理

プロジェクトの健康状態を確認するのにもふさわしいタイミング（快晴・曇り時々雨・激しい嵐）

厄介な問題について話し合う

バーンダウンチャートを使うと、プロジェクト完了への現実的な見通しがわかる

悪いニュースは早めに

建設的にフィードバックする方法

「だけど」を避ける

次回のイテレーションで改善できる余地を探す（ミニふりかえり）

10〜15分の短くて集中したミーティング

すごくうまくいったことや、もっとうまくやるためにどうすればいいかを話し合う

一番大切なルールは、みんなが安心できる雰囲気を作ること

ふりかえり最優先条項

どんな問題が出てきたとしても、私たちは次のことを納得し、それを心から信じます。

チームメンバーそれぞれは、その当時わかっていたこと、備えていた自分自身のスキルと能力、手に入れることのできたリソース、そして現場の状況に応じて、自分の力が及ぶ限りの全力を尽くしたのです。

1. うまくやれたことは？

褒める

2. どうすればもっとうまくやれるか？

アジャイル開発の原則

チームがもっと効率を高めることができるかを定期的に振り返り、それに基づいて自分たちのやり方を最適に調整します。

デイリースタンドアップ

正式な会議として開催するものではない

毎日自主的に集まって話し合う

5〜10分、立ったままでやる

自分の作業の最新状況を報告、チームメンバーに知っておいてもらいたいことがあれば共有する

大抵のアジャイル手法の解説書では以下のことを一人ひとり伝える

昨日やったこと

今日やること

チームの開発速度を下げてしまうことがあればなんでも

こんな感じにしてみたら？

昨日、世界をどう変えたのか

今日は何をぶちかますつもりか

不運にも自分の行く手を阻んでしまったばかりに、あえなく吹き飛ばされるさだめとなった難問がどんな末路をたどるのか

毎日、チームのみんなに「今日、私はこれをやります」とコミットメントを表明しよう

自分でもびっくりするぐらいに実際に仕事をやり遂げられるようになっていく

やり方はひとつじゃない

価値につながらないものがあったらやめてしまおう

失敗を受け入れ、その教訓をチームメンバーと分かちあい、前へ進んでいく

第11章

現場の状況を目に見えるようにする

ビジュアルワークスペース

左側に完了した（リリース可能な）ユーザーストーリー、右側にこれから開発するストーリーを並べる

現在のイテレーションで取り組んでいるフィーチャ（ユーザーストーリー）の状態（図P223）

貼りものの真価は、取り組む物事をはっきりさせること、実際に仕事を進めていくこと、取り組む仕事に集中することを支援することにある

貼りものの作り方

出勤すれば誰でも、次に何をすべきかがすぐにわかる

チームのボトルネックが見えるようになる

現場にいる誰にでもプロジェクトの状況が一目瞭然になる

なぜこのチームがここで仕事をしているのかを、常に意識できる

チームの意思を明確にする

チームの約束（Working Agreements）

「私たちはチームとしてこうやって作業したい」という宣言を文字にしたもの

チームが大事にすること（Shared Values）

趣旨は「チームの約束」と同じだが、もっと感覚的な表現

プロジェクトで使う言葉を共有する

業務で使われる用語の意味を明確に定義してソフトウェアに反映させる

バグを監視する

毎回のイテレーションの10％の時間をバグをつぶすことにあててもいい

バグを見つけたら、その場ですぐに潰す

第12章

アジャイルなソフトウェアエンジニアリングにおいて問答無用で実践すべきプラクティス

ユニットテスト

ユニットテスト

バグを修正する前に、失敗するテストを書く（バグを再現させる）

ユニットテストの粒度はメソッドレベル

開発者がソフトウェアを変更するたびに書く

テストコードはプロダクトコードには含めない

テストコードをたくさん書くメリット

素早いフィードバックが得られる

デバッグ時間を大幅に削減できる

自信を持ってデプロイできる

「危なっかしい所をすべてテストする」

エクストリーム・プログラミングのマントラ

技術的負債（スパゲティコード、重複、手抜きなど）

一つひとつは小さく無害に思えても、時とともに累積していった結果が甚大な被害をもたらす

こまめに返済していく仕組みが必要

ソフトウェアの整合性を保ちながら、設計を少しずつ改善していける手法

外部からみたソフトウェア全体の振る舞いを変えることなく、少しずつ継続的に設計を改善していく手順の総称

コードの意図をつかみやすくしたり、変更がしやすくなるように設計を改善する

コードを書くことは、いい文章を書くことによく似ている

良いメソッド名や変数名を選ぶ

アジャイル開発の原則

技術的卓越性と優れた設計に対する不断の注意が機敏さを高めます。

どんどんリファクタリングすることを続ける

ソフトウェア開発の仕事で一番大変なのは、きれいな設計を保ち続けること

変数やメソッドの名前変更

変数のインライン化

メソッドの抽出

労力とコストに見合うか確信を持てないとき

プロジェクトの終了は近いか？

少しずつやれないか？

テストを先に書く

1. レッド：新しいコードを書く前に、まずは失敗するユニットテストを書く

2. グリーン：テストに成功するコードを書く

3. リファクタリング：実装を見直す。重複・無駄の除去。できる限り明瞭でわかりやすいコードにする

1. 失敗するテストをひとつ書くまでは、新しいコードを一切書かない

2. 「危なっかしい所」をすべてテストする

プロダクトコードがすでに存在しているかのように考えてテストコードを書く

テストコードもリファクタリング対象

常にリリースに備える

「ソフトウェアは開発している時間よりも、本番環境で動いている時間のほうが圧倒的に長い」

ビルド時間は短く

10分以内が望ましい

小さなプロジェクトなら5分以内

セットアップに必要なもの

ソースコードリポジトリ

チェックイン手順

ビルドの自動化

作業単位を小さくしようとする姿勢

アジャイルなチームのチェックイン手順

1. 最新のソースコードを取得する

2. 変更を加える

3. テストを実行する

4. 作業中に発生した更新差分を取得する

5. 再度テストを実行する

6. チェックイン

ビルドを大事に

ビルドを自動化する

統合の頻度が高いほど容易に統合できる

早めに、こまめにマージする

「アジャイルチェックリスト」は誰にも作れない

アジャイル開発は旅そのものであって、目的地じゃない

大切なのは、素晴らしいプロダクトを作ることと、それをお客さんにちゃんと届けること

「もうやり残したことはないし、何もかもわかった」と思ったその瞬間、アジャイルじゃなくなる

「アジャイルの道」に沿っているかどうか確認する2つの問い

毎週、価値ある成果を届けられているか？

たゆまぬ改善のための努力を惜しまず続けているか？