「初案件って、学習通りにいくもの?」
「全然いきませんでした。想定外だらけでしたよ」
デイトラを卒業して初案件を受注した時、「学習でやったことがそのまま活きるはず」と思っていました。実際、技術面ではその通り。でも、学習と実務の間には思ってもみなかったギャップがたくさんありました。
デザインデータがFigmaじゃない。作りながらデザインが変わる。納品後に出先で不具合の連絡が来る。クライアントからのメールが怖くなる…。
この記事では、僕が実務で経験した「焦ったこと」「想定外だったこと」を正直にお伝えしていきます。これから初案件を受ける方の心構えになれば幸いです。
- 初案件を控えていて不安を感じている人
- 学習と実務の違いを事前に知っておきたい人
- 実務でのトラブル対処法を知りたい人
- クライアントとのやり取りに不安がある人
学習と実務で一番違ったこと

デザインデータがFigmaとは限らない
デイトラではキレイに整ったFigmaのデザインデータからコーディングしていました。レイヤーも整理されていて、余白やフォントサイズも明確に読み取れる。
でも実務では、デザインデータがFigmaで来るとは限りません。
Excel、Photoshop、Illustrator、Canva…。案件によってバラバラです。Excelの画像データから作ってくださいと言われたときはびっくりしました。
Figma前提で学習していた身からすると、最初はかなり戸惑いましたね。
当然「思ってたのと違う」となり、修正が多く来ました。大変ですが、最初はこんなものと割り切ってやっていました!
デザインが途中で変わる・後から届く
学習では「完成したデザイン→コーディング」という流れが当たり前でした。
でも実務では、コーディングしながら並行してデザインが届くケースがある。「ここのセクション、やっぱりこうしたい」と途中で変更が入ることも珍しくありません。
パターン化が難しかったり、手戻りが多くなったり。最初のうちは「え、また変わるの?」とストレスを感じることもありました。今は「実務ってそういうもの」と割り切れるようになりましたが。
デイトラ基準だと「これでいいの?」と思うことがある
デイトラで習ってなくて困ったことは、正直ほとんどないですね。むしろ逆で、デイトラの基準が厳しすぎて「実務ではここまで求められないの?」と驚くことの方が多かった。
デイトラは大変だけど、その分、実務に入った時の安心感があります。「デイトラで鍛えられたおかげで余裕がある」と感じる場面は何度もありました。
実務で出会った技術・ツール

Git / GitHubは求められることが多い
チームで開発する案件では、Git / GitHubの使用を求められることが何度かありました。
デイトラでも触れてはいましたが、実務で使うとなるとブランチの切り方やプルリクエストの出し方など、より実践的な知識が必要になる。ここは案件を通じて覚えていきました。
GSAP・Bootstrap・Tailwindなど
アニメーションライブラリのGSAPは、実務で初めて触りました。また、BootstrapやTailwind CSSを使った案件もあります。
全部を事前に覚えておく必要はないけれど、「こういうものがある」と知っておくだけで、案件の幅が広がりますね。余裕があれば少しずつ触っておくといいかもしれません。
見たことない命名規則に驚いた
既存サイトの修正案件で、初めて他人のコードを触った時は驚きました。
デイトラではBEM(Block Element Modifier)を中心に学んでいたのですが、実務のコードは独自の命名規則だったり、CSSで同じようなスタイルが重複して放置されていたり。「現場のコードってこうなんだ…」という洗礼を受けましたね。
でもこれも経験を積むうちに慣れてきて、今では「どんなコードでも読み解ける力」になっていると感じています。
実務で焦ったエピソード

納品後に出先で不具合の連絡が来た
一番焦ったのは、納品後にサイトの表示崩れが見つかった時です。
しかもその連絡が来たのは、遠くに出かけている最中。手元にパソコンがなくて、どうしようもなくて急いで帰りました。
この経験以降、なるべくパソコンを持ち歩いて行動するようにしています。フリーランスはいつどこで対応が必要になるか分からない。これは会社員時代にはなかった感覚ですね。
納期管理は「1週間の余裕」がルール
納期に間に合わなかったことは、今のところありません。
これは意識的に対策していて、必ず1週間の余裕を持った納期を提案するようにしています。クライアントにOKをもらえれば、不測の事態があっても対応できる。
納期が最初から決まっている場合は、その案件に集中して他の作業を止めます。「納期を守る」はフリーランスの信頼の土台なので、ここは絶対に落とさないようにしていますね。
メンタル面で一番きつかったこと

クライアントからのメールが怖くなった
「自分には無理かも」と思ったことは、正直何度もあります。
作業自体は楽しくできるんです。でも、クライアントから修正依頼が何度も来ると、だんだん連絡自体に怯えるようになってしまって…。メールの通知が来るだけで心臓がバクバクする。最初の頃はメールが来るだけで恐ろしかったですね。
「また何か指摘されるんじゃないか」「自分のスキルが足りないんじゃないか」。そんな不安が頭の中をぐるぐる回る日々でした。
「ダメだったらごめんなさいしよう」と割り切った
1年以上続けて、少しずつ慣れてきました。乗り越えたきっかけは、少しおおらかに構えるようにしたこと。
「ダメだったらごめんなさいしよう」。そう割り切ったら、気持ちがすごく楽になりました。完璧を目指しすぎると自分を追い込むだけ。ミスはミスとして誠実に対応すれば、大抵のことはなんとかなります。
実際、大きな問題は今のところ起きていません。あの頃の恐怖は、自分で作り出していた部分が大きかったんだと思います。
あわせて読みたい
まとめ

この記事の内容を振り返ります。
学習と実務の違い
- デザインデータはFigmaとは限らない(Excel、Photoshop、Canvaなど)
- デザインが途中で変わる・後から届くことがある
- デイトラ基準の方が厳しいので、技術面は意外と大丈夫
実務で出会った技術
- Git / GitHubはチーム開発で必須
- GSAP、Bootstrap、Tailwindなど案件によって様々
- 他人のコードの命名規則に驚くことも
焦ったエピソード
- 出先で納品後の不具合連絡 → 以降はPC持ち歩くように
- 納期は1週間余裕を持って提案するルールにしている
メンタル面
- 修正依頼が来るたびにメールが怖くなった
- 「ダメだったらごめんなさいしよう」と割り切って楽になった
- 1年以上続けて少しずつ慣れてきた
初案件は焦ることだらけです。でも、その焦りは全部「次からの対策」に変わります。最初から完璧にできる人なんていないので、怖がりすぎず、一つずつ経験を積んでいきましょう。

コメント