1. はじめに
こんにちは、鈴木稜生です。ディップのインターンシップに参加し、バイトルのリニューアルを担当するチームでWebフロントエンドの開発に取り組みました。
所属・学年 愛知工業大学情報科学部 学部3年
参加期間 2026年9月24日（木）〜10月2日（金）の7日間
これまでのインターンや個人開発を通じて、全体を理解しきっていない段階でも、必要な機能や時間がかかりそうな部分を見つけ、作業を分けて考えることが自分の強みだと感じていました。小さく作り、反応を確かめながら改善することも好きです。
今回は、その進め方をチームの中で行い、自分が価値を発揮できるかを確かめるために参加しました。
2. インターンの目標
具体的な目標は、担当する機能の背景や仕様を理解し、実装からレビュー対応、PRのマージまでやり切ることでした。その過程で、なぜその方法や範囲を選び、何を対象外にしたのかを、自分の言葉で説明できる状態を目指しました。
担当したのは、ホーム画面の文言変更、前のインターン生が作成したPRのレビュー対応、メール配信設定のUI実装、メール配信への登録導線の検討でした。
新規の対応はA・B・Cに分けました。設定画面を仕上げるAをGREAT、追加で取り組みたい仕事一覧や保存した検索条件からの登録導線をB・Cとし、MOREに位置付けました。
当初はA・B・Cをすべてやり切るつもりでした。AができればBとCは並行して実装できそうだと考え、3つにタスクを分けています。
3. 取り組んだこと
たった一行の文言変更
最初のタスクは、ホーム画面の「検索条件を設定してください」を「仕事を探す」に変えるものでした。
変更するコードは一行でしたが、レビューでは「仕事をさがしてみよう！」の方がUXライティングのガイドラインに沿うのではないかと提案されました。
文言を選ぶ理由を検証するため、改めてガイドラインやボタンを押した先の操作、同じページの文言を確認しました。スマートフォンでの見え方に加え、競合他社の表示も確認しています。デザイナーと相談した結果、採用したのは「仕事を探す」でした。根拠となる情報源を共有し、検討した内容と判断理由をGitHubのコメントに残しました。
実務では文言一つでもここまで考慮するのかと感じました。
計測する部分を変え、不要な取得を減らす
メール配信設定で引き継いだのは、前のインターン生が作成した3つのPRでした。まずコードを読み、データ取得から表示、配信操作までの流れと、残るレビュー対応を確認しました。
バックエンドへの負荷に気を配る必要はあると思っていましたが、実際の実装ではAPIの呼び出し回数やレスポンスのデータ量の確認が抜けていました。レビューでAPI側の負荷にも目を向けるよう指摘を受け、登録条件の件数や重複によって、呼び出し回数とデータ量がどう変わるかを調べました。
登録条件がなくてもマスタを取得する箇所や、都道府県データを重複して取得する箇所が見つかりました。不要な取得を省き、取得済みのデータを再利用するよう修正した結果、登録条件がない場合のマスタ取得は2回から0回に減りました。
今回のレビューで、分かっているつもりでも、実装する際の確認から抜けてしまうことがあると実感しました。
小さく実装し、実物を見ながら表示方針を合わせる
設定画面で実装したのは、PCとスマートフォンの一覧・詳細表示や、配信操作のUIでした。その際、操作に失敗したときの表示など、Figmaのデザインだけでは確定できない動作がありました。
最初の文言変更での経験を踏まえ、今回は実装前に疑問を洗い出すことから始めました。確認したかった状態や動作をSlackで共有してから、対面で確認する時間も設けました。
言葉だけではイメージしづらそうな部分は、軽く実装して見てもらいました。失敗時の通知を､ ほかの画面と同じToastで知らせる方針で合意することができました。当初のモーダル内の文章を変更する独自の表示は取り下げました。実物を見ながら、表示方法を統一するという観点で認識を合わせられた経験でした。
条件の名前を取得できない場合も相談しました。当初は、取得失敗を利用者に伝えるべきだという考えでした。相談では代替文言も意味が伝わりにくいという話になり、保存済みの条件を維持したまま該当項目を非表示にし、調査用のログを残す方針にしました。
既存仕様を問い直し、背景を知る
新バイトルへの移行では、既存の機能も新しく作るものとして、今の仕様でよいのかを問い直す機会があると聞きました。メール配信への登録条件も、これを機に考え直す必要があると考えました｡
旧サイトのメール配信設定にはアカウント登録が必要でした。一方で、求人にはゲストのまま応募できました。それなら、メール配信にもゲストで登録できる入口が必要ではないかと考え、相談しました。
話し合って決めたのは、アカウントを必須にする方針でした。私は、メール配信にはメールアドレスが必要だからだと考えていました。しかし、ほかにも理由があるのではないかと聞かれ、うまく答えられませんでした。
そこで教わったのは、ゲスト応募も、本来はアカウント必須にしたかった仕様を調整した結果だということでした。
さらに、登録導線を増やしたい背景には、バイトルとスポットなどのサービスを横断してアカウント情報を活用する将来像があると聞きました。応募者の別サービスでの就業経験などを企業が把握できれば、採用時の判断材料が増え、面接の負担を減らせるのではないか、という話でした。
4. 気づき・学び
気づきを次の仕事で試す
文言変更で得た気づきを、次の実装前の準備に活かせたことは、自分にとって手応えがありました。小さく作ったものを相談に使い、相手の観点を聞いて方針を修正できたのも、今回試せたことでした。気づきを次の仕事で実践するところまで、インターンの中で経験できたと思います。
先回りして考えるための知識を増やす
レビューを通じて、実装前に何を疑問として挙げられるかは、自分の持つ知識にも左右されると感じました。
当初は、読み上げ用のラベルに、その要素が何を指しているのか明確であれば問題ないと思っていました。
デザインを反映するHIFI対応で、カードや削除ボタンのラベルに使っていたのは内部の管理番号でした。レビューで、番号では利用者に対象が伝わらないと指摘を受け、画面に表示する場所や職種などの条件内容と関連付ける形に修正しました。
また､ Figmaでは定義できない観点としてキーボードショートカット等が挙げられます｡ スマートフォン向けの条件詳細シートでは、レビューで指摘を受け､ Escapeキーで閉じる処理を追加しました。
既存APIや制約は事前にAIを使って調べていましたが、まとめて取得できるAPIがあることを､ レビューされるまで見落としていました。調査の指示や事前に共有した情報が十分ではなく、必要な情報を得られなかったのではないかと感じました。
具体的な手段を前提にAIへ相談したことで、調査もその実現方法に偏ってしまったのではないかと感じました。次は、解決したい課題や目的を整理する段階からAIと相談し、手段を決める前に選択肢を広げてみたいです。
今後は、調べたいことや前提をAIにどう伝えるかも見直したいです。アクセシビリティに加え、SEOやCore Web Vitalsの知識も深め、利用者の操作や表示方法について、相談の段階から確認事項や改善案を出せるようになりたいです。
プロダクトが目指す体験から考える
会社が描く将来像を初めて聞き、アカウントを必須にする理由に納得しました。プロダクトが目指す体験から個別の仕様を考えることも、エンジニアの役割なのだと感じた経験でした。
ユーザーが目的を達成できる状態まで届けるために、仕様の背景を知り、実装する範囲や順番を考える必要があると学びました。
5. 結果
当初、GREATと定義していた範囲まで完了できました。文言変更はマージまで進め、引き継いだPRのレビュー対応と設定画面のUI実装にも取り組みました。実装や範囲を選んだ理由を、具体例とともに説明するという目標も達成できたと思います。
一方、MOREとして定義していたB・Cの登録導線は実装計画書を残すところまでとしました。前任者のコードの理解やレビュー、計測、デザインやUIの状態の調整に時間がかかったためです。残りの期間では、実装方針と未解決の議論点を明確にしておくことが、次の開発に役立つと判断しました。
作業は分割できましたが、Aの設定画面だけでは、ユーザーが一連の操作を完了できませんでした。新しく条件を登録する入口がなく、登録してから条件を確認・管理するまでの操作が完結しなかったためです。ユーザーが一連の操作を完了できる範囲を考えて分けるところまでは、今回実践できませんでした。
スクラムイベントやチームの取り組みから、ユーザーにとっての成果を考える視点を学びました。どう分ければよかったのか、まだ答えは出ていません。プロダクトが目指す体験から開発の範囲を考えることを、今後の開発で身につけたいです。
6. おわりに
今回、小さく作って確かめる進め方をチームでも実践できました。次は知識を増やし、PdMやデザイナーに技術的な選択肢と理由を自分から示せるFEエンジニアになりたいです。参加前はぼんやりしていた目標が、実務を通じて具体的になりました。
これからインターンに参加する方にも、自分が普段使っている進め方を、実務で試してみてほしいです。私の場合は、試したことで活かせる強みと、これから考えたい課題の両方が見つかりました。
.png?fit=max&w=1920&q=75&fm=avif)