オフショア開発はとても大変だけど良い経験だった

f:id:kkv:20141206161127j:plain

少し前に、とあるオフショア開発プロジェクトに開発者として参加し、某国と設計書とソースコードのやり取りをすることがありました。

最近は当時大変だったことを振り返っては、もっとこうしておけば良かったな、とかあれはどうすれば良かったかなぁと考えていました。

この経験を自分の頭の中に有耶無耶のままにしておかず、反省点や改善点などを整理して書き残しておこうと思います。

まずはプロジェクトの概要です。
・Webアプリケーション作成プロジェクト
・システム規模としてサーバ10台くらい
・人数は日本10人、某国15人くらい

また、基本的なオフショア工程は下記になります。
1. 日本で企画から詳細設計まで行う
2. ブリッジが翻訳
3. 某国でプログラミングから単体テスト
4. 日本で受入
リリース間近は納期の遅れがでそうだったので、受入+共同開発みたいになりました。

自分の役割はメンバーだったので、上記のうち1. と 4. でした。ブリッジさんは某国の方で、一度翻訳された設計書を見ましたが、日本語で書かれた一語一語をきちんと訳しているようでした。また、設計書の連携だけでなく、ちょっとしたQ＆AはRedmine上で行っていました。

それでは、以下の事柄について振り返ってみようと思います。

1. 詳細設計書の連携について
オフショア先に連携するのは詳細設計書になりますが、これは日本語で書いていました。
しかし、例えば条件分岐の条件とか数値の大小とかは、なるべく英語や共通言語の数字など共通言語で書いていました。詳細設計書では、どこまで書くか、どのように書くかなど不明確な部分が多かったので、試しに書いてみてフィードバックでさらに改善していくという感じでした。かなり具体的にしないといけないときは、プログラム言語で書いていきましたが、書くときに変数名とかをこちらで考えて書いていたのでコストがかかってしまったような気がします。

・反省点
また、詳細設計書を具体的に書いてしまいがちになり、基本設計での変更(条件の変更やテーブル名の変更)で設計書の変更が多発したときに、修正コストがかなりかかってしまいました。

・結論
結論として、設計書作成時間の短縮、修正コスト、理解してもらうことをた第一にすると、入出力だけ丁寧に書き、後は一文のみにシンプルにしてあげるのが良かったんじゃないかなと思います。

2. 受入について
オフショア先が作成したコードのレビューとプログラムの動作検証を行うことになりますが、単体テストが完了している場合でも、動作しない場合もありました。また、細かい条件が伝わっていないまま実装されていたり、間違って解釈されて実装されていたりもします。

・反省点
基本的に単体テストが完了していることを念頭においていたので、動作確認から入っていましたが、動作しないコードが多かったことを踏まえば、ここは単体テストのレビューから入るべきだったと思います。単体テストが正しい仕様で行われていれば、少なくても動作しないということは防げただろうと思います。実際に動作しないコードを返すときにもどこが間違っているのかを調査していたので、受入れにも時間がかかりました。

・結論
詳細設計書の質が悪くて品質の低いコードができてしまうことは、反省することですが、現実解としては、受入→修正依頼→受入のサイクルを早めつつ、コードレビューをしっかりやることですかね。

3. 共同開発について
納期が近づいてきて、日本でも開発を行うことになりました。ここで問題になったのはソースの管理でした。品質・工程に対する考え方の違いなのか、マージに失敗しているケースや日本側で作成したソースコードに上書きしているケースがありました。コミット時間をずらすことで問題はあまり起こらなくなりました。

4. その他・全般
当たり前のことかもしれませんが、Q＆Aや受入などのレスポンスは早くしなければいけませんでした。レスポンスの遅れはスケジュールの遅れに直結しますからね。ここらへんのことは日本人同士でも同じですね。

けっこう大変な思いもしましたが、それだけ学ぶべきことも多かったです。次にオフショア開発を行うときはこの教訓を生かしていけたらと思います。