オフショア委託先のレビューのやり方をチェックしていますか？

レビューのやり方は組織によって異なる

レビューは品質確保のための重要な手段です。
不良は実機テストで叩き出せば良いと言う人もいますが、実機テストですべての不良を摘出するのは大変です。
また、保守性に関わるものなど、プログラムの動作に影響しない不具合もあり、それらを摘出する手段としてレビューは非常に有効です。

しかし、レビューに注目が集まるようになったのは割合最近のことです。数年前から雑誌の特集や書籍が出るようになりました。
それまでもレビューの重要性は認識されていたはずです。ところが、やり方は組織によってマチマチで、これが正しいという方式はありませんでした。
「レビューなんて、そんな大層なものじゃない。作った成果物をみんなで確認するだけじゃないか。」と言われるかもしれません。
私は、ベンダー７社で構築するシステムの開発に携わったことがあるのですが、そのとき他社の人たちと一緒にレビューする機会が幾度もありました。するとやり方が違うのに驚きました。
例えば、ソースコード・レビューでは、以下のようなパターンがありました。

• 予め用意されている標準チェックリストを上から消し込み
• ソースコードを上から1行1行確認
• 単体テスト仕様書を消し込み
• 代表的なテストデータで、プログラムの動きをトレース

「こういうやり方をするんですね。」と相手にいうと、大抵「おたくは違うやり方ですか？」と驚いていました。
組織の中にいると、他の組織のことは案外分からないものです。

また、レビュー対象物のどこを主に見るかなど、細かい進め方になると会社の中でも異なっています。
その辺りはマニュアル化もされていないので、実際に参加して見て覚えてもらうしかありません。

オフショア開発でも一緒に参加して教えるのが望ましい

あるトラブルプロジェクトの支援で中国のオフショア開発委託先を訪れたときのことです。
主たる仕事は進捗管理や問題管理などプロジェクト管理の支援だったのですが、その合間にコーディングレビューとチェックリスト（単体テスト仕様書）レビューに参加しました。

プロジェクタに写したソースコードを担当者が説明していくという方式です。説明はかなり粗く、400ステップほどのプログラムの説明が、ほんの2、3分で終わってしまいます。
その後は、リーダの質問に担当者が答えていくのですが、リーダは思いつきで質問しているようで、一貫性がありません。それも10分ほどで終わってしまいました。
どういう目的のレビューを行おうとしていたのか分かりませんが、ムラがあり効果は薄そうでした。

調べてみると、過去のコーディングレビューでは指摘がほとんど出ていません。ところが単体テストでは不良は基準値よりも摘出されています。

そこで、他のプロジェクトで使っていた標準チェックリストを渡して、レビューの最初に消し込むように指示しました。
また、代表的なテストデータでプログラムの動きをトレースするよう依頼しました。

数日後、改善効果を確かめるためにレビューに参加してみましたが、うまく行ってません。
慣れないことでぎこちないのはしょうがないのですが、やり方を変えたのに見ている観点は変わっていないようでした。リーダは相変わらず思いつきで質問をしています。

そこで気づきました。
彼らは実際のレビューを見たことがないので、口で言っても分からないことに。
ちょっと考えれば当たり前のことなのに、実際にやってみるまで気づけませんでした。

そこで、私もレビューに参加し、自分でも指摘を出しながら、脱線する人がいれば注意するようにしました。
それを何回か繰り返すうちに徐々に理解してもらえるようになりました。

オフショアプロジェクトを始めるときには、最初にやり方を教え、できれば始めのうちは一緒にレビューに参加して指導してあげるのが望ましいと思います。