会社員になってお仕事としてソフトウェア開発を始めたころ、ぼくにとってコードレビューは当たり前のものではありませんでした。幸いなことに、なにかのタイミングで当時ぼくが属していたチームのリーダーが「コードレビューをやりましょう」と提案してくれて、それで、会議スペースに液晶ディスプレイを設置して、ソースコードを画面に映して、チームメンバーで集まってあれこれと言い合う時間を過ごせました。これがきっと、ぼくとコードレビューの出会いです。おかげでぼくは「コードレビューって、ありがたいものなんだな」「コードレビューがあることで回避される悪いシナリオがたくさんあるな」と思えるようになりました。
気付けばあれから 10 年以上が経っていて、ぼくらの業界におけるコードレビューの認知度はどんどん上がり、実践している現場もどんどん増えてきたように感じています。今では「ふつう、やるよね？」と捉えている人も多いかと思います。そんな時代にソフトウェアエンジニアになった人々をここでは「コードレビュー・ネイティブ世代」と呼んでみることにしましょう。もちろん「デジタル・ネイティブ世代」になぞらえて。
コードレビューのない世界
会社員になって、研修の段階でコードレビューを教わった真面目な人々は、コードレビューがない状態でのソフトウェア開発の経験がほとんどなかったりします。
以前、ソフトウェアエンジニアの研修の様子を眺めていたとき、彼ら彼女らのふりかえりで「コードレビューに多大な時間を要してしまった」という内容が Problem として挙がっているのを目撃しました。そこでぼくは「じゃあ、コードレビューをやめてみたら？それで解決するんじゃない？」と提案してみました。そうすると「えっ…？」といった反応で、コードレビューをしないという選択肢に驚いたようでした。研修の過程で「コードレビューは、必ずするもの」と認識したのでしょう。勝手に省いてはいけないとも思ったのかもしれません。
コードレビューにせよ、バージョン管理にせよ
コードレビュー、やる場合とやらない場合のそれぞれのメリットとデメリットを整理して、自分たちにとってお得な方を選んだらいいですよね。判断すればいいはず。まともに判断するためには天秤の皿に乗せるものたちのことをよく知っておく必要がありますから、やる場合、やらない場合、双方を経験しておくとよいでしょう。
すでにお気付きの通り、コードレビューをすべて「バージョン管理」に置き換えてもこの文章の論旨は変わりません。自動化テストでも、継続的インテグレーションでも、継続的デリバリーでも、アジャイルでもスクラムでもいいかもしれません。なにかしらの道具を使うときは、使わない場合と比較してなにがどう違うのか、メリットとデメリットはどんな感じなのか、理解しておくに越したことはありません。
道具にふりまわされずに、道具をうまく活用していきたいものですね。
試しに捨ててみる
立場上、さまざまなチームの人々から「いま、チームにおいて◯◯がうまくまわっていなくて…」と相談を受けます。コードレビューの運用についての相談もよく受けます。
そんなとき、一度は「じゃあ、一度やめてみたらどうですか？」と進言します。もしやめることに強い抵抗感を覚えるとしたら、なぜそう感じるのかを言語化してみると気付きがあります。「そっか、やめていいのか」とあっさり思えるのなら、やめてみましょう。そうして 1 週間 2 週間と過ごすと、やはり気付きがあります。失ってみて初めて気付く、というやつですね。そこで拾える気付きが、あなたを、チームを、ひとつ強くしてくれるはずです。
道具に対する自分の感覚を持つ
ぼくの身近なところにはぼくが心配しなきゃいけないような若手はほとんどいないので、杞憂ではあるものの。あえて心配事を挙げるとしたら、それは「よく採用されている手法から外れる」ことではなくて「自分の頭で考えられなくなる」ことです。後者に比べれば前者は微々たるものです。
誰かに与えられた道具を使っているとしたら、それがなんなのか、なんのために存在するのか、ぜひ考えてみてください。あなたにとって役立つものなのかどうか、どのように役立つものなのか、ぜひ言語化してみてください。
で 99 円を送金する