発注者側から「なぜ価値創造契約がうまくいかないのか」を考える

永和さんの「価値創造契約」が大苦戦を強いられている件 - GoTheDistance

永和システムマネジメントさんでは、アジャイルらしいシステム受託開発の方式として、ソースコードを納品しないで、利用中も継続課金するという契約方式を試行しておられます。

それが実は苦戦しているそうだということが、永和さんの発表資料から話題になっています。

私もソフトウェア開発を外注することも良くありますが、たしかに発注者の立場からみると、開発中も利用中もずーっと継続課金させるという課金方法で発注するのは、かなりうまくできた仕組みでないと難しいかなと思います。

当たり前ですが、ソフトウェア開発･運用を考えれば、開発フェーズの方がずっと重く、運用フェーズの方がずっと軽いわけです。

ですから、通常の契約では開発フェーズは多くの費用を請求し、運用フェーズでは少ない費用を請求するということになります。それは理にかなったやり方だと思います。

もし納品しない方式であれば、「開発フェーズの金額は受注者が負担し、長期的に回収する方式」なら発注者にはリスク低減メリットがあるでしょう。もしそうではない（稼働時間分を全て請求するor請求金額分しか稼働しない）のなら、単に発注者に対して余計なコストを背負わせているだけということになります。

価値創造契約では、開発フェーズの負担は永和さんが負うように見えますが、その部分をどのような計算で、いくらくらいの開発費や工数を永和さんが負担し、その金額をどのように後日の請求に回していくのか、ということがウェブサイト上では明確ではないように見えます。

経済的に見て、誰がどのように開発費などを負担し、それをどのように償還していくのかということを、きちんと経済学やファイナンスの知見を踏まえて、経営者にとって分かりやすいように説明する必要があるかと思います。

「スモールスタートで」と言うことが書かれていますが、わざわざ支払を繰り延べしてリスク低減する必要があるシステムというのは、スモールスタートよりも社運を賭けた一大プロジェクトのようなものになるのではないでしょうか。

スモールであれば、べつに一括発注でも、普通に人月契約でプログラマを雇って作らせても全く構わんわけですから。失敗すればまたやり直せばよろしなので。

永和さんには、まずファイナンスやミクロ経済学の観点から（リース契約などに習って）契約形態を見直し、ウェブサイトの記述なども見直し、経営者から見てメリットがある形に整理する必要があるかと思います。

もちろん契約書などもかなり入念にレビューして、双方にとって妥当性のあるものにしなければならんでしょうね。

ではでは。

2014/9/19 追記: あと顧客にとって特定の契約形態を押しつけられて売り込まれても何のメリットもないので、プッシュ営業するのは無理だと思いますね。あくまで選択肢の一つという形で提示しておいて、引き合いがあれば提供するという形でないと無理かと思います。