アジャイル開発の「ア」くらいを勉強してみた

最近アジャイル開発に関わる機会がありました。 やり始めて感じましたが、アジャイル開発は、一般的なウォータフォールとは考え方の根本的な部分から違います。 これが腹落ちせずに開発に加わると間違いなく失敗します。

今回は、

• アジャイル開発とはなにか
• どうやって進めるのか

について勉強したので、その覚書です。

参考にさせていただいたのはこちらです。

アジャイルサムライ−達人開発者への道−

アジャイルな見積りと計画づくり ~価値あるソフトウェアを育てる概念と技法~

アジャイル開発とは

wikipediaによるとアジャイル開発の定義はこうなっています。

アジャイルソフトウェア開発 (アジャイルソフトウェアかいはつ、英: agile software development) は、ソフトウェア工学において迅速かつ適応的にソフトウェア開発を行う軽量な開発手法群の総称である。

ざっくり言えば、

アジャイル開発とは、プロダクトオーナー（クライアント、顧客）にとっての価値を最大化することを目的とした開発手法

です。 とは言うものの、アジャイルで開発したからと言って、ウォータフォールより良いプロダクトを作れる保証はありませんが。

特徴としては、アジャイル開発では成果物としての仕様書は基本的にありません。 そのかわり、顧客と成果物に対する満足度を確認するために頻繁にフィードバックをもらうようになります。 ウォーターフォールと比較するともう少しわかりやすいです。

	ウォーターフォール	アジャイル
ゴール	プロジェクト立ち上げ当初作成した要求仕様を忠実に実装	プロジェクトが生み出すプロダクトを最大化するように実装
重視する観点	仕様書通りのプロダクトを作り上げること	プロダクトオーナーにとって価値あるプロダクトをリリースし続けること
期間	長期	短期（〜６ヶ月）
前提とする不安	スケジュール不安	マーケット不安
戦略	初期計画の精度を高める	実験的に徐々に精度を高める
変化	弱い	強い
アプローチ	理性主義	経験主義
開発規模	比較的大きめ	比較的小さめ（諸説ある）
顧客が成果物を確認するタイミング	プロダクトを納品するとき	イテレーションごと
個人的な印象	仕様書に書いてあることは絶対正義	プロダクトオーナーは絶対正義

（参考） www.nec-solutioninnovators.co.jp

アジャイル開発において、開発工程は「このようにしなさい」といった決まりごとは特にありません。 あるのは、「こんな風に進めるとうまくいくかもしれない」程度の目安くらいです。 アジャイル開発は「プロダクトオーナーにとって価値あるプロダクトを提供するための思想」がベースにあり、そのための方法論はざっくりと提唱されているものの、実際にどうやって進めるかといった細かいところはチームに任されている開発手法だと言えます。

アジャイル開発の進め方

アジャイル開発の一般的な流れはこんな感じです。

上図のように、企画とイテレーションしか工程はありません。 ウォーターフォールのように、要件定義して基本設計して外部設計して…のような段取りは取りません。 そのかわり、イテレーションの中で対象となる機能に関して設計・実装・テストのすべてを実施します。

企画

一番始めに計画を立てます。 これは、開発にはどうしても契約が必要になり、契約を結ぶためにはどんな物を作り、プロジェクトをどう進めていくかをクライアントに示さなくてはなりません。

どんなものを作るかを定める際に、ウォーターフォールでは基本設計をしますが、アジャイル開発ではもっとざっくりユーザーストーリーを定めます。

プロダクトのユーザーが、プロダクトを使って価値を享受するために実施するであろう内容を洗い出します。 これによって、どのように実装するかはさておき、プロダクトによってどんなものが可能になるかというプロダクトのかちが判明します。 洗い出された各項目がストーリーと呼ばれ、これらをすべて実現することが開発のゴールになります。

ストーリーが洗い出せたら、次は計画を作成します。 計画と言っても、ここでいう計画はストーリーの規模の見積もりとその優先順位を考えます。 規模の見積もりについてはプラニングポーカーという手法が紹介されていました。

各ストーリーについて、参加者全員で開発規模をポイントで見積もります。 ポイントで見積もる理由は、期間や予算ではなく他のストーリーとの相対的な規模を代替で見積もれればいいため、独自の尺度を導入します。 ポイントとしては、よくフィボナッチ数列が使用され、フィボナッチ数列の値からポイントを選択します。 そして、そのポイントをメンバー間で議論し、最終的なストーリーを決定します。

ストーリーの規模を見積もることで、それらを総合することで開発全体としてどれだけの規模になるかを推定します。 そのポイントでの見積もりをもとに、チームの開発スキルからイテレーションごとに何ポイントを消化できるか推定し、期間を算出していきます。 またストーリーには優先順位が存在し、それらを明確にして優先順位の高いものから実装に取り掛かるように計画します。

忘れてはいけないのが、アジャイル開発ではフィーチャも計画も、必要に応じて柔軟に見直します。 場合によってはどうしても必要な機能があとから判明するかもしれませんし、予算が削減されて泣く泣く開発のスコープが縮小されるかもしれません。 全てはプロダクトオーナーにとっての価値が最大化するためにやっているのですから、この変化が発生することが十分にありうるということは大きな特徴となります。

イテレーション

イテレーションでは、1〜2週間の間にいくつかの機能を実装します。 各イテレーションの終了時には、仮にそこでプロジェクトを打ち切られても実装した機能に関してすべて問題なく動作するようにします。 そのため、各イテレーションの中では、設計・実装・テストの工程をすべて実施します。 また、各イテレーションで実装する機能はプロダクトオーナーにとって価値が高いと判断した機能から順番に実装していきます。

イテレーションを進めていくと、だんだん当初の規模の見積もりとの乖離に気づくことができます。

残ストーリーポイントを縦軸、イテレーション数を横軸に撮ったグラフをバーンダウンチャートと読んだりしますが、これによって開発チームが一回のイテレーションでどれだけのストーリーポイントを消化できるかを実働をもとに把握する事ができます。 上の図では、当初イテレーションが７で完了すると見込んでいましたが、実際には９必要になりそうだということがだんだんわかってきます。 アジャイル開発では、これを許容しスコープを小さくしたり、納期を延ばしたり、人員を増員したりして柔軟に対応します。

アジャイル開発のポイント

クライアントへのプロダクトが最優先

アジャイル開発は「プロダクトオーナーにとって価値あるプロダクトを提供するための思想」がベースにあり、実際にどうやって進めるかといった細かいところはチームに任されている開発手法でした。 根っこにある思想は、プロダクトオーナーに対して提供するプロダクトを最優先だということです。 プロダクト自体に比べれば設計書の価値は低いと判断されれば設計書の作成を排除し、以下に納品間近であってもプロダクトオーナーが必要と判断すれば機能を追加します。

ここでポイントになってくるのは、実装のトレードオフです。 新しいストーリーが加わったらその分別のストーリーは諦めないといけません。 すべてを実現するには、人員を増加させるか納期を延長する必要があることをプロダクトオーナーに説明する必要があり、予算を増加させることができれば問題ありません。 しかし、多くの場合にはそれは簡単ではなく、実際にはスコープを調整します。 その苦しい判断を下すのは、プロダクトオーナーだということを理解し、堂々と交渉してください。 できないものはできないのですから。

あらゆる見積もりは不正確である

プロジェクトでは必ず計画を立てることが求められます。

ウォーターフォール型の開発では、一般的に予算や開発期間の見積もりを出します。 そして、その見積もりはだいたい外れます。 納期をオーバーしたり、納期に間に合わせるために人員を調達したりして、なんとかやりくりします。 こうして、予定より予算がオーバーしたり、タダ働きによってまかなったりします。

開発の時期と見積もりの誤差の関係はだいたいこんな感じです。

開発初期には、見積もりの２倍程度の誤差が予想され、逆に納品直前にはほぼ正確な見積もりを出すことができます。 プロジェクトではなにが起こるかなんて事前にわかりませんし、ある程度プロジェクトを進めていくと「だんだんこんな感じ」というさじ加減がつかめてきます。

アジャイル開発では、基本的に正確に見積もりを行うことを諦めています。 契約を結ぶ関係で見積もりを出す必要はもちろんありますが、その正確性については保証しません。 これは正確な見積もりを出そうとするためにかけた労力に対して、その制度が比例しないためです。

プロジェクトを進めていく中で、見積もりが間違っていることに気づいたら適宜修正し、見積もりのずれに対して納期を変更するか実装する機能を調整します。

こうすることで、予算の範囲内でチームの能力を最大限に活用して本当に価値のある機能から優先的に実装し、可能な限り価値の高いプロダクトをプロダクトオーナーに提供します。

なにはともあれやったほうがいいこと

アジャイル開発は、実際の進め方はかなり自由度が大きく、使用するツール等は開発チームが自由に選択します。 そうはいうものの、下記の４つは「最低でもこれくらいはやったほうがいい」というレベルで紹介されていました。

ユニットテスト

当たり前ですね。 個々人がプログラミングしているので、合わせてみるまで動くかわからないっていうのはまずいです。 イテレーションではテストまで終わった状態で、プロダクトオーナーにそのままリリースしても問題無いレベルまでテストをして品質を高めてください。

リファクタリング

手を抜きがちなリファクタリングも、きっちりやりましょう。 プロジェクトが進むにつれて、保守性の低いコードはバグを生みやすくなります。 常日頃から、リファクタリングすることを習慣づけて、不必要なバグに悩まされることがなくなるようにしてください。

テスト駆動開発(TDD)

これも忘れがちですが、コードを書き始める前にテストを書いてください。 もっと言えば、そのテストを自動化するようにテストコードを作成してください。 始めのうちは手作業でコードを書いても特に不自由ないですが、プロジェクトが進むに連れてリグレッションテストを簡単に実施するためにも自動化したテストを用意するようにしてください。

継続的インテグレーション

これはなにかというと、バージョン管理をしましょうってことです。 いつ契約を打ち切られても、最新のバージョンでプロダクトをリリースできるように、最善の準備を常日頃からしましょうということです。

感想

アジャイル開発の大まかな流れについて説明しました。 アジャイル開発は「プロダクトオーナーにとって価値あるプロダクトを提供するための思想」がベースにあり、細かいところはチームに任されている開発手法でした。 そして、それを実現させるエンジニアには非常に多くの高いスキルが要求され、個々人が様々なタスクをこなしていく必要があります。 プロダクトに対する思いと、エンジニアのスキルやプライドで成り立つ開発手法だなと感じました。