【インターン体験談】AI 時代の学生が、7日間の実務で知った個人開発との差

こんにちは。慶應義塾大学 4 年の中村颯です。ウォンテッドリーの Visit AI Squad というチームで、7日間のインターンに参加しました。

自己紹介

中村颯のプロフィール - Wantedly

自己紹介 Keio SFC | 合同会社Atture CEO | Rubyを母語とするエンジニア兼サービスデザイナー ...

https://www.wantedly.com/id/hayato1031

大学の所属は環境情報学部で、研究会のテーマは生成 AI のビジネス活用です。普段は、Web エンジニアとしてのインターンに通いながら、AI を使った個人開発でさまざまな大会にも出ています。

好きなことはサッカー観戦とディズニーで、中でも映画『ベイマックス』が好きです。そこからロボット等のプログラミングに興味をもったのが、プログラミングを始めたきっかけでした。いまは Web アプリを中心に、ときにはメディアアートにもはみ出しながら、ユーザーが楽しく使えるプロダクトを作っています。

はじめに

最近は AI を使えば、学生でも一人でそれなりのアプリを作れるようになりました。大学でも AI を使って実装することが前提になる場面が増えています。

しかし、大きなプロダクトを開発しようとすると、今でもチームで開発する必要があります。今回のインターンでは、転職 AI エージェントのアプリ Mendy の機能を 1 つ、要件定義から作りました。実務のチーム開発に入ってみると、個人開発にはない場面がいくつもありました。中でも大きかったのは、自分の書いたコードを人に説明する場面です。

このストーリーでは、7 日間でやったことを順に振り返りながら、個人開発との差として感じたことを書きます。

自己紹介
はじめに
インターンの概要
インターンで実施したこと
最初の2日間
3日目〜最終日
個人開発と実務の差
作りかけの機能を隠しながら、細かく出す
変更を出す順番を守る
判断の理由を残して、周りと揃える
レビューで気づいたこと
技術を理解しようとしたこと
おわりに

インターンの概要

今回のインターンは Mendy というプロダクトの開発チームに入り、1つの機能開発を行うものでした。

あなた専属の転職AIエージェント Mendy by Wantedly

エージェントとのやりとりを1か所に。届いた求人はAIが経歴と希望条件からマッチ度を診断。返信の下書きまでおまかせ。iPhone・Android対応、無料。

https://mendy.wantedly.com

新アプリ Mendy のアーキテクチャと技術選定 | Wantedly Engineer Blog

こんにちは、ウォンテッドリーで Visit AI Squad のリーダーと、Mendy のプロジェクトリードをしている市古（@sora_ichigo_x）です。はじめに2026年9月28日に、新...

https://www.wantedly.com/companies/wantedly/post_articles/1095924

私が参画した開発チームは Visit AI Squad というAI を使ったプロダクトを開発しているチームで、メンターは Squad リーダーの市古さんでした。

当時の Mendy の課題の1つに、気になった求人を残しておく手段がないことがありました。多くの求人が届く人は、一度開いた求人を見返すのに、一覧から探し直すしかありません。この課題を改善するために、求人に「気になる」を付けて、あとから見返せるようにする機能を任され、モバイルとバックエンドの両方を作りました。

インターンで実施したこと

最初の2日間

最初の2日間は、Mendy の開発に入るための準備と、メインのタスクの設計に使いました。

初日の目標は、Mendy を手元で動かすことです。社内ツールが手元の Mac で動かない、最新の Xcode が既存のライブラリと合わない、と何度か詰まり、そのうち1つは次に入る人のためにセットアップ手順へ対処法を足しました。

2日目には、小さな修正でコードに慣れてから、メインのタスクに入っています。まずモバイルのキャッチアップとして、ヘッダーの見出しの文字サイズをデザインに揃える修正を出し、レビューを受けてマージしました。メインのタスクは Mendy の今の動きを確かめるところから始めました。そのうえで、ユーザーの流れ、ワイヤーフレーム、機能の呼び方、API とデータの設計、実装の分け方までを、コードを書く前に決めて Issue に残しました。

3日目〜最終日

3 日目からは、2日目に分けたタスクに沿って実装を進めました。DB、API、一覧の画面、詳細の画面と、PR を分けて少しずつマージしていきました。途中でデザインが確定してからは、仮の見た目で作っていた画面を差し替えながら進めています。最終日に「気になる」機能をリリースして、インターンを終えました。

個人開発と実務の差

実装を進める中で、個人開発では意識してこなかったことがいくつもありました。

作りかけの機能を隠しながら、細かく出す

私はバックエンドを触ることが多く、フィーチャーフラグという仕組みを今回はじめて知りました。

リリース・デプロイ戦略を支える技術 | Wantedly Engineering Handbook

ここでは Kubernetes 上で起動する server や worker の deploy 戦略について説明します。ウォンテッドリーにおける Git 及び GitHub の運用方法が前提となるので事前にを読んでおくと良いでしょう。各 repository で CI/CD で下の２つのことを行うことで GitHub Flow を実現しています。ここで ci-build は commit hash を tag にもつ docker image を作成して registry に保管し、 deploy

https://docs.wantedly.dev/fields/infrastructure/deploy-strategy-implement#featureflag

一般的にフィーチャーフラグとは、コードを配信したあとでも、設定を切り替えるだけで機能を出したり隠したりできる仕組みのことです。作りかけの機能を隠しておくほかに、一部のユーザーにだけ先に公開したり、問題が起きた機能をすぐに止めたりするのにも使われます。

Mendy はモバイルアプリなので、マージした変更は、次にアプリを配信したときにユーザーに届きます。細かくマージしないと開発は速く進みませんが、細かくマージすると、作りかけの機能がユーザーに届いてしまいます。フィーチャーフラグを使うと、フラグが OFF の間は新しい機能が画面に出ないので、作りかけのままでもマージできます。インターンでは、このフラグの裏で PR を分けて、少しずつマージしていきました。

変更を出す順番を守る

DB とサーバーの変更は、PR を分けて、順番を守って出します。順番が逆になると、サーバーがまだない列を読みにいってエラーになるからです。個人開発では、こうした順番を意識したことがありませんでした。

判断の理由を残して、周りと揃える

個人開発では、画面の作りも機能の名前も、自分が決めればそれで済みます。今回は、「気になる」を付けた求人をどこで見せるか、外したときにどう見せるかといった判断を、理由と一緒に Issue に書き残し、周りと揃えながら進めました。

名前も、最初から「気になる」だったわけではありません。最初は「ブックマーク」と呼んでいましたが、デザイナーからもらった UI 案を見て、「気になる」に決めました。名前が決まるまでは、あとで書き換える前提で、仮の名前のまま実装を進めました。

また、デザイナーと一緒に作るのは、一人で AI と向き合うのとは違う面白さがありました。ユーザー体験にははっきりした正解がないぶん、AI ではなく人の意見を聞けることに意味があると感じています。

レビューで気づいたこと

個人開発では、自分で書いたコードを自分でマージすれば先に進めます。実務では、PR にレビューをもらったり、マージの前に市古さんとコードを一緒に見ながら口頭で説明したりする場面がありました。その中で、自分が使っている技術を理解しきれていないところが、いくつも見つかりました。

レビューでは、なぜそう書いたのかを説明する必要があり、理由は答えられても、その技術の中身までは説明しきれないことがありました。口頭で説明するときも同じで、話しているうちに、自分がどこを分かっていないのかが洗い出されていきます。インターンを通じて、技術を理解していることの重要さを痛感しました。

振り返ると、理解が必要だったのはレビューのときだけではありませんでした。一覧で「気になる」を外したときは、カードをすぐには消さず、次に一覧を取り直したときに消える見え方にしていました。この見え方は、アプリが一覧をいつ取り直すかに依存します。そこは分かったうえで仕様を決めていましたが、一覧のデータの取得とキャッシュを受け持つ Apollo Client の挙動までは知りませんでした。そのため、一覧を取り直すように設定を変えたところ、画面を戻るたびに一覧が短くなるバグが起きました。この挙動に気づけたのは、レビューで指摘してもらったからです。

仕様は、使う技術がどう動くかを前提に決まります。土台となる技術について知らないと、仕様を決める段階で、生じるリスクや不確実性に気づけません。仕様を決めるのも、レビューで説明するのも、判断について人と話すことが必要です。技術を理解していないと、その判断について人と話せないのだと感じました。

技術を理解しようとしたこと

技術を理解していれば、チームの人と共通のレベル感で話せます。相手と同じ水準になれるという意味ではなく、相手に合わせて話せるという意味です。インターン中は、使っている技術の中身を知ろうとしていました。

そう意識するようになったきっかけの一つが、インターンの期間中に開かれた今年の Kaigi on Rails です。私は昨年から、Ruby や Ruby on Rails のカンファレンスである RubyKaigi と Kaigi on Rails に参加しています。ちょうどインターンの期間中に今年の Kaigi on Rails が開かれたので、今回も参加しました。とても面白かった一方で、多くのセッションは、聞いてもまだまだ分かりませんでした。

開発では、Devin でリポジトリをまたいで調べて全体をつかみ、Claude には実装を手伝ってもらっていました。社内には、Kubernetes を使いやすくするための kube というツールがあり、開発環境はこれで支えられています。

kube | Wantedly Engineering Handbook

ここではウォンテッドリーの社内ツールである kube の概要について解説します。 kube というツール自体に着目し、Kubernetes やその運用方法については扱いません。この章をウォンテッドリーに存在する kube に関するルートドキュメントと位置づけます。したがって説明は概論にとどめて細かい利用方法などは他のドキュメントで保管していくものとします。現在各所に散らばる kube に関するドキュメントをこの章に集約している段階です。主に下のような人を想定しています。 kube はで管理されて

https://docs.wantedly.dev/fields/dev-tools/kube

kube のすごさは何度も聞く機会がありましたし、実際に使っていても何も気にせず使えていたので、中身が気になりました。そこで、手元で Kubernetes を試せる minikube を動かしてみたり、GraphQL や Ruby も学び始めたりしました。

ただ、理解するのは簡単ではありません。 minikube についても、手順どおりに全部動かしたあとで、言うほど理解できていないと感じました。朝会で minikube について話した説明が間違っていたことにも、あとで気づきました。それでも、自分で動かしてみたことは少し自信になりましたし、ドキュメントやコードを読むのは楽しい時間でした。 GraphQL も、学ぶ前よりすっきり説明できるようになっています。

概要をつかむだけなら楽です。技術が何なのかを分からないまま振り回すことは、いまは当たり前に起きています。だからこそ、中身を知ろうとする時間を取れたことは、このインターンでよかったことの一つです。