業務委託エンジニアの定例ミーティング設計｜偽装請負を避ける運用ルール

業務委託エンジニアとの定例ミーティングを始めようとしたとき、「進捗を聞きたいが、これって指示にあたるのでは」と一度は立ち止まったことのある発注担当者は少なくないはずです。社員相手であれば気にも留めない一言が、業務委託メンバーに向けられた瞬間に「指揮命令」と判定され、偽装請負のリスクとして跳ね返ってくる可能性があるためです。

社内法務やコンプライアンス部門に確認しても、返ってくるのは「個別タスクの直接指示はNGです」「労務管理はしないでください」といった抽象的な助言が中心になりがちです。実際の運用に落とし込むには、定例MTGの場で「何を聞いてよく、何を言ってはいけないのか」を発言レベルで把握する必要があります。

実は、こうした実務判断の拠り所として、厚生労働省が「労働者派遣事業と請負により行われる事業との区分に関する基準（37号告示）に関する疑義応答集（第3集）」を公表しています（厚生労働省・疑義応答集（第3集））。アジャイル型開発を含む準委任契約での協働を前提に、発注者と受注者の関係性をどう保てば適正な請負・準委任とみなされるかが整理されています。

本記事では、この公的指針を踏まえつつ、業務委託エンジニアとの定例ミーティングを「偽装請負リスクを避けながら実効性も担保する場」として設計する具体策を解説します。偽装請負の判断軸の整理から、現場で使える5つの設計原則、週次・隔週・月次のアジェンダテンプレート、非同期コミュニケーションとの組み合わせまで、自社の運用ルールにそのまま転用できる粒度で提示していきます。

業務委託エンジニアの定例ミーティング設計で発注側が直面するジレンマ

業務委託エンジニアとの定例ミーティングをどう設計するかは、単なる会議体の話ではなく、契約の適法性に直結するテーマです。最初に、発注側がぶつかりやすいジレンマと、それを放置した場合のリスクを整理します。

「進捗確認」と「指示」の境界がわからない不安

業務委託エンジニアと定例MTGを開いたとき、発注担当者の頭をよぎるのは「これを言ったら指示になるのではないか」という不安です。たとえば次のような発言は、社員相手ならごく当たり前のやり取りですが、業務委託メンバーに向けると微妙な領域に入ります。

• 「次はこのチケットを担当してもらえますか」
• 「明日中にこのバグを直しておいてください」
• 「今日は何時から何時まで作業していますか」
• 「コードレビューでこの実装方針に直してください」

社内法務に確認すると「個別タスクの直接指示はやめてください」と言われ、結果として「ではどう聞けばいいのか」が宙に浮いたままになります。境界線の感覚がないまま定例MTGを開くと、「とりあえず進捗だけ確認する」会議か、逆に「無意識に細かく指示してしまう」会議のどちらかに振れがちです。

偽装請負と判断されたときに発注側が負うリスク

定例MTGの運営を雑に行った結果、発注側と業務委託エンジニアの関係が「実態として労働者派遣」と判断されると、複数の法律違反に問われる可能性があります。

労働者派遣法に基づき、許可を受けない労働者派遣事業として「1年以下の拘禁刑又は100万円以下の罰金」が科されるケースがあります（労働者派遣法第59条）。職業安定法上の違法な労働者供給事業とみなされた場合も同等の罰則対象になります（偽装請負の罰則に関する解説（マネーフォワード クラウド））。罰金の金額そのものよりも、行政指導や公表による信用毀損・取引先からの懸念表明のインパクトのほうが事業上は深刻です。

加えて、業務委託メンバーが社会保険の遡及加入を求めるリスク、契約の有効性を巡る民事紛争、社内コンプライアンス上のレピュテーション低下も無視できません。「ちょっと言いすぎただけ」では済まないからこそ、定例MTGの設計を後回しにせず、最初から線引きを明確にしておく価値があります。

そもそも偽装請負とは何か：定例ミーティングで注意すべきポイント

定例ミーティングの設計に入る前に、判断基準である「労働者派遣事業と請負により行われる事業との区分に関する基準」（昭和61年労働省告示第37号、通称「37号告示」）の骨格を押さえます。

偽装請負の判断基準（37号告示の4要件）

37号告示は、ある契約が請負・準委任として適正なのか、それとも実態として労働者派遣なのかを判別するための基準です。大きく分けて「労働力の利用に関する自己の指揮命令」と「自己の業務としての処理」の2つの観点があり、それぞれに細かい要件が設定されています。

定例ミーティングの設計に直結する観点を簡潔に整理すると、以下の表のようになります。

発注者が業務委託エンジニア個人に対して、勤務時間や作業手順を細かく指示する関係になっていると、契約形式が「業務委託」であっても実態として労働者派遣（しかも許可外なら偽装請負）と判断され得ます。発注者側にどこまでの依頼・指示が許容されるのか、適法な範囲をより詳しく確認したい場合は業務委託で適法な指揮命令の範囲とは？も参考になります。

定例ミーティングが争点になりやすい理由

定例ミーティングは、発注者と業務委託エンジニアが直接顔を合わせる代表的な場です。会議の運営の仕方しだいで、上の4要件のうち複数が崩れる引き金になります。

• 業務委託エンジニア個人に対し、具体的なチケットや作業を発注者が直接アサインする
• 「何時までに対応してください」「明日も同じ時間にお願いします」など、勤務時間・作業時間を細かく指定する
• 実装方針・コーディングスタイル・レビュー指摘を、発注者から個人に対して直接細かく指示する
• 業務委託メンバーが自社（受託者側）の業務指示系統から切り離され、発注者の指揮系統に組み込まれている

これらは個別に見れば日常会話に近い行動ですが、積み重なると「発注者が業務委託エンジニアを直接指揮命令している」状態に近づきます。定例MTGはその振る舞いが集約される場になりやすく、運営設計を間違えると争点になりやすいのです。

アジャイル開発と準委任契約での解釈：厚労省疑義応答集（第3集）の要点

「アジャイル開発のように頻繁にコミュニケーションを取る前提だと、そもそも偽装請負を避けられないのではないか」という疑問に対し、厚生労働省は2021年9月に「労働者派遣事業と請負により行われる事業との区分に関する基準（37号告示）に関する疑義応答集（第3集）」を公表しています（厚生労働省・疑義応答集（第3集））。

要点を整理すると、次のような考え方が示されています。

• 37号告示は契約形式（請負か準委任か）ではなく、実態として労働者派遣にあたるかどうかで判断する
• アジャイル型開発のように発注者と受注者が一体的に協働するケースでも、対等な関係下で協働し、受注者側のメンバーが自律的に判断していれば偽装請負にはあたらない
• 受注者が自社の労働者に対して業務の遂行に関する指示その他の管理を自ら行っていること、および受注者が請け負った業務を自己の業務として契約の相手方から独立して処理していることが、適正と判断される前提となる

つまり「会議体や会話の量」が論点なのではなく、「指揮命令系統がどちらに属しているか」「受託者側に自律性があるか」が判断の中心です。定例MTGも、発注者から個人への一方的な指揮命令の場ではなく、対等な関係で情報共有・要件すり合わせを行う場として設計できれば、頻度を上げても問題視されにくくなります。

偽装請負にならない定例ミーティングの設計原則

ここからは、上記の判断軸を踏まえて、定例MTGをどう運営するかの設計原則を5つに整理します。各原則ごとに、現場で発しがちな「NG発言」と、同じ意図を適切に伝える「OK発言」を対比します。なお、定例MTG以外の日常的なやり取りも含めた接し方の全体像は業務委託エンジニアとのコミュニケーション方法で整理しています。

原則1：個人ではなくチーム（受託者側責任者）を窓口にする

定例MTGの参加者構成と、依頼や調整の宛先を「個人」ではなく「受託者側のチーム（リードや責任者）」に揃えます。発注者が個別のメンバーに直接タスクを割り振る関係を避け、業務の差配は受託者側に委ねます。

「誰がやるか」を発注者が決めるのではなく、「何を目指したいか」「いつまでに実現したいか」を伝え、内部のアサインは受託者側で行ってもらう構造にします。

原則2：タスクの直接アサインではなく「成果・要件」を共有する

定例MTGで共有するのは、個別のタスクではなく、求めたい成果と要件です。「何を作ってほしいか」「どのような状態になれば完了か（受入基準）」を起点にし、具体的なチケット分解や着手順序は受託者側に任せます。

成果単位で依頼することで、実装方針や順序の判断は受託者側に残り、発注者の発言が「指揮命令」と判定されるリスクが下がります。

原則3：手順・進め方を指示せず、受託者の裁量に委ねる

定例MTGで実装の細部や作業手順まで踏み込むと、原則2を満たしていても実態として手取り足取りの指示になりがちです。技術選定・実装方針・テスト手法などの「進め方」は、受託者側の裁量に委ねます。

「品質基準・非機能要件・受入基準」を共有することはまったく問題ありません。問題になりやすいのは、それを満たすための「やり方」を発注者が直接指示するパターンです。

原則4：勤務時間・場所・出退勤は管理しない

37号告示の重要な観点として、勤務時間・場所・出退勤の管理を発注者が直接行わないことが挙げられます。社員と同じ感覚で「朝会の時間に間に合ってください」「就業時間内は常時オンラインにしてください」と求めると、勤務時間の管理にあたる可能性があります。

定例ミーティングやレビュー会への参加など「契約上必要な業務遂行に関する取り決め」と、「勤務時間そのものの管理」は別物として整理します。

原則5：議事録に「依頼内容」と「合意した成果」を明示する

定例MTG後の議事録は、後から見たときの判断材料そのものです。議事録に「個人への作業指示」が並んでいると、行政指導の際にも不利な材料になります。逆に「合意した成果」「次回までに確認したい点」が明示されていれば、適正な業務委託としての運用実態を示しやすくなります。

議事録は「発注者から個人への指示記録」ではなく、「両社で合意したスコープと受入基準の記録」と位置づけて運用します。

定例ミーティングのアジェンダテンプレート（週次・隔週・月次）

設計原則を踏まえ、頻度別に使えるアジェンダテンプレートをまとめます。スプリント運用の有無や契約形態に合わせて、所要時間・参加者は調整してください。

週次ミーティング（30〜45分）：進捗共有と要件のすり合わせ

短いサイクルで、進捗共有・ブロッカー解消・次の期間のスコープ確認を行うMTGです。発注者は「成果ベース」で進捗を聞き、個別のタスクの細かい指示は避けます。

隔週ミーティング（60分）：方向性の調整とリスク確認

スプリントレビュー・プランニングに相当するMTGです。完了した成果のデモ、次のスプリントで実現したいユースケースの共有、リスク・課題の整理を行います。

月次ミーティング（60〜90分）：成果レビューと契約期間内ゴールの再確認

中長期の方向性と契約期間内のゴールをすり合わせるMTGです。成果が当初想定とずれていないかを確認し、必要に応じて契約スコープや要件の見直しを議論します。

各アジェンダで避けるべきNG発言・OK発言の対比

頻度を問わず、定例MTGで生じやすい発言を横断テーブルに整理します。普段の自分・チームの発言を当てはめてみて、NG側に近い表現が常態化していないかを点検する材料として活用してください。

非同期コミュニケーションとの組み合わせ方

定例MTGの設計をどれだけ整えても、その間のSlackやチケット上のやり取りで指示密度が上がっていれば、実態は変わりません。むしろ「会議体以外の場所での発言・運用」のほうが、日常的なコミュニケーション量としては多いはずです。非同期コミュニケーションをセットで設計することで、運用全体の「指示の濃度」を構造的に下げられます。

定例ミーティングに依存しすぎない運用設計

「定例MTGですべて決める」運用にすると、会議の場で個別タスクの議論や指示に踏み込みやすくなります。同期と非同期で扱う内容を明確に分け、定例MTGは「合意・方向付け・リスク共有」の場に絞るとよいです。

「会議で決めたことを、ドキュメントに落とし込み、チケットで進捗を可視化する」という流れを基本構造にすると、発注者が個人へ直接タスクをアサインする場面が自然と減ります。

Slack・チャットでのやり取りで気をつける表現

Slack等のチャットツールは即時性が高く、つい命令形・個人宛の指示口調になりがちです。やり取りそのものを避ける必要はありませんが、宛先と表現を意識します。

「@個人 + 命令形」を「@チームのリード + 依頼形」に置き換えるだけでも、運用実態は大きく変わります。

GitHub Issue・タスクボードでの依頼方法

チケット・Issueも「発注者がエンジニア個人にタスクを直接振る道具」になりやすいツールです。チケットの作成と起票はしてよいですが、Assignee（担当者）を発注者が直接指定する運用はリスクが高い設計です。

「成果に対する受入確認」と「実装手段の指示」は別物として運用を切り分けます。

ドキュメント運用で「指示の濃度」を下げる工夫

要件定義書・受入基準書・FAQドキュメントなど、書面で固められる情報を増やすほど、定例MTGやチャットで都度指示を出す必要が減ります。

• 要件定義書：実現したいユースケース・成果を明文化。スプリントごとに更新
• 受入基準書：「どの状態になれば完了か」を箇条書きで明確化
• ADR（Architecture Decision Record）：採用した技術選定の経緯を双方が記録
• FAQ・用語集：用語の認識違いを減らし、口頭での補足説明を最小化

「成果に関する合意」をドキュメントに集約し、「指示」をその場の発言ではなくドキュメントの更新と参照に置き換える運用に近づけていきます。

発注側のためのセルフチェックリスト：あなたの定例ミーティングはセーフか

ここまでの設計原則を踏まえ、自社の定例MTG運営をすぐに点検できるセルフチェックリストを示します。一つでも該当項目がある場合は、運用見直しの優先度が高い領域です。定例MTGに限らず、契約・運用全体での偽装請負リスクを網羅的に点検したい場合は偽装請負チェックリストも併用してください。

10項目のセルフチェックリスト

チェックで赤信号が出たときの改善ステップ

該当項目があった場合は、いきなり関係を切り替えるのではなく、段階的に運用を更新していくのが現実的です。

1. 運用ルールの明文化: 上のチェック項目に基づき、定例MTGとチャット運用のルールを自社の標準ドキュメントとして整備する
2. 受託者側との合意形成: 「受託者リードを窓口にする」「Assignee 設定は受託者側で行う」など、運用変更の意図を共有し、合意を取る
3. ドキュメントの整備: 要件定義書・受入基準書を整備し、定例MTGで「成果単位」での議論ができる土台を作る
4. 議事録テンプレートの見直し: 個人宛の作業指示が並ばない構成（合意した成果・受入基準・残課題ベース）にテンプレートを変更する
5. 定期的なセルフ点検: 上のチェックリストを四半期ごとに見直し、運用が崩れていないかを確認する

法務・コンプライアンス部門と連携しながら進めると、社内全体での運用整合性が取りやすくなります。

まとめ：実効性とコンプライアンスを両立する定例ミーティング運営へ

業務委託エンジニアとの定例ミーティングは、設計次第で「偽装請負リスクを抱える場」にも「対等な協働関係を築く場」にもなり得ます。本記事の要点を改めて整理します。

• 偽装請負の判断は契約形式ではなく、実態としての指揮命令関係・受託者の自律性で行われる（厚労省37号告示・疑義応答集（第3集））
• 定例ミーティングでは「個人ではなくチーム」「タスクではなく成果」「手段ではなく受入基準」を軸に発言・依頼を組み立てる
• 週次・隔週・月次の頻度ごとに目的とアジェンダを切り分け、各MTGで踏み込んでよい議題と避ける議題を明確にする
• 非同期コミュニケーション・ドキュメント運用とセットで設計し、運用全体の「指示の濃度」を構造的に下げる
• セルフチェックリストを使って、自社の定例MTG運営を定期的に点検する

定例ミーティング自体は、業務委託エンジニアとの信頼関係を築き、プロジェクトの方向性を共有するうえで欠かせない場です。「会議を減らす」のではなく「会議の中身を設計する」発想で、実効性とコンプライアンスを両立した運用を目指していきましょう。