オフショア開発でソースコードの品質を維持する

※私の会社では、オフショア先は中国（北京）なので、このエントリーでのオフショア開発先は中国を想定しています（たぶん、他の国でも共通する部分は多いでしょうけど）。また、開発言語はJavaです。

ソースコードの品質は大事です。ソースコードの品質というのは、可読性やメンテナンス性などに優れているという意味で使っています。ソースコードの品質が悪い状態を表す言葉として、いわゆる「スパゲティ化」という言葉は有名です。

1度作ったらおしまいというシステムならいざ知らず、継続的に機能追加・修正を行うパッケージ開発においては、ソースコードの品質は死活問題ともいえます。にもかかわらず、その重要性を理解している（できる）のはエンジニアだけだというのが辛いところです。コスト削減やエンジニア不足への対策ということで会社・組織方針としてオフショア開発を推進するようなことになった場合に、ソースコードの品質対策まで意識した上でオフショア開発に踏み切っているケースは少ないと思います。

ソースコードの品質を維持するためには、デザインパターンを適切に適用する・リファクタリングを行う、といったことが考えられます。実際にそれを実施している現場も少なくは無いと思いますが、これがオフショア開発だと事態が難しくなります。ソースコードの品質の良し悪しは、個人の感覚による部分が大きいです。気心の知れた少人数のチームで開発を行っている分にはうまくいっても、オフショア開発において大量の中国人エンジニアがソースコードを改変するような場面で、ソースコードの品質を維持するというのは容易なことではありません。

納品されたソースコードを見て、「このコードはあまりにもひどいから直せ」と言っても、「仕様どおりには動くだろ」と言い返されて押し問答になるのが関の山です。
その一方で、あらかじめきちんと決められたことであれば、さすがに守られるという傾向はあるので、ソースコードの品質を守るためにも、そのためのルールをどれだけ作ることができるかが重要になります。

すぐに思いつくのはソースコード規約を作ることです。これは重要なことですが、本当に守られているかどうかをチェックするという部分については課題があります。ソースコード規約を作ってみるとわかるのですが、機械的にチェックできるものは少ないです。そのため、納品されたソースコードをまともにチェックしようとすると、それだけで相当の手間がかかる（そのそも、オフショア開発している現場ではチェックできる人材が少ない）ということになります。ですので、ソースコード規約については、オフショア先でのチェック体制は明確にしてもらった上で、受け入れ側では抜き打ちチェックとして（もしくはそれすらやらずに）、見つかったものについては修正に応じること、とするくらいのやり方が現実解になるのかなと思います。

いわゆるソースコード規約というものについては、機械的にチェックできるものは少ないと書きましたが、逆に、機械的にチェックできるものはチェックしようというスタンスに立つと、いくつか使えるツールがあります。
私の会社で使っているのはCheckstyleとFindBugsです。
この2つのツールは、類似しているけれどもけっこうコンセプトは異なっています。Checkstyleは、その名の通りスタイルのチェックを行うもので、「命名規則の正規表現によるチェック」や、「if文／for文での中カッコの必須チェック」などがあります。一方FindBugsの方は、バグとは言わないまでも無駄な書き方や怪しい書き方をしている箇所をチェックするツールで、「宣言しただけで利用されていない変数がある」や、「equals()メソッドをオーバーライドしているのにhashCode()をオーバーライドしていない」というようなものをチェックしてくれます。

これらのツールを使うと、簡単に実行できて結果が明確に現れるので、ルールとして守らせやすいというメリットがあります。ただし、それぞれのツールには複数のチェックルールが存在しますが、全て適用すればいいと言うものではなく、中には疑問を感じるものもあります。そのため、プロジェクトの実態に合わせて適用するチェックルールをどれにするかについて検討する必要はあります。

こういったツールでチェックできることというのは、ソースコードの品質のごく1部の側面だけなので、これだけやっていれば万全というものではありません。とはいえ、オフショア開発における受け入れ側の手間と効果のトレードオフという意味では、けっこう効果的だと思います。