はじめに
初めまして！名城大学理工学部メカトロニクス工学科3年生の東出涼太郎(ひがしで りょうたろう)です。
Android領域を中心に開発をこなっており、多くのハッカソンにも参加してFlutter,ReactNative等を用いたモバイルアプリ開発に取り組んでいます。趣味は音楽で名城大学應援團吹奏楽部にてトランペットを吹いたりしています。
今回は2026年9月7日から9月「ソリューション開発本部プロダクト開発統括部プロダクトソリューション部」のインターンシップに参加し、求人情報サイト「バイトル」のKMPを用いた大規模リニューアルに携わりました。
インターンの目標
今回のインターンでは、「チームの熱量とユーザーの課題をつなぎ、共創を通して本当に求められているものを実装し切るエンジニア」を目指しました。この理想像の背景には、ハッカソンでの経験があります。要件を検討する中で、議論の主語が「自分たちが作りたいもの」から「ユーザーが必要としているもの」へ変わっていく過程に、面白さを感じました。また、リーダーとしてプロダクトの目標設定、デザイナー、バックエンドの意見を聞き、成果物に反映していく作業をしていく経験をしてきました。さらに他社のインターンシップでは企画、ユーザー利用の数字に基づいて事業を提案するインターンシップに参加し、ユーザーと企画の両方の課題を解決していく考えを学びました。
これら経験から、私はユーザーの課題を起点に、チームで考えながら実装を進められるようになりたいと考えていました。
ここでこのビジョンを実現するためにインターンでは、特に二つのことを意識しました。一つは、その機能が誰のどんな不便を解決するのかを考え、理由を持って仕様を判断することです。もう一つは、わからないことや迷っていることを言語化し、相手が判断しやすい形で相談・共有することです。
取り組む中での課題・工夫・判断
今回取り組んだのは、応募確認画面のおすすめ求人の上に、ユーザーがキープした求人を表示する機能です。応募に進んだタイミングで以前気になった求人を思い出し、追加の応募候補として検討しやすくすることを目指しました。 私はAndroid側の仕様検討と実装に取り組み、iOS側との仕様や挙動のすり合わせも経験しました。
「キープした求人を表示する」と聞くと、画面に一覧を追加する作業に思えるかもしれません。しかし、実装を進めるには、いつ求人を取得して表示するか、候補がない場合や取得に失敗した場合にどう振る舞うか、ユーザー情報を更新したときに表示や選択状態をどう扱うかなど、多くの判断が必要でした。
また、それぞれの判断をAndroid側で実装するだけでは、OSをまたいで同じ体験を提供できるとは限りません。iOS側と実装を比較する中で、仕様の解釈や挙動の違いを確かめる必要性にも気づきました。
一つの機能にも、多くの決断が必要だった
「応募確認画面にキープ求人を表示する」という機能でも、実装に入ると細かな判断が必要でした。求人を取得するタイミング、キープとおすすめの結果を反映するタイミング、取得に失敗した場合の表示、ユーザー情報を更新した後の選択状態などです。
最初はユーザーのためになる選択肢を広く考えていましたが、選択肢が増えるほど決めることも増え、仕様検討に時間がかかりました。ある仕様を選んだことで新たな検討事項が生まれ、別のIssueで扱う予定だった内容まで実装範囲が広がることもありました(その結果、AIとの対話の中で自分がした決断は少なくとも79回もありました)。この経験から、ユーザーへの価値を考えることに加えて、「今回の機能として、どこまでを決めて実装するか」を明確にする必要があると感じました。
判断材料を整理し、具体的な場面から考える
仕様を決める際は、前提条件、ユーザーへの影響、実装側のメリット・デメリット、これまでの決定を変更できるかを整理するようにしました。例えば、求人候補の取得に失敗した場合には、キープとおすすめを一括で非表示にするのか、取得できた側を残すのかという選択があります。ここでは、取得できた情報をユーザーに届けることを考え、成功した側は表示する仕様にしました。
情報更新時の扱いも、操作の場面によって判断しました。プロフィール編集から戻った場合は全体を取得し直し、追加選択をリセットします。一方、確認画面内で生年月日を保存する場合は、表示済みの候補や選択を保持します。「情報を更新する」という共通点だけで決めず、その操作の前後でユーザーが何を続けたいかを考えました。
しかし、判断材料を整理しても、すぐに決断できるわけではありませんでした。さまざまな視点から検討するほど、それぞれの案に利点が見つかり、どれを選ぶべきか迷うことが増えました。中間面談では、この「いろいろ検討すると、かえって決められなくなる」という悩みを相談しました。
その相談をきっかけに、すべての案の良さを一つに取り込もうとするのではなく、「それぞれの仕様が、どんな場面で有効になるのか」を考えるようにしました。今回の場面で優先することを明確にし、その条件に合う案を選ぶという考え方です。採用しなかった案についても、どのような状況なら有効なのかを整理するようにしました。
この考え方によって、「なぜ今回はこちらを選ぶのか」を説明しやすくなりました。選択した案の利点に加え、それが有効になる場面まで示せることで、自分の判断に説得力が生まれ、決断にも自信を持てるようになりました。
完了条件を自分で持ち、AIに照合を任せる
何度も仕様を検討していると、その決断が新たな決断しないことを生み、実装範囲が意図せず広がってしまうことはあります。その実装範囲の広がりを防ぐため、当初はAIに「Issueが肥大化していないか」と確認していました。しかし、確認の基準が曖昧なままでは、後続Issueの範囲に踏み込んでしまいました。
そこで、Issueの完了条件を明示し、「この条件に含まれない対応はどれか」と照合する方法に変えました。基準は自分が持ち、その基準と実装を比較する作業をAIに任せる分担です。この方法に変えてからは、今回必要な対応と、後続へ送る対応を整理しやすくなりました。検討中に見つかった対応の中には、機能全体に必要なものもあります。その場合は、必要になった理由を共有し、別のIssueや申し送りとして残すようにしました。
iOSとの比較で、仕様を共有する難しさに気づいた
KMPの実装ではiOS,Android,KMPの3つの層があります。KMP層でロジックを定義してデータを流し、それをAndroid層、iOS層のそれぞれで受け取るといった具合です。
成果物レビュー会の準備では、AndroidとiOSで実装に違いがあることが分かりました。また、Issueのコメントを参照しているのにも関わらず、実装漏れがあることも判明しました。同じ機能に取り組んでいても、細かな条件や状態の扱いまで一致しているとは限らないことを実感しました。
例えば、仕様資料にも、生年月日が未保存の場合に候補取得を待つかどうかや、プロフィールの部分更新中にローディングを表示するかといった違いがあります。こうした差を確認するには、完成した画面だけでなく、どの操作をきっかけに、どの順序で状態が変わるかまで比較する必要があります。
確認方法として、互いのOSの端末で操作してみる案が挙がりました。また、機能が一つ完成した段階で、それぞれの実装状況を整理して比較する機会も必要だと感じました。今回の経験を通して、仕様を決めることと、その判断をチームで共有できる形にすることは、つながった作業であると学びました。自分の実装を進めるための判断を、他の人も確認・比較できる情報として残すことが、共通のユーザー体験をつくる土台になると感じています。
インターンを通して得た気づき
決断するには、その仕様が生きる場面を考える
今回の開発を通して、一つの機能を実現するまでに、多くの決断が必要だと実感しました。表示内容だけでなく、取得のタイミング、失敗時の動作、情報更新後に保持する状態など、ユーザーからは見えにくい部分にも判断がありました。
当初は、さまざまな視点を取り入れるほど選択肢が増え、決められなくなることがありました。中間面談をきっかけに、「それぞれの仕様が、どんな場面で有効になるか」を考えるようになり、今回の状況に合う案を選びやすくなりました。
採用しなかった案についても、有効になる条件を整理することで、選んだ理由を説明できるようになりました。決断への自信は、判断の根拠と、それが成り立つ条件を言葉にすることから生まれると感じています。
判断を共有し、実装で確かめるところまでが必要だった
自分の中で理由を持って仕様を決めても、その意図や条件がチームに伝わっているとは限りません。AndroidとiOSを比較した経験から、同じ機能名や説明を共有していても、細かな場面で挙動に差が生まれることに気づきました。共通のユーザー体験を実現するには、何を作るかに加えて、「どの状況で、どう動くべきか」を共有し、実際の動作と照らし合わせる必要があります。今後は、機能が一つできた段階で確認する場を設け、判断した内容を両OSで比較できる形に残していきたいです。
ユーザーのために考えたことを、完成につなげる
ユーザー視点で考えるほど、改善したいことや必要な対応が見つかりました。その一方で、すべてを一度に扱おうとすると、実装範囲が広がり、完成までの見通しが立ちにくくなりました。完了条件を明確にし、後続の対応を切り出す経験を通して、今回完成させる範囲を決めることも、ユーザーに価値を届けるために必要だと学びました。AIを使う際も、自分が判断基準を持つことで、確認や整理を任せやすくなりました。
私が目指しているのは、チームの熱量とユーザーの課題をつなぎ、求められているものを実装し切るエンジニアです。今回の経験を通して、そのために必要な行動が、以前より具体的になりました。これからは、理由を持って決め、その判断を共有し、ユーザーが触れる動作まで確かめることを大切にしていきたいです。
まとめ
今回のインターンでは、キープ求人の表示機能の開発を通して、一つのユーザー体験を形にするまでに多くの判断が必要なことを実感しました。仕様に迷い、実装範囲を広げすぎることもありましたが、そのたびに相談やレビューを重ね、自分の判断を見直すことができました。
特に印象に残ったのは、自分で納得して決めた仕様も、チームで意図を共有し、実際の動作を確かめて初めて、共通の体験につながるということです。今回得た学びを今後の開発にも活かし、ユーザーの課題に向き合いながら、チームで実装を最後まで進められるエンジニアを目指していきます。仕様検討から実装、レビューまで支えてくださったメンターやチームの皆さま、一緒に考えながら開発を進めたインターン生の皆さま、ありがとうございました。
