ITビジネスの契約実務〔第2版〕 単行本 – 2021/10/18 伊藤 雅浩 (著), 久礼 美紀子 (著), 高瀬 亜富 (著)
ソフトウェア開発契約書（一括請負型）
要件定義を含めた全行程を1本の請負契約とする。どんなシステムを作るか見えてないので、いくらコストがかかるのか？どの位期間がかかるか？わからないのである。
どの位の赤字がでるのか、紛争含みの受注を覚悟するのか？保守契約5年縛りで、開発と保守契約の2本でコスト面をクリアするのか？工夫しないと一括請負型は受けない方がいい。特に全社型システム開発は、様々な部署から様々な仕様要求が来て、契約に縛られマズい状況に追い込まれる。相手の業務に無知なら、無茶ぶりは起きる。（例えば、消費税はモノやサービスの提供に課税されるのだが、普段スーパーで買い物して消費税を支払っている主婦がいるとする。ある時に家のガラスが割れたから、交換をガラス屋さんに依頼。交換後に請求書を見る。ガラス代＋消費税、設置料＋消費税と書いてある。クレーム案件となる。「ガラス代はモノを買ったものだから消費税が掛るのはわかるけど、設置料に消費税がかかるのはおかしいのではないか？」
こういった認識の齟齬からクレームとなり、紛争に至ります。一括請負型を選択するなら、契約前の事前の擦り合わせがとても大事です。
業務委託契約書（要件定義・準委任契約）
タイトル、前文、委託業務、準委任契約、作業分担（ユーザーがシステムの機能要件及び非機能要件をベンダに提示する。ベンダはそれに基づいて要件定義書を作成する。）作業期間、委託料及び支払方法、と続いて、要件定義書（ユーザーとシステム会社の責任者に承認させる。後になって要件が漏れてました。そんなシステムは技術的につくれません。と後出しを防ぐ）著作権（要件定義書にも著作権が発生する）
ソフトウェア開発基本契約書（アジャイル）
臨機応変型の開発形態。本来は、後からの仕様変更要求は、契約変更である。相手側は応じる義務は民法上なく、一度合意した事を履行を強制し変更に応じない権利を有しています。
しかし、それでは開発を進めて見えてくる要望に対応できません。アジャイルは要求、開発、テストを個別契約で繰り返す開発形態です。試行錯誤型なので完成につながらないデメリットもあり、大規模なシステム開発には向きません。
システム保守委託契約
議論となりやすいのは、障害対応は保守契約の範囲なのか否かです。問い合わせ対応の必要性。システムの提供時にマニュアル等の説明書や仕様書も提供されるが、それのみでユーザーが十分に対応できるか？使用方法や設定方法は？
保守委託契約とは、大きく2つあり、。1つは「運用」マニュアル手順の仕事。ネットワークの監視作業、サーバー動作のチェック、サーバールームの入退室管理、確認結果の報告書を作る。仕事をこなすには、マニュアルの製品機能を理解して、ハードウェアや様々なソフトウェアの仕様を覚える。バージョンが上がった場合、手順の変更に伴うマニュアルの修正。製品知識を知った上でドキュメントに落とし込む作業など。
2つ目は、「保守」システムの障害対応（アラート対応）。トラブルが起きた時どう対処するのか？技術的な問題を解決するのが大事な業務。障害マニュアルから対応フローに従って動くことになる。ある程度知識がないと、マニュアルを読み解けない。システムの構成、製品知識、ソフトウェアの理解。正業化プログラムを走らせ、監視ソフトウェアをチェックして、障害が大きければ責任者に連絡して、システムを止めてバックアップをしないといけない。そして、「問い合わせ」にも知識が必要。「こういった事象が発生して困っています。調査して復旧させたいがどうすればいいのか？」問い合わせ先のシステムエンジニアは「どういった環境で？OSのバージョンか？使っているソフトウェアの名前とバージョン？」どういったエラーが発していて、なぜ問い合わせたのか？と伝えられなければならない。それで、調査するにもログファイルが必要だったりするので、サーバーから集めてサポートセンターに送ったり、ネットワークのログをスクショして送ったりして傷害の状況を調査するための材料を送らないといけない。マニュアルに載っている手順とイレギュラーなログの収集を指示される間合いもある。サポートからのメールで手順が示されていて、コマンドを打ったりGUI（グラフィカルユーザーインターフェース）の画面を操作したりしてログを集めたりとか。サーバーが壊れる障害だったら、別のサーバーでサービスを立ち上げたり、壊れたサーバーをバックアップ、復旧操作とかも保守の仕事。あとマニュアルに書かれてない対応も、日頃相当な知識を広める努力をしておかないと対応ができない。マニュアル以外の事もしなくてはならないので技術力（トラブル対応力）が求められます。
契約不適合責任に基づいても、期限があるし緊急対応に応ずる体制になってない場合、どう解決すべきか？また契約不適合の範囲外であった場合（保守の範囲）立往生することになる。また長期に渡る契約なので慎重な交渉と検討を行った上で締結する事が最善。対応は平日の営業時間なのか？土日対応は？夜間は？契約不適合責任期間と有償対応の契約上の兼ね合いなど。
保守契約上再委託は認めるのか？システムが動いて生の情報が動いているので、守秘義務上再委託のリスクをとるのか？担当責任者を決めるべきか？様々な想定と丁寧な協議と契約締結が求められる。みずほFGは、システムを19年かけて完成させ、完成後システム人員を6割減らして、運用の失敗を招いて障害を起こしました。開発と運用は、システムの両輪です。ハグというものはシステムには付き物でなくせないです。運用でのバックアップ、復元力で対応していくしかありません。
SES基本契約
システムエンジニアリング（SE）サービス（S）建設業でいう「人夫出し」契約。偽装請負にかからないように契約上の細かな取り決めがある。人を抱えるが、何をやるかは決めてない点に契約の特性がある。
#契約書作成 #リーガルチェック #契約書審査 行政書士 千葉市 #業務委託契約書 #システム開発契約書 #ソフトウェアライセンス契約 #クラウドサービス利用契約 #販売店・代理店契約