フリーランス開発者を外部から調達しようとして、候補者の多さに逆に迷った経験がある方は少なくないはずです。Next.js、TypeScript、PostgreSQL、Stripe、AWSといった技術スタックで検索すれば、候補は数百人、数千人単位で出てきます。にもかかわらず、実際に発注する相手を決める段階になると、途端に判断が難しくなります。
この記事は、外部の開発者やフリーランスエンジニアに案件を発注する立場の方、あるいはAIコーディングツールを前提にした開発体制の中で外部リソースを組み込もうとしているPM・テックリード向けに書いています。採用プラットフォーム上の情報だけでは見えてこない判断軸を整理しました。
なぜ「技術スタックが一致している」だけでは決められないのか
まず前提を整理します。求人票や発注条件に「Next.js経験者」「AWS運用経験あり」と書くのは簡単です。しかしこれらは候補者をふるい落とすための弱いフィルタに過ぎません。
Stripe（オンライン決済を扱うための開発者向けAPI基盤）を触ったことがある、という経歴は、簡単な決済ボタンを実装した経験かもしれませんし、サブスクリプションの失敗課金・返金・Webhook処理まで含む複雑な決済フローを設計した経験かもしれません。プロフィール上の「Stripe対応可」という一文からは、その違いが読み取れません。
同様に、AWS（Amazon Web Services、クラウドインフラの代表的なサービス群）という記載も、EC2を1台立てただけの経験から、マルチリージョンでの本番運用まで幅があります。技術スタックの一致は「会話が成立する最低条件」であって、「任せられる根拠」にはならないという点を押さえておく必要があります。
判断軸1: 経験年数ではなく経験の中身
「シニアエンジニア募集、経験5年以上」という条件は分かりやすい反面、実態を反映しません。
5年間同じようなWordPressサイトの保守だけをしてきた人と、3年間でAPI設計・本番障害対応・デプロイ・決済連携・アーキテクチャ判断まで経験した人を比べると、年数だけでは後者の価値を測れません。深夜に本番障害が起きたときに頼れるのは、多くの場合後者です。
確認方法としては、職務経歴やポートフォリオの説明文に「担当した」ではなく「どう判断したか」が書かれているかを見るのが実践的です。判断の記述がない経歴は、経験の深さが見えにくい状態だと考えてよいでしょう。
判断軸2: ポートフォリオは結果であって過程ではない
完成したアプリケーションのスクリーンショットは、見栄えこそ良いものの、その人が何を担当したのかを語ってくれません。
15人のチームのうちフロントエンドだけを担当したのか、1人でアーキテクチャから実装まで回したのか。既存コードベースを引き継いだだけなのか、ゼロから設計したのか。この違いは、同じ「完成品」からは判別できません。
面接やヒアリングの場では、「これを作りましたか」という質問ではなく、「このプロジェクトで一番難しかった技術的な問題は何で、どう解決しましたか」という聞き方に変えると、担当範囲と判断力の両方が見えてきます。質問の立て方ひとつで、得られる情報の解像度が変わります。
判断軸3: コミュニケーションは技術力と別に評価する技能
リモートで外部開発者に発注する場合、進捗報告の質がそのままプロジェクトの不確実性を左右します。
「バックエンドはほぼ完了しました」という報告と、「認証とユーザーAPIは完了、現在Stripe Webhookを実装中。決済失敗時の処理に課題があり、明日中に解消予定」という報告を比べてみてください。書いたコード量は同じでも、発注者側が得られる視界はまったく違います。
曖昧な報告が続く相手には、週次でよいので「完了したこと」「今取り組んでいること」「詰まっている箇所」の3点を定型フォーマットで求めるとよいでしょう。これだけで初期の不安はかなり減らせます。
判断軸4: 案件の複雑さと経験の複雑さを一致させる
シンプルなMVP（Minimum Viable Product、検証用の最小限の製品）を作りたいだけなら、5000万ユーザーを想定したアーキテクチャを設計できる人材は不要です。むしろ「完璧な設計より今日動くものを優先できる」判断力のほうが価値を持ちます。
逆に、1日数千件のトランザクションを処理するシステムを、ランディングページしか作ったことのない人に任せるのはリスクが高い選択です。採用で見るべきは「スキルの有無」ではなく「問題の複雑さと経験の複雑さが釣り合っているか」という一致度です。
選択肢の比較
外部発注の判断材料として何を軸に見るか、代表的な4つを整理すると以下のようになります。
| 判断軸 | 見るべき情報源 | 弱点 |
|---|---|---|
| 技術スタックの一致 | プロフィール・求人検索フィルタ | 深さが分からない |
| 経験年数 | 職務経歴書 | 中身を反映しない |
| ポートフォリオ | 公開実績・リポジトリ | 担当範囲が不明 |
| ヒアリング（判断の質問） | 面接・トライアル案件 | 時間がかかる |
ケース別の推奨
短期の小規模案件で、決済もスケールも絡まないランディングページ制作なら、技術スタックの一致とポートフォリオの確認だけで十分です。判断軸1・3にそこまで時間をかける必要はありません。
本番運用中のSaaSに機能追加する案件や、Stripeの決済フロー改修のような既存システムへの手入れが必要な場合は、判断軸2と3を重視してください。既存コードの文脈を壊さずに進められるか、進捗報告の解像度が高いかを、短い有償トライアル案件で見極めるのが現実的です。
基幹システムやアーキテクチャの再設計に近い大型案件では、判断軸1・2・4すべてを使い、可能であれば技術面接に加えて設計レビューの場を設けるべきです。ここでスキルタグだけに頼ると、複雑さの不一致によるプロジェクト失敗のリスクが高まります。
あえて見送るべき条件
逆に、次のような状況では、今回挙げた判断軸をフル活用する必要はありません。
- 社内に技術レビューできる人材がおらず、発注先の技術的判断を検証する手段がない場合（この場合は先に社内体制を整えるほうが先決です）
- 1週間未満で終わる使い捨てのプロトタイプで、品質より速度が最優先の場合
- 既に継続発注している相手がいて、新規開拓のコストがリスクに見合わない場合
無理に厳密な選定プロセスを回そうとすると、かえって発注までのリードタイムが伸び、本末転倒になりかねません。
まとめ
技術スタックが一致する候補者は簡単に見つかる時代になった一方で、「任せられるかどうか」を判断する材料は従来のフィルタだけでは足りません。
次に外部開発者を探すときは、求人検索の絞り込み条件を増やす前に、ヒアリングの質問を「作りましたか」から「どう判断しましたか」に変えてみてください。それだけで得られる情報の解像度が変わります。
また、案件の複雑さと候補者の経験の複雑さが釣り合っているかを、発注前に一度言語化しておくと、過剰スペックな人材への依頼や、逆に力不足な人材への丸投げを避けやすくなります。