ITプロジェクトを発注する時に、みなさんはどのような契約で発注していますか？

大多数の企業は、「請負契約」で発注していると思います。
そこには何の違和感もないと思います。

以前の記事（発注企業が受託企業に「請負発注」する3つの理由）でも書きましたが、
請負契約する理由は3つあって、それは以下のようなものです。

①契約手続きが楽である
②検収条件を使って、受託企業に完成責任を負わせられる
③それ以外の契約形態を知らない

でも実際は、色々な問題をはらんでいるんです。

契約手続きは決して楽ではない

機密保持契約、基本契約、見積書受領、個別契約、注文書発行、納品書受領、検収書発行、請求処理・・・

一般的な請負契約の契約手続きです。
1つのITプロジェクトであっても、何らかの理由で契約を分割したりするケースだと、上記の手続きをその1つ1つに対してやらないとなりません。

これ、僕も経験したことありますが、非常に面倒くさいです。
面倒くさいってことはつまり、そこにコストがかかってるわけです。

発注企業と受託企業との間で、何度も価格交渉が発生することがあります。

予算内に収めたい発注企業と、リスクをヘッジしたい受託企業との間で、価格に対する考え方に乖離があるからです。

この価格交渉にも、結構な労力を使います。

ITプロジェクトの途中経過において、必ず発生するのが「仕様追加・変更」です。

この仕様追加・変更、必ずと言っていいほど、発注側と受託側とで、

「仕様追加・変更」か「設計ミス」か、を決めるための不毛なバトルが繰り広げられます。

どちらにせよそれは結局、

「要件定義で決まったことと異なる仕様にしたい」
「要件定義で漏れたことを追加したい」

ということであり、それを有償でやるのか、無償でやるのか、そのせめぎあいをしているわけです。

これ以上予算を増やしたくない発注側の思いと、これ以上コストを増やしたくない（＝利益を圧迫したくない）受託側の思いと、双方で相反する思惑があるわけだから、そりゃ激しい交渉にならざるを得ません。

通常、請負契約には検収条件が設定されていると思います。

これ、つまり納品物が要件通りにつくられているかどうかを確認する、ってことなんですが、これ、ものすごい労力がかかる行為なんですね。

ソフトウェア以外にも、要件定義書、設計書、テスト仕様書などなど、いろいろ確認しなければなりません。

ITプロジェクトにおける、発注企業側の担当者が1名や2名というケースも少なくなく、とてもその人数でやり切れる分量ではなかったりするため、かなりの稼働負担になります。

このように発注する側には、

・契約手続き
・価格交渉
・仕様追加・変更かどうかの交渉
・検収手続き
と、かなりの労力となる「手間」が発生します。

これらの手間は、やって当然、当たり前の業務なのでしょうか？

発注企業のITプロジェクト担当者は、普段、通常業務を持っています。

情シス、マーケティング、営業企画などのセクションの方々で、本当は自分のセクションの業務に集中しなければならないはずです。

でも、ひとたびITプロジェクトが発足すると、兼務することになりますが、とても片手間でできる業務量ではないのです。

なぜこのようなことになってしまうのか？

全ての原因は、

「受託側に完成責任を負わせている」

からです。

期待通りのモノをつくってもらうために、完成責任を負わせているのでしょうが、そこには、発注側の「多大な労力」という犠牲も払っているのです。

でも、発注企業にとって、「期待通りのモノが完成する」ことが目的なのでしょうか？

発注企業側にとって、本当に必要なことは、

自分たちのビジネスやサービスを、「継続していく」こと

なんじゃないでしょうか。

どんなに完成責任を負わせても、ビジネスやサービスが継続するかどうかには、ほとんど影響しません。

どこかの筋トレジムの宣伝ではありませんが、
「完成責任にコミットする」
ではなく、

「継続責任にコミットする」。

ITプロジェクトにおいて、発注企業側の手間をゼロにすることはできませんが、
受託側が「継続責任にコミットする」ことで、
かなりの手間を軽減することができます。