「納期を半分にしてくれ、金なら出す」

システム開発で、もし顧客から「お金なら出しますから、4カ月のところを2カ月で作ってくれませんか？」と言われたらどうするか？ この状況についての考察を、TISの社内ベンチャー「SonicGarden」代表を勤める倉貫義人氏がブログ「Social Change!」のエントリ「アジャイル開発のボトルネック」に興味深くまとめています。

倉貫氏はアジャイル開発手法を実践してきた人としても知られており、先日まで「日本XPユーザグループ」の会長でもあった人です。考察もアジャイル開発手法の考え方に基づいて展開されています。

まず、品質以外のパラメータが変動可能なら、納期を短くすることも可能か？ について倉貫氏は考察しています。

確かにエンジニアがいるなら、もしくは、集める目処が立つなら、ありがたい話かもしれない。XPでも、「リソース・スコープ・品質・時間」のパラメータで、品質以外は変動可能としている。

ということは、リソースがなんとかなれば、時間を短くする、もしくは、時間を変えずにスコープを増やすことができるのだろうか。

しかし実際には納期を短くするのは難しいだろうとしています。なぜなら、開発の速度にかかわるボトルネックは開発だけにあるわけではないからです。

冒頭の台詞は、開発側にこそボトルネックがあり、コストさえかければスピードアップできると考えているから出る発言だろう。

ではどこにボトルネックがあるのでしょうか？

コストをかければ、完成が速くなるのか？「仕様」が完全に固まっており、発注側による「検収」を含まない、ということであれば可能かもしれない。しかし、「仕様」が完全に固まっていることって本当にある訳がないし、きちんと「検収」されていない状態を完成とは呼ばない。

倉貫氏は、仕様が固まっているかどうか、検収可能かどうかがポイントだと指摘しています。そしてアジャイル開発を前提にした場合、何度も短い期間ごとに繰り返し顧客と仕様についての打ち合わせが必要となります。

繰り返しながら、「仕様」を決め「開発」をし「検収」していくとしたら、開発する速度と同等の速度で、仕様を決めていかねばならないし、作られたソフトウェアの確認をしていかなければならない。そう考えたら、かなりの時間を発注側が割かねばならないはずである。おそらく、開発と同等かそれ以上のコスト（工数）がかかるのではないか。

コストを負担するのは開発側だけでなく、仕様を決める発注側にも相当のコスト負担が必要だ、ということです。倉貫氏はこうまとめています。

つまり、発注側のかけるコスト（工数）の限界が、ソフトウェア開発における速度の限界点なのだ。プロジェクトが成功するかどうかの分水嶺と言える。

倉貫氏の考察は、Publickeyで先日公開したエントリ「システムの納期とは確率分布だ」で紹介したアジャイル開発手法の1つであるRUPの創始者ウォーカー・ロイス氏が展開した論に重なります。

ロイス氏は、システム開発には不確実性がつきものであり、それをいかに管理していくかが大事だと話しました。

ロイス氏はそのリスクを管理するための考え方として、「スコープは要求文書ではなく、交渉の連続です」ということと「計画は規定ではなく、進化し、変化する目標です」という2つを挙げていましたが、これは顧客と開発者が協力してスコープを決めていくこと、計画を話し合っていくことを意味しているはずです。

顧客の要求に沿うものを限られた納期で実現するためには、キーボードに向かって作業するのと同様に、顧客に向かい合って作業することも大事であるという点で、両者は一致しています。開発側がそれを理解したとして、ではそのことをどう顧客に理解してもらうのか、この点がこれを実現しようとしたときのいちばん大きな壁になるのでしょう。