今回は2週間の就業型インターンに参加してきたので、そこで感じたことや学んだことをまとめていきます。

目次

CA Tech Job Liteとは
なぜ参加したのか
インターンでの目標
実際にやったこと
実務の開発現場で感じたこと
2週間で自分は何が変わったのか
届かなかったこと
一番大きかった気づき
これからどう活かすか
感想

CA Tech Job Liteとは

CA Tech Job Liteは、株式会社CyberAgentが開催している学生向けの体験就業型インターンシップです。

今回参加したものは、iOS / Android / Flutterのエンジニアが募集されており、それぞれ技術を扱っている部署に配属される形式でした。

このインターンの特徴は、社員の方と同じようにチームの一員として実際の業務を行うことです。

詳しくはこちら。

自分は、Flutterでアプリ開発をしているWINTICKETのチームに配属され、施策のUI開発を担当しました。

なぜ参加したのか

これまで自分は、個人開発とサークルでのチーム開発を中心にアプリを作ってきました。

業務委託としてプロダクト開発に関わる経験はありましたが、

大規模なプロダクトを、チームで作り続ける現場

を経験したことがありませんでした。

一通り作れるようにはなったものの、そこから先に進んでいる感覚がなく、成長が止まっているように感じていました。

「自分に何が足りないのか」が、自分ではわからない状態だったと思います。

そこで、実務に入れるインターンを探していました。

また、3月に「CA Tech Dojo」という育成型のインターンに参加したことや、福岡でのイベントで社員の方と話す機会があったことで、会社としての魅力を知ることができていました。

「実際に働く側から見てみたい」と思っていたタイミングでこのインターンを知り、応募しました。

インターンでの目標

インターン開始時に自身の目標について問われ、

実務と自分の経験の差を1日1個探し、成長の道標を3つ立てて持ち帰る

という目標を設定しました。

2週間という期間で「たくさんコードを書く」ことを目標にしても、実務のスピードには追いつけないと考えました。

それよりも、

実務では何が当たり前になっているのか
自分の開発には何が無かったのか

を持ち帰るほうが、この2週間の価値が大きくなると思ったからです。

「道標」の定義

道標の定義も、最初に決めておきました。

道標＝目指す状態＋その具体的な行動

目標を立てるときに、達成度を測る基準も3段階で決めておきました。

点数	基準
80点	差のメモが10個以上集まる / 道標3本が「目指す状態＋今後の行動」の形式で書けている / タスクからリリースまでの流れを自分の言葉で説明できる
100点	流れの説明に加えて「なぜそうするのか」が言える / 質問を「自分の仮説＋確認したいこと」の形式に変えた / 能動的行動が1日1回継続できた
120点	学生開発と実務のギャップをドキュメント化 / 質問や報告のやり方が定着し、初週より明らかにスムーズになったと具体的に比較できる

実際にやったこと

2週間で3つのタスクを担当し、PRを3本出しました。

具体的な機能内容については書けないため、ここではどのような判断をしたのかを中心に書いていきます。

タスク① リリースまでの一周を体験する

最初のタスクは、機能そのものよりも、

コードが本番に届くまでの経路を一周体験すること

が目的のものでした。

大まかな流れは以下のようなものでした。

ブランチを切る
  ↓
Draft PRを出して方向性をすり合わせる
  ↓
CI / 自動テストが走る
  ↓
レビュー（人間 + AI）
  ↓
指摘 → 修正の往復
  ↓
approveが揃ってmainにマージ
  ↓
リリース

学びとして

小さく安全に出す
未完成の機能はフィーチャーフラグで隠す
段階的にリリースする
問題があればフラグで切り戻す

という仕組みがありました。

タスク② 既存のUIに機能を追加する

次のタスクは、既存UIに機能を追加でした。

複数人のレビュアーに加えてAIレビューも入り、往復してマージまで到達しました。

来た指摘を要約すると、次のようなものでした。

その用途なら、もっと標準的な部品で足りるのではないか
この実装は本当に必要か
既存はこうしていない

ここで必要だったのは、

デザイン要件を「自作で作り込むか、標準機能で実現するか」を判断すること

でした。

実際にとった行動

デザイナーに仕様の意図を確認して、要件を確定させる
既存コードを調査し、同じ表現を自作している前例がないことを確認する
その表現を標準で持つ部品を、既存の前例を根拠に採用する
なぜその実装にしたのかをPRに残す

実装自体は、レビューの往復の中で3回作り直しました。

ここでは、

「動くかどうか」は前提で、「なぜこの形なのか」を問われ続ける

という経験をしました。

このタスクで行った判断

判断	考えたこと
どこに実装するか	共通基盤に手を入れると影響範囲が大きいため、機能側のコンポーネントとして追加
判定と描画の分離	可否の判定は親側が持ち、子には結果だけを渡す
将来を見た設計	後続で拡張される前提で、渡す情報を1つのモデルに集約
状態の持ち方	画面を閉じたら忘れてよい状態なので、グローバルな状態管理に載せずローカルで完結
作り込まない判断	フレームワークの標準挙動で吸収できる部分は自作しない
慣例にないものは足さない	既存画面に前例がないことを確認し、一度追加した実装を削除
PRを切り直す	指摘を受けてrevertし、既存挙動を変えない追加のみのPRに分割

このタスクで強く感じたのは、

実装力だけではなく、実装しない判断にも技術力が必要

ということでした。

タスク③ コンポーネント切り出し

最後のタスクは、コンポーネントを新しく作るタスクでした。

ここでは、

部品ごとに「使う」と「作る」を分けること
APIのデータを表示用にまとめ直すこと

が軸になりました。

行ったこと

既存コンポーネントを再利用
既存の入口が別用途のデータ専用だったため、変換済みデータを受け取る入口を追加
変換処理は呼び出し側に配置
他画面でも使える部分を共通コンポーネントとして切り出す
API仕様を確認してから汎用設計にするか判断
バラバラの形で返ってくるAPIデータを、表示単位のモデルとしてModel層に新設
「UI層で結合しない」という方針をドキュメントコメントに残す
表示の分岐ロジックを1箇所に集約
ユニットテストを作成

レビューへの返し方を分けるようにした

このタスクで一番学びが大きかったのは、レビューへの返し方でした。

最初は指摘をもらったら、全部そのまま直そうとしていました。

しかし途中から、状況によって動き方を分けるようになりました。

状況	動き方
納得した	すぐ直す
事実がわからない	仕様書や設計書などの一次情報を確認してから直す
設計意図がある	根拠を説明して残す
今回の範囲外	責務外であることを回答し、別PRでの対応を提案する

ここで学んだのは、

指摘は全部直すものでも、全部守るものでもない

ということでした。

重要なのは、

どのケースに当たるのかを見分け、それぞれ違う返し方をすること

でした。

実務の開発現場で感じたこと

コードレビューの文化

一番差を感じたのがここでした。

1つのPRに対して、1日で複数ラウンドの指摘と修正の往復が発生する
レビュアーごとに観点が違う
- 実装
- デザイン表現
- 文章表現
人間のレビューに加えてAIレビューも入る

自分がこれまでやっていた、

「動いたら見てもらう」

とは、かかっているコストが全く違いました。

品質を道具で守っていること

品質を担保するための仕組みが、いくつも用意されていました。

例えば、

VRT（Visual Regression Testing）
UI Catalog
開発中のビルドを他職種の方の実機に配布する仕組み
本番ユーザーのエラーを監視して原因を究明する運用
チーム独自のlintルール

などです。

人の注意力に頼るのではなく、仕組みで品質を担保する。

これが学生開発との大きな違いだと感じました。

他職種との連携

デザイナーやWeb、ビジネスの方と連携する施策では、共通認識をドキュメントに起こしてから進めることが前提になっていました。

これは、手戻りを防ぐための投資なのだと感じました。

また、意外だったのが、

仕様は完成品で降ってこない

ということです。

UIも含めてすべてがかっちり決まっているわけではありません。

気づいた人が発言することで、施策やプロダクトの質が上がっていく構造になっていました。

つまり、

「決まっていないから聞く」

だけではなく、

「気づいたから言う」

ことが求められる場だと感じました。

設計ドキュメントについても、

アーキテクチャ
段階的なリリース
切り戻し
過去の障害を繰り返さないための対策

など、複数の視点で書かれていました。

何を考え忘れやすいのかが、型として共有されていることも印象的でした。

振り返りがしっかりしていること

KPTが施策ごとに定期的に行われていて、他チームの学びまで取り込まれる運用になっていました。

振り返りが個人の反省で終わらず、

チームの資産に変わる仕組み

として動いているのが印象的でした。

学生開発では、振り返り自体をあまりやっていなかったので、ここは素直に持ち帰りたいと思いました。

2週間で自分は何が変わったのか

集めた実務との差から3本の「道標」を立てました。

道標1：実装の前後にあるものを含めて設計できる

目指す状態

着手前に、要件の背景（なぜ・誰の・どんな課題か）を自分の言葉で説明できる
見積もりを「要件整理 / 設計 / 実装 / レビュー往復 / 手戻り」の5分割で出せる
選んだ理由と捨てた案を、人に伝わる形で書ける

今後の行動

「なぜ作るのか」に答えられない状態でコードを書き始めない
レイヤーごとの責務配置を書き出してから実装に入る。書けなければ調べるか聞く
見積もりと実績のズレを記録し、どの項目でズレたかを毎回確認する

道標2：わからないことを開示して、巻き込んで進める

目指す状態

わかる / わからないの境界を言語化して、そのまま伝えられる
質問を「事実 → 試したこと → 仮説 → 確認したいこと」の形で出せる
実装方針を決める前に、関係する職種へ確認を投げられる

今後の行動

詰まったら30分で切り上げて質問に移る
仮説が固まらないことも伝える材料にする
レビュー依頼は自分からメンションして出す
スコープが膨らんだら、落とし所の案（今回やる / 次に回す）を自分から出す

自分がどこまでわかっていて、どこからわからないのかを言語化できないと、相手は「任せていいのか」「フォローすべきか」を判断できません。

それができないと、チームとして動きづらい人になってしまうと感じました。

道標3：判断を残す形で実装する

目指す状態

なぜその実装かが、コードの外（PR説明・コミット・設計ドキュメント）に残っている
1目的 = 1PR。レビュアーが何を見ればいいかが明確になっている
完成前にDraft PRで方向性を確認できている

今後の行動

個人開発でもPR説明に「やること / やらないこと / 捨てた案」を書く
指摘を受けたら「どうすればこの指摘は来なかったか」を1行残し、次のセルフチェックにする
「ちゃんとしてから見せたい」を意識的にやめる
途中で出す方がコストが低いことを意識する

届かなかったこと

自分で決めた基準に照らすと、80点は満たし、100点は一部達成という着地でした。

できなかったことも書いておきます。

PR粒度のずれ

ずれの特定まではできましたが、修正の行動はこれからです。

質問を形にするまでの時間

仮説を立てるのに時間がかかり、質問の具体がまとまらないことがありました。

一番大きかった気づき

最終日の日報に書いた所感を、ほぼそのまま残しておきます。

2週間という期間の見積もりがちゃんとできていなかった。2週間で自分はコードもバリバリ書いて進められると感じていたが、実際は施策の要件だったり、配属されたプロダクトの理解だったり、曖昧な実装ではダメで、エラーとか今後の開発のことだったり考えることや求められるものが多く、それを加味しながら実装しないといけないので、想像より進まないことがわかったし2週間じゃ足りないと感じた。

実際感じたこととして、

学生開発は「動くものを作ること」しか考えていなかった。
実務では「チームで作り続けられるものを作ること」を考えていた。

これからどう活かすか

持ち帰ったものを、明日から回せる形にしておきます。

① 見積もりを5分割する

サークルや個人開発でも、

要件整理
↓
設計
↓
実装
↓
レビュー往復
↓
手戻り

の5つに分けて見積もります。

② 個人開発でもPRを立てる

PRの説明に、

## やること

## やらないこと

## 捨てた案

## なぜこの実装にしたか

を書くようにします。

自分一人の開発でも、「未来の自分」をレビュアーとして扱うイメージです。

③ 詰まったら30分で切り上げる

これまでの自分は、わからないことがあると「もう少し調べればわかるかも」と長時間調べ続けることがありました。

これからは、

30分調べて解決しなければ、質問する

というルールにします。

「自分ひとりで完結させない」

自分に足りなかったのは、技術そのものよりも、

他人が関わる前提でコードと時間を扱うこと

だったので、まずは「行動の形式」から変えていきたいと思います。

感想

2週間という短い期間ではありましたが、実務の開発フローだけでなく、エンジニアとしての働き方や成長の仕方についても多くの気づきを得ることができました。

実装量だけで見れば、大したことはできていないと思います。

ただ、

「自分に何が足りないのかが自分ではわからない」

という状態からは抜け出すことができました。

足りないものが12個の言葉になって、そこから3本の道標になったので、

「次のステップの起点を作る」

という当初の目的は達成できたと感じています。

トレーナーの方をはじめ、レビューに何度も付き合ってくださったチームの皆さん、仕様を確認させてくださったデザイナーの方には本当に感謝しています。

ありがとうございました！

そして、同じように

「個人開発の先が見えない」

と感じている学生の方には、ぜひ一度実務に飛び込んでみることをおすすめしたいです。

自分が当たり前だと思っていた開発方法が、実務では当たり前ではなかったりします。

逆に、実務で当たり前になっていることを知るだけでも、自分の開発を見直すきっかけになります。

2週間という短い期間でも、

「自分に何が足りないのか」

を見つけるには、十分すぎるほど濃い経験でした。

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