こんにちは〜。@kakeyangです。日本は今どんな気候でしょうか・・・！？
ハノイは良い感じで夏っぽくなってきたとおもいきや、今日は妙に肌寒かったりと、よくわかりません。
写真はオフィスからの眺めです。高い建物があまりないので地平線が見えちゃいます。
あと、ハノイでは至る所で開発中の風景が見られます。
今回は、オフショア開発プロジェクトにおけるアンチプラクティスを挙げてみようかなと思います。どれも当たり前といえば当たり前ですがw
下記に幾つか挙げていますが、要は日本側のリソースもある程度割かないとうまく行きませんよ、という話です。
進捗管理の丸投げ
「ダメ、絶対」です。たとえ開発委託先にPLを立てても日本側で確認しないとダメです。スケジュールに対する意識が日本とベトナムではかなり乖離しているためです。
想定される結末
- いつの間にかとんでもなく遅延している
- 「ノープロブレム」と言っていたにもかかわらず、深堀りすると数々の問題が発見される
対策
- 全ての成果物（ドキュメント、ソースコード）に対して、レビューと納品の日程を決め、毎日定点観測する。チケット管理でOK。
ドキュメントをレビューする前に開発着手
いくらスケジュールが厳しくなってきて、早くコーディングにとりかからなくてはいけないとう状況になったとしても、ドキュメントをレビューして認識があっているという確認を怠ってはいけません。
想定される結末
- 要件と全く違うものが実装される。
対策
- 設計書をレビューし、認識相違がないという確認が取れるまで設計書をFIXしない。テストケースも同様。
- 設計書がFIXされるまで開発着手しない。同じ理由でテストケースがFIXされるまでテストは着手しない。確実に手戻りが発生するので時間の無駄。
- スケジュールに影響が出そうな場合は、スコープの再検討、配置換え、デッドラインの調整などを行う。
成果物の品質を開発側で担保させる
ソフトウェアやDBの設計、ドキュメント、ソースコード全てについて言えます。品質のレベルを外国人に伝えるのは非常に難しいです。すべてチェックしてください。
想定される結末
- 一応は仕様通りに動くものの、保守性や拡張性を考慮されていない設計で出てくる。
- あまりにメンテしづらいものが納品され、結局日本側で作り直しましょうか、という話になる。
対策
- レビューは全てにたいして行い、一言一句漏らさずに確認する。思わぬ所で認識相違が発生するため。
- ソースコードも当然、全ファイルレビューする。GitHubでプルリクエストしてレビュー、が簡単でおすすめ。
- 仕様は必ず意図を伝える。
納品物やゴールを曖昧に定義する
想像だにしない出来事が起きるという事を想定しなくてはいけません。きちんとゴールを明確に定義してクロージングまできっちりとやり切ってください。
想定される結末
- バグ修正が終わっていないソースコードを納品
対策
- 日本の「常識」をかなぐり捨てる。
ドキュメントはすべてレビューしてるし、ソースコードもチェックしてるからさすがにそれなりのものが納品されるだろう、という甘えは許されません。ソースコードというものはきちんとテストされて、テストで出たバグは修正された上で納品されるべきだという常識も日本に置いてきてください。実際にこういうことが起きうるのです。
オフショアをやる上での心得
- 日本人が「常識」だと思っていることが、彼らにとっても「常識」だとは限らない。
- ドキュメントに書かれていること以上のものが実装されて出来上がることはない。現時点で決まっていることは漏れ無く全て記載し、且つ、レビューを念入りに行い、極力モレと矛盾のないドキュメントを作らなくてはならない（そうしないと間違ったまま実装される）。
- メンバーの生産性が上がらない、または想定しているものと全く違うアウトプットが出てきた場合は、自分の指示が良くなかったと心得る。
・・・というわけでオフショアは大変ですw
If you want to read this blog post in English, you can refer SEPTENI TECHNOLOGY engineer's blog.
次回はオフショア開発で品質を上げるための、TDDを前提とした継続的インテグレーション（CI）について書いてみようかなと思います。
