最近セルフネイルにハマってます！add moreの森田です！

いよいよ冬らしくアウターなしでは出かけられない季節になってまいりました。
思えば20卒エンジニアとして昨年の4月に新卒入社してからあっという間に1年半が経過し、もうすぐ2年になります。そこで今回は、学生の頃の自分を振り返ってアドバイスができるならどんなことを伝えたいかをまとめてみました。

まずは、実務に入った際に感じたことをご紹介します。

①学校で得た知識はあくまでも最低限の知識、土台であって実務レベルではない

学校では基本的に課題はクリアしていましたし、グループでの制作経験もありましたので、実務もその延長線上でこなせると思っていましたが、いざ臨んでみると必要とされている技術レベルと自分のスキルレベルの差に衝撃を受けました...学校で教わる知識はあくまでも社会にでてスタートラインに立つために必要な知識であったと痛感しました。

②知らない専門・ビジネス用語や略語が当然のように出てくる

MTG中(MTGもミーティングの略語ですね！)や朝会などで当然のように専門・ビジネス用語、略語が飛び交います。はじめはまるで外国にいるような気分になりますが、その言葉の意味を知ると既に知っていることであるパターンが多く、学校ではいかに先生がわかりやすい言葉選びをしていたんだなということを実感しました。下記に個人的に頻出度の高い用語の一例をご紹介します。

【個人的に頻出度が高い略語、ビジネス・専門用語】
・リスケ...スケジュールを変更する、計画を組み直す
・バッファ...余裕、緩衝
・インシデント...好ましくない出来事、事件
・コンフリクト...衝突
・スコープ...範囲
・トルツメ...余計な文字や記号を削除した上、空いた部分を詰めるという指示
・アサイン...任命する、割り当てる
・FB...フィードバック(Feedback)の略語として使用される
　※フェイスブック(Facebook)の略語である可能性も0ではありません
・PR...Gitにおいてプルリクエスト(PullRequest)の略語として使用される
　※広報や宣伝で用いられるパブリックリレーションズ(Public Relations)の略語である可能性も0ではありません

もし話の流れで知らない単語が出てきましたら、会話に置いていかれないためにその場で意味を聞いてしまうのも良いと思います。(「なんでそんなこと聞くんだ！」と言う人はそうそういないでしょうし...)

ここからは、本題である学生の頃の自分に伝えたいことをご紹介したいと思います。

・公式リファレンスを断片的でも良いので読んでみること。

作業の途中で行き詰まったり、対応方法がわからなくなった場合、その改善策が公式リファレンスに記載されているという事例は実務において少なくありません。

公式リファレンスは基本的に英語で記載されており、はじめはギョッとなることもあります(私はなりました)が、学生のうちにその気持ちを減らし、あわよくば、何かの障壁にぶつかった際に公式リファレンスを読む癖を身につければ解決スピードが段違いに上がることでしょう。

・インターンシップや勉強会などにもっと積極的に参加すること。

先述した通り、学校で学ぶ知識はエンジニアの門を叩くための最低限の知識であり、日々の授業で使用される言語や記述方法においてもそれに付随した書き方が推奨され、モダン(モダン=現代的、最先端)でない場合が殆どでした。私の場合はフレームワークやGitは授業には含まれておらず、テキストエディタにterapadが強制されていた時期もありました。(terapadはHTMLタグの予測変換に頼らないようにするという意図もあったらしいのですが...)インターネットでモダンな知識や記述方法を調べることはある程度可能ですが、それがどれほど重要なものなのか、どれを優先して学習すべきかまで把握することは正直難しいのかなと思います。

そういった場合に、どのような案件にどのような言語が適しているのか、ソースコードをどのように管理しているのかを肌で感じるのにインターンシップは最適であると思いました。また、社内の雰囲気やコミュニケーション、プログラミングでお金を稼ぐことについても学べる貴重な機会としても良いと思います。また、そこで得た知識を勉強会などで共有したりして、知見を広げてみると実務でのギャップも減らせると思います。

・課題以外でのアウトプットを増やすこと。

学校での課題はグループワークやイベント提出作品制作を除いて正直「授業さえ真面目に受けれていれば余裕で作れる」ハードルのものが多いです。課題をクリアすることは大事なことに間違いはないのですが、それはあくまでも「学校についていけている」だけであり「IT業界についていけている」訳では断じてないということを認識することが大事です。課題で得たスキル+α(興味のある・必要だと思ったスキル)を駆使してもう一つランクを上げた作品制作をすることで少しでもIT業界についていけるようになると思います。また、そこで得た知見をQiitaなどに技術記事として投稿してみたり、制作物に実用性や背景を加味することでポートフォリオという実績として残すのも良いアプローチだと思います。

・どんなに些細なことでも良いのでいろいろなことに疑問と興味を持つこと。

「もっと便利な書き方ないのかな」「他にはどんなオプションがあるのだろう」「周りはこれをどう活かしているだろう」「こんなもの作れるんじゃないか」といった小さな疑問から行動へ移すことは、今後大切な知的財産になること間違いなしです。

・「学生の頃と違ってプログラミングでお金を稼ぐとなると嫌になる」とよく言われていたけど別にそんなことなかった。

これは個人的にかなり大きかった部分かなと思います。職種にかかわらず、いくら適性や知識があっても、興味やモチベーションがなければ仕事を続けることは非常に困難です。決して簡単すぎず、かといって手も足も出ないレベルではない案件と常に対峙し、毎日何かしらの新しい発見をすることができる現状に大変満足しています。

・単純作業がほぼ全くと言っていいほどない。

受託開発も行うadd moreだからこそという部分もありますが、案件のたびに先方の業種や使用する言語、スタイルが違ったりするので全く飽きが訪れません。

まとめ

あれした方がいいこれした方がいいと過去を振り返って書いてみましたが、あくまでももっと積極的にプログラミングしたいときのアプローチの一つとしてご紹介しました。

今の学生に最も伝えたいことは「プログラミングが面白く興味深いものだと思い続けていてほしい」ということです。学外のイベントに参加したり、休日を自己学習に当てることは確実に自分のためになることなのは間違いないのですが、その根底に「プログラミングを面白いと思っている」という気持ちがあるということがなにより一番大切だと思います。どうしてもやりたくない日だったり、乗り気じゃない日は必ずありますので、そんな日はパソコンを閉じて趣味に没頭したり、出かけたりしましょう！学生のうちに自己学習をしておくことは大事ですが、PCから離れて友人と遊ぶ時間も学生の間しか取れない貴重な機会だと思います！遊ぶときには遊び、学ぶときには学ぶメリハリのあるライフスタイルが社会人になっても活きてくると思います。

あれこれ振り返ってはみましたが、当たり前ですが悲しいことに私はもう学生のころには戻れません。今はどれだけの知識や経験を吸収し、実務における制作物の品質の向上につなげられるかを重要視して日々業務に取り組んでおります。

学生の方は是非この記事をこれからの活動の参考にしてみてください！