業務委託エンジニア(フリーランス)に開発を発注したものの、契約更新や評価のタイミングで「そもそも何を目標にしていたんだっけ?」と立ち止まってしまった。あるいは、評価しようとして本人と認識がずれ、気まずいやり取りになった——。外部人材の受け入れに慣れていない発注担当者から、こうした声をよく聞きます。
厄介なのは、この問題が「評価のとき」に表面化するのに、原因は「最初に目標を握らなかったこと」にある点です。後出しで成果を測ろうとすれば本人ともめますし、社内に「この発注の成果はこうでした」と説明することもできません。費用を払い続けながら、何を得られたのか曖昧なまま——という状態は、発注者にとって最も避けたい事態です。
しかも業務委託エンジニアの場合、正社員の目標設定をそのまま流用できません。人事評価制度の外にいる人材であり、契約形態によっては「指示を出しすぎると偽装請負になる」という法的な制約もあります。だからといって何も握らないと、評価のしようがありません。「どこまで目標として握っていいのか」が分からず、固まってしまう発注者は少なくありません。
本記事では、業務委託エンジニアのKPI目標設定を、契約・キックオフの時点で本人と合意するための具体的な進め方を、発注者目線で解説します。準委任と請負で握るべき目標がどう違うのか、偽装請負にならない「目標」と「指示」の線引き、そして評価でもめないための合意シートの作り方まで。読み終えるころには、キックオフで使える目標のたたき台を、自分の手で作れる状態を目指します。
なお、設定した目標を実際に評価する段階、目標が未達だった場合の立て直しについては、本記事の「下流」にあたるテーマです。本記事はあくまで「業務開始前に、何を・どう握るか」に焦点を絞ります。
なぜ業務委託エンジニアのKPI目標設定は「業務開始前」に握るべきなのか

業務委託エンジニアにまつわるトラブルの多くは、評価フェーズで発覚します。しかしその根っこをたどると、ほぼ例外なく「最初に目標を握らなかったこと」に行き着きます。評価で勝負を決めようとすると、すでに手遅れなのです。まずは、目標の曖昧さがどんなトラブルを招くのかを整理し、なぜ業務開始前という早いタイミングが重要なのかを確認します。
目標の曖昧さが招く3つのトラブル
目標を握らないまま発注を進めると、典型的には次の3つのトラブルが起こります。
1. 成果が測れない
「いい感じに開発を進めてほしい」というふわっとした依頼でスタートすると、数か月後に「結局、何ができたのか」を客観的に判断できなくなります。コードは積み上がっているように見えても、それが当初期待した価値に結びついているのかを評価する物差しがありません。
2. 評価時の認識ずれ
発注者は「もっと幅広く対応してくれると思っていた」、本人は「依頼された範囲はきっちりやった」。この食い違いは、最初に期待値を言語化しなかったことから生まれます。評価のタイミングで初めて期待値を口にすると、本人にとっては「後出し」に感じられ、信頼関係が一気に崩れます。
3. 社内への説明不能
経営層や他部門から「この発注で何が得られたのか」と問われたとき、目標が曖昧だと説明できません。費用は明確に発生しているのに、リターンを言語化できない。これは発注担当者自身の評価にも跳ね返ってきます。
正社員の目標設定をそのまま流用できない理由
「目標設定なら正社員でもやっているし、同じようにすればいい」と考えたくなりますが、業務委託エンジニアには次の3つの事情があり、流用すると無理が生じます。
- 人事評価制度がない: 業務委託エンジニアは社内の等級・評価制度の外にいます。「来期の昇格に向けて」といった社内文脈の目標は意味を持ちません。目標は契約期間内に閉じた、具体的な業務成果として設計する必要があります。
- 契約形態の制約: 準委任契約か請負契約かによって、そもそも握れる目標の性質が変わります(次の章で詳しく扱います)。正社員にはない論点です。
- 指揮命令の壁: 準委任契約では、発注者に指揮命令権がありません。準委任契約の受託者は雇用関係にないため、発注者は業務の進め方や働き方に関する指示ができないとされています(東京労働局「偽装請負について」)。正社員のように「日々の業務を細かく管理して目標に向かわせる」というアプローチが取れないのです。
目標設定は評価・継続判断の質を決める「上流の投資」
業務開始前の目標設定にかける時間は、せいぜい1〜2時間です。しかしこの1〜2時間が、その後の数か月間の評価・単価交渉・継続判断の質をほぼ決めてしまいます。
最初に握った目標は、「契約を更新するか」「単価は妥当か」「次はどんな役割を任せるか」を判断するときの、唯一の客観的な基準になります。逆にここを飛ばすと、判断のたびに感覚と印象に頼ることになり、本人とも社内ともめる火種を抱え続けます。目標設定は、評価の手前で勝負を決める「上流の投資」だと捉えてください。
契約形態で変わる「握ってよい目標」の種類

業務委託と一口に言っても、契約形態は大きく「準委任契約」と「請負契約」に分かれます。そして、この違いによって設定すべき目標の性質がまったく変わります。ここを取り違えると、「請負なのにプロセスを細かく縛る」「準委任なのに完成責任を負わせる」といったミスマッチが起き、偽装請負やトラブルの引き金になります。まずは自社の契約がどちらなのかを判別し、それに合った目標の型を選びましょう。
準委任契約の目標 — プロセス・稼働・関与の質
準委任契約は、「仕事を完成させること」ではなく「業務を遂行すること」に対して報酬を支払う契約です。受託者は完成責任を負いません。したがって目標も、成果物の完成そのものではなく、業務への関与の質・プロセスに置くのが自然です。
準委任契約で握りやすい目標の例:
- スプリントへの参加と貢献: 各スプリントの計画・レビューに参加し、合意したタスクに着手している
- 進捗の見える化: チケット管理ツール上で進捗を可視化し、週次で状況を共有している
- レビュー貢献: チームのプルリクエストレビューに参加し、品質向上に寄与している
- 専門領域での助言: 設計やアーキテクチャの論点に対して、専門家としての見解を提示している
ポイントは、これらが「どう作業するか」の指示ではなく、「どういう関与をしてほしいか」という期待値の合意である点です。後述する指揮命令との線引きにも直結します。
請負契約の目標 — 成果物・品質・納期
請負契約は、「仕事を完成させること」に対して報酬を支払う契約です。受託者は完成責任を負います。したがって目標は、成果物そのもの・その品質・納期に置きます。
請負契約で握りやすい目標の例:
- 納品物の受入基準: 合意した機能要件をすべて満たした成果物を納品する
- 品質基準: 受入テストで重大バグがゼロであること、指定したコーディング規約に準拠していること
- 納期遵守: 合意した納品日までに成果物を納める
請負では「いつまでに、何を、どの品質で」を明確にすることが目標の中心になります。逆に、日々の作業プロセスや稼働時間を目標に組み込む必要はありません(むしろ組み込むべきではありません)。
自社の契約形態を判別するチェックポイント
「自社の契約がどちらか分からない」という場合は、次の2点を確認してください。
チェックポイント | 準委任契約 | 請負契約 |
|---|---|---|
完成責任の有無 | 完成責任を負わない(業務遂行が目的) | 完成責任を負う(仕事の完成が目的) |
報酬の対象 | 稼働・労働時間・業務遂行に対して支払う | 成果物・納品物に対して支払う |
月額の稼働ベースで継続的に開発に入ってもらう形なら、多くの場合は準委任契約です。「この機能を、この期日までに、いくらで」と一括で発注する形なら請負契約です。契約書のタイトルだけでなく、実態がどちらに当たるかを確認してください。判断に迷う場合は、契約締結前に法務や専門家に確認することをおすすめします。
「目標」と「指揮命令」の線引き|偽装請負を避ける目標設定の作法

業務委託エンジニアの目標設定で、発注者が最も身構えるのがこの論点です。「目標を設定して達成度を見たいけれど、指示を出しすぎると偽装請負になると聞いた。どこまで握っていいのか」——。ここでは、目標として握ってよいことと、指示してはいけないことの境界を、具体例で線引きします。
目標として握ってOKな例/NGになりやすい指示の例
偽装請負とは、形式上は業務委託でありながら、実態は労働者派遣のように発注者が指揮命令を行っている状態を指します。業務委託契約であるにもかかわらず、発注者がフリーランスなどの受託者に指揮命令を行うと偽装請負の状態となり、罰則の対象になり得ます(東京労働局「偽装請負について」、クロスデザイナー「準委任契約における指揮命令の考え方」)。
線引きの考え方を、対比で整理します。
目標として握ってOK(達成水準・期日・品質の合意) | 指揮命令になりやすくNG(手順・労働の細管理) |
|---|---|
「このスプリントで合意した機能を動く状態にする」 | 「今日の午前中はこの画面、午後はあの画面を作って」 |
「受入テストで重大バグゼロを満たす」 | 「テストはこの手順で、この順番でやって」 |
「コーディング規約に準拠した成果物を納める」 | 「毎日9時から18時まで稼働して」 |
「週次で進捗を共有する」 | 「常時オンラインにして、すぐ返信できる状態にして」 |
左側は「どんな成果・状態に到達してほしいか」という結果の合意です。右側は「どう作業するか・いつどこで働くか」という過程の管理であり、指揮命令と判断されやすい領域です。業務プロセスや作業時間を細かく指示することは、指揮命令と見なされます。
準委任で「成果の合意」と「指揮命令」を分ける考え方
準委任契約では発注者に指揮命令権がない、という前提が出発点です。ここで混乱しやすいのは、「指揮命令できないなら、目標も握れないのでは?」という誤解です。
両者は別物です。指揮命令は「手段への介入」、目標の合意は「結果についての相互の期待のすり合わせ」です。たとえば「この期間で、この機能群を、この品質で形にしてほしい」という期待を伝え、本人が「その役割で関わります」と合意することは、対等な当事者間の合意であって、一方的な業務命令ではありません。
実務上のコツは、目標を「お願い」や「合意」の言葉で表現し、「指示」「命令」の言葉や、手順・時間の細かい指定を避けることです。達成してほしい水準・期日・品質基準を握り、そこへの「行き方」は本人の裁量に委ねる。これが偽装請負を避けながら成果を握る基本作法です。
契約書・キックオフ資料に目標を明記しておくことが防御になる理由
口頭だけで目標をすり合わせると、後で「言った・言わない」になりがちです。さらに、偽装請負の判断では契約内容と労働実態が一致しているかが重視されます。契約書に重要項目を明記し、契約内容と実態を一致させることが、偽装請負を避けるうえで重要だとされています(パソナ「業務委託とは」)。
そこで、握った目標を契約書の業務範囲やキックオフ資料に「成果・水準の合意」として書き残しておくことをおすすめします。これは2つの意味で防御になります。1つは、評価のときに「最初にこう合意しましたね」と立ち返れること。もう1つは、目標が「結果の合意」であって「過程の指示」ではないことを文面で示せること。書面化は、本人ともめないためにも、社内・対外的に説明するためにも効きます。
業務委託エンジニアのKPI目標を本人と合意する5ステップ

ここからが本記事の中核です。発注者がキックオフまでに踏むべき、目標設定の具体手順を5ステップで示します。一貫して大切なのは、KPIを一方的に「押し付ける」のではなく、本人と「合意する」という姿勢です。納得した目標に対して、フリーランスは意欲的に動きます。逆に押し付けられた数値は形骸化します。目標設定のフレームワークであるSMARTの法則(具体的・測定可能・達成可能・関連性・期限)を、外部人材向けに翻訳しながら進めます。
ステップ1 期待値を言語化する
最初にやるべきは、本人と話す前に、発注者側で「何を任せたいのか」を言語化することです。ここが曖昧なまま会話を始めると、すり合わせが空中戦になります。
整理する観点は次の3つです。
- 任せたい成果: この発注で最終的に得たい状態は何か(例: 決済機能をリリース可能な状態にする)
- 背景: なぜそれが必要なのか、ビジネス上の文脈(例: 来期の新料金プラン開始に間に合わせる必要がある)
- 優先順位: 複数の期待がある場合、何を最優先するか(例: スピードより安定性を優先する)
背景まで伝えることが、外部人材には特に効きます。社内の文脈を知らない本人に「なぜこれが大事か」を共有することで、本人が自律的に良い判断をできるようになります。
ステップ2 契約形態に合った目標のたたき台を作る
次に、言語化した期待値を、契約形態に合った目標のたたき台に落とします。先ほど整理したとおり、準委任ならプロセス・関与の質、請負なら成果物・品質・納期が軸です。
このとき、SMARTの観点で「測定可能」にすることを意識します。「品質を高くする」ではなく「受入テストで重大バグゼロ」、「積極的に関わる」ではなく「週次のスプリントレビューに参加し進捗を共有する」というように、誰が見ても達成・未達を判断できる表現にします。ただしこの段階では完璧を目指す必要はありません。あくまで本人とすり合わせるための「たたき台」です。
ステップ3 キックオフで本人とすり合わせる
たたき台ができたら、キックオフの場で本人とすり合わせます。ここが「合意」と「押し付け」の分かれ目です。
たたき台をそのまま提示するのではなく、「こういう成果を期待しているが、専門家から見て現実的か」「この水準は妥当か」と本人の見立てを引き出してください。経験豊富なフリーランスエンジニアほど、「その期日ならこの範囲が現実的」「ここはリスクがあるので前提を確認したい」といった有益なフィードバックを返してくれます。
このプロセス自体が、目標の精度を上げると同時に、本人の当事者意識を高めます。自分が関わって決めた目標には、人は責任を持って取り組むものです。
ステップ4 測定方法と振り返り頻度を決める
目標に合意したら、「それをどう測るか」「いつ振り返るか」をセットで決めます。ここを決めずに目標だけ握ると、結局あとで「達成したのか分からない」状態に逆戻りします。
決めるべきは次の3点です。
- 誰が測るか: 発注者側の誰が達成度を確認するのか
- 何で測るか: チケット管理ツールの進捗、受入テストの結果、レビューの記録など、客観的な材料は何か
- いつ測るか: 週次・スプリント単位・月次など、振り返りの頻度
外部人材の場合、定期的な1on1や振り返りの場を設けることが特に有効です。成果だけでなくプロセスや認識のずれを早期に拾い、軌道修正できます。月単位で発注している準委任なら、最低でも月1回は振り返りの場を持つことをおすすめします。
ステップ5 合意を書面化し評価につなぐ
最後に、合意した内容を1枚のシートに書き残します。口頭の合意は時間とともに記憶が食い違うため、必ず書面(または共有ドキュメント)に残してください。次の章で紹介する「目標合意シート」が、その器になります。
ここで書き残した目標が、業務遂行中の評価、契約更新の判断、単価交渉のすべての土台になります。「最初にこう合意した」という共通の基準があるからこそ、評価の場でもめず、社内にも説明できる。設定フェーズと評価フェーズは地続きであり、ここで作った合意が後の評価の物差しになります。実際の評価の進め方や評価指標の選び方については、業務委託エンジニアをKPIで評価する方法も併せて参考にしてください。
キックオフで使う目標合意シートの作り方

5ステップで握った内容を、実際に1枚のシートに落とし込みます。ここでは、キックオフでそのまま使える目標合意シートの項目例と、記入の良し悪しの具体例を示します。網羅的なフォーマットや職種別の指標カタログまでは踏み込みませんが、たたき台としては十分なものを目指します。
目標合意シートに入れる項目
最低限、次の項目を1枚にまとめておくと、後の評価・社内説明にそのまま転用できます。
項目 | 記入内容 | 記入のポイント |
|---|---|---|
契約形態区分 | 準委任 / 請負 | どちらかを明記。目標の性質がここで決まる |
目標 | 達成してほしい成果・状態 | 「結果の合意」として書く。手順は書かない |
達成水準 | 何をもって達成とするか | 測定可能な表現にする(例: 重大バグゼロ) |
期日 | いつまでに | スプリント単位・納期など具体的に |
測定方法 | 誰が・何で測るか | 客観的な材料を指定(テスト結果、進捗記録など) |
振り返り頻度 | いつ振り返るか | 週次・月次など。1on1の有無も |
背景・優先順位 | なぜ・何を優先するか | 本人の自律的判断を助ける情報 |
この7項目を埋めるだけで、「業務開始前に、もめずに・偽装請負にもならず・後で評価できる形で握る」という最初の合意が形になります。社内に対しても、このシートを見せれば「こういう目標で発注しています」と即座に説明できます。
良い目標/曖昧な目標の書き分け例
同じ意図でも、書き方次第で「評価に耐える目標」と「またもめる目標」に分かれます。準委任契約のケースで、1組の対比を示します。
曖昧な目標(後でもめる)
決済まわりの開発を、いい感じに進めてほしい。積極的にチームに関わってくれると助かる。
これでは「いい感じ」「積極的に」の基準が人によって異なり、評価のしようがありません。さらに「進めてほしい」という表現は、過程への期待なのか結果への期待なのかも曖昧です。
良い目標(評価に耐える)
【契約形態】準委任 【目標】決済機能の改修を、リリース可能な品質まで到達させる関与をする 【達成水準】合意した改修チケットを各スプリントでクローズし、レビューで指摘された重大な不具合を残さない 【期日】6スプリント(約3か月)以内 【測定方法】PdMが、チケット管理ツールの進捗と週次レビューの記録で確認 【振り返り頻度】週次のスプリントレビュー+月1回の1on1 【背景・優先順位】来期の新料金プラン開始に間に合わせる必要があり、スピードと安定性のバランスを重視
後者は、誰が見ても達成・未達を判断でき、かつ「手順の指示」になっていません。準委任の制約を踏まえつつ、評価に耐える形になっています。職種・領域ごとのより詳細な指標例や、コスト・ROIの観点まで含めて外部人材活用の判断材料を体系的に整理したい場合は、外部エンジニア活用のROI・コスト試算ガイドも用意していますので、自社のケースに合わせて活用してください。
よくある質問(FAQ)
業務委託エンジニアの目標設定で、発注者からよく寄せられる疑問にお答えします。
Q. 業務委託に目標を設定すると、指揮命令・偽装請負になりませんか?
目標を握ること自体は問題ありません。偽装請負になるのは「作業手順を細かく指示する」「労働時間や勤務場所を指定する」など、過程を管理する行為です。「達成してほしい成果・水準・期日・品質基準」を合意し、そこへの行き方を本人の裁量に委ねる形なら、対等な当事者間の合意であって指揮命令ではありません。線引きの具体例は、本記事の偽装請負を避ける目標設定の作法の章を参照してください。不安な場合は、目標を「指示」ではなく「合意」の言葉で書き、契約書やキックオフ資料に明記しておくと安全です。
Q. フリーランス本人が目標設定を嫌がりませんか?
一方的に数値を押し付ければ嫌がられますが、本人とすり合わせて合意した目標は、むしろ歓迎されることが多いです。経験豊富なフリーランスほど「期待値が明確なほうが動きやすい」と考えます。曖昧な期待のまま走らされ、後から「思っていたのと違う」と言われるほうが、本人にとってもリスクだからです。納得して合意した目標には、当事者意識を持って取り組んでもらえます。ポイントは、ステップ3で本人の見立てを引き出し、一緒に作ることです。
Q. 目標が未達だった場合はどう対応すればよいですか?
未達が判明したら、いきなり評価を下げるのではなく、まず原因を切り分けることが大切です。前提条件が変わったのか、見積もりが甘かったのか、関与の質に問題があったのか。原因によって取るべき対応が変わります。未達時の立て直しは本記事のスコープを超えるため、業務委託KPI未達の対応で詳しく解説しています。
Q. 設定した目標を使って、実際にどう評価しますか?
本記事で握った目標は、評価フェーズの物差しになります。評価では、合意した達成水準に対する到達度を、あらかじめ決めた測定方法(テスト結果・進捗記録など)で確認します。具体的な評価指標の選び方や評価シートの作り方については、業務委託エンジニアをKPIで評価する方法を併せて参考にしてください。設定と評価は地続きであり、最初の合意がしっかりしているほど、評価はスムーズになります。
まとめ|目標設定は発注者の最初で最大の打ち手
業務委託エンジニアのマネジメントは、「設定 → 評価 → 未達対応」という流れで進みます。その起点が、本記事で扱った「目標設定」です。評価でもめるのも、社内に説明できないのも、その多くは最初に目標を握らなかったことに起因します。逆に言えば、業務開始前の1〜2時間を投資して目標を握れば、その後の評価・継続判断・単価交渉のすべてが格段に楽になります。
押さえるべきポイントを振り返ります。
- トラブルは目標設定の失敗の結果。評価の手前、契約・キックオフの時点で勝負を決める
- 契約形態に合った目標を握る。準委任ならプロセス・関与の質、請負なら成果物・品質・納期
- 偽装請負を避けるため、握るのは「結果の合意」まで。手順・時間の細管理(指揮命令)には踏み込まない
- KPIは押し付けず、本人とすり合わせて合意する。納得した目標には意欲的に取り組んでもらえる
- 合意は目標合意シートに書面化し、評価・社内説明の土台にする
明日からの第一歩は、シンプルです。本人と話す前に、「この発注で何を任せたいのか」を発注者側で言語化してみてください。任せたい成果・背景・優先順位の3点を書き出すだけで、キックオフの解像度が一気に上がります。そこから契約形態に合ったたたき台を作り、本人と握る。この最初の一手が、評価でもめない発注への確実な前進になります。
参考にした主な情報源



