人・組織系
SES・外注エンジニアへの指示と発注で確認すべきこと。Slack・GitHubのログが証拠になる
「SlackでA社のエンジニアに直接タスクを振ってもいいですか？」「外注先のGitHubにコードレビューのコメントを入れても大丈夫ですか？」「フリーランスに頼んでいるので書面は省略していいですか？」。技術的な話ではないため「そういうのは人事や法務が考えること」と思われがちです。しかしこのカテゴリで問われるのは、エンジニア自身の日々のふるまいそのものです。
そして厄介なのは、証拠が自動的に残り続けることです。Slackのメッセージ、GitHubのコメント、Jiraのチケットアサイン履歴は、「誰が誰にどんな指示を出していたか」を日付つきで記録しています。「口頭で指示していただけです」が通じた時代とは違い、偽装請負の調査や訴訟では、これらのログがそのまま有力な証拠になります。しかも他のカテゴリと違って、リリース前に気づいて直せるものではありません。問題のある運用を続けた履歴は、後から消せません。
こんな状況が現場で起きていたら
- 発注者側の社員が、業務委託エンジニアに直接Slack・メールで作業指示を出している
- 発注者側のPMが、Jira・GitHubで業務委託エンジニアにタスクを直接アサインしている
- スクラムのデイリーで、発注者側が「誰が何をやるか」を個別に割り振っている
- コードレビューで、命名規則や実装スタイルを逐一指定している
- 常駐先の勤怠管理・就業規則に、業務委託のエンジニアが従っている
- 朝礼・勉強会・清掃など、業務と無関係な活動への参加を求めている
- 「まず手を動かして」と、発注書なしで作業を開始させている
- 検収から支払いまでが60日を超えている／仕様変更を無償でやらせようとしている
機能別の確認事項
| 実装しようとしている機能 | 主な確認事項 |
|---|---|
| SES・業務委託エンジニアへの指示 | 「何を作るか」の合意はよく、「どう作るか・いつ作業するか」の細かい管理が指揮命令になりうる。指揮命令の経路（発注者→受託会社の責任者→エンジニア）を設計したか。Slackのチャンネル設計もその経路に沿っているか。コードレビューは成果物の品質・仕様適合の指摘なら許容、実装スタイルへの逐一指示は問題。スクラムのタスクアサインは受託側の責任者が行う運用か |
| フリーランス・外注先への発注 | 作業開始前に書面（メール・チャットの文面でも可）を交付したか。報酬額と支払期日を発注時に明示したか。受領から60日以内に支払うフローになっているか。仕様変更を追加発注（追加報酬）として処理するか。個人への発注ならフリーランス保護新法が資本金不問で適用される |
このカテゴリの勘所
「何を作るか」と「どう作るか」の間に線があります。 成果物・仕様・納期の合意（「このAPIを今月末までに実装してください」）は業務委託として自然な範囲です。一方、「どのように作るか」「いつ・どこで作業するか」の細かい管理は指揮命令に該当するリスクが高まります。コードレビューで言えば、「セキュリティ要件を満たしていない」「計算量が仕様の上限を超えている」は成果物の受け入れ判断として許容されますが、「この変数名は命名規則に従え」「今すぐこの行をこう書き換えろ」は作業プロセスへの介入です。スクラムも同じで、バックログの優先順位を伝えるところまでが「何を作るか」、「誰がどのタスクをいつやるか」の決定は受託側の責任者の仕事です。
「フリーランスだから問題ない」は誤りです。 偽装請負のリスクは、法人のSES会社との契約に限りません。個人のフリーランスへの業務委託でも同様で、発注者が作業方法・作業時間・優先順位を細かく指示している状態は、実質的な雇用関係に近いとみなされる可能性があります。契約の相手が会社か個人かは、この論点では関係ありません。
適用範囲は下請法とフリーランス保護新法で違います。 下請法は発注者・受注者双方の資本金規模の組み合わせで適用が決まりますが、2024年11月施行のフリーランス保護新法は、個人（従業員を持たない事業者）への発注であれば資本金に関係なく全員が対象です。「うちは小さい会社だから下請法の対象外」だとしても、個人に発注するならフリーランス保護新法からは逃れられません。書面交付・60日以内の支払い・代金の事後削減の禁止は、どちらの法律でも共通して求められます。
あわせて確認
- 支払い期日管理のシステム化は → 外注費の支払い管理（受領日の記録と60日アラートの自動化）
- 体制を決める段階の確認漏れは → フェーズ1：機能企画・要件定義時
- 日々の発注・契約管理は → フェーズ3：実装時