はじめに

はじめまして。金沢工業大学 情報工学科 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の魅力

環境が整っている

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

 

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

 

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

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

 

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

 

人材が豊富

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

 

おわりに

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

 

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

 

とても魅力的な事業部です！
最後までお読みいただきありがとうございました！