システム開発契約の実務2026｜請負・準委任と検収基準の決め方

「システム開発 契約」で検索する担当者の多くは、そのまま使える契約書のひな形を探しています。ところが実務で紛争になるのは条文の言い回しではなく、契約類型・検収基準・契約不適合責任・知的財産権の帰属という4つの項目が、ばらばらの前提で決められてしまうことです。この4項目は、要件がどれだけ固まっているかというただ1つの変数に合わせて、ワンセットで設計する必要があります。本記事では、タイの日系工場が生産管理システムを発注する場面を想定して、その決め方を整理します。

「システム開発 契約」で本当に決めるべきこと — 一般論では足りない理由

契約書のひな形はインターネット上にいくらでもあります。それでも発注側が不安を感じ続けるのは、ひな形が「どの条項を入れるか」しか教えてくれず、「自分たちの状況ではどう埋めるべきか」を教えてくれないからです。

システム開発の契約でトラブルになる論点は、結局のところ次の4つに集約されます。第一に、契約類型を請負にするのか準委任にするのか。第二に、何をもって完成とみなすのかという検収基準。第三に、納品後に不具合が見つかったときの契約不適合責任。第四に、できあがったプログラムの知的財産権が発注者と開発会社のどちらに帰属するのか。

重要なのは、この4つが独立した論点ではないという点です。4つはすべて「要件がどれだけ確定しているか」という同じ変数に支配されています。したがって、1つだけを有利に決めても契約全体は安定しません。むしろ、組み合わせを誤ると内部矛盾を抱えた契約書ができあがります。

もっとも典型的な矛盾が、要件定義が固まっていない段階で「一括請負契約」と「厳格な検収基準」を組み合わせてしまうケースです。請負契約は仕事の完成を約束する契約ですから、何が完成なのかが確定していなければ、そもそも約束の対象が定まりません。そこに詳細な検収基準を書き込むと、開発が進むにつれて「これは当初の仕様に含まれていたのか、それとも追加要望なのか」という論争が毎回発生します。発注側は「当然入っているはずだ」と言い、開発会社は「合意した範囲外だ」と言う。どちらも自分の理解では正しいので、着地しません。

逆のパターンもあります。要件も画面設計も完全に固まっているのに、開発会社の提案どおり全フェーズを準委任契約にしてしまう場合です。この場合、完成しなくても稼働した工数分の報酬が発生するため、発注側は完成のリスクをほぼ全面的に引き受けることになります。要件が固まっている局面でこれを受け入れる合理性はありません。

つまり、請負と準委任のどちらが正しいかという一般論には意味がありません。意味があるのは、自社の要件が今どの程度固まっているかを正直に評価し、その確定度に合わせて4項目をまとめて設計することです。本記事はその設計手順を扱います。

なお、費用の内訳がどう決まるのかについては業務システム開発の見積の内訳を解説した記事で、発注先そのものの選び方についてはタイのシステム開発会社の選び方で扱っています。本記事は費用やベンダー比較には踏み込まず、契約の法的な骨格だけに絞ります。

はじめにお断りしておきます。本記事は実務担当者向けのガイドであり、法的助言ではありません。個別の契約書の内容や、特定の紛争への対応については、必ず弁護士等の専門家に確認してください。

請負契約と準委任契約はどう違うのか

まず2つの契約類型の違いを、実務上の効果に絞って確認します。

請負契約は、受託者が仕事の完成を約束し、発注者がその結果に対して報酬を支払う契約です。ポイントは報酬が「結果」に紐づいている点にあります。約束した成果物が完成しなければ、原則として報酬を請求できません。

準委任契約は、法律行為ではない事務の処理を委託する契約です。受託者は善良な管理者の注意をもって事務を処理する義務を負いますが、成果物の完成そのものは約束しません。報酬は原則として稼働した期間や工数に対して支払われます。なお2020年4月に施行された改正民法では、準委任のうち成果に対して報酬を支払う型も明文化されており、準委任だから成果物を一切定義できない、というわけではありません。

実務解説でも、要件定義フェーズは準委任契約が向くという整理が一般的です。理由は明快で、要件定義とは「何をつくるかをこれから決める作業」だからです。何をつくるかが決まっていない段階で、その完成を約束させることは論理的に不可能です。それでも一括請負にしてしまうと、開発会社は不確実性の分をリスク費用として見積に乗せるか、あるいは範囲を狭く解釈して防衛的に振る舞うかのどちらかになります。どちらも発注者の利益にはなりません。

一方で、要件が確定した後の製造フェーズを準委任のままにしておくと、完成の責任が誰にもない状態で工数だけが積み上がります。ここは請負に切り替えるのが自然です。

つまり2つの類型は優劣ではなく、フェーズごとの適材適所です。1本の契約で全工程を覆おうとするから無理が出るのであって、フェーズを分けて類型を変えれば、どちらの欠点も避けられます。

どちらを選ぶべきか — 要件の確定度で決める

では、切り替えの判断はどこで行うのか。基準は「要件の確定度」です。抽象的に聞こえますが、次の3つの問いに答えられるかどうかで判定できます。

第一に、システムが扱う業務の範囲、対象拠点、対象部門が確定しているか。第二に、主要な画面と帳票の一覧が出ていて、それぞれの入力項目と出力項目が列挙できるか。第三に、既存システムや設備との接続点、つまり何と何を繋ぐのかが決まっているか。

この3つがすべて答えられる状態であれば、請負契約で製造フェーズを発注しても大きな齟齬は生まれません。逆に、1つでも「これから詰める」という答えになるなら、その部分は準委任のフェーズで先に固めるべきです。

この表を見ると、契約類型と検収基準が連動していることが分かります。準委任フェーズの検収は「報告書や要件定義書という中間成果物が、合意した内容を反映しているか」で判定します。請負フェーズの検収は「要件定義書に紐づくテストに合格したか」で判定します。前段の成果物が確定していなければ、後段の検収基準は書けません。この順序を飛ばすことはできません。

実務でよく聞かれるのが、「要件定義を準委任で別発注すると、その分だけ費用が増えるのではないか」という質問です。増えます。ただし、後述する独自試算のとおり、増えるのは見えている費用であり、削減されるのは見えにくい手戻りと遅延です。どちらが得かは一概には言えませんが、少なくとも「要件定義の費用が見積に乗っていない提案」は、その作業が消えたのではなく、誰かが無償で担うか、あるいは製造フェーズの中に隠れて紛れ込んでいるだけだと考えてください。

なお、スクラッチ開発とパッケージ導入のどちらを選ぶかによっても、要件の確定度の意味は変わります。パッケージであれば要件はある程度製品側が持っているためです。この分岐についてはスクラッチ開発とパッケージの3択を判定する記事で整理しています。

検収基準はいつ、何を基準に決めるべきか

検収は契約の中でもっとも揉めやすい局面です。実務ガイドでも、検収トラブルの最大の原因は検収基準が曖昧であることだと指摘されています。そして対策として、検収基準は開発に着手する前に決めておくべきだとされています。

当たり前のようですが、実際には守られていません。多くのプロジェクトでは、契約書に「発注者は納品後の所定の期間内に検査を行い、合格した場合は検収書を交付する」といった手続きだけが書かれ、何をもって合格とするかは書かれていません。この状態で納品を迎えると、発注者は自分の期待値を基準に判定しようとし、開発会社は仕様書の記載を基準に判定しようとします。両者の基準が違うので、検収は必ず紛糾します。

近年の実務では、検収を1回で済ませず、要件定義完了時、設計完了時、最終検収というように複数のタイミングに分割する中間検収が増えています。理由は2つあります。1つは、後になるほど手戻りのコストが跳ね上がるためです。要件定義書の段階で気づけば修正は文書の書き換えで済みますが、テスト工程で気づけば設計・実装・テストのすべてをやり直すことになります。もう1つは、発注者が実物を見るタイミングを前倒しできるためです。文書だけで完成形を想像するのは誰にとっても難しく、画面のプロトタイプを早い段階で確認できれば認識のずれを早く発見できます。

検収基準を書くときに、最低限そろえておきたい項目は次のとおりです。

• 検収の対象。どの成果物を、どの単位で検査するのか
• 判定の方法。テスト項目書に基づくのか、実機での操作確認か、書面の査読か
• 合否の線引き。軽微な不具合は合格としたうえで別途是正するのか、すべて解消してから合格とするのか
• 検査の期間。納品から何営業日以内に判定するのか
• みなし検収の扱い。期間内に発注者が判定しなかった場合にどう扱うのか
• 不合格時の手続き。再納品の期限、再検査の範囲、費用負担

このうち発注側が見落としやすいのが、みなし検収と、軽微な不具合の扱いです。みなし検収の条項があるにもかかわらず社内の検査体制を準備していないと、繁忙期に納品を受けて誰も触らないまま期限を過ぎ、自動的に合格扱いになります。また、軽微な不具合を一切認めない基準にすると、稼働開始がいつまでも訪れません。実務上は、業務が回るかどうかで合否を判定し、軽微な不具合は期限を切って是正する形が現実的です。

相見積もりの段階で各社に検収基準の案を出させるという方法もあります。提案書の比較軸としても有効です。この進め方は生産管理システムのRFPを扱った記事で詳しく整理しています。

契約不適合責任とは — 旧・瑕疵担保責任との違い

納品して検収に合格した後で不具合が見つかったとき、どこまで開発会社に直してもらえるのか。これを定めるのが契約不適合責任です。

2020年4月に施行された改正民法によって、それまでの瑕疵担保責任は契約不適合責任に改められました。名称の変更にとどまらず、実務に効く変更が含まれています。

もっとも影響が大きいのが、権利行使期間の起算点の変更です。旧制度では引渡しの時から1年以内に権利を行使する必要がありましたが、改正後は契約不適合を知った時から1年以内に通知すれば足りる形になりました。引渡しから時間が経ってから発見された不具合についても、発注者が救済を求められる余地が広がったことになります。

もう1つの変更が、救済手段の明文化です。改正民法では、追完請求と代金減額請求が明文で定められました。追完請求とは、不適合な部分を修補させる、あるいは代替物を引き渡させるといった、契約に適合した状態にするよう求める権利です。代金減額請求は、追完がなされない場合に、不適合の程度に応じて代金の減額を求める権利です。従来から損害賠償請求と契約解除は認められていましたが、そこに2つの選択肢が加わりました。

ただし、契約不適合責任の規定は当事者の合意で変更できます。実務では、契約書側で責任期間を短く設定したり、責任の範囲を「発注者が支払った委託料の総額を上限とする」と限定したりする条項が置かれることが少なくありません。開発会社が提示するひな形では、こうした限定が入っているのが通常です。発注側としては、条文の有無だけでなく、期間と上限額がどう書かれているかを必ず確認してください。

また、システム開発では「不具合」と「仕様変更」の線引きそのものが争点になります。合意した仕様どおりに動いているが業務上使いにくい、という状態は契約不適合ではなく仕様変更の要望です。この線引きを事後の議論に委ねないためにも、要件定義書と検収基準がどれだけ具体的に書かれているかが効いてきます。契約不適合責任の条項だけを厚くしても、比較の基準となる仕様が曖昧なままでは機能しません。

知的財産権はどちらに帰属するのか

発注してお金を払ったのだから、できあがったシステムは自社のものだ。これは自然な感覚ですが、法的にはそうなりません。

何も契約で定めなければ、開発したシステムの著作権は開発会社、つまり受託した側に帰属します。実際にプログラムを創作したのが開発会社の従業員だからです。発注者が著作権を得たい場合には、契約書で譲渡を明記しておく必要があります。

ここで見落とされやすいのが、改修する権利です。プログラムを書き換える行為は、著作権法上の翻案にあたりえます。したがって著作権が開発会社に残っている場合、発注者が別の会社に保守や改修を委託すると、著作権侵害になるおそれがあります。数年後に開発会社との関係が切れたときや、対応が遅いので別の会社に乗り換えたいと考えたときに、この問題が表面化します。

実務上の選択肢は、大きく3つあります。

• 著作権を全面的に発注者へ譲渡する。発注者にとってはもっとも自由度が高い。ただし開発会社は同種の資産を他案件に流用できなくなるため、見積が上がることがある
• 著作権は開発会社に留保したうえで、発注者に対して利用と改修の許諾を与える。第三者への保守委託を認める旨まで明記できていれば、実務上の不都合は小さい
• 汎用的な部分と個別開発部分を切り分ける。ライブラリや共通基盤は開発会社に残し、業務固有のロジックのみ発注者へ譲渡する

3つ目の切り分けは合理的ですが、境界が曖昧だと将来の紛争の種になります。どの範囲が汎用モジュールに当たるのかを、契約時点で具体的に列挙しておくことが望まれます。

なお、譲渡を定める場合は、著作者人格権の不行使についても触れておくのが一般的な実務です。著作者人格権は譲渡できない権利であるため、行使しない旨の合意という形をとります。この点は条文の書き方が結果を左右するため、弁護士の確認を受けることを強くおすすめします。

秘密保持(NDA)で見落とされやすい2つの穴

秘密保持契約は、提案依頼の段階で締結済みという会社が多いはずです。それだけに内容を精査しないまま雛形を使い回している例も多く、次の2点が抜けたまま運用されていることがあります。

1つ目の穴は、再委託先まで義務が届いていないことです。システム開発では、開発会社が一部の工程を別の会社やオフショア拠点に再委託することが珍しくありません。ところが秘密保持契約の名宛人が開発会社だけになっていると、実際に自社の図面や原価データに触れる人が契約の外側にいる状態になります。再委託を認めるかどうか、認めるなら同等の秘密保持義務を課したうえで再委託先の行為について開発会社が責任を負うことを明記しておく必要があります。

2つ目の穴は、目的外使用の禁止と、契約終了後の取り扱いが書かれていないことです。秘密保持契約の多くは「第三者に開示しない」ことは定めていますが、「本件業務以外の目的に使用しない」ことまでは定めていない場合があります。開示しなければ、自社の分析や他の提案資料に流用することは禁じられていない、という解釈の余地が残ります。また、プロジェクト終了後に提供したデータをどうするのか、返還するのか消去するのか、消去したことをどう証明するのかも定めておくべきです。テスト用に本番データを渡した場合、この一文の有無が実務上の差になります。

秘密保持契約は締結してしまうと見直されないまま何年も使われます。開発の契約を締結するタイミングは、この2点を点検するよい機会です。

実例に学ぶ — 契約の設計を誤るとどうなるか

契約設計の甘さが大規模な紛争に発展した例として、しばしば参照されるのがスルガ銀行と日本アイ・ビー・エムの間で争われたシステム開発紛争です。

報道によれば、東京地方裁判所は2012年3月29日に約74億円の支払いを命じる判決を出しました。その後、控訴審である東京高等裁判所は2013年9月26日に、この金額を約42億円に減額する判決を出しています。東京高裁は、プロジェクト初期の不確実性についてはユーザー企業側にも応分のリスク負担が求められるという判断を示したと報じられています。

本記事は判例評釈ではないため、法的な評価に立ち入ることはしません。実務担当者として押さえておきたいのは、次の点です。

第一に、金額の大小にかかわらず、争点になったのは「初期段階の不確実性を誰がどこまで引き受けていたのか」であったということ。第二に、その負担配分は、契約書の書きぶりとプロジェクトの進め方の両方から判断されたということ。第三に、一審と控訴審で判断が変わったという事実そのものが、この論点が容易に決着しないことを示しているということです。

裏を返せば、要件が固まっていない段階でどちらか一方に完成責任を全面的に負わせる契約は、規模の大小を問わず不安定だということになります。中小規模のプロジェクトで裁判まで至る例は多くありませんが、その代わりに、追加費用の交渉が長引き、稼働が遅れ、担当者どうしの信頼関係が壊れるという形で損失が発生します。金額として集計されないだけで、失われているものは同じです。

導入がうまくいかない要因は契約だけではありません。発注前に自社で決めておくべき項目全体については生産管理システムの導入失敗を扱った記事で整理しています。

タイで契約するときに追加で必要な3つの条項

ここまでは日本法を前提にした一般論でした。タイの現地法人が発注する場合、あるいは日本本社がタイの開発会社と契約する場合には、追加で確認すべき条項があります。日本で使っていた契約書をタイ語に翻訳しただけでは、機能しない契約書になりかねません。

第一に、準拠法です。どの国の法律に基づいて契約を解釈するかは、当事者の合意で選択できます。日本法を選ぶことも、タイ法を選ぶことも可能です。ただし選んだ準拠法と、後述する裁判管轄が食い違っていると、タイの裁判所で日本法の内容を立証する必要が生じ、手続きが重くなります。

第二に、言語の優先関係です。タイ民商法の規定により、複数の言語で作成された契約書について優先関係を明記していない場合には、タイ語版が優先すると理解されています。日本語版と英語版だけを交わして安心していると、後からタイ語の翻訳版が出てきたときに想定外の解釈が主張される余地が残ります。実務上の対応としては、英語版を正本と定めてタイ語版と日本語版を翻訳版と位置づけるか、あるいはタイ語版を優先すると明記したうえでタイ語の文言を精査するか、いずれかを選ぶことになります。曖昧なまま3言語を併記するのが、もっとも危険です。

第三に、裁判管轄です。タイ法人に対して支払いや損害賠償を請求する場面を想定するなら、紛争解決地をタイの裁判所に指定する合意が実務上は必須です。日本の裁判所で勝訴判決を得ても、その判決をタイで直接執行することはできないためです。日本法・日本の裁判所という組み合わせは日本側にとって心理的に安心ですが、相手方の資産がタイにある場合には実効性を欠きます。

もう1つ、契約類型そのものについても注意が必要です。タイ民商法には「Hire of Work」と呼ばれる契約類型があり、これが日本法の請負契約に近い概念にあたります。完成した仕事の結果に対して報酬を支払う契約として定義されており、条文としても整備されています。一方で、日本法の準委任契約、すなわち法律行為でない事務の委任に厳密に対応する契約類型は、タイ法には存在しません。

したがってタイの開発会社と要件定義フェーズの契約を結ぶときは、「準委任契約とする」と書いても意味が通りません。契約書の中で、その業務が成果物の完成を約束するものなのか、それとも役務の提供に対して対価を支払うものなのかを、業務の性質として具体的に記述して手当てする必要があります。成果物として何を提出するのか、報酬は何に対して発生するのか、完成の保証を含むのか含まないのかを、条文の言葉で書き切ることが求められます。

近隣国で開発する場合も、地域ごとの実務の違いは無視できません。ベトナムで開発する場合の論点はベトナムでのシステム開発を扱った記事にまとめています。

独自試算｜契約類型のミスマッチが生む手戻りコスト

ここまでの議論を、金額に置き換えてみます。以下はモデルケースに基づく独自試算であり、実在の企業の数値ではありません。金額の大きさそのものではなく、構造を確認するための材料として読んでください。

前提を置きます。タイの日系工場が生産管理システムの刷新を発注する場面を想定します。製造フェーズの契約金額は3,000,000 THBです。標準的な追加開発の単価は3,000 THB/人日、仕様変更1件あたりの標準開発工数は3人日とします。ここで、要件定義の確定度が異なる2つのケースを比較します。

ケースAは、要件定義の確定度が60%の段階で、製造フェーズを一括請負契約として締結した場合です。契約後に発生した仕様変更は8件でした。

オーバーヘッドの4,500 THB/件は、契約後に仕様変更を個別協議で処理するために発生する作業を金額化したものです。影響範囲の調査、見積の再作成、追加の合意形成会議を合わせて1件あたり1.5人日相当と置いています。請負契約では契約範囲の外にある作業を無償では進められないため、この協議が毎回発生します。

金額に表れないコストもあります。8件のうち複数のモジュールにまたがる変更は5件あり、これらは1件あたり平均6.4営業日の合意形成期間を要しました。合計すると5件 × 6.4営業日で32営業日が、クリティカルパス上の遅延として積み上がっています。この遅延は金額に換算していません。加えて、協議が長引くほど紛争化のリスクが高まり、担当者どうしの信頼関係も損なわれます。これらは定量化できませんが、実務上はもっとも重いコストになりえます。

ケースBは、要件定義フェーズを準委任契約として別に切り出し、確定度を95%まで上げてから製造フェーズを請負契約で締結した場合です。要件定義フェーズは期間2.5ヶ月、月額150,000 THBで、契約額は375,000 THBとします。

契約後に発生した仕様変更は2件まで減りました。追加コストの合計は27,000 THBです。ケースAの108,000 THBと比べると、108,000 ÷ 27,000 で4.0倍の差があります。差額は108,000 − 27,000 で81,000 THBです。

ここで正直に書いておかなければならないことがあります。ケースBでは要件定義フェーズに375,000 THBを先行投資しています。一方で削減できた追加コストは81,000 THBです。81,000 THBは375,000 THBを下回りますから、この投資はキャッシュの計算では回収しません。要件定義を分離すれば費用が下がる、という説明は正確ではないということです。

では、なぜ要件定義の分離を推奨するのか。回収されるのは金額ではなく、32営業日の遅延の回避と、紛争化するリスクの低減だからです。稼働が32営業日遅れることが自社の事業計画にとってどれだけの重さを持つのか、そして契約後の協議が紛争に発展したときに何を失うのかを、金額とは別の軸で評価してください。工場の稼働開始や決算対応の期日が動かせない場合、32営業日の遅延は81,000 THBの差額よりはるかに重い意味を持ちます。逆に、期日に余裕があり要件も比較的単純な小規模案件であれば、ケースAの進め方が合理的なこともあります。

いずれにしても、要件定義を準委任で切り出す判断は「安くなるから」ではなく「不確実性を先に潰しておきたいから」という理由で行うものです。過大な投資対効果を期待して始めると、期待外れに終わります。

契約書チェックリスト｜発注前に確認する項目

ここまでの内容を、契約書を受け取ったときに確認する順序に並べ替えます。開発会社から提示されたひな形を読むときは、この順に見ていくと抜けが出にくくなります。

このリストのうち、発注側が自分で決められるのは上から5つ、すなわち契約類型・業務範囲・成果物の定義・検収基準・検収の期間です。ここは開発会社に埋めてもらうのではなく、自社で案を持って交渉に臨んでください。残りの項目は、ひな形の記載を読み込み、不利な条件になっていないかを点検するという性質のものです。

一度にすべてを完璧にする必要はありません。ただし、契約類型・検収基準・契約不適合責任・知的財産権の4項目については、要件の確定度という同じ物差しで一貫しているかを必ず確認してください。この4つがちぐはぐな契約書は、どれだけ条項の数が多くても機能しません。

IPAのモデル契約書をどう使うか

契約書をゼロから作る必要はありません。公的機関が公開している中立的なひな形があります。

独立行政法人情報処理推進機構(IPA)は、2020年12月22日に「情報システム・モデル取引・契約書」の第二版を公開しました。ユーザー企業とITベンダのどちらにも偏らない中立的な内容を目指したひな形として整備されており、同じタイミングでセキュリティ仕様に関するガイドラインも公開されています。

このモデル契約書の価値は、そのまま使えることではありません。フェーズごとに契約類型を分ける考え方、検収の手続き、知的財産権の扱いといった論点が、どのような条文の形で整理されるのかを確認できる点にあります。開発会社から提示されたひな形と読み比べれば、どの条項が削られているのか、どの条項が一方に有利な形に書き換えられているのかが見えてきます。

実務での使い方としては、次の順序をおすすめします。まずモデル契約書を通読して、論点の全体像を把握します。次に、開発会社から提示された契約書を、モデル契約書の目次と突き合わせます。抜けている論点があれば、その理由を開発会社に確認します。そのうえで、自社の要件の確定度に合わせて、契約類型と検収基準の部分を書き換えます。

注意点もあります。モデル契約書は日本法を前提としているため、タイでの契約にそのまま適用することはできません。前述の準拠法・言語の優先・裁判管轄の3条項は追加が必要ですし、準委任という類型の扱いも読み替えが必要です。あくまで論点の抜け漏れを確認するための地図として使い、最終的な条文は現地の法務実務に通じた専門家の確認を受けてください。

よくある質問

請負契約と準委任契約はどちらが安全ですか？

どちらが安全ということはありません。要件が確定している工程では請負契約のほうが完成の責任を開発会社に負わせられるため発注者に有利ですが、要件が固まっていない工程で請負契約を結ぶと、仕様変更のたびに個別協議が発生して結果的に不利になります。安全かどうかは類型ではなく、要件の確定度との組み合わせで決まります。

検収基準はいつ決めるべきですか？

開発に着手する前です。検収基準の曖昧さがトラブルの最大要因であることは実務ガイドでも繰り返し指摘されており、着手前に確定させておくべきだとされています。納品直前に基準を作ろうとすると、双方が自分に有利な基準を主張するため、まとまりません。要件定義書を確定させるときに、その要件をどう検査するかまで同時に決めるのが理想です。

契約不適合責任の期間はどれくらいが妥当ですか？

一律の正解はありません。改正民法では契約不適合を知った時から1年以内の通知という枠組みになりましたが、契約書で期間を短く定めることは可能であり、実務ではそうした条項が置かれることが少なくありません。判断材料としては、システムの稼働が季節性を持つかどうかが目安になります。年に一度しか動かない決算処理や棚卸の機能がある場合、短い期間では不具合の発見自体ができません。

著作権は必ず自社に譲渡してもらうべきですか？

必ずではありません。譲渡を求めると見積が上がることがあります。実務上重要なのは、所有そのものよりも、将来にわたって改修できる状態を確保することです。著作権が開発会社に残る形でも、利用と改修の許諾があり、第三者への保守委託が認められていれば、実務上の不都合は小さく収まります。逆に、譲渡の条項があっても汎用モジュールの範囲が曖昧だと、結局どこまで自由に扱えるのかが分かりません。

日本の契約書をタイ語に翻訳すれば足りますか？

足りません。準拠法、言語の優先関係、裁判管轄の3条項が必要です。特に言語の優先関係を明記しないと、タイ民商法の規定によりタイ語版が優先すると解される点に注意が必要です。また、日本法の準委任契約に厳密に対応する契約類型がタイ法には存在しないため、業務の性質を条文の中で具体的に記述しておく必要があります。

小規模な案件でもここまで契約を作り込む必要がありますか？

金額の小ささと紛争の起きやすさは比例しません。ただし、限られた時間で優先順位をつけるなら、検収基準と知的財産権の2つを優先してください。検収基準は支払いの可否に直結し、知的財産権は数年後の乗り換えの自由度に直結します。この2つが押さえられていれば、他の条項が標準的なひな形のままでも、致命的な事態は避けやすくなります。

まとめ

システム開発の契約で決めるべきことは、契約類型・検収基準・契約不適合責任・知的財産権の帰属という4項目です。この4つは独立した論点ではなく、要件がどれだけ確定しているかという1つの変数に支配されています。したがって、ばらばらに決めると内部矛盾を抱えた契約書ができあがります。

請負と準委任のどちらが正しいかという議論には意味がありません。要件定義フェーズは準委任、要件が固まった製造フェーズは請負というように、フェーズごとに使い分けるのが実務的です。検収基準は着手前に決め、要件定義完了時・設計完了時・最終検収という複数のタイミングに分けることで、後工程での手戻りを小さくできます。契約不適合責任は2020年4月施行の改正民法で起算点と救済手段が変わっていますが、契約書で修正できるため、期間と上限額の記載を必ず確認してください。知的財産権は何も定めなければ開発会社に帰属します。所有そのものより、改修と第三者への保守委託が認められているかが実務では効きます。

独自試算では、要件の確定度が60%の段階で一括請負を結んだケースAの追加コストは108,000 THB、要件定義を準委任で切り出したケースBは27,000 THBで、4.0倍の差が出ました。ただし要件定義への先行投資375,000 THBは、差額81,000 THBだけではキャッシュで回収しません。回収されるのは32営業日の遅延回避と紛争リスクの低減という、金額化しにくい価値です。この点を誤魔化さずに社内で説明できるかどうかが、稟議を通すうえでも重要になります。

タイで契約する場合には、準拠法・言語の優先関係・裁判管轄の3条項を必ず追加してください。日本の契約書を翻訳しただけでは機能しません。そして繰り返しになりますが、本記事は実務ガイドであり法的助言ではありません。個別の契約内容については弁護士等の専門家に確認してください。

契約書の条項をどう埋めるかは、結局のところ自社の要件がどこまで固まっているかによって決まります。その確定度を自分たちで判断するのが難しい、あるいは開発会社から提示された契約書のどこを交渉すべきか分からないという段階でも構いません。タイでの生産管理システム導入と契約実務の経験から、状況の整理だけでもお手伝いできます。お問い合わせはこちらからご連絡ください。

参考情報

• BUSINESS LAWYERS — 請負契約と準委任契約の違いとシステム開発における使い分け
• BUSINESS LAWYERS — システム開発における契約不適合責任の実務
• 東京スタートアップ法律事務所 — システム開発における契約不適合責任
• ヒューマンナビ — システム開発の検収とは。トラブルを防ぐ検収基準の決め方
• 秀総合事務所 — システム開発における著作権の帰属と改修の権利
• 独立行政法人情報処理推進機構(IPA) — 情報システム・モデル取引・契約書 第二版
• 日本経済新聞 — スルガ銀行と日本IBMのシステム開発訴訟 控訴審判決
• GVA法律事務所 — タイでの契約実務と準拠法・言語・裁判管轄の考え方
• Legal Execution Thailand — タイ民商法 第7章 請負に関する規定