オフショア開発考察

先日別プロジェクトの同期とオフショア開発（中国）について話をする機会があったのですが、やはり彼のプロジェクトも嵌って居るようで、失敗事例として全社公表してやると息巻いていました。

うちの会社は、海外発注が始めてではない（むしろ世の中的には早いうちから実施していた）のにも関わらず、発注額の目標のみ全面に押し立てられて、それ以外は全くの無策であるのが根本原因なのですが、まあ文句ばかり言っていても仕方ないので現場で出来ることは何かを考えてみました。

オフショア開発のそもそもの目的は海外（特に中国のこの業界は日本語の読み書きが可能な人間が比較的多い）の安い人件費をうまく活用して、原価の低減を図ることです。

ただし、それを達成するにはプロジェクト管理を徹底して当初の想定人月で終わらせる事が必須となります（受け入れ後の工程も含めて）。

また中国人の気質（特に日本人との違い）として

・設計書に書かれている通りにソースコードを作る（たとえ設計書の間違いに気づいても放置）
・自分の分が進んでいると本人が感じていれば他のメンバの進捗が悪くても放置。人によっては遅れていても普通に定時で帰る。
・プライド高い（自分が作ったバグはバグとしてなかなか認めない）

というのがあります。もちろんそうでない人も居ますが、こんな感じの人が多いというのが自分の印象です。これらを踏まえた問題点として、

・進捗報告を正確に行わない（日本でもひどい会社は同じですが）
・ソースコードの品質は作成者によってかなり違う（相互ソースレビューを実施しない）し、全体的な品質もあまり良くない（日本だと一部の責任感を持っている人がひたすら　直しまくって品質を上げようとするパターンが多いですが、中国人ではそういう感覚の人が皆無に近い。もっとも日本でもひどい会社は同じ）
・日本から出す設計書の品質もそもそも良くない
・国内向けと同じ感覚で丸投げ

ぐらいがプロジェクト管理が徹底できない理由かなと思います。

実は自分もオフショア開発は今回が初めてだったのですが、上記問題点はある程度予想していたので、一応対策は打っておきました。が、実際にやってみるとまだまだ不十分という感じです。

今のプロジェクトでできたことは

・コーディング規約などの規約類の整備（これは考えうるものは全て出来たように思う。規約違反は全て直させるように契約にも盛り込み済み）
・JTestによるソースコードの静的チェックの徹底

ぐらいで、今考えると全然まだまだですね。今後のプロジェクトでは

・発注する際の設計書の品質向上の為にレビューの徹底。未レビューのままでも平気で外に出す文化を無くさせる仕組み作り（国内への発注の場合は設計書の品質が悪くても何とかなるので、そういう悪い文化が染みついてしまっている）
・設計書の仕様を理解している人を必ず中国に送り込んで、設計書の不備をひたすら直す。設計書の間違いに気づいているのにそのままソースにしてしまうことを止めさせる。（そういう意味だとブリッジSEを設計の段階から日本に連れてくるのも一つの案と思われる）
・進捗管理の自動化。人間が数値を挙げるといくらでも恣意的にできるので、例えばJUnitを毎晩自動実行してgreen bar,red barの数を自動的に毎日グラフ化するとか。mavenとか使ってうまくできないか試行錯誤中。
・ソース、試験項目のレビューの徹底（こちらで日程を決めて有識者を中国に送り込み、レビューウィークを作るぐらいしたい）

ってぐらいは徹底してやってみたいと思っています。

日立や富士通なども苦戦している状況の様なのでどこまでうまくいくかは分かりませんが、何もしないで失敗するより色々試してみて失敗する方が精神衛生上良いということで頑張りますか。