仕様凍結後の変更依頼で悩める日々に光を。システム発注責任者にお勧めの本。

本の内容

ソフトウェアやシステムの受託開発は難しい。
まだ形のないものについて、発注者も受注者も合意しなければならないから。当然、出来上がるものは作る人の仕様解釈が反映されるから、発注者の意向にぴったり沿う可能性は低い。また意向に沿っていたところで、発注者自身でも使い始めてみなければ分からないことは沢山ある。その時に改変しようとしてもまた多くの費用がかかる。

だから契約形態を変えよう。
ミニマムの機能で使い始めて、永続的にアジャイル開発し続ける形にしよう。

つまり「納品」のない受託開発をしよう。

という話。

ではどう活かせるか

おっしゃることは、ごもっとも。
そりゃ、確かにそういう契約ができるならそのほうがいい。

ただしこのやり方、著者も書いているように万能じゃない。
著者の会社でやっているのは

・Amazon Web Serviceをサーバーとして使う
・Webベースのシステム

の場合だけ。
しかも、毎週の開発会議に決定権者が出席できるほど小規模な会社の話。
他システムとのややこしい連携とかもなさそうだし。

…はっきり言って、参考にならない！

仕様固めや、手戻りが頻発して大変なのは、
・決裁権者が会議には出てこないような大きな組織
・予算どりや資産計上の関係で
「決めたものを決めた期間までに作る」契約にせざるをえない
からなんですけど！

ただ、そういう僕も、
納品後に継続的に改修する契約は2件ほど結んだことがある。
これ、ほんとすごく良い。
開発ボリュームの上限を決めている契約だから顧客の側も改修の優先度を考えて要望を絞るし、
受ける側もなるべく良い改修をして欲しいからいろいろ提案する。
結果、顧客との関係も良好になる。

だからチャンスがあればこういう契約にしようと、いつも狙ってはいるけど、結果は7年でたったの2件だ。
こういうやり方があるんだ！と知るだけでは「納品のない受託開発」はできない。

ただ、そんなことは著者もよく分かっているだろう。
分かった上で、それでもこのやり方を広めようと本を書いた。
なぜだろう？

思うに、発注者側にこのやり方を知らしめたかったからじゃないだろうか。
そうだとすれば、受注者側として読んでも全く物足りないこの内容は納得がいく。

だけど惜しいことに、このタイトルでは…
読んでみようと思うのは受注者側ばかりだろうな。

第二弾は、受注者目線でのノウハウ公開に期待したいところ。

きっと本当はノウハウに凄みがあるのだろうと思う。
どうやって「納品のない契約形態」で契約してもらうか。
ドキュメントがなくて、本当に問題ないのか。
人員は本当に確保できるのか。

などなど。
期待して待つことにします。