ソフトウェア開発を外注するために必要な、契約書フォーマットを公開

ソフトウェア開発はフリーランサーへ外注しましょう。あなたが時間と労力をかけて勉強する必要はありません。あなたのニーズに応えるプログラマーが既にいます。

あなたがするべきことはソフトウェアの仕様をまとめることです。あとはプログラマーと相談しながら形にしていきます。今では多くのフリーランサーサイトでプログラマーがあなたからの仕事依頼を待っています。あなたが作った仕様書をそこへ投稿すれば、１日とたたずにいくつものオファーが舞い込みます。簡単なプログラムであれば数千円～１万円も払えば作ってくれる人はたくさんいます。

発注にあたっての不安と信頼関係

発注しても延々と完成しなかったらどうしよう。追加で高額な費用を請求されるかもしれない。途中で開発放棄されたらどうしよう。はじめて発注する時はこんな不安があります。一方の受注側も同じような不安をもっています。発注者はちゃんとお金を払ってくれるんだろうか。途中で大きな仕様変更を求められたらどうしよう。いちゃもんじみたコメントを付けられないだろうか。

これはソフトウェア開発に限ったことではありません。全ての取引における二者間の持つ不安です。発注側は依頼した通りの品質、コスト、納期で品物が納入されるか不安です。受注側は発注者がちゃんとお金を払ってくれるか常に不安なのです。

極端なたとえ話をします。あなたはコンビニでお弁当を買います。まさかそれが腐っているとは思わないでしょう。なぜならいつもの馴染みのコンビニを信用しているからです。ボロボロの恰好をしたホームレスが、道端でお弁当を売っていたとしてあなたは買うでしょうか。答えはノーですね。

日本で日常生活をするにあたっては、売る側も買う側も信頼関係がすでに担保されています。売る側はその店舗、ネームバリュー、商品そのものが信頼の証です。買う側は手持ちの現金、クレジットカードが信頼の証です。

しかしビジネスでは売り手も買い手も信頼関係の無いケースがほとんどです。その信頼関係を担保する仕組みが世の中にはたくさんあります。契約書はその一つです。

契約書は信頼関係を作る

契約書の基本的内容は、製品の仕様、価格、納期といったところです。これらは当事者同士が最も興味のあることです。なのでわざわざ契約書で文書化しなくても、契約前に既に共通認識が取れている場合が多いです。このような基本的な内容に焦点をあてると、契約書を取り交わす必要性があまり感じられません。

契約書で重要なのは無味乾燥とした決まり文句、定型表現です。そこには想定外のトラブルが起こった時の対処法が記載されています。「仕様を満足しなかったらどうする」「天災が起きたらどうする」「裁判になったらどうする」。

事例１
あなたはとある自動車部品メーカーに勤めています。これまで在庫管理は帳簿でやっていましたが、業務効率化のためデータベースによる商品在庫管理システムを導入することになりました。あなたは開発業者A社を選定し仕様、納期、価格を取り決め発注しました。
ある日A社から納期遅延の申し出があり、聞くところによると開発環境が故障したため復旧に３か月程度かかるそうです。当初取り決めていた納期の倍以上の期間となり到底受け入れることができません。A社では代替機の使用や外注化も検討しましたが、いずれも２週間程度の納期短縮にしかなりませんでした。
幸いにして、発注直後だったこともあり、あなたはA社への発注を取り消すこととし、見積当時２番手だったB社へと発注しなおすことにしました。この話をA社へもちかけたところ、A社は今回の開発のため新しい開発環境を導入しエンジニアも新たに雇ったところで、今さら発注取り消しなんて受け入れられないと主張。どうしても発注を取り消すのであれば裁判所に持ち込むと言っています。
あなたは契約書の１項（ⅳ）「クライアントは、本契約の条項に重大な違反があり、そのような違反の通知から 5日以内にそのような違反を解決しなかった場合、いつでも本ソフトウェア開発契約を終了することができます。」を参照しA社へ伝えたところ、それをA社はしぶしぶひきさがり契約のキャンセルを了解したのでした。

お互いがサインした契約書というのはあなたが想像する以上に心の重しとなります。両者にそれを守ろうという強烈なプレッシャーを発します。極端なことを言えば、契約書が実効性を発揮するのは裁判所へ持ち込まれてからですが、コストも時間もかかる裁判をする人はほとんどありません。何かトラブルが発生した際、両者でその契約書を眺めると、ほとんどの場合そこに取り決められた通り物事が運びます。これは私がプラントエンジニアとして国内、海外のあらゆる企業とやりとりをし、契約を交わした経験に裏付けされています。

ただし契約書も万能では無いことも覚えていてください。上記事例１で、もしあなたの会社が多額の前金をA社へ支払っていた場合、おそらくA社を使い続けるはずです。契約をキャンセルし前金を取り返すことも可能ですが、一度支払ったお金を取り戻すことは非常に難しく、たとえできたとしても交渉に多大な労力と時間を要します。それこそ裁判にもつれ込む可能性が高いでしょう。その間あなたの会社は、A社への支払いにより悪化した財務状況で、前金を取り戻すまでの期間を耐え忍ばなければならないのです。

先ほど契約書の実効性という話をしましたが、その実効性の源はお金のことです。両者の関係にお金を介在させることで両者は動かざるを得ない状況になります。そこで考えるのは、両者でやりとりされるお金を直接コントロールすることです。これが支払条件の取り決めです。

支払条件を取り決めることで安心して取引が出来る

支払い条件とは、こうこうこういう条件になったら、いくら支払いますという取り決めです。

コンビニでジュースを買うときは一括で料金を先払いしてから飲むことが出来ます。レストランでは先に料理やサービスを提供を受け後払いする取引です。家や車など高額な買い物ではローンを組みますが、これも実際には購入者がローンを組んで先払いをしています。日常生活の中では、ほとんどが一括支払いで前払いか後払いのどちらかなので、これが普通だと思っているかもしれませんが、企業同士で取り交わす契約のほとんどは、この支払条件をすこしづつ調整します。全体の支払額を１００とすると、前金で１０、納品時に８０、保証期間終了後に１０支払う、という具合です。

事例２
あなたは自分でデザインしたこだわりの木製椅子を、SNSで知り合った木工アーティストA氏へ製作を依頼します。支払は納品後に一括で払おうと思っていましたが、A氏は材料の木材を買うためのお金がないとのことで、前金として２０％を先払いすることで合意しました。一方で納品後に壊れたり変色したりしないかが気になるため保証期間を定め、その終了後に１０％支払うことにしました。残りの７０％は製品納入時に支払います。

このように支払条件を調整することで、発注者と受注者の双方の懸念を払しょくすることができます。保証期間を定め１０％の支払いを残していれば、もし保証期間中に椅子の足が折れたとしても、A氏は足の交換を無償でしてくれる可能性は高いです。納品時に全額支払っていれば対応されないか、ものすごく遅くなる可能性があります。

事例からは少し外れますが、一般的に製造業の営業利益率は数％～１０％と言われています。そんな中で支払金額の１０％というのは非常に大きな数字で、保証期間後の１０％の支払いを受けて初めて利益が出るのです。そのため受注者はその１０％を得るために必死に不具合に対応します。

ここまで契約書の重要性について説明しました。契約書は受発注者の双方に信頼関係を持たせる方法の一つで、何か想定外のことが起こった時のための取り決めが書かれている。そこに双方のサインをすることで、それを守ろうとする意識が働く。ただし契約書も万能ではなく、契約者双方に実効性を働かせるためには、その元となるお金をコントロールすること。つまり支払条件をリスクに応じて取り決めることが重要である。

契約書のフォーマット

前置きが長くなりましたが、以下有料部分にソフトウェア開発に使える契約書のフォーマットを添付しておきます。小規模な開発であればこれで十分なはずです。本文には解説も付けているので、各項が何を意味しており、契約上どういうリスクが想定されるのかを理解できるはずです。

外国のフリーランサーを雇うことも想定し英語版と日英併記版も載せておきます。通常併記版では優先言語が規定されますが、日本語が書かれていることによって、社内関係者への契約理解がしやすくなるでしょう。

契約書フォーマットの目次

1. 開発者の義務
2. 成果物
3. 支払い
4. ソフトウェアの知的財産権
5. 仕様の変更
6. 秘密保持
7. 保証
8. 補償
9. 書面以外での契約内容の変更の不可
10. 準拠法
11. 特別条項
別添A ソフトウェアの仕様
別添B マイルストーンと進捗支払

契約書フォーマット

以下にWordファイルを張り付けています。日本語版、英語版、日英併記の3種類のフォーマットがあります。各項目の解説は日本語版に記載しているのでご参照ください。