仕様変更をどこまで許容するか

仕様変更をどこまで許すか、というのはソフトウェアの受託開発において永遠のテーマなのではないかと思う。私の浅い経験ではあるが、私の考えを書いてみる。

私が持っているプロジェクトマネジメントの本を開くと次のようなことが書いてある。

ある時点での要求仕様はベースラインとして定義されるべきである。一度ベースラインを定義した後で要求仕様の変更が生じた際は、CCB(Change Control Board)が、仕様変更が及ぼすコストやスケジュールへの影響範囲を評価し、仕様変更を許可するか、拒否するかを判断する。CCBはプロジェクトマネージャーが担当することもあれば、そうでないこともある。一人かもしれないし、複数かもしれない。それは組織やプロジェクトの形態によってさまざまである。しかし、その役割は必ずプロジェクトの中に存在する。(終わり)

まあ、ただこういうことをしっかりやっている組織というのはあんまり無いだろう。たいてい、担当者の裁量で事が進んでいく。これは管理しているとは言い難い。客先に言われるがまますべての変更を受け入れるひともいれば、杓子定規にすべて突っぱねる人もいるだろう。(後者はあまり見たことないが、どちらかといえばそういう傾向がある人は居る)

理想論を言えば、一度定めた要求仕様は変更しないのが望ましい。仕様書がすでにあり、それをもとに開発を受注した場合はなおのことだ。たとえば、家の設計図を大工さんに渡して「これで作ってよ」と契約書を交わした後に、基礎工事を完了したあたりで「やっぱ3階建てにしてよ」などという要望は常識的に考えれば通らない。

しかしソフトウェアの世界ではそれが通ってしまう。それも、追加費用もなく通ることも多い。私の推測ではあるが、ソフトウェア開発というのは基本的に原価が存在しない(モノが存在しない)ので、計画変更が容易に行えると思っているクライアントが多いからであろう。それは大きな誤りであるのだが、それなりに名のある会社に勤めている社員であってもそう信じて疑わない人がいる。

契約にないことをやらされているのであれば、法的にはそれを請負者がやる義務は一切ない。だからやりません。で、済めば良いのだが顧客との関係性を重視して飲まなければならないケースは実際には多いだろう。

だからと言ってすべての要求を受け入れていたのではプロジェクトは破たんする。顧客からこういうチャレンジがあった。それを達成させるためにメンバーが死ぬ気で頑張りました。結果、うまく行って顧客からの信頼を得ることが出来ました。次回も大型案件を受注できる見込みです。終わり。パチパチ。という話は聞こえは良いが、その裏で多数のプログラマーの命が労働基準法ガン無視で削られているのを忘れてはならない。

加えて言えば、これは客先との良い関係を築けたとは手放しでは言い難い側面もある。一度無理をしてでも完成したという実績を作ってしまうと、普通、顧客は次回もそのレベルを要求するだろう。「この金額でこのシステムを作った実績があるのだから、次も大丈夫だろう」と思うはずだ。なぜならばそれが信用というものだからである。実績があるので次回も同じことが出来るはず。当たり前の思考だ。

しかし、実際にはそれは無理を重ねてようやく仕上げたプロジェクトなので、二回目以降もそのレベルを求められるとしんどい。しんどいけど、「しんどいんで止めてください」とは客には言いにくい。つまり自分で自分の首を絞める結果となる。

そうならないためには、ちゃんと仕様変更を管理しなければならない。つまり、CRBの役割を果たす人/組織をたて、プロジェクトが破たんしないようにするべきだ。現在のお金と時間で出来るものは受け入れ、できないものは突っぱねる。至極当然のことである。

また、見積もり作成時にはそういうことが発生するリスクをあらかじめ積んでおく。これもどんぶり勘定ではなく、過去のプロジェクトデータを基にして算出すべきだろう。と、言うは簡単だが、それぞれのプロジェクトで真面目にデータを集めているかというと、まあこういうのがしっかりできている会社は少数だろうと思う。

なんだか当たり前のことしか書いていないような気がしてきたが、どうもソフトウェア開発の世界というのは未成熟なのか、オレオレなやり方が横行していて困る。もうちょっと普通のソフト開発がしたいな、と思うのだが中々それにたどり着く機会が無い。