仕様書にやらないことを書かないから後で喧嘩になる

どんなソフトウェアを作るのか、を紙にしたものが仕様書である。一般的には顧客がソフトウェア開発会社側に示すものが仕様書であるが、現実的に中小企業では顧客側が書くことはほとんどなく、ソフトウェア開発会社側が仕様書を書くところから参加している。

要は自分で作るものを自分で決めているわけだが、仕様書作成過程において、顧客と何を作るかについて延々と話し合う事になる。この時点（まだ何を作るのかすら決まってない時点）で、予算と納期が決まっている事がよくある。

予算と納期が決まっているということは、仕様を作成する段階で、仕様から落とす項目が当然出てくる。「今回はこの機能はやめておきましょう」とかなんとか言って、顧客も「予算的に無理ということであれば、稼働してから考えましょう」と同意する。

ところが、予算と納期に合わせていい感じに仕様が決まり、いざ開発となって中盤から終盤に差し掛かった頃、急に顧客の偉い人が「この機能が足りないと使い物にならない」とか言い始めるのである。

ここで、「仕様書に書いてないじゃないですか！」と言っても、「この機能は必須である。仕様書から抜け落ちているのはそちらの不備である」とか言いかねない。さすがにそこまで責任転嫁するところはないと思いたいが、少なくとも顧客側は不満に思うだろう。不満はそのうち別の所で爆発したりするので無いに越した事は無い。

問題は、落とした項目について営業担当者レベルでは同意していても、仕様書には一切「今回やらないこと」として記載されていないということだ。書いてあっても機能追加になりそうな気もするが、その場合は顧客側の責任ということで、金額と納期の交渉は出来るだろう。

やらないことを書いたほうがいいと言うと、膨大になるから無理という議論になりそうだが、そうでもない。予算と時間があれば追加したい機能一覧と思えば、書きやすいのではないだろうか。

そういう意味では、最初から予算と時間に合わせて仕様を決める前に、一回り大きな仕様を用意して、そのうちこの部分を今回のシステム化範囲とする、としたほうが後々の仕事にも繋がるのではないだろうか。

書いてあることを全部満たすようにソフトウェアを作るという前提だと、とにかく俎上に載せたものは全部作らなければならないという感覚に陥りやすくなってしまう。

顧客も最後になって、今言わないともう作ってもらえない！と思うと機能を追加したくなるので、そういう心理に追い込まないことが結果的に予算も納期も守れることに繋がるのではないかと思う。

技術的に遜色ないなら、あとは心理戦である。同じ作るならどういうアプローチにすれば効果的かを考えていかないと、無駄に損をしてしまう。仕事を円滑にするためのパターンというのが、プログラマにはもっと必要なのかもしれない。