システム開発では、プログラムの形に関するルールをコーディング規約としてまとめているプロジェクトが多いかと思います。

コーディング規約は、単にプログラムの形式だけでなく、不良が発生しやすいコードをなくしたり、別の人がプログラムを読みやすくするために役立ちます。

しかし、コーディング規約を守らせるのは結構骨が折れます。
規約に違反していてもプログラムの動作に違いはないので実機テストでの確認はできず、すべて目視でプログラムを確認しなければならないからです。

納品物にコーディング規約違反を発見

ベトナムのオフショア開発先にWebシステムを発注したときのことです。
作業は順調に終了し、納品物を確認していました。

部下の一人が冴えない顔をして私のところに来ました。

私 「どうしたの?何か問題でも起きた?」
部下「ちょっと気になることを見つけました。」
私 「何を見つけたの?」
部下「コーディング規約に違反している箇所があったんですよ。」
私 「それなら、オフショア開発側に連絡して直してもらえばいいじゃない。」
部下「それが、結構違反箇所がありそうなんですよ。」
私 「どのくらい?」
部下「2本のプログラムを見ただけなんですが、30箇所以上ありました。」

ソースプログラムは300本以上あるので、違反箇所は4500箇所以上存在する可能性があります。
これだけの量を修正するとなると、プログラムを直すだけでも大変ですが、実機テストをすべてやり直す必要があり、作業量は膨大なものになります。

とにかく現状を把握しなければならないので、オフショア開発側に連絡し、違反箇所の調査を行ってもらいました。

対策会議

2日後にオフショア開発側での調査が完了し、対策を協議するためにオフショア開発側のPMとTV会議を開きました。

私 「コーディング規約違反はなん箇所ありましたか?」
PM「3,600箇所ありました。」
私 「対策にはどのくらいの時間が掛かりますか?」
PM「修正は1週間以内に終わります。」
私 「実機テストは含まれていますか?」
PM「含んでいません。実機テストのやり直しは必要ですか?」
私 「プログラムを修正する以上、再テストは必要です。」
PM「再テストを行う場合、1ヶ月以上掛かります。」
私 「再テストを行ってくれるのですか?」
PM「それは無理です。」
私 「では、どうするんですか?」
PM「修正しなくてはダメですか?プログラムの動作には影響がないですよ。」

再テストを行う工数も時間もないのは分かっていますが、あまりに無責任なオフショア開発側のPMの態度に腹が立ちました。

私 「プログラムの動作に影響がないと言い切れるんですか?そこまで見ていないでしょう。」
PM「多分大丈夫だと思います。」
私 「多分では困ります。しっかり確認してください。」

このようなとき、日本人技術者であれば必死に妥協点を探しますが、オフショア開発の技術者はあっさり投げ出してしまいがちです。
顧客と距離が離れているので切迫した状況が伝わらないためか、発注元が早々にあきらめて日本側で対策を行うために考える訓練が不足しているためなのか、とにかくオフショア開発側の技術者は問題解決に向けた粘りが足りません。

このケースでも時間がなかったため、オフショア開発側での調査は続けてもらいつつ、日本側で対策案の検討を行いました。

対策

摘出した規約違反を分類し、修正が必要なものと不要なものに分けました。
本当は良くないのですが、プログラムの動作に影響がない違反は修正不要としました。
すると修正箇所は、約40箇所まで減らすことができました。
これなら修正と再テストを行っても何とか間に合います。

再発防止策

今回のプロジェクトでは、プロジェクトメンバに対してコーディング規約の事前教育を実施していました。
さらにプログラム作成直後にコーディングレビューを実施してもらっていました。
しかし、それだけでは不十分だったわけです。

そこで以下の再発防止策を実施することにしました。

  • コーディングレビューのチェックリストの記述の具体化
  • コーディング完了時点での日本側の確認
  • オープンソースのコーディングチェッカーのオフショア開発側への導入

コーディングレビューのチェックリストの記述の具体化

コーディングレビューは、専用のチェックリストを見ながら確認してもらっていました。
チェックリストのコーディング規約遵守に関する部分は1行「コーディング規約を守っているか」とだけ書いていました。
規約のひとつひとつをチェックリストに記述することはできなかったため、このような記述にしていたのですが、実際のコーディングレビューでは内容を確認せずに消し込んでいたことが判明しました。

そこで、コーディング規約の具体的な内容をチェックリストへ追加しました。
ただし、規約の内容全てを記載することはできないので、重要な項目に絞りました。

オープンソースのコーディングチェッカーのオフショア開発側への導入

いくらチェックリストを強化しても、目視でのチェックには限界があります。
また、コーディング完了後のチェックでは手戻りが発生することになります。

そこで、Eclipse(Javaのプログラミング環境)のプラグイン形式のコーディングチェッカーをオフショア開発側に導入してもらうことにしました。

市販の製品はライセンスの問題でオフショア開発側に提供することが難しかったので、オープンソースのプラグインを導入してもらいました。

オープンソースは無償で使える反面、チェック内容の弱いところがありましたが、ルールをカスタマイズすることで対応しました。

プラグイン形式なので、プログラムを入力すると同時にチェックが実行されます。
そのため、手戻りを減らすことができました。

それでもコーディング規約のすべてをチェックできたわけではありませんでした。
プラグインでチェックできない項目は、コーディングレビューのチェックリストの内容を充実することでカバーしました。