偽装請負、無許可派遣、スコープ不明確、情報漏えい、知財、再委託、契約終了、支払遅延を、企業法務・労務・情報セキュリティの視点で整理します。
偽装請負、無許可派遣、スコープ不明確、情報漏えい、知財、再委託、契約終了、支払遅延を、企業法務 ・労務・情報セキュリティの視点で整理します。
契約書の文言と現場運用がずれると、単なる取引紛争を超えて複数の法領域に波及します。
SES契約は、IT人材不足を補うために広く利用される取引形態です。一方で、発注者がエンジニアへ直接指示を出す、勤怠や休暇を直接管理する、成果物責任と稼働責任が混在する、機密情報や個人情報の扱いが曖昧になる、といった運用が重なると、労働者派遣法、職業安定法、受託取引規制、個人情報保護法、著作権法、不正競争防止法、民法、独占禁止法、労働法制、情報セキュリティ規範の問題へ広がります。
個別案件では、契約書、個別契約、SOW、メール、チャット、チケット、勤怠記録、請求書、作業報告書、体制図、再委託関係を確認する必要があります。このページでは一般的な制度説明と実務上の整理を示し、具体的な判断や対応方針は専門家に相談する前提で読めるように構成しています。
次の一覧は、SES契約トラブルがどこから発生しやすいかを整理したものです。原因を先に把握することが重要なのは、契約書だけを直しても現場運用が変わらなければ再発するためです。どの原因が自社の案件に近いかを読み取ってください。
準委任、請負、派遣、業務委託、常駐支援という用語が混在し、何を約束した契約かが不明確になります。
契約上は委託でも、現場では発注者が個々のエンジニアへ直接作業指示や勤怠承認を行うことがあります。
作業範囲、成果物、検収、変更管理、障害対応、セキュリティ責任が文書化されていない状態です。
成果や役務の内容ではなく、人数、時間、常駐日数だけで管理され、実態が労務供給に近づきます。
契約審査で止まり、現場教育、モニタリング、ログ管理、是正措置、再発防止会議に接続していない状態です。
再発防止の中心は、契約書だけではありません。発注書、作業仕様書、体制図、運用ルール、チケット管理、会議体、勤怠処理、セキュリティ管理、委託先監査、インシデント対応を一体で設計することが重要です。
次の強調表示は、このページ全体の結論を短く整理したものです。なぜ重要かというと、SES契約のリスクは契約名ではなく現場実態で評価されやすいためです。自社の運用が人の管理に寄りすぎていないかを読み取ってください。
個人ではなく責任者へ依頼し、情報と権限を最小限にし、追加作業と支払条件を記録し、終了時には知識と権限を確実に引き継ぐことが、SES契約トラブルの再発防止の軸になります。
SESは法律上の典型契約名ではなく、契約内容と現場実態で整理する必要があります。
SESは、一般にSystem Engineering Serviceの略称として使われ、システム開発、保守、運用、インフラ構築、クラウド移行、ヘルプデスク、テスト、PMO、セキュリティ運用などで、ベンダー側のエンジニアが発注者のプロジェクトに参画する取引を指します。ただし、民法や労働者派遣法に定義された契約類型名ではありません。
次の比較表は、SES契約で混同されやすい契約類型を整理したものです。ここが重要なのは、契約タイトルだけでは責任内容が決まらず、支払、検収、指揮命令、成果物責任の設計が変わるためです。各類型で何を約束し、どこに注意すべきかを読み取ってください。
| 類型 | 中心となる約束 | SES契約での注意点 |
|---|---|---|
| 準委任 | 一定の事務処理や技術支援を行うこと | 成果物完成を当然に約束するわけではありませんが、善管注意義務、報告義務、秘密保持、引継、セキュリティ義務は問題になります。 |
| 請負 | 成果物の完成と検収 | 要件定義書、設計書、プログラム、テスト結果などの納品、検収、契約不適合責任、仕様変更管理が重要になります。 |
| 労働者派遣 | 派遣先の指揮命令下で労働させること | 派遣許可や派遣契約の枠組みが必要になります。委託契約のまま直接指揮命令が生じると重大なリスクになります。 |
| 混合型 | 技術支援と成果物作成が併存すること | 準委任作業と請負作業を個別契約で分け、成果物、検収、報告、支払条件を切り分ける必要があります。 |
準委任型SESでは、ベンダーは成果物の完成よりも専門的な役務提供を中心に負います。設計レビュー、技術調査、運用監視、障害一次対応、保守支援、コードレビュー、PMO、課題管理、テスト支援、脆弱性対応などが典型例です。
もっとも、準委任だから成果物責任が一切ないという理解は危険です。実際にはドキュメント、コード、設定ファイル、テスト結果、作業報告書などが発生し、知的財産権、検収、品質基準、報告義務、秘密保持、再委託管理、情報セキュリティ、損害賠償、契約終了時の引継が問題になります。
請負型開発では成果物完成が中心であり、納品、検収、契約不適合責任、遅延損害金、仕様変更管理を設計します。準委任型SESで同じように、完成しなければ報酬を払わないと設計すると、契約類型と実態がずれます。反対に、成果物完成を求めているのに契約書だけ準委任にすると、品質責任や検収をめぐる紛争が起きやすくなります。
偽装請負だけでなく、職業安定法、受託取引規制、フリーランス法、個人情報、知財が重なります。
SES契約で最も重大なリスクの一つは、偽装請負・無許可派遣です。契約上は請負や準委任などの業務委託でも、実態として発注者が受託者の労働者に直接指揮命令している場合、適法な委託から外れる可能性があります。
次の一覧は、SES契約トラブルが発展しやすい法領域を並べたものです。複数領域が同時に問題になるため、法務だけ、情シスだけ、購買だけで閉じない点が重要です。どの部門を巻き込むべきかを読み取ってください。
発注者が個人へ作業方法、勤務時間、休暇、配置、評価を直接管理すると、契約名にかかわらず問題になり得ます。
候補者を実質的に選別し、ベンダーが人材を送り込むだけの運用になると、職業安定法上の検討が必要になります。
情報成果物作成委託や役務提供委託では、支払遅延、買いたたき、不当減額、発注内容不明確化が問題になります。
顧客情報、ログ、ソースコード、設計情報、認証情報へアクセスするため、委託先監督と秘密管理が必要です。
ソースコード、設定ファイル、運用手順、テンプレート、既存資産、OSSの帰属と利用範囲を分ける必要があります。
雇用関係がなくても、常駐先での長時間稼働、人格否定的発言、メンタルヘルス問題は取引停止や損害に広がります。
次の比較表は、リスクを引き起こす典型的な運用と、予防のための管理項目を対応させたものです。発生原因と管理策を同じ行で見ることが重要です。自社の案件で未整備の項目を読み取ってください。
| リスク領域 | 問題になりやすい運用 | 管理の要点 |
|---|---|---|
| 偽装請負 | 発注者社員が、タスク割当、優先順位、作業方法、勤怠、休暇、残業を直接管理する。 | ベンダー責任者を連絡窓口にし、発注者は依頼、仕様確認、成果確認にとどめる。 |
| 労働者供給 | 事前面談が個人の採否決定のように運用され、ベンダーが業務管理を負っていない。 | 体制、経験、スキルセットの確認として位置づけ、議事録と選定基準を残す。 |
| 取適法・支払 | 支払遅延、不当減額、買いたたき、不当なやり直し、システム利用料の一方的負担がある。 | 発注書面、支払期日、価格協議、追加発注、争いのない部分の支払を管理する。 |
| フリーランス | 個人事業主やひとり法人に、発注内容、報酬額、支払期日、解除条件を曖昧にしたまま依頼する。 | フリーランス法の書面交付、支払、募集情報、ハラスメント対応の観点を確認する。 |
| 情報漏えい | 退場者アカウントが残る、私物端末や個人メールを使う、生成AIへ機密情報を入力する。 | 最小権限、MFA、ログ、端末暗号化、DLP、退場時削除、インシデント報告期限を定める。 |
| 知財 | 成果物、既存資産、汎用ノウハウ、OSS、第三者ソフトウェアの区別がない。 | 譲渡または利用許諾の範囲、改変、複製、グループ会社利用、再委託先利用を明記する。 |
典型例、法的問題、再発防止策を同じ視野で確認します。
次の比較表は、SES契約で繰り返し起きやすい15類型を、発生場面、問題の核心、再発防止策に分けて整理したものです。全体を一覧化することが重要なのは、個々のトラブルが別々に見えても、契約類型、指揮命令、スコープ、証跡不足という共通原因に戻るためです。自社の案件に近い行を起点に、必要な契約条項と運用改善を読み取ってください。
| 類型 | 典型例 | 問題の核心 | 再発防止策 |
|---|---|---|---|
| 直接指揮命令 | 発注者PMが朝会やチャットで個人へタスクを割り振り、休暇や残業も承認する。 | 準委任契約でも実態が派遣に近づき、偽装請負・無許可派遣のリスクが高まる。 | 発注者の依頼はベンダー責任者を通じ、チケットは依頼と優先度の記録にとどめる。 |
| 業務範囲不明確 | システム開発支援や運用保守支援とだけ書かれ、調査、改修、テスト、資料作成が積み上がる。 | どこまで月額報酬に含まれるか不明になり、追加費用と支払拒絶の争いが起きる。 | SOWに対象システム、工程、成果物、除外事項、軽微作業、緊急対応、変更手続を記載する。 |
| 成果物責任の混在 | 発注者は機能未完成を理由に不払いを主張し、ベンダーは時間稼働済みと反論する。 | 準委任と請負の債務内容が混ざり、検収、契約不適合責任、支払条件が不明確になる。 | 準委任、請負、保守運用を個別契約で分け、成果物がある場合は納品、検収、権利帰属を定める。 |
| スキルミスマッチ | 提案されたエンジニアのスキルが不足し、交代を求めても代替要員が確保できない。 | 個人選別が強いと人材供給に近づき、品質確保と偽装請負回避の両立が難しくなる。 | 個人ではなく体制、役割、スキルセットで確認し、交代手順、教育、引継期間を定める。 |
| 精算幅・残業 | 140から180時間の精算幅を超えても、固定月額か超過精算かで対立する。 | 時間精算の設計が曖昧で、深夜休日、オンコール、待機、移動、会議、教育時間の扱いが不明になる。 | 基準時間、控除・超過単価、端数処理、緊急対応単価、実績共有と事前協議を明記する。 |
| 再委託・多重下請 | 一次ベンダーの先に二次、三次、個人事業主がいて、契約主体や秘密保持の範囲が分からない。 | 委託先管理、労働者供給、個人情報、営業秘密、セキュリティ、フリーランス法の問題が複雑化する。 | 再委託を事前承諾制にし、再委託先名、範囲、所在地、教育、権限、同等義務を台帳管理する。 |
| 情報漏えい | 退場後も本番アカウントが残り、ソースコードや顧客データが私用環境に保存される。 | 個人情報保護法上の報告・通知、営業秘密管理、損害賠償、顧客対応に発展する。 | 最小権限、退場時即時削除、端末暗号化、ログ、MFA、DLP、インシデント報告期限を整備する。 |
| 知財・成果物利用 | スクリプトや設計書をグループ会社で使おうとして、利用範囲外と指摘される。 | 成果物、既存資産、汎用ノウハウ、OSS、第三者ソフトウェアの区別がない。 | 権利帰属と利用許諾範囲を、目的、地域、期間、改変、複製、再委託先利用まで定める。 |
| 障害対応 | 本番障害で、運用保守の責任か発注者の設定変更が原因かをめぐって対立する。 | 監視、一次対応、原因調査、暫定復旧、恒久対応、SLA、RTO、RPOの責任が不明確になる。 | 優先度分類、初動時間、連絡網、変更管理、バックアップ、ロールバック、ポストモーテムを定める。 |
| 契約終了・退場 | 終了直前に引継資料やアカウント一覧を求めたが、引継義務と費用が定まっていない。 | 業務継続性、セキュリティ、証跡、知財、未払費用をめぐる紛争になる。 | 終了予告、引継資料、返却・廃棄、アカウント削除、未解決課題、追加費用を定義する。 |
| ハラスメント | 発注者社員が深夜休日対応を強く求め、人格否定的発言により体調不良が起きる。 | 雇用関係がなくても、職場環境、安全配慮、ハラスメント防止、信用毀損のリスクがある。 | 禁止行為、相談窓口、調査協力、報復禁止、緊急連絡条件、過度な稼働防止を契約と運用に入れる。 |
| 減額・支払遅延 | 予算不足や期待水準未達を理由に、合意済み単価を一方的に減額する。 | 受託取引規制、民法上の報酬不払い、相殺、債務不履行が問題になる。 | 発注書、単価、支払期日、精算条件、支払留保条件、争いのない部分の支払を明記する。 |
| アジャイル開発 | POやスクラムマスターがベンダーエンジニアへ細かな作業指示をしているように見える。 | 協働と直接指揮命令の境界が曖昧になり、偽装請負リスクが高まる。 | 発注者は要求、受入基準、優先順位を提示し、作業方法と担当割当はベンダー側が決める。 |
| 生成AI・外部SaaS | コードレビューや障害調査のため、ソースコードやログを外部生成AIへ入力する。 | 秘密保持、個人情報、営業秘密、著作権、越境移転、利用規約、監査ログの問題がある。 | 承認済みツール、入力禁止情報、ログ取得、DLP、品質・脆弱性・ライセンス混入レビューを定める。 |
| 証拠不足 | 契約書、議事録、チケット、勤怠、リポジトリ履歴、障害ログが分散し、退場後に履歴が消える。 | 事実認定ができず、請求、支払拒絶、契約解除、行政対応、内部調査、再発防止が困難になる。 | 契約、発注、議事録、作業報告、ログ、承認記録、証拠保全指示、保存期間を一元管理する。 |
契約、業務、監査を分けて設計し、依頼と指揮命令の境界を現場に落とし込みます。
SES契約の再発防止では、法務部が契約書をレビューするだけでは不十分です。偽装請負や情報漏えいは、契約条項よりも現場運用で起きることが多いためです。
次の一覧は、再発防止策を三つの統制に分けて整理したものです。層を分けることが重要なのは、契約書、日々の業務、証跡・監査のどれか一つが欠けても、同じ問題が再発しやすいためです。自社に不足している統制を読み取ってください。
基本契約、個別契約、SOW、秘密保持、個人情報、セキュリティ、再委託、知財、解除、損害賠償を整備します。
体制図、責任分界、チケット管理、定例会、変更管理、障害対応、成果確認、引継を整備します。
台帳、ログ、月次レビュー、内部監査、委託先監査、教育記録、是正報告、再発防止会議を運用します。
RACIは、業務ごとに実行責任、最終責任、協議先、報告先を整理する方法です。この比較表が重要なのは、誰が決めるかを明確にすることで、直接指揮命令、品質責任、障害対応、証拠保全の曖昧さを減らせるためです。発注者とベンダーの責任分界を読み取ってください。
| 業務 | 発注者の役割 | ベンダーの役割 | 記録すべき証跡 |
|---|---|---|---|
| タスク依頼 | 要望、仕様、優先度、受入基準を提示する。 | 担当割当、作業方法、進め方を決める。 | チケット、議事録、合意事項 |
| 勤怠・休暇 | 業務影響の連絡を受ける。 | 出退勤、休暇、残業、健康状態を管理する。 | 作業報告、勤怠記録、連絡履歴 |
| 障害対応 | 優先度、影響範囲、顧客対応方針を決める。 | 一次対応、原因調査、復旧作業、報告を行う。 | 障害票、ログ、承認、復旧報告 |
| 権限管理 | アクセス許可範囲と承認者を決める。 | 利用者、端末、権限、退場時削除を管理する。 | 申請、承認、ログ、削除証跡 |
| 追加費用 | 変更要求の必要性、費用、納期を承認する。 | 影響範囲、見積、体制、リスクを提示する。 | 変更要求書、追加発注、請求書 |
次の比較表は、発注者から受託者への伝達を、比較的許容されやすい依頼とリスクの高い直接指揮命令に分けたものです。この区別が重要なのは、品質要求を伝えること自体は必要である一方、個人の作業方法や労務管理に踏み込むとリスクが高まるためです。日々の会議やチャットで使う表現を読み替えてください。
| 場面 | 比較的許容されやすい伝達 | リスクの高い伝達 |
|---|---|---|
| 仕様 | この画面仕様を満たしてほしい。 | あなたは今日このコードをこの手順で書いてください。 |
| 優先度 | 障害対応を優先したいので、ベンダー責任者と調整したい。 | Aさんは障害対応、Bさんは設計書修正をしてください。 |
| 勤怠 | 明日の会議に体制として参加可能か確認したい。 | Aさんの残業を承認します。休暇は当社に申請してください。 |
| 品質 | 納品物に不備があるので、体制として是正を求めます。 | Aさんの評価は低いので配置転換してください。 |
| 会議 | 課題共有、仕様確認、受入基準確認を行う。 | 日々の作業指示、進捗詰め、服務指導を行う。 |
次の判断の流れは、現場で依頼を出す前に確認すべき順番を示しています。この順番が重要なのは、急ぎの場面ほど発注者から個人へ直接指示が出やすいためです。依頼先、内容、記録、変更費用の確認順を読み取ってください。
発注者が決めるべき業務目的、受入基準、優先順位を明確にします。
個々のエンジニアではなく、管理責任者またはリーダーに依頼します。
SOW、個別契約、月額範囲、緊急対応条件と照合します。
チケットや議事録に依頼内容と合意事項を残します。
費用、納期、体制、リスクを合意してから着手します。
基本契約、個別契約、セキュリティ別紙、部門別の確認事項を接続します。
次の一覧は、基本契約、個別契約、セキュリティ別紙で確認すべき項目をまとめたものです。重要なのは、法務条項だけでなく、作業場所、ツール、権限、ログ、終了時処理まで契約文書に接続することです。どの文書に何を置くかを読み取ってください。
契約類型、業務内容、指揮命令、体制、報酬、変更管理、成果物、秘密保持、個人情報、セキュリティ、再委託、損害賠償、解除、監査、紛争解決を確認します。
契約統制プロジェクト名、対象システム、対象環境、業務目的、成果目標、作業範囲、対象外作業、体制図、作業場所、リモート可否、標準作業時間、精算幅、成果物、SLAを定めます。
業務統制情報分類、アカウント発行・変更・削除、MFA、端末管理、VPN、ログ保存、リポジトリ、本番環境アクセス、バックアップ、生成AI利用制限、インシデント報告を定めます。
監査統制次の比較表は、社内部門ごとの役割を整理したものです。部門別に見ることが重要なのは、SES契約トラブルは契約書だけではなく、発注、現場運用、支払、労務、セキュリティ、監査の連携不足から発生するためです。自社で責任者が空白になっている領域を読み取ってください。
| 部門 | 主な確認事項 | 実務上の問い |
|---|---|---|
| 法務 | 契約類型、偽装請負、再委託、個人情報、知財、損害賠償、終了時引継、受託取引規制、フリーランス法。 | 発注者が個人へ直接作業指示を出す予定はないか。 |
| 情報システム・PM | タスク依頼経路、品質改善要求、勤怠承認禁止、チケット、変更管理、最小権限。 | 依頼内容と合意事項をチケットや議事録に残しているか。 |
| 購買・調達 | 価格、発注書面、支払期日、取引先選定、再委託、反社チェック、価格協議。 | 単価交渉だけでなく、発注内容と支払条件を明確にしているか。 |
| 人事労務 | ハラスメント、長時間稼働、メンタルヘルス、労災、服務規律、入退館、緊急時対応。 | 受託者の雇用主と発注者の協力体制を整えているか。 |
| 個人情報・セキュリティ | 委託先評価、入場時教育、アクセス権限、ログ、インシデント対応、再委託、退場時削除。 | 個人データや本番環境にアクセスする外部要員を厳格に管理しているか。 |
| 内部監査 | 契約書と現場実態、発注書、体制図、指示経路、勤怠承認、再委託、権限、退場処理、証跡保存。 | 契約で決めた運用が現場で守られているか。 |
偽装請負、情報漏えい、支払・追加費用の場面ごとに、証跡保全と是正を優先します。
トラブル発生時は、いきなり責任追及や契約解除に進むのではなく、契約、実態、証跡、影響範囲、暫定措置を切り分ける必要があります。特にSES契約では、契約書の記載より現場実態が重要になる場面が多いため、チャット、メール、チケット、勤怠、ログ、議事録を保全することが出発点になります。
次の判断の流れは、偽装請負・派遣リスクが疑われる場面の初動を示しています。順番が重要なのは、直接指示の証跡を確認しないまま契約名だけで判断すると、是正策が現場に届かないためです。何を確認し、どの時点で運用を止めるかを読み取ってください。
基本契約、個別契約、SOW、発注書、体制図を確認します。
チャット、メール、チケット、会議録、勤怠記録から指揮命令の実態を確認します。
直接指示、勤怠承認、評価、配置指示、服務指導の有無を確認します。
直ちにベンダー責任者経由へ切り替え、必要に応じて契約類型の見直しを検討します。
再発防止策、現場教育、月次レビュー、内部監査を継続します。
次の時系列は、情報漏えいが疑われる場面で優先すべき対応を示しています。時間順に並べることが重要なのは、初動が遅れると証拠が消え、被害範囲や報告要否の判断が難しくなるためです。遮断、保全、報告、分析、再発防止の順番を読み取ってください。
漏えい対象、時刻、経路、関係者、影響範囲を特定します。
アカウント停止、アクセス遮断、ログ保全、端末保全を行います。
委託元、委託先、再委託先、個人情報の報告・本人通知の要否を確認します。
顧客、取引先、監督官庁、保険会社、外部専門家への連絡を検討します。
原因、暫定対策、恒久対策、再発防止報告書を整理します。
支払・追加費用トラブルでは、契約書、見積書、発注書、請求書、作業報告を確認し、合意済み範囲と追加作業を切り分けます。争いのない部分の支払、受託取引規制やフリーランス法の適用可能性、今後の変更要求書と追加発注の必須化を検討します。
発注前、入場時、月次、退場時で、確認すべき事項を分けて運用します。
次の比較表は、社内ルールを運用フェーズごとに整理したものです。フェーズ別に分けることが重要なのは、発注前の審査、入場時教育、月次点検、退場時処理のどこかが抜けると、指揮命令、追加費用、情報漏えい、証跡不足が再発するためです。各時点で最低限確認すべき項目を読み取ってください。
| 時点 | 確認項目 | 主な目的 |
|---|---|---|
| 発注前 | 契約類型、直接指示の必要性、ベンダー責任者、業務範囲、成果物、個人情報、本番環境、再委託、取適法、フリーランス法、セキュリティ審査。 | 契約と現場実態のずれを発注前に減らす。 |
| 入場時 | 契約書、個別契約、SOW、体制図、連絡経路、直接指揮命令禁止、秘密保持、個人情報、セキュリティ教育、最小権限、実作業者台帳。 | 現場で守るべきルールを共有し、権限を必要最小限にする。 |
| 月次 | 直接指示、勤怠承認、無償追加作業、作業報告、チケット、議事録、超過稼働、深夜休日対応、メンタル不調、権限過大、再委託変更。 | 契約と運用の乖離を早期に是正する。 |
| 退場時 | アカウント、VPN、リポジトリ、クラウド、入館証、端末、媒体、秘密情報、引継資料、未解決課題、削除証明、監査ログ。 | 情報漏えいと業務停止を防ぎ、証跡を残す。 |
条項例は案件ごとに調整が必要ですが、設計上の論点は共通しています。
次の比較表は、SES契約で条項化しておきたい骨子を整理したものです。条項名だけでなく、どのリスクに対応するかを見ることが重要です。自社ひな形に不足している論点を読み取ってください。
| 条項骨子 | 定める内容 | 対応するリスク |
|---|---|---|
| 指揮命令・連絡経路 | 受託者の従業員や再委託先従業員へ、労務管理上または業務遂行上の直接の指揮命令を行わないことを定める。 | 偽装請負、無許可派遣、労務責任分界 |
| 変更管理 | 業務範囲を超える作業は、変更内容、影響範囲、費用、納期、体制、リスクを記載し、合意後に着手する。 | 無償追加作業、支払紛争、スコープ拡大 |
| 再委託 | 事前承諾、再委託先への同等義務、秘密保持、個人情報、セキュリティ、知財、監査、責任主体を定める。 | 多重下請、情報漏えい、委託先監督 |
| 個人情報・セキュリティ | 目的外利用、第三者提供、無断複製、無断持出しを禁じ、事故時の報告、原因調査、証拠保全、再発防止協力を定める。 | 個人情報漏えい、営業秘密、監査対応 |
| 知的財産 | 発注者固有成果物、受託者既存資産、汎用ノウハウ、開発ツール、OSS、第三者ソフトウェアの帰属と利用範囲を分ける。 | 成果物利用制限、再利用紛争、OSS混入 |
| 契約終了時の引継 | 成果物、作業状況、未解決課題、運用手順、アカウント、資料、データの返還・削除、引継説明を定める。 | 業務停止、情報残存、追加費用紛争 |
次の一覧は、SES契約の再発防止を阻害しやすい誤解を整理したものです。誤解を明示することが重要なのは、現場担当者が善意で行う運用ほど、法的な境界を越えやすいためです。契約研修やキックオフで共有すべき認識を読み取ってください。
契約書の名称だけでは安全になりません。実態として誰が指揮命令し、受託者が独立して業務処理しているかが重要です。
品質管理と直接指揮命令は別です。仕様、受入基準、品質要求、不備指摘は、ベンダー責任者を通じて管理できます。
人月単価でも契約対象は労働力そのものではなく業務です。対象システム、責任範囲、成果物、除外事項が必要です。
常駐していても発注者の従業員ではありません。労務管理は受託者が行い、発注者は施設利用や安全・情報管理に必要な範囲を定めます。
現状把握、高リスク案件の是正、雛形整備、現場教育、監査改善の順で進めます。
経営者は、SES契約のリスクを法務部や情報システム部門だけの問題として扱わないことが重要です。重要システムの外部依存、多重下請構造、情報漏えい時の初動、価格交渉と支払実務、終了時の業務継続、ベンダー依存と属人化、社内PMの理解度を管理すべきです。
次の時系列は、実務で使える再発防止の進め方を5段階で整理したものです。段階化することが重要なのは、いきなり全契約を全面改定しようとすると現場が止まりやすいためです。まず棚卸しし、高リスク案件を先に直し、標準化と教育、監査へ進む順番を読み取ってください。
すべてのSES契約を台帳化し、契約類型、取引先、再委託、要員数、業務内容、個人情報取扱い、アクセス権限、直接指示チャンネルを棚卸します。
直接指揮命令が疑われる案件、本番環境・個人データにアクセスする外部要員、再委託構造が不明な案件、発注書や支払条件が曖昧な案件を優先します。
準委任型SES、請負型開発、保守運用、派遣契約を区別し、SOW、セキュリティ別紙、個人情報別紙、再委託申請書、変更要求書を整備します。
PM、情シス、購買、法務、セキュリティ担当に、直接指揮命令に当たり得る発言例、チケット管理、会議運営、勤怠確認、追加作業承認を周知します。
半期または四半期ごとに内部監査を行い、事故、紛争、支払遅延、退場トラブルを分析し、契約更新時にリスク、単価、範囲、体制、セキュリティを見直します。
一般的な考え方を整理します。具体的な判断は個別事情により変わります。
一般的には、契約書の名称だけで契約類型や適法性が決まるわけではないとされています。ただし、契約条項、成果物の有無、検収、指揮命令、勤怠管理、現場の運用記録によって評価が変わる可能性があります。具体的な対応は、資料を整理したうえで弁護士等の専門家へ相談する必要があります。
一般的には、仕様確認や成果確認のためのやり取りと、作業方法・勤務時間・配置・服務に関する直接指揮命令は区別して考えられます。ただし、質問の内容、頻度、会議体、チケット運用、ベンダー責任者の関与によって評価が変わる可能性があります。具体的な運用設計は、資料を整理したうえで弁護士等の専門家へ相談する必要があります。
一般的には、月額報酬に含まれる範囲は、個別契約やSOWで定めた業務内容、軽微作業、緊急対応、精算条件によって整理されます。ただし、追加依頼の内容、工数、発注経緯、承認記録、取引規制の適用可能性によって結論が変わる可能性があります。具体的な請求や支払の判断は、資料を整理したうえで弁護士等の専門家へ相談する必要があります。
一般的には、漏えい対象、時刻、経路、関係者、影響範囲、アクセス権限、ログ、端末、再委託先、個人情報の有無を確認するとされています。ただし、情報の種類、契約上の報告期限、法令上の報告・通知要否、証拠保全状況によって対応は変わります。具体的な初動は、資料を整理したうえで弁護士等の専門家へ相談する必要があります。
一般的には、全面禁止か条件付き許可かは、取り扱う情報、利用目的、ツールの契約条件、保存・学習利用の有無、ログ取得、越境移転、社内監査の体制によって設計されます。ただし、ソースコード、認証情報、個人情報、脆弱性情報を入力する場合は高いリスクが生じる可能性があります。具体的なルールは、資料を整理したうえで弁護士等の専門家へ相談する必要があります。
公的機関・一次資料を中心に、制度と実務の確認に使う資料名を整理します。