ITシステム開発「契約」の教科書 第2版 単行本（ソフトカバー） – 2023/1/23 池田 聡 (著)
この本の著者 池田 聡弁護士先生は、みずほ銀行の出身でシステム障害を現場で体験された方である。
契約書の中で一番重要な事は、債権債務を明確にするため開発の対象、金額、納期。また紛争に備えて、解決清算の指針となる条項に契約解除、損害賠償、管轄裁判所。そして開発を成功に導く条項に体制、責任者、作成物（承認方法）の条項。
元みずほ銀行の池田弁護士も「システム開発の失敗事例の過半は、要件定義に問題があった為」と主張している。契約書には、「要件定義の承認には、システム開発会社（ベンダー）の承認も必要と明記すべきと。なぜなら、委託者に責任を一方的に押し付けられないようにするため。更にベンダには高裁が判示した義務がある。当事者の役割や行動に関する指針となるような契約書となるよう意識すべき。開発対象のソフトウェアは、要件定義工程によって決められる。
プロジェクトマネジメント義務。判例で「常に進捗状況を管理し、開発作業を阻害する要因の発見に努め、これに適切に対処し、かつ、注文者のシステム開発へのかかわりについても、適切に管理し、システム開発について専門知識を有しない注文者によって開発作業を阻害される行為がされることのないよう注文者に働きかける義務」
一方、ユーザーには「協力義務」かあり、従という関係ではない。ユーザーの開発に関する情報、知見、経験等によってベンダの義務が低減する非対称性がイメージ。いずれにしても、ユーザーからの積極的な情報提供や協力なしには、仕事が進まない。みずほ銀行統合時の最初のシステムトラブルも、情報提供を求めるベンダに銀行側は、「顧客情報だから教えられない」と拒否したという。
そもそも要件定義が固まって、その工数を踏まえて見積もりを出せるので、多段階契約がメインで、一括契約は工数が固まっている例外と言えます。
債務は契約で発生し、履行されなければ債務不履行となります。システムが完成できない（履行不能）、遅れる（履行遅滞）などです。債務不履行と因果案系がある損害（通常損害）を損害賠償として請求できます。加えて予見すべきだった損害（特別損害）も賠償範囲となります。システム開発の契約書で、損害賠償の制限条項の扱いは、非常に重要なポイントです。そして債務の内容は契約で決まるので」、契約に書いていることを履行しないと原則契約解除事由になり、催告解除の対象となる。しかし軽微な不履行だと解除は難しい。
システム開発には、著作権が付き物。必ず契約書に扱いを記す。しっかりとした文言で条項を組み立てないと、権利関係の不具合が生じる。著作権の要件は創作性です。アイディアは特許権です。特許権は、特許の審査があります。特許の扱いも記載事項です。作成プログラムが特許になるのでしたら、所有権の扱いが重要です。下請けとの契約も元請けに著作権を移転する条項をいれてないと、ソフトウェアの完全な著作権を元請け経由でユーザーに移転できない。また著作権の共有は、自分で使うにも、譲渡、許諾にも共有者全員の同意が必要。ベンダからの著作権譲渡には、ソースコードも譲渡を受ける事。譲渡には当然ソースコードが入っている訳ではない。著作権の譲渡は、ただ著作権譲渡では、27条28条は動かない。ちゃんと27と28条を譲渡すると記入しないと完全な著作権は移転しない。あと著作人格権を行使しないという文言も必要。あと独占禁止法がらみで、「譲渡金額は、委託費に含む」との記述も必要。
下請法・・・この法律はあらゆる業種にかかるのではなく、運送や倉庫の役務提供、製造、修理委託、プログラムの作成の委託という業種に限られて適用される。また会社の資本金がフィルターとなっている。3条書面の交付義務など記載項目を契約書に反映した方がよく（反映されなければ別の書面で3条書面を交付）支払いも、納品から60日以内となっていて、遅れれば遅延利息の支払い義務と役所から罰金、勧告措置、公表などペナルティーがある。その他書類の保存義務、禁止事項など細かく決まっている。
その他、偽装請負（委託者の社員が、受託者の社員個人に指示命令してしまう事）に気をつけないといけない。指示命令系統を生じさせない。
ソフトウェアの開発委託契約書には、独立行政法人情報処理推進機構が作成した契約書がひな型として利用されているが、大手ベンダと大企業の取引に使われてきた。例えば重要インフラ、企業基幹システムなど大規模な案件を対象としている。なので中型、小型の取引には帯が長い（使わない条項が多数ある）
ソフトウェア開発基本契約書（多段階契約）
基本契約＋個別契約の構成。要件定義は準委任契約にあまり争いはないが、外部設計、システムテスト、導入受入支援、運用テストを請負にするか、準委任にするかで判断が分かれる。この本の著者は、ユーザーの立場で言えば、外部設計を準委任でその他は請負がいい。ベンダとしては、ユーザーの決定がないと仕事を完成できない導入受入支援、運用テストも準委任にするのが好ましい。
タイトル前文
目的（契約を紛争で解除する時に重要な要素）
定義 （本契約で用いる用語の意味を記す。一方が、そういう意味で使ってないとか解釈のすれ違いを防ぐ為）
個別契約 （基本契約に対しての個別契約。その個別契約のルールを記す。どちらが優劣か？ また、個別契約には、作業項目・範囲、準委任、請負契約の表示、作業分担、作業期間、成果物、納入場所、納期、委託代金、その他必要事項を記載する。注文書、請負書でも良い。
運用条項 （準委任契約と請負契約のかかる条項を記す）
委託料及び支払方法 （いくら、いつまで、どういった方法でしはらうか？下請法の規制に注意。そして、ベンダの社員の必要経費はベンダの会社が委託料で払うと明記。偽装請負を疑われない為。それと支払の振込手数料の振り込む側の負担を明記。）
作業期間、納期 （始期と終期を明確に。いつから6か月？のどにならないように〇年〇月〇日～〇年〇月〇日まで。解釈の違い認識の違いが生じない表記の仕方を徹底）
再委託 （記載しなければ民法が適用され、請負は、再委託自由。準委任は、委託者の許可が必要。デザインとか全て一社でやらない。協力会社と組んで仕事を完成させるのが現実。ユーザーは情報漏洩などの防止の為の条項を追加しておく。再委託状況の把握とベンダに情報管理の徹底をお願いする条項。
協働と役割分担 （システムを作るときユーザーの判断がないと進めない項目が多い。デザインでも、何色にしますか？ 青系にして見せて、褐色系がいいかな？こういう委託者と受託者のキャッチボールで作られていきます。協働作業が不可欠。委託者も必要な決定をしないで作業が遅延したら法的責任を負う形にもっていく条項を）
責任者 （会社によって組織や責任者の権限が様々。決めるのに誰に話を持って行き承認を得ればいいのか？この案金はあそこの課、これは別の課、いや越権！これはうちの課。では収拾がつかないので、開発責任者を契約で委託者側と受託者側で決めて開発を進めていきましょう。という体制、権利義務の明確化）
主任担当者 （サブリーダー。開発の規模により責任者の下に設置する）
連絡協議会 （意思疎通を活発にさせる定期的な会議。契約書で責任者出席で月何回開催すると決めておく。議事録作成が不可欠。何が決定事項か明確に共有する。誤解、すれ違いなどが、後々の紛争の種となる）
要件定義書・外部設計書 （契約書に固めておく事で、受託者はシステムの完成義務が生じ、委託者は、追加要件を軽々しく言えなくなる。）
課題管理 （双方の会社にシステム開発に関する課題が発生した場合、記録をし、解決に向けた責任者とスケジュールを管理する。問題が起きた時、放置させない条項
変更管理手続（システム開発が失敗する原因は、内部設計以降に要件定義、外部設計の不備が発覚して後戻りしてしまう事。変更する場合連絡協議会で委託者と受託者の合意を経て、増加工数分の対価を明確にして変更契約書を締結する。）
資料の提供・管理等 （開示ついて、善管注意義務、複写、返還についての取り決め）
開発環境の提供 （偽装請負とみなされない為に必要な条項）
秘密情報 （別契約で秘密保持契約NDAを最初に結んでからシステム開発の話に入る事も多いでしょうが、改めてシステム開発基本契約書でも条項を設けておくのがいいでしょう）
個人情報 （流失した場合のダメージが大きいので、契約書に明記し、損害の賠償という形にして細心の注意を喚起する。なるべき委託は避けて匿名化して授受するのがベストだろう。）
納入物の所有権及び著作権 （支払いと同時に移転する。という形が不払いというリスクに対処できる。委託者側としては、作成と同時に、もしくは納入日に移転が好ましい）
著作権以外の知的財産権 （システム開発に伴うアイディアから特許権などの申請ができる場合がある。受託会社の開発会社の単独申請するのか、両者で共同申請するのか、そして実施権の設定や対価など決めておくことが多数）
知的財産権の侵害の責任 （システムに第三者の著作権を侵害していた場合、第三者の承諾を得ないでソフトウェアを使って紛争になった場合、開発した受託者が責任をもつという条項）
セキュリティー （不正アクセスによる情報漏洩に対処するため協議して仕様を決定する）
権利義務の譲渡禁止 （受託会社が、無断で下請け企業に契約上の地位を譲渡して、契約関係から離脱されてしまうような事を禁止する条項）
解除 （無催告解除は、例えば不渡りを出して倒産しそうだが、解除条項がない為解除できなく、契約関係から離脱できない。履行が不能の時も無催告解除が契約にあれば可能。催告は不要でも、解除通知は必要。それと催告解除。契約違反に対して是正を求めて相当期間に是正がない場合解除ができる。催告がなければ解除できない。軽微な契約違反だと解除は難しい。軽微で解除するつもりなら、～違反は軽微な違反ではないことをお互いに確認する。みたいな条項が必要。
ビジネス環境の変化や仕様の伝達漏れで、ベンダに仕様変更を求めた場合、ウォーターフォール型開発の場合、想定以上の金額と納期が示され紛争になる場合がある。その場合に仕様変更を合意できずに契約を解除する条項も入れておきたい。ベンダは契約通り開発すればいいが、ユーザーは完成させても契約目的を達成できなければ契約を終らせるしかない。解除してもそこまでの履行の割合に対して報酬は払う必要がある。算定基準をあらかじめ算定して合意して契約書に落としておけば紛争になりにくい。（アジャイル型なら仕様変更を想定しているので問題ないが、この開発のデメリットもある）
損害賠償 （システム会社の損害賠償上限条項はシステムにハグがあるという現実では仕方ないのかもしれないが、上限を契約書に定めても故意重過失の場合、裁判所はスルーされるので、注意が必要。委託者の側からすれば全額補償してもらいたいが、なかなか難しい。制限の種類など基準を設ける事も考慮に値するだろう）
反社条項 （一般条項として契約書に記載するのは努力義務として都道府県の条例に謳われている。）
契約の変更 （最初に契約した当事者の合意と書面に署名捺印が必要としておけば良い。現場責任者同士で変えられてしまうと契約が不安定になる）
裁判管轄 （専属管轄と記入しないと選択肢の一つと見做される）
協議条項 （紛争になりそうな状況でも、契約書に協議すると合意してるので、話し合いませんか？ときっかけを作る条項）
検収 （検収基準の明確な設定をあらかじめ決めておくことの重要さ。紛争の起きやすい見解の相違が現われる。手順、合格基準の明確化。ベイダ側に有利な、みなし検収条項も）
契約不適合責任 （検収完了後1年が一般的。記載しないと気が付かない場合、最長10年の時効まで引っ張れる。保守管理契約で対応するのが適切。契約不適合責任の対応にシステムのアップデートがしてなくてフリーズ原因だった場合、回復させる義務がない。仕様書との不一致が原因の場合は、契約不適合責任で無償で1年とか保守管理契約の中にいれて運用するのが現実的。不具合の全てを契約不適合責任の品質性能の不足でカバーできない。）
#契約書作成 #リーガルチェック #契約書審査 行政書士 千葉市 #業務委託契約書 #システム開発契約書
