はじめに断っておきますが今回の記事は私の持論ではなく、私の会社のS氏が普段主張してる意見を私の言葉で書いたものです。

お客様はアジャイルがお好き

私はWebアプリケーションの構築を生業としていますが、Webアプリケーションの特性上、よく「アジャイルで開発して欲しい」という要望を受けます。顧客もアジャイルの定義を正確に知っているわけではないと思いますが、アジャイルの具体的な手法として XPがあり、XPは短期のリリースサイクルを繰り返すことで顧客の要求を柔軟に吸収できる開発手法であるという理解はあるようです。これは正確な定義とは異なりますが、アジャイルとXPについて概ね正しい理解だと思います。アジャイル開発について詳しくはウィキペディアをご覧下さい。

顧客から「アジャイルで開発して下さい」と頼まれた時の私の切り返しは、「じゃあ見積りもアジャイルでやりましょう」というものです。アジャイルのメリットである短期リリースと柔軟な要求の受領は顧客にとって魅力的ですが、開発側にとってはプロジェクトを失敗させる（可能性のある）大要因の一つです。

そもそも顧客にメリットのあるプラクティスだけをpickupして開発方法論を要求されても困りますが・・

私の知人のS氏がよく主張しているのですが、「開発をアジャイルでやるなら、見積りや契約もアジャイルでやるべきだけど絶対にそうはならない」とのことです。この意見は私に新鮮な衝撃を与えました。確かに開発方法論としてアジャイルを採用した場合、新規の要求や既存機能へのフィードバックは次々に発生するにも関わらず、見積りや契約に関しては、確定後にそれを流動的に変更できることはまずありません。そんなことを主張しようものなら、

• 「そんなことをしては予算が確定しないので無理だ」
• 「それでは会社としての収支計画が立たないので会社から許可が降りない」

などと切り替えされてしまいます。

私も会社の予算を管理する立場にあるのでこの主張をする気持ちは理解できます。

見積りは未だにウォーターフォール

でも考えてみればここ数十年で開発方法論は進化しているのに、見積りや契約の方法論は全くと言っていい程変わっていない気がします。もしかして世界レベルで見ればいろいろと変化しているのかも知れませんが、少なくとも日本では、もっと限定すると私関わってきたプロジェクトでは全く変化していないように見えます。見積りや契約の形態はウォーターフォール一辺倒なのです。（＝一度確定したものが絶対）

以前私は『開発方法論はビジネスモデルとセットで語られるべき』という主張をしましたが、もしかしたら見積りや契約も同じかも知れません。つまり「開発方法論は見積りや契約の方法論とセットで語られるべき」だと思うのです。しかしながら世の中の開発方法論を鑑みると見積りと契約まで踏み込んだものはあまり無く、それらについては別個で研究されているように見えます。

これはおそらく開発方法論を研究している研究者が開発者出身であることに起因しているのだと思います。（あくまで予想です）

S氏は「誰かアジャイル見積りの方法論を確立してくれないかなぁ・・」と言っていました。これには私も同意です。恐らく世界のどこかでそのような学問が行われていると思いますが、まずは現場の第一線で働いている我々が、アジャイル見積りの必要性 を認識する必要があるのではないかと思いました。