はじめに
はじめまして。名城大学情報工学部3年の上村彩音（うえむら あやね）です。
普段はFlutterを中心にモバイルアプリの開発に取り組んでいます。
9月7日から9月18日までの2週間、ディップ株式会社のインターンシップに参加し、バイトルアプリの大規模リニューアルに携わりました。
今回はKMP（Kotlin Multiplatform）やiOSの実装に取り組み、チームの皆さんと相談しながら、仕様の整理からレビュー対応までを経験しました。
iOSのネイティブ開発はほぼ初めての挑戦でした。
この記事では、2週間で取り組んだことと、開発やチームとの対話を通して得た気づき・学びを振り返ります。
インターンの目標
私は「ユーザー視点を持ち、技術の根拠を自分の言葉で説明し、対話しながら納得のいくプロダクトを形にするエンジニア」を目指しています。
チームに技術や実装方針を提案するときには、自分なりの根拠を持って説明したいと考えています。
この理想に近づくため、インターンでは次の目標を立てました。
- バイトルのアーキテクチャを一つでも理解する。
- PRの対面レビューで実装内容を説明し、承認をいただく。
- ユーザー視点に立った開発や企画の提案を一つ以上する。
特に、コードを読む力には課題を感じていたため、変更後のコードが動くことに加えて、「なぜその実装にしたのか」を理解することを意識しました。
取り組んだこと
主に取り組んだのは、応募確認画面で、ユーザーがキープしている求人を確認し、ほかの求人と一緒に応募できるようにする機能です。
最初に説明を聞いたときは、キープ求人を表示し、チェックを入れてまとめて応募できるようにする、表示と選択が中心の機能だと想像していました。
しかし実際には、既存機能との連携や、画面を移動した際の状態保持など、考慮すべき点が多くありました。
まず、親Issueの完了条件を整理し、sub-Issueに分割しました。
「キープ求人を見る」「求人の詳細を確認する」「求人を選択して一緒に応募する」といった、ユーザーの行動を起点に整理したうえで、KMP・Android・iOSの担当領域と依存関係を確認し、実装する順番を決めました。
仕様を詰める際には、表示できることだけでなく、操作の前後も考えました。例えば、同じ求人がキープとおすすめの両方にある場合にタップ元を区別できるか、詳細シートを閉じた後も一覧や選択状態を保持できるか、といった点です。
判断が必要な内容はメンターやチームの方、プロダクトオーナー（PO）に相談し、決定した方針と理由をIssueに残しました。
実装では、KMPの共通部分をペアプログラミングで進め、iOS側ではキープ求人の表示や既存の求人詳細シートへの接続に取り組みました。
また、レビュー対応では、指摘された箇所について「なぜその変更が必要なのか」を理解したうえで修正することを意識しました。
インターン期間中には、iOSDCにも参加し、ブースでの説明を経験しました。ほかのエンジニアの方との交流を通じて、技術の選び方や開発の進め方について、さまざまな考えに触れることができました。
ほかの開発者も迷いながら判断していることを知り、技術力には、コードを書く力に加えて、状況に応じて判断し、その理由を伝える力も含まれるのだと考えるきっかけになりました。
気づき・学び
1. 今考えるべきことを選び、行動につなげる
インターン前半は、仕様の背景や実装の理由を理解しようとする中で、考える範囲が広がり、作業に時間がかかることがありました。自分で納得して進めたいという思いがある一方、今のタスクに必要なことと、後から考えられることを十分に分けられていませんでした。
1週間目の振り返りでは、「分からないことを理解する姿勢や、自発的に学ぶ姿勢は強み」と評価していただきました。同時に、背景や目的を深く考えるからこそ、具体的な作業に落とし込む際にもすべてを考えようとしてしまうため、情報や作業の取捨選択が必要だとフィードバックをいただきました。
この言葉を受けて、後半は「今決める必要があることは何か」「今回の作業ではどこまで取り組むか」を意識するようになりました。また、自分の中だけで考えを固めず、「こういう意図で、この方針で進めようとしています」と途中段階で共有し、認識をすり合わせることを心がけました。実際に、仕様に迷った際に相談することで、相手と共通認識を持ち、自信を持って実装を進められると感じました。
この経験から、限られた時間でユーザーに価値を届けるには、考える対象やタイミングを選ぶことも必要だと学びました。深く理解しようとする姿勢を活かしながら、今必要な判断に集中し、周囲との対話を通して具体的な行動につなげていきたいです。
2. ユーザー視点とは何か
成果物レビュー会では、POやデザイナーの方に、2週間で取り組んだ機能を説明しました。その中で、求人カードに掲載する情報はテストを通して検討されていることや、デザインにはユーザーに取ってほしい行動を後押しする意図があることを知りました。
これまで私は、ユーザー視点を持つことを、「使いやすくする」「あったら嬉しい機能を作る」と捉えていました。今回の対話を通して、どの情報を、どのタイミングで、どのように見せるかも、ユーザーの判断や行動につながっているのだと気づきました。
さらに、行動を後押しする際には、それがユーザー自身の納得できる選択につながるかどうかも大切だと感じました。今回の機能でも、まとめて応募できることに加え、ユーザーが求人を比較し、納得して応募先を選べることを意識したいと思いました。
表示する情報やデザインの一つひとつに意図があることを知り、その奥深さを面白く感じました。エンジニアとしても、こうした意図を理解し、ユーザーにとってどのような意味があるのかを考えながら、仕様の検討や実装に関わっていきたいです。
3. AIを活用するためにも、自分で判断できる理解が必要になる
初めはアーキテクチャへの理解が浅く、AIが出力したIssueの分割案が適切か、自分では判断できませんでした。
開発ではKMPの共通部分とiOS・Android側の実装の役割を理解する必要がありました。しかし、その前提となるアーキテクチャの知識が不足していたため、まずMVC・MVP・MVVMの役割やメリット・デメリットを学び、処理の責務を分ける考え方から理解を深めました。
また、方針だけでなく、その判断に至った理由もIssueに残すようにしました。
仕様と判断の根拠が整理されていると、AIに意図を伝えやすくなり、出力されたコードを自分で読む際にも、何を確かめるべきかが明確になります。AIを活用するうえでも、自分が内容を理解し、判断するための準備が大切だと感じました。
目標の達成度
バイトルのアーキテクチャを一つでも理解する
MVC・MVP・MVVMの役割やメリット・デメリットを学び、実際の開発で処理の役割や実装方針を考えるための土台ができました。
一方で、バイトルで採用されているアーキテクチャが実際のコードにどう反映されているかについては、まだ理解を深める必要があると感じています。
今後は、学んだ知識と実際のコードを結びつけ、処理の流れや役割分担を自分の言葉で説明できるようになりたいです。
PRの対面レビューで実装内容を説明し、承認をいただく
「PRの対面レビューで実装内容を説明し、承認をいただく」という目標は、今回達成できませんでした。一方で、レビューを受けて修正する中で、自分だけでは気づけなかったコードの読み方や確認すべき観点を学びました。
今後は、学んだ観点を使って自分で差分を確認し、変更の目的や実装の理由を整理したうえで、レビューの場で自分の言葉で説明することに挑戦したいです。
ユーザー視点に立った開発や企画の提案を一つ以上する
開発中には、求人カードに表示されている項目について「どのような意図でこの情報を載せているのか」を質問したり、「こちらのデザインの方がよいのではないか」と改善案を伝えたりしました。
仕様やデザインについて疑問を持ち、改善案を自分から伝えられたことは、目標に向けた一歩だったと感じています。今後は、その提案によってユーザーにどのような利点があるのかまで、根拠を添えて伝えられるようになりたいです。
まとめ
今回、特に変化を感じたのは、実装に向き合う姿勢です。「なぜその実装にするのか」という技術的な根拠に加え、「なぜその機能が必要なのか」「ユーザーにどのような価値を届けたいのか」まで考えるようになりました。
また、自分の中だけで考え込まず、途中段階で意図や方針を共有することが、納得して開発を進める助けになると実感しました。
目指していたエンジニア像を、実際の開発経験を通して以前より具体的に捉えられた2週間でした。今後も、深く理解しようとする姿勢を大切にしながら、今必要なことを選び、周囲との対話を通してユーザーに価値を届けられるエンジニアを目指していきたいです。
最後に、2週間にわたり支えてくださったメンターやモバイルチームの皆さま、そしてインターンシップを通じて関わってくださったすべての皆さまに、心より感謝いたします。
