請負契約では、作業範囲を明確に

どの契約形態を取るかは、事前に決めておかなければなりません。シスアド試験にも出る内容なので、ちょっとおさらいをしておきます。

請負契約とは、外注先である受託者が、発注元である委託者から業務を請け負う形態の契約です。あくまで仕事を請け負う契約であり、その点では、派遣契約と異なります。派遣契約では、開発を依頼する側の派遣先は、派遣されている労働者への指揮命令権がありますが、請負契約ではソフトウェア開発会社の労働者への指揮命令権がありません。

受託者は、委託者から請け負った内容に基づいてプログラムを開発します。 よってそのソフトウェア自体の著作権は受託者にあります。

さらに、プロジェクトの進捗状況を報告する義務はありません。

瑕疵担保責任は、契約書上に記載がない場合は、民法では引渡し時から1年、商法では6ヶ月存続します。

業務委託契約は、請負契約が「仕事を完成させる」ことを重点にしているのに対し、「労働の提供」そのものに重点が置かれた契約です。従って、予定工数を超過した場合、精算が行なわれるのが一般的です。

このような違いがあるため、今から行なうプロジェクトの方針に沿った契約形態を選ばなければなりません。

しかし、多くの場合は、請負契約として契約しているのが実情ではないでしょうか。なぜなら、費用に対するリスクがないから。

費用に関するリスクがない分、発注側は、作業範囲を明確にし、指揮命令系統をはっきりと意識しなければなりません。ここでも作業範囲記述書が重要な役目を果たします。

何も法律論を振りかざすつもりはないですが、請負契約にそぐわない場面によく出会います。

ある建設業準大手のERPプロジェクトで起こったことです。プロマネ、リーダーが不在の時に、顧客の1人がメンバーに、あるインターフェースの仕様書を作成するよう依頼しました。

その報告を後で、プロマネが聞いたわけです。そのインターフェースは、作成しないと決定済みのものでした。そのメンバーに対し、仕様書作成を確約したのかどうかを確認すると、答えは「はい」。

そこで、プロマネは、そのモジュールリーダーと共に、顧客と話し合い、作成しないと決定しているインターフェースの仕様書を作成することをなぜ依頼したのかを確認し、その話はなかったことにしました。

このようなことは、日常茶飯事です。金額が固定だから、スコープを度外視して詰め込んでしまおうとする考えが、頭の片隅にあるのではないでしょうか。