解決策の探求
問題を解決するためには、まず知識を増やす必要があると考えました。
とりあえず、大型書店で役に立ちそうな本を探すことから始めました。「これは！」と思う本を見つけたら、購入して通勤時間に読みふける日々をしばらく続けました。さまざまな本を読んでみた結果、内容が抽象的だったり、本当に役に立つのかどうか分からなかったりと、自分の仕事とマッチする答えはなかなか見つかりませんでした。
しかし、本を読んだおかげでさまざまな手法を知ることができました。せっかく本を買ったのに活用しないのはもったいないと思い、なんとか使えないかとあれこれ思索してみました。その結果、本に記載されている手法をそのまま使うのではなく、自分の仕事に合わせてカスタマイズして使うことを思いついたのです。
どの方法を試すか考えてみる
初めて改善を実践したとき、私が参画していたプロジェクトは、次の様な状況のものでした。
| 開発対象分野 | 組込み系 |
| 言語 | C++ |
| 人員数 | 私を含め2名（リーダー＝私） |
| フェーズ | メンテナンス |
| 時期 | 今（2007年）から数年前 |
当時、現場では十分なテスト技法やレビュープロセスが確立できておらず、プログラムミスによる計画外の作業が発生し、作業時間が増加していました。
この問題に対処するべく、まずは単純なプログラムミスを減少させる方法を考えました。その結果、簡単かつ有効な手段として、「コードレビュー」が適していることに気がつきました。
実際に動作するコードをレビューすることは、製品の品質確保に直結します。また、テストフェーズ前に実施することで、コードレビューとテストによる二重のチェックとなり、信頼性がより高まります。さらに、プログラマーレベルの担当者でも実施することができ、新たな教育を実施する必要がほとんどありません。必要な資源も、開発者とレビュアー、そしてソースコードのみのため、比較的簡単に実践することが可能であると考えました。
うまくいくか試してみる
うまく行くかどうか、とにかく試してみるしかありません。下記の通り必要最低限のルールを決め、まずは実践してみることにしました。
| 対象 | 新規追加／更新／削除を行ったコードすべて |
| 実施タイミング | コンパイル完了時（単体テスト前） |
| 実施方法 |
|
| レビュー内容 | コーディング規約、メモリ破壊、NULLポインタアクセス、初期化漏れ、処理効率、機能漏れなどがないかといった観点で、コードの差分を2人で確認する |
| 終了判定 | 指摘事項がコードにすべて反映されているか確認する |
自分自身、それまで苦労して身につけたコーディングスキルに自信を持っていたため、コードレビューに大きな価値を見出せていませんでした。しかし、いざコードレビューを実施すると、自分には無い視点でコードを見ていただき、非常に多くのフィードバックを得ることができました。実際に機能抜けや、処理効率の改善箇所などの指摘もあり、非常に有効な手法であること実感することができました。
