はじめに
はじめまして。京都大学工学部理工化学科3回生の小北隼都です。大学では有機化学と高分子化学を学びながら、授業外ではモバイルアプリやゲームを開発しています。趣味はテニスとラーメン巡りです。
今回、5日間のインターンシップで、求人情報サービスのモバイルアプリ開発チームに参加しました。担当したのは、Androidの求人検索一覧に、ユーザーに合ったおすすめ求人を横に並べて表示する機能です。
参加前の私は、目標から逆算して計画を立てることに苦手意識がありました。そこで、日ごとのゴールと進め方を自分で考えることを目標にしました。また、「誰のために作るのか」「なぜこの方法を選んだのか」を説明できる状態を目指しました。
最低限の要件は、最終ゴールから考える
求人を探すユーザーは、自分で設定した条件に合う求人を中心に見ます。しかし、条件から少し外れていても、実はその人に合う求人があるかもしれません。
そこで、検索結果の途中におすすめ求人を表示し、「検索結果を見る」から「おすすめ求人に気づく」、そして「詳しい情報を開く」という行動につなげることになりました。
もともとの課題には、画面表示、通信、追加読み込みなど、多くの内容が含まれていました。すべてを5日間で完成させれば、一つひとつの品質が下がる可能性があります。
参加前の私は、最低限のゴールだけを決め、早く終われば残り時間でできるところまで進めていました。しかし今回は、先に最終ゴールを決め、そこへ到達するために必要な課題を並べました。そのうえで、必ず完成させる範囲と、余力がある場合に挑戦する範囲を分けました。最低限の要件は感覚で決めるのではなく、最終ゴールから逆算した結果として見えてくるものだと学びました。
求人の取得タイミングについて
最初に、検索結果が5件以上なら5件目の後、少ない場合は一覧の最後へ、おすすめ求人を表示しました。
読み込み中は専用の枠を出し、取得できた場合だけおすすめ求人へ切り替えます。おすすめ求人がなかった場合や取得に失敗した場合は、その枠だけを表示しません。おすすめ機能の失敗によって、中心となる求人検索を邪魔しないためです。
おすすめ求人を取得するタイミングも検討しました。最初は、検索条件を設定する画面ですでに求人数が表示されていたため、その時点で取得すれば早いと考えました。
しかし、ユーザーは条件を何度も変えながら求人を絞り込みます。そのたびに取得すれば、使われない通信が増えます。また、条件を設定したまま画面を離れ、時間がたってから検索することもあります。その間に求人が終了したり、新しく追加されたりする可能性があります。
そこで、ユーザーが実際に検索結果を見る時点に合わせて取得する方法へ変更しました。
「ユーザーがいつ使うか」から考える重要性を学びました。最初の案を変えることは失敗ではなく、判断の精度を上げた結果でした。
AIを家庭教師として使う
今回参加したのは、多くの機能とコードから成る大規模なプロダクトです。インターンの5日間ですべてを理解してから開発を始めることは現実的ではありません。一方で、AIに実装を任せきりにしてしまうと、自分が変更したコードを説明できなくなります。
そこで、プロダクト全体を一度に理解しようとするのではなく、担当機能に必要な部分をAIと一緒に一つずつ読み解く方法を選びました。必要な範囲を素早く理解しながら、自分がすべての変更理由を説明できる状態を作るためです。
個人開発でもAIを使っていましたが、今回は課題を渡して一度に実装させる方法を取りませんでした。一つのファイルを変更するたびに、次の流れを繰り返しました。
1. そのファイルの役割を確認する
2. 何を、なぜ変えるのか説明してもらう
3. 複数の方法と、それぞれの良い点・悪い点を比べる
4. エンジニア向けの説明を聞く
5. 同じ内容を中学2年生向けに説明してもらう
6. 自分で方法を選び、実装後に確かめる
7. 納得してから次のファイルへ進む
技術を身につける力と説明する力は別物だと考えていましたが、説明を開発へ組み込むことで、二つを同時に伸ばせると気づきました。
難しい言葉を簡単に言い換えられなければ、まだ十分に理解できていない可能性があります。そこで、私の理解度テストに中学2年生を勝手に召喚しました。変更理由を先に言葉にしたことで、チームにも「何を、なぜ変えたのか」をすぐ説明できました。
この方法は地道です。しかし、理解しないままAIへ任せると、説明できないコードが積み重なり、将来の開発を難しくする「技術負債」につながります。後から読み直す時間まで考えれば、理解しながら進める方が結果として早いと感じました。
AIの回答もそのまま信じず、既存のコード、デザイン、自動テスト、実際の端末、通信の記録を使って確かめました。
AIは正解を決める人ではなく、選択肢と判断材料を整理してくれる家庭教師として使いました。
Issueが増えることは、後退ではない
一つの課題を解決しようとした結果、新しい課題が二つ見つかったこともありました。最初は「一歩進んで二歩下がっているのではないか」と感じました。
しかし、問題が新しく生まれたわけではありません。共通部品の使われ方や、読み込み中と表示後の高さの違いなど、見えていなかった課題を発見できたのです。
その場ですべてを直すと、ほかの画面にも影響が広がります。そこで、原因と影響範囲を整理し、別のIssueとして切り出しました。後続Issueは、できなかったものを置く場所ではなく、見えなかったリスクを管理できる状態にするものです。これは大規模開発ならではの経験でした。
デザインレビューでは、背景色がデザインとわずかに異なることも分かりました。機能を動かすだけでなく、早い段階からデザイナーと認識を合わせる重要性を学びました。
結果と、社員の方との会話から得た学び
最初に「ここまでは完成させる」と決めた範囲は、ほぼ達成できました。一方、デザイン上の要件を一つ見落としたことは悔しく感じています。
余力があれば挑戦する予定だった追加機能には、あえて着手しませんでした。中途半端な実装と引き継ぎコストを残すより、完成した範囲の品質を守る方がよいと判断したためです。
ただ、最後に少し時間が余り、「もう少し挑戦できたのでは」という心残りもあります。
次は、実装に必要な時間だけでなく、開発中に新しく見つかった課題を調べ、次に取り組める形へ整理する時間も計画に含めたいです。
限られた時間の中でも、どこまで実装するかだけでなく、どの課題を発見してチームへ残すかまで考えることを、次のアクションにします。 社員の方との会話の中では、Peopleマネジメントと技術力について伺いました。
「人との会話は質より量」という言葉が特に印象的でした。普段から話す回数を増やし、率直な意見や悩みを話せる信頼関係を作るという考え方です。
また、「技術力とは、新しい技術へ適応する力でもある」という話も印象的でした。一つの技術を深く学ぶだけでなく、新しいものを吸収し、自分で確かめながら使える力も必要です。
今回、AIを使った開発方法を試し、自分なりの使い方を作った経験ともつながりました。
全日対面だったため、分からないことを体感2秒で聞けたことも大きかったです。小さな疑問をすぐに解決でき、開発だけでなく学習の速度も上がりました。
5日間で一番成長したのは、機能を作る力だけではありません。ユーザーの行動から課題を考え、最終ゴールから逆算し、何を作り、何を捨てるかを自分で決められるようになったことです。
おまけ：ラーメンを食べて健康になろう
今回のインターンでは、「5日間、毎日ラーメンを食べる」という裏目標も立て、無事に達成しました。
開発では慎重にスコープを決めましたが、こちらは一切スコープアウトせず完遂しました。
5日間の丼顔を載せるので、どこのラーメンか分かった方は当ててみてください。なお、1日だけまぜそばが含まれています。
まぜそばはラーメンではないですが、本店なので今回はセーフとします。
（2日目の武蔵家中野本店さんは写真撮影禁止のため写真はないです。最高に美味しかったです。）
オフィスの下にライフがあるのも、個人的に嬉しかったです。くら寿司のびっくらぽんくらい嬉しかったです。
最後まで見ていただき、ありがとうございました！
