システム開発を個人に発注するときに押さえておくべき契約のポイント【2024年最新版】

小規模なシステム開発を依頼したいのだけど、予算はあまりかけられない。
フリーランスのエンジニアなら料金は安そうだけど、実際頼んで大丈夫だろうか…トラブルが起きたときには対処できるのだろうか…こんな不安を持つ発注担当者の方も多いと思います。
結論から言いますと、その不安は当たっています。
個人でシステム開発をすると言っても、そのレベルはピンからキリまであるのが実情です。

例えば、大手ベンダーなどで実績を積み自分でもシステム構築技術は持っていて、さらにその多彩な人脈を駆使してプロデューサーのような立場で信頼のおける各方面のエンジニアを束ね、システム開発の仕事を受注している人もいます。
こうした人材は、組織のなかでも十分に活躍できる実力を持ちながら、仕事のスタイルとして個人として動いているというケースが多いので、システム開発の仕事を安心して依頼することができます。

その逆に、組織のなかでうまくやって行けないなど、ネガティブな理由で会社を退職した人がいわゆる「食っていくため」という理由で「格安でシステム構築やります」的な看板を掲げて仕事をしているというケースもあります。
技術者としてのレベルも低い場合が多く、チームで動くという場合にも周りに信頼のおける高いレベルの技術者はいない…というのが実態です。

こうした質に関しては統計データがないので正確なところは分かりませんが、先程のスーパーエンジニアが全体の5%程度、食っていくために未熟な技術でやっている人が30％程度、のこりの65%程度（全体の2/3）が、その中間の普通のエンジニアだというのがおおよその目安と考えていいでしょう。

こうした、フリーのエンジニアに仕事を頼む場合のコツは、「契約書」をきちんと交わすことです。
もちろんこれはリスクヘッジということが第一なのですが、ほかにも積極的な理由があります。

それは、契約書の話をすれば、個人で動いているエンジニアが「スーパーエンジニア」なのか「食っていくためエンジニア」なのか「平均的なエンジニア」なのかがすぐに判明するという点です。

先程のスーパーエンジニアグループは、契約書の交わし方も非常に洗練されており、開発の範囲や役割分担と責任明確化、イレギュラーな事態が起こった場合の対処などポイントを押さえた契約書を個別に用意してくれます。
単に技術に詳しいというだけでなく、いわゆる仕事の勘所のようなところを押さえる本当の実力と経験がないとまとめられない案件ごとに隙のない契約書を作れるのがこのグループです。

食っていくためにやっているグループは、「契約書にしてください」と発注者に言われてから、あわててインターネットから無料の契約書フォーマットをダウンロードしてきて、コピペしながら「とりあえず作ってきました」ということがありありと分かるような契約書を持ってきます。

そして、2/3の普通のフリーランスエンジニアは、契約書作成には慣れていない感じはするものの、開発の範囲や役割分担と責任明確化、イレギュラーな事態が起こった場合の対処などポイントなどにつき、打ち合わせを重ねるなかで誠意を持って契約書にまとめようとしてくれます。

スーパーエンジニアに頼む場合には、通常のシステム会社に発注するときと同じくらいの金額であったり、場合によっては高かったりするケースもあります。
また残念ながら「食っていくためエンジニア」は典型的な安かろう悪かろうの納品物が上がってくるケースがほとんどです。

したがって予算の都合で「システム構築を個人に発注しようか…」と考えている場合には、上の例で示したうちの「2/3の普通のフリーランスエンジニア」（以下、この記事ではこの標準的なエンジニアを「フリーランスエンジニア」と表記します）から、リーズナブルな価格で誠意を持って仕事を完遂してくれそうなエンジニアをピックアップすることが重要です。

この記事では、フリーランスエンジニアのなかからビジネスセンスを持ち、比較的安価な料金で間違いなく仕事を仕上げてくる相手をピックアップするための手段として極めて有効な「契約書のポイント」について解説します。

それでは、個人事業主とシステム開発の契約を結ぶポイントを見ていきます。
依拠する法的な部分は基本的に通常の企業と結ぶ契約書と変わりはありませんが、具体的に契約書の文言を詰める際にはいくつかの重要なポイントがあります。
それぞれの項目については、大多数のフリーランスエンジニアはトラブル回避のためのノウハウをよく理解していない、ということを忘れずに発注者主体で話を進めていきましょう。

発注者側からすると、仕事の終わりとは当然「動くシステムを納品してもらったとき」になります。
ところが、フリーランスエンジニアからすると「依頼された作業内容が終わったとき」という感覚を持ってしまいます。

具体的に言えば、顧客管理システムを発注したケースで納品時に意図した動作が行われていなければ「やり直してください、それまでは支払いはできません」というのが発注者側の論理であり、「最初の打ち合わせで確認した仕様書通りに作って作業は完了したので、お支払いをお願いします」というのがフリーランスエンジニアの論理です。

発注者側からすると「不完全な製品を持ってきて請求とは何事だ!?」という実感を持ってしまいますが、法律上はフリーランスエンジニアの主張が認められるケースも多いのです。

こうしたトラブルを引き起こさないためには、フリーランスエンジニアとの契約形態を知っておく必要があります。

請負人がある仕事を完成することを約束し、注文者がその仕事の完成に対して報酬を支払う約束をすることによって成立する契約

フリーランスエンジニアとの契約をこの「請負契約」で結んだ場合には、先程の発注者の論理で仕事の完成に対して報酬を支払うことが約束されています。

民法上は準委任契約に分類されており、依頼者が法律行為以外の事務の処理を依頼し受任者がこれを引き受けることによって成立する契約

こちらは委託された業務に対して誠意を持って取り組み、最後までやりとげることを約束する契約形態ですので、先程のフリーランスエンジニアの論理が通ってしまいます。

⇒ 会社の看板を掲げて仕事を受注しているシステム構築会社との契約では、業務委託契約を結ぶことが多いですが、フリーランスエンジニアとのシステム完成をめぐるトラブルが特に心配な場合には「請負契約」を選んだほうが無難です。

＊なお「請負契約」と「業務委託契約」の概要は以上ですが、この記事の最後に解説する便利な「多段階契約」において、この「請負契約」と「業務委託契約」の法律的意味を知っておく必要がありますので、再度詳述いたします。

システム構築会社に業務を依頼する場合には、社内にミスのないプロジェクト進行のノウハウのような資産が蓄積されていますので、開発に必要なデータや資料をクライアントに要求するタイミングや、預かったデータや資料の保管や返却などについてそれほど気にする必要はありません。

しかし、フリーランスエンジニアとの仕事の場合には、発注者側がどんな資料やデータを準備することが必要なのか、役割分担が不明確になって開発が遅々として進まない、というケースが頻繁に起きます。大切なデータや資料なども、今どちらが持っているのか分からなくなってしまうなどのトラブルもフリーランスエンジニアとのプロジェクトではありがちです。

またどんな場合にどんな判断を下せばよいのかなどが曖昧になりがちなので、発注者側としては「これくらいのことは自分で判断して最良の方法でやってくれているだろう」と思っていたところが「どうしたらよいか分からないので指示してくれるものと思い、指示を待っていました」といった状態で、開発作業がずっとストップしていた、などというケースもあります。

⇒ フリーランスエンジニアとの仕事では役割分担を明記した進行管理表を作り、どの部分に発注者がタッチすべきで、どの部分はフリーランスエンジニアの責任で進めていくかについて明確化することが必要です。

システム構築会社に業務を依頼した場合には、万が一トラブルが生じたときも、組織として対応してくれます。
しかしフリーランスエンジニアとの仕事においては、トラブルが生じたときに的確で迅速な対応を取ってくれない場合があります。
それでも最終的に取ってくれればまだよいのですが、そのフリーランスエンジニアの手に余るような大きなトラブルであった場合、対応することそのものが不可能というケースもあり得ます。

⇒ こうした事態を避けるためには、想定されるトラブルについて契約書でできる限り具体的に列挙し、そのときにフリーランスエンジニアが対応すべき事柄、責任の範囲などについて明確化しておきましょう。大きなトラブルが想定されるのに、フリーランスエンジニアがそのトラブルに対処できないと明らかになった場合には、契約手続きを進めることをいったんストップすることなども必要です。

次に、これら３つのポイントを踏まえてリスク回避をするための具体的な契約書作成のテクニックをお伝えします。

システム開発では、「基本契約」と「個別契約」を使い分ける場合が一般的です。
と言っても、契約書を２つに分けることで何か複雑性が増すわけではなく、むしろその反対にフリーランスエンジニアと契約する場合には特に「基本契約」と「個別契約」を上手に使い分けたほうが、契約がスムーズにいきます。

「基本契約」とは、これから作成するシステムの目的や概略、支払い条件や大まかな納期、基本契約書の有効期間など、システム開発をスタートするに当たっての基本的な事柄について取り決めをします。
基本契約を交わす時点ではシステムの詳細の仕様も決定していませんので、見積金額を契約書に書き込むことはあまりしません。

フリーランスエンジニアと基本契約を結ぶ意義は、仕事に対するある程度の拘束性をはっきりさせることにあります。
個別の金額や詳細仕様はあとで決定するとしても、最初にこの仕事にきちんと取り組んでもらうためのコミットメントを確約させる意味で基本契約書は重要です。

フリーランスエンジニアに仕事を依頼する場合には、どうしても納期が曖昧になります。また、途中から開発内容が最初の目的とずれてきても、通常会社に依頼したときには進行状況をチェックするチームや社内の人間がいませんので、そのまま事態が悪い方向に進むケースもあります。したがって、基本的な方向性と契約の概略について、契約書である程度の縛りを入れておくことがポイントです。

また、最初に話を開始してそのまま連絡が取りづらくなるようなケースを防いだり、当初の目的とずれたシステム構築が進行していくのを避けたりするためにも、まずは「基本契約」でプロジェクトの内容全体への責任ある関わりを明確化することが大切です。

また法律上の契約形態を、「請負契約」と「業務委託契約」のどちらにするかも決定しておきます。
あとで解説する「システム開発における多段階契約」においては、請負契約と業務委託契約を組み合わせることで、さらに柔軟な契約を実現することができます。

システム構築では最初に基本契約を結んだ時点でシステムの詳細は明らかになっておらず、話し合いのなかで詳細を詰めていき、どれくらいの金額でシステムが組めるかを決定していきます。

このとき大切なのは、プログラミング作業をはじめとする技術的な部分だけを対象にして詳細を決めない、という点です。
システム開発プロジェクトは下記のような大きな一連の流れで構成されています。

現在１の「基本契約書締結」でフリーランスエンジニアのコミットメントを確定させましたが、次に「個別契約」を交わすまでに、「要求定義作成」「要件定義作成」「外部設計」「内部設計」というシステムの基本部分を詳細に詰める作業と、納品後の「保守・メンテナンス」をどうするか（依頼するのか/しないのか、するならどんな内容か）を決定しないと、正確な金額が出てきません。

ここで「保守・メンテナンス」をどうするかという点は、「あとから決めてもよいのでは？」と思う担当者の方もいると思いますが、フリーランスエンジニアの場合には、時間的な制約などから納品したあとの保守については、業務範囲外だとして引き受けてもらえないケースも多々あります。
そうした場合には、保守やメンテナンス作業が極力少なく自社内でもできるような形であらかじめプログラムを組んでもらう必要も出てきますし、プロジェクト全体の予算を、フリーランスエンジニアに依頼する狭義のシステム構築の部分と、それ以外の業者に頼む保守・メンテナンス作業に分割して配分する必要も出てきます。

フリーランスエンジニアへのシステム構築依頼は、こうしてプロジェクトを俯瞰しながら予算配分や、あらかじめ必要な保守メンテナンス機能を盛り込むかどうかなどを決定していく必要があります。
フリーランスエンジニアは、とかく狭い視野で狭く「システム開発＝自分のプログラミング作業」とだけ考えがちですので、「個別契約書」作りに関しても、発注者がリードすることがポイントとなります。

フリーランスエンジニアに仕事を依頼するリスクのひとつに、「そんなこと聞いていません」「いや、お願いしました」という“言った言わない論争”が起きやすいということがあります。
先程の項目でも指摘したように、フリーランスエンジニアは自分の仕事を職人としてプログラミング作業をすること、と考えている人が多いので、開発が始まったあとでも発注側のお膳立てがないと動いてくれない（動きたくても動けない）ケースが頻発します。

例えば、システムに入れ込むデータを発注側からいつ渡すのか、途中テストはどんなスケジュールでだれが行うのか（立ち会いがいつ必要か）などについて、システム開発のどの段階で発注側が関わるべきかを個別契約書に明記しておく必要があります。

契約書作成のチェックポイント2：役割分担の明確化で指摘した役割分担はこの「個別契約」に入れておきます。

こうした取り決めは、フリーランスエンジニアとプロジェクトを進める場合には特に重要です。
フリーランスエンジニアのなかには、管理業務や役割分担による共同作業が苦手なので、組織を離れて個人で動いているという人もたくさんいます。
技術力があるので仕事の実績を積んでいても、こうした契約上の知識や共同作業のノウハウは身についていない、というフリーランスエンジニアは少なくないので注意しましょう。

ここまで「基本契約」でフリーランスエンジニアの仕事に対するコミットメントを明確化し、「個別契約」でその内容を事前に詳細に決めることで、起こりそうなトラブルをあらかじめ回避しておく方法をお伝えしました。

基本的にはこうした方法でかなりのトラブルを防ぐことができますが、システム構築においては想定外の事態を事前に完全にゼロにしてしまうことはほぼ不可能です。
また、途中での変更と言ってもネガティブな事柄だけでなく、プロジェクトを進行させているうちに、クライアントの都合で優先すべき目的が変更になる場合もありますし、もっと最適なシステム構築の方法が見つかったりする場合もあります。

こんなときは「請負契約」と「業務委託契約」を組み合わせた「多段階契約」が便利です。

「多段階契約」は「請負契約」と「業務委託契約」の良いところを組み合わせた契約形態です。まずは多段階契約の理解の前提となる「請負契約」と「業務委託契約」の法律的な意味から見た特徴、メリットとデメリットを整理しておきましょう。

先程述べたように「請負契約」は、納期と品質が担保されるため、発注者側にとっては安全性の高い契約だと言えます。
法律的には「完成責任」と「瑕疵担保責任」（欠陥がある状態）をフリーランスエンジニアが負いますので、確かに必要な作業はやったようだがバグだらけで使えない、という納品物を拒否することができます。

しかし、よく考えてみれば分かるように、このときの「完成」の状態とは何かについて、事前に明確な定義をしないと請負契約はそもそも成立しません。
このことは請負契約のデメリットともなります。

「請負契約」でフリーランスエンジニアと仕事を進める場合には、開発が始まる前にその仕様など完成品の明確な定義を示す必要があります。
これがないと、フリーランスエンジニアは何を持って発注者が満足できるのかを客観的に知ることができないため、「これではダメです」という明確な理由もないままに、延々と無償で納品チェックを繰り返すことになりかねません。

完成形を事前に明確に提示することということは、一見すると当たり前のように思えます。
しかしシステム構築において最初の段階で完成形を明確に定義し尽くすというのは非常に難しいことでもあります。
プロジェクトがスタートして社内の関係者との話し合いを繰り返すなかで、目的とするシステムについて「こうしたほうが良い」という完成形の変更が起きることは珍しくありません。
変更というのはより効果の高いシステムが見えてきた、というポジティブなケースもたくさんありますので、最初に完成形をガチガチに固めてしまうと、結局発注者側の利益を損なう結果にもなります。

納品時に「こんな完成形は最初に定義していません」という理由で納品物を拒否できる「請負契約」が、ある場合には、発注者側を縛ってしまうこともあり得ることを確認しました。
この点「業務委託契約」ならば、発注者側都合による仕様の変更にも柔軟に対応できます。

なぜ業務委託契約だと仕様の変更ができるのかですが、それは契約の目的が「個別の業務の提供」であって、「完成形の納品」ではないからです。

具体的に言えば、こうなります。
発注者が自社の「○○会社顧客管理システム」という完成物を納品してもらいたいという場合、自社でどんなシステムが必要かを精査して、どんな要件を満たしている必要があるかをリストアップして検証し、最終的に仕様に落とし込んでもらいます。

これに対して、業務委託の場合には、例えば「今月１ヵ月間で営業マンが訪問した顧客のなかから、次の商談に進みそうな優良顧客を自動的にピックアップする」という内容について、業務を委託します。

もし「今月１ヵ月間で営業マンが訪問した顧客のなかから、次の商談に進みそうな優良顧客を自動的にピックアップする」という内容が、週に１回の集計に変更されて「今週１週間で営業マンが訪問した顧客のなかから、次の商談に進みそうな優良顧客を自動的にピックアップする」となった場合、いったん１ヵ月スパンの顧客抽出プログラム開発をキャンセルして、新たに1週間スパンの顧客抽出プログラムを依頼すればよいのです。

業務委託の場合には、個別の業務に対して契約が発生しますのでこのような柔軟な仕様変更への対応が可能ですが、請負契約の場合には、「今月１ヵ月間で営業マンが訪問した顧客のなかから、次の商談に進みそうな優良顧客を自動的にピックアップする」という内容を含めてたくさんの仕様が完成形の条件として契約書に明記されます。

したがって、請負契約で新たに１週間バージョンの顧客抽出プログラムを実現してほしいという場合には、仕様書の作り変えから行わなくてはなりません。
そうでないと、最終的に完成形として納品するシステムが契約書に明記された仕様を満たしていないことになってしまい、あとから問題が生じるからです。

フリーランスエンジニアにしっかりとした納品物を収めてほしいということだけから考えると「請負契約」が適切ですが、逆にフリーランスエンジニアの柔軟なフットワークを活かして、発注者都合の前向きな仕様の変更に対応してもらいたいという場合には、請負契約ではなく「業務委託契約」が適しているということになります。

では、自由な仕様変更があり得るのなら無条件で「業務委託契約」がいいのかと言うと、もちろん業務委託契約にもデメリットがあります。
「請負契約」とちょうど正反対になりますが、業務委託契約の場合には、フリーランスエンジニアに対して最終的な「完成責任」と「瑕疵担保責任」は生じません。

もちろん、先程の例で言えば個別の月次/週次の顧客抽出プログラムについて、誠意を持って業務を遂行する義務はありますが、そうした個別のプログラムが全体として、当初予定していた自社の「○○会社顧客管理システム」という完成物として完成するかについては責任を負いません。
各種の個別プログラムを総合した結果、非常に使い勝手が悪く、バグもたくさん出てきたという場合であっても、個別のプログラムがきちんと納品されているのならば、フリーランスエンジニアの側ではシステム全体に対する責任を負う必要がないのです。

以上一長一短のある「請負契約」と「業務委託契約」の特徴を見てきました。
それでは、両者をどうのように組み合わせると双方のメリットを活かした「多段階契約」が可能になるのかを整理します。

「多段階契約」とは要件定義、外部設計、内部設計、プログラミングなどのシステム開発の工程ごとに、順次個別契約を結んでいくというやり方です。

つまり、最初に大まかな目的や納期などについて「請負契約」を結び、要件定義、外部設計、内部設計、プログラミングなどの各工程については個別に詳細事項を決定して「業務委託契約」とするのです。

この方法による発注者側企業のメリットとしては、「請負契約」でフリーランスエンジニアのシステム開発への基本的な責任を明確化しながらも、あとからの仕様変更は「業務委託契約」で個別に柔軟に設定ができるということにあります。

この記事の「基本契約書と個別契約書を使い分ける」で解説したように、大まかな方向性の確認やフリーランスエンジニアの責任あるコミットメントに関する部分の基本契約書は、法律上「請負契約」で規定されているやり方で実施して、工程ごとの個別契約を、法律上「業務委託契約」で行うのが「多段階契約」となります。

多段階契約を使いこなせば、仕様の柔軟な変更や、プロジェクトの優先順位を常に見直していくことを前提とした「アジャイル型開発」も、フリーランスエンジニアとトラブルなく進めることができるでしょう。
また、小さな完成品（プロトタイプ）を作りながら、仕様を正確に確認してプログラミングを進める「プロトタイピング型開発」も可能です。

また、フリーランスエンジニアにとっても、「多段階契約」ならば、工程が終了するごとに代金の請求をすることができるというメリットがあります。
フリーランスエンジニアは一般の会社ほど資金が潤沢でない場合が多いので、金額的に大きなシステムであっても入金は半年先というような仕事は敬遠されがちです。
かといって、仕事が途中なのにフリーランスエンジニアの懐具合を勘案して半金を前払いにするなどは、発注者側の経理処理の問題があってできないことが普通です。

多段階契約を使えば、支払いに関してもルールに則った柔軟な対応が可能になります。
フリーランスエンジニアのコミットメントを担保しながら、同時に自由な仕様変更も確保でき、さらに相手にとってもメリットのある「多段階契約」をぜひ検討してみてください。

最後に、システム開発を外注した際にかかる費用相場をご紹介します。

システム開発の費用相場をご紹介しました。より正確な費用を知りたい方は料金シミュレーターをご利用ください。

以上、法律的な部分に気をつけてフリーランスエンジニアを発注側主導で上手に活かしていく、というノウハウを解説しました。
基本的にはこうしたやり方を取っていれば大きなトラブルに遭遇することもなく、仮にトラブルが起きたとしても想定の範囲内で収めることが可能です。

しかし、フリーランスエンジニアとの仕事では、会社に依頼した場合のような安定感はなかなか望めません。
やはり、ノウハウや技術が属人化しており、極端な話契約したフリーランスエンジニアが体調を崩したり、個人的な事情で仕事が続けられなくなったりというリスクはついて回ります。
会社の場合には、法人としてプロジェクトに対する責任を負っているため必ず継続のための対策を講じますが、フリーランスエンジニアとの仕事の場合には、どうしてもやむを得ない事情でプロジェクトが頓挫するということもあり得ることは認識しておきましょう。

最近フリーランスとの契約形態として人気の出てきている「クラウドソーシング」でシステム開発を依頼する場合も、こうしたリスクから完全に免れているわけではありません。
クラウドソーシングではフリーランスとの間にクラウドソーシング運営会社が入って、よくあるトラブルの回避や支払い管理（事前デポジット入金方式）などをやってくれます。

しかし、結局最後に満足のいく納品物が出てくるのか、途中でプロジェクトが頓挫することはないのかなどについては、クラウドソーシング運営会社は責任を負いません。
取引のためのプラットフォームは提供し、最低限のトラブル回避のためのノウハウやサポートは提供するが最終的な責任は負わないというのがクラウドソーシングの実態です。
そう考えると、クラウドソーシング運営会社が入るよりも、実際にフリーランスエンジニアと顔を突き合わせていろいろな確認作業をしていったほうが大きなトラブルには遭遇しないという見方もできます。

したがって、小規模で短納期、さらに納品後のメンテナンスなどがほとんどいらない案件などはフリーランスエンジニアを上手に使っていくことにメリットもありますが、中規模以上の案件はやはり会社と契約したほうが安心感は高いと言えるでしょう。

「アイミツ」に相談していただければ、実績のあるフリーランスエンジニアを含め、コストパフォーマンスもよく、個人と同じような小回りの利く機動力ある開発会社もご紹介できますので、ぜひお声をかけてください。