先に結論：僕が変えた3つのこと
長く書きますが、結局のところ効いたのは次の3つでした。
ひとつ、提案文を「自己紹介型」から「課題解決型」に書き直した。ふたつ、応募先のジャンルをLaravelから、LP修正・WordPressに絞った。みっつ、ポートフォリオのトップページを「3秒で伝わる」構成に変えた。
そして、最初の案件が決まったあとにクライアントへ採用理由を聞いてみたら、返ってきた答えは「提案文で自分の問題点を整理してくれていたから」でした。技術力ではなく、提案の書き方が決め手だった。この事実が、僕の考え方を根本から変えました。以下、詳しく書きます。
変えたこと① 提案文を「自己紹介型」から「課題解決型」へ
最初に送っていた提案文は、今読むと恥ずかしいくらい典型的なものでした。「こういう経験があります」「こういうスキルを学びました」——要するに自己紹介です。テンプレートに毛が生えた程度で、案件ごとの中身はほとんど変えていませんでした。
返信が来なかったのは、当然でした。クライアントが知りたいのは「あなたが何をできるか」ではなく、「あなたが自分の問題を解決してくれるか」だからです。
そこで書き方を変えました。案件の募集文をよく読み、「この案件で困っていることは何か」を自分なりに整理し、「自分ならこのアプローチで解決します」と提示する形にしたのです。スキルの列挙はその根拠として最小限添えるだけ。主役を「自分」から「クライアントの課題」に移した、という言い方が近いと思います。
これが、後から分かった採用の決め手でした。
変えたこと② 応募ジャンルを絞った（Laravelを一旦捨てた）
最初は「とにかく幅広く応募する」戦略でした。せっかくLaravelを学んだのだからと、Laravel案件にも手を出していました。
でも現実として、Laravel案件は競合が多く、実務実績ゼロの自分が選ばれる余地はほとんどありませんでした。そこで方針を変え、LP修正やWordPress案件——つまりHTML/CSSでできる仕事に絞りました。
学んだ技術のいちばん上のレイヤーで戦うのではなく、「今の自分が確実に価値を出せて、かつ実績としてカウントできる場所」に降りていく。遠回りに見えますが、実績ゼロの状態を抜けるにはこれが一番早かったと思っています。
変えたこと③ ポートフォリオを「3秒で伝わる」形に
仮に提案を読んでもらえたとして、クライアントがポートフォリオを開いてくれる時間はごくわずかです。
そこでトップページを作り直しました。冒頭の説明文を短くシンプルにして、「どんな人か」「何が作れるか」が3秒で伝わる構成に変えたのです。作品を並べる前に、まず判断材料を渡す。この順番が大事でした。
初案件が決まった日
初めて案件獲得の連絡をもらったとき、しばらく現実感がありませんでした。
内容はLPの軽微な修正で、報酬は数千円程度。決して大きな仕事ではありません。それでも「自分の技術に対してお金を払ってもらえた」という事実は、金額以上の意味がありました。
数字で書くと、こうです。提案を送り始めてから初案件が決まるまで、3ヶ月以上かかりました。その間に送った提案は50件以上。ほとんどが返信すらありませんでした。
しかもこのとき、僕はすでに公務員を辞めていました。安定した給料はもうない。学習にはローンを組んで受講料を払っている。その状態で、50件断られ続ける3ヶ月です。正直、精神的にはかなり削られました。「本当にこの道で食べていけるのか」と何度も思いました。
だから、これを読んでいるあなたが今10件や20件断られている段階なら——まだ全然、途中です。僕は50件送って、やっと数千円の案件でした。
公務員として働きながら学習を始め、スクールに通い、そして職を手放してから、ポートフォリオを何度も見直し、提案を送り続けて——その全部が、この数千円の案件につながりました。「自分はエンジニアとして仕事ができる」と初めて手応えを感じた瞬間でした。
案件を取ってからの方が、学びが多かった
「案件を取ることがゴール」だと思っていました。実際は逆で、取ってからの方が学ぶことは多かったです。
納期の感覚が身についていないこと。クライアントとの認識合わせを最初にしっかりやる必要があること。「動けばいい」ではなく「使いやすいか」「意図した動作になっているか」をクライアント目線で確認する重要性——学習段階では、どれも意識していませんでした。
特に印象に残っているのは、クライアントからもらった「思っていた通りです、ありがとう」という一言です。コードが動いたことへの感謝ではなく、「自分が期待した通りになった」ことへの感謝でした。技術よりコミュニケーションが効く場面がある——それを初めて肌で理解した体験でした。
そもそも、ここに至るまで（学習フェーズの話）
ここからは補足として、案件に応募できる状態になるまでの話を短く書いておきます。
学習を始めた当初は「タグって何？」というレベルでした。YouTubeの入門動画とProgateで基礎をやり、最初にHTMLで「Hello World」が表示されたときの、自分の書いたコードが画面に出たという感覚。あれが続ける最初のエネルギーになりました。
その後、COACHTECHのカリキュラムでLaravelに出会います。「ルーティング」「コントローラー」「モデル」「マイグレーション」「Eloquent」——最初は言葉の意味すら分からず、「自分には無理かもしれない」と本気で思いました。それでも毎日触っていると、ある日バラバラだった概念が繋がります。リクエストをルーティングが受け、コントローラーがモデル経由でデータベースと話し、結果をBladeに渡してHTMLが返る。MVCの流れが一本の線になった瞬間は、今でも覚えています。
そしてポートフォリオ制作。これが想像以上にきつかった。チュートリアル通りに書くのと、ゼロから設計して実装するのは、まったく別の作業です。何を作るか決まらない、機能の範囲が決められない、決めたはずの仕様が実装中に変わる。テーブル設計が甘くて後から作り直し、コントローラーに処理を詰め込みすぎて読めなくなり、リレーションを張ったのにデータが取れずエラーが出続ける。何度も「もうやめようか」と思いました。
「完璧より完成」——ここで学んだ一番のこと
ポートフォリオ制作で学んだ最大のことは、「完璧を目指すと、完成しない」でした。
最初はきれいなコードも、充実した機能も、見栄えの良いUIも、全部を一度に達成しようとしていました。結果、どれも中途半端なまま時間だけが過ぎた。
途中から「まず動く状態で完成させる」に切り替えました。リファクタリングは後でできる。機能追加も後でできる。でも「完成させること」は今この瞬間にしかできない。そう割り切ったら、一気にペースが上がりました。
この「完璧を待たずに、まず出す」という判断は、その後の案件でも、このブログを続けることでも、繰り返し効いてくる考え方になりました。
これからLaravelを学ぶ人へ
最後に、技術面で伝えたいことを3つだけ。
公式ドキュメントを早めに読み始めてください。最初は難しく感じますが、チュートリアルが終わった段階から少しずつ読む習慣をつけると、学習スピードが変わります。Laravelはドキュメントがよくまとまっています。
エラーメッセージを怖がらないでください。エラーは「壊れた証拠」ではなく「問題の場所を教えてくれる情報」です。メッセージを読む→スタックトレースを追う→原因を特定する。この手順を繰り返すうちに、エラーとの関係が変わります。
そして、小さくていいので自分が使いたいものを作ってください。機能はひとつでいい。「自分が作って自分が使うもの」を作る経験が、学習の質を決定的に変えます。
まとめ
提案しても返信が来なかった時期、僕は「技術力が足りないからだ」と思っていました。でも実際に足りなかったのは、クライアントの課題を読み取って言葉にする力でした。
提案文を課題解決型に変え、勝てる土俵にジャンルを絞り、ポートフォリオを3秒で伝わる形にする。この3つで、50件以上・3ヶ月以上の先に、ようやく最初の数千円の案件にたどり着けました。金額は小さくても、あれがなければ今の自分はありません。
完璧を待たずに動くこと。返信が来なくても、改善して続けること。案件獲得の前も後も、結局そこに尽きると思っています。
