トラブルを防ぐシステム開発契約書の作り方

こんにちは。弁護士・ビジネスコーチの波戸岡光太です。

今回は、システム開発における業務委託契約、特に中小企業間で行われるシステム開発契約の契約書作成についてお話しします。

工程が多く細かいシステム開発ですが、双方が納得できる契約書作成のポイントをお伝えします。

どの案件にも共通する部分はひな形活用が効率的

 契約書を作成する際は、ひな形を活用するのが早くて便利です。ですが、ひな形はどの程度信頼できるのでしょうか。

 結論から言うと、システム開発の契約書作成では、案件ごとにさほど変わらない部分についてはひな形を活用したほうが、時間の節約になります。
　・再委託の可否
　・納品時期
　・品質保証
　・機密保持
　・個人情報
などについては、それほど大きく変わらない項目なので、ひな形を参考に作成すると良いでしょう。

個別性の高い内容は案件ごとに取り決めを

 その一方で、案件ごとに個性がある部分には工夫が必要です。開発対象や検収基準などは個別性が高いので、案件に合わせて契約書ごとにきちんと言語化する必要があります。

 システム開発をめぐる紛争の多くは、「何を作る約束だったのか」（＝開発対象）を明確にし、「それが完成しているのか」の判断基準（＝納品検査基準）を明確にしておくことで防ぐことができます。そのためには、要件定義、仕様書、設計書をできるだけ詳細に作成するのがポイントです。

 案件に合わせ言語化したほうがよいのは、以下の4つです。
　●開発対象
　●納品検査基準（検収基準）
　●契約不適合責任
　●知的財産権

それぞれ、詳しく解説しましょう。

１．開発対象は明確に定める

 システム開発は、ざっくりと以下の流れで進みます。

① 要件定義：何を実現したくて、何を作るのかを定める
↓
② 仕様書：そのために、具体的にどんな機能を備えるのかを定める
↓
③ 設計書：それをどうやって作るのかを定める
↓
④ 開発：それを実際に作る（プログラミング）
↓
⑤ テスト、実装：それを実際に動かしてみる（運用）
↓
完成

特に重要なのが①要件定義と②仕様書で、これらを決めるには発注者（ユーザー）と開発者（ベンダー）の密なコミュニケーションが必要になります。

①要件定義。先ずは「何を実現したいか」を共有します。実は、共有しているつもりで、案外とできていないことが多いです。

ユーザー：こんな感じのシステムを作って欲しいんだけど。
ベンダー：（こんな感じって…？）えっと、こんな感じで作りました！
ユーザー：思っていたのと全然違う！使えないよ！
ベンダー：そんなこと、聞いてませんよ。ともかく納品したので支払いお願いします。
ユーザー：依頼した内容と違うのに払えるわけないでしょ！

こんな感じでトラブルになるケースが多いのですが、どこが問題だったのかわかりますか？

そうです！「こんな感じ」をきちんと言語化していないことです。
そのため、何を作るのか、ゴールが明確になっていませんでした。コミュニケーションを密にとり、“そのシステムを使って何を実現したいのか”という本当のゴールを見える化しておけば、このようなことは起こらないはずです。

 ②仕様書についても、どんな機能を備え、どんな情報を得て、どんな動きにするのかを協同作業のなかで構築し、言語化しておくことが重要です。

 なかには「専門外だから」とベンダー任せにしてしまうユーザーもいますが、教え、教わりながらの関係の中で共通認識を持てるようにしておくことが大切です。

 ベンダー側も、ユーザーと認識があっているか、想定が共有できているか確認しながら進めるようにしましょう。

 また、システム開発は、進めていく中で仕様や機能の追加・変更を行うことも多いので、その際の追加費用の有無について定めておくとともに、新たな合意事項について書面化・記録化しておきましょう。

２．納品検査の基準を定める

よく、建物建築に例えられるシステム開発ですが、建物建築と大きく異なるのは、完成引き渡し後も引き続き作業が発生することがある、ということです。

システム開発では、仕様書・設計書に基づいてやるべきことは完了し実装したけれども、なお改善の余地があったり、メンテナンスしながら動かしてみたりすることはよくあります。軽度なバグがあることも当たり前と言えるでしょう。熱心なベンダーであればあるほど、ユーザーが満足いくまでとことんつきあうことになり、どこが完成なのかわからなくなってしまいます。

 そうならないためにも、納品検査基準（検収基準）として、仕様書や設計書に照らし合わせてのテスト項目、テスト方法を定めておき、「約束したものができているのか」の判断基準を契約書に盛り込んでおくようにしましょう。

 システム開発には開発の流れに沿って上流工程から下流に開発を進める「ウォーターフォール型」と、それぞれの工程で繰り返し事実を把握しながら進める「アジャイル型」があります。アジャイル型の場合はその特性上、テスト項目やテスト方法を定めることは難しいでしょう。ですから、納品検査基準を明確にしておく必要の高いユーザーとの取引では、ウォーターフォール型を選択し、テスト項目、テスト方法を定めることを検討するものも一案です。

 ３．契約不適合責任（瑕疵担保責任）について定める

 2020年４月から施行された改正民法では、「瑕疵」という用語がなくなり、「契約不適合」（＝契約の内容に適合しないもの）という用語が用いられるようになりました。

 改正のポイントは次のとおりです。
①欠陥品だとか、契約で定められた品質を満たさない「契約不適合」品の場合は、修理（履行の追完）、代金の減額、損害賠償、契約解除といったメニューが一定要件のもとで認められる。
②①の責任追及は、「注文者がその不適合を知った時から１年以内に通知」すればよい。

ただ、これはあくまでも契約書に契約不適合責任についての取り決めがない場合に適用される規定です。もちろん、契約書において自由に欠陥や不具合についての担保や保証規定を定めておくことも可能です。

例えば、①要件定義や②仕様書で定めた内容を満たしていないものを「契約不適合」と定義するほか、責任を負う期間を、「知った時から」ではなく、「納品時」とか「検査合格時」から１年とか６か月と定めるなど、ベンダーが負う責任の範囲や期間を明確にしておきましょう。

また、単に責任を負う負わないだけでなく、いつまでが無償対応で、いつからが有償対応なのか、という定め方も検討するとよいでしょう。

４．知的財産権の帰属について定める

システム開発に伴って、著作権をはじめさまざまな知的財産権が生まれることがあります。その場合に、どの範囲でどちらが権利を持つのかを定めておくようにしましょう。

安易に共有財産にしてしまうと、どんな場合でも相手の了解がないと使えないということになり、かえって使い勝手が悪い場合も出てくるので注意しましょう。

まとめ

システム開発契約書作成で注意すべきポイントを整理しました。

システム開発は、ユーザーとベンダーとが声を掛け合いながらキャッチボールをし、一緒にゴールを目指すようなプロジェクトです。契約書は、お互いがルールを守りゴールにたどり着くための明確なルールブックとなるようにしておきたいものです。

 とは言え、契約書で要件定義などをどれだけ細かく定めても、それだけでうまく進むとは限らないのがシステム開発です。ですから、いざというときに主張できる状況は作っておくべきだと私は考えます。先ずはこちらが正しい契約書を作った、正しい対応をした、正しい報連相を行ったという状況を作り、いざというときに有利に主張できる武器を持つことが重要です。その上で、強く出るのか要求を受け入れるのか、臨機応変に選択をしていただきたいと思います。

 システム開発の契約についてお悩みの会社様は、ぜひ一度ご相談ください。いざというときにしっかりと主張できる状態が作れるよう、精一杯サポートします。
https://hatooka.jp/index.html