こんにちは！飲食プロダクト開発4G のフロントエンドチームでインターンシップをしていた、筑波大学システム情報工学研究群 M1 の野牧 樹です。

普段は個人開発で Web やコンパイラを作ったり、研究でプログラミング言語ランタイムを作ったりするなど、高いレイヤから低いレイヤに至るまで幅広く興味があるような人です。

私は RECRUIT INTERNSHIP for Engineers 2025 の第1タームに参加させていただき、主にモバイルオーダーのフロントエンドの幅広い改善を行っています。執筆時点では飲食領域に関するインターンシップ参加記は見当たらなかったので、新しい有益情報として、本インターンシップへの参加をご検討されている方々への一助となれば幸いです！

『Airレジ オーダー』モバイルオーダーとは

先ほどから『Airレジ オーダー』や「モバイルオーダー」などと当たり前のように使っていますが、まずはそれらについて簡単にご紹介したいと思います。

『Airレジ オーダー』とは、飲食店などでの注文業務を支えるプラットフォームの総称で、例えばフロアの方が注文を受けるための端末（ハンディ）やキッチンの中で注文の表示などをするための端末（キッチンモニター）などから構成されます。特に「モバイルオーダー」は、テーブル上の 二次元コードをお客様自身のスマートフォンで読み込むことで注文を完結させるシステムを指します。

公式サイトを見ていただくと、より詳しくモバイルオーダーについて知っていただけると思います。

技術スタック

モバイルオーダー自体もいくつかのシステムによって構成されます。そのため一概には言えませんが、今回は私がメインで携わった部分である、お客様のスマートフォン上で動作する注文アプリに焦点を当ててご紹介します。

• フロントエンド：React +TypeScript, Redux, Jotai, msw, Jest
• バックエンド：Spring Boot + Kotlin
• CI：GitHub Actions (Enterprise)

チームの雰囲気

とても賑やかで、温かさがあふれているように感じます。
私自身、約1ヶ月ととても短い期間の在籍ですが、それでもあっという間に打ち解けることができ、気兼ねなく質問や会話をできるようになりました。私の所属する飲食4G自体が毎週金曜日を出社推奨日にしているのもあり、社食や近隣の飲食店でランチをする機会も比較的多いです。出社日があることで、対面でのコミュニケーションも取りやすいと感じました。

業務でのコミュニケーションという側面に関しては、互いの認識を常に一致させておくことをとても大切にしているように感じています。どの方も一区切りついたタイミングで相手に違和感がないかを尋ねられているので、誰ひとりとして取り残されない議論が進められていることに驚きました。質問や相談のハードルを下げるための場として、Google Meetに常時接続しておく文化があるのですが、ここにもそのような風土が現れているように思います。

インターンシップで取り組んだこと

ひとくちに改善と言っても設計や実装、運用などさまざまなものがあります。ここでの改善はその全てを指しますが、最終的な達成目標は「未知の課題を見つけ、その改善策を提案すること」でした。すなわち、ある課題を完全に改善するところまで持っていかなくとも、改善するに足る方針を明確にしておくことが求められました。

案件ではなく、なぜ改善をすることにしたのか

本インターンシップに参加される方々の多くは、案件という形で新しい機能の設計から実装までをされている印象があります。そんな中、私は「改善」という、あえて案件ではないことを行っていくことになりました。これには次のような理由があります。

• 案件というある意味ではゴールが決まっているものではなく、改善のような方針が明確でないタスクに取り組むことで、より大規模なプロダクトに対する思考を深めたかったから

• エンジニアリングを通して社会に貢献したいという動機から、自身の経験が最も活きる可能性を感じたから

このような私の意向を汲み取っていただき、さまざまな大きさの改善タスクに取り組んでいくことになりました。

序盤で行ったこと

プロダクトそのものや設計・実装・運用などについて知らない状態でチームにジョインして、いきなり改善を提案することは難しいものです。そのため、まずは「課題感や方針が明確な改善タスク」に取り組み、手を動かしながらプロダクトを理解していくところから始めました。

具体的には、ある編集画面 A ではデータの編集を行った状態でページ遷移を行おうとした際、ページを離脱するかどうかを確認するモーダルが出るのですが、ほかの編集画面 B, C ではそれが出てこないという問題の解決です。この過程で数十行のプログラムを書き、PR を出しつつ、QAチームの方とのコミュニケーションを図りました。2, 3 日かけてこのタスクに取り組み、プロダクトの全体像を理解していきました。

中盤（メイン）で行ったこと

メインで行った改善タスクは「課題感は漠然としていて改善方針は未定」という特性がありました。具体的には、モバイルオーダーのフロントエンドではクリーンアーキテクチャを採用しているのですが、そのリポジトリ層のUT（ユニットテスト）が不完全であるというものです。

このタスクの難しさとして、答えがないという点が挙げられます。漠然と「リポジトリ層でドメイン構造とリクエスト・レスポンスの構造を変換する際、リクエストへの変換がうまくテストできていない」という認識がチーム内であったようですが、実際にはメンバー各々の認識や課題感に差異がありました。したがって、さまざまなメンバーの意見を聞いてまとめ、課題を明確にするところから始めました。最終的なゴールは、各メンバーが納得できる改善策を提案することです。

私は大学院ではプログラミング言語を専門としており、多少の知識があります。それを活かし、プログラム言語論的な視点やWeb フロントエンド開発に関するさまざまなべき論などからこの問題について検討し、チーム内での2回の議論を経て、最終的には3つの課題と5つの解決方針にまとめました。解決方針についてはそれぞれ詳細な手法を考え、それぞれのメリット・デメリットを比較する形で検討を行いました。その中のひとつに関してはPoCとなるプログラム修正を施しPRとして提示しています。

全体を通して行ったこと

タスクを進めるにつれ、達成目標でもある「未知の課題」を複数見つけ出すことができました。例えば CI 上でのeslint実行が遅いという問題を見つけ、これは全てのファイルではなく差分のあったファイルのみをチェックすることで解決できるというようなことを提案しました。ほかにも4, 5つほどの改善の提案を行っています。

インターンシップを通して意識したこと

今まで述べた通り、私は「改善の提案」をテーマにインターンシップを遂行してきました。それを通して、常に What だけでなく How を示してきました。つまり手法だけでなく、実際に改善を進めるための計画の提示です。これにより、より改善が現実的なものになるため、遂行可能性を飛躍的に高めることができます。とはいえ、これは最初からできていたのではありません。途中でチームの方にご指摘を受けて意識して進めるようになりました。

またリクルートには「圧倒的当事者意識（ATI）」という文化があります。誰もが場の当事者であり、常に積極的な姿勢を求められます。私もこれを意識し、ミーティング中に発言するようなことも行いました。

インターンシップを通して学んだこと

私はインターンシップに参加するまで、将来に対する漠然としたビジョンはあったものの、それをうまく言語化できていませんでした。加えて自分にはどのような強みがあり、どこが弱いのかもよく理解していませんでした。

これに関して、私は本インターンシップを通して、エンジニアリングをきっかけにして自己理解を深められたと感じています。例えばメンターや人事の方とのよもやま（1on1）を通して、拡散性が高いことに気がつきました。つまり、興味や話題が発散しがちになるということです。反対に、それなりに論理的に説明できる力があることにも気がつけました。

このような気づきの背景には、リクルートのよもやま文化があります（詳細はこちらの記事をご確認ください！）。人事の方をはじめとして、どの方も言語化能力が高く、自分がどうであるかを常にフィードバックしてくれるような環境が学びにつながったと感じています。

もちろんエンジニアリング的な学びも大きかったです。リクルートならではの超大規模アプリケーションを開発運用するための、スクラムやテストの手法を現場で直に浴びるように学ぶことができました。また、データセンターを見学する機会があり、それを通して事業会社としての規模も実感させられました。深い思考に基づいて議論を交わし、自分なりの解を見つけ、提案し、実行するという体験は確実にエンジニアとしての力になったと思います。

まとめ

本インターンシップは、エンジニアリングを通して自分自身への解像度を高められる、就活を始めたての方には非常に価値のあるものだと思います。大規模アプリケーションの開発だけではない経験が得られる RECRUIT INTERNSHIP for Engineers、おすすめです！