ばとらの部屋
長期インターンシップを3か月やってみて
作成日 2025年6月1日 / 最終更新日 2025年6月7日
6月に入り、2月半ばから始めた長期インターンシップも3か月が経過しました。ここまでの感想や学びをまとめてみます。
今回、初めてのインターンシップということでこれまで個人開発しかしてこなかった人間が始めて実際の開発現場に飛び込むとどうなるのかをまとめてみました。
ここで書くことは、私が業務を行う中で勉強になったことや指摘されたことを書いていきます。
私は大学2年の春休み(2月)から業務委託の形態で長期インターンシップを始めました。スタートアップの企業であることもあり、日々の業務はリモートで行っています。
「報告・連絡・相談」であることは言うまでもないと思います。しかし、頭では分かっていても実際にできていないことが多くありました。
リモートで働きはじめると、お互いが何をしているのかが見えなくなってしまいます。 例えば、今何のタスクに取り掛かっているのか、タスクの進捗状況は順調かなど社員の方からすると言われないとわかりません。
そのため、稼働の開始には「○○のタスクをやります」とか「ここまで終わらせる予定です」、稼働の終了には「ここまで終わって、PRをドラフトで出しました」など定期的な報告をするべきです。
また、稼働時間の調整といった仕事全体に関係のあることはプラスのことでもマイナスのことでも連絡するべきです。
実装方針や、実装方法、プロダクトの歴史など仕事を進めていく上で分からないことがあったらとりあえず相談するべきです。ここで相談する内容は、あらかじめ整理しておく必要があります。
何が起こっているか事象を整理する
最終的には何がしたいのか、何がわからないのか、どういう状態になっていたいかをあらかじめ整理してから質問するべきです。
人に聞く前にAIに聞いてみる
人に聞くとその人の時間を奪ってしまいますが、AIに聞く分には自分の時間を消費するだけです。また、事象の整理ができていなくてもAIに投げることである程度事象がまとまる手助けになるかもしれません。
テキストか通話か
複雑すぎる質問をテキストで聞かれても相手は回答しづらいことが多いため、単純な質問はテキストで、複雑な質問は通話で相談するべきです。
曖昧な表現は人によって解釈が異なる可能性があります。例えば、
これは筆者も使いがちですが、特に急ぎでやらなければならないタスクなどで進捗を問われたとき、「今日中に終わらせます！」と言ってしまいます。
ここでの「今日中」とは誰にとっての時間であるかが曖昧になってしまいます。正社員にとってのコアタイムなのか、23:00に使うと次の日までなのか、深夜に使うと今の稼働なのかなど人や時によって解釈が変わります。
「たぶん」がついてしまうと、聞いている側は何か不安があるのかなという風に感じ取られてしまいます。ここでは、「たぶん」を付けたくなった理由を添えるべきです。
相談時に意識することにもあったようにメッセージを送信するときは自分のなかで内容を整理してから行うべきです。
例えば～筆者がやってしまったこと
社員> ○○について実装してください
筆者> ○○はどうやって実装することができますか？これはアウトですね。
社員> ○○について実装してください
筆者> ○○を実装するのに△△と××の2通りの実装方法がありますが、どちらの方が良いでしょうか？先ほどより自分で調べた痕跡があり良い返信になっていますが、まだ情報不足です。
社員> ○○について実装してください
筆者> ○○を実装するのに△△と××の2通りの実装方法があります。△△のメリットは～で、デメリットは～です。××のメリットは～で、デメリットは～です。どちらの方が良いでしょうか？2つの実装方法にメリット・デメリットをつけることで社員の方はプロダクトのドメインや今後の方針を鑑みて選びやすくなります。
このように「分からない」「判断できない」ことをそのまま返すのではなく自分で調べたり噛み砕いてから質問したり返信するべきです。
ここからは技術的に得た知識などを書きたいと思います。
3か月の間に何をやったかなとPRを眺めてみました。詳しいことは書けませんが、ざっとこんな感じでした。
主にAPI開発とテストがメインでした。技術面とは直接的に関わりませんが開発手法や設計に関しても学びが多かったです。
後程、それぞれの概念などを別記事に書きたいと思います。
これは、個人開発では得られなかったことですが、レビューをしてもらう際にはレビュワーの立場になってレビューすることを考えてみましょう。
サークルでの共同開発では「1Issue = 1PR」「1エンドポイント = 1PR」の感覚でした。
簡単な機能の実装やバグ修正程度であれば、それでもいいのですが業務レベルになると1エンドポイントの実装量が大きくなってしまうことがあります。実装量が多いとレビュワーの負担が大きくなってしまいます。
そのためPull Requestは意味のある小さい単位で作成するべきです。ここでの「意味のある小さい単位」とは、プロダクトが壊れないことを指します。
また、PRを小さな単位で作成することは、マージによる影響範囲を小さくする目的もあります。
最近では、急激に生成AIが成長しており開発をするうえでは欠かせない存在になってきました。
筆者も、業務の中で技術的に分からない時や内容が整理できていないときなど様々な状況で積極的に生成AIを活用しています。そんな生成AIとの付き合い方をまとめたいと思います。
コーディングに生成AIを使うときは注意点があります。それは、生成されたコードが責務違反をしていないか、ビジネスロジックに間違いがないかということです。
個人開発程度では気にする必要がないかもしれませんが、大きなプロダクトの場合はコードの管理・保守のことも考えなければなりません。
そのため、Agentにすべて任せるようなことはせずに最後には人間の目でチェックする必要があると思います。
実装方針を考えたり設計をするときに、他に案はないのか？なぜその案にしたかなど(Design Docを書くうえでも)必要になってきます。
技術力がなくとも、調べることはできますのでAIに聞いてみるといいと思います。ここでの注意点は、聞き方です。
例えば、データベースで一括して作成・削除を行う実装方法が分からないとき
このコードで条件○○に合致するレコードを新しい配列△△に追加して、for文の外で一括削除できるように修正してくださいと聞いてしまうと結論ありきで聞きすぎになってしまいます。すなわち、新しい方法を聞きたいのに、方法を固定して聞いてしまい特定の答えしか返ってこないからです。
ここでは一括して作成・削除する目的を考える必要があります。
そのうえで、どのような方法があるかを聞くのがベストだと思います。
初めての実務経験という中で技術面もそうですが、技術面以外の学びが大きかったような気がします。インターン生が初めからなんでもできる訳ではなく技術面は後からついてくるものだと思っているので、技術面以外の「積極性」や「コミュニケーション能力」、「時間を守る」といった当たり前かもしれないことをする。これが「エンジニアとして働く」ことの第一歩なのではないかと感じた3か月でした。