業務委託発注の要件定義書の書き方｜フリーランス発注で失敗しない6項目と書面明示対応

フリーランスエンジニアへの業務委託を始めたものの、「要件定義書をどう書けばよいのか分からない」という発注担当者の声は少なくありません。

開発会社への発注経験はあっても、フリーランスへの直接発注（準委任型の業務委託）は初めてという方も多く、従来の「仕様書」の書き方をそのまま当てはめようとして戸惑うケースがあります。

本記事では、業務委託（準委任型）に特化した要件定義書の書き方を6つの記載項目・作成ステップ・チェックリストとともに解説します。フリーランス新法（2024年11月施行）の書面明示義務への対応方法も合わせて紹介しますので、発注担当者の方はぜひ参考にしてください。

業務委託の要件定義書は「請負発注」と何が違うのか

請負型は「何を作るか」、準委任型は「どう動いてもらうか」を定義する

業務委託における要件定義書を正しく作るためには、まず「請負型」と「準委任型」の契約形態の違いを理解することが重要です。

請負型では、完成した成果物（システム、デザイン、Webサイト等）を納品することが目的です。要件定義書は「何を作るか」「どんな機能が必要か」という成果物の仕様書として機能します。

一方、準委任型（フリーランスエンジニアへの業務委託で多く使われる形態）では、役務の提供そのものが目的です。エンジニアが「何をするか」「どの範囲で動くか」「どのように関与するか」を定義する文書が求められます。

この違いを知らないと、請負型向けの「機能要件・非機能要件」中心の仕様書を準委任型の発注に当てはめてしまい、作業範囲のもめ事や品質の不一致が起きやすくなります。

要件定義書がないと起きる3つのトラブル

要件定義書を整備せずにフリーランスエンジニアへの発注をスタートすると、以下の3つのトラブルが典型的に発生します。

1. 作業範囲のもめ事

「それは依頼に含まれていないと思っていた」「追加の作業は別途費用が発生します」という状況です。業務の範囲（スコープ）が書面で合意されていないと、認識のズレが表面化するのは作業が進んでからになります。

2. 品質基準の不一致

「動くと思っていたが、想定していた品質ではなかった」というケースです。「完成」の定義が発注者とフリーランスの間で違っていた場合、受け入れ基準が不明確なまま検収の段階になって問題が発覚します。

3. 進捗確認の困難さ

「何をどこまで進めてもらえているのか分からない」状態は、準委任型で特に起きやすい問題です。請負型と異なり、成果物単位での確認が難しいため、マイルストーンや進捗確認の仕組みを事前に設計しておく必要があります。

業務委託エンジニアの活用で失敗しやすいポイントについては、業務委託エンジニア活用で失敗する4つのフェーズ｜発注者が知るべき防止策も参考にしてください。

業務委託（準委任型）の要件定義書に書く6つの項目

準委任型の業務委託における要件定義書に記載すべき項目を6つ紹介します。

1. 業務の目的・背景

最初に、なぜこの業務をフリーランスエンジニアに委託するのかを明記します。

• 社内リソースが不足しているため
• 特定の技術スタックの専門家が必要なため
• スピードを優先するため

目的・背景を書くことで、フリーランスエンジニアが全体像を把握し、優先順位の判断や主体的な提案がしやすくなります。「何のためにこの仕事をするのか」が分かっているエンジニアとそうでないエンジニアとでは、成果物の質に大きな差が出ます。

2. 業務の範囲（スコープ）

やること・やらないことを明示します。これがフリーランス新法における「業務の内容」の明示義務（2024年11月施行）にも対応する最重要項目です。

記載例（バックエンド開発を依頼する場合）:

「やらないこと」を書くことが特に重要です。「やること」だけを定義すると、記載がない業務を「含まれるはず」と解釈されることがあります。

3. 期待する役割・稼働量

週あたりの稼働量と、どのような形で参加してもらうかを記載します。

記載例:

• 稼働量: 週3日（24時間/週）
• 参加スタイル: 朝会（週3回・Zoom）への参加、Slackでの応答（営業時間内）
• コードレビュー: チームのプルリクエストへのレビュー対応
• 技術的意思決定: アーキテクチャ上の判断事項は事前に共有・相談

フリーランスエンジニアは複数のクライアントと並行して仕事をしているケースが多いため、稼働の期待値を明確にすることはトラブル予防に直結します。

4. コミュニケーション設計

誰と・どのツールで・どれくらいの頻度でやり取りするかを定義します。

記載例:

• 主要コミュニケーションツール: Slack（テキスト）、Zoom（ビデオ会議）
• 定例ミーティング: 週1回（月曜30分）、進捗確認と課題共有
• 報告フォーマット: 週次の進捗報告（テキスト形式でSlack#週次報告チャンネルに投稿）
• エスカレーション先: 業務担当者（○○）→ 問題が解決しない場合はプロジェクトオーナー（△△）

コミュニケーション設計が不明確だと、フリーランスエンジニアが孤立したり、問題が表面化するのが遅れたりします。

5. マイルストーン・確認タイミング

いつ・何を・どのように確認するかを設定します。フリーランス新法では、役務提供を受ける日（確認タイミング）の設定と、完了日から60日以内の報酬支払いが義務付けられています。

記載例:

マイルストーンを設けることで、問題の早期発見と報酬支払いの根拠が明確になります。

6. フリーランス新法対応の書面明示事項

2024年11月に施行されたフリーランス新法（特定受託事業者に係る取引の適正化等に関する法律）により、発注事業者には業務委託時に以下の事項を書面等で明示する義務が課されています。

法定の明示事項（発注書面または要件定義書に含めること）:

• 業務の内容
• 報酬の額
• 支払期日
• 発注事業者・特定受託事業者（フリーランス）の名称
• 業務委託をした日
• 給付を受領・役務提供を受ける日
• 給付を受領・役務提供を受ける場所
• （検査を行う場合）検査の完了日
• （金銭以外で支払う場合）報酬の支払方法に関する事項

これらを要件定義書に含めるか、別途発注書として発行するかは任意ですが、少なくとも業務委託開始時に書面で渡しておく必要があります。要件定義書に含めることで、業務範囲と法的義務を一つの文書で管理できます。

フリーランス新法への対応を含む契約リスクの詳細については、フリーランス新法対応 業務委託発注の法律・契約リスク点検ガイド（ebook）もご活用ください。

業務委託の要件定義書を作る3ステップ

ステップ1: 「問題」から逆算して書き始める

「このシステムを作ってほしい」という成果物ベースではなく、「この業務課題を解決したい」という問題ベースから始めます。

問いかけ例:

• 現在どんな業務課題があるか
• その課題がなくなると、何が変わるか（定量的に表現できるか）
• フリーランスエンジニアの力を借りることでどう解決するか

この順番で考えると、スコープが自然に絞られ、「やること・やらないこと」が明確になります。

ステップ2: スコープと境界線を決める

やること・やらないことをリストアップします。判断に迷う項目は「もしやらないとしたら、何が困るか」という問いかけで整理します。困らないなら対象外でよく、困るなら含めるべきです。

このステップで「含めるかどうか迷っているもの」をリストアップして可視化することが重要です。あいまいなまま進めると、後から「含まれると思っていた」というトラブルの原因になります。

ステップ3: フリーランスエンジニアにレビューしてもらう

要件定義書は発注者だけで完成させないことが重要です。作成した後、発注予定のフリーランスエンジニア（または候補者）に事前レビューを依頼してください。

レビューで確認すること:

• 業務範囲の記載に曖昧な点はないか
• 稼働量・コミュニケーション設計は実現可能か
• マイルストーンの設定は実態に合っているか

着手前に認識のズレを潰しておくことで、作業中のもめ事を大幅に減らすことができます。フリーランスエンジニアの活用前の社内準備については、フリーランスエンジニア活用を始める前に整える社内準備6ステップも参考にしてください。

要件定義書を確認するチェックリスト

作成した要件定義書を以下のチェックリストで確認してください。すべて「はい」であれば、準委任型業務委託の要件定義書として十分な品質です。

一般的な要件定義書との違い（補足）

本記事は準委任型の業務委託に特化した要件定義書の書き方を解説しました。請負型のシステム開発発注（開発会社に成果物の納品を依頼するケース）向けの一般的な要件定義書の書き方と、機能要件・非機能要件の詳細な記載方法については、要件定義書の書き方とテンプレート【非エンジニア発注者向け7項目・記入例付き】をご参照ください。

まとめ

業務委託（準委任型）の要件定義書は、請負型の「成果物の仕様書」とは異なります。「役務の期待値・業務範囲の合意書」として、以下の6項目を盛り込んで作成してください。

1. 業務の目的・背景 — なぜ委託するのかを明記
2. 業務の範囲（スコープ） — やること・やらないことを明示
3. 期待する役割・稼働量 — 週あたりの稼働と参加スタイル
4. コミュニケーション設計 — ツール・頻度・エスカレーション先
5. マイルストーン・確認タイミング — いつ・何を確認するか
6. フリーランス新法対応の書面明示事項 — 法的義務を漏れなく記載

6項目を整備し、フリーランスエンジニアにレビューしてもらうことで、手戻り・スコープのもめ事・品質不満を大幅に減らすことができます。

要件定義書が整ったら、次のステップとして契約・法律リスクの確認も重要です。フリーランス新法への具体的な対応方法や契約リスクの点検については、以下の資料をご活用ください。