アジャイル開発の最も優れた点は、プロジェクト中の仕様変更に対する柔軟性です。そのためこの開発手法に注目している企業も増えてきており、中には「アジャイルでやりましょう」とクライアントの方から提案してくることもあるほどです。

しかし、アジャイルはその手法自体の難易度の高さが問題です。クライアントとの認識にズレがあると、非常に厳しいプロジェクトになることもあるでしょう。

今回は、アジャイル開発を始めるにあたり気を付けるべきポイントについて、解説していきます。

納期に対する正しい理解があるか

アジャイルでは最初に全体の設計をするのではなく、1機能ずつ作っていきます。そのため仕様変更が起こっても、比較的に容易に対応できますが、それを「いくらでも仕様変更を要求できる」と勘違いしているクライアントは少なくありません。

仕様変更をすれば、当然それに対する開発の工数がかかります。あまりに仕様変更が多ければ、他の機能の開発が遅れ、最初に想定していた納期に間に合わなくなる箇所も出てくることでしょう。
ですが、それこそがアジャイルの特徴です。

期日までに必要な最小限の機能だけを担保し、それ以外の間に合わなかった機能は、リリース後の追加案件として請け負う、それがアジャイルの正しい形です。

クライアントにはまずそのことを伝え、仕様変更に備えたバッファを組む必要があることを確認、調整しなければなりません。

設計書は最低限しか作成しない

ウォーターフォールでの開発では、「設計書の作成　⇒　コーディング」という流れをセオリーとしています。

それぞれの工程を長い期間で取り組むため、メンバーの入れ替わりも前提として考えておかなければなりません。設計者と製造者が違うことも多く、そういった事態のために詳細設計書が必要なのです。

しかしアジャイルでは短いサイクルで開発を行っていくため、設計者と製造者が異なるケースはほとんどありません。つまり基本設計書さえあれば、詳細設計書は不要なのです。

クライアントによっては「納品物として詳細設計書が必須だ」と考えているところもありますが、仕様変更を容認する性質上、詳細設計書を納品物にしてしまうと、整備にとんでもない工数がかかってしまいます。

これを改善できないのであれば、アジャイルでの開発は避けた方が無難でしょう。

短すぎるサイクルは避ける

機能ごとの設計から開発、テストまでの工程を「サイクル」と呼びますが、その期間が短すぎる場合、トラブルの際に対応できなくなります。

例えば急に風邪で欠員が出たケースについて、1週間と1ヶ月のサイクルでは、どれほど影響に違いが出るか見てみましょう。

・1週間サイクルの場合
営業日5日 － 病欠1日 ＝ 実働4日（20%の損失）

・1ヶ月サイクルの場合
営業日20日 － 病欠1日 ＝ 実働19日（5%の損失）

この例を見て分かる通り、1週間のサイクルでは、例え1日休んだだけでもスケジュールには大打撃です。これを避けるためには、サイクルの単位は出来れば1ヶ月、最低でも2週間は欲しいところですね。

短すぎるサイクルを提案された場合は、これらの例を挙げ、無理のないスケジュールを組むようにしてください。

結合テストのスケジュールが別途必要

機能ごとに開発していくアジャイルは、単体テストの連続になります。

そのため結合テスト、システムテストには、相応の期間が必要になります。この点のみ「コーディング ⇒ 試験」という、ウォーターフォールと同じ流れでのスケジュールになるため、クライアントも担当者も必要工数を見誤りがちです。

結合テストの結果、大幅に手直しが入る可能性を考え、なるべく余裕を持たせるようにしましょう。

最大の弱点は、経験者の少なさ

ここまで挙げた例を見て分かる通り、アジャイルは優れた開発モデルではあるものの、難易度が非常に高い手法となっています。

そのため運用にはある程度の慣れが必要ですが、日本ではまだまだアジャイルの経験者が少ないのが現状です。

もしクライアントにアジャイルを提案された場合は、経験が少ないこと、予想されるリスクが多いことを余すところなく挙げ、本当にアジャイルが相応しいかを考えてみるべきです。