こんにちは。DSOCサービス開発部の阿部です。
私は、昨年4月に新卒アプリケーションエンジニアとして入社し、普段は名刺のデータ化システム「GEES」の開発をおこなっています。
今回は、新卒入社してからの1年間を振り返って、エンジニアとしてぶつかった以下の3つの壁、そしてその解決につながったことを書いていきたいと思います。
- 大規模サービスのシステム理解
- タスクスケジュールのコントロール
- ビジネスコミュニケーションの難しさ
4月ということで、1エンジニアの経験談として、新卒ITエンジニアの方のちょっとした参考になれば幸いです。
1. 大規模サービスのシステム理解
GEESはDSOC内に数あるサービスの中でも最も古いサービスで、その分システム自体もとても大きいサービスになっています。配属からしばらくは、わからないところばかりでかなり苦労していました。
自分でコードを読んだり、チームメンバーに質問したりすることはもちろん大事なのですが、ここでは、仕事の中でちょっと意識することで、大きくシステム理解につなげることができたことを書いていきたいと思います。
GitHubを存分に活用する
運用期間の長いサービスでは、どうしてもコードだけでは理解しづらい、当時の状況や判断などのコンテキストが存在します。そのため、既存のコードを読むときは、積極的にコミットからPRを辿り、そこから関連するPRまでを把握するようにしていました。そうすることで、コンテキストを理解することができただけでなく、どういう考えで設計しているのかや、実装について当時どのような議論をされたかまで勉強することができていました。
ペアコードリーディングをお願いする
複雑だったり技術的に難しい箇所のコードの場合、先輩社員にお願いして一緒に読んでいってもらうことで、把握と理解が深まることがありました。デザインパターンが実践的に使われているところなど、技術的に難しい部分は、自分一人で理解するのはなかなか難しかったりします。私の場合は、わからないところを質問した際に、よくペアコードリーディングをやってもらっていたのですが、自分の力で読んでいきつつ途中でフォローしてもらうことで、深く理解できることが多かったように思います。
また、こういう時間きっかけで、先輩が使っている便利なツールや方法を教えてもらい、勉強になることもありました。
コードレビューを「する」
チームで開発をしていると、詳しい人が実装した方が速いといったこともあり、特定の領域の実装者が偏ってしまうことがあります。それゆえ、自分のタスクの範囲だけだと理解が狭くなってしまうのですが、他のメンバーのPRをレビューすることで、普段触らない領域や難しい領域の知識を、効率的に取り込むことができるようになりました。
最初はコードレビューをするのに、ハードルがある人もいるかと思います。私も最初はなかなかレビューできないでいましたが、1コ上の新卒の先輩に「2Approve必要だからあまり気負わなくていいよ。僕も去年は適当にApproveしてたりしてたんだから（笑）」と言われ、気持ち的に楽になって徐々にレビューできるようになりました。*1もちろん、自分なりにレビューをしますし、その先輩も冗談めかして言っただけかと思いますが、最初は質問するだけくらいの感じでPR上で絡むことで慣れていけたように思います。
また、コードレビューに関しては、若いエンジニアとしては、優秀なエンジニアからコードレビューを受けることで、勉強になるというイメージがあると思います。実際勉強になりますが、私にとっては、自分がコードレビューを「する」ことがそれ以上に勉強になる手段となっていました。レビューをできるレベルになるまでコードを読み、ときには質問をすることで、人のコーディングであっても自分の中に落とし込むことができます。それによって、その人の工夫やどういう情報を元にどういう判断をしているのかを吸収することができていました。
2. タスクスケジュールのコントロール
システム理解が深まり、ある程度1人でタスクに取り組めるようになったころ、見積もりが甘く自分が立てたスケジュールを超過してしまったりと、スケジュールをコントロールできないという壁にぶち当たっていました。さらに、それにより自分の中のリズムができず、いまいちノリきれないことが続いていました。
タスクを細かくする
「タスクを細かくする」はよく聞くアドバイスだと思うのですが、実際その通りで、一つのタスクをさらに細かく分割することで開発がしやすくなりました。開発するときは実装時間よりも調査・検討時間が多くを占めるときも多いのですが、調査・検討するスコープを小さくすることができ、整理しやすくなったように思います。
GEESチームでは、アジャイル開発を採用していて、週に1度定期リリースがおこなわれています。タスクを分割しようとする前は、何週もリリースに含められないことがありましたが、意識し始めてからは小さくとも毎週リリースに何かを含めることができるようになりました。それによって、自分の中でのリズムもできていったように感じます。「いつまでにリリースするか」を意識していたのが、「何をリリースするか」にフォーカスするようになり、優先度も意識しながら進めることができるようになりました。
時間を測る
見積もりが外れてしまう、という課題を解消するため、日々の開発工数を細かく記録すること、開発工数を細かく予想することを始めました。「工数予測・開発・工数計測」のサイクルを回していると、一つ一つに自分が思っているよりも時間がかかること、最初に思っているよりも検討することが多いことに気づきます。また、細かく工数予測をすることで、よりタスクの解像度を上げながら見積もりをすることができるようになり、見積もりの精度を徐々にあげることができるようになりました。
ちなみに記録方法として、最初はタイマーで時間を記録できるようなツールを使っていましたが、タイマーのスタート・ストップを頻繁に忘れてしまい続きませんでした。最終的には1日の終わりに今日やったこととざっくりのかかった時間、明日やることと予想時間を記録する方法に落ち着いています。
3. ビジネスコミュニケーションの難しさ
コミュニケーションはエンジニアのみならず社会人にとって重要なスキルの一つであり、例に漏れず私もコミュニケーションの難しさを痛感しました。また、同じチームの人・同じ部の違うチームの人・違う部の人など、関わる人によってもコミュニケーションの仕方は少し変わってきます。
ここでは少し意識の話になってしまいますが、コミュニケーションにおいて重要だと感じた点を上げていきます。
数字で説明する
GEESチームでは、何万何十万というデータを日々扱っていることもあり、データを元に議論する文化があります。エンジニアとしては当然といえば当然なのですが、新入社員ほどデータをよく見ることが重要だと感じました。エンジニアにとってデータほど説得力のあるものはありません。適切にデータを見ることができていれば、信頼感にもつながります。
また、データをよく分析することで、同時にシステム自体の理解を深めることにも繋がりました。
自分の判断をのせる
Sansanの企業理念にあたるValuesの一つに「意思と意図を持って判断する」というものがあります。実際この1年、関わる人がどんな人であっても（上司であっても）、情報を伝えるだけでなく、自分の判断をのせてコミュニケーションをとることを求められてきました。
自分で判断をするためには、必要な情報が何かを考え収集すること・多角的な視点から見て潜在的なリスクを予測すること、など様々な考慮が必要になります。そして、これはコストのかかることであり、高度なことなのですが、だからこそタスクに責任をもち、深く考えることができるようになります。
自分自身まだまだなのですが、しっかり考え判断をすることができた場合は、たとえ間違っていたとしても建設的なコミュニケーションがとれ、相手からの信頼度も上がったように思います。
終わりに
今回この記事で書いた方法は、人に合う合わないもあると思いますし、より効率の良い他の方法が見つかることもあると思います。私自身まだまだ勉強中の身ですが、それでも誰かが同じような壁に当たったときに少しでも参考になれば幸いです。
buildersbox.corp-sansan.com
buildersbox.corp-sansan.com
〜編集部からのお知らせ〜
Sansanでは今年9-10月に実践型の10daysインターンシップ（学年不問）を開催いたします。
エンジニアとしての成長に必要不可欠な「ビジネスと技術を結び付ける方法論」をインプットし、「ハッカソン」でアウトプットする。プロダクト開発を体験できるプログラムです。
ただいま申込受付中です（締切：7月16日(金)18:00）。詳細はこちらをご覧ください。
jp.corp-sansan.com
*1:当社では2ApproveでPRをマージできることとしています
