提案文の冒頭に実績を書くと在宅コーディング補助では読まれない

2026年3月10日

前田壮一

この記事のポイント

✓在宅のコーディング補助案件に提案文を送っても返信が来ない理由は実績不足ではありません
✓冒頭の書き出しで読み飛ばされる構造
✓通る提案文の組み立て順

在宅のコーディング補助案件に提案文を送り続けているのに、返信が来ない。皆さんがそう感じているなら、まず、安心してください。原因はほぼ確実に実績の量ではありません。提案文の冒頭に何を置いているか、そこ1点で読まれるかどうかが決まっています。

この記事では、在宅のコーディング補助の提案文がどこで読み飛ばされているのか、発注側が最初の3行で何を判断しているのか、実績が少ない状態でどうやって具体性を作るのか、そして送った後に何をすべきかを順番に書きます。私も40代で会社を辞めてフリーランスになった人間なので、実績が薄い状態から始める怖さは分かっているつもりです。そのうえで、精神論ではなく手順として書きます。

在宅コーディング補助の提案文が読まれていない理由

最初に事実関係を整理します。皆さんの提案文は、落とされているのではなく、読まれていない可能性が高い。ここを取り違えると対策の方向がずれます。

在宅のコーディング補助案件、たとえばWordPressのテーマ修正、既存サイトのHTMLとCSSの改修、デザインカンプからの静的コーディング、Web制作会社の下請けとしての部分実装。こうした案件には、1件あたり20件から80件の提案が集まることが珍しくありません。発注する側は本業の合間にこれを捌きます。全文を読むわけがない。実際には一覧画面で冒頭の1行から2行を見て、開くか閉じるかを決めています。

つまり勝負がついているのは、提案文の中身ではなく冒頭です。ここに何を書いているか思い出してください。

「はじめまして。フリーランスでWeb制作をしております◯◯と申します。これまでにコーポレートサイトのコーディングを10件ほど担当してまいりました」

これが最も多い書き出しで、そして最も読まれない書き出しです。理由は3つあります。

1つ目は、この情報が発注者の判断に使えないからです。「10件」が多いのか少ないのかは、発注者には分かりません。5件の人も30件の人も同じ形式で書いてくるので、数字を並べても差がつかない。

2つ目は、この文が「私の話」だからです。発注者が知りたいのは自分の案件がどうなるかであって、応募者の経歴ではありません。冒頭で自分の話を始めた時点で、読む優先度は下がります。

3つ目は、全員が同じ形式で書いているからです。一覧に並んだときに区別がつかない。テンプレートを使っている人ほど、この書き出しになります。

提案文が通らない原因を実績不足だと考えている人が多いという指摘は、指導の現場からも上がっています。

提案文が通らないと、つい「実績がないから」と結論づけたくなります。でも実際は、組み立て方を少し変えるだけで、通りやすさは変わってきます。出典: menta.work

実績が同じでも通る人と通らない人がいる。この差が組み立ての差だという見立ては、私自身が発注側に回ったときの感覚とも一致します。

発注者が最初の3行で判断していること

発注者が冒頭で確認しているのは、次の3点だけです。

1つ、この案件の内容を理解しているか。2つ、いつまでにできるか。3つ、いくらか。

順番も重要です。この3点のうち、最初に効くのは「案件の内容を理解しているか」です。発注者が一番恐れているのは、話が通じない人に発注してしまうことだからです。単価が安くても、修正を何度も往復する相手には頼みたくない。

コーディング補助の案件でこの「理解しているか」を示すには、案件文に書かれた具体的な要素に触れるのが最短です。「レスポンシブ対応が必要とのことですので」「既存のテーマを直接編集せず子テーマで対応する前提で」「WordPressのバージョンが6系であればブロックエディタ側の調整も」。こうした一言が冒頭にあると、発注者は「読んでいる人だ」と判断して本文を開きます。

テンプレート感が出る文章の共通点

テンプレートを使うこと自体は悪くありません。効率のために必要です。問題は、テンプレート感が出てしまう文章に共通の特徴があることです。

まず、案件固有の名詞がゼロの文章です。案件文に出てくる技術名、業種、納期、ページ数。これらの単語が一度も出てこない提案文は、誰にでも送れる文章なので即座に見分けがつきます。

次に、褒め言葉から入る文章です。「御社のサービスに大変魅力を感じました」。コーディング補助の案件で発注しているのは制作会社や個人事業主であることが多く、サービスへの共感を求めていません。むしろ営業メールの定型文に見えるので逆効果です。

3つ目が、できることの列挙です。「HTML、CSS、JavaScript、jQuery、PHP、WordPress、Sass、Gulp、Git」。この羅列は、案件に必要なスキルが何かを判断する作業を発注者に押し付けています。列挙するなら、案件で必要なものだけを選んで、それぞれをどう使うかを1行ずつ書いたほうが伝わります。

4つ目が、極端に長い文章です。実績が少ない人ほど、量で埋めようとして長くなります。冒頭で読まれていないのに長くしても意味がありません。全体は600文字から900文字程度で十分です。

通る提案文の組み立て順

順番を変えるだけで通りやすさが変わります。私が実務で使っている順番を示します。

冒頭は「案件の要点の言い換え」から始める

1行目に自己紹介を置かない。代わりに、案件の要点を自分の言葉で言い換えます。

「既存のコーポレートサイト8ページを、スマートフォン表示に対応させる作業と理解しました。デザインの変更は伴わず、既存のレイアウトを崩さずにブレークポイントを追加する方針で進められる案件かと思います」

この2文だけで、発注者は「案件を読んでいる」と「方針を持っている」の2つを同時に受け取ります。ここで初めて本文が開かれます。

言い換えるときの注意は、案件文をそのままコピーしないことです。コピーは読んだ証明になりません。自分の理解として1段階かみ砕いた表現にしてください。かみ砕けないということは理解していないということなので、その案件は提案を見送ったほうがよい。

2番目に「作業手順」を3ステップで書く

次に、実際にどう進めるかを書きます。ここが最も差がつく部分です。

「作業手順としては、まず現在のCSSの構成を確認し、既存のクラス設計に影響を出さない形でメディアクエリを追加します。次に主要な3画面幅（375px、768px、1024px）で表示崩れを潰し、最後に実機で確認して修正箇所の一覧をお渡しします」

実績が少なくても、この手順は書けます。手順を書けるということは、作業を頭の中でシミュレーションできているということで、これは経験の量とは別の能力です。発注者はここを見て「進行が想像できる相手か」を判断しています。

3番目に「懸念点と確認事項」を1つ書く

ここを入れる人はほとんどいません。だから効きます。

「1点確認させてください。既存サイトのCSSがフレームワーク由来のものである場合、上書きではなく設定側での対応が必要になることがあります。現在のテーマまたは使用フレームワークをお教えいただけると、より正確な工数をお出しできます」

懸念点を書くと消極的に見えると思うかもしれませんが、逆です。発注者から見ると、リスクを先に潰そうとする相手は安全に見えます。しかも質問を投げているので、返信する理由が生まれます。提案文への返信率は、質問が1つ入っているかどうかで明確に変わります。

ただし質問は1つだけにしてください。3つ4つ並べると、答えるのが面倒になって放置されます。

4番目に「納期と金額」を数字で書く

ここまで来て初めて条件を出します。

「納期は着手から5営業日、金額は4万円（税抜）でお受けできます。確認事項の回答内容によって工数が増える場合は、着手前に改めてご相談させてください」

金額を書くときは、後から変わる条件を明記しておきます。これを書いておかないと、想定外の作業が出たときに追加請求しづらくなります。40代で独立してから何度か痛い目を見ましたが、着手前に一言入れておくだけで、後の交渉がまったく違います。

最後に実績を「案件に関係するものだけ」1つか2つ

実績はここです。冒頭ではありません。

しかも全部書かない。案件に関係するものだけを1つか2つ。「WordPressの既存テーマに対する部分改修を担当した経験があり、子テーマでの上書き対応も行っています」。数を誇るのではなく、今回の作業と同種であることだけを示します。

実績が本当にゼロの場合は、練習で作ったものについて「自分で作った架空サイトで同じ作業を行っています」と正直に書いてください。嘘を書くより通ります。発注者が恐れているのはできない人ではなく、できないのにできると言う人です。

実績ゼロでも具体性は作れる

「具体性を出せと言われても、書く材料がない」という声はよく聞きます。材料は実績以外から作れます。

同じ実績ゼロでも通る提案文と通らない提案文がある、という指摘があります。

同じ実績ゼロの状態でも、通る提案文と通らない提案文がある。その差は、実は書き方の順番と中身だったりするんですよね。出典: menta.work

材料の作り方を4つ挙げます。

1つ目は、案件の対象サイトを実際に見ることです。多くの在宅コーディング補助案件では、対象のURLが公開されているか、業種が特定できる程度の情報は出ています。実際に開いて、開発者ツールで構造を確認する。「ヘッダー部分がposition: fixedで組まれているため、モバイル時の高さ調整も併せて必要になりそうです」と書けたら、これは実績よりも強い具体性です。

2つ目は、作業環境の明示です。「Git経由での納品に対応できます」「Backlogでの進行管理に慣れています」「差分をプルリクエストで提出する形でも問題ありません」。制作会社が発注元の場合、この一言で候補に残ります。逆に、環境の話が一切ない提案は、実績があってもチームに入れにくいと判断されます。

3つ目は、連絡の設計です。「平日は9時から18時の間であれば2時間以内に返信します。それ以外の時間帯は翌営業日の朝にまとめて返信します」。在宅ワークで最も嫌がられるのは連絡が読めないことなので、ここを最初に固定しておくと安心されます。

4つ目は、練習で作ったものの見せ方です。ポートフォリオがない人でも、案件と同種の作業をやってみて、その過程を短くまとめることはできます。「同じ規模のサイトで練習として実装した際は、実作業6時間程度でした」。所要時間を書けるのは実際にやった人だけなので、これも具体性になります。

私自身、Webライティングを副業で始めたときに、最初の提案文はひたすら自分の経歴を書いていました。メーカーで品質管理をやっていたので、その話を長々と書いた。まったく返事が来ませんでした。返事が来るようになったのは、「この記事は誰に読ませるものかを最初に確認したい」という一文を冒頭に入れてからです。経歴ではなく、案件への向き合い方を示したときに初めて反応が変わりました。この構造は、コーディング補助でもまったく同じです。

提案文を送る前にやるリサーチ

提案文の質は、書き方より前のリサーチで決まります。所要は10分程度です。

まず案件文を最後まで読みます。当たり前に聞こえますが、募集要項の後半に「必ず◯◯と記載してください」という指定が入っていることがあります。これは応募者が本文を読んでいるかを測るための仕掛けで、抜けた時点で落とされます。

次に発注者の過去の募集を見ます。同じ発注者が繰り返し募集していれば、継続案件の可能性があります。継続前提なら、提案文の中で「継続的にお手伝いできる体制です」と一言添える価値があります。逆に単発ばかりの発注者なら、その一言は不要です。

3番目に、金額の妥当性を確認します。予算1万円でページ数が10ページのコーディングという案件は、時給換算で成立しません。安い案件に丁寧な提案文を送るのは時間の損失なので、リサーチの段階で見送りを決めるべきです。開発系の単価水準を知っておくと判断が早くなります。ソフトウェア作成者の年収・単価相場には職種ごとの相場がまとまっているので、自分が受けようとしている案件が相場のどのあたりかを確認しておくと、安値の案件に時間を吸われずに済みます。

4番目に、募集開始からの経過時間を見ます。提案文は早いほど有利です。募集から24時間以内に出した提案と、5日後に出した提案では、読まれる確率が違います。発注者は最初に来た数件で候補を絞ってしまうことが多いからです。

5番目に、自分がその案件を本当に受けられるかを確認します。受注してから「実は経験がなかった」となると、納品遅延や品質不良につながり、評価が下がります。1件の失敗を取り戻すには数件の成功が必要なので、割に合いません。

送った後にやること

提案文は送って終わりではありません。ここでやることを持っている人は少ないので、差がつきます。

返信が来た場合、返信の速さがそのまま次の判断材料になります。数時間以内に返せると、進行のイメージが良くなります。逆に翌日以降になると、他の候補で決まっていることがあります。

返信が来ない場合の追いかけ方には注意が必要です。募集期間中に何度も催促するのは逆効果ですが、募集が締め切られた後に一度だけ「今回はご縁がなかったようですが、同種の案件がありましたらお声がけください」と送っておくのは有効です。制作会社の発注担当は、次に人が足りなくなったときに手元のリストを見ます。ここに名前が残っているかどうかで、次の機会が変わります。

不採用が続いたら、提案文のどこで落ちているかを切り分けてください。方法は単純で、提案文の冒頭だけを変えたパターンを10件ずつ送って比較します。冒頭を変えて返信率が変わるなら読まれ方の問題、変わらないなら条件（金額、納期、スキル要件）の問題です。条件の問題であれば、提案文をいくら磨いても通りません。案件の選び方を変える必要があります。

この切り分けをやらずに提案文だけを書き直し続けると、時間だけが消えます。落ちた理由を分類する習慣が、在宅で案件を取り続ける人とそうでない人を分けています。

提案文が通り始めた後に効いてくること

提案文の目的は受注ですが、受注した後の動き方が次の提案文の材料になります。

最初の案件で意識してほしいのは、納品時に「作業の記録」を残すことです。何にどれだけ時間がかかったか、どこで詰まったか、どう解決したか。これを自分用にメモしておくと、次の提案文で書ける具体性が一気に増えます。「同種の作業で、既存CSSの詳細度が高く上書きが効かないケースに対応した経験があります」と書けるのは、記録を取っていた人だけです。

もう1つが、報告の型を作ることです。作業の途中経過を、決めた頻度で短く送る。「本日、トップページと下層3ページまで完了しました。残りは明日中に上げます」。これだけで発注者の不安が消えます。在宅の仕事は姿が見えないので、進行が見えることの価値が対面より高い。文書での報告に慣れていない人は、型から入るのが早道です。ビジネス文書検定のような体系は、報告や依頼の文書構成を型として整理するのに使えます。

技術面の裏付けを増やしたい場合、インフラやネットワークの基礎を押さえておくと対応できる案件の幅が広がります。サーバー移行やドメイン周りの相談が来たときに答えられるかどうかで、単価交渉の位置が変わります。CCNA（シスコ技術者認定）はネットワーク領域の基礎を確認できる認定として知られています。コーディング補助から周辺領域へ広げていくときの選択肢の1つです。

案件の種類ごとに提案文の重心を変える

在宅のコーディング補助といっても、発注元によって見られている点がまったく違います。同じ提案文を全部に送っている限り、通過率は上がりません。発注元は大きく3種類に分かれます。

1つ目が制作会社やWeb系の受託会社です。ここが最も多く、そして最も継続につながりやすい。この相手が見ているのは、チームの進行に乗れるかどうかです。品質はある程度以上あれば足りていて、それより「指示した通りに上げてくるか」「連絡が滞らないか」「約束した日に出てくるか」が重視されます。提案文の重心は、作業環境と連絡設計に置いてください。バージョン管理の運用、タスク管理ツールの経験、修正指示の受け取り方。この3点に触れている提案は、実績が薄くても候補に残ります。

2つ目が事業会社の担当者です。社内にWeb担当が1人しかおらず、手が足りないから外に出しているケース。この相手が見ているのは、専門用語を使わずに説明してくれるかどうかです。担当者自身がコーディングを理解していないことが多いので、技術的に正確な提案文ほど不安にさせます。「この作業をすると、サイトの見た目はどう変わるか」を1文で書き添えるだけで反応が変わります。提案文の重心は、成果物の説明と、作業中にサイトが止まるかどうかの説明に置きます。

3つ目が個人事業主やフリーランスからの再委託です。金額は低めですが、話が早く、継続しやすい。この相手が見ているのは、自分の代わりに任せられる範囲がどこまでかです。「どこまでを自分でやり、どこからを確認してほしいか」を提案文の中で先に線引きしておくと、後の揉め事が減ります。

この3種類を見分ける手がかりは、案件文の書き方にあります。仕様が細かく書かれていれば制作会社、目的や困りごとが中心なら事業会社、口語的で短ければ個人からの再委託であることが多い。案件文を読んだ時点で相手の種類を判定し、重心を切り替えてください。テンプレートを1つ持つのではなく、3つ持つのが正解です。

単価が低い案件に丁寧な提案文を送らない

提案文の質を上げると、皮肉なことに単価の低い案件から先に通ります。数が多いからです。ここで受注を積み上げると、時間だけ埋まって収入が伸びない状態になります。

判断の基準は、想定作業時間で割った金額です。修正対応と打ち合わせの時間を必ず含めてください。コーディングの実作業が6時間でも、指示の読み込みと修正往復に4時間かかるなら、実質は10時間です。この計算をせずに応募すると、着手してから後悔します。

安い案件を完全に避ける必要はありませんが、避けるべきパターンははっきりしています。仕様が曖昧で、修正回数の上限が書かれていない案件です。「納得いくまで修正します」と書いてしまうと、終わらない案件になります。提案文の段階で「修正は2回までを想定しており、それ以降は別途ご相談させてください」と書いておくのが、自分を守る唯一の方法です。この一文で落とされる発注者は、そもそも受けないほうがよい相手です。

通らない提案文と通る提案文の違いを並べる

同じ案件に対する2つの書き出しを比べます。案件は「既存のWordPressサイトのお問い合わせフォームを改修したい」という内容だとします。

通らない書き出しはこうなります。「はじめまして。Web制作を専門にしているフリーランスです。HTML、CSS、JavaScript、PHP、WordPressの実務経験があり、これまで多数のサイト制作に携わってまいりました。今回の案件、ぜひ担当させていただきたくご連絡いたしました」。案件固有の情報がゼロで、どの案件にも送れる文章です。

通る書き出しはこうなります。「お問い合わせフォームの改修とのことで、現在お使いのプラグインが何かによって進め方が変わる案件と理解しました。既存のフォームを残したまま項目を追加する方向であれば、テンプレート側の編集で対応でき、送信先やメールの文面もあわせて調整できます」。技術の羅列はありませんが、案件を理解していることと、進め方の見当がついていることが伝わります。

差は文章力ではありません。案件を読んでから書いたか、書き溜めたテンプレートを貼ったかの差です。1件あたり10分のリサーチをするかどうかで、ここまで変わります。

そして重要なのは、この10分をかける案件を絞ることです。全部の案件に丁寧な提案を送るのは不可能なので、リサーチの段階で受けたい案件を3件まで絞り、その3件だけに時間をかける。数を撃つ戦略は、テンプレート感が出るため逆効果になります。

提案文を保存して再利用する仕組みを作る

毎回ゼロから書くのは続きません。かといってテンプレートを貼るのは通りません。この2つの間を取る方法があります。

提案文を、固定できる部分と案件ごとに書き換える部分に分けて保存します。固定できるのは、作業環境の説明、連絡可能な時間帯、修正回数の考え方、納品形式の3つから4つ。ここは案件が変わってもほぼ同じ内容で使えます。書き換えるのは、冒頭の案件理解の言い換え、作業手順、確認事項の3つ。この3つだけを毎回書けば、1件あたりの作成時間は15分程度に収まります。

保存の仕方も工夫の余地があります。案件の種類ごとにフォルダを分け、それぞれに「通った提案文」を残しておく。通った提案文には、何が効いたかを1行のメモとして添えます。この記録が溜まると、自分の得意な案件の型が見えてきます。私の場合、技術寄りの説明を短くして進行の説明を厚くした提案のほうが通ることが、記録を取って初めて分かりました。感覚では逆だと思っていたので、記録がなければ気づけませんでした。

独自データの考察

在宅ワークの案件の動きを見ていると、コーディング補助の領域は募集の数そのものは安定している一方で、求められる範囲が少しずつ広がっています。純粋な静的コーディングだけの案件は減り、CMSの設定、フォームの実装、簡単なJavaScriptの調整、AIツールを使った既存コードの整理までを含む募集が増えています。この流れを踏まえると、提案文で書くべきことも変わります。「HTMLとCSSができます」ではなく、「周辺のどこまで対応できるか」を明示したほうが刺さる場面が増えました。

隣接領域の広がり方を把握しておくと、提案の幅が変わります。開発案件全般の実務内容はアプリケーション開発のお仕事に、AIの業務活用を支援する仕事の中身はAIコンサル・業務活用支援のお仕事にまとまっています。マーケティングやセキュリティ寄りの周辺案件についてはAI・マーケティング・セキュリティのお仕事が参考になります。文章仕事を組み合わせて収入の谷を埋める人も多く、その場合の相場感は著述家，記者，編集者の年収・単価相場で確認できます。

20年この市場を見てきた立場から言えば、提案文が上手い人が長く続くわけではありません。長く続いているのは、最初の1件を丁寧にやって、そのまま同じ発注者から2件目、3件目をもらっている人です。提案文を書く回数が多い人ほど、実は不安定な状態にあります。提案文の役割は「入口を1つ開けること」であって、開いた後の関係づくりが本体です。この順番を取り違えると、いつまでも提案文を書き続ける側から抜けられません。

運営者として見てきた限りでは、仲介手数料が乗らない直接の取引をしている人ほど、この関係づくりに時間を使えています。同じ5万円の案件でも、間に何割か抜かれる形と、そのまま受け取れる形では、次に投じられる時間の余裕が変わる。手数料0%の意味は金額の大小ではなく、依頼する側が同じ予算でより多く頼めて、受ける側の手元に厚く残るという構造にあります。手元が厚い人は、目先の1件を取りにいく提案文ではなく、次につながる仕事の仕方を選べる。提案文が通らないと悩んでいる皆さんに最終的に必要なのは、書き方の技術より、この構造に自分を置くことだと感じています。

在宅で働く上での体調と気力の維持も、提案文の質に直結します。疲れているときに書いた提案文は、冒頭が自己紹介から始まりがちです。長く続けるための習慣は在宅ワーカーのメンタルヘルスケア｜孤独・燃え尽きを防ぐ5つの習慣【2026年版】にまとまっているので、提案が通らない時期こそ目を通しておく価値があります。