アジャイル開発とは
アジャイル開発(agile software development)とは
アジャイルソフトウェア開発宣言について
アジャイル開発は、2001年に『アジャイルソフトウェア開発宣言』が提唱されたことから始まります。
この宣言は、当時のソフトウェア開発に不満を抱いていた17名の開発者が議論し、これからの開発手法のあるべき姿を下記「4つの価値」と「12の原則」にまとめたものになります。
アジャイルソフトウェア開発宣言
要約すると、以下の通りです。
- ビジネス側の人と開発者が一緒の環境で働き、できるかぎり対面で話をする。
- 動くソフトウェアを短い間隔でリリースして、進捗の尺度とする。
- 顧客満足度を最優先として、要求（仕様）の変更を歓迎して顧客の競争力を引き上げる。
アジャイル開発とは
アジャイル開発とは、「アジャイル(Agile) = すばやい」という意味通り、迅速にソフトウェア開発を行いシステムを作り上げる開発手法です。
最初にシステム全体の計画を立てるのではなく、進めながら目標を再設定していくことに重点が置かれ、要求の変化にも柔軟に対応していく開発方法です。
都度都度で、動作するソフトウェアを顧客と共に確認していくことで、顧客が本当に要望しているシステムを完成させていきます。
アジャイルとは
アジャイル開発における「アジャイル」とは、宣言を行うことではありません。
アジャイルとは「する」のではなく「なる」ものです。
良い方向への変化を求め続けて、良く変化した状態になった瞬間が「アジャイルである」と言います。
"Don't just Do Agile, Be Agile"
アジャイル開発の注意点
アジャイルとアジャイルプロセスの違いについて
たまに「アジャイルで開発しています」という言葉を聞くことがありますが、この言葉は厳密には正しくありません。
アジャイルとは、ソフトウェア開発に対する心構えや取り組む態度をあらわした言葉であり、アジャイル開発宣言で具体的な手法は書かれていません。
アジャイル開発を実践している場合には「アジャイルプロセスのスクラム開発やXP開発などを採用して開発しています」というのが正しい表現です。
アジャイルプロセスとは、XPやスクラムに代表されるアジャイルな開発を実践するための「重要なプラクティスを定義して、まとめたもの」です。
このアジャイルプロセスをやみくもに実践しているだけでは、アジャイルなソフトウエア開発はうまく行きません。
アジャイルプロセスの価値と原則を知り、最適なプラクティスを効率的に実践することが大切です。
アジャイル開発はドキュメントを書かないのか？
よく「アジャイルはドキュメントを書かない」という言葉を聞きますが、これは間違いであり、アジャイルプロセスでもドキュメントは書きます。
『アジャイルソフトウェア開発宣言』にもあるように「完全なドキュメントよりも、動くソフトウェア」を優先しているだけです。
最小限の文書化で最大限の効果を狙うように、必要なドキュメントを作成するべきです。
また、「ドキュメントであるかのようなコード」という表現は大抵の場合に幻想です。
ソースコードだけでは「なぜ、その設計にしたのか？」とか「他の設計は検討したのか？」という設計判断の根拠が残せません。
アジャイルプロセスでは、コードとドキュメントの間で上手くバランスをとることが重要です。
アジャイル開発は計画を立てる必要がないのか？
アジャイル開発においても計画は重要です。
例えば、チームの作業量やコストを可視化する目的で、ガントチャートを書くこともあります。
アジャイルソフトウェア開発宣言にある「計画に従うことよりも変化への対応を」という言葉は、柔軟に計画を変更することを推奨しています。
アジャイル開発による作業の成果量を明確化するために、ベロシティを算出します。
ベロシティを安定化させるようにタスク量を調整・計画することはアジャイルプロジェクトにとって大切な要因です。
ベロシティとは
ベロシティとは、チームの生産性の測定単位です。
一定期間における、製造・妥当性確認・受け入れが完了した成果物の量を示します。
ベロシティが安定している場合や、上昇傾向にある場合は、チームが成長している証拠となります。
ベロシティでチームの実力を評価することはできない
ベロシティは予測や作業調整に使うべきであり、評価と切り離す必要があります。
ベロシティの数値でチームを評価してしまうと、チームメンバーは数値を高めるために不適切な見積もりを出したり、無茶な作業量をこなそうとします。
そうなると、ベロシティを算出した意味が失われてしまいます。
ベロシティは適正で安定した数値を出せることが重要であり、ただ数値を高めても全体的な効率や製品品質は高くなりません。
また、ベロシティの数値を他チームと比較して競争することは不適切です。
なぜなら、チームによってストーリーポイントの基準、つまりストーリーポイント1ポイントが示す作業量が異なります。
チームごとに相対的な見積もりも変わってくるため、ベロシティでチームの実力を比較することは不適切です。
アジャイル開発のデメリット
アジャイル開発は、方向性を見失いやすい
アジャイル開発は、柔軟に変更を要求できてしまうため、いつまでも顧客側が最終仕様を決定できないことがあります。
何度も変更要求を繰り返したことで、最初に顧客が欲しかったものとかけ離れてしまうこともあります。
こうなると、システムの全体像をつかみにくい上、プロジェクト全体のスケジュールが読みづらくなります。
実現するべきゴールを顧客と適切に調整することが重要です。
（思いつきで適当な要求ができない仕組みは、未だアジャイルプロセスに存在していないのです・・・。）
形式だけになってしまうと、アジャイル開発は開発担当者への負担を増やしてしまう
例えば、ウォーターフォール型開発を実施していて、そこそこプロジェクトが進んだ段階で顧客から機能変更を要求された場合には、追加費用請求もしくは期間延長請求ができます。
少なくとも一度は合意した事項に対する変更であり、ある意味で顧客の判断ミスで仕様変更が発生しているため、顧客も丁寧な対応をしてくれます。
そのため、開発担当者にとっては、工数的負担はあれど心理的負担はそれほど大きくありません。
しかし、アジャイル開発の場合、顧客側は当然の権利のように仕様破棄や機能追加を要求してきます。
急な仕様変更が発生した場合に、事前に見積もった工数がその通りに実現することは稀です。（というか現実的にはありえません。）
顧客は悪びれもせず、変更が実現するものと考えてしまい、もし実現できなければクレームを挙げるかもしれません。
真の問題は、その仕様変更のしわ寄せはすべて開発担当者にくることです。
もちろん理想論では、機能変更があった場合は別の機能をあきらめるといった工数調整を行うべきです。
しかし現実的には、あらゆるものを開発担当者のスキルと残業時間でまかなうのです。
アジャイル開発は、適切に実施されなければ、開発担当者の心理的負担を増加させて、開発モチベーションを低下させてしまいます。
当然、開発しているソフトウェア・システムの品質も低下します。
本来的にはアジャイル開発は、顧客はもちろん、プロジェクトメンバー全員がメリットを享受できる方法論であるはずです。
もしもアジャイル開発を実施した結果、プロジェクトの管理職だけ気分をよくしているならば、すでに失敗していると認識するべきです。