実プロジェクトではどうSonarQubeを使うのか。導入に落とし穴はないのか―。筆者が経験したプロジェクトを例に説明しよう(図1)。

図1●SonarQubeの実プロジェクトへの導入事例
図1●SonarQubeの実プロジェクトへの導入事例
実装工程だけをオフショアに委託したプロジェクトで、実装工程のバグを結合テスト以降に持ち込まないという目的でSonarQubeを利用した
[画像のクリックで拡大表示]

 対象のプロジェクトは、新規開発の受託案件。日本国内で外部設計までを実施した後、詳細設計から単体テストまでをオフショアの開発チームで行い、結合テスト以降はまた日本国内で作業する形だった。

 結合テスト工程で多数のバグが発見される状況になると、最悪の場合、オフショアの開発メンバーが来日して対応することになる。そうなると全体の進捗に悪影響を及ぼすうえ、オフショア活用によるコスト削減効果が薄れてしまう。

 そこで、SonarQubeを中心としたコード品質共有システムを導入した。オフショアの開発チームに品質維持プロセスを徹底させると同時に、日本側でリアルタイムに品質状況を追いかけられるようにするためだ。

 この目的を達成するため、次のようなルールを設定した。「プログラマーはソースコードをバージョン管理システムに登録した後、必ずSonarQubeで問題点の指摘件数0件、テスト成功率100%、テストコードの網羅率(C0(命令網羅)およびC1(分岐網羅))100%の指標値を満たしていることを確認する。指標値を満たせない場合は、オフショア側の開発リーダーに相談する」といったものだ。三つの指標を“掟”として設定したわけだ。

 実際にこのルールを運用してみると、問題のあるプログラミング行為を効率良くあぶり出せることが分かった。例えば、「プログラマーが正しい例外処理の書き方を認識しておらず、問題点の指摘に対応できなかった」や「別の場所にあるソースコードの一部をコピー&ペーストして作成したコードだったが、プログラマーがコピー元のソースコードの意図をくみ取れず、テストケースを書けなかった」といった問題が見つかった。

 これらの問題に対し、オフショア側の開発リーダーが修正方法の指導をした。ソースコードの問題点があぶり出されるだけでなく、プログラマーのスキルも明らかになる。そのため、開発リーダーは改善に向けた行動を取りやすくなったと評価していた。