SES・業務委託エンジニアへの指示

発注者からの直接の指揮命令は偽装請負になりうる。Slack・GitHubのログが証拠になる

なにが問題になるか

SESは「業務の成果や役務の提供に対して報酬を払う」業務委託契約であり、エンジニア個人の労働力を時間単位で買う契約ではありません。契約上は業務委託なのに、実態として発注者がエンジニアに直接指揮命令を行っている状態が偽装請負です。偽装請負と認定されると、発注者側は無許可の派遣受け入れとして、受注者側は無許可の派遣業として、双方が行政指導・罰則の対象になりえます。

線引きの基本は「何を作るか」と「どう作るか」の区別です。

• 許容される範囲：成果物・仕様・納期など「何を作るか」の合意（「このAPIを今月末までに実装してください」「仕様書はこちらです」）
• リスクが高まる範囲：「どのように作るか」「いつ・どこで作業するか」の細かい管理

コードレビューの線引き：「セキュリティ要件を満たしていないため修正が必要」「計算量が仕様の上限を超えている」といった成果物の品質・仕様への適合を確認する指摘は許容されます（成果物の受け入れ判断）。問題になるのは「この変数名はこの命名規則に従え」「今すぐこの行をこう書き換えろ」といった作業プロセスや実装スタイルへの逐一指示です。

スクラムは構造的に偽装請負になりやすい：デイリースクラムで発注者側のスクラムマスタが「AさんはこのIssue、BさんはそのIssue」と個別にタスクをアサインすると指揮命令に該当します。許容されるのは「バックログの優先順位を伝える（何を作るか）」まで。「誰がどのタスクをいつやるか」の決定は受託側の責任者が行うべきです。

そして現代の開発現場では、Slackのメッセージ・GitHubのコメント・Jiraのチケットアサイン履歴がすべてログとして残り、「誰が誰にどんな指示を出していたか」の有力な証拠になります。「口頭で指示していただけです」が通じた時代とは違います。

なお、これは法人のSES会社に限らず、個人のフリーランスへの業務委託でも同様です。「フリーランスだから問題ない」という理解は誤りです。

確認すべきこと

• SES・業務委託エンジニアが参画する場合、指揮命令の経路（発注者→受託会社の責任者→エンジニア）を設計した
• Slackのチャンネル設計が「発注者↔受託会社の責任者」「受託会社の責任者↔エンジニア」の経路を意識した構成になっている
• 成果物・仕様を契約・仕様書レベルで明確に合意し、日々の作業方法には発注者側が立ち入らない運用になっている
• コードレビューの指摘が「成果物の品質・仕様への適合確認」の範囲に収まっている
• スクラムのタスクアサインを受託側の責任者が行う運用になっている

こんな仕様が出たらアラート

• 発注者側の社員が業務委託エンジニアに直接Slack・メールで作業指示を出している
• 発注者側のPMがJira・GitHub・Backlogなどで業務委託エンジニアにタスクを直接アサインしている
• スクラムのデイリーで発注者側が「誰が何をやるか」を個別に割り振っている
• GitHubのコードレビューで実装スタイル・命名規則など作業プロセスを細かく指定している
• 常駐先の就業規則・勤怠管理に業務委託のエンジニアが従っている
• 社内勉強会・朝礼・清掃など業務と無関係な活動への参加を求めている

あわせて確認

• 発注書・支払いのルール → フリーランス・外注先への発注