なぜプロジェクトは失敗するのか？　その３

以前の記事で、

「プロジェクトが失敗する原因は、請負契約にある」 と書きました。

ではなぜ、請負契約がプロジェクトを失敗させるのでしょうか？

民法632条によれば、請負契約とは、 「請負は、当事者の一方がある仕事を完成することを約し、相手方がその仕事の結果に対してその報酬を支払うことを約することによって、その効力を生ずる」 とあります。

つまり、受託側には 「完成責任」 が発生するのですが、 それは 　「完成品が定義てきている」 ことが前提なわけです。

完成品が定義できていなければ、仕事が完成したかどうかが、わかりませんよね。

この「完成品が定義てきている」かどうかが、請負契約を履行できるかどうかの分かれ目になるのですが、 僕は、ITの受託ビジネスにおいては、「完成品は定義できていない」と考えています。

もっと厳密に言うと、「完成品が定義できた」と言える状態は、 プロジェクトの最後の方、プロジェクトの終盤に差し掛かったころだと思います。

（※プロジェクト終盤は、定義云々というより、もう完成品が出来上がる状態なんですけどねｗ）

発注のタイミングで完成品が定義てきていない以上、 完成責任を約束することはできない、ということなのです。

従って、ITの受託ビジネスにおいては、そもそも請負契約は適合しないのではないか、 と考えるようになりました。

適合しないような契約なので、 プロジェクト失敗の根本原因だと考えるようになったのです。

そんな「完成責任を約束できない」はずの請負契約ですが、 ITの受託業界では「常識」です。

誰も疑うことなく「請負」で受託しています。

でも、この「常識化」した請負契約の中には、3つの矛盾が存在しています。

「常識化している3つの矛盾」

その3つの矛盾とは、以下です。

①完成責任を約束している
②総額を決めている
③仕様変更が発生する

①と②は、 「完成品が定義できている」前提のお話しなのですが、 ほとんどのプロジェクトにおいて、発注段階で完成品は定義できていません。

1つ目。

①完成責任を約束している

について。

これについては、上述した通りです。 家を建てるのに、 「図面は完成してない、でも家は完成させろ」 と言われているようなものです。

図面が完成していない状態で家なんて建てたら、欠陥住宅になってしまいますよ。

図面が完成していないのに、家の完成は約束できないんです。

でも、ITの受託ビジネスにおいては、図面が完成していないのに、家の完成を約束しているようなものなのです。

これ、矛盾していませんか？

2つ目、

②総額を決めている

について。

一般的にIT業界における請負契約は、 「予め完成品の総額を決める」方式をとります。

つまり、 　

・発注側が見積り作成を依頼し、
・受託側が見積りを提出し、 　
・予算が決まる

というプロセスを経て、総額が決まります。

しかし、 ITを駆使してつくる成果物（Webサイトや情報システム）って、 細かい仕様を決めないと、本来は総額が決められないものなんです。

この、完成品の総額、が見誤っていたとしたら、プロジェクトはどうなりますか？

細かい仕様を決めずに見積もるので、ほとんどの見積りは精度を欠き、 本来必要な総額よりも少なく見積もってしまうことが、ほとんどなのです。

完成品の総額が、本来必要な総額よりも少なければ、プロジェクトは成功しませんよね？

これはITに限らず、どのビジネスでも同じだと思います。

予算が不足していれば、成功する確率は下がるのです。

完成品が定義できていないのに、総額を決める。

これ、矛盾していませんか？

①と②の矛盾は、プロジェクト成功の確率に大きく影響する要素です。

僕は、この矛盾を解消しない限り、プロジェクトが成功することはないと確信しています。

3つ目、 ③仕様変更が発生する については、次回お話しします。