はじめに
プログラミングを学び始めた頃、自分の力で案件を獲得することが目標でした。
公務員として9年間働きながら、副業として、そして将来的にはフリーランスとしてエンジニアの仕事ができるようになりたいと考えていました。ただ正直なところ、学習を始めたばかりの頃は「案件を取れる自分」を具体的にイメージできていませんでした。
HTMLって何、というレベルから学習を始めて、最終的に最初の案件を獲得するまでに何があったか。喜んだことも、本当に辛かったことも、できるだけ正直に書きます。
HTMLとCSSすら分からなかった頃
学習を始めた当初、本当に何も知りませんでした。
「タグって何？」というレベルからスタートして、YouTubeの入門動画とProgateを使って基礎を学び始めました。<h1>タグで文字が大きくなる、colorプロパティで色が変わる——そういう小さな発見を積み重ねる毎日でした。
最初にHTMLで「Hello World」が表示されたとき、「自分が書いたコードが画面に出た」という感覚が、続ける最初のエネルギーになりました。単純ですが、あの体験がなければその後を続けていなかったかもしれません。
Progateでいくつかのコースを終えた頃には、「なんとなく理解できている気がする」という感覚がありました。でも後から分かるのですが、それは「誰かが用意した道を歩んでいる」だけだったのです。
Laravelとの出会いと最初の混乱
学習を進めていく中で、COACHTECHのカリキュラムを通じてLaravelに出会いました。
PHPのフレームワークで、Webアプリケーションを効率的に構築するための仕組みです。「フレームワーク」という言葉自体も初めて聞く概念でした。
最初にLaravelのドキュメントやカリキュラムのテキストを開いたとき、見慣れない言葉が並んでいました。「ルーティング」「コントローラー」「モデル」「マイグレーション」「Eloquent」——それぞれが何を意味するのかすら分からない状態で、「自分にこれは無理かもしれない」と思ったのを覚えています。
それでも毎日少しずつ触り続けると、ある日突然、バラバラだった概念が繋がる瞬間が来ます。
「ルーティングがリクエストを受けてコントローラーに渡す」「コントローラーがモデルを通じてデータベースと話す」「その結果をBladeビューに渡してHTMLを返す」——MVCの流れが頭の中で一本の線になった瞬間は、今でも覚えています。その瞬間の感覚が楽しくて、Laravelへの学習意欲が一気に上がりました。
ポートフォリオ制作が想像以上に大変だった
Laravelの基礎を学んでからポートフォリオ制作に入りましたが、これが想像以上に大変でした。
チュートリアル通りにコードを書くのと、ゼロから自分でサービスを設計・実装するのは、全く別の作業でした。チュートリアルでは「何を作るか」「どう設計するか」は全部決まっていました。ポートフォリオ制作では、その全てを自分で決めなければなりません。
特に詰まったのは「仕様を決める」段階でした。何を作るか決まらない。機能をどこまで実装するか決められない。決めたはずの仕様が実装を進めるうちに変わってくる——こういった「決める力」は、チュートリアルをこなしているだけでは身につかなかった部分でした。
実装に入ってからも苦労は続きます。テーブルの設計が甘くて後から変えたくなる。コントローラーに処理が詰め込みすぎて読みにくくなる。リレーションを張ったのに取得できなくてエラーが出続ける——こういった問題が連続しました。
何度か「もうやめようか」と思いましたが、「ポートフォリオが完成しなければ応募もできない」という事実が続ける理由になりました。
「完璧より完成」を優先した
ポートフォリオ制作を通じて学んだ最も大切なことのひとつが、「完璧を目指すと完成しない」ということでした。
最初は「きれいなコード・充実した機能・見栄えの良いUI」を一度に達成しようとしていました。結果として、どれも中途半端なままで時間だけが過ぎていきました。
途中から、「まず動く状態で完成させる」に方針を切り替えました。リファクタリングは後でできる。機能追加も後でできる。でも「完成させること」だけは今この瞬間にしかできない——そう割り切ったら、一気にペースが上がりました。
「完璧でなくていいから完成させる」という判断は、後の案件でも繰り返し応用することになる考え方でした。
最初の応募は怖かった
ポートフォリオが完成した後も、すぐに応募できたわけではありませんでした。
クラウドワークスとランサーズのアカウントを作り、案件一覧を開いても、「応募する」ボタンの前で何度も止まりました。「こんな自分が応募していいのか」「スキルが足りなくて迷惑をかけるんじゃないか」という気持ちがあったからです。
最終的に背中を押したのは、「応募しなければゼロのまま」という単純な事実でした。断られることへの恐怖より、何もしないまま時間が過ぎることの方が怖かったです。覚悟を決めて、最初の提案文を送りました。
現実は甘くなかった
最初の数週間、返信はほとんど来ませんでした。
提案を送っても無視される。既読すらつかない。たまに返信が来ても「今回は見送ります」という一行。何が悪いのか分からないまま、時間だけが過ぎていきました。
今振り返ると、返信が来なかったのは当然でした。提案文はほぼ定型文で、ポートフォリオは「動くこと」を優先して作ったもの。クライアントの視点から見れば、選ぶ理由がなかったと思います。
ただ当時は「何がダメなのか」の分析ができておらず、ただ落ち込むことしかできませんでした。
返信が来ない時期に試したこと
返信が来ない期間も、完全に止まっていたわけではありませんでした。
試したことを順番に書きます。
提案文を書き直した 最初の提案文は「こういう経験があります、こういうスキルがあります」という自己紹介型でした。改善後は「この案件の要件はこうで、自分ならこのアプローチで解決できます」という課題解決型に切り替えました。クライアントが知りたいのは「あなたが何をできるか」ではなく「あなたが自分の問題を解決してくれるか」だと気づいたからです。
応募先のジャンルを絞った 最初は「とにかく幅広く応募する」という戦略でしたが、LP修正・WordPress案件に絞ることにしました。Laravelを使う案件は競合が多く、実績なしでは難しかったです。まずHTMLとCSSでできる仕事で実績を作ることに切り替えました。
ポートフォリオのトップページを改善した 見てもらえたとして、何秒でポートフォリオの内容が伝わるか。冒頭の説明文を短くシンプルにして、「どんな人か」「何が作れるか」が3秒で伝わる構成に変えました。
初めて案件が決まったとき
初めて案件獲得の連絡をもらったとき、しばらく現実感がありませんでした。
LPの軽微な修正案件で、報酬は数千円程度です。小さな案件ですが、「自分の技術に対してお金を払ってもらえた」という事実は、金額以上の意味がありました。
採用された理由を後からクライアントに確認してみると、「提案文で自分の問題点を整理してくれていたから」という答えでした。技術力の差ではなく、提案の書き方が決め手だったと知り、改善し続けて良かったと思いました。
公務員として働きながら学習を始めて、スクールに通って、ポートフォリオを何度も見直して、何十回も提案して——その全てが「数千円の案件」につながった瞬間でした。「自分はエンジニアとして仕事ができる」という手応えを初めて感じた瞬間でした。
最初の案件を終えて気づいたこと
案件を終えると、また新しい課題が見えてきました。
納期の感覚が身についていなかったこと。クライアントとの認識合わせを最初にしっかりしておく必要があること。「動けばいい」ではなく「使いやすいか」「意図した動作になっているか」をクライアント目線で確認する重要性——これらは、学習段階では意識していなかったことでした。
特に印象的だったのは、クライアントから「思っていた通りです、ありがとう」という一言をもらったときです。コードが動くことへの感謝ではなく、「自分が期待した通りになった」という感謝でした。技術よりコミュニケーションが大切だと、初めて肌で感じた体験でした。
「案件を取ることがゴール」だと思っていましたが、取ってからの方が学びが多かったです。この気づきが、後のフリーランス活動の方向性を変えてくれました。
Laravelを学んで本当に良かったこと
少し時間が経った今、改めてLaravelを選んで学んだことの意味を考えます。
Laravelは日本国内でも求人・案件のニーズが高いフレームワークです。Web系のフリーランス案件でもLaravelの案件は一定数あり、学習コストに対してリターンが見込める選択肢でした。
ただそれ以上に、Laravelを学んだことで「MVCの考え方」「ORMとデータベースの関係」「ルーティングの仕組み」といった、フレームワーク共通の概念が身につきました。Laravelで学んだ設計の考え方は、別のフレームワークに移るときにも下地として機能しています。
最初は複雑に見えたLaravelの仕組みが、一定の学習量を超えた瞬間に「これは単純な仕組みをきれいに組み合わせたものだ」と見えるようになる瞬間があります。その感覚を手に入れられたことが、Laravelを選んで良かったと思う一番の理由です。
まとめ
Laravelを学び始めた頃、最初の案件獲得は遠い目標でした。
ポートフォリオ制作で何度も詰まり、応募しても返信が来ない日々が続き、それでも少しずつ改善を続けた先に最初の案件がありました。
金額は小さかったですが、あの体験がなければ今の自分はなかったと思っています。
技術力よりも大切だったのは、「完璧を待たずに行動すること」「返信が来なくても改善して続けること」「提案文をクライアント目線で書き直すこと」でした。そして案件が取れてから、本当の学びが始まりました。
Laravelを学ぶ人へのアドバイス
最後に、これからLaravelを学ぼうとしている人、学んでいる途中の人へ伝えたいことを書きます。
公式ドキュメントを早めに読み始めてください 最初は難しく感じますが、チュートリアルが終わった段階から少しずつ公式ドキュメントを読む習慣をつけると、学習スピードが上がります。Laravelはドキュメントがとてもよくまとまっているフレームワークです。
エラーメッセージを怖がらないでください エラーは問題の場所を教えてくれています。最初はエラーが出るたびに落ち込んでいましたが、「エラーメッセージを読む → スタックトレースを追う → 原因を特定する」という手順を繰り返すうちに、エラーへの向き合い方が変わりました。
小さなものから実際のサービスを作ってみてください チュートリアルを終えたら、自分が実際に使いたいと思う小さなWebアプリを作ってみてください。機能が一つでも良い。「自分が作って自分が使うもの」を作る経験が、学習の質を大きく変えます。
Laravelは最初難しく見えますが、仕組みを理解すると非常に論理的で、一度覚えると応用が効くフレームワークです。詰まっても諦めずに続けてください。
おすすめのサービス
