フリーランス案件の事前調査｜企業・現場・商流の調べ方と質問リスト

事前調査を4層に分けて考える

事前調査を「なんとなく調べる」で済ませると、案件票を読む時間・面談で聞く時間・企業を検索する時間が混ざって、抜けに気づけません。応募から参画までの数日〜2週間の間に、4つの層に分けて情報源を割り当てるのが実務的です。

なぜ「案件・現場・企業・商流」の4層か

案件票は「募集の枠」を示すもので、実際の現場・企業・商流とは別物です。案件票だけを見て応募し、面談で企業側の話だけを聞き、商流を確認せずに契約する、というルートが最も抜けが多くなります。層に分けると、面談の限られた時間で「案件票では埋まらない情報」に絞って質問できます。

4層の情報源マップ

企業の裏取りは面談前に終わらせておくと、面談時間を現場と商流の質問に集中できます。案件票の追加確認は、面談前にエージェント経由で回答が来る範囲は先に潰しておきます。

事前調査にかける時間の目安

独立初期から中堅のフリーランスが、公開情報と面談準備を自分で行う前提では、1案件あたり2〜4時間がひとつの目安です。応募段階で1時間（案件票と企業）、面談前に1時間（質問リストの作成）、面談で1時間、面談後に1時間（違和感の言語化と最終判断）が目安の内訳です。稼働中に並行して探す場合、時間が取れない案件は無理に受けず、時間が取れる案件に絞る判断も必要になります。

ミニFAQ

Q. 事前調査を短縮したいときはどこを削るか

A. 削るのは「企業の裏取り」ではなく「案件票の読み込み」を削ります。案件票は面談で追加確認できますが、企業の登記・IR・技術文化は面談後に聞いても検証しづらいためです。企業裏取りだけは30分でも面談前に必ず取っておきます。

案件票で読むべき8項目と裏取り

案件票は「見出し」で判断すると危険です。役割・体制・技術スタックの細部は但し書きに埋め込まれていることが多く、面談で追加確認しないと参画後のギャップにつながります。

見出しでは判断しない

「PMO案件」「バックエンド開発」といった見出しは範囲が広く、実際の担当領域を示しません。「PMO」と記載されていても実務はメンバー折衝が主だったり、「バックエンド」でもインフラ運用の割合が半分だったりします。応募前に本文を最後まで読み、見出しと本文のズレを洗い出します。

役割・担当領域の粒度

案件票の「役割」欄には抽象的な言葉が並びがちです。次の観点で追加ヒアリングを依頼します。

• 自分1人で担当するか、複数人で分担するか

• 担当領域の境界（例：バックエンドAPI設計まで／インフラ運用は別担当）

• 意思決定に関与するか、指示された実装のみか

• レビュー担当者は社員か、他のフリーランスか

技術スタックのバージョンと現行構成

「Ruby on Rails」とだけ記載されていても、Rails 5系のレガシー保守なのか、Rails 7系の新規開発なのかで求められる知識が大きく変わります。バージョン、フレームワークの本流構成、周辺の依存ライブラリ（ジョブキュー、ORM、認証周辺）を面談前にエージェント経由で確認します。古いバージョンで保守メインの案件は、フレームワーク本体や周辺ライブラリがEOL（サポート終了）に近い可能性があるため、アップデート計画の有無を必ず聞いておきます。

体制・人数・チーム構成

「体制5名」と書かれていても、社員／協力会社／フリーランスの内訳は不明な場合が多いです。次を確認します。

• 社員：フリーランス比率

• 業務委託の割合（半数以上が業務委託の現場では、社員決裁者との距離が遠くなるケースもあるため、意思決定者が誰かを確認する）

• チームリード・PMは社員か

• 面談担当者と現場責任者は同じ人か

稼働・稼働時間帯の但し書き

「週5・9-18時」と書かれていても、リリース前後の残業慣行・深夜対応・オンコール対応の但し書きが別途あることがあります。「稼働時間帯外の対応可否」を必ず確認します。

単価と精算幅

単価は「精算幅」と併せて読みます。140〜180時間精算の案件と、160〜200時間精算の案件では、実質単価の下限が変わります。精算超過時・不足時の単価も確認します。

期間と更新可否

「3ヶ月」と書かれていても、初回契約が3ヶ月で以降は自動更新の案件と、3ヶ月で契約終了の案件は別物です。契約更新の判断時期・更新可否の目安・更新面談の有無を確認します。

リモート条件と出社頻度

「フルリモート可」でも、キックオフ時のみ出社／月1出社／週1出社など幅があります。出社頻度・出社場所・交通費支給の有無・情報セキュリティ要件（社内PCの貸与、VPN経由等）まで詰めておきます。

ミニFAQ

Q. 案件票に書いていない情報を聞くとエージェントに嫌がられないか

A. 具体的な質問は歓迎されるケースが多いです。抽象的に「もう少し詳しく」ではなく、「バージョン・体制の内訳・オンコールの有無」など個別項目で質問すると、エージェント側も企業に確認しやすくなります。詳しい質問リストはフリーランス面談で聞くべき質問リスト｜ミスマッチを防ぐ確認事項を参照してください。

企業情報の裏取り3ソース

企業の裏取りは面談前に終わらせておきます。公式サイト・法人番号公表サイト・求人ページの3つで最低限をカバーできます。

公式サイトで見る観点

トップページより「事業内容」「会社概要」「採用情報」を優先します。役員構成・資本金・主要取引先・事業の主力領域を押さえておくと、面談で「事業のフェーズがつかめている前提の質問」ができます。エンジニア向けページ・技術ブログがある場合は、記事の更新頻度と直近半年の記事内容も確認します。更新が数年止まっている技術ブログは「発信文化がない現場」ではなく「発信担当者が退職した現場」のケースもあるため、単独では判断せず、他情報と組み合わせて解釈します。

法人番号公表サイト・登記情報の使い方

国税庁の法人番号公表サイトで、法人名・所在地・法人番号を確認できます。案件票の企業名と登記上の商号にズレがないか、本店所在地が公式サイトの記載と一致するかを確認します。ズレがある場合、グループ会社経由の発注や、屋号での事業展開などの可能性があります。詳細な登記事項は法務局の登記情報提供サービスから取得できます（有料）。

求人ページ・エンジニアブログから読む技術文化

企業の求人ページに掲載されている技術スタック・チーム構成・開発プロセスは、案件票よりも実態に近いことがあります。求人票の「開発フロー」「使用ツール」「1日のスケジュール例」は目を通しておきます。Wantedlyなどの採用媒体や自社採用ページのエンジニアインタビューも参考になりますが、採用向けのポジティブな情報が中心のため、他情報と組み合わせて判断します。

IR資料・決算書から見る事業健全性

上場企業なら直近の四半期IR資料を、非上場でも公開されている決算資料を確認します。事業の主力領域と、案件が組み込まれるプロジェクトの位置づけが分かります。赤字継続・大幅な事業縮小が公表されている場合、案件そのものが途中で打ち切られるリスクを織り込んで判断します。

ミニFAQ

Q. スタートアップで公開情報が少ない場合はどうするか

A. 代表・CTOのSNSと登壇資料、資金調達のプレスリリースを追います。直近6ヶ月の資金調達履歴と、代表のSNSでの発信内容から、事業の方向性と組織状態をある程度読めます。スタートアップでは「直近の資金調達状況」「今後半年のマイルストーン」を質問すること自体は珍しくありませんが、開示範囲は企業によります。答えにくそうな場合は「差し支えない範囲で」と前置きすると無難です。

現場を読むための面談での逆質問リスト

案件票と企業情報で埋まらない部分は、面談での逆質問で補います。逆質問は「聞かなかったこと」があとで問題化しやすいため、質問リストを固定化しておくのが安全です。逆質問の網羅性を上げるには、面談で聞かれる質問側の対策も並行して行うと当日の余裕が生まれます（フリーランスエンジニアの面談で聞かれる質問と回答例も参照）。

開発体制・レビュー文化に関する質問

• コードレビューの担当者は誰か（社員／リード／全員相互）

• レビュー観点のガイドラインは文書化されているか

• 1PRのレビュー所要時間の平均

• レビュー後の修正差し戻しの割合

• CI/CDの整備状況とテスト自動化の範囲

稼働・時間管理に関する質問

• 定時外の連絡（Slack等）にどこまで対応する慣行か

• リリース前後の残業実態

• 有給・稼働調整のフレキシビリティ

• オンコール・障害対応の当番制の有無

意思決定プロセスに関する質問

• 技術選定の意思決定は誰が行うか

• フリーランスから提案した施策の採用実績

• 意思決定にかかる期間の目安

• ステークホルダーとの調整に自分が入るか

参画後のオンボーディングに関する質問

• 初日のオンボーディング担当者

• 開発環境のセットアップ手順書の有無

• キャッチアップに使えるドキュメントの整備状況

• 初月のマイルストーン設定の有無

逆質問で避けるべきパターン

• 案件票に書かれている内容の言い換え質問

• 「何かご質問はありますか？」に対する「特にありません」（現場理解の姿勢が伝わらない）

• 給与・待遇の話に偏った質問

• 抽象的な「開発文化はどうですか？」（具体的観点で聞く）

商流を確定させる質問と読み方

商流の確認を避ける習慣は、多重下請けや契約トラブルの温床になります。面談の後半、契約詳細の話が出るタイミングで必ず商流を質問します。仕組みそのものは多重下請け構造とはに整理してあるため、本記事は「調べ方」に絞ります。

発注元と商流の階層を確認する

「今回の案件の発注元はどちらでしょうか」「面談担当の御社と発注元は同一ですか」を素直に質問します。エージェント経由の場合、エージェント→SIer→発注元、のようにエージェントが把握している範囲でも回答が得られるケースが多いです。

自分は何次請けか

契約上のフローで自分が何次に位置するかを確認します。エージェント経由の契約でも、「準委任でエージェントとフリーランスの直接契約」なのか、「エージェント→中間法人→フリーランス」なのかで、報酬支払フロー・トラブル時の窓口が変わります。

契約書・NDAで確認するポイント

契約書のドラフトを面談前後で共有してもらい、次を確認します。

• 契約の当事者（自分の契約相手は誰か）

• 契約種別（準委任／請負）

• 業務範囲の記載

• 秘密保持の範囲と期間

• 損害賠償の上限

• 契約解除の条件（中途解約時の扱い）

• 競業避止義務（他案件との兼務可否）

契約種別の判断や条項の読み方に不安がある場合、弁護士など契約実務に詳しい専門家に相談するか、中小企業庁の下請ガイドラインなどの公的資料で発注者・受注者間のルールを確認しておくと安心です。契約条項の解釈や法的リスクの最終判断は本記事の範囲外であり、専門家に確認してください。

支払サイトと入金経路

支払サイト（月末締め翌月末払い等）と、エージェント経由の場合の入金経路を確認します。商流が長いほど関与法人が増えるため、入金確認や責任分界が複雑になりやすく、トラブル時の確認コストが上がる構造があります。

直案件と多重下請けの見分け方

案件票に「直請け案件」と書かれていても、実際は中間法人が入っていることがあります。契約書の当事者名と発注元の記載を突き合わせ、間に別法人がある場合は多重構造の可能性があります。直案件を狙う場合の獲得ルートはフリーランスエンジニアの直案件の取り方に整理しています。

単価と稼働条件の妥当性を検証する

案件の単価と稼働条件が市場相場から乖離していないかは、事前調査の最後で確認します。ここで単価だけを見て判断すると、他条件のマイナスを見落とすため、稼働条件とセットで検証します。

提示単価が相場と合っているか

主要フリーランスエージェントの公開案件（週4〜5日・準委任・首都圏）を参考に、提示単価が同スキル帯の相場から乖離していないかを確認します。比較の際は、職種・経験年数・稼働日数・リモート比率・上流工程の有無をできるだけ揃えて突き合わせます。相場より高い場合は、オンコール・深夜対応・高難度要件など、単価に反映されている条件を確認し、相場より低い場合は「リモート可・稼働柔軟」など単価以外のメリットが具体化されているかを見ます。

自分が狙える単価の目安は、無料のフリーランスエンジニア単価診断で確認できます。単価を体系的に上げる考え方はフリーランスエンジニアの単価相場と単価の上げ方にまとめています。

稼働日数・稼働時間の但し書きを疑う

「週5・160-200時間精算」と「週5・140-180時間精算」では、実質単価の下限が変わります。精算幅・精算超過時の単価・精算不足時の減額ルールを確認します。

交通費・機材貸与・情報セキュリティ費用の扱い

出社頻度がある案件では交通費の実費支給有無を、リモート案件では貸与PC・VPN費用・セキュリティ機器の負担範囲を確認します。ここが自己負担になると、実質単価が下がります。高単価案件を絞る観点は高単価案件に共通する5つの条件に整理してあります。

ケース別｜事前調査の重点を変える

独立1年目・初回参画のケース

事前調査の全項目を丁寧に踏むよりも、「契約書の当事者」「稼働時間の但し書き」「オンボーディング担当者」の3つを最優先で確認します。1年目は「聞かなかったことによる想定外」の被害が大きいため、抜けを減らすほうが優先度が高くなります。

継続案件・長期参画を狙うケース

長期参画を狙う場合、更新可否の判断時期と、事業側の中期計画を重点的に確認します。「事業の縮小可能性」「予算枠の見通し」まで踏み込めるとリスク管理がしやすくなります。案件の切り替え時期の考え方は案件を変えるべきタイミングと判断基準を参考にできます。

スポット・短期案件で調査時間が取れないケース

短期案件は事前調査に時間を取れないことが多いです。「契約書の当事者」「業務範囲の明文化」「支払サイト」の3点だけは絶対に妥協せず、他は面談で口頭確認する運用に切り替えます。

直請け（エージェント外）で参画するケース

直請けの場合、エージェントが担うことの多い調査・契約補助・支払フォローを、自分で補う必要があります。企業の登記情報の確認、契約書のリーガルチェック（必要に応じて弁護士相談）、支払時の入金確認体制の整備を、応募段階から準備します。

参画48時間前の最終チェックリスト

参画直前は準備物と条件確認に絞り、細かい調査はここまでで終わらせておきます。前日だと契約・アカウント発行・貸与物の修正が間に合わないため、遅くとも48時間前を目安に確認する運用が実務的です。

契約書の合意事項再確認

• 業務範囲の明文化

• 稼働時間帯の但し書き

• 単価・精算幅・支払サイト

• 中途解約条項

稼働開始日の準備物

• 業務PC（貸与／持ち込み）

• 開発環境アカウント（Slack、GitHub、社内システム）

• VPN・セキュリティ機器

• 参画開始日の初日連絡先

参画初日の質問リスト

• チームメンバーへの自己紹介の場

• 初日のマイルストーン

• 開発環境セットアップ手順書

• キャッチアップに使えるドキュメントの入手

想定リスクと撤退基準

• 稼働開始から2週間で「事前に聞いていた話と大幅に違う」場合の対応

• 中途解約時の相談窓口（エージェント経由の場合の担当者）

• 稼働超過が続いた場合の交渉方針

よくある失敗と対策

案件票を「読んだつもり」で確認漏れ

案件票の見出しだけで判断し、本文の但し書きを読み飛ばすと、参画後に「聞いていない仕様」が出てきます。応募前に案件票を印刷または別画面で開き、8項目チェックリストと突き合わせて読む運用に切り替えると抜けが減ります。

面談で聞きにくいことを聞かずに参画

「単価の内訳」「オンコール」「深夜対応」は聞きにくい話題ですが、聞かずに参画した場合のダメージが最も大きい項目です。逆質問リストの後半に配置し、面談時間の終盤で必ず投げる運用にします。

エージェント担当者の主観に依存

エージェント担当者の「良い現場ですよ」「働きやすい会社です」といった主観は、参考程度に留めます。担当者が現場を直接見ていないケースもあるため、企業情報・社員のSNS・技術ブログで裏取りする姿勢を持ちます。

商流の質問を避けて多重下請けに巻き込まれる

商流の質問を避けると、契約後に「別法人が間に入っていた」と判明することがあります。面談の後半で必ず商流を質問し、契約書の当事者名で最終確認する運用にします。

現場のカルチャーを技術ブログだけで判断

技術ブログの内容は採用向けに調整されている場合があります。「良さそう」と感じても、面談で開発体制・レビュー文化を具体質問して裏取りします。

まとめ

• 事前調査は「案件・現場・企業・商流」の4層に分けて情報源を持つ。層を混ぜないことで抜けが減る

• 案件票は見出しではなく但し書きを読む。役割・体制・技術スタックのバージョン・稼働の但し書きを1項目ずつ深掘りする

• 企業情報は公式サイト・法人番号公表サイト・求人ページの3ソースで最低限を裏取りする

• 現場は面談での逆質問リストを固定化し、聞きにくい項目も終盤で必ず投げる

• 商流は「発注元は誰か」「自分は何次請けか」を面談で必ず確定させる

• 参画48時間前に契約書・準備物・撤退基準の最終チェックを行う

案件票を読み、企業を裏取りし、面談で商流を確定させ、参画前48時間で最終確認する。この4ステップを固定化すると、案件ごとに事前調査の質を再現できます。

危険サイン自体の詳細は地雷案件の見分け方15項目、複数案件の比較・優先順位は案件の選び方、商流の仕組みそのものは多重下請け構造とはにそれぞれ整理しているため、あわせて読むと事前調査の解像度が上がります。次のステップとして、フリコンの案件一覧で気になる案件を見つけたら、本記事のチェックリストを使って調査を進めてください。