はじめに
こんにちは！開発エンジニアの小宮です！
私は入社エントリで、述べたとおり、 23年新卒でスマートキャンプに入社し、早いもので半年が経過しました。今回は、半年間の振り返りを書く機会をいただいたので新卒ならではの 挑戦や困難などについて書いていきたいと思います。あまりテックな話は少ないかもしれませんが、 最後までお読みいただけると幸いです！
私の仕事内容
私は、入社してからBALES CLOUD（以下「BC」）という事業部でエンジニアとして働いています。業務内容は主に、新規機能の開発、テスト、バグ調査などの保守運用開発です。
BCのエンジニアチームは、社員が自分を含めて4人、業務委託の方が1人で構成されています。
みなさん経験豊富な方が多く、私がみなさんに比べ一回りほど年下という、組織です。
新卒入社から半年間の振り返り
新卒入社して半年間を振り返ると、大きな悩みなどはなかったと思いますが、新卒ならではの細かい課題にはたくさん直面しました。
それらの課題について振り返ってみたいと思います。
新卒ならではの直面した課題は以下の3つです。
- キャッチアップが追いつかず、タスクが遅れる
- 年齢差による意見の遠慮
- ドキュメントによるコミュニケーションの難しさ
キャッチアップが追いつかず、タスクが遅れる
新卒研修が終わり、BCに配属後にはじめて立てた目標は、毎週のタスクを約70%完了させることでした。これだけ聞くと、「70％？100％が当たり前じゃないの？」と思われるかもしれませんが、
BCでは1スプリントを一週間で行ないその間に要件の詳細決め、開発、テスト、レビュー、リリースを行ない、
複数人が１つのタスクに携わるため、当時のチームの完了率見ても80％程度でした。
そのなかで70％という目標を立てたのですが、当初の私としては「どうせやるなら100％目指そう」と思っていました。
ただBCの技術スタックは今まで触れたことがないものも多く、キャッチアップしながらタスクを進めていくという流れでした。
入社して右も左もわからない私は、まずはとにかくコミット量を増やしていこうと思いました（脳筋）その結果、配属直後はタスクの量や難易度が調整されていたので、コミット量だけで順調に進んでいました。
しかし、タスクの量が増えたり、難易度が上がると、完了率がだんだんと下がり、キャッチアップの時間もほとんど確保できず、タスクが遅れることが増えました。
その時は、自分のかけれる時間をとにかくかけてもタスクが終わらないという状況に陥り、かなり焦っていたのを覚えています。
心がけたこと
上記の課題に対しては、抜本的な解決策はなく、地道にタスクをこなして少しずつドメイン・技術の理解を深めるしかないと思いました。ただ、そのなかでも意識的にやっていたことが3点あります。
1点目は、最初から全部をやろうとせず、段階を踏んでからタスク量を増やそうと決めたことです。私の場合は、コードレビューをすることに配属当時に多くの時間を使ってしまっていたので、
期限を決め、ある程度業務に慣れるまで、担当から外れるようにを上長に相談し、一定期間コードレビューから外れました。コードレビューを通じて、他の人のコードを見ることで、成長できるというメリットもあると思いますが、
私の場合、新卒で技術もドメインも知識が乏しい場合は、ある程度タスクベースでキャッチアップすることの方が効率的だと感じました。
２点目は、技術のキャッチアップをする際に公式ドキュメントを読むことです。
私はもともと技術書などを読むことに苦手意識があり、公式ドキュメントを読むこともなんとなく避けていてネットにある記事やQiitaなどを読むことやchatGPTに聞くことが多かったです。
しかし、トレーナーからのアドバイスもあり少しずつ公式ドキュメントを読む癖をつけていきました。読む習慣がついてからは開発で困ったときに、自分の力で必要な情報にたどり着けるようになったと思います。
3点目は、質問をする際にwhyを意識するようにしたことです。スマートキャンプでは、新卒のエンジニアにトレーナーという業務上のサポートしていただける方がついてくれます。
そのトレーナーに実装に関することを質問する際に、入社当初は、自分で考えてわからないことを、「どうやって実装するのか？」というHowばかりきいてました。
もちろんその形式の質問でも問題は解決されるので、満足感がありそれ以上調べたりせずにその場しのぎで終わることが何度もありました。その結果同じような質問を期間を開けてからまたしてしまうことがありました。
その経験から質問する際には、「なぜそのような実装をするのか？」どのような思考のプロセスでその実装にするかなど、答えだけではなく、答えに至るまでの過程まで聞くようにしました。
whyを意識して質問するようになると、自分との考えの違いや、プロセスを知ることなり今まで以上に理解が深まるようになりました。
年齢差による意見の遠慮
私が所属しているBCのエンジニアチームは、冒頭でも少し述べたとおりエンジニア経験が豊富で、社会人経験も長い方が多く、私との年齢差が少しあります。
そのため私が配属したときは、リファイメントやプランニングなどのスクラムイベントで、自分の意見を遠慮していました。コードレビューにおいても、コメントを書くのを遠慮していてLGTMおじさんになっていました。
理由としては、年齢差により過剰に技術・ドメインの知識の差があると考えていて、自分が発言してMTGを止めない方がいいのではないか？という思いや、コードレビューでベテランだからこのような実装にしているかもしれない？と考えていました。
心がけたこと
こちらの課題に関しても、抜本的な解決策はないのですが、どんな切り口でも良いので自分から関わっていく意識を持つようにしました。
まず、MTGにおいては、質問ベースでもいいので発言すること・ファシリなどを積極的に行なうことをしてMTGに少しずつ参加していく意識を持つようにしました。
その際に、どんな質問や意見なども丁寧に対応していただいたチームメンバーの方々には感謝です。
また、コードレビューにおいても、なぜこのようなコードになったのかなどの質問書くことから始めました。
そこからはじめ、今ではバグなどを未然に防ぐようなレビューもできるようになったと思います。
ドキュメントによるコミュニケーションの難しさ
BCでは、連続した開発時間を確保するために一部のMTGの非同期化しています。
上の画像は緊急度や発散性に応じて、コミュニケーションを取るツールを使い分ける際に参考にしている図です。
図から分かるように緊急度が高くないやり取りはドキュメントベース（Notion）でのコミュニケーションが多くなります。新卒として入社した当初、この取り組みにすぐには慣れませんでした。
その時の私の思いとしては、「ドキュメントベースでやり取りするより、直接話した方が早く解決できるのではないか？」という疑問がありました。
さらに、単純にドキュメントを書く習慣がなかったため、書くことに対する苦手意識がありました。
心がけたこと
まず、ドキュメントを書く習慣を少しずつ身につけていきました。ただいきなり書けと言われても、どのようにを書けばいいのかわからないので、とにかく他の人のドキュメントを真似るところから始めました。
BCのチームの皆さんはドキュメントを書くのが上手で、1人1人のドキュメントのスタイルが若干違うので、それを見て良いと思った箇所を真似ていくことで、自分も少しずつ書けるようになってきました。自分はテーブルなどの表を用いてドキュメントをまとめるのがかなりお気に入りですw。
また、自分がドキュメントを書けるようになってくるとMTGの非同期化への理解が深まってきました。開発時間の確保もそうですが、ドキュメントを書くことで自分の考えを整理してから伝えることができ、
記録にも残るので後から見返すことができるというメリットなどを感じることができました。
成果
タスクの完了率は結果として、目標の70%を超えて、111％に到達しました。さらに、FourKeysのリードタイムも86.9時間とgoogleが定めるハイパフォーマーに分類される数値に到達しました。
その成果が認められ、年に２回開催されるスマートキャンプ全体のキックオフで新人賞をいただくことができました。中途の方々も対象になる中で賞をいただいて、自分が向き合ってきたことをしっかりと認められたことがとにかく嬉しかったです。画像は新人賞の賞品でいただいた本です。
ただ自分が選ばれると思っていなかったので、表彰の場にジャージで行なってしまったことが少し後悔ですw。
まとめ
半年間での振り返りをしてみると、新卒ならではの課題にぶち当たりながらも、それに対して解決策を見つけ、少しずつ成長できたと思います。
前期は自分自身のパフォーマンスを上げることに必死でしたが、今期は主語を大きくして、チームのパフォーマンスを上げるために行動していきたいと思います!
また、エンジニアとして技術的にインパクトがあることにも挑戦していきたいと思います！これからもよろしくお願いいたします!!
