ブログ

なぜ請負じゃなくて準委任なのか?

弊社は業務プロセス改善をウリにしてますが、ちゃんとソフトウェア開発もしています。でも、そのソフトウェア開発は「請負」ではなく「準委任」でやると決めています。請負のように瑕疵担保責任を保証してくれないのか!無責任じゃないか!と言われてしまいそうなので、その辺しっかりご説明しておきたいと思います。

 

理由1.お客様が負担するコストを下げるため

ぶっちゃけこれが一番大きいです。同じ業務委託で最終的にお客様が得られる利益は変わらないけども、請負にするだけでコストが跳ね上がります。例えば、「調査票を作成する業務がすごく大変なので、エクセルを使って自動化してほしい」というご依頼があったとします。

 

弊社の料金算定方法は、お客様のコスト削減額の50%です。弊社が構築するツールによって、お客様が1カ月あたり40時間のコスト削減が可能だとすると、コスト削減額は24万円(40時間×6カ月×時給1,000円)となり、その半分の12万円が報酬、ということになります。

 

一方でこれをExcelやAccessの受託開発業者に発注したとします。すると、開発工数ベースで見積もりが行われます。これってつまり、お客様のコスト削減効果というのは一切無視して、業者側の日給をベースとして計算しますよ、ということなんです。一般的に、レベルの低いSEでも1人月80万以上かかります。レベルの高いSEなら1人月200万くらいいきます。ということは、調査票のツールを作るのに最短で2週間はかかるとすれば、40万円以上のコストはかかってしまう、ということになります。業者側(SEの立場)から見れば「この案件儲からないなぁ・・」と思うはずだし、お客様から見れば「レベルの低いSEなのに、こんなに金がかかるのか・・」と思うはずです。

 

ちなみに、なぜ1人月80万円以上もかかるのかというと、ウォーターフォール型という開発方式と、「請負契約」により余計な保証をしなくてはないけないという2つの原因があります。

 

図1

ウォーターフォール型というのは伝統的な開発方式で、「要件定義」→「外部設計」→「内部設計」→「コーディング」→「単体テスト」→「結合テスト」→「システムテスト」という工程を経て、ソフトウェアを開発していくやり方です。この開発方式の問題点はたくさんあるのですが、とにかく作業工程の数が多いがゆえに、コストが増大していく、という点が最大の問題です。

 

まず、仕様書はお客様が用意しなければなりません。受託開発業者は基本的に「言われたことしかやらない」し、「頼まれたものしか作らない」ので、どういうツールを作ってほしいかはお客様が明確に定義しなければなりません。

 

お客様はあらかじめ用意してきた仕様書を誤解のないように業者に伝えて、業者はそれを要件定義資料や外部設計資料に落とし込みます。できあがった資料はお客様に確認してもらって、「これでいいですね?(今後この設計書を修正する場合は別料金もらいますよ?)」という念押しをしてきます。

 

その後、内部設計書を作成し、低レベルのプログラマーに開発をやらせて、その間に単体テスト計画書、結合テスト計画書、システムテスト計画書を作って(実はそのテスト計画書のクオリティもかなり低いのだが)、ひたすらテストをやってバグをつぶします(といってもバグはゼロにはなりません)。

 

作業品質は置いておいて、これだけの工程を「とりあえずこなす」だけでも相当の期間が経過します。その間に発生する人件費が、お客様の払うコスト、ということになります。できあがってきたツールを見て、お客様は確かに自分たちが頼んだとおりのものだ、と思うでしょう。でも、何の感動もありません。そりゃそうですよね。お客様が考えた以上の工夫が何もない=付加価値ゼロなわけですから。

 

じゃあ日本頭脳株式会社は何が違うのか、というと、まず最初にお客様が本当に困っていることを口頭で伺って、その後は弊社がリードします。「こうしたらいいんじゃないか」ということをガンガン提案していきます。ツールの仕様書も要件定義も弊社が主導で行います。

 

概して、お客様(ユーザー)が考える仕様というのは正解ではないことが多い。これは私が10年以上この業界でやってきて得た結論の一つです。本質的にどうあるべきかを考えて、正しい仕様に落とし込むのはプロに任せろ、ということです。お客様は業務の専門家、弊社は業務改善の専門家。取り扱う領域が違うので、業務改善のやり方やツールの実装については弊社に任せてください、ということです。

 

そして、ムダなドキュメント作成やテストの工程はすべてすっ飛ばして、まずは荒削りでもいいからスピーディにツールを開発して、お客様にどんどん使っていただきます。その結果、受託開発業者に頼むと2週間以上、通常1カ月くらいかかるツールの開発が、早ければ1~2日で仕上がる、というわけです。

 

ちなみに、そんなに早く作ったらバグだらけで品質は劣悪なんじゃないか?と思われるかもしれませんが、そんなことはないというのが私の意見です。品質の高さを示す数値の一つに「バグ収束率」(総バグ件数/バグ予測件数) というのがあります。これが100%になるとバグ(不具合)がほとんどないということが言えます(100%ない、ということではない)が、100%にするには莫大な工数がかかります。

 

バグ収束率 85%→90%にするのに10万円かかるとすると、

バグ収束率 90%→95%にするのに100万円、

バグ収束率 95%→100%にするのに1000万円かかる、

 

と考えてもらっても差し支えないと思います。もちろん不具合はあっていいものではありませんが、容認できるバグ(あったとしても業務上支障はない不具合)と、容認できないバグ(あると業務に支障がある不具合)があって、容認できるバグをつぶすために一生懸命お金をかけるのはムダ、ということです。

 

弊社のバグ収束率が仮に90%程度とすれば、受託開発業者は95%程度でしょう。ただ、その5%の違いは大した違いじゃない、ということです。つまらないバグをつぶすのに何十万円も多く支払い、さらに1週間も2週間も多く時間をかけているくらいなら、早く使い始めて利益を享受したほうがいいのではないですか?というのが弊社のメッセージです。

 

図2

 

なぜ請負じゃないのか、という話に戻りますが、請負にすると「とにかく不具合を出しちゃいけない」という思考になります。それはどういうことかというと、不具合を出さないためにも「仕様はとにかく細かく取り決めて、お客様が言ったという言質を取ろう」とか、「テスト工数を確保しなきゃいけないから、スコープはなるべく狭く設定しよう」とか、「瑕疵担保責任で後から無茶なこと言われたくないからテスト工数は余分に積んでおこう」といったネガティブな仕事のやり方になるわけです。

 

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

 

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

 

ちょっと長くなってしまったので、それ以外のお話はまた別の機会に・・

 

 

理由2.業務効率化をスピーディに実現するため

理由3.パートナーシップを強化するため

 

関連記事

  1. この記事へのコメントはありません。

  1. この記事へのトラックバックはありません。

ページ上部へ戻る