アジャイル開発とは｜ビジネスサイドのための IT 用語集

 アジャイル開発とは開発対象を当初からすべて決めきらず、数週間ごとに動作する部分を構築して確認を重ねるソフトウェア開発の考え方です。確認の結果に基づいて、次に開発するものや優先順位を再決定していきます。スクラムなどの個別の手法をまとめて呼ぶ総称です。
対になるのはウォーターフォールで、要件定義・設計・開発・テストを一度ずつ順に遂行し、当初確定した仕様のとおり完成させる進め方を指します。
店でいえば小規模に開店し、売れ筋を見ながら棚を入れ替えていく出店に近いです。開店前に品ぞろえをすべて決めることはしません。
 なぜ生まれたか1990年代までの業務システム開発では、最初に分厚い仕様書を作成し、その仕様どおりに開発して納品することが一般的でした。ところが完成までに1年以上かかる開発では、使い始める頃には事業の状況や現場の要望が変化しています。仕様の変更には追加の見積もりと契約の変更が必要でした。そのため利用されない機能が残存し、必要な機能が後回しになりやすくなっていました。
この反省から策定されたのがアジャイルソフトウェア開発宣言です。宣言は計画や文書の価値を認めたうえで、計画に従うことより変化への対応を、網羅的な文書より動くソフトウェアを重視するとしています。
 効果数週間ごとに動作するものを確認できるため、開発中のものと期待とのずれを早期に把握できる。進み具合も書類の進捗率ではなく、実際にどこまで動作するかで確認できる
価値の高い機能から開発するので、予算や期間が途中で尽きても利用できる部分は完成済みになる
市場の反応や業務の変化に合わせて、開発する機能を途中で変更できる
早期に一部をリリースでき、売上や業務改善の効果が表れる時期を前倒しにできる
 コストとリスク発注側にも優先順位を決定する担当者と、定期的に成果を確認する時間が必要になる。この手間は開発期間中ずっと続く
最初に総額と完成形を確定できないため、社内の予算承認や稟議の手順を変更しなければならない場合がある
開発しながら仕様を変更する前提なので、自動テストやリリースの自動化といった技術的な仕組みが不十分だと、変更を重ねるたびに品質が低下し、開発も遅くなる。提案の段階で、自動テストをどこまで整備するか、リリースをどう自動化するかが計画に含まれているかを確認する。この仕組みを維持する費用は導入後の保守でもかかり続ける
仕様書を一括で作成しないため、担当者が交代すると経緯を追いにくくなる。最低限の記録を保持する運用を定めておかないと、保守を別の会社へ引き継ぐときに支障が出る
優先順位を決めきれないまま見直しを続けると、範囲が膨らみ続けて完了しない
自律して行動できる開発チームと、発注側の担当者を育成する必要があり、どちらも短期間では整わない
 よくある誤解 アジャイルにすれば速く安く開発できる開発する量が同じなら、手間の大幅な減少は期待しにくいです。短い間隔で確認するための会議やテストの自動化に手間がかかる分、かえって手間が増加することもあります。速くなるのは価値の低い機能を開発せずに済む場合と、手戻りを早期に発見できる場合に限られます。全機能を確実に完成させることが目的なら、総額を最初に見積もりにくくなります。
 アジャイルでは計画も文書も作成しない計画は作成し、短い間隔で再作成します。文書も保守や引き継ぎに必要なものは保持します。宣言が重視しないとしたのは網羅のための文書で、文書全般ではありません。
 アジャイルと呼んでいれば進め方もアジャイルになっているアジャイルという名前だけが広まり、中身が伴わない進め方も多くあります。進行中の案件では数週間ごとの成果の確認で発注側の担当者が次に開発するものと優先順位を再検討しているかを確認すれば判別できます。確認の結果として今の計画のままでよいと決定するのも再検討の1つで、計画が変更されないこと自体は問題ではありません。問題は確認の場で変更したい点が生じても、契約や社内の承認の都合で最初の計画を変更できない状態です。これは最初に確定した計画を短い期間に区切って遂行しているだけです。