生産性が高いと大抵の問題は解決する

これは Matz が言ったらしい。どういった文脈で言ったのか(本当に言ったのか)は不明だが、私も同じことを思っていて、ドキュメントスキル、マネジメントスキル、マーケティングスキル等がポンコツであっても、生産性が高ければ割と何とかなることが多い。そんなことをマネジメント畑の人や経営者に言うと絶対に怒られると思うが、単純なソフトウェアエンジニアリングをやっていく上で、最後に頼れるのは圧倒的な生産性だと思うし、何より生産性が上がると仕事は楽しいし、振ったスキルポイントの恩恵を最も早く感じられるのも、恐らくプログラミングスキルだ。

プログラマーの仕事だってどんどん消えていくから別方向に舵を取れという人もいるけど、そこそこの生産性があれば食っていけなくなることもないと思う。そこそこの生産性を持ったプログラマーの雇用がなくなる時代が来たら、もう人間はあまり働かなくても良い時代なんじゃないだろうか。

生産性とコードの美しさ

生産性とコードの美しさは直結すると思う。美しいコードを書ける人じゃないと契約してくれない顧客もいる。勿論、見た目上の美しさだけでなく、必要なテストが必要な分量書かれているか、そのプログラミング言語やフレームワーク、あるいはプロジェクトの文化に沿ったコードになっているか、パフォーマンスに問題はないか、設計において選択するデザインパターンは適切か、ユーザーインターフェースやデザインが適切か、等も大切だ。

じゃあ、プロジェクトの異なる皆のコードを一斉に美しくするためには何をすれば良いか、となればコードレビューしかないと思う。技術力のない人だけで構成されるプロジェクトは必ず出てくるので、それらを救ってやるためには外部からコードの品質を審査するしかない。こうしなければ業務時間内の技術力はいつまでも上がらないわけで「お前ら業務時間外に勉強して技術力上げろよ」みたいな話になる。冗談ではない。業務時間外に業務に関する勉強なんて論外だ。業務に必要な技術は業務時間内に習得できるべきだ。

コードレビュー浸透までの壁

面倒なプロセスが1つ増える問題

レビューイ側からすれば、コードを書く度に1つ壁を挟まなければならなくなる。これを面倒だと思うのは当然だ。こればかりは、レビューによる即効性のある恩恵をレビューイに与えるしかないと思う。

ただ、この恩恵の感じ方は人それぞれだ。レビューによってコードが美しくなっていく、知識が増えていく様を楽しめる人もいるし、指摘によって重大な問題を回避できたとか、テスト書けって言われたおかげで後々助かったとか、顧客に褒められたとか、そういった外的要因によって恩恵を感じる人もいる。

これは今のところ迷宮入りだ。面倒だと思われない、あるいはレビューを必要だと万人に感じてもらう方法は思い浮かばない。以降書くことも大体思い浮かばないのだが。

レビュアーの時間が取れない問題

レビュアーも自分の仕事があるので、レビュー依頼をしても誰も見てくれない、ということはある。2日分ぐらいの指摘が一度に一気に来るとレビューイは萎えるので、溜め込まないようにしなければならない。また、単純に今 Pull request 出してるものがマージされないと、次の開発に進めない、なんてこともあるかもしれない。

レビュアーの負担を減らす1つの施策は、コーディング規約の自動化だ。ブラケットの内側に半角スペースがないとか、慣習に沿ってないとか、コードの振る舞いや品質に直接的な影響を与えない指摘はする方もされる方も辛い。Ruby on Rails だったら rubocop と guard で自動チェックするようにしてもらったり、CI で push を reject したりして、できるだけレビュー前に悪いコードを弾けるようにしておけば、レビュアーも本質的なコードの振る舞いに集中できる。

叩かれすぎて凹む問題

例えば、5行しか書いていないのに5つ指摘が付いたりすると、私のようにメンタルの弱い人は凹む。また、経験年数の多い人が経験年数の少ない人から指摘されると憤りを感じるかもしれない。

ここは正直人間的、感情的なアプローチを取るしかない気がする。普段からレビューイにリスペクトの姿勢を見せるとか、指摘コメントの末尾に絵文字を付けるとか、:ok_woman: を美少女の LGTM GIF にするとか、そんなヒューリスティックが意外と有効だったりする。

顧客のコードを丸ごと社内公開はできない問題

いくら社内開発であれ、セキュリティ的な事情でプロジェクトメンバーのみにしかコードを公開できない場合がある。ここで、プロジェクトメンバーに有識者がいなければ地獄の始まりだ。

この問題は解決の方法がわからない。メソッド単位などのコードスニペットを抜き出して、公開しても問題のない範囲でレビューを行うことはできるかもしれない。ただ、スニペットに対して Pull request によるレビューは難しそうなので、まずどのようなツールを使えば良いか分からない。また、スニペット単位のレビューでは、よほどカプセル化されたコード等でなければプロジェクトの背景を取り違えたり、公開できない箇所の設計に引っ張られてる箇所を検出できなかったり、いろいろ辛そうである。

リポジトリ問題

さすがに全てのコードを OSS にするわけにはいかないので、プライベートなリポジトリを作る必要がある。ただ、社員全員でプライベートリポジトリを運用しようと思うと、GitHub にも Bitbucket も結構な金額がかかる。コードレビューで生産性や技術力が高まった実績もない状態で、そのお金を捻出してもらうことはできない。

無制限のプライベートリポジトリ、無制限のユーザーを無料でとなると Gitlab Cloud しか選択肢がないように思えるのだが、これがとても遅い。最近早くなったという話をちらっと聞いたが、確認はできていない。また、master は GitHub で運用することが多いと思うので、リモートリポジトリを複数サービスで運用するのは結構辛みを感じると思う。とはいえ他に選択肢がないので Gitlab Cloud で運用を始めてみるしかない。