「実務スキルは足りているはずなのに、なぜか案件に選ばれない」。複数の案件に応募しても書類で落ち、面談まで進んでも他の候補者に決まってしまう。フリーランスエンジニアとして1〜3年活動していると、こうした壁にぶつかる方は少なくありません。
スキルシート（経歴書）は何度も見直したはずです。技術スタックも実務年数も整理してある。それでも反応が変わらないと、「自分のスキルが足りないのでは」と不安になってきます。
しかし、面談に呼ばれない原因はスキル不足ではなく、応募時に添える「提案文・自己PR」の設計にあることがほとんどです。多くのフリーランスエンジニアは、案件が変わっても同じ内容の自己PRを使い回しています。スキルを並べただけの文章は、どの案件にも当てはまる代わりに、どの案件にも刺さりません。結果として、似たような提案を出す他のフリーランスの中に埋もれてしまいます。
選ばれるフリーランスがやっているのは、案件ごとにクライアントの課題を推定し、「自分がその課題をどう解決できるか」を示す提案です。スキルを羅列する「スキル羅列型」から、課題に応える「課題解決提案型」へ。この転換ができると、クライアントから「言われた作業をこなす受注者」ではなく「課題を一緒に解決するパートナー」として見てもらえるようになります。
本記事では、提案書が通らない原因の整理から、スキルシートとの役割の違い、課題解決提案型への具体的な書き換え手順、案件種類別・営業経路別の書き分け、そして提案書を面談・受注につなげる準備までを、例文を交えて解説します。明日の応募から、まず1案件分の提案書を書き換えられる状態を目指してください。
フリーランスエンジニアの提案書が通らない3つの原因
提案書を改善する前に、まず「なぜ通らないのか」を言語化しておきましょう。原因が曖昧なまま例文だけ真似ても、根本は変わりません。面談に呼ばれない提案書には、おおむね次の3つの共通点があります。自分の提案文がどれに当てはまるか確認しながら読み進めてください。
原因1：スキルの羅列で終わり、案件ごとに中身が変わっていない
最も多いのが、案件が変わっても提案文の中身がほとんど同じというパターンです。「PHP・Laravelで5年、フロントはReactを3年経験。要件定義から運用まで対応可能です」といった自己紹介を、応募する案件すべてに使い回していないでしょうか。
スキルの羅列自体が悪いわけではありません。問題は、その内容が「この案件のために書かれた文章」になっていないことです。クライアントから見ると、使い回しの提案文は一読しただけで「テンプレートだな」と分かります。自社の案件を真剣に検討してくれているのか伝わらず、後回しにされてしまいます。
スキルシートに書いてある情報をそのまま提案文に再掲しても、新しい判断材料は増えません。クライアントが知りたいのは「あなたが何をできるか」ではなく「あなたがこの案件で何をしてくれるか」です。
原因2：クライアントの課題に触れていない
2つ目は、自分の経歴の説明に終始し、クライアントが抱えている課題に一言も触れていないパターンです。
案件の募集要項には、必ず「なぜこの人を探しているのか」という背景があります。「開発が遅れている」「専任エンジニアが足りない」「既存システムが古く改修に手が回らない」など、募集の裏には解決したい課題が存在します。提案文がその課題に触れていないと、クライアントは「自分たちの状況を理解してくれているか」を確認できません。
経歴を丁寧に書いても、それが課題と結びついていなければ「立派な経歴の人」で止まります。クライアントが選びたいのは「立派な経歴の人」ではなく「うちの課題を解決してくれそうな人」です。経歴と課題のあいだに橋を架けるのが提案文の役割です。
原因3：提案書が「面談に呼ぶ理由」になっていない
3つ目は、提案書を「自己紹介の完成形」と捉えてしまっているパターンです。
書類選考の段階で、クライアントは提案書だけで採用を決めるわけではありません。提案書の役割は「会って話を聞いてみたい」と思わせること、つまり面談に呼ぶ理由をつくることです。すべてを書ききろうとして情報を詰め込みすぎると、かえって要点がぼやけ、「会って確認したいこと」が残りません。
逆に、課題への理解と解決の方向性が簡潔に示され、「具体的な進め方は面談で詰めたい」という余白があると、クライアントは続きを聞きたくなります。提案書はゴールではなく、面談という次のステップへの入り口です。この前提が抜けていると、書けば書くほど面談から遠ざかってしまいます。
ここまでの3つの原因は、いずれも「使い回しのスキル羅列」という一点に行き着きます。次章以降で、この状態から抜け出すための具体的な手順を見ていきましょう。
提案書とスキルシートはどう違うのか｜役割の整理
課題解決提案型の書き方に入る前に、「スキルシートを出しているのに、なぜ提案書も必要なのか」という疑問を解消しておきます。両者の役割を切り分けると、提案書に何を書くべきかが明確になります。
スキルシートは「標準書類」、提案書は「カスタマイズ書類」
スキルシート（経歴書）は、自分の経歴・技術スタック・担当工程を網羅的にまとめた標準書類です。どの案件に応募するときも基本的に同じものを使い、クライアントは「この人はどんな技術を、どのくらいの期間扱ってきたか」を一覧で把握します。情報を漏れなく整理することが目的なので、案件ごとに中身を変える必要はありません。
一方、提案書（提案文・自己PR）は、応募する案件1件ごとに内容を変えるカスタマイズ書類です。その案件のクライアントが抱える課題を推定し、「自分がその課題にどう貢献できるか」「過去に似た課題をどう解決したか」を、その案件に向けて書き下ろします。
両者は対象とする読者の関心が異なります。スキルシートは「能力の証明」、提案書は「この案件への適合の説明」です。スキルシートの情報をそのまま提案書に書き写しても、適合の説明にはなりません。提案書では、スキルシートに載っている経歴の中から「この案件に関係するもの」だけを選び、課題と結びつけて語り直す必要があります。
なお、スキルシートそのものの書式や記載項目の整え方については、フリーランスエンジニアのスキルシート・経歴書の書き方で詳しく解説しています。本記事は、その標準書類に対して案件ごとに上乗せする提案書に焦点を当てます。
2つを組み合わせて応募の通過率を上げる
スキルシートと提案書は、どちらか一方で足りるものではなく、組み合わせて初めて通過率が上がります。
スキルシートだけでは、「能力はあるが、この案件をどう捉えているか」が伝わりません。提案書だけでは、「主張を裏づける経歴の全体像」が見えません。スキルシートで能力の土台を示し、提案書でその土台を案件の課題に接続する。この二段構えがそろうと、クライアントは「能力がある」かつ「うちの課題を理解している」と判断でき、面談に呼ぶ理由がはっきりします。
応募のたびにスキルシートを作り直す必要はありません。労力をかけるべきは提案書のほうです。標準書類は使い回しでよく、カスタマイズ書類こそ案件ごとに書き分ける。この役割分担を意識すると、限られた時間を効果的に配分できます。
スキル羅列型から課題解決提案型へ｜提案書の構成設計
ここからが本記事の中核です。スキルを並べるだけの提案書を、課題解決提案型へ転換する具体的な手順を見ていきます。やることは大きく4つ、「課題を推定する」「構成に沿って書く」「自己PRに数値と再現性を入れる」「ビフォーアフターで確認する」です。
クライアントの課題を募集要項・企業フェーズから推定する
課題解決提案型の出発点は、クライアントの課題を推定することです。多くの場合、課題は募集要項に明示されていません。しかし、書かれている情報から十分に推測できます。
着目したいのは次の3点です。
- 募集要項の文言：「至急」「短期で立ち上げたい」とあれば開発リソースの逼迫、「既存システムの改修」とあればレガシー対応の負荷、「設計から任せたい」とあれば上流を担える人材の不足が読み取れます。
- 企業のフェーズ：シード・アーリーのスタートアップなら「少人数で速く形にしたい」、拡大期の企業なら「増えた開発量に体制が追いついていない」、成熟企業なら「古いシステムを止めずに改善したい」といった傾向があります。企業サイトや採用ページで事業の状況を確認しておきます。
- 指定された技術スタック：要求技術が枯れた構成なら安定運用や保守の文脈、新しめの構成なら新規立ち上げや技術刷新の文脈が想定できます。
これらから「このクライアントは、おそらく◯◯に困っている」という仮説を1〜2文で立てます。仮説なので外れることもありますが、外れても問題ありません。重要なのは、提案書の冒頭で「御社は△△という状況で、□□の解決を求めているのではないかと考えました」と課題仮説を言語化することです。これだけで、使い回しの提案文との差は明確になります。仮に推定がずれていても、「課題を理解しようとしている人」という印象は残り、面談で軌道修正できます。
提案書の基本構成：課題の理解→解決アプローチ→再現性の提示→貢献イメージ
課題仮説が立ったら、次の4ブロックの構成で提案書を組み立てます。この順序には意味があります。
- 課題の理解：推定したクライアントの課題を、提案書の冒頭で言語化します。「御社は◯◯のフェーズにあり、△△に課題を抱えているのではないか」と切り出します。ここで読み手は「自分たちのことを分かっている」と感じ、続きを読む姿勢になります。
- 解決アプローチ：その課題に対して、自分ならどう取り組むかを示します。詳細な実装計画ではなく、「どこから着手し、どんな進め方をするか」という方向性で十分です。書類段階で完璧な解決策を求められているわけではありません。
- 再現性の提示：解決アプローチの説得力を支えるのが、過去の類似経験です。「以前、似た課題を抱えた案件で、こう取り組み、こういう結果につながった」と具体的に語ります。これがあると、提案が「できそうな話」ではなく「実際にやってきたこと」になります。
- 貢献イメージ：最後に、参画後にクライアントにどんな状態を提供できるかを描きます。「開発スピードの安定」「属人化していた領域のドキュメント化」など、クライアントが得られる変化を一言で示します。
この4ブロックは、スキル羅列型の「自分は何ができるか」を、「クライアントの課題」を軸に組み替えたものです。主語をクライアントに置き、最後に「だから自分が役立てる」と結ぶ。この流れが課題解決提案型の骨格です。
自己PRに「数値実績」と「再現性」を入れる
4ブロックのうち、提案書の説得力を最も左右するのが「再現性の提示」です。ここを強くするには、数値実績と再現性の2つを意識します。
数値実績とは、過去の経験を具体的な数字で語ることです。「大規模なシステムの開発を担当」ではなく、「月間アクセス数◯万のサービスで、3名のチームのバックエンドを担当し、APIの平均応答時間を約40%短縮」のように書きます。工数・チーム人数・改善率・対応規模など、扱える数字があれば添えます。数字は経験の解像度を上げ、読み手に状況を具体的にイメージさせます。
再現性とは、「その成果がたまたまではなく、再び出せるものだ」と示すことです。具体的には、結果だけでなく「どういう判断・進め方でその結果に至ったか」をひとこと添えます。「応答時間を短縮した」だけでなく「ボトルネックを計測で特定し、優先度の高い箇所から改修した」と書けば、同じ進め方を別の案件でも適用できると伝わります。クライアントは「うちでも同じことをしてくれそうだ」と判断できます。
数値と再現性をそろえることで、自己PRは「過去の自慢」ではなく「将来の貢献の根拠」になります。なお、再現性をさらに裏づける手段として、実際の成果物を見せるポートフォリオの併用も有効です。提案書で語った経験を、コードや成果物で確認できる状態にしておくと、クライアントの安心感は高まります。
NG例とOK例で見る書き換えのビフォーアフター
ここまでの内容を、具体的な書き換え例で確認します。架空の案件として「拡大期のSaaS企業が、開発が逼迫しているためバックエンド改善を任せられるエンジニアを募集」というケースを想定します。
NG例（スキル羅列型）
PHP・Laravelでの開発経験が5年あります。要件定義から設計、実装、運用まで一通り対応可能です。フロントエンドはReactを使った経験もあります。レスポンスは早めを心がけており、リモートでの稼働も問題ありません。ご検討よろしくお願いいたします。
この提案文は、スキルと稼働条件を並べているだけで、どの案件に出しても通用します。クライアントの課題に触れておらず、「この案件のために書かれた文章」になっていません。
OK例（課題解決提案型）
募集要項を拝見し、御社はサービス拡大に開発体制が追いつかず、バックエンドの改善が後回しになっている状況とお見受けしました。まずは既存コードと負荷状況を把握したうえで、影響の大きいボトルネックから優先的に改善する進め方が有効と考えています。
前職に近い拡大期のSaaSで、3名チームのバックエンドを担当し、計測でボトルネックを特定して優先度順に改修した結果、APIの平均応答時間を約40%短縮した経験があります。同じ「計測してから優先度をつける」進め方は、御社の状況でも再現できると考えています。
参画後は、改善のスピードを安定させつつ、判断の経緯をドキュメントに残し、属人化を防ぐところまで担当できればと考えています。具体的な進め方は、ぜひ面談でご状況を伺いながら相談させてください。
OK例では、課題の理解から始まり、解決アプローチ、数値実績を伴う再現性、貢献イメージへと進み、最後に面談へつないでいます。同じ経歴の持ち主でも、「課題を軸に語り直す」だけで提案書の印象は大きく変わります。書き換えの際は、まずNG例のように手持ちのスキルを書き出し、そのうえで「この案件の課題は何か」を起点に並べ替えるとスムーズです。
案件の種類別｜提案書テンプレートと書き分けのポイント
課題解決提案型の構成は、案件の種類によって「何を訴求の主軸に置くか」が変わります。ここでは代表的な3タイプ、新規開発・保守改修・コンサル/技術支援について、書き分けのポイントを整理します。応募する案件がどのタイプかを見極め、主軸を調整してください。
新規開発案件：構想段階への貢献と立ち上げ実績を訴求する
新規開発案件は、サービスやプロダクトをこれから形にしていくフェーズです。クライアントが不安に感じているのは、「要件が固まりきっていない状態でも、一緒に考えながら進められる人かどうか」です。
訴求の主軸は、構想段階への貢献力と、ゼロから立ち上げた実績です。「決まった仕様を実装するだけでなく、要件の整理や技術選定の相談から関われる」という姿勢を示します。
例として、こう書けます。「御社は新規プロダクトの立ち上げ段階で、仕様を固めながら開発を進められる人材を求めていると理解しました。前職では新規サービスを企画段階から担当し、技術選定と最小構成での実装を進め、3か月でリリースまで到達した経験があります。仕様が動く前提で、優先度を相談しながら進める進め方が得意です」。立ち上げ特有の不確実さに寄り添える点を前面に出すのがポイントです。
保守・改修案件：既存システムのキャッチアップ力と安定運用を訴求する
保守・改修案件は、すでに稼働しているシステムに手を入れるフェーズです。クライアントが不安に感じているのは、「既存のコードを壊さずに、早くキャッチアップして安定運用に貢献できるか」です。
訴求の主軸は、既存システムのキャッチアップ力と、安定運用への貢献です。「ドキュメントが十分でない環境でも、コードを読み解いて全体像を把握できる」「いきなり大きく変えるのではなく、影響範囲を見極めながら改善する」という慎重さを示します。
例として、こう書けます。「御社は長く運用されてきたシステムの改修を、安定稼働を保ちながら任せられる人材を求めていると理解しました。前職ではドキュメントが限られた既存システムを引き継ぎ、まずコードと挙動の把握に時間をかけたうえで、影響の小さい箇所から段階的に改修し、障害を起こさずに機能追加を進めた経験があります」。新規開発とは逆に、「派手さよりも堅実さ」を伝えるのがポイントです。
コンサル・技術支援案件：意思決定への関与と再現可能なノウハウを訴求する
コンサル・技術支援案件は、手を動かす実装だけでなく、技術的な意思決定やチームの底上げが求められるフェーズです。クライアントが不安に感じているのは、「技術判断を任せられるか」「自分たちのチームにノウハウが残るか」です。
訴求の主軸は、意思決定への関与と、再現可能なノウハウの提供です。「技術選択肢を整理して判断材料を示せる」「自分が抜けた後もチームが回るよう、知見を移転できる」という点を示します。
例として、こう書けます。「御社は開発体制の改善と、社内に技術ノウハウを蓄積することを求めていると理解しました。前職では複数チームの技術支援を担当し、選択肢を比較した判断材料の整理や、レビュー基準の文書化を通じて、支援終了後もチームが自走できる状態づくりに取り組んだ経験があります」。一過性の作業者ではなく、組織に残るものを提供できる点を前面に出すのがポイントです。
直接営業とエージェント経由｜提案書の違いと使い分け
案件の種類だけでなく、案件をどの経路で獲得するかによっても提案書の最適な形は変わります。提案書を読む相手が誰かを意識すると、同じ内容でも見せ方を調整できます。
直接営業の提案書：課題の言語化と費用対効果まで踏み込む
直接営業で獲得する案件では、提案書を読むのは発注者本人です。意思決定者が直接目を通すため、提案書はそのまま発注判断の材料になります。
このケースでは、課題の言語化と費用対効果まで踏み込みます。発注者は「この人に任せて、コストに見合う成果が得られるか」を見ています。課題の理解を丁寧に示したうえで、解決アプローチに加えて「どのくらいの期間で、どこまで進められそうか」「参画によって発注者の負担がどう減るか」といった見通しを添えます。
直接営業では、発注者がエンジニアの専門用語に必ずしも詳しくない場合もあります。技術の話に終始せず、「それによって発注者の事業や業務がどう良くなるか」という言葉に翻訳して伝えると、提案の価値が伝わりやすくなります。
なお、直接営業の案件数を増やすためのSNS集客の設計については、フリーランスエンジニアのX（Twitter）集客｜フォロワー0人から案件依頼される発信戦略で詳しく解説しています。
エージェント経由の提案書：エージェントが営業しやすい素材を渡す意識
エージェント経由の案件では、提案書を最初に読むのはエージェントの担当者です。担当者は、複数のフリーランスの中から案件先に推薦する人を選び、案件先へ「この人がおすすめです」と橋渡しをします。
このケースで意識したいのは、エージェントが案件先に営業しやすい素材を渡すことです。担当者があなたを推薦するとき、提案書の内容を要約して案件先に伝えます。そのため、「強みが一文で要約できる」「なぜこの案件に合うのかが明快」な提案書だと、担当者は推薦しやすくなります。
具体的には、提案書の冒頭に「この案件に対する自分の適合理由」を簡潔にまとめ、担当者がそのまま使える状態にしておきます。担当者を「あなたの最初の営業担当」と捉え、その人が動きやすい材料を提供する意識を持つと、案件先に届く前の段階で差がつきます。なお、エージェントの担当者は提案・交渉・面談のサポート役にもなり得る存在です。担当者との連携や条件交渉の進め方は、それ自体が深掘りに値するテーマなので、別の機会に詳しく扱います。
どちらの経路でも崩さない訴求の軸
経路によって見せ方は変わりますが、崩してはいけない軸があります。それは「クライアントの課題を理解し、過去の経験に基づいて再現性のある解決を示す」という課題解決提案型の骨格です。
直接営業なら費用対効果まで、エージェント経由なら推薦しやすい要約を、というのはあくまで見せ方の調整です。土台にある「課題理解→解決アプローチ→再現性→貢献イメージ」の構成は、どちらの経路でも変えません。経路ごとに提案書をゼロから作り直すのではなく、共通の骨格を用意したうえで、読み手に応じて強調点を足し引きする。この考え方なら、複数の経路を併用していても提案書づくりの負担を抑えられます。
面談につなげる準備｜提案書→面談→受注の一貫した訴求設計
提案書は、面談に呼ばれて初めて意味を持ちます。そして面談は、受注につながって初めて成果になります。提案書・面談・受注を「点」で考えるのではなく、一貫した訴求でつなぐ「線」で設計することが、最後の仕上げです。
提案書で書いた訴求を面談で深掘りできる状態にする
面談で評価を下げてしまう典型は、提案書に書いた内容を、面談で具体的に語れないことです。提案書に「APIの応答時間を約40%短縮した」と書いたなら、面談では「どんなボトルネックを、どう特定し、何を改修したのか」を具体的なエピソードで説明できる必要があります。
提案書を書いたら、各項目について「これを面談で聞かれたら、何を話すか」を一度想定しておきます。書面では一文で済ませた経験も、面談では背景・判断・結果まで掘り下げて語れる準備をしておく。提案書と面談で訴求の軸がそろっていると、クライアントは「書いてあることと話す内容が一致している、信頼できる」と感じます。逆に、提案書は立派でも面談で深掘りできないと、「提案書は誰かの助けを借りたのでは」と疑念を持たれかねません。
面談前の30分でやる案件リサーチと想定質問の準備
面談の直前、30分ほどあれば最低限の準備はできます。やることは2つです。
1つ目は、案件と企業の再リサーチです。提案書を書いた時点から時間が経っていることもあるため、企業サイト・採用ページ・最近のニュースを改めて確認し、「課題仮説が今も妥当か」を見直します。新しい情報があれば、面談で「御社の◯◯という発表を拝見し、△△の課題もあるのではと考えました」と触れると、関心の高さが伝わります。
2つ目は、想定質問への回答準備です。「なぜこの案件に応募したのか」「過去の案件でうまくいかなかったことは何か」「参画後どう進めるか」といった定番の質問に対し、提案書の内容と矛盾しない回答を用意します。特に「うまくいかなかったこと」は、失敗そのものより「そこから何を学び、進め方をどう変えたか」を語れると、再現性のある人だという印象につながります。
受注後を見据えた「継続したいパートナー」としての見せ方
面談のゴールは、目の前の案件を1件受注することだけではありません。クライアントに「この人とは継続して付き合いたい」と思ってもらえれば、契約更新や別案件の紹介につながり、案件獲得の安定化に直結します。
そのために意識したいのが、「言われた作業をこなす受注者」ではなく「課題を一緒に解決するパートナー」としての見せ方です。面談では、目の前の案件への対応だけでなく、「この課題が解決した先に、こういう改善も考えられます」といった一歩先の視点を添えます。クライアントの事業や開発体制に関心を持ち、中長期で役立とうとする姿勢が伝わると、単発の発注先候補から、継続的に頼りたい相手へと位置づけが変わります。
提案書で課題解決型の訴求を打ち出し、面談でそれを深掘りで裏づけ、受注後を見据えたパートナーの姿勢まで見せる。この一貫した流れができると、1件ごとの受注率が上がるだけでなく、一度つかんだ関係から次の案件が生まれるようになります。継続的に案件を獲得し、収入を安定させる仕組みは、こうした一貫した訴求設計の積み重ねの上に成り立ちます。
まとめ｜案件ごとにカスタマイズする提案書が選ばれる差をつくる
フリーランスエンジニアの提案書が通らない原因は、スキル不足ではなく、案件が変わっても中身が変わらない「使い回しのスキル羅列」にあります。本記事で解説したポイントを振り返ります。
- スキル羅列型から課題解決提案型へ：クライアントの課題を募集要項・企業フェーズ・技術スタックから推定し、「課題の理解→解決アプローチ→再現性の提示→貢献イメージ」の構成で書く。
- スキルシートとの役割分担：スキルシートは使い回す標準書類、提案書は案件ごとに書き換えるカスタマイズ書類。両者を組み合わせて通過率を上げる。
- 案件種類別の書き分け：新規開発は構想段階への貢献、保守改修はキャッチアップ力と安定運用、コンサル/技術支援は意思決定への関与とノウハウ移転を主軸にする。
- 営業経路別の使い分け：直接営業は費用対効果まで踏み込み、エージェント経由は推薦しやすい素材を渡す。骨格は崩さず見せ方だけ調整する。
- 提案書→面談→受注の一貫設計：提案書の訴求を面談で深掘りできる状態にし、受注後を見据えたパートナーの姿勢まで見せる。
すべてを一度に変える必要はありません。まずは、いま応募を検討している案件を1件選び、その提案書を課題解決提案型で書き換えてみてください。クライアントの課題を1〜2文で推定し、4ブロックの構成に沿って書き直すだけで、これまでの使い回しの提案文との違いが見えてくるはずです。
案件ごとにカスタマイズした提案書を積み重ねていくことが、他のフリーランスとの差をつくり、「課題を一緒に解決するパートナー」として継続的に選ばれる状態につながります。明日の応募から、その1件目を書いてみましょう。
