（INSIGHT NOW!への連載記事と同様の内容です）
私がAgile開発という言葉を耳にしたのは、2010年頃でした。
とあるクライアントからの要望でAgile開発によるシステム導入の管理を行いました。
当初の私の認識としては、スクラップ＆ビルドでブラッシュアップするスパイラルモデルの構築とほぼ同義であろうという程度に考えでした。
しかし、実際には本質的な部分が違うということに、早い段階で気付かされます。
それは、“スコープ”、“工数”、“期間”の考え方が異なるという事です。
一般的なウォーターフォール型の開発の場合、“スコープ”が固定されており、それに対して、“工数”と“期間”を見積もります。
スパイラルモデルに関しても、要件を明確にするためにスパイラルモデルを用いるのであって、あくまで“スコープ”は固定されているという点からすると本質的にはこれと同様だと思います。
しかし、Agileモデルは全く違っていました。
Agileモデルで固定されるのは、あくまで“工数”と“期間”であって、“スコープ”は変動するのです。
この違いというのは、プロジェクトを管理する側の立場としては、非常に大きな違いになりました。
通常のウォーターフォール型の開発であれば、確定したスコープに対してWBSを作成し、スケジュールとコストの見積もるのに対し、
Agile型の開発においては、クライアントの要件が“薪”のように積み上げられており、決まった期間とコストの中で、この薪（=要件）を優先順位の高いものから燃やしていく（=開発する）のです。
よって、プロジェクト管理においては通常用いるWBSのようなものは用いず、薪を燃やす状況を表した“Burn Down Chart”なるものを用いて管理を行います。
“Burn Down Chart”の説明は別の機会に行う事としますが、この管理手法の違いというのは、アサインする要員、会議体、クライアントの関与の仕方、ドキュメンテーション、契約形態などプロジェクト管理の要素に多大なる影響を及ぼします。
ウォーターフォールとAgileの比較
それぞれプロジェクト管理への影響を及ぼす項目を簡単にまとめてみると以下のようになります。
おわかりの通り、外部委託先もクライアント側も、慣れ親しんだウォーターフォール型開発とは
異なるマインドセットおよびスキルが求められるのです。
- 外部委託先…一人一人の生産性が可視化されるため、設計者兼プログラマーとして高いスキルとコミュニケーション能力が求められる
- クライアント…外部委託の感覚を捨て、One Teamとして共に汗をかく事が求められる。また、日々スコープや優先順位に関する意思決定が求められる
そして、中でも複雑な問題は、契約形態です。
極力請負契約にして瑕疵担保をしてほしいクライアント側と、要件が変動するシステムで請負契約は困難と考える
外部委託先の思惑は一致しないのです。
私なりの見解としては、イテレーション*の期間は準委任契約とし、別途設計書などをドキュメンテーションする期間を設け、そこから請負契約に変更するなど、ハイブリッドの契約形態を志向するのが良いのではないかと考えています。
*：Agile開発で用いられる短い期間（通常2週間程度）で反復する開発期間単位のこと
この点に関しては、様々な意見があると思いますが、最終的に請負うための期間とコストを外部委託先に払う事で“保険”を得ると考えるのが良いように思います。
どちらにしても、クライアントと外部委託先の信頼関係が構築されないと、意図せずトラブルに発展する可能性があるので注意が必要です。
初回である今回は、Agile開発の本質についてプロジェクト管理側の観点から考察してみました。
次回は、Agile開発成功のためのポイントについて考えをまとめてみたいと思います。
