業務委託エンジニアのマネジメント方法｜偽装請負を避けて品質を守る5つの手順

業務委託エンジニアとの仕事を始めたものの、「どこまで指示していいのか」「進捗確認は何回してもいいのか」と不安を感じたことはありませんか。

「指示を出しすぎると偽装請負になる」という話は耳にしていても、具体的にどこが境界線なのかが分からず、結果としてコミュニケーションを控えすぎてしまう担当者は少なくありません。そのため、気づけば品質が期待通りでなかったり、プロジェクト終了後に社内に何も残っていなかったりという状況に陥ることがあります。

業務委託エンジニアを活用する際のマネジメントには、正社員とは異なる独自のポイントがあります。法的コンプライアンスを守りながら、品質・進捗をしっかりコントロールし、社内にナレッジを蓄積する ― その実務的な手順を、本記事で具体的に解説します。

なぜ業務委託エンジニアのマネジメントは難しいのか

正社員と業務委託の指揮命令権の違い

正社員と業務委託エンジニアの最も大きな違いは、指揮命令権の有無です。

正社員に対しては、業務の指示・方法・時間管理など幅広い指揮命令が認められています。一方、業務委託の場合は、発注者（企業）と受注者（エンジニア）が「対等な立場」であり、発注者は受注者の作業方法や日々の業務進め方を直接指定することができません。

ただし、これは「何も言ってはいけない」という意味ではありません。以下のような「業務に必要な情報共有や成果物の品質確認」は適法です。

• 納期や成果物の品質基準の共有
• プロジェクトの方向性や優先事項の整理
• 進捗状況の報告を受ける（準委任契約では受注者に報告義務がある）
• セキュリティや法令コンプライアンス上の要件の伝達

一方、NGとなるのは「どの方法で作業するか」「何時に作業するか」といった、作業の具体的手順や時間管理への踏み込みです。

偽装請負のリスクとは

偽装請負とは、形式上は業務委託契約を結びながら、実態では雇用（指揮命令）関係と同等の管理をしてしまっている状態です。職業安定法違反となり、1年以下の懲役または100万円以下の罰金が科される可能性があります。

典型的な偽装請負のパターンとして、以下が挙げられます。

• 毎日の勤怠管理（出退勤の時刻を管理する）
• 作業場所・作業方法を細かく指定する
• 「今日はこの作業をしてください」と日常的に指示を出す

こうしたリスクを認識した上で、次のセクションでは「実務でどこまで・どのように管理できるのか」を具体的に見ていきます。

業務委託エンジニアマネジメントの5つのポイント

ポイント①業務範囲・成果物を契約・キックオフ時に明確化する

業務委託マネジメントの成否は、契約・キックオフの段階で大きく決まります。「お任せします」という形で始めてしまうと、後から品質問題や認識ズレが生じやすくなります。

契約・キックオフ時に明確にしておくべき項目は以下です。

成果物の定義

• 何を作るか（機能の具体的な要件、デモ動画・ドキュメントの有無など）
• 品質基準（バグの許容件数、コードレビューの合格基準など）
• 納品の形式（GitHubへのプッシュ、ファイル渡し、レビュー済みブランチなど）

スコープ外の扱い

• 依頼範囲に含まれない作業が発生した場合の対応方法を事前に合意しておく
• 「スコープ変更は書面・メールで合意した上で追加発注する」と明記する

コミュニケーションの取り決め

• 定期報告の形式・頻度
• 緊急連絡の方法と対応時間

こうした内容をキックオフドキュメントや業務仕様書として文書化しておくことで、後からの「言った・言わない」を防ぐとともに、マネジメントの基準が明確になります。

ポイント②偽装請負リスクを避けた進捗確認の方法

「進捗確認は偽装請負にならないか」という不安から、確認を控えすぎる担当者がいますが、適切に設計された進捗確認は適法です。

準委任契約の場合、受注者には作業報告義務があります（民法第645条）。そのため、定期的な進捗報告を契約で定めることは問題ありません。

適法な進捗確認の方法

• 週次レポートの提出を契約書に明記し、テンプレートを渡す
  • 例: 「今週完了したタスク」「来週の予定」「課題・ブロッカー」の3項目
• GitHubのコミット履歴・プルリクエストで成果物の進捗を把握する
• Notionや共有のタスク管理ツールに、エンジニア自身がステータスを更新する仕組みを作る

NGになりやすいパターン

• 「今日の午前中はこの機能を実装してください」という日次・時間単位の作業指示
• 「社内のSlackに何時〜何時の間は常駐してください」という時間拘束

ポイントは「作業結果（アウトプット）を確認する」ことは適法で、「作業の進め方（プロセス）を指示する」ことがNGという区別です。

ポイント③品質基準の設定と合意形成

品質管理で多くの発注企業が困るのが、「クオリティが期待に届かなかったが、どう伝えればいいか分からない」という状況です。この問題は、多くの場合品質基準の事前合意が不足していることに起因します。

品質基準の文書化と合意手順

1. 受け入れ基準の策定: 成果物を受け入れるための具体的な条件を文書化する
   • 例: 「指定の機能要件を全て満たしていること」「ユニットテストのカバレッジが80%以上であること」「バグチケットが0件であること」
2. キックオフ時に合意: 文書化した基準を共有し、双方が合意した上でプロジェクトを開始する
3. 検収プロセスの明確化: 成果物を受け取ったあとにどう確認するか（検収テスト）を事前に決めておく

なお、「コードレビューをしてほしい」という依頼は問題ありません。ただし、「このようにコードを書いてください」という実装方法の指示はNGになるため、「成果物の品質基準に照らして確認する」という立場を保つことが重要です。

ポイント④コミュニケーション設計（ツール・頻度・方法）

業務委託エンジニアとのコミュニケーションは、過剰すぎず・不足しすぎずのバランスが重要です。指揮命令にならない形で、プロジェクトの方向性と品質を共有し続ける体制を設計します。

推奨するコミュニケーション構成

ミーティングは「進捗報告の場」ではなく「方向性の確認・課題解決の場」として設計すると、偽装請負リスクを避けながら生産的なコミュニケーションが実現します。

アジャイル開発を採用している場合、スプリントレビュー（成果物を確認するデモの場）を活用するのも効果的です。作業方法への指示ではなく、完成した成果物に対してフィードバックを行う形式のため、準委任契約の枠内で適切に機能します。

ポイント⑤社内ナレッジ蓄積の仕組み構築

業務委託エンジニアの活用で見落とされがちな課題が、プロジェクト終了後のナレッジ喪失です。「エンジニアが離れたらシステムのことが誰も分からなくなった」という状況は、仕組みなしには避けられません。

社内ナレッジを蓄積するための仕組み

• 技術ドキュメントの提出を成果物の一部として契約に含める
  • 例: 「システムの設計書・アーキテクチャ図・API仕様書を納品物として定義する」
• コードのコメント義務化
  • 「なぜこの実装にしたか」の理由を README やコードコメントに残すルールを設ける
• 月次レポート（技術的な決定事項・課題・改善点）の蓄積
  • NotionやGoogle Driveで管理し、退場後も参照できる状態にする
• 引継ぎドキュメントの作成を最終フェーズに組み込む
  • 「プロジェクト完了の2週間前には引継ぎドキュメント作成を開始する」とスケジュールに組み込む

ナレッジ蓄積は「お願いベース」にするのではなく、契約・成果物定義の段階から要件として組み込むことが最も確実です。

フリーランス保護法（2024年11月施行）で変わる発注企業の義務

フリーランス保護法の概要と発注企業への影響

2024年11月1日に「フリーランス・事業者間取引適正化等法（フリーランス保護法）」が施行されました。これにより、業務委託エンジニアに仕事を依頼する発注企業には、これまでより明確な義務が課せられるようになりました。

フリーランス保護法の目的は、フリーランスと発注企業の取引を適正化し、フリーランスが安心して働ける環境を整備することです。

発注企業が対応すべき7つの義務

フリーランス保護法では、発注事業者に対して以下の7つの主要な義務が定められています。

1. 取引条件の明示: 業務内容・報酬額・支払い期日などを、書面またはメールで明示する義務
2. 報酬の支払い期限の遵守: 成果物受領日から原則60日以内に報酬を支払う義務
3. 不当行為の禁止: 受領拒否・報酬の減額・買いたたきなど7種類の不当な行為の禁止（1か月以上の継続委託の場合）
4. 募集情報の正確性確保: 求人・募集に関する情報を正確かつ最新の状態に保つ義務
5. 育児・介護への配慮: 6か月以上継続する業務委託の場合、育児・介護と業務の両立に配慮する義務
6. ハラスメント対策の体制整備: 研修の実施や相談窓口の設置など、ハラスメント防止のための措置を講じる義務
7. 契約終了時の予告: 6か月以上の継続契約を終了させる場合、原則30日前までに書面で予告し理由を開示する義務

違反した場合は50万円以下の罰金や行政指導、企業名の公表といった罰則が科される可能性があります。

実務での対応ポイント

まず確認すべきは、契約書や発注書に上記の内容が適切に盛り込まれているかどうかです。特に「取引条件の明示」については、口頭での合意ではなく書面化が必須となっています。既存の契約書テンプレートを見直し、必要に応じて法務担当や弁護士に相談することをおすすめします。

（出典: フリーランス新法とは？発注側に課せられる7つの義務）

まとめ ― 業務委託エンジニアマネジメントの実践チェックリスト

業務委託エンジニアのマネジメントで重要なのは、「何もしない」でも「指示しすぎる」でもなく、適切な設計と仕組みを前提に関係を構築することです。

本記事で紹介した5つのポイントを、実践のチェックリストとしてまとめます。

契約・キックオフ時のチェックリスト

• 成果物の定義・品質基準を文書化したか
• スコープ外の対応方法を事前に合意したか
• 定期報告の形式・頻度を契約書に明記したか
• ナレッジ蓄積（技術ドキュメント・引継ぎ）を成果物の一部として定義したか
• フリーランス保護法に対応した契約書になっているか

プロジェクト進行中のチェックリスト

• 週次レポートや進捗共有の仕組みを運用できているか
• 成果物の品質基準に照らした検収ができているか
• 「アウトプット確認」と「プロセス指示」を区別できているか
• ドキュメント・コードコメントが蓄積されているか

業務委託エンジニアを活用する発注企業にとって、こうした実務手順の確立は「トラブルを防ぐ守り」であるとともに、「外部人材の力を最大限に引き出す攻め」でもあります。本記事のポイントを参考に、自社のプロジェクト体制を見直してみてください。

外部エンジニア活用をより戦略的に進めるためのノウハウは、お役立ち資料（ebook）でも詳しく解説しています。自社に合った外部人材活用の仕組みづくりにお役立てください。