はじめに
私は 2025年8月、エキサイト株式会社の就業型インターンシップ 「Booost!!!」 に参加しました。約1か月間、実際の開発現場に入り、これまでの個人開発では気づけなかったことを「チーム開発の現場での進め方」や「個人開発では意識しなかった責任あるコードの書き方」について書こうと思います。
自己紹介
フロントエンド・UIデザイン志望の27卒専門学生です。もの作りが好きで、これまではハッカソンや個人開発を通じてPython・Next.js・Unityなどを使いながらWebアプリやゲームを作ってきました。これまでの開発では、自分ひとりで作り切ることが多く「現場でのチーム開発の進め方」や「綺麗なコードの書き方」に触れる機会があまりありませんでした。そこで、実際の現場で開発を体験しながら学びたいと考え、このインターンに参加しました。
インターンでやったこと
FanGrowthのフロントエンドの開発業務に携わりました。
最初は簡単なタスクから始まりましたが、徐々にページ全体を任せてもらえるようになり、自分の成長を実感できました。レビューを通してコードの書き方も学べ、とても充実した1ヶ月でした。この記事ではチーム開発する上では当たり前のルールについて自分の失敗談も含めて書いていこうと思います。
規模が大きいページを作るときは必ず機能ごとにPRを作る
私は普段の個人開発ではページ単位でブランチを切っていたので、このやり方を聞いてすごく腑に落ちました。 ただ、いつもの癖でモックデータ込みのフロントエンドをまとめて作り始めてしまい、後から機能ごとにPRを切り分けようとした際に、GitHub ActionsでESLintエラーが発生してしまいました。結果的に修正に手間取り、今回はまとめてPRする形になってしまいました。 幸いAPIの繋ぎ込みはまだ行っておらず、コンポーネント単位でコードが分かれていたこともあって大きな問題にはなりませんでしたが、この経験を通して「最初から機能単位でブランチを切ってから作成する」ことの大切さを実感しました。
よく使うコンポーネントや変数は共通化する
共通化は個人開発でも意識して行ってきましたが、思ったように綺麗にいかないことが多いです。 なぜなら、作業の中で都度必要なものを追加してしまい、後から似たような処理や色指定がバラバラに散らばってしまうからです。 しかし FanGrowth では UI のほとんどが共通化されており、カラーコードに至るまで統一されていました。振り返ってみると、私は個人開発で同じ色をその都度コピーして使っていたことが多く、こうした無駄を減らす工夫にとても納得させられました。 この経験から、共通化は「効率化のため」ではなく「チーム全体の開発体験を整えるため」に必要なのだと感じました。
レビューは信頼関係を築く場
レビューを通して学んだのは、コードの良し悪しを判断されるだけではなく、「この人のコードなら安心して任せられる」と思ってもらえることの大切さです。小さな修正でも丁寧に対応することで、自然と信頼が積み重なっていくのを実感しました。 責任あるコードを書くというのは、動くものを作るだけではなく、チーム全体が安心して開発を進められるようにすること。その姿勢が結果的に次のタスクやチャンスにつながるのだと感じました。
チーム開発で意識すべきこと
これらの経験を通して強く感じたのは、チーム開発では「自分が分かればいい」ではなく「誰が見ても分かる状態で作る」ことが基本だということ改めて実感しました。 個人開発では多少の雑さや後回しが許されますが、チーム開発ではその積み重ねが全体の遅れや混乱につながります。だからこそ、最初から丁寧に分けて作り、共通化を意識し、レビューを前向きに受け入れることが欠かせません。
終わりに
1か月という短い期間でしたが、多くの学びを得られたのは、メンターの方が丁寧にレビューをしてくださったおかげです。自分ひとりでは気づけなかった視点や改善点をたくさん教えていただき、本当に感謝しています。この経験を糧に今後も学び続け、ものづくりを楽しんでいきたいです。
