はじめに
初めまして！福岡工業大学3年の堀田空です。
ディップ株式会社のインターンシップで、求人情報サイト「バイトル」のWebフロントエンド開発に携わりました。求人カードや検索履歴・保存条件画面のUI修正を中心に、既存コンポーネントの改善や検索・応募機能の修正などを担当しました。
この記事では、実装からレビュー、関係者との相談、リリースまでを経験する中で学んだ、個人開発とは違う、実務のフロントエンド開発で大切な視点や気づきを紹介します。
インターンで設定した目標と理想像
インターンでは、最終的にサービスを使いやすくする成果物を作り、リリースまでの一通りの作業を終えることを目標にしました。
また、理想のエンジニア像として掲げたのは、AIが書いたコードや提案した実装に対しても、サービス価値や設計から実装まで、明確な理由と意図を持って承諾し、自分の言葉で説明できるエンジニアです。
AIの出力を含め、実装をブラックボックスにせず、自分が根拠を持ってコントロールできる状態を目指して開発に取り組みました。
取り組んだこと
設計方針を確認しながら進めた求人カードの修正
最初のUI修正では、複数の求人カードを枠付きのデザインへ統一しました。
バイトルのデザインシステムでは、小さなパーツを組み合わせてコンポーネントを構築し、プロパティを切り替えることで各カードの形へ変化させる設計が採用されています。修正前にFigmaの完成形だけでなく、共通パーツと各カードの関係を確認しました。
実装では、おすすめ求人カード、応募履歴などで使われる求人カード、キープした求人カードのデザインを調整しました。また、おすすめ求人カードの応募ボタンの重なりや、重複していたスタイルも修正しました。
この作業から、デザインシステムは見た目を統一するだけでなく、実装の「正」を共通部分へ集約する役割も持つと学びました。共通部分を修正すれば、カードごとの修正漏れを防ぎやすくなります。
個人開発では、目の前の画面が意図した見た目になれば完了と考えることもありました。業務では、同じ部品がどこで使われているか、今後変更するときに正しい実装をどこで管理するかまで考える必要がありました。
検索履歴・保存条件画面のUI修正
検索履歴・保存条件画面について、Figmaと実際の画面を見比べながら、表示内容や余白、アイコン、日時などを修正しました。
主な変更内容は次のとおりです。
- 0件の場合も件数を表示
- 日時の表示形式を変更
- ナイトワークを含むかどうかをアイコンと文言で表示
- 削除ボタンのアイコンと押下領域を調整
- 条件、件数、検索ボタンの配置や余白を調整
この修正を通じて、同じ情報でも、文字、アイコン、余白、配置によって伝わり方が変わることに気づきました。見た目を整えるだけでなく、利用者にとって情報を理解しやすいか、操作しやすいかまで考える必要がありました。
コード上では正しく見えても、実際に画面を表示すると崩れる場合があります。そのため、SP・tablet・PCの違いや、0件表示などの状態を確認しながら修正しました。
レビューでは、使わなくなった関数の扱いや、関数の命名・配置についても確認しました。不要な関数を残すと、その存在を忘れたり、後から読む人が必要なコードだと誤解したりする可能性があります。そのため、使わなくなった関数は削除しました。
また、関数名から処理内容が分かること、既存コードを参考に責務に合った場所へ置くことも意識しました。今の自分だけが理解できるコードではなく、将来ほかの人が安全に変更できるコードにすることが、長期運用されるサービスの保守性につながります。
操作方法の違いを考えた職種検索UIの改善
PCの職種検索では、横に並ぶ職種を移動するためのスクロールボタンを実装しました。
この作業を通して、同じ画面でも、マウス、トラックパッド、スマートフォンなど、利用するデバイスによって操作感が異なることに気づきました。横スクロールできる実装になっていても、利用者がその操作に気づけなければ、使いやすいUIとはいえません。
実装では、既存のボタンを再利用できるか確認し、プロジェクト内のコンポーネントを使用しました。また、表示や操作について疑問がある部分はデザイナーと話し合いました。
提示されたデザインをコードにするだけでなく、実際の操作方法を考え、必要に応じてデザイナーやPOと相談することもフロントエンド開発の一部だと学びました。
デザイナーとの話し合いでは、実装した画面以外についても、次のような改善案を提案しました。
- 市区町村が多いエリア選択画面を、区切り線や階層表示で探しやすくする
- ナイトワークを含むかどうかを、見た目から判別しやすくする
- SPの職種選択でも、横に続く項目へ気づきやすくする
- 気になる求人を並べて比較できるようにする
提案した案が、すべてそのまま実装対象になるわけではありません。例えば比較機能は、便利そうだと考えて提案しましたが、関連する既存機能が実際にはあまり使われておらず、追加すると継続的な管理コストもかかることを教えてもらいました。
個人開発では「便利そうだから作る」で決めることがありました。業務では、過去に検討された経緯、利用データ、主な利用者、開発後の管理コスト、今回のスコープまで含めて優先度を判断します。自分の案が否定されたのではなく、自分だけでは持てない情報が加わり、判断の精度が上がったと感じました。
UI以外の既存機能とAPI呼び出しの検討
UI以外にも、検索条件の並び順や応募画面へのパラメータ引き継ぎを修正しました。
検索条件の修正では、並び順の値が`null`の場合の扱いを、既存のURL解析処理と統一しました。応募機能の修正では、フォームを省略して確認画面へ進む場合にも、必要なクエリパラメータを引き継ぐようにしました。
どちらも変更するコードは小さなものでしたが、既存の仕様やデータの流れを理解しなければ、正しい修正箇所を判断できません。また、修正した条件を自動テストへ追加し、期待する振る舞いを確認しました。
さらに、検索候補を取得する外部APIをフロントエンドから直接呼ぶか、React Routerのサーバーを経由するかという実装方針も検討しました。以前の実装はフロントエンドから直接呼んでいましたが、私はサーバーを経由した方がよいのではないかと考えました。
最初は感覚的な考えだったため、両方の方法を比較しました。サーバーを経由すると、次の利点があります。
- 外部APIをブラウザへ直接露出させない
- ログ、監視、レート制限をサーバーへ集約できる
- エラー処理やレスポンス形式を統一できる
- CORSなど、ブラウザから直接呼ぶ場合の制約を避けられる
一方で、サーバー側の負荷や、入力中に発生するリクエスト数を考慮する必要があります。連続入力中のリクエストを抑えることで負荷とのバランスを取り、最終的にReact Routerのサーバーを経由する方式を選びました。
この経験から、「なんとなくこちらがよさそう」という考えをそのまま採用せず、運用まで含めた根拠を整理して意思決定することを学びました。
レビューしやすい状態を作る
インターンでは、実装後にPRを作成し、レビューで指摘された内容へ複数回対応してLGTMをもらい、マージまで進めました。その中で、コードを正しく書くだけでなく、レビューする人が確認しやすい状態を作ることも大切だと気づきました。
社員の方から提案を受け、UIの変更では画面画像を載せ、レビュー対応後は修正したコミットのハッシュを示し、関連するタスクのURLも貼りました。これにより、コードだけでは分かりにくい変更や、再確認する範囲を相手へ伝えやすくなりました。
自分の実装を説明し、チームが判断するための材料をそろえるところまでが開発作業だと学びました。レビューもコードの検査だけではなく、より良い実装を一緒に考えるコミュニケーションの一つです。
気づき・学び
今回、特に大きかった学びは、フロントエンド開発では「仕様どおりに動くこと」だけでなく、「利用者が理解し、操作しやすいこと」まで考える必要があるということです。
件数や日時、選択状態のような同じ情報でも、表示方法は一つではありません。利用者やデバイスに合った伝え方を考え、UI・UXやアクセシビリティの観点から確認する必要があります。
また、機能を追加できるからといって、必ず追加すべきとは限りません。主な利用者、利用率、必要性を考え、優先度を決めることもユーザー体験につながります。その判断には、コードを書く時間だけでなく、デザイナーやPOと会話し、認識を合わせる時間が必要でした。
大きな組織では関係者が多いからこそ、実装の理由や影響範囲を分かりやすく伝える力も必要だと感じました。
チームで動くためのコミュニケーション
初日にチームのレトロスペクティブを見学し、現状や改善点、今後も続けることを段階に分けて共有する流れを知りました。個人で作業するのではなく、チームで同じ状況を把握し、次の行動を決めるための方法です。
日々の開発でも、仕様の確認や「この機能があれば便利ではないか」「こちらの方が使いやすいのではないか」という会話に多くの時間を使いました。コードを書く時間だけが開発ではありませんでした。
Slackでは、文章に加えて絵文字やリアクションも使われていました。確認済みなのか、対応中なのかが分かりやすく、文字だけでは伝わりにくい感情も補えます。相手が理解しやすい形で伝えることは、対面の会話、Slack、PRレビューのすべてに共通していました。
気づき・学び
今回、特に大きかった学びは、業務開発では「自分の環境で動くこと」だけをゴールにできないということです。
件数や日時、選択状態のような同じ情報でも、表示方法は一つではありません。利用者やデバイスに合った伝え方を考え、UI・UXやアクセシビリティの観点から確認する必要があります。
また、機能を追加できるからといって、必ず追加すべきとは限りません。主な利用者、利用率、必要性を考え、優先度を決めることもユーザー体験につながります。その判断には、コードを書く時間だけでなく、デザイナーやPOと会話し、認識を合わせる時間が必要でした。
AIはコードの調査や実装に活用しましたが、操作性、ユーザーの利用状況、過去の検討経緯、運用上の判断といった情報をすべて持っているわけではありません。AIだけでは持てない情報を、人との会話や実際の画面での検証によって補いました。
個人開発との違いを振り返ると、次の4点に整理できます。
個人開発での考え方 | 業務開発で学んだ考え方 |
|---|---|
自分の環境で動けばよい | 複数の利用者・デバイスで確認する |
便利そうなら作る | 利用状況と管理コストから必要性を判断する |
自分が理解できればよい | 将来の変更と責務を考えて実装する |
経緯を自分が覚えていればよい | レビューできる情報を相手へ伝える |
目標に対する結果
インターン開始時には、サービスを使いやすくする成果物を作り、リリースまでの一通りの工程を経験することを目標にしていました。
実際に、Figmaと既存実装の確認、UIの実装、テスト、画面確認、PR作成、レビュー対応まで経験しました。UI関連の修正はApproveを得るところまで進めました。
また、応募者情報が入力済みの場合に入力画面を省略する処理で、必要な計測用パラメータが確認画面へ引き継がれない問題を修正しました。対象外のパラメータを引き継がないことも含めて回帰テストを追加し、この修正は本番リリースまで完了しました。
実際のサービスへ変更が反映されたときは、達成感よりもまず安堵が大きかったです。学校や個人開発では得にくい、本番サービスへ変更を届ける経験ができたことは貴重でした。
一方で、サービス価値、設計、実装を常につなげて説明する力は、まだ伸ばす必要があります。今後も、実装方法だけでなく「誰のために、なぜ作るのか」まで考え、自分の言葉で説明できるようになりたいです。
おわりに
インターンを通して、Figmaを見ながらコードを書くところから、画面での検証、デザイナーやPOとの相談、レビュー、リリースまで、フロントエンド開発の流れを経験できました。そして、その多くは一人でコードを書くのではなく、チームで判断し、相手へ伝える作業でした。
今後は、今回学んだUI・UX、アクセシビリティ、レビューの視点を生かし、細部まで根拠を持ってより良いものを提案できるエンジニアを目指します。
最後に、開発やレビューを支えてくださった社員・メンターの皆様に感謝申し上げます。
