「外部のエンジニアに発注して、このプロジェクトを進めてほしい」。上司や経営層からそう任されたものの、自社にはエンジニアが一人もいない。エージェントやプラットフォーム経由で候補者との面談は組めるようになったけれど、送られてきたスキルシートには見慣れない専門用語が並ぶばかりで、誰が優秀で誰がそうでないのか、まったく見当がつかない。こうした状況に置かれている発注担当者の方は、決して少なくありません。
業務委託でエンジニアを起用する企業は年々増えています。一方で、相手の技術力を正しく見極められないまま発注し、「期待していたスキルが備わっていなかった」「着任後すぐに実務経験のなさが露呈した」といったミスマッチも後を絶ちません。フリーランス向けに経歴を「盛る」手法が出回っているという報道もあり、発注側の警戒は強まっています。
ここで多くの非エンジニアの担当者がつまずくのは、「技術がわからない自分が、技術者の実力を判断していいのか」という根本的な不安です。コードは読めませんし、技術試験を出しても採点できません。スキルシートに書かれた経歴が本当かどうかも、自力では検証のしようがありません。それでも「この人に任せて大丈夫か」という判断は、自分が下さなければならない。これは相当なプレッシャーです。
結論から言えば、技術力そのものを直接測れなくても、業務委託エンジニアの実力を見極めることは可能です。鍵になるのは発想の転換です。「技術力を直接採点する」のではなく、「観察できる間接指標」と「失敗を防ぐプロセス」を組み合わせて判断するという考え方に切り替えれば、非エンジニアでも再現性のある評価ができます。
本記事では、技術知識を持たない発注担当者が業務委託エンジニアのスキルを評価する方法を、実行順に沿って解説します。スキルシートの確認ポイント、面談で使える質問と「良い回答・危険な回答」の見分け方、そして面談だけに頼らず実力を裏取りするトライアル発注や第三者レビューまで、自分の手で実行できる手順として整理しました。次の面談に自信を持って臨むための、実務的なチェック手順として活用してください。
非エンジニアが業務委託エンジニアのスキル評価でつまずく理由
最初に、なぜ非エンジニアの発注担当者がスキル評価に苦戦するのか、その構造を整理します。原因を言語化しておくと、「自分の能力が足りないから判断できない」のではなく「そもそも直接測れない情報を測ろうとしている」だけだとわかり、評価の方針を立てやすくなります。
非エンジニアがぶつかる3つの壁
技術がわからない担当者が業務委託エンジニアを評価しようとすると、典型的に3つの壁にぶつかります。
1つ目は、コードを読めないという壁です。 エンジニアの成果物の中核はコードですが、非エンジニアにはその品質を直接判断できません。きれいに整理されたコードなのか、後で問題を起こす書き方なのか、見ても区別がつきません。
2つ目は、技術試験を採点できないという壁です。 採用面接で技術的な質問を投げかけても、返ってきた答えが正しいのか、的外れなのかを判定できません。専門用語で淀みなく説明されると、内容の正確さとは無関係に「詳しそうだ」と感じてしまいがちです。
3つ目は、スキルシートの真偽を検証できないという壁です。 「Java 5年」「AWS構築経験あり」と書かれていても、それが事実かどうかを確かめる手段がありません。実際、開発の現場では「Java経験5年」とされた人材を受け入れたものの、着任後まもなく質問に答えられず、二週間で実務経験がほぼないと判明した事例も報告されています（日経クロステック）。バックグラウンドチェックの調査では、経歴詐称の発覚件数が前年から大きく増加しているとの報告もあり（バックグラウンドチェック比較ガイド）、書類の記載をそのまま信じるリスクは無視できません。
この3つの壁は、いずれも「技術力を直接測ろうとすると越えられない」という共通点を持っています。逆に言えば、直接測る以外の方法に切り替えれば、壁を回避できるということです。
「技術力を直接測る」のではなく「仕事を任せられるかを判断する」
そこで必要になるのが、評価の目的そのものを置き換えることです。
発注担当者が本当に知りたいのは、「この人のプログラミング能力は何点か」ではありません。「この人に発注して、期待どおりの成果物が、期待どおりの品質と納期で上がってくるか」です。これは技術力だけで決まるものではなく、コミュニケーションの取り方、進行管理のしかた、業務委託という立場への理解など、複数の要素で構成されています。そして、これらの多くは非エンジニアでも観察できます。
たとえば、専門用語を素人にもわかる言葉で説明できる人は、要件のすり合わせで認識のズレを起こしにくい傾向があります。過去の案件で何に苦労し、どう乗り越えたかを具体的に語れる人は、未知の課題への対応力が期待できます。こうした「観察できる間接指標」を積み上げていけば、コードを読めなくても「任せられるかどうか」の判断材料は十分に集まります。
本記事では一貫して、この「直接測れないものを、観察できる指標とプロセスで判断する」というアプローチを取ります。まずは何を観察すればよいのか、評価の軸から見ていきましょう。
評価すべきは技術力だけではない｜業務委託エンジニアを見極める4つの観点
業務委託エンジニアを見極めるとき、非エンジニアでも観察できる評価軸は大きく4つあります。技術力を直接測れなくても、この4観点に沿って候補者を観察すれば、判断の精度は大きく上がります。
技術力は「説明させて」間接的に測る
技術力そのものは採点できなくても、技術についての「説明のしかた」は評価できます。
優れたエンジニアは、複雑な技術を相手のレベルに合わせてかみ砕いて説明できます。逆に、本当は理解が浅い人ほど、専門用語を専門用語のまま並べて煙幕を張る傾向があります。面談では「今回のシステムで使う技術を、エンジニア以外の社内メンバーにも伝わるように説明してください」と頼んでみてください。たとえ話を交えながら平易に説明できる人は、技術への理解が深く、かつ社内との橋渡し役としても期待できます。
過去の経験の語り方も重要な手がかりです。「どんな課題があり、なぜその技術を選び、結果どうなったか」を筋道立てて説明できる人は、自分の頭で考えて仕事をしてきた証拠です。担当した範囲を主語を明確にして語れるかどうかも見てください。
コミュニケーション力
業務委託エンジニアは、多くの場合リモートかつ非常駐で働きます。日常的に顔を合わせない関係だからこそ、コミュニケーションの質が成果を大きく左右します。
見るべきは、第一に「非エンジニアにわかる言葉で話せるか」です。発注側に技術者がいない以上、専門用語をそのままぶつけてくる相手とは、要件のすり合わせが成立しません。第二に「報連相の質」です。面談の段階でも、回答の前に質問の意図を確認したり、わからない点を率直に「確認させてください」と返したりする姿勢があれば、進行中も適切に報告・相談してくれる可能性が高いといえます。逆に、わからないことを曖昧なまま流す人は、発注後にトラブルを抱え込むリスクがあります。
自己管理・進行管理力
非常駐の働き方では、日々の進捗を誰かが横で管理してくれるわけではありません。エンジニア自身が自分でタスクを分解し、優先順位をつけ、納期から逆算して進める力が求められます。
面談では「複数の案件を並行していた時期に、どう優先順位をつけて進めていましたか」「納期に間に合わないと気づいたとき、どう対応しましたか」と尋ねてみてください。具体的な工夫を語れる人は、自走できるエンジニアです。逆に「特に問題なくこなしていました」と抽象的に答える人は、進行管理の経験が浅いか、課題を振り返る習慣がない可能性があります。
業務委託特有の責任範囲の理解
正社員と業務委託では、責任の持ち方が根本的に異なります。業務委託では「指揮命令を細かく受けながら作業する」のではなく、「合意した成果物を、合意した条件で完成させる」ことが基本です。この違いを理解しているかどうかは、トラブルの起きやすさに直結します。
確認したいのは、契約形態（請負か準委任か）への理解、成果物の範囲と完成基準への意識、稼働時間や連絡可能な時間帯への認識です。「成果物はどこまでを納品物と考えますか」「修正対応はどの範囲まで想定していますか」といった質問に、自分の考えを持って答えられる人は、業務委託としての経験が確かで、後々の認識ズレも起きにくいといえます。発注後の評価やフィードバックの設計まで含めて整理したい場合は、フリーランスエンジニアの評価方法もあわせて参考にしてください。
面談前にスキルシート・職務経歴書で確認すべきポイント
評価は面談から始まるわけではありません。面談前のスキルシート・職務経歴書の段階で、非エンジニアでもできる確認が数多くあります。ここでふるいにかけておけば、面談の時間を本当に見極めたい相手に集中できます。
スキルシートで見るべきは「言語名」ではなく「役割と関与度」
多くの担当者は、スキルシートの「使用言語」や「経験年数」の欄に目を奪われます。しかし、「Python 3年」と書かれていても、それが主担当として設計から手がけた3年なのか、既存システムの一部を手伝った3年なのかで、実力はまるで違います。
見るべきは、言語名そのものではなく「どのプロジェクトで、どんな役割で、何を担当したか」の具体性です。「ECサイトの決済機能を、要件定義から実装・テストまで一人で担当」のように、プロジェクト・役割・担当範囲がセットで書かれているものは信頼できます。逆に、技術名と年数だけが羅列され、何をしたかが見えないスキルシートは、実態が薄い可能性を疑ってください。
経歴の盛りすぎ・詐称を疑うべき5つのサイン
技術知識がなくても、書類の「書き方」から不自然さは見抜けます。以下の5つは、経歴を盛っている、あるいは詐称している可能性を示すサインです。
- 記述が抽象的で、具体的な担当内容が書かれていない — 「各種開発に従事」「幅広い業務を担当」といった表現ばかりで、何を作ったのかが見えない。
- 経験年数と担当役割が釣り合わない — 「経験2年」なのに「大規模プロジェクトのリーダー」など、年数に対して役割が大きすぎる。
- 使用技術が極端に多い — あらゆる言語・フレームワークを「経験あり」と並べている。一人で短期間に習得しきれない量は、表面的に触れただけの可能性が高い。
- 成果や数値が一切書かれていない — 「何を、どこまで、どんな結果に導いたか」がなく、参加した事実だけが並んでいる。
- プロジェクトの期間と内容が矛盾している — 短期間では到底完成しないはずの規模のシステムを、極端に短い期間で「担当」したことになっている。
これらは単独では決定打になりませんが、複数が重なる場合は面談で重点的に深掘りすべきです。経歴詐称の手口は年々巧妙化しており、「経歴詐称マニュアル」が出回っているとの報道もあります（日経クロステック）。書類の段階で違和感を放置しないことが、後の失敗を防ぎます。
ポートフォリオ・GitHub・公開実績の確認方法
スキルシートに加えて、ポートフォリオや GitHub などの公開実績が提示されることがあります。コードそのものは読めなくても、非エンジニアが確認できるポイントはあります。
たとえば、GitHub であれば「最近も継続的に活動しているか」「他者のプロジェクトに貢献した記録があるか」「公開しているものに説明文（README）が丁寧に書かれているか」といった点は、技術的な内容を理解しなくても観察できます。ポートフォリオサイトであれば、実際に動くものが公開されているか、何を担当したかが明記されているかを見てください。GitHub の具体的な見方はエンジニアのポートフォリオ評価方法で非エンジニア向けに詳しく解説しています。ここで判断に迷う部分があれば、後述する第三者レビューで補えばよいので、無理にすべてを自力で判断しようとする必要はありません。
非エンジニアが面談で使える質問リストと「良い回答／危険な回答」の見分け方
ここが本記事の中核です。面談では、技術試験のような「正解のある問い」ではなく、非エンジニアでも回答の質を判断できる質問を使います。重要なのは、質問そのものよりも「答えのどこを見れば良し悪しがわかるか」です。各質問について、なぜ聞くのか・良い回答のサイン・危険な回答のサインをセットで示します。
なお、すぐに使える質問テンプレートをより多く用意したい場合は、フリーランスエンジニアの見極め方に非エンジニア向けの質問例を12個まとめています。本記事ではその中でも「回答の採点基準」に踏み込んで解説します。
過去の経験を深掘りする質問
質問例:「直近の案件で一番苦労した点と、それをどう解決したかを教えてください」
この質問は、候補者が実際に手を動かして課題を乗り越えてきたか、その経験を主体的に語れるかを測ります。
- 良い回答のサイン: 具体的な状況（何が・なぜ問題だったか）から始まり、自分がどう考え、どう動き、結果どうなったかを順序立てて語れる。うまくいかなかった点や反省も率直に含まれている。
- 危険な回答のサイン: 「いろいろ大変でしたが、なんとか乗り切りました」と抽象的に終わる。あるいは苦労した点を「特にありません」と答える（経験が浅いか、振り返る習慣がない）。チームの成果を自分一人の手柄のように語るのも要注意です。
今回の案件への理解度を測る質問
質問例:「今回の依頼内容で、技術的に難しそうな箇所や、つまずきそうなポイントはどこだと思いますか」
優秀なエンジニアは、仕事を引き受ける前にリスクを見通そうとします。この質問は、案件を自分ごととして捉えているか、経験に裏打ちされた予測ができるかを測ります。
- 良い回答のサイン: 「この機能は外部サービスとの連携が必要なので、相手側の仕様によっては想定より時間がかかるかもしれません」のように、具体的な懸念とその理由を挙げられる。安易に「問題なくできます」とは言わない。
- 危険な回答のサイン: 「特に難しいところはないと思います」「やってみないとわかりません」と、リスクを一切想定しない。何でも「できます」と安請け合いする姿勢は、後で「想定外でした」と覆るリスクが高いといえます。
説明力・翻訳力を測る質問
質問例:「このプロジェクトで使う技術を、社内のエンジニアではないメンバーにも伝わるように説明してください」
発注側に技術者がいない以上、専門用語をかみ砕いて伝えられる力は必須です。この質問は、コミュニケーションの土台となる「翻訳力」を測ります。
- 良い回答のサイン: たとえ話や身近な例を使い、相手の理解度を確認しながら説明する。「ここまでで不明な点はありますか」と双方向に進めようとする。
- 危険な回答のサイン: 専門用語を専門用語のまま並べ、噛み砕こうとしない。説明が一方通行で、相手が理解しているかを気にかけない。技術的に正しくても、これでは発注後の意思疎通に苦労します。
危険なサインの一覧
ここまでの質問を通じて、特に警戒すべき回答の傾向をまとめておきます。次の3つのいずれかが目立つ候補者は、慎重に判断してください。
- 曖昧な回答が続く: 具体的な状況・数字・固有名詞が出てこず、抽象的な言葉でやり過ごす。
- 専門用語で煙幕を張る: こちらが理解できないとわかっていて、あえて専門用語で押し切ろうとする。質問の本質をはぐらかしている可能性があります。
- 何でも「できます」と即答する: リスクや前提条件を確認せずに安請け合いする。本当に経験のあるエンジニアほど、引き受ける前に条件を確認するものです。
面談はあくまで主観的な印象に基づく評価です。これらのサインに気づけたとしても、面談だけで最終判断を下すのは危険です。次は、面談の結果を客観的に裏取りする方法を見ていきます。
面談だけで判断しない｜トライアル発注と第三者レビューで実力を裏取りする
どれだけ丁寧に面談しても、「話のうまい人」と「仕事のできる人」は必ずしも一致しません。面談での好印象が、そのまま成果物の品質を保証するわけではないのです。だからこそ、面談の評価を客観的な事実で裏取りする仕組みを持っておくことが重要です。「自分一人で見極めきれない」と感じるのは当然のことで、判断を分散させ、裏付けを取ることはむしろ賢明な進め方です。
トライアル発注・短期契約で「実物」を見る
最も確実な裏取りは、小さく発注して実際の仕事ぶりを見ることです。
いきなり本番のプロジェクト全体を任せるのではなく、まずは1〜2週間程度で終わる小規模なタスクを切り出して発注します。あるいは、最初は1か月の短期契約とし、問題がなければ段階的に範囲を広げる進め方もあります。実際に手を動かしてもらえば、スキルシートや面談ではわからなかった「実物の仕事」が見えてきます。これは経歴詐称やスキルミスマッチを発注後の早い段階で発見できる、最も実効性の高い方法です。
成果物の品質を非エンジニアが間接評価する方法
トライアルの成果物が上がってきても、コードの中身は読めません。それでも、非エンジニアが評価できる観点は十分にあります。
- 納期を守れたか: 合意した期限どおりに納品されたか。遅れた場合、事前に連絡と相談があったか。
- 指示を正しく理解できていたか: 依頼した内容と、出てきた成果物がずれていないか。認識のズレが多い相手は、本番でも手戻りが増えます。
- 修正対応の質: フィードバックを伝えたとき、的確に意図をくみ取って対応できるか。修正のたびに新たな問題が出るようなら注意が必要です。
- 報告・相談の頻度と的確さ: 進捗の報告が適切なタイミングであったか。判断に迷う点を早めに相談してきたか。
これらはすべて、技術知識がなくても観察できる指標です。納期・指示理解・修正対応・報連相という「仕事の進め方」の質は、長期的な信頼性を予測する有力な材料になります。
第三者の技術レビューで裏取りする
コードの品質そのものをどうしても確認したい場合は、技術がわかる第三者に評価を依頼するのが現実的です。
社外に信頼できるエンジニアの知人がいれば、その人にスキルシートの妥当性や成果物のレビューを依頼する方法があります。心当たりがなければ、開発会社に技術面の評価やコードレビューをスポットで依頼することもできます。少額の費用はかかりますが、発注後にスキルミスマッチが発覚して大きな手戻りが生じるリスクを考えれば、有効な保険です。「技術判断は技術がわかる人に任せ、自分は仕事の進め方やコミュニケーションを評価する」という分担にすれば、非エンジニアでも責任を持って発注判断を下せます。
評価の精度を上げる発注体制｜ミスマッチを構造的に減らす
ここまでは個別の候補者をどう見極めるかを扱ってきました。最後に視野を広げ、そもそもミスマッチが起きにくい発注のあり方を考えます。毎回ゼロから不安を抱えて見極めるのではなく、仕組みでミスマッチを減らせれば、評価の負担そのものが軽くなります。
要件と成果物を先に言語化する
ミスマッチの多くは、スキル評価以前の「要件の曖昧さ」から生まれます。何を作ってほしいのか、どこまでを成果物とするのか、いつまでに必要なのかが曖昧なまま発注すれば、どれだけ優秀なエンジニアでも期待とのズレは避けられません。
発注前に、目的・成果物の範囲・完成基準・納期・予算を、できる限り具体的に言語化しておきましょう。要件が明確であれば、候補者の理解度や提案の質も比較しやすくなり、評価の精度が自然と上がります。要件定義からトライアル判定までを工程として設計する方法は、業務委託エンジニア採用のミスマッチを防ぐ4工程プロセス設計で詳しく解説しています。
技術判断を補完できるパートナーを持つという選択
非エンジニアの担当者が、毎回一人で技術判断の責任を背負い続けるのは、現実的とはいえません。そこで選択肢になるのが、技術判断を補完してくれるパートナーを持っておくことです。
たとえば、信頼できる開発会社や技術アドバイザーと継続的な関係を築いておけば、候補者のスキル評価やコードレビュー、要件の妥当性チェックなどを、必要なときに相談できます。個別案件ごとにフリーランスを直接見極める方法と、技術判断を担保できるパートナーを併用する方法を組み合わせれば、発注の安定性は大きく高まります。採用チャネルそのものを選ぶ判断軸については、フリーランスエージェントと直接採用の比較も参考になります。属人的な見極めに頼り続けるのではなく、仕組みとして技術判断を担保できる体制を整えることが、ミスマッチを構造的に減らす最終的な答えになります。
まとめ｜技術がわからなくても業務委託エンジニアは見極められる
業務委託エンジニアのスキル評価は、技術力を直接採点しようとするから難しく感じるだけです。「観察できる間接指標」と「失敗を防ぐプロセス」を組み合わせれば、非エンジニアでも再現性のある見極めができます。本記事で解説した手順を、実行する順番でチェックリストとして整理します。
- 発想を切り替える — 「技術力を直接測る」のではなく「仕事を任せられるかを判断する」。観察できる指標とプロセスで判断する。
- 4つの観点で評価する — 技術力（説明させて間接的に測る）・コミュニケーション力・自己管理／進行管理力・業務委託特有の責任範囲の理解。
- 面談前に書類を確認する — スキルシートは「言語名」ではなく「役割と関与度」を見る。盛りすぎ・詐称の5つのサインに注意し、ポートフォリオや GitHub も非エンジニアなりの観点でチェックする。
- 面談で「採点基準」を持って質問する — 過去の経験・案件理解度・説明力を問う質問に対し、良い回答／危険な回答のサインを照らし合わせて判断する。
- 面談だけで決めない — トライアル発注や短期契約で実物を見て、納期・指示理解・修正対応・報連相を間接評価する。必要なら第三者の技術レビューで裏取りする。
- 仕組みでミスマッチを減らす — 要件と成果物を先に言語化し、技術判断を補完できるパートナーを持つことで、属人的な見極めから体制での担保へ移行する。
この順序で進めれば、「技術がわからない自分が選んで大丈夫か」という不安は、「この観点とこの質問で見極められる」という確信に変わります。コードを読めなくても、技術試験を採点できなくても、発注判断を下すために必要な材料は、ここまでの手順で十分に集められます。
採用前のスキル評価から、発注後のオンボーディングや継続判断までを一冊で見通したい方は、「フリーランスエンジニア採用・活用ガイド」もご活用ください。本記事で扱った見極めの観点に加え、契約・オンボーディング・トラブル防止までを体系的にまとめています。次の面談を、自信を持って迎えてください。
