新卒から即戦力になりたいあなたへ。

はじめに

株式会社メタップスホールティングス に 23 新卒として入社した 2 年目の Web エンジニアです。
普段は mfloow という「業務フローの可視化」「タスクの進捗確認」「SaaS 連携で自動化」の 3 本を柱に、人事労務領域の課題を解決するサービスを開発しています。

本記事では、入社してから私が自走できるようになるまで考えていたことや取り組んだことに関して触れます。(現在進行中でも考え、取り組んでいることでもあります)

本記事の目的は以下です。

• 自分の思考の整理
• 2 年目となり後輩ができ、また来年も後輩が入社予定なので彼らの一道標になれたらという思い

あくまでも私個人が考えていることであり、会社を代表するものではないことをご容赦ください。
また、新卒から即戦力になる方法は星の数ほどあると思うので、一サンプル程度にお考えいただけると幸いです。

1 章 入社前から現在にいたるまで では、学生時代何をしていたのか、入社してからどのような流れで部署配属があり、その後どのようなアウトプットをしてきたかについて触れます。
2 章 心構え では仕事をする上でのメンタリティについて触れています。
3 章 コミュニケーション では業務に取り組む上で、他者とどのようにコミュニケーションをとっているかについて触れています。
4 章 インプット では馴染みのない言語やシステムをどのようにしてインプットすると吸収率が高くなるかについて述べています。
5 章 アウトプット では担当したチケットをどのようにこなしていくのかについて具体的に触れます。
6 章 コードレビュー ではどのようにしてコードレビューを進めていくかについて言及しています。

チームのメンバー、部署のメンバー、社内のメンバーに尊敬と感謝の念を込めて。

入社前から現在にいたるまで

バックグラウンド

入社前の情報はざっと以下になります。

• 地方国立大情報学部卒 (画像処理を中心に浅く広く)
  • 予備校通わず自宅浪人 1 年間 (自己学習方法をこの時に確立)
• 在学中は高校数学の塾講師のバイト (数学的思考とても開発に生きる)
• 就活時のポートフォリオは 2 ヶ月くらいかけて作った Web アプリ 1 つ
  • ガッツリ開発していた学生時代ではない

入社後

入社してから配属までは以下のようなことをしていました。

• 4 月 : 社会人マナーや弊社の組織理解のための研修
• 5 ~ 8 月 : 内製 Web アプリの開発
• 9 月 : re-shine 開発 (プロダクトローテ)
• 10 月 : mfloow を開発する部署に配属
  • mfloow 開発チームは 5 人程度

チケットの大小はありますが、配属後から半期ごとにリリースしたチケット数は以下になります。

期間	チケット数	リリース頻度 (ひと月の営業日を 20 日と仮定)	大きめなチケット
2023/10-12	20	3 日 / チケット	メール機能
2024/1-6	55	2.18 日 / チケット	権限拡充
2024/7-12	52	2.30 日 / チケット	通知チャネルごと (5種類) かつ通知対象 (17 種類) に対する個別通知設定 (合計 85 パターンの制御)

配属後 3 ヶ月程度で、ひと月の営業日を 20 日と仮定した時に 1 チケットあたり 2 日程度の頻度でリリースできるようになりました。
エラー発生は体感で 10 % 未満 (50 件中 5 件あるかないかくらい) です。(もちろんレビュワーや動作確認をする CS やプロジェクトオーナーの貢献あってのことです)
また、現在の業務では自分が担当するチケットの開発だけではなく、コードレビューも行っています。

心構え

プロフェッショナルを定義する

対価が発生するということは、その時点で既にプロフェッショナルです。
では、プロフェッショナルとは自分にとってどういうイメージであろうかと考えます。
私の場合はサッカー選手という職業がプロフェッショナル像を考える上でそのイメージが近いです。
彼らは自分のために、勝利のために、チームのために自分の考えを先輩・後輩関係なく伝え合い、自分のパフォーマンスを最大化します。
新卒だから、経験が浅いから、という理由で主張しないというのはこのプロフェッショナル像に反します。
自分のために、プロダクトを推進するために、チームのために何かしらのアイディアや現状の在り方に疑問を持ったら、それを伝えることはとても重要だと思います。

瞬間的に自己中心的でいる

本記事のいくつかの項目でこういう疑問が浮かび上がるかもしれません。
「先輩・上司の時間を奪うことになるんじゃないか？」
「それほど今の自分に時間を割く価値は先輩・上司にとってないのではないか？」
以上のような疑問を考えることは、即戦力にこれからなる私たちの仕事ではないです。
なぜなら、私たちは新卒として採用されたからです。ポテンシャル (潜在的な能力) を買われて採用されたからです。
潜在的な能力を顕在化する仕事は自分の仕事であると同時に先輩・上司の仕事でもあります。
相談したい時、質問したい時、その瞬間は自己中心的で良いと思います。
「先輩！今自分に時間を注ぐことで、そう遠くないうちにアウトプットが現在の何倍にもなるんだから、自分に時間割いたほうが得ですよ！」
くらいの心持ちで私自身取り組んでいます。

自分で掴みに行く

何事も自分で掴みに行きます。
面白そうなチケットが切られたら、それを担当したいと主張してみます。
結果的に担当にならなくても意思表示をすることは、上司が認識する自分の立ち位置を知ることができます。
担当にならない理由を考え、どのように日頃アウトプットできたらそのレベルのチケットを担当できるか、現状との差分を把握して埋めていきましょう。

仕事で扱う言語やフレームワークに専念する

入社して研修があり、研修を終えると担当するプロダクトや所属するチームが決まるかと思います。
残念なことに、必ずしもそこで扱う言語やフレームワークが自分の関心高いものと一致するわけではありません。
そのようなケースに遭遇した時、興味がある言語やフレームワークを自己学習したい誘惑に駆られることがあるかと思います。
しかし、最短距離でアウトプットできるようになるまでは、業務で扱わない言語を自己学習時間にあてることは推奨しないというのが私の見解です。
なぜなら、「軸となる言語」=「業務で扱う言語」にすることが圧倒的にコストパフォーマンスの点で勝るからです。
1 日 8 時間実装し、自己学習時間を 2 時間と仮定すると、 1 週間、 1 ヶ月、　1 年という期間で考えたとき言語に触れる総量には歴然とした差があります。
量は正義です。
また、軸となる言語を作ることで別の言語を習得する際に圧倒的に今以上のスピードでインプットすることが可能だからです。

他の項目でも何回か触れますが、プログラムというものはその性質上「順次」「分岐」「繰り返し」この 3 種類しか存在しません。
少なくとも私の知る言語では (どんなに複雑なロジックでも) これら 3 種類しかないのです。
このことを本当の意味で理解して頭の中でイメージできるまでは 1 つの言語で着実にこれら 3 種類の概念を習得しましょう。

誰のボールかわからないものに対して積極的にリアクションをする

「誰のボールかわからないもの」その最たる例は本番環境で発生したエラーです。
エラー監視ツールから検知されたエラー全てにリアクションをします。
そのためには現状の実装にどのような問題を抱えているのか発見するためにコードを読まなければいけません。
その積み重ねの結果、どれほど巨大に見えるシステムでも、その細部と全体像を少しずつ理解することに繋がります。
またエラーを解決しようとするとき、強く「順次」「分岐」「繰り返し」という視点でコードを観察するかと思います。
その姿勢で観察することは、扱う言語・フレームワークの概念に対する理解度が飛躍する一つの契機になります。

ビジネスサイドのメンバーからの問い合わせも同様です。
例えば、この機能の仕様はどうなっているか、お客様からこのような問い合わせが来ているなどです。
自分にメンションがなくとも、素早く仕様書や該当箇所のコードを読み回答しましょう。
たとえ、その回答に誤りが含まれていたとしてもメンションされた人が必ず訂正してくれるはずです。
エラー時の対応と同様の効果が得られるかと思います。

仕事を楽しめる瞬間が訪れるまで辛抱強く

私の好きな漫画「ハイキュー」ではこのようなやりとりがあります。
以下 「その瞬間」が有るか、無いかだ！！！ からのコピペです。

月島
「僕は純粋に疑問なんですが、どうしてそんなに必死にやるんですか？バレーは、たかが部活で将来履歴書に『学生時代、部活を頑張りました』って書けるくらいの価値しかないんじゃないですか？」
木兎
「月島君さ！バレーボール楽しい？」
月島
「いや、特には……」
木兎
「それはさ！へたくそだからじゃない？」
月島
「……」
木兎
「俺は3年で全国にも行ってるし、お前よりも上手い。断然上手い。」
月島
「言われなくてもわかってます。」
木兎
「でもバレーが”楽しい”と思う様になったのは最近だ」
月島
「？」
木兎
「”ストレート”打ちが試合で使い物になる様になってから。元々得意だったクロス打ちをブロックにガンガン止められて、クソ悔しくてストレート練習しまくった。んで、次の大会で同じブロック相手に全く触らせずストレート打ち抜いたった。」
木兎
「その一本で「俺の時代キタ！」くらいの気分だったね！」
木兎
「ーーー”その瞬間”が有るか、無いかだ。」
木兎
「将来がどうだとか、次の試合で勝てるかどうかとか、一先ずどうでもいい。目の前の敵ブッ潰すことと、自分の力が120％発揮された時の快感が全て。」
月島
「……。」
木兎
「……まぁそれはあくまで俺の話だし、誰にだってそれが当て嵌まるワケじゃねぇだろうよ。お前の言う「たかが部活」ってのも、俺はわかんねえけど、間違ってはないと思う。ただ、もしも、その瞬間が来たら……」
木兎
「それが、お前がバレーにハマる瞬間だ。」

「ハマる瞬間」が来るまで辛抱強くコツコツと日々できることを積み重ねていきましょう。

コミュニケーション

プロダクトを推進する上では上司と部下という関係はなくフラットである

プロダクトを推進する上で上司と部下という関係はなくフラットだというのが私の見解です。
なぜなら、プロダクトを推進する確かの方法を誰も知らないからです。
そういう意味ではフラットな関係であると言えます。
プロフェッショナルを定義するで述べた、プロダクトを推進するために何かしらのアイディアや現状の在り方に疑問を持ったら、それを伝えることはとても重要だと思うというのはこの考えが根底にあるからです。

また、実装に関しても同じことが言えると思います。
アーキテクチャやロジックの書き方に完全な正解はなく、あるとしたら「その瞬間限りの正解」があるだけです。
先輩から指示された方法だけではなく、このように処理したらもっとシンプルな実装になるのではないか、依存関係を少なくできるのではないかという視点を持ち続けましょう。

正解は聞かず、ヒントを聞き、その思考過程もセットで聞く

正解は聞かず、ヒントを聞くという姿勢は「自分で掴みに行く」ことの 1 つだと思います。
正解を自分で掴みに行くという意味において。
先輩が「答えを知っている」というメンタリティは成長を阻害する要因の 1 つです。
導き出せない今この瞬間も自走しましょう。

1. どうなったらゴールかを明確にする
2. そのゴールまでの道のりを測る (遠すぎたら別のメソッドやコンポーネントに切り出すチャンス)
3. そのために今どんな情報が自分に足りていないかを明確にする
   1. こんな出力をする API があれば解決できる
   2. どのレイヤーにメソッドを定義するのが最適か
   3. (できる限り狭い範囲で特定した) ここの処理が上手くいってないことは確かだが、なぜ上手くいっていないのか知れる術があったら良いのに
4. その足りていない情報を共有し、ヒントをもらう
5. ヒントに対して、ヒントが出るまでの思考過程を質問する
   1. その API はどうやって見つけたのか、どんな検索単語を入力したらその情報に辿り着けるのか
   2. そこにメソッドを定義するのはどういうことを考慮して判断したものなのか、既存コードで同じような処理の仕方をしているものはあるのか (あったらそこの処理を把握する)
   3. どのようにデバッギングしているのか、なぜその箇所をデバッギングしようとしたのか、どのような情報を得たいと最初に考えたのか、自分が定めた範囲よりもなぜそこまで狭い範囲に絞れたのか

他者の取り得る引数を理解する

コミュニケーションに関して人もメソッドと同様だというのが持論です。
引数の個数、その引数の内容、引数に対する出力がメソッドによって異なるように、人にも自分の発言に対して受容可能な個数 (情報のキャパ) 、受け取り方 (発言者にとっては伝え方) 、その発言に対する反応は異なります。
コミュニケーションにおける相手の取り得る引数を理解して、お互いに気持ち良く仕事を進められるよう努めていきましょう。

インプット

ドキュメント・書籍以外は読まない

学生時代、研究室で大変お世話になった担当教員の好きな言葉があります。

インターネットは玉石混交である。玉と石を見分けることさえできればインターネットは有用である。石を信じてはならない。

ドキュメント、書籍、ソースコードはほとんどの場合「玉」に該当します。
まず、何が「玉」なのかを把握するにはこれらを参照することが確実です。
Qiita, Zenn, Stack Overflow などをいきなり参照するのではなく、参照したとしてもドキュメント等の情報をキャッチアップする習慣をつけましょう。
もちろん Qiita や Zenn には素晴らしい記事がいくつもあります。
しかし、その記事を書いている人は何を参照しているのかというと、公式ドキュメント、書籍、ソースコードがほとんどだと思います。
今のうちから日本語・英語に関わらず文章を読む体力をつけていきましょう。

言語、フレームワークやライブラリの概念モデルを掴むまで繰り返しドキュメントを読む

ここで言う「概念モデル」は 『誰のためのデザイン？』 で繰り返し使われているデザインの専門用語である「概念モデル」を指します。
以下は概念モデルの意味を簡潔に説明したものです。

極めて簡素化されたあるものがどのように動くかについての説明のこと

概念モデルは役に立っている限り完全なものでなくても良く、正確である必要すらないことが特徴です。
例えば、デスクトップ画面にはファイルやフォルダを配置できますが、実際に PC の中に物理的なフォルダはありません。しかし、私たちはどれがファイルであるか、フォルダであるかを知ることができます。
それはデスクトップ画面の概念モデルを理解し、その概念モデルを説明できるからです。

言語、フレームワークやライブラリを理解する上で、それらの概念モデルを自分で構築することは極めて有用だと思います。
例えば Ruby on Rails では MVC アーキテクチャが採用されていますが Controller から View を出力する具体的な実装は知らなくとも render という API を呼び出すだけで特定の View テンプレートが表示されます。
この「具体的な実装は知らなくとも何が起こるかわかっている (= 概念モデルを理解している)」という状態が言語を習得するファーストステップに置くと成長のスピードが段違いだと思います。

なぜ概念モデルをファーストステップに置くのかと言うと、フレームワークやライブラリなどはプログラムの性質である「順次」「分岐」「繰り返し」が高度に抽象化され、隠蔽されていることが多いからです。
高度に抽象化された API を使用すると、処理の中で「飛躍」が起きます。
この「飛躍」を掴むことで、プログラムの性質の 1 つである「順次」として頭の中で処理することが可能になります。
飛躍なので必ず出発点と着地点があります。
出発点から着地点までの道のりを知らずとも、出発点と着地点の場所を理解するところから始めましょう。

では、どのように概念モデルを理解すれば良いのでしょうか。
それはドキュメントを繰り返し読むことが最短かと思います。
飛躍が起きる API とその出発点と着地点を理解するまで何度も読みましょう。

言語・フレームワークが提供する API についてのインプットは後回しにする

言語・フレームワークが提供する API についてはインプットを後回しにします。
(前項目で触れた「飛躍」が起きる API は概念モデルを掴む上で、先に習得しましょう)
なぜなら、前の項目で触れた言語、フレームワークやライブラリの概念モデルがわからないと話にならないからです。
どんなに言語やフレームワークが提供する API を知っていても、扱うものの概念モデルを知らないと API を使うところまで辿り着けないからです。

加えて API は覚えるものではなく、検索するものだというのが持論です。
使う頻度が高ければ自然と覚えていくので、検索して辿り着くことの方がむしろ重要です。

あくまで後回しという意味であって、必要ないというわけではありません。
扱う言語の概念モデルを掴んだら、どこかで網羅的に書籍でインプットすると開発が進めやすくなるかと思います。

最初から答えを覚えるのではなく問いから覚える

人によってこの方法の相性はあると思いますが、吸収率高くインプットするコツは答えではなく問いを覚えることだと思います。
ペーパーテストとは異なり、答えは検索すれば出てくるものです。
その時に検索する単語は覚えた問いの中に既にあります。
使用頻度が高くなれば自然と答えも覚えていきます。

例えば React には useState と useRef という API があります。

// useState は getter (第一要素), setter (第二要素) に分かれている
const [count, setCount] = useState(0);
// useRef は getter, setter に分かれていない
const countRef = useRef(0);

この 2 つの共通点と相違点は以下の通りです。

共通点

• レンダーを跨いで情報を保存する (普通の変数だとレンダーごとにリセット)
• 保存された情報はコンポーネントのインスタンスごとに固有である

相違点

• useState は値が変更されるとそのコンポーネントが再レンダーする
• useRef は値が変更されても再レンダーされない

上記の共通点・相違点が答えだとすると、この 2 つの API の問いは以下のように設定します。

• レンダーを跨いで情報を保存したい時 React が提供する API は何個ある？
  • A. 2 個
• その 2 個の API の名前は？
  • A. useState と useRef
• 再レンダー (値の変更を画面に反映) するのはどっち？
  • A. useState

まず問いを覚えることで、検索によって useState と useRef に辿り着くことが容易にできます。
ふとした瞬間 (歯磨いているとき入浴中など) に、レンダーを跨いで情報を保存したいときの API は何個あるんだっけか〜？という風に想起することがポイントです。

共有してもらったリンクは検索性高く管理する

PR レビューや、ふとした時に先輩から記事や書籍を紹介いただくことがあるかと思います。
それに目を触れることは大前提として、検索性高く管理して再度参照できるようにしましょう。
私は Raindrop.io を使用しています。
タグ付け、階層構造、記事のプレビューなどの機能があり、検索性高く管理することができます。

記事化 (文章化) するものとしないものに明確な基準を設ける

インプットしたものであれ、アウトプットしたものであれ記事化 (文章化) することは最も効率の悪いインプット方法であるというのが持論です。
なぜなら、単純に時間がかかるからです。
よく使用するメソッドは自然と覚えますし、言語の概念モデルは質ではなく量で獲得する方が効率的です　(書くよりも言葉として発する方が量をこなせます)。

API について記事化するのであれば、ドキュメントをモニター 1 にエディターをモニター 2 に持ってきて、ぶつぶつと繰り返し API が何をしているのか言葉にしながら実装する方が吸収率高くインプットできるように思えます。

因みに、技術的な記事に関して私は記事化する基準を現在 2 つ設けています。

• 重要だが触れる頻度が少ないもの
  • ex. 【SQL】NOT IN と NOT EXISTS の違い
• 概念モデルの具体をインプットしたとき
  • ex. 素の JavaScript でコンポーネントを作成してみて React の気持ちを考えてみる

アウトプット

参照する

以下をしっかり参照して実装を開始しましょう。

• 仕様書
• コード規約
• 類似処理があるコード
• ドキュメント
• ライブラリのソースコード (初めて使うとき、困ったとき)
• ライブラリの GitHub Issues (困ったとき)

説明できない実装はしない

類似処理のあるコードを参照するにせよ、ドキュメントを参照するにせよ、何をしているのか説明できないまま実装するのはやめましょう。
いつか理解できるようになると思っているとすれば、その「いつか」はいつ訪れるのでしょうか。
今この瞬間掴みに行きましょう。
概念モデルレベルの理解や説明で構わないので、しっかり説明できるようにしましょう。
例えば、医者が自身で説明できない処置をしていたらゾッとしますよね。
コードレビューを依頼するまでには、どのような処理をしているのか、なぜそのようにメソッドを切り出しているのかなど説明可能な状態にしましょう。

ORM が構築する SQL クエリを確認する

ORM を使用して DB に問い合わせる実装をするとき、必ずその SQL クエリを確認しましょう。
例えば ActiveRecord::Relation class には to_sql というメソッドがあります。
このメソッドは ORM で構築した SQL クエリを出力してくれます。
「ORM からなんとなくこんなクエリを」ではなく「SQL クエリから考えて ORM を使用する」ようにしましょう。
なぜなら SQL から考えることで、より効率的なクエリを ORM で実装できたり、バグを抑えながら実装を進めることができるといった利点があるからです。

早めにフィードバックを求める

手戻りは避けるが吉です。
自分でマイルストーンを設けて、そのマイルストーンにどう向かうか見えてきたタイミングでフィードバックを依頼しましょう。
DB 設計、ビジネスロジック設計、UI コンポーネント設計などです。(さらに細分化しても良いかもしれません)

ゆるいテスト駆動開発で実装を進める

ゆるいテスト駆動開発とは、テスト駆動開発のように全てのテストケースを記述してから実装をする方法とは異なり、メソッド単位で実装後にテストを書いていくという方法です。

1. エディターの一方のウィンドウに実コードのファイルを、他方のウィンドウに対応するテストファイルを開く
2. 実コード 1 メソッドを作成
3. 対応するテストファイルにそのメソッドのテストを書いて実行
4. ステップ 2, 3 を繰り返す

見えないものについて考えるよりも、見えるものについて考えた方がイメージしやすいはずです。
ゆるいテスト駆動開発は実コードが見える状態でテストを書くため、完全なテスト駆動開発よりも進めやすいかと思います。

では、ゆるいテスト駆動開発で進めると、どのような恩恵を得られるのでしょうか。
まず、不具合の早期発見ができます。
不具合は大きく分けて「入力が間違っている」か「出力が間違っている」かの 2 種類しかありません。
入力が正しく、出力が正しいことをメソッド A を作成した時点で確定させることで、そのメソッド A を使用する上位レイヤーのメソッド B を作成するときに、メソッド B に完全に集中できます。
メソッド B の実装中うまく動かなかった時に「メソッド A に不備があるかも？」という考えを持たなくて済みます。
「メソッド A に不備があるかも？」となった時点で、考慮する範囲がメソッド B からメソッド A とメソッド B に拡大してしまいます。
考える範囲が小さければ小さいほど問題解決までの時間が短くて済みます。
考える範囲を最小限に抑えるために、ゆるいテスト駆動開発を導入することを推奨します。

1 メソッドにつき 1 commit

1 メソッドの変更につき 1 commit を基本としましょう。
この commit には以下のファイルが含まれます。

• 変更したメソッドのファイル
• 変更したメソッドに対応するテストファイル

commit を小さくすることで後で困った時に小さく戻すことができます。
小さいは正義です。
commit 単位で実装範囲を限定することで、思考がクリアになります。
「今はこれをやる。他のことは考えない。」という風に。

デバッギングのために仕込むログの位置は熟考する

デバッギングのために仕込むログの位置は熟考します。 (3 ~ 5 分くらい)
位置が決まったらなぜその位置にログを仕込むのか、ボソボソと自分に説明します。
この情報が今わかっていないから、この位置にログやデバッガーを仕込めば情報がクリアになるはずだ。そして、この情報がわかるということは次のアクションではあれこれをすれば良い。
ここまで考えた上で実行します。

また、実行にはいくつか方法があります。

• アプリケーションを動かす
• テストファイルを動かす
• コンソール上で該当メソッドや特定の処理を動かす

この中で一番デバッギングしずらいのはアプリケーションを動かすことです。
なぜなら、いくつものメソッドの連鎖から検証したいメソッドまで辿り着くには操作含め時間がかかり、該当メソッドの入力データが曖昧だからです。
アプリケーションを動かす時はフロントエンドとバックエンドの疎通がうまくいかないときに選択すると良いです。

次に、テストファイルを動かす時はメソッドの引数のデータが複雑だったり、そのメソッドを実行して知りたい情報を得るためには DB のデータが必要な時です。
アプリケーションを動かす時に比べて比較的早く検証でき、また小さく検証できます。

最後にコンソール上で該当メソッドや特定の処理を動かす方法は一番最初に検討すべき方法です。
なぜなら、一度コンソールを立ち上げてしまえば、後はスムーズにコンソール上でメソッドの挙動を確認できるからです。
一番小さく早く検証できる方法です。
加えてメソッド単位だけではなく行単位で確認できることも、他の方法にはない大きなメリットです。

登壇を控える

新卒 1 年目からの登壇は控えました。
なぜなら準備、移動、イベント中の所要時間を考えると、シンプルにコストがかかるからです。
また OSI 参照モデルが「物理層」「データリンク層」「ネットワーク層」「トランスポート層」「セッション層」「プレゼンテーション層」「アプリケーション層」からなるように、私たちにもレイヤー構造があります。
そのレイヤー構造とは下から「自分」「チーム」「部署」「会社」「社会」です。
物理層がなければ、アプリケーション層が動かないのと同様に「自分」がなければ「社会」に通ずる術はありません。
そのため、地味かもしれませんが下のレイヤーからコツコツと貢献していくことで、上のレイヤーへの貢献にも寄与できる人物になることでしょう。

確かに社外の人とコミュニケーションをとることで、所属チーム固有のあらゆる習慣への偏りを避けることができるかもしれません。
しかし、その状態に至るほど現在関わるシステムを熟知しているのかと考えたとき、私自身その答えは No でした。
そのため登壇は控えていました。

コードレビュー

セルフレビューを行う

レビューをする前にセルフレビューを行いましょう。
セルフレビューをするにあたって Visual Studio Code の GiHub Pull Requests が便利です。
PR の File changed とは異なり変更があった箇所だけではなく、変更したものをファイル単位でその差分を見ることができるからです。

大きく 3 つの観点でセルフレビューをします。

• コード規約に反していないか
• 差分を見て不安になる箇所があれば、テストケースを追加したりデバッギングをする
• リファクタの余地がないか
• 最後に仕様書などを参照しながら考慮漏れがないことを確認

Conversation は Conversation する

PR の Conversation (会話・対話) は Conversation します。

• クリティカルな不備に対するコメントには、なぜ不備が生まれてしまったのか、今後改善可能な進め方は何か
• 提案コメントに対しては、その提案に対して自分がどのように考えているか (自分の実装と比較した時のメリデメ) 、提案を受けた箇所をそのように実装した経緯

たとえレビュワーが読まなくても、どう自分が考えているのかというアウトプットをすることは大切に思えます。

レビューが 2 往復以上したら負けという心づもりでいる

レビューが 2 往復以上したら負けという心づもりでいましょう。
2 往復するとき、細かくマイルストーンを置いてフィードバックを受けていない可能性が高いです。
先にも述べましたが手戻りは避けるが吉です。
小さく共有して、レビュワーがレビューする段階には実装イメージがレビュワーの中にあるとレビュー負荷が小さくなります。
小さいは正義です。

おわりに

共に頑張りましょう。