新卒2年目が開発現場から得た学び

はじめまして。

キャリア開発グループ 新卒2年目の吉村です。

去年の丁度今頃、新人研修が終わりチームに配属されたなと、過去を振り返りしみじみしている今日この頃です。

配属された当初、絶賛稼働中のサービスの仕様やコードを目の当たりにし、その膨大さと複雑さに絶望したのはいい思い出となっています。

上記のことについては、私の同期達が記事を投稿してくれていますので、良ければご覧下さい!

エス・エム・エスキャリアの新人研修を終えて

文系未経験 新卒エンジニアがエス・エム・エスの現場に入ったら…


さて、今回は私から以下2点についてご紹介できればと思います!

☆新人がコードレビューをするようになって☆
☆当事者意識の重要さ☆

☆新人がコードレビューをするようになって☆

まず新人である私がレビューをするようになって感じたこと、意識していることを紹介できればと思います。

私がレビューをするようになったのは今から約3ヶ月ぐらい前のことでした。

初めは大きな不安を感じました。

配属されてしばらく経ったこともあり、サービスについての理解は徐々に深まっていましたが、いきなり先輩方のコードをレビューできるほどの自信はありませんでした。

不安に感じたポイントは以下になります。

  • 修正ファイル、修正箇所が多い時に漏れなくチェックできるのか
  • 先輩方のコードを見てると指摘する箇所があるのかと思えてくる
  • 疑問に思った箇所は、仕様や決まりに沿ったものか既に色々考えた上だろうと思えてくる
  • 単純なコードの書き方だけでなく、サービスの仕様やリリース後の影響も考えてレビューする必要があるが、そもそもの仕様を詳しく知らないので気づくことができないのではと思う

初めはこんな状態でレビュアーデビューしたわけですが、約3ヶ月も経つと自分なりに対処方法が分かってきました。

日頃意識していること

▼感じた疑問・感想を大事に

当たり前すぎるのですが、なぜこういう書き方を?、こういった点は考慮済み?などちょっとした疑問が、そのままレビュアーが指摘するべき修正箇所だったりしました。

また、全てに当てはまるわけではありませんが、新人の自分でも分かるような複雑すぎないコードこそ、今後の保守・運用に適したコードだと感じました。

▼過去の経験がレビューに活きてくる

レビューしていく中で注意深く見る箇所や、自分が指摘する箇所は、過去に自分が実装中に困った箇所や同じように指摘を受けた箇所だったりします。

つまりタスクをこなせばこなすほど、自分のレビュー時に指摘できる引き出しが増えることに繋がります。

レビューの数をこなすのも大事ですが、同じぐらいタスクをこなして経験を得ることも大事だと感じました。

▼自分の担当ではないタスクのレビューも覗く

他の方のタスクを覗くことで、自分が知らない仕様について知れたり、自分が指摘されたかのような、学びを得ることがあります。

もちろん全部が全部のタスクをしっかり見ることは難しいですが、見れる時にさらっとでも見ておくことで知識の向上に役立ちます。

結果

これらのことを意識することで、徐々にではありますがレビューができるようになってきました。

まだまだレビュアーとしての経験が浅く、知らないこともありますが、引き続きキャッチアップを続け、チームに貢献できるように力をつけていきたいと思います。


☆当事者意識の重要さ☆

最近、開発を進めていく中で感じたことがあります。

それはチーム開発において当事者意識を持つことがすごく重要だということです。

これは、最近チームでタスクの消化スピードを上げるのための施策を実施する機会があり、施策を進めていく中で私自身が感じたことになります。

私が所属するチームでは、数日〜1、2週間程度でできるサイト改善のタスクを中心にアジャイル開発を行なっています。

施策を実施する以前は、タスク着手への遅れやコードレビュー待ちタスクの滞留により、タスク完了までに時間がかかるという問題が発生しており、どうにかこの問題を解消して効率を上げられないかとなりました。

実施した施策

▼タスクの割り振りをアサイン制から自分で取っていくスタイルに

今までは週に1回、タスク状況確認のミーティングがあり、各自が持つタスクの状況を報告し、それに合わせて優先度が高いタスクを中心に割り振りするという形でした。

これを、タスク自体をチームの方々が見える場所に優先度順に配置しておき、手が空いた人から取る形式に変えました。

この施策の良かった点としては、以下が考えられます。

  • ミーティングの開催を待たずにタスクを取れるようになり、タスク着手までのリードタイムが短くなった
  • レビュー依頼中など手が空いた時に、その空いた時間に見合った優先度のタスクを自分で取れるようになった
  • よく目に付く場所にタスクが期限付きの優先度順で並ぶようになり、当事者意識が生まれた

▼サービスを横断的に担当ではなく軽い担当制に

私のチームでは複数のサービスを抱えていますが、今までは特定の人以外、特にこのサービスの担当で、というのが決まっていませんでした。

これを各サービスのタスクとコードレビューのメイン担当として、チームのメンバーを割り振ることにしました。

また、割り振るといってもガチガチに担当サービスを決めるのではなく、担当サービスに余裕がある時などは、手一杯になっているサービスのタスクをサポートできるように、緩めに割り振りを行いました。

この施策の良かった点としては、以下が考えられます。

  • タスクやコードレビュー着手への基準ができたことにより、各自で取りやすい環境に
  • 自分の担当サービスという意識が生まれ、タスク消化、コードレビュー着手への積極性が増した
  • 担当サービスのタスク、レビューをこなしていく中でサービスへの理解が深まり、どんどん着手へのハードルが下がった

結果

ギリギリだったタスク消化はある程度の余裕を持ち、後続のタスクを先取りできるまでに、溜まりがちだったコードレビュー待ちタスクの数は半分ほどに収めることができました。

これらの施策により変わったことは、指示を受けた後に行動するのではなく、当事者意識を持って自分から行動するようになったこと、だと思います。

私自信、自分の担当サービスができると、今までよりそのサービスを意識するようになり、自分の関わったタスクによるサービスへの影響などに、より関心を持つようになりました。

また、他サービスを触る機会があると、担当サービスとの違いに目がいくようになり、そこで得た新たな発見を自分の担当サービスだと、どう活用できるかなども考えるようになりました。

これは自分が詳しいと思える担当サービスができた事による、意識の変化だと思われます。


おわりに

配属されて約1年、様々な難易度、様々な内容のタスクに触れることで、業務や技術に関する知識が増えてきました。

配属された当初に比べれば大きく成長できたように思えます。

これは新人にも関わらず、様々なことに挑戦する機会を与えてくださり、また密なコミュニケーションでサポートしてくださったチームの皆さんのおかげだと感じています。

今後もサービスの向上、またチームの皆さんの役に立てるよう、業務に励みたいと思います。

長くなってしまいましたが、お読み頂きありがとうございました!

Pocket
LINEで送る