ベンチャー企業で働くエンジニアのインターン生が意識したら爆速で成長できたこと7選

大学1年の夏からベンチャー企業でエンジニアとして働いてました。紆余曲折あり、今はスタートアップ3社目、エンジニア経験1.5 ~ 2年です。

色々な会社を転々とする中で、これさえ守っておけば爆速で成長できる、という項目が体感レベルでわかってきたので、それらを紹介します。

エンジニアだけに限らず、他の業種のインターン生にも適用できることだと思います。ぜひご活用ください。

気軽に質問をする&可能な限り調べる

聞くは一時の恥聞かぬは一生の恥といいますが、これはまじで本当でして、聞くと一瞬で解決することはよくあります。エンジニアの場合は特にそう。

かといって、問題に行き詰まったら何も考えずに質問をする、というのも違います。知識が定着しないというのもありますし、質問をするということは、誰かの時間を自分に使ってもらうということ。

社員の方の時給を考えると、質問にかけた時間によっては膨大なロスにつながることもあるわけで、インターン生だからこそ、そのあたりを意識しないといけません。

ということで、詰まったら気軽に質問するということと、わからないところは限界まで調べる、という一見2つの矛盾した行動を実行できると、めっちゃ強くなれます。

質問テンプレを作る

こういう手順で質問をすると短い時間で解決できるな、という型があります。

社員の方に割いていただく時間を最小限に抑えつつ、かつ最大の結果を得るため、自分の質問テンプレを作っておくことはおすすめです。

僕の場合の質問テンプレートはこんな感じです（エンジニア用）

1. 自分のタスクの説明をざっくりわかりやすく（例: 〇〇というAPIを追加していて~、APIのテストを追懐して~、みたいな）
2. エラーの起こる箇所、エラーの起こるタイミング、エラーの挙動、エラーの発生条件（例: 〇〇というメソッドのところでつまずく、条件Aではうまくいくが、条件Bではうまくいかないなど）
3. デバッグのために試したこと（例: consoleデバッグ、printデバッグ、ブレークポイントを設定して、エラーの起こる前後での処理を見たかどうか、など）
4. 追加で調べたこと。ライブラリの挙動とか、概念の理解とか
- 公式のドキュメントを読んだかどうか
- 同じメソッド、似たような処理をしている、プロジェクト内の他のコードを調べたか
5. 仮説検証してみた結果（〇〇のところに、xxという処理を追加すればうまくいくと思ったのだが、ダメだった、など）
6. うっかりミス、ケアレスミスの可能性はないか（typo, 大文字小文字違い、実は必要なメソッドをimportしてないみたいな）

エンジニア以外の職種にもできるように拡張すると、こんな感じになります。

1. タスクの説明（質問する人が、タスクをアサインしてくれる人だったらここは省きます）
2. わからない箇所
3. なぜわからないのか、理由を説明。（わからないところがわからない、というパターンもあります）
4. 調べたこと・仮説

例えばSEOだったら、

1. タスクの説明: サイト記事の順位分析
2. わからない箇所: なぜ、この記事は○位なのか
3. なぜわからないのか: この記事の上位に来ているあのサイトの記事より、こちらのほうが質が高そうに見える
4. 調べたこと・仮説: サイトのドメインパワー、被リンク、公開日時などが影響しているのではないか？

みたいな感じですかね！

SEOをガチでやったことはないので、例がちょっと薄っぺらくなってしまいましたが、要点は伝わったかと。

シフトを入れまくる

まあ当たり前なんですが、シフトを入れれば入れるほど、こなせるタスク量は増えていきますし、タスクの粒度も大きくなっていきます。

タスクの粒度とは、すなわち「責任」と言い換えてもいいんですが、責任の大きさとインターン生の成長の速度は正比例します。

毎週2日しかシフトを入れられない子に、大きめのタスクを割り振ろうとしても、厳しいんですよね。シフトが少ないということは、少し進捗が遅くなるだけで、簡単に1、2週間の遅延が発生するということなので。

エンジニアの場合も、文言修正とか、テストコードを書くとか、そういうタスクばかりやっていては、成長速度は遅いままです。新機能追加とか、設計からテスト、リリースまで一気通貫に担当するとか、そういうことをしていかないと、圧倒的成長はできないんですね。

チャット(Slack)を確認しまくる

自分の勤務時間以外はSlackなんて確認しませーん、通知オフ！、なんてインターン生に裁量の大きい仕事は任せられるでしょうか、ちょっと不安ですよね。

表現が多少ブラックになりますが、自分がシフトを入れていないときもslackに張り付き、メンションが飛んだら即レスできるぐらいのフットワークを出すと、信頼されます。

エンジニアの場合は、自分が作った機能が、あるとき不具合を出した、なんてことはよくある話です。不具合のレベルによって緊急度は変わってくるわけですが、仮にシフトに入っていなくても、自分の担当した範囲が問題なく動いているか、チャットを時々確認する、ぐらいの責任感は持ちたいですよね。

勉強しまくる

勉強する

↓

タスクをこなせるスピードが上がる

↓

よりレベルの高いタスクを振ってもらえる

↓

もっと勉強する

このポジティブスパイラルに突入できると、めちゃめちゃ楽しいです。社員の方との距離感も縮まりますし、なんというか、「認められてるな」という実感が湧きます。

接待インターンからの脱却

短期インターンと長期インターンの最も大きな違い。それは、インターン生が「お客様」かそうでないか、でしょう。

正直、サマーインターンで3日間のワークショップ、みたいなのをやっても、何か有益なことが学べるとは全く思えません。その会社の外聞のいい部分の上っ面を薄くなぞる、みたいなことしかできないんじゃないですかね。

どんなにキラキラしているように見える会社でも、その内部はめちゃめちゃ泥臭いもの。短期インターンでは、キラキラ企業という幻想を見せられますが、それは外向けの建前というやつなんですよ。

というか、泥臭い部分を見せたら、みんながっかりして応募しなくなってしまうのでw

長期インターンをしているのなら、そういう上っ面インターンをするのはもったいないです。例えるなら、刺し身を食べるとき、スーパーでパック入りの刺し身を買うのか、漁に出て魚を釣って、地力でさばくのかの違いです。

自分はインターン生だから、と一歩引くのではなく、いかに社員の人と同じ裁量、同じレベル、同じ立場になれるか、を貪欲に追求していくと、自ずと圧倒的成長はやってくるはず。

最後に

あたかも自分は今回挙げた各項目ができている、みたいな口調でしたが、いえ、全くそんなことはありません、まだまだ修行中の身です、と予防線を張らせていただきます。

ただ、自分の意見が間違っているとは一ミリも思いませんし、ここで挙げた項目がいわゆる「普遍的な真理」というやつだと思います。すなわち、今回紹介した項目を追求していけば、いつの間にか劇的成長を遂げることができるはずです。

僕も最近はインプットが不足しがちなので、もっとコードを書いて成長しないとな、という感じです！以上！