「なぜこの実装なのか」を説明できるエンジニアへ。求人サービスのフロントエンド開発で学んだこと

「なぜこの実装なのか」を説明できるエンジニアへ。求人サービスのフロントエンド開発で学んだこと

はじめに

はじめまして、愛知工業大学工学部3年次生の樋口陽輝です。私は求人情報サイト「バイトル」のWebフロントエンド開発に携わりました。

今回取り組んだのは、検索結果ページの改善と、新着求人を知らせるメール設定画面の実装です。どちらも最初は小さな画面・条件分岐の変更に見えました。しかし実際には、ユーザー体験、検索エンジン、既存システム、モバイルアプリなど、複数の前提を踏まえて判断する必要がありました。

この記事では、実装した機能の紹介だけではなく、課題が曖昧な状況でどのように考え、周囲と相談し、判断の根拠を作ったかを振り返ります。

インターンシップで設定した目標と理想像

初日に掲げた理想像は、「ユーザーの困りごとや原因がまだ定まっていないときに、考える切り口や仮説を提案できるエンジニア」です。

個人開発では、自分で決めた仕様を自分で実装することが多く、「なぜこの実装にするのか」を他者へ説明する機会は限られていました。今回は、単に動くコードを書くのではなく、技術的な判断の理由を根拠とともに説明し、関係者と納得感のある合意をつくってから実装することを目標にしました。

取り組んだこと

1. 存在しない検索結果ページをどう扱うか

検索結果の件数を超えたページ番号をURLで直接開くと、存在しないページにもかかわらず、HTTPステータスは200のまま「検索結果がありません」というページが表示される状態がありました。古い共有リンクなどから訪れたユーザーが、実際には求人が残っていても「求人がなくなった」と誤解する可能性があります。

検索エンジンにとっても問題があります。本来、検索結果の2ページ目を表すURLが、対象の求人が存在しない場合にも正常なページとして返るためです。URLそのものの意味が変わるのではなく、**URLが示すはずの検索結果ページ**と、実際に返すHTTPステータス・空のコンテンツが一致しません。このようなページは検索エンジンからsoft 404として扱われ、インデックスから除外される可能性があります。また、存在しないURLのクロールにリソースが使われることで、実在する検索結果ページのクロールや更新反映に相対的な影響が出る懸念もあります。

対応として、エラーページを返す、最初または最後の検索結果ページへ移動させる、状況により使い分ける、という選択肢を比較しました。URLの意味を保てること、既存の挙動との一貫性、仕様とテストを複雑にしないことを優先し、存在しないページはエラーページとして返す方針にしました。

しかし実装を進めると、ページ数の計算には通常の求人だけでなく、条件によって表示される案内枠も関係すると分かりました。閲覧する地域や検索条件によって、1ページに入る通常求人の件数が変わり得るためです。最初は件数を一律にすれば解決できると考えましたが、それでは一覧の見た目や「次のページがある」と気づけるかどうかにも影響します。SEOに詳しい方やデザイナーと相談し、URLの種類ごとに表示件数とページ数の判定をそろえる方針を決めました。

すべての環境で完全に同じ見た目にすることよりも、主要な利用環境で一覧の見やすさを保ち、ページの有無を一貫して判断できることを優先しました。具体的には、国外からのアクセス時や一部の検索条件でのみ、見やすさが損なわれることを許容する実装としています。

この経験から、小さな条件分岐でも「誰の、どの状態が変わるか」を先に洗い出す重要性を学びました。特に、SEO上の正しさ、一覧の見やすさ、国内外の利用状況を分けて考え、何を優先し、どの利用環境でどこまでの見た目の差を許容するかを決める視点が増えました。

また、用意されたデザインや既存の表示件数を、そのまま絶対の前提として扱わないことも学びました。デザインを守ることは重要ですが、デザインが成立している前提と、変更によって失われる体験を確認しなければ、画面単体では自然に見える変更でも、プロダクト全体では不自然になる可能性があります。技術的に最も単純な実装が、必ずしもプロダクトにとって最適とは限りません。

2. 新着求人メールの設定を「読める情報」として表示する

設定情報を取得するAPIは、画面に表示できる文章ではなく、検索条件を表すコードを返します。場所、職種、勤務条件などをユーザーが確認できる形にするには、コードと表示名を対応させる複数のマスタデータを参照し、意味のある条件へ組み立て直す必要がありました。

さらに、検索条件には階層構造があります。広い地域を選択しているのに地域名が細かく並んだり、職種グループをすべて選択しているのに個別職種が並んだりすると、ユーザーは自分の設定を確認しづらくなります。そこで、下位項目がすべて選ばれている場合は上位のまとまりとして表示し、詳細な地域名を取得できない場合は親の地域へ勝手に広げて表示しないことにしました。

また、既存システムやモバイルアプリと比較すると、対象サービスや表示名に差がありました。画面側で取得後に対象外の条件を除外するのではなく、取得リクエストの時点で必要な設定だけを指定する形に変更しました。不要な変換やマスタ参照を避けながら、Webとアプリの対象範囲・表示基準をそろえるためです。

APIレスポンスを画面に表示する仕事は、コードを文字列へ置き換えるだけではありません。「ユーザーは何を設定したつもりなのか」「既存の設定をどこまで正確に見せるべきか」「他クライアントとどこをそろえるべきか」を考え、データをユーザーの理解できる単位へ戻す必要があると学びました。

画面デザインに「場所」「職種」「その他」という領域が用意されていても、そこへデータを当てはめるだけでは足りませんでした。APIが返す値、既存の検索条件、階層構造を確認し、画面に求められる情報と一致しているかを確かめる必要があります。与えられた仕様やデザインを実装の出発点にはしても、その成立条件まで確認する視点を持つようになりました。

3. レビューを通して、設計の判断基準を言語化する

レビューでは、変換処理をなぜ専用の機能単位に置くのか、データ取得処理と変換処理の責務をどこで分けるのか、型を共通化する基準は何か、といった設計判断について質問を受けました。

最初は「分けた方が読みやすい」「既存実装に近い」と感覚的に考えており、自分の言葉で十分に説明できない場面がありました。調べ直した結果、データ取得処理は認証・通信・エラーを担当し、変換処理は取得済みデータを検索条件として解釈・組み立てることを担当する、と整理しました。また、複数の変換処理から使う型は共通化し、特定の処理でしか使わない型はその処理の近くに置くことにしました。

レビューを通じて、設計は「正解らしい構成」にすることではなく、責務、変更の影響、テストしやすさ、再利用性で比較し、その理由を共有できることが大切だと学びました。コード品質は、動作や一時的な読みやすさだけでなく、次に変更する人が責務と変更範囲を把握し、安全に保守できることまで含むと捉え直しました。自分で答えられず調べながら返信した経験から、実装時の判断がまだ粗かったことも理解できました。

4. 実装の外側まで含めて、設計を考える

レビューでは、実装そのものだけでなく、その後の運用や依存先への影響についても質問を受けました。

一つは、既存システムとの差分やテストの意図を残すために作ったドキュメントについてです。「なぜこの場所に置くのか」「例外的なドキュメントを作ったとして、今後も正しく更新されるのか」と問われました。私は判断理由を残すことだけを考えていましたが、誰が・いつ・何を更新するかまで考えなければ、将来はかえって認識のずれを生むと気づきました。

また、マスタにない値をそのまま表示するフォールバックについても、「その状況が発生したことを開発者は検知できるのか」と問われました。ユーザーに誤った情報を見せないだけでなく、想定外のデータを検知し、後から調査・改善できる状態にする視点が必要でした。

さらに、複数のAPIやマスタを参照する設計では、ユーザーの待ち時間だけでなく、API提供側の負荷も考える必要があります。通信回数、データ量、並列性、重複取得に加え、最小の条件と最大の条件でどこまで増えるかを確認する必要があると学びました。画面が表示できるかだけを見ていた自分にとって、依存先のシステムまで含めて評価する視点は新しいものでした。

これらの質問から、設計とは画面を正しく動かすためだけのものではなく、変更後に正しく運用され、想定外が起きたときに開発側が気づけて、依存するシステムにも無理をさせないためのものだと捉え直しました。個別の対応を増やすだけでなく、継続して扱える仕組みにできるかを考えるようになりました。

おわりに

今回のインターンシップで最も大きく変わったのは、「なぜこの方法なのか」と問われたときに、結論ではなく判断の過程を説明しようとする意識です。SEO、利用環境ごとに許容できる差、デザインの成立条件、将来の保守性、運用を支える仕組みまで、画面の実装前後で確認する視点が増えました。

今後は、何を改善したいのか、他にどのような選択肢があるのか、何を優先し何を許容するのかを先に整理します。責務、利用者にとっての意味、既存システムとの整合、性能といった判断基準を添えて提案することで、初日に掲げた理想像に近づいていきたいです。