2000年以降、「アジャイル開発」という開発スタイルが登場してから、現在でもその有効性が議論されています。従来型の開発手法（主にウォーターフォール開発）と比べて「効率性が高い」とよく言われていますが、実際のところはどうなのでしょうか？
本稿では、アジャイル開発の基礎を従来型開発と比較しながら紹介し、EC担当者に知っていただきたい失敗しないポイントをご紹介します。
アジャイル開発とは
アジャイル開発は、アジャイルソフトウェア開発 とも言われ、ソフトウェア開発を迅速に行うための開発手法の総称です。
アジャイル開発には実際のところいくつかの手法がありますが、いずれも「常に改善している状態」「より良いものを持続的に作っている状態」を目指しています。ただし、これはフワッとした定義なので、頭の隅に入れておく程度で構いません。以下に挙げていくのが、従来型開発と比較した際の明確な定義になります。
Time（時間）とCost（費用）を固定する
プロダクト開発の現場には「Scope（何を作るのか）」「Time（どれくらい時間をかけるのか）」「Cost（いくらお金をかけるのか）」の三原則があります。時間もお金も無限ならばどんなものでも作れますし、脆弱性をゼロにすることだってできます。しかし、現実では何かを優先し、何かを捨てるという選択が付きまわります。
このとき、従来型開発ではまずScopeを固定します。作るものを最初に決めて、それからTimeとCostを考え、プロダクトに合わせてお金と時間を決めていくのです。どんなものづくりにせよ、これが一般的な方法ではないかと思います。
一方、アジャイル開発は最初にTimeとCostを固定します。たとえば「開発リソースを10人、開発期間を2週間」と決めて、その中で「何を作ることができるか？（Scope）」を考えるという、まったく反対の考え方で開発にあたるのです。
見方を変えますと、Scopeが最初に固定しているというのは「途中での要件変更ができない」ことを意味します。実際に従来型開発は途中工程での要件変更が苦手ですし、ちょっとした変更がプロジェクトに与える影響は甚大です。
アジャイル開発はどうかというと、固定しているのはTimeとCostだけなので、プロジェクトの途中でも要件を変更できる強みがあります。「要件変更は往々にして起こるもの」を大前提に置けば、アジャイル開発の有効性は容易に想像できます。
成果物（Scope）と時間（Time）の関係
従来型開発の場合は、ScopeとTimeは変動する関係にあります。成果物を1つの大きな商品として考えるため、それを完成させるためには時間をどれだけ使っても構わない、という考えが根底に存在します。しかし、この思想がプロジェクトに大幅な遅れをもたらすことは、開発関係者なら誰もが知っています。
一方で、アジャイル開発ではTimeが固定されており、それも短い期間が設定されています。一般的には数週間で作れるScopeを定義し、この数週間の開発期間（スプリントなどと呼ばれる）を繰り返し、それぞれのScopeを組み合わせながら最終的な商品を完成させていきます。
こうしたScopeを分割することで、スプリントの最後に問題がないかを確認し、問題が発覚すれば、すぐに対応するなどの行動を起こします。例えば要件の変更や追加用件など、次のスプリントで対応していきます。要するにTimeは固定しながら今までのウォーターフォールモデルと違い、Scopeなどは柔軟に変更可能な状態と言えるのです。
人と開発プロセス
プロダクト開発において、Costはほとんど人件費を指します。そのため、プロジェクトに何人の開発者が関わっているかで判断する場合が大半です。従来型開発の場合、各開発プロセスに応じて開発者を割り当てます。要件定義書を作るために必要な人と時間、設計書を作るために必要な人と時間、コーディングごとに必要な人と時間といった具合に、開発プロセスに人を合わせていきます。
それに対し、アジャイル開発でのチームは固定的です。チームでできる範囲の要件定義/設計/開発/テストを行っていき、一般的には同じチームがすべての工程を完了させます。このため、開発プロセスが変わってもチームは変わらないので、前回プロセスで学んだことをチーム内のスキルやノウハウとして蓄積していき、無駄なドキュメントが不要になるというメリットがあります。
いかがでしょうか？このように従来型開発との比較を行いながら説明すると、アジャイル開発の特徴が浮き彫りになってきます。改めて前述した「常に改善している状態」「より良いものを持続的に作っている状態」という定義を考えてみると、アジャイル開発は「なるほど、PDCAサイクルのような改善フレームワークであり、特定のプロジェクトにおいて絶大な効果を発揮するのだな」ということが分かります。
アジャイル開発で失敗しないポイント
残念ながら、アジャイル開発は取り組めば効果を発揮するような魔法のフレームワークではありません。失敗することも往々にしてありますし、最終的なScopeが明示できないという難点もあり、クライアントからの理解を得づらいこともあります。そこで、ECサイト担当者がアジャイル開発へ取り組むにあたり、失敗しないポイントをご紹介します。
アジャイル開発を「やった気になった」を避ける
多くのアジャイル開発にはルールやセレモニーのようなものがあり、それらを守ることで新しい開発手法を取り入れやすくなることは確かです。しかしながら、それだけでアジャイル開発を「やった気になった」状態になるのが一番危険です。そもそも、アジャイル開発におけるルールなどは原則と理想を示しているに過ぎず、すべてを忠実に実施することは難しいのが現実です。そのため、開発チームごとに原則をもとにしながら独自にルールをセレモニーを作り、自分たちに合ったアジャイル開発を模索することがとても大切です。
「ドキュメントはやはり必要だ」と理解する
アジャイル開発に取り組むと開発チームが固定することから、無駄なドキュメントが不要になると説明しました。これはあくまで「無駄なドキュメント」に限った話であり、ドキュメントそのものが不要になるわけではありません。ところが、「アジャイル開発ではドキュメントが要らない」といったにわかな知識を信じ、開発プロジェクトに取り組んでしまうケースが少なからず存在します。プロダクト開発に対して賢明な方ならば、これが以下に愚かな行為で、後に大きなしっぺ返しを食うかは重々理解していることでしょう。
必要に応じてツールを使い分ける
世の中には「アジャイル開発ツール」なるものも登場しており、チーム単位での開発を支援する機能が提供されています。ただし注意していただきたいのは、「そのツールが自社にマッチするかどうかは、話が別」ということです。アジャイル開発をスムーズに進めていくためには複数のツールを使い分ける必要があるので、チームごとに使いやすいツールを選択し、自分たちだけの開発環境を整えることをおすすめします。
ECサイト構築におけるアジャイル開発
ECサイトは、ある程度の仕様が固まれば、それに向けて開発すれば良いのですが、ビジネスの制約上仕様を固める時間すら惜しいというケースも中にはあります。そのような場合には、最低限の機能を実装して、まずは公開を意識することが重要かもしれません。そして、その後、機能を追加していくようなイメージです。そのようなケースにおいてはアジャイル型が適していると言えます。
ただし、最初に何を作るのか決めないということは、請負契約として完成物の納品を約束することができないということにもつながってきます。請負契約の場合、完成義務が受託者に生じるわけですが、準委任契約の場合その義務がないので納品されない、スケジュール内に完成できなった際のリスクを契約でヘッジ出来ないということになります。もちろん準委任契約であっても善管注意義務は発生するので、あまりにもいい加減でどうにもならないということにはなりませんが、初めてアジャイル開発での発注にチャレンジするという場合においてはこういった契約形態の違いについてもよく理解しておく必要があります。
アジャイル開発に成功すれば、今までにないスピードでプロダクト開発に取り組めることは確実です。本稿でご紹介した内容を参考にしながら、ぜひアジャイル開発に取り組んでみてください。
