アジャイルサムライを読んでみたので、大事だなと思った内容をまとめる。

大雑把にいうと『アジャイル開発のやり方』を具体的に学べる。いくつか読んだアジャイル本(SCRUM BOOT CAMP THE BOOK, いちばんやさしいアジャイル開発の教本)の中で、一番具体的な進め方を詳細に書いている本だと感じた。

プロジェクトがダメになる理由

基本的に、関係者全員でプロジェクトについて話し合う前にプロジェクトが始まってしまうことが問題。それにより、認識違いなどを引き起こす。

よって、そうならないために次のことが大事。

やること	理由
ゴールやビジョン、プロジェクトの状況、背景についてチームでよく話し合う	チームが状況に応じて適切な判断を下せるようにしたい
ステークホルダーに情報を提供する	ステークホルダーはプロジェクトを続けるかの判断材料が必要

これを実現するためには、色々と関係者で議論する必要がある。その際に使える手法に、インセプションデッキがある。これは、10の手強い質問と課題に答えるというもの。

インセプションデッキ

インセプションデッキ概要

インセプションデッキは次の10個からなり、前半5つはプロジェクトの『WHY』を把握し、後半5つで『How』を考える。

我々はなぜここにいるのか？

下記を明確にする。

何のためにチームを組むのか？
顧客は誰か？
プロジェクトが始まった理由は？

エレベーターピッチ

30秒以内に2センテンスでプロジェクトをアピールするとしたら、何を伝えるべきかを考える。これを行うと次の恩恵を得られる。

明確になる

プロダクトが具体的に何で、誰のものかがはっきりする
チーム意識を顧客に向けさせる

プロダクトの強み、顧客が対価を支払う理由がはっきりする
核心を捉える

本当に重要なことが何かが明らかになり、優先順位をつけるときに役立つ

エレベーターピッチのテンプレート

[潜在的なニーズを満たしたり、抱えている課題を解決したり]したい

[対象顧客]向けの

[プロダクト名]というプロダクトは、

[プロダクトのカテゴリー]である。

これは[重要な利点、対価に見合う説得力のある理由]ができ、

[代替手段の最右翼]とは違って、

[差別化の決定的な特徴]が備わっている

ちなみに、エレベーターピッチの由来は、『エレベーターに乗っている短い時間で投資家にプロダクトをPRし、資金援助を獲得する』というところから来ており、ごく短い時間でアイデアの本質を伝えるという意味になる。

パッケージデザイン

雑誌のページに、プロダクトやサービスの広告が載るとしたら、どんな内容が良いか？また、その広告を見た人は、プロダクトは買いたくなるのかを考える。

次ようなステップを踏むと良い。

プロダクトの効能をブレインストーミングする
キャッチコピーを決める
パッケージをデザインする

やらないことリスト

プロジェクトで実現したいことが明確であるのと同じくらいに、やらなくていいことを一覧化する。それにより、プロジェクトの何がスコープ内で、何がスコープ外なのかが一目瞭然になる。

「ご近所さん」を探せ

「プロジェクト関係者」を広く集めて、繋がりを作る。チーム全員でブレインストーミングを行い、やりとりが必要な相手を洗い出す。理由は、後々面倒になることを避けるため。

解決案を描く

チーム全員の認識が揃っていることを確認するために、概要レベルのアーキテクチャ設計図を描く。

ここでやることは次の3つ。

どんな風にシステムを構築しようとしているかを図で伝える
どこにリスクがあるかを明確にする
みんながその解決策に同意していることを確認する

チームの開発者が集まって、今回のプロジェクトではどんな風に作るかを相談する。オープンソースやフレームワークで使いたいものがあれば、この時点で採用できるかを検討しておく。

夜も眠れない問題

プロジェクトで起きうる問題、心配事を話し合う。最悪の事態を避けられる、被害を最小限に食い止められる方法があるか？

ここでもチームでブレインストーミングを行い、プロジェクトで起こりそうなあらゆるリスクを洗い出す。例えば、インセプションデッキ中に感じた『これはちょっとおかしいんじゃないか』というような違和感など。

リスクを先に洗い出しておく利点は次の通り。

プロジェクトの課題を早い段階で明らかにできる
「いや、その理屈はおかしい」を表明するチャンス
単純に気持ちがスッキリする（不安感情を共有することで、チームの結束力も高まる。）

期間を見極める

どれくらいの期間が必要なプロジェクトなのか？

正確に期日を見積もるのは、やっぱり難しい。選択肢として次の2つがある。

期日を軸にして、そこに収まるようにフィーチャーを調整していく
中核をなすフィーチャーを届けることにはコミットメントするが、期日については幅を持たせる

何を諦めるのか

プロジェクトで操作可能な要素（スコープ、予算、時間、品質）で譲れないもの、譲ることもやむないものを決める。

どんなプロジェクトでも、スコープ、予算、時間、品質は固く結びついており、全てを優先するということはできない。よって、プロジェクトを進める上で何を優先させるかをはっきりさせておく。

そこで使えるのが、トレードオフ・スライダーというツールがある。下記のように、顧客と一緒に何を優先させるかを、あらかじめ合意をとっておく。

何がどれだけ必要か

期間、コスト、どんなチームなら達成できるかを話す。

ステークホルダーからすると、結局のところ次の回答が欲しい。

いつ完了するか？
いくら掛かるのか？

ただ、期日や開発チームの仕事のスピード、金額などの様々な数値について、現時点では100％のコミットメントはできない（結局のところ、当てずっぽうなので）。よって、インセプションデッキの内容で全体のプロジェクトの規模などを見せた上で、大体このくらいになりそうということを提示する。

ユーザーストーリー

ウォーターフォール型などでは、要求を捉える手段として要件定義書や仕様書を作るが、結局のところ、そうした文書を作ったところで、文書での伝達には限界がある（誤解を生むし、重厚なものは読んでくれなかったり）。つまり、ものすごい時間とエネルギーを文書化にかけている。（『何を成し遂げたいのか？』ということではなく、『何を文書に書くか』に注力してしまっている）

ユーザーストーリーとは

従来のやり方での課題から、アジャイルでは『文書に頼りすぎてはいけない』ということを教訓とし、次のような何かが必要だとしている。

お客さんが欲しいと思っていることの本質を捉えるようにしたもの
計画を立てるときに何のためだったかを理解できるくらいには詳細なもの

上記のようなことを満たすために考えられたのがユーザーストーリー。ユーザーストーリーは、顧客がソフトウェアで実現したいと思っているフィーチャーを簡潔に記述したもの。

ユーザーストーリーのポイント

ユーザーストーリーは、インデックスカードを使って、フィーチャーの本質を捉えるキーワードを書き出す。よって、ありとあらゆる要求を聞き出すことが目的ではない。

なぜ本質以外の要求を聞き出さないかというと、そういった事柄は後になっていらなくなることが多いため、本当に必要になるという時までは、放っておく。そうすることで無駄なことにエネルギーを割かなくて良くなる。

また、よく書けているユーザストーリーは次の特徴を持つ。

顧客にとって何かしら価値が書かれている
エンドツーエンドになっている（ケーキを切った時のように、それだけでお客さんにとって価値がある）
独立している
交渉の余地がある
テストできる
小さい、見積もれる

少し細く書きたい時のテンプレート

ユーザーストーリーは、適切な言葉で簡潔に書かれていれば、チーム全員が思い出せるのでそれでOK。例えば、『ログインする』とか。

ただ、もう少しストーリーの前提となる状況をはっきりしたいときには、次のようなテンプレートが使える。

<ユーザの種類>として
<達成したいゴール>をしたい
なぜなら<理由>だからだ

上記のように書くことで、『誰が・何を・なぜ』ということを明らかにできる。ただ、ユーザーストーリーの記述としては、少し長くなるので、ユーザストーリーを分析するという時などに使ってみるのも良い。

ストーリー収集ワークショップを開催する

アジャイル開発では、プロジェクト計画時に顧客が求めるフィーチャーリストが必要。そのフィーチャーリストを作るための作戦として、ストーリー収集ワークショップがある。このワークショップでは、開発チームと顧客が一緒になって、開発対象のユーザーストーリーを書く。

ワークショップのステップは次のようなものがある。

大きくて見通しの良い部屋を用意

図をたくさん書く(※荒い粒度にとどめる)

次のような図が使える。

目的	図の名称
ユーザを理解する	・ペルソナ
システムが動作するのに必要な把握する	・フローチャート・シナリオ
仕事の構造を整理する	・システム概要図・プロセスフロー
実際にどんな感じかをイメージできる	・コンセプトデザイン・絵コンテ・ペーバープロトタイプ
違った観点の何か	・独自に考えた何か

ユーザーストーリーをたくさん書く（エンドツーエンドの機能にする）
その他もろもろをブレインストーミングする
リストを書き上げる

見積もり技法

端的に『概算見積もりなんて当てずっぽう』であるのは頭に置いておく。その通りだと思う。

そうはいっても、プロジェクトの予算や成果を期待できるかの見通しを立てないといけない。そこでアジャイルでは、次を踏まえて計画を立てる。

ストーリーそれぞれを互いに相対的なサイズで見積もる
ポイントを基にして進捗を追跡する

相対サイズで見積もる

ポイントで見積もる

アジャイルでは、見積もりの単位として『ポイント』を採用している。時間にしてしまうと、見積もり時の再調整が多くなり、いつまでも終わらなくなってしまうからだ。使用するポイントの値は、ストーリー間の違いを明確にするために、フィボナッチ数列（とはいっても、1,3,5,8くらいで収まるように）のようなものが好ましい。

見積もり技法①：三角測量

代表的なストーリーをいくつか基準として選出し、残りのストーリーを基準となるストーリーとの相対サイズで見積もる。

基準となるストーリーを選出する観点は次のもの。

論理的なグループ分けができそうなものがあるか
エンドツーエンドになっているストーリーはあるか
プロジェクトを象徴するような代表的なストーリーはどれか

見積もり技法②：プランニングポーカー

各ストーリーに対して、開発チームのメンバーそれぞれで当該ストーリーのポイントを見積もる。開発チーム全員の考えが見える化され、その段階でチームで話し合えることで、より適切に見積もれるようになる。

アジャイルな計画づくり（初回の計画作り）

初回の計画作りは次のステップからなる。

マスターストーリーリストを作り、リリース（意味のある単位でストーリをまとめたもの）を定義する
プロジェクト規模を見極める
優先順位をつける
チームのベロシティを見積もる
期日を仮決めする

期日固定もしくはフィーチャー固定にするかの戦略を立てる

上記の方法で、大体計画を作ることができ、スマートに運用するためには、計画の進捗状況を効率よく確認できた方が良い。その方法にバーンダウンチャート（顧客のストーリーをどれくらいの速度で焼き尽くせるか）がある。バーンダウンチャートでは、次の項目が可視化される。

どれだけ仕事を完了させたか
どれだけ仕事が残っているか
チームのベロシティ
いつ頃全てを完了させられそうか

具体的には、下記のような感じ。

他にも、バーンアップチャートや、バーンアップチャートとバーンダウンチャートを組み合わせたようなものもある。

イテレーションを運営する

イテレーションでは、価値ある成果を毎回アウトプットする必要がある。そのやり方は、次のようにステップをこなす。

分析と設計：作業の段取りをする

今から１ヶ月こと先のことなんてわからないので、ユーザーストーリーを実装するタイミングが近づいてきてから着手する。具体的な分析のタイミングは、イテレーション中に次のイテレーション。

『ストーリーを分析して、具体的に何をアウトプットするの？』については、システムの動作や必要な手順をシンプルに表現したい場合は、フローチャートなどが使える。ストーリーごとにどんな示し方がいいかを決めて分析する。

分析が終わったら、テスト条件（このストーリーが完成したことを確認できそうなこと）を書いていく。
開発：実際に作業する

分析したストーリーからリリース可能なソフトウェアを実装する。ここでやることは次のもの。
1. 自動化されたテストを書く
2. 設計を継続的に発展させ、改善し続ける
3. ちゃんと動くソフトウェアであり続けるために、継続的にコードをインテグレーションする
4. 顧客がシステムについて語る言葉に合わせてコードを書く
また、具体的なストーリー実装に入る前に、イテレーションゼロ（開発準備期間）期間を設け、次のことを済ませておく。
- ソースコード管理
- ビルド自動化
- 開発環境やテスト環境
- （アーキテクチャスパイク）
テスト：作業結果の確認をする

イテレーションのたびにテストは実施する。もちろんリリース前の受け入れテストも必ず実施する。理由は、顧客が本気になってテストを確認するのは、最終的な受け入れテストのスケジュールが近づいてきた時のため。