1ヶ月の Tapple インターンで掴んだ 4 つのこと

はじめに

はじめまして。金沢工業大学 情報工学科 2 年の高岡己太朗です。

大学では Android 開発を中心に個人開発やインターンに取り組んできました。

Android の開発歴はおよそ 2 年になります。

今回、CA Tech JOB を通じてサイバーエージェントの Tapple に参加しました。

この記事では、読者の皆さんに持ち帰ってもらいたい 4 つのテーマ を軸にお伝えします。

• 自走力の定義

• インターン生の立場で意見を言う技術

• 迷ったときの思考法

• Tapple の魅力

インターンの概要

期間は 2026 年 3 月 3 日から 3 月 31 日までの約 1 ヶ月間です。

担当した施策は主に 2 つ。メッセージ送信取り消し機能、あしあと機能です。

いずれもユーザーに直接届く機能であり、実装だけでなく仕様の議論やログ設計にも深く関わりました。

【図表：インターン期間中の定量データ】

項目

数値

PR 数

24 本 ( 内マージ 22 本 )

追加行数

1,724 行

レビューコメント

84 件

関わった社員数

42 名

ランチをご一緒した社員数

25 名

施策詳細

• 送信取り消し施策：Tapple アプリのメッセージ機能に送信取り消し機能の実装

• あしあと施策：Tapple アプリに自分のプロフィールを見た人がわかる機能の実装

自走力の定義

メンターの 池津 さんから「この1ヶ月で何を達成したいか」と聞かれ、自走力を挙げました。

しかし、「自走力」とは何か。漠然とした状態でした。

そこで、池津 さんとの対話の中で、自走力を2段階に分けて定義しました。

自走力の定義

• Lv 1

• 1 人で実装・工数見積もり・提案ができる

• レビューを根拠持って行う

• 質問の際、自分の考えを持ち、判断ができる

• Lv 2

• その人が居ればチームがスムーズに回る

• チーム全体の視点と担当職種の視点の 2 つから意見ができる

• チーム全体でのボトルネックを見つけ、解消する方向に働きかける

この定義は、自分の現在地を測る物差し として非常に有効でした。

この 1 ヶ月では、まず Lv 1 の到達を目指し、さらに Lv 2 へ向かう一歩目として Lv 1.2 を目標に設定しました。

• 自分のAndroid実装だけでなく、チームとしての浮き玉を見つける

• チーム全体がスムーズに前に進めるように働きかける

これらができた時、Lv 1.2 に到達を実感しました。

「チームの中で自分がどう動けばプロジェクトが前に進むか」を考える視座はとても大事な技術だと身をもって感じました。

インターン生の立場で意見を言う技術

「インターン生が仕様に口を出すのは差し出がましいのではないか」

「正解を持っている人に聞く方が効率的」

提案をする時、僕は上記の 2 つの懸念を感じていました。

しかし、チームメンバーとして所属している以上、提案をする必要があります。

メンターにも相談しつつ、解消しようと取り組んだ結果、2 つのことが大事だとわかりました。

伝え方の選択をできるようになる

これは、「インターン生が仕様に口を出すのは差し出がましいのではないか」という懸念の解消法です。

意見の中身以前に、コミュニケーションの方法で印象は大きく変わります。

• オフラインとオンラインは、緊急性や相手の状態を見て使い分ける。

• チャットではテキストだけだと背景が伝わりにくいので、コードブロックや見出しを使って構造化する。

• Slackではリアクションだけで済ませず「ありがとうございます」とテキストで返す。

こうした小さな丁寧さの積み重ねだけで、差し出がましく映るリスクは大きく軽減されます。

担当範囲のコードを誰よりも調べる

これは、「正解を持っている人に聞く方が効率的」という懸念の解消法です。

全コードを把握するのは無理でも、今の施策で関わるページや機能の影響範囲は、議論の前に徹底的に読み込みました。

ドメイン知識や歴史的背景では社員に負けます。それは当然です。

しかし、「現状のコードがどうなっているか」だけは誰にも負けない状態を目指しました。

そうすると「現状はこうです」「この実装だとこうなります」と根拠のある発言ができるようになります。結果として、「聞いた方が早い」ではなく「自分の意見を言った方が議論が前に進む」という状態に変わっていきました。

インターン生という立場だから意見を言えない、ということはありません。

伝え方を整えて、コードという事実を握る。この 2つを行うことで、インターン生でも対等に議論に参加できると学びました。

迷ったときの思考法

約1ヶ月の開発の中で、何度も「どちらの実装にすべきか」「この設計で合っているのか」と迷う場面がありました。その中で得た最大の気づきは、迷いは深掘り不足 だということです。

迷いには2段階の構造があると思っています。

まず、各選択肢のトレードオフを十分に調査できていない段階。メリット・デメリットを徹底的に洗い出せば、大抵はどちらかに倒せます。

それでも判断できないなら、一段上の前提「そもそも何を実現したいのか」の理解が甘いということです。

KMP関連の設計で迷ったとき、メンターの 池津 さんに「なぜ迷っているのか」を言語化するよう促されました。

整理してみると、迷いの原因は選択肢の多さではなく、トレードオフの調査不足でした。さらに掘り下げると、そもそもの設計意図への理解が浅かったことに行き着きました。迷いの正体を突き止めれば、やるべきことは明確になります。

ただし、インターン生には背景知識の壁があります。社員と同じ精度でトレードオフを判別するのは現実的には難しいです。だからこそ、自分の中で最大限調べて考えた上で、最後に「僕の考慮漏れはないですか？」とメンターに確認する。これは必要な行動だと思います。一番避けるべきは、よくわからないまま迷った状態で止まることだと学びました。

環境が整っている

Tapple は制度面・技術面・組織面のすべてにおいて環境が整っていると感じました。ランチ制度では社員の方と気軽にご飯に行けます。

技術面でも Maestro や Molecule といった技術を積極的に採用していて、Compose 化もほとんど完了しています。社内イベントもあり、インターン生でも孤立しない雰囲気がありました。

ユーザー対ユーザーの複雑さ

マッチングアプリでは、2人のユーザーの状態の組み合わせが常に発生します。例えば、「あしあと」機能の実装においては、「ユーザーAはブロック済み、ユーザーBはいいかも済みでプライベートモード」といった複雑な状態を考慮する必要がありました。

「いいかも」「いまいち」「ブロック」「通報」「ありがとう」といったアクションと、プライベートモードやマッチ済み、いいかも済みといった各ユーザーの状態が掛け合わさるため、クライアント側でも考慮すべきことが非常に多いです。非常に難しいけれど、非常に面白い。この複雑さこそがマッチングアプリ開発の醍醐味だと感じました。

人材が豊富

PM（プロジェクトマネージャー）、デザイナー、iOSエンジニア、Androidエンジニア、バックエンドエンジニア、DS（データサイエンティスト）、マーケティングなど、さまざまな職種にしっかりとした人員が揃っています。年代も若手からベテランまで幅広く、スペシャリスト寄りの方もいればマネージャー寄りの方もいます。どのタイプにも複数人が在籍しており、一人に依存していないからこそチームとして安定感があります。私がインターン中に質問や相談をしやすかったのも、この層の厚さがあったからこそだと感じました。

おわりに

約1ヶ月間、本当にお世話になりました。メンターの池津さんからは、技術だけでなく「エンジニアとしての考え方」を教わりました。レビュアーの皆さんには、レビューとコメントを通じて、コードの品質とは何かを学ばせていただきました。Tappleチームの温かい雰囲気があったからこそ、インターン生である私自身も臆することなく踏み込むことができました。

最後に、この記事を読んでくださっている学生エンジニアの皆さんへ。ここまで書いたTappleの魅力に少しでも共感した方には、ぜひ一度インターンに参加してみてほしいです。整った環境、複雑で面白い技術課題、そして層の厚いチーム。

とても魅力的な事業部です！

最後までお読みいただきありがとうございました！