請負でやるから失敗する、３つの理由

弊社は、生産性向上やコスト削減を目的としたオフィス業務改善を得意としており、その解決手段としてExcel VBAやAccess VBAを使ったツール（ソフトウェア）開発も受託しています。しかし、そのツール開発契約はすべて「請負」ではなく「業務委託（準委任）」でやらせていただいています。

請負のように瑕疵担保責任を取ってくれないのは無責任ではないか、というご意見もあろうかと思いますので、請負にすると生じる様々な問題点や、業務委託にすることで得られるメリットを明らかにしていきます。

【理由１】効果を無視したコスト算定方法であるため

◆人月ベース思考から脱却すべき

請負契約で開発を依頼すると、ほとんどの場合「開発工数（人月）」ベースで見積もりが行われます。開発工数ベースというのは言い換えれば、お客様が得る効果、例えば業績向上やコスト削減、生産性向上といった効果を一切無視して、開発ベンダー側の給料をベースとして開発コストを算出する、ということです。

一般的に、レベルの低いプログラマーでも１人月８０万円要します。レベルの高いプログラマーなら１人月２００万円くらい必要です。ということは、業務効率化ツールを開発するのに２ヶ月かかるとすれば、最低でも１６０万円以上の予算は必要、ということです。お客様から見れば「レベルの低いプログラマーなのに、なぜこんなに金がかかるのか・・」と思うはずです。

もちろん完全成功報酬にすると開発ベンダーのリスクが一気に増大するので現実的ではないですが、少なくともお客様が得る利益が、開発に投じられるコストを上回るように案件を調整することはできます。人月ベースでの画一的な見積りはやめて、お客様の利益を優先して開発案件の最適化を図る方向にシフトしていくべきだと考えます。

◆品質とコストは指数関数的

品質は高いほうが望ましいですが、どこまで品質を追い求めるのかは要検討です。高い品質にするには当然コストがかかります。品質を上げるのにどれくらいのコストがかかるのかについては、以下のようなイメージをもっておくとよいと思います。ここでは、品質の高さを示す指標として「バグ収束率」を用いています（数値が高いほど良好）。

バグ収束率　８０％→８５％にするのに１０万円
バグ収束率　８５％→９０％にするのに１００万円
バグ収束率　９０％→９５％にするのに１０００万円

どれだけ時間をかけたとしても、どの業者に開発を依頼したとしても、１００％の品質を実現するのはほぼ不可能だと考えるべきです。となると、開発時間とコストをたっぷりとかけて数％の品質を上げるのか、早めにツールを使い始めてさっさと投資したコストを回収し始めるか、そのバランスを見極めるべきでしょう。

また、ほとんど読まれることのないマニュアル作成の工程などを省けば、さらに投資コストを削減できます。荒削りでもいいからスピーディにツールを導入して、お客様にどんどん使っていただき、ユーザ向けマニュアルは業務に精通したお客様に作成していただくほうが効果的です。その結果、通常は１～２ヶ月かかるツールの開発が、早ければ１～２週間で仕上がる、というわけです。

ちなみに、そんなに早く作ったらバグだらけで品質は劣悪なんじゃないか？と思われるかもしれませんが、そんなことはありません。もちろんテスト体制が整備されているに越したことはありませんが、品質というのは開発ベンダーの要件定義力と開発能力と開発センスに依存すると考えています。業務ユーザによるテストを経て、容認できないバグ（業務に支障がある不具合）さえしっかり潰してしまえば、容認できるバグをつぶすためにどれだけお金をかけるかは投資余力と相談して決めればよい、ということです。

【理由２】お客様の仕様策定負担が増大するため

請負契約は、あらかじめ決められた仕様が存在することを前提として、開発ベンダーはその仕様どおりに開発することを請け負う契約です。言い換えると、お客様が最初から仕様を細かく決めて発注しなければならない、というデメリットがあります。そこで問題となるのは、お客様が決めた仕様は果たして最善なのか、さらには当初から仕様を確定させることなど本当にできるのか、ということです。

弊社は、ツールの仕様策定段階から参画し、お客様に対して仕様を提案していくことを強みとしています。お客様の業務上の課題・問題点さえ明確になれば、その業務を改善するために必要な仕様を提案させていただくことが可能です。最初から仕様が決まっていない以上、請負で開発しようがない、ということもいえます。

また、請負は徹底したネゴシエーションの世界です。仕様の1つ1つが発注者と受託者の争いのタネになります。開発を受託する段階で、費用を上げろ下げろという一悶着があり、さらに一度決めた仕様を変更する場合は当然追加コストがかかるかからないの争いも生じます。結果として、発注する前段階からお客様は仕様策定に相当の時間をかけなければならないし、言ったとおりに開発が実施されたか懐疑的な目でチェックしなければならず、もはや協力関係どころか敵対関係に近いという印象すらあります。

【理由３】目的達成に向けた協力関係が破壊されるため

請負契約では、発注者と受託者の間に明確な上下関係が生まれます。発注者側には無意識的に「開発ベンダーを使ってやっている」という感覚が生まれ、開発ベンダー側には「発注者の言うことに逆らえない」という意識が生まれます。結果として、上下関係による思考停止状態が発生します。

開発ベンダーは瑕疵担保責任によるコストオーバーランをなんとしても避けたいので、とにかく不具合を出してはいけないという思考に陥ります。不具合を出さないためにも「仕様はとにかく細かく取り決めて、お客様が言ったという言質を取ろう」とか、「テスト工数を確保しなきゃいけないから、期間はなるべく多く、コストは多少多めに積んでおこう」といったネガティブな思考の連鎖を生み出すわけです。

果たしてそれが、お客様にとっても、業者にとっても幸せなことなのでしょうか？業務に問題が生じていてそれを解決したいというのがお客様のゴールであるはずなのに、それを一緒に考えてくれるパートナーがいない。業者は言われたことしかやってくれないし、場合によっては言ったことすらちゃんとやってくれない。お互いに不満しか残らない、極めて不幸な契約形態が「請負」なのだと言えます。

したがって、後ろ向きに作用しがちな請負契約よりも、前を向いてお客様のために仕事ができる業務委託契約のほうが、双方のために良いことだと私は考えています。