レビューのアウトプットは、レビューアのレベルを超えない（４）

私自身が専任のレビューアとして、一年間以上コードレビューを行ったことがあります。多い時には、週に4日で終日レビューをするという日々を送っていました。それは、2000年から2002年の中頃まで続いていました。対象とするコードはすべてC++でした。

C++で書いた経験がほとんどない技術者がレビューを受けながら製品開発を行っていくのですが、レビューの回数を繰り返すことで、確実にスキルが上がっていきます。

最初の頃は、スタイル関連の細かな指摘も含めて多くの指摘を受けるのですが、回数を重ねるごとに減っていきます。何も学習をすることなく同じことを何度も指摘を受け続ける人は、一般にはいません。その結果、コードレビューではより本質的なレビュー、すなわち、処理が正しいかとかエラー処理が正しいかという点に集中することができます。

レビューアとしてレビューを長い期間続けていると、各人のスキルが把握できてしまうのと、スキルの向上を知ることができます。ただし、スキルがどの程度上がっているかに関しては、レビューアとしての主観であり、数値化するのは困難だったりします。

逆に言えば、エンジニアのスキルを知るには、コードをレビューし続ければ良かったりします。コードの質だけでなく、質問に対する受け答えや、説明の方法などで総合的に知ることができます。スキルを把握できれば、仕事の難易度に応じて割り当てができるようになります。

正誤表更新『Effective Java 第2版』

『Effective Java 第2版』の正誤表を更新しました。

http://www001.upp.so-net.ne.jp/yshibata
http://www001.upp.so-net.ne.jp/yshibata/myhomepage/errata/ej2eerrata.html

レビューのアウトプットは、レビューアのレベルを超えない（3）

ソフトウェア開発に従事して、開発チームや組織内でコードをレビューすることを私自身が実践したのは、ソフトウェア開発の経験の中でかなり後になってからです。実際には、1999年後半か2000年前半ぐらいだと思います。それまでは、チームとしてコードをレビューすることはありませんでした。

記憶が定かではありませんが、まず、着手したのは「Code Review Guide」を書くことでした。それと同時に、プロジェクト用に「C++ Coding Standard」を書いて、コードレビューの重要性を教育で教えて、さらに、現場でコードレビューを実践するということを日々行っていました。

コードレビューは、コーディングという行程において、できる限り品質を作り込むために行うものであり、一行一行処理内容を確認しながらレビューしていました。それにより、後工程であるテストの工数を減らすためです。当時は、テスト駆動開発ではなく、実際のハードウェアで手作業でテストせざるをえない環境でしたので、レビューで品質を作り込むというのは非常に重要でした。もちろん、すべてのバグがレビューで見つけられる訳ではありません。

開発チーム全体のスキルを上げるためには、一対一のコードレビューではなく、複数参加のレビューの方が知識の伝達には効率的です。その結果、私が当初指摘していたことを、徐々に他のメンバーも指摘するようになります。つまり、コードを見る時の視点がコードレビューを通して良い方向に変わっていくわけです。

一方、開発プロセスでコードレビューを実施することが決められていて、レビューしたことを報告しないと次のステップへ進めない場合に、レビューが形式的になっている場合があります。4、5名で数回レビューしたはずなのに、一対一で私にレビューしてもらいなさいと指示されたのでレビューをお願いしますと言われたことがあります。その時に、チームでレビューしているのになぜ私がまたレビューしないといけないのかを聞いてみると、一行一行の処理内容を確認しながらのレビューはしていないとうことでした。

このような一対一のレビューは、複数のメンバーに同時に知識を伝えることができません。スキルが十分でないメンバーが多い開発組織では、きちんとしたレビューを複数メンバーで地道に継続して、全体のレベルの向上を図っていく必要があります。しかし、そのような活動をしないと、チームメンバーのコードレビューに対する視点は全く向上しないことになります。

さらに、きちんとしたレビューを開発メンバーが受けることがないと、コードレビューはこの程度で良いと思うようになり、プロセスでレビューすることを強化しても、コードの品質は上がらないし、開発組織全体のレベルも向上しないことになります。その結果、後工程のシステム全体の結合テストで多くの不具合が発生して、その対策として、さらにプロセスが強化されて様々な報告が求められるようになるかもしれません。しかし、もともときちんとレビューできない組織では、強化しても何の役にも立たず、むしろ、報告作業のためにコードレビューにかける時間を減らすことになり、状況を悪化させるだけだったりします。

レビューのアウトプットは、レビューアのレベルを超えない（2）

開発組織としてメンバーのスキル向上を行うためには、経験豊富なエンジニアの知識をレビューという形式で伝えていくことが重要です。そして、たとえ初心者であっても、繰り返しきちんとしたレビューを受け続けることにより、成長させていく必要があります。コードレビューは、ソフトウェアの品質を作り込む場でもあるのですが、同時にエンジニアを教育する場でもあったりします。

しかし、開発組織がコードレビューに関して否定的だと、開発プロセスでレビューすることが規定されているというだけの理由で、初心者レベルのエンジニアだけでレビューを行わせたりします。ここで「初心者レベル」というのは、ソフトウェア開発経験年数が少ないという意味ではなく、きちんとしたコードを書くということに関して初心者レベルという意味です。

コードの品質に興味がない人がリーダとして開発チームをリーディングしている場合には、開発が遅れてくると大量に初心者レベルの技術者が投入されて、きちんとしたレビューも行われることなく、大量に技術的負債を増産させる可能性があります。

大量に技術的負債を増産されると、実際にはバグが多く作り込まれて、結果として開発が遅れてしまうのは明らかなのですが、以前に書いたように、実際の開発の現場で次のように言われてしまうと、コードをレビューする気力は失われてしまいます。

レビューを受けてきたことがない人のコードをレビューして、色々と指摘して、最後は一緒にペア・プログラミングして、Eclipseの効率的使用法も教えながらコードを良くしたのに、「納期が厳しいのに本人に余分な工数がかかった」と言われてしまいます。

コードレビューを肯定するようなリーダではなく、否定するようなリーダであれば、結果として優秀なエンジニアは他のエンジニアのコードをレビューをする意欲を失っていきますし、結果として開発組織の成長は望めなくなります。そして、技術的負債を積み上げていき、デスマーチを推進することになり、優秀なエンジニアは去って行くことになります。

レビューのアウトプットは、レビューアのレベルを超えない

拙著『プログラマ”まだまだ”現役続行』では、コードレビューに関して以下のことを述べています。

　コードを複数の開発メンバーでレビューした結果のコードの質は、レビューに参加したレビューア以上のものにはなりません。つまり、いくらコードレビューが効果的だとはいっても、プログラミングの初心者どうしが集まってお互いのコードをレビューしたところで、その質には限界があります。
　ペアプログラミングによって、コーディングを行いながらレビューした場合も、まったく状況は同じです。つまり、ペアプログラミングによってコードの品質が向上するかどうかは、誰とペアプログラミングしたかに依存します。
　時間をかけてコードをレビューするのですから、レビュー結果として高い質を求めるためには、対象とする領域に関する技術知識を持ち、読みやすいコードを書くことに関しても知識とセンスを持つソフトウェアエンジニアがレビューアとして参加する必要があります。
　しかし、現実には開発プロセスとしてコードレビューが完全に取り込まれていなかったり、多くの初心者が中心となったソフトウェア開発が行われたり、レビューアとなれるレベルに達する前に開発から管理業務へ移ったりする結果、レビューアが育っていないというのが、多くの開発現場の実情ではないでしょうか。
　特に、コードの読みやすさに重点を置かないレビューを実施してきた、あるいは、全くレビューを実施してこなかった開発組織では、レビューアとなれるソフトウェアエンジニアはほとんどいないかもしれません。
　開発組織として、実質的で効果的なコードレビューを行うためには、レビューアとして高いレベルのソフトウェアエンジニアが不可欠です。

『プログラマ”まだまだ”現役続行』（204頁）

たとえば、先日、5名で2回コードレビューされたコードをたまたま見てみました。私はレビューには呼ばれていなかったのですが、ちょっと読んで何をしているのかと調べてみたら、明らかに機能していない実装（つまりバグがある実装）に気づきました。

私からすると初歩的なバグなのですが、レビューでは誰も指摘していないという状態です。初歩的なバグと言っても、正しい知識を持っているかどうかによるものであり、持っていなければ見落としてしまう種類のものでした。

書籍『SEが20代に身につけておきたいこと』

SEが20代で身につけておきたいこと (技評SE選書)

• 作者: 荒井 玲子/深沢 隆司/前田 卓雄/柴田 芳樹/三宅 和之
• 出版社/メーカー: 技術評論社
• 発売日: 2011/03/26
• メディア: 単行本（ソフトカバー）

新たに発売されます。私の部分は、雑誌『System Engineer, Vol.1』に掲載された記事です。私の著書ではないですが、インタビューが掲載されている本としては、以下の書籍があります。

SEの読書術 -「本質を読む」力を磨く10の哲学

• 作者: 浅海 智晴/荒井 玲子/後藤 大地/柴田 芳樹/萩本 順三/原田 洋子/平鍋 健児/二上 貴夫/山崎 敏/山本 啓二
• 出版社/メーカー: 技術評論社
• 発売日: 2006/01/30
• メディア: 単行本（ソフトカバー）

朝2時起きで、なんでもできる! (3)

• 作者: 枝廣 淳子
• 出版社/メーカー: サンマーク出版
• 発売日: 2004/10
• メディア: 単行本

枝廣 淳子さんの本では、本名ではなく仮名で登場しています。

基礎教育（２）

「基礎教育」で、前の会社では「データ構造とアルゴリズム」を新卒新人に学ばさせるために、書籍『プログラミング作法』の第2章を行わせていたと書いています。

新卒新人が私の部門に配属されると、最初に書籍「プログラミング作法」の第2章を、私が作成した「勉強会ノート」に従って学習させます。プログラミングの問題も含め、トレーナーからのＯＫが出るまで何度でもやり直しさせていました。

したがって、実際の開発業務に従事してから、基礎的なアルゴリズムに関する質問をしてくる人はいませんでした。しかし、今の会社では新卒新人に対してデータ構造とアルゴリズムの教育はほとんど行われていません。さらに、そのような教育は必要なく、開発の現場で鍛えるのが重要だと言うマネジャーがいたりします。しかし、開発の現場では担当業務を行うだけであり、業務に必要のないことは学ばなかったりします。

結果として、実際に開発しているソフトウェアで使用する、あまりにも基礎的なアルゴリズムの問題を私に聞きに来る人※1がいたりします。問題なのは、本人だけでなく回りの開発組織のメンバーのレベルも同じ可能性があるということです。

講演や教育で話をしている「ソフトウェアエンジニアの心得」の中で、できるだけ若い早い段階で基礎的な「データ構造とアルゴリズム」を学ぶように話していますが、強制的に学習をさせないと、自発的に学ぶ人はかなり少ないのが現状だと思います。※2

※1　2分探索が適切な処理に対して線形探索で実装して、線形探索以外に良い方法はないのかと。
※2　今の会社で書籍『プログラミング作法』の第2章「アルゴリズムとデータ構造」を全部やりましたと報告してきた人は残念ながらまだいません。

Red, Green, Refactor

JUnitなどのxUnitフレームワークを用いてテストコードを書いて、実装してテストがパスするようになったら、実装作業が終わりではありません。その後に必ずリファクタリングをすることが必要です。しかし、教育などで「Red、Green、Refactor」と教えても、ソフトウェア開発経験の浅い人は、必ずリファクタリングを忘れてしまいます。

忘れてしまう理由としてはいくつかあります。

• 初心者の場合、与えられたプログラミングを行うだけで精一杯であり、テストコードがパスするようになった時点で終わった気になってしまう。
• 初心者の場合、そもそもどのようなコードが綺麗か汚いか判断できるほど経験を積んでいなかったり、書籍（『Clean Code』 や『Code Complete』など）で学んでいなかったりするので、テストコードがパスするようになった安堵感も加わって、自分で書いたコードを見直しても何も悪くないように感じてしまう。
• リーダや上司からリファクタリングしたかとか、するようにとかの指導を受けないようなソフトウェア開発組織で開発している。あるいは、コードレビューが実施されていても、コードの読みやすさを含めたリファクタリングの指摘まではされない。

特に初心者の場合、コードレビューで指摘された修正だけを行うだけだったりします。つまり、修正結果を見直してコードをさらに改善することを自分でできなかったりします。そのため、初心者に書かせたコードは、3、4回レビューしないとまともなコードにならなかったりします。

ここでの「初心者」には、私の「プログラミング言語Java」教育コースを修了したレベルも含まれます。したがって、修了したレベルの知識も持たない初心者を頭数だけ集めてソフトウェアを開発しても、まとなソフトウェアが開発できる可能性は低く、技術的負債を結果として残す可能性が大きくなります。

「Red, Green, Refactor」をきちんと実践できるようになるには、3年から5年の経験を積んでいく必要があるかと思います。もちろん、ソフトウェア開発に従事した年数が目安になることはありませんので、上記の理由に該当するような状態が続いているだけであれば、10年を経てもスキルは上がっていなくて初心者と同じスキルしかない可能性も高くなります。

歩数計

オムロン(OMRON) WellnessLINK対応歩数計 ブルー HJ-205IT-B

• 出版社/メーカー: オムロン(OMRON)
• メディア: スポーツ用品

以前使っていた歩数計が壊れてから、しばらく使っていなかったのですが、新しいものを購入しました。これを機にできるだけ歩くようにしたいと思っています。