---
title: 人・組織系
description: SES・外注エンジニアへの指示と発注で確認すべきこと。Slack・GitHubのログが証拠になる
sidebar:
  label: 概要
---

「SlackでA社のエンジニアに直接タスクを振ってもいいですか？」「外注先のGitHubにコードレビューのコメントを入れても大丈夫ですか？」「フリーランスに頼んでいるので書面は省略していいですか？」。技術的な話ではないため「そういうのは人事や法務が考えること」と思われがちです。**しかしこのカテゴリで問われるのは、エンジニア自身の日々のふるまいそのものです。**

そして厄介なのは、**証拠が自動的に残り続ける**ことです。Slackのメッセージ、GitHubのコメント、Jiraのチケットアサイン履歴は、「誰が誰にどんな指示を出していたか」を日付つきで記録しています。「口頭で指示していただけです」が通じた時代とは違い、偽装請負の調査や訴訟では、これらのログがそのまま有力な証拠になります。しかも他のカテゴリと違って、リリース前に気づいて直せるものではありません。問題のある運用を続けた履歴は、後から消せません。

## こんな状況が現場で起きていたら

- 発注者側の社員が、業務委託エンジニアに**直接**Slack・メールで作業指示を出している
- 発注者側のPMが、Jira・GitHubで業務委託エンジニアにタスクを直接アサインしている
- スクラムのデイリーで、発注者側が「誰が何をやるか」を個別に割り振っている
- コードレビューで、命名規則や実装スタイルを逐一指定している
- 常駐先の勤怠管理・就業規則に、業務委託のエンジニアが従っている
- 朝礼・勉強会・清掃など、業務と無関係な活動への参加を求めている
- 「まず手を動かして」と、発注書なしで作業を開始させている
- 検収から支払いまでが60日を超えている／仕様変更を無償でやらせようとしている

## 機能別の確認事項

| 実装しようとしている機能 | 主な確認事項 |
|---|---|
| [SES・業務委託エンジニアへの指示](/features/people/ses-instruction) | **「何を作るか」の合意はよく、「どう作るか・いつ作業するか」の細かい管理が指揮命令になりうる**。指揮命令の経路（発注者→受託会社の責任者→エンジニア）を設計したか。Slackのチャンネル設計もその経路に沿っているか。**コードレビューは成果物の品質・仕様適合の指摘なら許容**、実装スタイルへの逐一指示は問題。スクラムのタスクアサインは受託側の責任者が行う運用か |
| [フリーランス・外注先への発注](/features/people/freelance-order) | **作業開始前に書面（メール・チャットの文面でも可）を交付**したか。報酬額と支払期日を発注時に明示したか。**受領から60日以内**に支払うフローになっているか。仕様変更を追加発注（追加報酬）として処理するか。**個人への発注ならフリーランス保護新法が資本金不問で適用**される |

## このカテゴリの勘所

**「何を作るか」と「どう作るか」の間に線があります。** 成果物・仕様・納期の合意（「このAPIを今月末までに実装してください」）は業務委託として自然な範囲です。一方、「どのように作るか」「いつ・どこで作業するか」の細かい管理は指揮命令に該当するリスクが高まります。コードレビューで言えば、「セキュリティ要件を満たしていない」「計算量が仕様の上限を超えている」は成果物の受け入れ判断として許容されますが、「この変数名は命名規則に従え」「今すぐこの行をこう書き換えろ」は作業プロセスへの介入です。スクラムも同じで、バックログの優先順位を伝えるところまでが「何を作るか」、「誰がどのタスクをいつやるか」の決定は受託側の責任者の仕事です。

**「フリーランスだから問題ない」は誤りです。** 偽装請負のリスクは、法人のSES会社との契約に限りません。個人のフリーランスへの業務委託でも同様で、発注者が作業方法・作業時間・優先順位を細かく指示している状態は、実質的な雇用関係に近いとみなされる可能性があります。契約の相手が会社か個人かは、この論点では関係ありません。

**適用範囲は下請法とフリーランス保護新法で違います。** 下請法は発注者・受注者双方の資本金規模の組み合わせで適用が決まりますが、2024年11月施行のフリーランス保護新法は、**個人（従業員を持たない事業者）への発注であれば資本金に関係なく全員が対象**です。「うちは小さい会社だから下請法の対象外」だとしても、個人に発注するならフリーランス保護新法からは逃れられません。書面交付・60日以内の支払い・代金の事後削減の禁止は、どちらの法律でも共通して求められます。

## あわせて確認

- 支払い期日管理のシステム化は → [外注費の支払い管理](/features/accounting/outsourcing-payment)（受領日の記録と60日アラートの自動化）
- 体制を決める段階の確認漏れは → [フェーズ1：機能企画・要件定義時](/checklist/phase-1-planning)
- 日々の発注・契約管理は → [フェーズ3：実装時](/checklist/phase-3-implementation)

{/* 実務メモ: 書籍にない独自の追加情報はこの下に追記していく */}