レビュアーとして早く成長する3つの方法　停滞を打ち破り、効率良く成長している実感を得るためのヒント

橋本氏の自己紹介

橋本遼太氏：今日は「レビュアーとして成長するには」というテーマで発表していきたいと思います。

今日話すことは、レビュアーとして早く成長する方法です。新人プログラマーは、自分の成長の方法の一例として、ベテランの方は「若手をこうやってレビュアーとして成長させれば」という育て方の一例として参考にしてもらえればなと思っています。

軽く自己紹介をします。橋本遼太なので、「はっしー」と呼ばれています。2023年で27歳になります。（スライドを示して）出身地はこんな感じで、今は岡山市に住んでいます。

趣味はいろいろあるんですが。あっ、イメージですね。今は金髪でひげも生えちゃって……。この時の僕はどこに行っちゃったのか（笑）。

そんな感じで、プログラマーが最初の職業じゃなくて、実はいろいろやってたどり着いている感じになっています。

先ほど説明したように、自分は情報系の学校を出たわけでもなく、未経験でプログラマーになったんですね。かつ、プログラマーになったのも2022年4月なので、新人の部類に入るかなと思います。

学校でも一般教養のプログラミングの授業を取った程度で、そんなにがっつり情報系のバックグラウンドがあるわけじゃないところからスタートしたので、今、新人として悪戦苦闘している方には、参考になるものがあるんじゃないのかなと思います。

（スライドを示して）MATLABは、あれは統計用の有料の……。言語みたいな感じのやつですね。

レビュアーとして成長するべき理由1　チームに貢献できる

（スライドを示して）目次です。「なぜレビュアーとして成長するべきか」というところから今日は話していこうと思います。

2つの理由があります。チームに貢献できるということと、プログラマーとしての力が伸びるというところがあります。

（スライドを示して）チームに貢献できるというのはけっこう大事で、新人のうちはどうしても頼る一方になってしまいがちだと思うんですよね。でも、健全な関係というのは、頼られてこそ頼れるし、頼ってこそ頼られる。giveされたならgiveを返すところになると思います。

この後も説明するのですが、新人にとってはコードレビューはgiveする手段の有力な1つになります。giveできていれば、頼る時も申し訳なさが減ります。

どういうことかというと、貢献できていない時に頼るのは申し訳なくなっちゃうんですよね。でも、聞いたら1発で解決することも多いです。

これは僕の場合ですが、自分に貢献意識があると、同僚や先輩に遠慮なくさっさと聞けるようになったんですよね。なので、チーム貢献が自分のためにもなるということです。チームに貢献できるのは大事だよというところです。

レビュアーとして成長するべき理由2　プログラマーとしての力が伸びる

それから、「プログラマーとしての力が伸びる」ことですね。すごく簡単なところから始まるのですが、世の中には、良いコードと悪いコードが存在します。悪いコードは、例えばDRYなプログラムじゃなくて、プロジェクト内に同じコードが何ヶ所もある。

こういうものがあると、「ここの名前をちょっと変えたいな」という時や、「表示するものを変えたいな」という時に、いちいち全部コードを全文検索して、漏れがないかみたいなチェックをしていると、やはり労力がかかります。

あとは「hiduke = 12」とかいう、わけのわからない変数があったりしますね。hidukeとかじゃなくて、例えば誕生日だったら「birthday」みたいに置くとか。

「コードは動くから別にいい」わけではなくて、良い書き方と悪い書き方があるということです。ちなみに「hiduke = 12」は、実際に僕が見たことがあるコードです（笑）。

なので、機能を実装するとか、メンテナンスしやすく機能を実装するという、この2つの間、つまり良いコードと悪いコードには、大きな隔たりがあります。

ということで、レビュアーとして成長すると、良いコード、悪いコードがわかるようになってきて、ひいては良いコードが書けるようになっていきます。

なのでレビュアーとして成長しよう、ということになります。

レビュアーとして成長する方法1　技術書を読む

では「どう成長するの？」というところですね。これは「当たり前やん」と言われると思うのですが、「どうすればレビュアーとして成長できるか？」というと、「技術書とレビュー」になります。

まずレビューの大前提から話していきたいのですが、自分の持っている引き出しでしか指摘はできません。超能力で天から天啓が降ってきてとか、そういうことはほとんどあり得ないからです。

なので、結局が自分の持っている引き出しをいかに多く、しかもそれらを使いこなして、すぐ取り出せるようにするかが大事になります。

ということで、「技術書を読もう」ですね。

方法1。技術書は、引き出しを増やす効果がめちゃくちゃ高いです。どうしてかというと、技術書は、筆者がある分野について情報を体系的に「これが必要だな」というものを取捨選択してまとめたものなので、その分野についての引き出しを広く体系的に習得できるところにすごく価値があります。

ただ、これには注意点があって、本を読むのはけっこう要求ステータスがあるなというのに最近気がつきました。いかに名著と呼ばれていても、いきなり理解できるかは別だと思っていて、背伸びしすぎると効率が悪いなと今は思っています。「1年後に読み直して内容が腑に落ちた」ということがやはり普通にあるからです。

（スライドを示して）どういうことが起こったかというと、これは某『リーダブルコード ―より良いコードを書くためのシンプルで実践的なテクニック』ですが、ネットで「エンジニアは読むべき」と書かれていたので買いました。入社直後の自分では、正直ピンと来ないんですよね。よくわからない。

「こういうコードが書いてあるから、なんでいいのか、悪いのか」みたいなところがピンと来ないんですよね。ただ、1年後に読み直してみたら、おもしろく読めるんですよね。

一方で、1年後に（この本を）読んだ時に、レビューで指摘されたことがあることが多く書かれていて、本を読んでいれば早く気づけたことも多かったんじゃないかなと思っています。なので、読むのに最適なタイミングがあるはずだと。

今回思ったのが、本の内容を理解できない時は、そもそもまだ読むべきではない時ということになるのですが、楽しく読めるのは、すでに知っていることが多いから楽しいんじゃないかということです。

なので、自分の場合は「理解できるが少し読むのが苦しい」くらいの頃に読むのが、一番差分が取れるんじゃないのかなと思って、この基準を持って本を読もうと思っています。

レビュアーとして成長する方法2　自分のコードのレビューを受ける

次に「レビューを受ける」と「（レビューを）読む」というところですね。「レビューを受ける」というのは、題材が自分のコードになるので、自分に今必要な引き出しを増やしてくれます。かつ、自分のコードの悪い点をダイレクトに改善できる効果があります。

レビュアーとして成長する方法3　レビューを読む

次が「レビューを読む」というところですね。これも題材がチームや会社のコードになることが多いかなと思うので、チームのコードの価値観がわかったり、あと単純に、自分だけじゃなくてチーム全員の分があるので、量が多くて、多くインプットできます。あとは、ほかで指摘されていることをあらためて察知できて、同じ間違いを事前に防ぐ効果があります。

レビューを受けるだけの頃からレビュアーとしての成長は始まっている

では「レビューを受ける」の実践編ですね。今回は、レビュアーとしての成長という話には結局なるのですが、レビューを受けるだけの頃から、レビュアーとしての成長は始まっています。なので、それを意識することでけっこう変わってくるものがあるんじゃないかなと思います。

レビューをもらったら意味を理解しようとすることが大事

「レビューをもらったら、まず意味を理解しよう」ということがすごく大事なことになります。レビューは「修正します」と言って修正をして、「修正しました」と言うのだとダメです。最初の頃はどうしても「修正します」と言って修正して終わりになりがちだと思います。ですが、実際には「なぜそうなのか」を理解したり、議論したりすることがすごく大事になります。

「内容を理解しろってことでしょ？　はいはい」となるのですが、（内容を理解するということが）新人には難しいんですよね。

これがなぜ起こるかというと、レビュアーにとっては当たり前すぎて伝える必要がないと思っている情報があったり、あとは、そもそも何がわからないのかを伝えないと、レビュアーが何を教えるべきかわからないことはかなりあると思います。

つまり、レビューのコメントはいつも完全なものではなくて、自分で情報を取りにいってようやく完成するものもけっこうあります。なので、わからない時はコミュニケーションを取って、わかった気になったり、なんとなくで通り過ぎてしまうのはやめましょう。

「わかった気になっている」の改善方法

「わかった気になっている」というのも、自分では判断できないのがかなり恐ろしいところで（笑）。「直したんだけど違いました」ということが普通にあります。「なぜ『なぜ？』っていうところまで？」という話になるのですが、「なぜ？」まで理解して落とし込めると応用が利くので、ほかに展開ができます。

逆に「なぜ？」というところまで落とし込めないと、1対1対応になってしまいます。例えば「これはこれにも適用できるな」というものがあると、その時に、違う似たようなものにも展開ができます。それができないと、「これはこれに対応しているから」ということしかできなくなり、応用が利かなくなって良くありません。

先ほどの「わかった気になる」の改善の方法の1つですが、もし可能であれば、最初の頃は対面やZoomなど、リアルタイムでレビューを受けると良いと思います。

最終的にテキストで質問するよりも時間がかからないので、結果的に早く終わるのと、あと、これはコードは関係なくて、エディタの使い方やショートカットなど、プログラムだけではわからない改善点を教えてもらえることがけっこう多いです。なので、最初の頃は、リアルとかリアルタイム、Zoomとかでレビューを受けることを僕はお勧めします。

1行のレビューから始める

「コードレビューをしよう」というところになっていきます。「小さく始めよう」ですね。「コードレビューを始めます、レビュアーとしての活動始めます」と言って、最初にいきなり全部やろうとすると、まずパンクします。

例えば自転車を練習する時にどうするかというと、いきなり乗ろうとしないで、まず補助輪を使ったり、足をつけて地面を蹴ったりするところから始めますよね。

僕の失敗例を話そうかなと思います。新人の僕は「とりあえずコードを読んで、気がついたところを指摘しよう」と全部読もうとするんですが、全部やろうとすると、いろいろなことを気にして、気にして、結局集中力が落ちて、最終的には、コードが目を滑っていきます。

そして、最終的に15分も経ったけれど、「なんの成果も得られませんでした」となります（笑）。15分のコードレビューで成果が得られないと、本当になにも得られないんですよね。コードを書いていると（そのコードを見て）「これはできない」みたいなことがわかるのですが。

なので、こうならないためにはどうするかというと、まず、1行でわかることから始めるのが良いと思います。

例えば「シングルクォートとダブルクォートを使い分けているか」とかです。Rubyだとダブルクォートで挟んでいるか、シングルクォートで挟んでいるかはけっこう変わってきます。

あとはファイルの最終行は改行で終わっているか、putsとかconsole.logみたいなデバッグで使ったコードが残っていないか、配列を取ってくる時にorderをつけて順番を担保できるかとか、こういう点はその1行のみで独立しているので、単なる間違い探しとして発見できます。

こういうことを何度も指摘していると、コードレビューの時に自然と気がつくようになって、それがだんだんオートモードになっていきます。見たら違和感として気がつくようになっていく感じですね。ほかの部分に意識が割けるようになっていくので、引き出しの量じゃなくて、スピードも上がっていきます。

そうなると、1行から複数行へという感じにどんどん（コードレビューが）できるようになっていきます。

設計・メンテナンス性は「実感」で必要性を理解する

「設計、メンテナンス性っていうのはどうなる？」というと、本を読んで知識を入れるのも良いのですが、DRYにしておくことの良さや、読みにくいコードのクソさを実感しないと、結局必要だとは思えないんですよね。

多くの人間は、必要だと思うまで本当の意味で認識ができません。だから、同じことを言われていても、「このことか」（と思うだけ）とか、聞いているけど聞き流しちゃうみたいなことが起こっちゃうんですよね。

では、どうやったら必要性がわかるようになるかというと、自分でアプリをイチから作ってメンテナンスをするのがけっこういいかなと僕は思います。

クソコードやクソ設計をどうしても含んでしまうので、それに困ってキレると、次回から同じことはしないようになるし、コードや設計というよりも、メンテナンス性をちゃんと考えるのも大事なんだと気がつくことができます。これはほぼ実体験に近いですね。

新人がわからないなりに、貢献する方法

最後に「わからないなりに、貢献する方法」というものがあります。ここまでのことは、スキルが上がらないと結局できないことだと思います。

「ここがわかりにくい」という言葉ですね。良いコードというのは、理解しやすいコードです。新人でも理解できるコードであれば、それは理解しやすいコードになるので、「ここがわかりにくい」というコメントも、レビューをする時に役に立ちます。

なので、「ここがわかりにくい」と言うだけでも、コードレビュー、レビュアーとして貢献できることになると思うので、ここから始めてみるのもいいんじゃないかなと思います。

プログラミングは努力が成果に結びつきやすい

「終わりに」です。すでに3分オーバーしているので手短に進めます。

結局「本を読んでコード書いてレビューもらってレビューして」というのをやった分だけ伸びていくので、今日の話は、その効率をどうやって上げるかとか、無駄になってしまうことをいかにしないかということになるんですね。

ただ間違いないのは、プログラマーという職業は、プログラミングという面では、努力が成果に結びつきやすいと思っています。だから、成長している実感が持てて楽しくなるし、逆にいうと、成長している実感があればそれを楽しめるということだと思うんですよね。

なので、今日の話がみなさんが停滞を打ち破り、楽しく成長するためのひとかけらのヒントになればうれしく思います。

以上で発表を終わります。ありがとうございました。