👔

新卒がエンジニアとして良い立ち回りをするために私がやってきたこと

に公開

はじめに

この記事の主人公、私 Kado は、新卒で「株式会社Sun Asterisk(以降Sun*)」に入社し、研修及びOJTを経て、最終的に案件にも配属できるようになりました。

まず、この8ヶ月間多くの学びとサポートをくださったSun*の皆さんには本当に感謝でいっぱいです。

そんな私がSun*でどう成長したか、そしてその土台になったマインドを、新卒エンジニア向けにまとめます。

前提

私自身はSun*に入社する前にもインターン等で実務経験を積んでおり、ある程度エンジニアリングのノウハウはある状態です。

しかし、フルタイムで案件にアサインされるのはSun*が初めてで、研修期間にはエンジニアリングだけでなく、ビジネスマナーやプロジェクトの契約関連の基礎、エンジニアリングの上流工程などを学び、まだまだ私の中で不足を感じていました。

この記事を書いた時点では11月で、新卒入社してから8ヶ月目となります。

持ち続けたマインド

まず結論から言うと、私は以下のマインドを持って案件に取り組んでいました。

  • とにかく前に進める
  • 相手を喜ばせることを考える

これはここ最近になって気付いた私の価値観でもあり、Sun*に入った序盤からそんなマインドを持ちながらエンジニアリングをしていた感覚があります。

このマインドのメリット

この2つのマインドは、エンジニアリングをするうえで、私にとってはとても重要だと感じています。特に、チームで開発をするときに役立ちます。

  • 実装力の向上
  • 信頼性の向上
  • 生産性の向上
  • より高度な案件にアサインしてもらえる

このマインドを持つことで、より早く私自身が成長して、より高度で責任の高い案件に従事できるようになります。

駆け出しエンジニアとスタンダードエンジニアの違い

※本記事での「駆け出し」「スタンダード」という表現は、筆者自身の経験と観察に基づく便宜的な区分です。一般的な職位やスキルレベルとは異なります。

唐突ですが、私の中で感じている新卒(駆け出し)エンジニアと既存(スタンダード)エンジニアの違いは、管理する対象が「自分自身」か「自分以外」であるか、だと感じています。

駆け出しエンジニアの段階では、まだ自分のタスク、自分のスキル向上で精一杯だと思います。

自分のタスク、コーディングのスキルが整ってきて、スタンダードエンジニアになると、視野は「自分自身」から「他者」「プロダクト」に変わり、タスクやメンバーのマネジメントに従事するようになります。

新卒は、今どちら側にいるかを定期的に確認してみることをおすすめします。もちろん分野によって、例えばフロントエンドは他人に教えられるが、バックエンドはまだそこまで至っていない、ということもあると思います。それでOKです。

私はこの8ヶ月間でかなり成長できたと感じており、かなり「スタンダードエンジニア」に近くなったと感じています。


ここからは観点別に、具体的にやったアプローチを紹介します。

エンジニア(駆け出し)の観点

一発Approveが出せるPRを作成

Approveがされず、コメントを頂くということは、再度レビュー依頼が必要となり、レビュワーの工数がかかります

もちろん一発Approveされるのが理想ですが、まずは同じ趣旨のコメントを貰わないようにしましょう。コメントの意図を理解してPRを出すことで、既存メンバーからは喜ばれます。

何のための変更か言語化

PRに関連して、自分が実装した処理が何のために実施したのかを言語化できるようにしましょう。特に生成AIを用いると、その確認が疎かになりやすいです。

レビュワーからすると、何の実装か分からずにコミットをしたものをマージしたいとは思いませんね

Gitを使用してる場合は、commitメッセージやPRの文章でそれ明記しておき、何のための変更かを明確にしておきましょう(PRのテンプレートをチーム側で用意するのが理想)。

期限を守る

これは当たり前のことですが、チケットとしてアサインされたタスクは必ず期限を守るようにしましょう。期限が遅れると、他のタスクの進捗も遅れてPJ全体に波及する可能性があります。

苦戦してる場合は都度報告

とはいえ、実際やってみて分からない部分も発生するかもしれません。

期限に間に合わなさそう、どう進めていいか不明な場合は、なるべく早く報告しましょう。最初のうちはどの案件でもドメイン知識周りで不明点が多いですが、既存メンバーから聞くと一気に解像度が上がったり、期限を延長してもらえたりします。あるいは別の簡単なタスクに誘導してくれるかもしれません。

繰り返しになりますが、なるべく早く報告しましょう。聞くことは全然悪いことじゃないですし、最初のうちに不明点を払拭して実施してもらったほうが、既存メンバーからすると安心です。

ドキュメント化

私が入った多くの案件は、情報が体系的に整備されていない事があります。また、私はキャッチアップがそこまで得意じゃないので、最初のキャッチアップは毎度苦戦しています。

そのため入ったばかりの段階からドキュメント整備をやることが多かったです。ただ、これによって自分の躓きポイントが明確な状態でドキュメント整備を実施するので、次に新しい人がアサインされたときにスムーズにキャッチアップできるようになります。

エンジニア(スタンダード)の観点

先程の例はどちらかというと「駆け出し」的な観点で、ここからはより高みを目指すための動きです。

環境構築やリファクタリングの提案

私はある程度 React の経験があったので、環境構築部分も実装、提案してたりします。

基本的にコード系のアップグレードは、本来であればエンジニアメンバーには喜ばれます。しかし、実務だとこれも工数としてカウントされ、場合によっては好まれない行為となる場合があります(レビュー負担、リファクタ工数、デグレ等)。

アサインされていないチケットを巻き取る

これは他人のためというより、暇な時間を良しとしないという私の価値観もありますが、私が暇になった、なりそうなときは「次のタスク」を自分から探しに行きます。

最初のうちは1つのタスクでいっぱいいっぱいかもしれませんが、そこそこスムーズにできるようになったらより上流工程の部分もキャッチアップして巻き取れるようになると、先を見据えた開発ができるとして高評価されます。

もしチケットを巻き取れそうな場合は、一度メンバーに確認をしてみましょう。より優先すべきタスクをアサインするかもしれません(独断でやるのは避けましょう)。

ボトルネック工程を最速で実施

PJを進めていると、他の作業(依存タスク、確定していない要件)がボトルネックとなり、作業が進められないことがあります。人によっては別PJが忙しくて自分の案件が滞ることも少なくありません。

そうなった場合、一旦待つというのもありですが、PRマージ待ちの場合別の対応もあるので試してみると良いです。

  • 別の依存しないタスクを実施する
  • 依存PRがApproveされる前提で別Branchを作成して作業を進める
  • 期限を決めて相手のタスクを催促する

最後のは、相手が上司だと少し抵抗があるように感じますが、複数案件を掛け持ちしていると単に忘れている場合もあります。報告したほうが最終的に助かることもあるので、上司がアサインされているタスクの期限も添えて確認してみると良いかもしれません。

かかる工数を予想しながら実施

自分がやるチケットがどれくらいで完了するかを考えながら実施する癖はつけましょう。

一番やりやすいのは、事前に今日やることを自分のメモにTODOとして置いて、何時間かかるかを事前に記載しておくことです。PJ内部で進捗やTODOを共有できるとより良いです。

9:00-10:00 タスク01の実施
10:00-12:00 タスク02の実施
昼休憩
13:00-16:00 タスク03の実施

将来的に、これをチケット単位で管理し、メンバーの能力に応じて工数を予想し、その上でアサインしていくことになります。PM的な動き方ですね。

社会人の観点

ここからは少し余談ですが、これも自分が心がけて良かったことなので共有します。

失敗を繰り返さない

初の社会人ですから、色々と失敗はつきものです。ただ、まだ駆け出しというのもあり、そもそも失敗して致命的なことは最初のうちはやらされません。なので、今のタイミングでたくさん挑戦して、失敗してほしいです

そして、その失敗は繰り返さぬよう、頭の中、メモとして保持します。これができるかどうかで今後の成長速度に影響します

OKRをもとに成長する

OKRは目標達成のためのフレームワークです。Sun*では社員一人ひとりが半年ごとに自分が叶えたい目標を設定し、振り返る取り組みがあります。

新卒入社したばかりのときは、組織貢献とか、そもそも自分の目標を立てることすらもかなり難しかったです。今、様々なPJを経て課題が見えてくると、OKRを設定して実行することの恩恵が感じられます。

体調管理を徹底する

私はかなりストイックな方なので、食事や睡眠はかなり気を遣っています。そのおかげでフルタイムでの集中力は人一倍高いと感じています。

たかが食事、睡眠と思うかもしれませんが、毎日の業務の中で、なんかだるい、眠気が襲ってくる、という状態は重症です。社会人ですから生活習慣はコントロールできるようになりましょう。

時間を効率的に使う

社会人になると、1日の1/3を仕事に割り当てることになります。加えて睡眠時間も8時間(のはず)なので1/3、残りは1/3の8時間です。この8時間をどう有効活用するかが今後のキャリアとして重要です

人によっては通勤時間、家事の時間などもあり、全然時間がないという方もいると思います。ただ、余暇の時間がないと、本当に仕事と私生活だけの時間になってしまいます。

私は学生の時からどう時間を増やすかを考えて実行してきたので、そこそこのノウハウはあります。当時はマコなり社長やトーマスガジェマガの動画をよく見ていました。

  • ドラム式洗濯機を購入する
  • 会社の近くに住む(それでも片道35分)
  • 外食をフル活用する
  • 部屋の荷物は最低限(あえて狭い部屋に住む)
  • できるだけ外に出る
  • 使用する家具、ガジェットにこだわる

振り返り

私がやってきた経験・習慣というのはかなり有効なものだったのかな、と感じています。

特に「とにかく前に進める」というマインドは、私自身の成長に大きく貢献したもので、ネクストアクションをどんどんアップグレードさせていき、より良いビジネスパーソンになるための行動だと感じました。

私自身もよく他人と比較してしまい辛くなることが何度もありましたが、まずは現状の自分の能力と、今後なりたいエンジニア像を比較しながら、成長していくことが重要だと考えています。

今後の視点

今後は更に上流工程(システムの設計、見積もり、メンバーの管理)あたりができるようになるといいと思っています。

ただ、それだけ責任は大きく増えます。今まで述べた部分を完璧にやったうえで、それを自分以外のメンバーに効率よくアサインし、PJを回せるかが重要です。

加えて、まだまだ技術スタック的に不足している部分があるので積極的にキャッチアップしたいと思っています。

開発が楽しい

大変なことはありますが、やはり開発は楽しいです

Sun*は裁量を持って働きやすく、あれしたい、これしたいという意見を出すと反映しやすいですし、むしろ歓迎されます。

そのためには、ある程度今のPJにモチベーション高く臨むことは重要で、上長から「楽しむ余白から、創造が生まれる」という助言をいただき、本当にそのとおりだと感じています。

エンジニアリングの成長環境として非常に恵まれた環境で、色々サポートしてくださったSun*のメンバーには本当に感謝しかありません。同じく新卒として成長をともに仲良くしてくださった同期メンバーにも、心から感謝申し上げます。

まとめ

  • とにかく前に進める精神で実施
  • 相手が本当に喜ぶための手法を学び実践
  • 今の成長段階の判断軸として、視野が「自分自身」か「自分以外」かを見極める
Sun* Developers

Discussion