アートオブアジャイルデベロップメントを読んで
今回は「アートオブアジャイルデベロップメント」と言う本のまとめを書きたいと思います．この本はアジャイル開発と呼ばれる方法の1つであるXP （eXtreme Programming）についてかなり詳しく書いた本です． 僕自身が所属するユーザベースもXPをかなり忠実に再現しています．とはいえ僕はまだ入って3ヶ月の未熟者なのでXPについて勉強する為にこの本を読みました（正確に言うとCTOの方からお勧めして頂きました！）． 読んだ上でどんな人が読むべきかと言いますと
アジャイルについて詳しく知りたい
実際に導入する中でこういうときどうしたらいいの？という困った点がある
人に向いていると思います．いきなりの初心者すぎますと情報量に圧倒されます．．読み方はまずは全体をサーって読んで後から気になるところを詳しく読むという使い方がいいと思います．
まずはそもそもアジャイルって何の為にあるの？ってとこからまとめていきたいと思います．
なぜアジャイルなのか？
アジャイルにおける成功
アジャイル開発とは何か？アジャイルとはある3つの成功を同時に達成するための理念です．その3つの成功を以下に示します．
個人的な成功
- 個人的なやりがい
技術的な成功
- エレガントな設計のプログラム
組織的な成功
- 組織に価値をもたらすこと
プログラマはコードを書くことにやりがいを感じ，開発チームはエレガントな設計をしたいと思う．ただし，組織に価値を持たらなさければソフトウェアに意味はありません．組織に価値をもたらすとはお金を出してくれるユーザに価値が届くことを指しています．アジャイルはこれら3つの成功を同時に達成したいと思う場合に適用すべきだと本書には書かれています． この成功を定義した背景には以前の開発手法での成功が「納期に予算内で仕様通りのソフトウェアが完成する」ことであったからです．これは本当に成功なのか？と言うことで生まれたのが前述の3つの成功とアジャイルという概念だと思います．
アジャイルマニフェスト
そしてアジャイルにおける成功をするにはどうすればいいのか？その規範を示したのがアジャイルマニフェストである．以下にその一部を抜粋します．
プロセスやツールよりも個人と対話を
包括的なドキュメントよりも動くソフトウェアを
契約交渉よりも顧客との協調を
計画に従うことよりも変化への対応を
これらにはプロセスを守ることが正しいのか？本当に届ける価値は何なのか？顧客と自分達は的なのか？，計画は変わるものであると言う思いが込められていると感じます．そしてこれらをより具体化したものにアジャイル原則があります．こちらは割愛しますがこのマニフェストに従い原則を守ることで3つの成功を実現させようと言うのがアジャイルと言う考えです．
XP
アジャイル開発のある1つの手法がXPで，本書でとりあげられているものです．1-20名のチームに適用可能であると記されています．XPは様々なプラクティスで構成されており，これらを実践することで成功へ近づけます． 次節以降でいくつかとりあげて解説しようと思います．
XPのプラクティス
ここからはXPのプラクティスについて説明します．ここで紹介するプラクティスは全て3つの成功を満たすのに繋がっています．さらにお互いに関連があったり，あるプラクティスが前提で成り立つものがあります．この本がプラクティスは全て導入せよと主張しているのはその為です．そしてそう言う視点で本書を読むと理解が深まります． ただその前に登場する役割について説明します．
役割
以下本書に載っている役割を抜粋して紹介します．
顧客
チームが作るソフトウェアを定義する人
プロダクトに関する全ての情報を持つべき人
プロダクトマネージャ
プロダクトのビジョンを維持し，推進する人
市場を良く理解し何が最も重要かを見極めることができる人
ドメインエキスパート
- 特定の業界の専門知識を持つ人
-
- 開発者
テスター
- ソフトウェアの品質に責任を持つ人
プロダクトコーチ
- XPのプラクティスに精通している人
プロジェクトマネージャ
- チームが組織の他のメンバーと仕事をする手助けをする人
-
- エンドユーザや経営陣を指す
この役割を1人兼務することがあります．プロジェクトマネージャやドメインエキスパートが顧客の役割も果たすと言った具合です．
次節以降で具体的にプラクティスについて説明します．
体制に関するプラクティス
活き活きとした仕事場
より生産的に仕事をする為に以下のことを気を付けるべきだと記述されています．
定時に帰るようにしよう
休憩をしっかりととろう
無理に仕事を進めるとバグの原因になってしまって結果的に価値を届けるのが遅くなってしまう． またプロダクトのビジョン（後ほど説明する）を開発者に伝えるようにする．これはプロダクトマネージャの仕事です．そうすることで開発者はやりがいを感じることができまgす．これは個人の成功にもつがります．
情報満載の仕事場
部屋に入るだけでプロジェクトの様子がわかる部屋づくりをしましょう．ホワイトボードに大きく進捗状況を表すチャート（バーダウン・バーンアップなど）を用意しましょう．XPでは変に電子化すべきではないとしています．電子化してしまうとこのように大きく貼り出すことができません．このような仕事場と作ることでいち早く問題に気付き解決することができます．
全員同席
全員同席はXPで最も重要なプラクティスです．これは前述の役割の人が全員同じ場所で仕事をすると言うプラクティスです．開発者全員はもちろんのこと顧客やプロジェクトマネージャもです！大変ですがXPの様々なプラクティスは顧客が同席していると言う前提のプラクティスが複数あります．情報満載の仕事場も皆がバラバラだと実現できません．特に後ほど出てくるプラクティスは顧客が同じ場所にいることが大切です．本当の顧客が同席できなければ顧客と同等の情報量を持つ人を開発者と同席させる必要があります．
なぜここまでやるのか？と言いますと背景にはXPでは開発速度の制約（ボトルネック）を開発者としています．つまり開発者の生産性を高めることが直接開発速度向上に繋がると考えています．開発者の生産性を向上させるには必要な情報を正しく素早く開発者に伝えることが一番であるとこの本では主張しています．よって顧客をも同席させいつでも情報を尋ねることができる状況を作り出しているのです．
信頼
お互いを信頼しあってチームで仕事をすることで，生産性は急上昇し素晴らしいことをすることができます．（XPはマニフェストにもある通り個人と対話を大切にし，顧客との強調も大切にしています） 先ほど述べた全員同席顧客はプログラムの間の信頼を気付く為に最も効果的です！お互いが熱心に仕事をしている姿を見ることができます．
計画に関するプラクティス
ビジョン
ここで言うビジョンとはプロダクトビジョンを示す．プロダクトビジョンとは，プロダクトの方向性を示すものです．作ろうとするソフトウェアやサービスの核です． そしてこのビジョンを明確にしたビジョンステーてメントを書くことが推奨されています．ビジョンステートメントは以下の3つを満たす言葉で書くべきだとされています．
何を達成すべきか
何故価値があるのか
達成の基準は何か
このビジョンをチームに伝えるのがビジョナリーの仕事で，これはプロダクトマネージャがやるべきことです．このビジョンを情報満載の仕事場に記すことでチームメンバーのやりがいにもつながります． そして後に続くリリース計画もこのビジョンに沿って決まっていきます．
リリース計画
リリース計画とはどの順番で顧客に価値を届けていくかの計画である．XPではリリース計画期間の中にイテレーションと呼ばれる期間が複数あります．イテレーションについては後述します． XPでは早期に頻繁にリリースすることを目指しています．それは何故か？と言うのを以下に示します．
収益が高くなる
- 大量の機能を一気にリリースするより，価値ある機能を絞ってリリースする方が最終的な収益が高くなります．同じ機能を2年かけて実装するとき，2年後にリリースする場合は2年間収益が0ですが，3ヶ月ごとにリリースすると3ヶ月目には収益が発生します！
フィードバックが増える
- 頻繁にリリースするとユーザからのフィードバックを細かくもらう事ができます！これは本当の価値を生み出すのに貴重な情報です．また頻繁にリリースすることでXPのチーへのユーザからの信頼度が高まります．
頻繁にリリースするメリットはわかったもののどうやって実現すればいいのでしょうか？このためのプラクティスはいくつも存在するのですが主には以下の方法をとります． - 最小顧客価値に絞る
- XPでは期間を定めて機能を絞ることをします．そして本当に重要な昨日からリリースするので常に最も価値かる状態でリリースすることができます．
常にリリースする状態にしておく
このリリース計画ではまず，ビジョンを明確にし，次のリリースに向けて最小顧客価値を定義します．そしてその機能を実現するストーリーを作成します．そのストーリーを見積もり，チームのベロシティ（開発速度を示す指標）と照らし合わせてリリース計画を作成します（計画ゲーム）．
ストーリー
ストーリーとは顧客価値を表します．例としては「ユーザはツイートを作成できる」などです．この1文がストーリーです．エンジニアが作ることが多いのですが注意としては顧客の言葉で書くことです．何故かと言いますと，次に紹介する計画ゲームで顧客がどのストーリーが価値があるかを判断するためです！エンジニアの〜テーブルを作るって言葉は顧客的には？ってなってしまい価値の優先順位をつけることができません． 実際にプログラマが行うタスクはエンジニアリングタスクと呼びます．複数のエンジニアリングタスクが集まってストーリが構成されるイメージです． プログラマはリリース計画を立てるためにこのストーリーにどのぐらいかかるかを見積もる必要があります．
見積もり
ストーリーをどうやって見積もればいいかを以下に示します．またこのストーリーを見積もるときの単位としてストーリーポイントと言うのを使います．1ストーリーポイントは1日プログラマが邪魔されえずに仕事をした際に消化できるタスクの量です．
ストーリーを実現するエンジニアリングタスクを考える
- 慣れると直感的に見積もれるらしい．．
他のストーリーポイントとの相対ポイントで見積もる
- 似たような仕様の者は同じポイント
この見積もりは1ストーリー1分以内で行うことが推奨される！もし時間がかかってしまう場合はストーリーを見積もるための仕様への理解が足りないか，技術的な情報が足りないということです．仕様への理解が足りない場合は顧客に情報を求めましょう（ここでも全員同席が前提である）．技術的な理解が足りない場合はスパイクストーリーという技術調査のためのストーリーを作りましょう．時間制限をつけて見積もるのに必要な情報をこのスパイクストーリーで集めます．
計画ゲーム
計画ゲームとはストーリの優先順位を決める作業です．開発者は開発コストに関する情報を持っており，顧客はソフトウェアの価値に関する情報を持っています．この2人が協力することでリリースの優先順位を決めていきます．
イテレーション計画
イテレーションとは1-2週間の区切りを指します．以下のような流れで各イテレーションは進んでいきます． 1. 前イテレーションのデモをする 2. 前イテレーションを振り返る． 3. ベロシティーを元にイテレーションで消化するストーリーを決める 4. コミットメントをする 5. 開発をする 6. リリースを準備する
振り返りやデモはXPにおける重要なプラクティスです．振り返ることでプロセスを改善し，デモをすることで顧客の信頼をえることができます．
ベロシティー
ベロシティーとは1イテレーションにおけるストーリー消化ポイント数です．この値を使うことで大体の開発の進捗を見積もることができます．ベロシティが15のチームは150ポイント分のストーリーを消化するのに10イテレーションかかると言った具合です（本書ではリスクを考慮した方法も載っている．）． 何故この方法がうまくいくかと言いますと，開発者の見積もりは当たらないにしても一貫してずれているというデータがあるそうです（10週間で終わる予定が12週間，5週間で終わる予定のものが6週間といった常に20％遅れるなど）．なので実際の1イテレーションにおけるストーリー消化ポイントであるベロシティを使うとある程度正確に見積もれるという訳です． 注意点としはベロシティーが安定するには3-4イテレーションかかります．
開発に関するプラクティス
インクリメンタルな要件
XPでは事前に要件定義が記されたドキュメントを用意しません．そうすることのメリットは以下の通りです．
顧客が要件定義するのと同時に開発することができる
要件定義をインクリメンタルに行うので変化に対応しやすい
ただしこれを実践するには前提条件があります．それは顧客が開発者と同席しておりストーリーに現れない要件をいつでも聴ける状態にあることです．このようの状況でないと開発者は要件がわからないときかなりの時間ロスをしてしまいます．またドキュメントを残さないので仕様が残る場所が普通ではありません．XPではテスト駆動開発を行いテストに仕様を表します．よって全員同席とテスト駆動開発ができてインクリメンタルな要件が実現可能なのです．
ペアプログラミング
ペアプログラミングとは，2人で1つのプログラムを開発する手法です．メリットとしては以下の2つです．
フローになれる
- 割り込みに対して，片方のペアが応答すれば良いので，作業を中断させずに済む
妥協をしなくなる
ペアプログラミングは2人交代で以下の役割を行います．
ナビゲーター
- 全体を考える人
ドライバー
- コードを書く人
ドライバーがコードを書いている間ナビゲーターはそれを見ながら全体の設計やテストの抜け漏れを考えます．そうすることでよりいい設計（シンプルな設計）を目指すことができます．
テスト駆動開発
テスト駆動開発はXPの要の1です．XPが頻繁にリリースする為には設計がシンプルである必要があります（シンプルな設計に関しては次少し触れます）．テスト駆動開発は設計をシンプルに保つことに多いに貢献します．ざっくり言いますとメソッドのインターフェースから考えることができる，テストがあるので安心してリファクタリングできるなどです．またXPがドキュメントを用意せずに済むのもテスト駆動開発のおかげです．以前も解説した記事があるのでこちらをご参照ください．
シンプルな設計
シンプルな設計とは？設計をシンプルに保つことでソフトウェアは開発速度を落とすことなく，どんどん変更が簡単になるはずであり，逆にこういうことが可能な設計はシンプルであるということです（僕も完全に理解はできていません．．）．この本では以下の要素を満たす者がシンプルであるとされています．
You Aren't Gonna Need it
- 将来を予測して無理に抽象化，共通化しない
Once and Only Once
- 重複は避ける
自己ドキュメント化コード
- チームが読みやすいコードを書く（綺麗さではない）
-
- 外部の呼び出しは同じような変換を何度も書くことになるので，アダプターパターンなどを利用しよう．
公開済みインターフェースを制限する
- 一度外部に公開すると，リファクタリングがしずらくなる．
シンプルな設計をすることでインクリメンタルに要件を拡大できますし頻繁にリリースもできます．
リリースに関するプラクティス
完全Done
完全Doneとはプロダクトコードレベルでストーリーが終わったことを指します．つまりテストも揃ってバグもなくリファクタリングも終わった状態です．XPでは完全Doneのものしかリリースしません．無理にベロシティを上げる為にDoneにするのはやってはいけないことです．顧客に無理な期待を抱かせたり，ベロシティが不安定になったりいいことがありません．
継続的インテグレーション
コードを数時間ごとにインテグレーションしようというプラクティスです．そうすることで，バグの早期発見や，バグを探す範囲を限定できます（数時間前は正常に動いていたコードにマージをしたので数時間前と今の差を比べれば良い）．そして常にリリースできる状態になっておりリリースの難易度を下げることができます．そうすることで頻繁にリリースし，顧客により価値を届けることができます！
感想
正直のこの本は中々のボリューム感と情報量でした．．ただ何周か見返すとXPの凄さを感じれる本です．様々なプラクティスが関連しながら3つ成功へ繋がっているというのが段々と見えてきました（まだまだですが．．）．その中でやはり思うのが全員同席とテスト駆動開発の重要性です．XPは顧客までもがチームとして同席することで情報の共有や信頼関係を産み出し，その上で様々なプラクティスが成り立っています．そして技術的な成功や価値を頻繁に届ける為にテスト駆動開発が存在しています．頻繁に届けるやインクリメンタルな要件はテスト駆動開発なしでは難しいでしょう．．また時間をおいて読み返したいと思える本でした．
