前回の記事で、ITの受託業界で「常識化」している請負契約には、 3つの矛盾があり、そのうちの2つについて書きました。

今回は、 3つ目、 ③仕様変更が発生する についてです。

請負契約は、「仕事の完成」を約束する契約なので、 「完成品が定義されている」ことが前提です。

発注のタイミングで、「完成品が定義されて」いれば、 受託側はその定義に沿ってモノをつくればよいので、 「仕事の完成を約束する」ことができます。

建築に例えれば、 図面がある（＝完成品が定義されている）ので、 家を完成させることを約束することができる、 というのと一緒です。

もし、しっかり「完成品が定義されている」プロジェクトであれば、 何の問題もなく「仕事の完成」を約束することができるので、 プロジェクトが成功する確率は高くなります。

ところが、ITの受託ビジネスにおいては、そううまくいきません。

なぜかというと、 必ずと言っていいほど、 　

　「仕様変更が発生する」

からです。

仕様変更が発生する理由は様々です。

• 要件定義で仕様を詰め切れなかった
• 発注側と受託側で認識の齟齬があった
• プロジェクト途中で市場環境が変わった
• 発注側のこだわり

他にもあるかもしれませんが、 主だったものはこのあたりだと思います。

僕も様々なプロジェクトを経験してきた中で言うと、 圧倒的に多いのは、1つ目と2つ目、

• 要件定義で仕様を詰め切れなかった
• 発注側と受託側で認識の齟齬があった

ではないかと思います。

まずは1つ目、

要件定義で仕様を詰め切れなかった

について。

これについては、まず、「そもそも論」があって、 請負契約って、 「発注のタイミングで、完成品が定義されている」 必要があるので、 そもそも「要件定義」という工程があること自体がおかしい。

要件決まってないなら、完成品が定義されていないんだから、 請負契約しちゃダメでしょ？

で、これを解決する方法として、 要件定義で完成品を定義して、それ以降の工程から請負契約するパターン。

これなら、仕事の完成を約束できます。

ですが、 要件定義後に、「要件定義で仕様を詰め切れていなかった」ということが発生します。

これは、 ITを駆使してつくる成果物（Webサイトや情報システム）って、 細かい仕様を決めないとならないことが多々あるからです。

要件定義で「大枠の仕様を決める」という作業だけでは決められない細かな仕様が多数あるのです。

なので、結局、要件定義以降にも多数、仕様変更が発生してしまいます。

2つ目、

発注側と受託側で認識の齟齬があった

について。

これは、いわゆるヒューマンエラーの部類に入ると思われますが、 なかなか無くせるものではないように思います。

コミュニケーションスキルやマネジメントスキルによって減らすことはできるかもしれませんが、そこに多くのエネルギーとコストをかけることに、個人的には疑問を感じています。

なぜかとうと、

ヒューマンエラーは発生するものだからです。

初めてのお客さんや、初めてのプロジェクトだと特にその傾向が強いです。 認識違いを無くすことにエネルギーとコストをかけるのではなく、 ある一定の認識違いが発生することは許容しつつ、 その認識違いによって発生した問題を改善することに、 エネルギーとコストをかける方が、 発注側と受託側両方にとって、健全ではないでしょうか？

ほとんどのプロジェクトでは、認識違いが発生すると、 発注側は、その認識違いを受託側のせいにして押し込もうとし、 受託側は、何とか「仕様変更」という形にして追加請求しようとします。

こうして、

発注側と受託側で「対立関係」

が生まれます。

これって、双方にとって健全なことなのでしょうか？

プロジェクトにおいて、「仕様変更」は必ず発生するんです。

だから、発注側と受託側は、

「仕様変更は発生するものとして契約を締結するべき」

だと思うんです。

長くなったので、今回はここまでにします。 じゃぁ、ITの受託ビジネスでプロジェクトを成功させようと思ったら、 どうしたらいいのか。

また別の機会にお話ししたいと思います。