HDE Advent Calendar Day 10 : ベトナムオフショア開発の良いこと、悪いこと

こんにちは。

System Consulting & Sales Division の大久保です。

今年の流行語大賞も決まり、あっという間に年末ですね。私の今年の流行語はずばり「ベトナム」。まさにベトナムに始まり、ベトナムに終わる一年でした。一年の締めくくりに、たぶん皆さんが興味深々であろう「ベトナムでのオフショアって実際どうなのよ？」というお話をしたいと思います。

なぜベトナムなのか？

当社CTOの小椋がベトナムのIT企業を視察したのがきっかけだったと思います。その後、あるベトナムIT企業からパーティ＋ゴルフコンペを現地で開催するから来て！ってお誘いを受け、ゴルフ始めた！って社内に宣言していた私に白羽の矢が立った。。。そんな感じで私のベトナム視察は実現しました（どんな感じだ？）。

私は15年程前、あるメーカーさんで客先常駐のお仕事をしており、その頃、20代前半のベトナム人がたくさん同じ職場にいたんですね。彼らすごく勉強熱心で、真面目で、謙虚な印象でした。15年経って彼らが自国に帰ってIT企業を起業しているんだろうな。そんな思いを馳せながらのベトナム視察でした。

人月単価が安い、平均年齢が若い、国がIT産業を支援している、時差が2時間で勤務時間が合わせやすいなど、一般的に言われているメリットは確かにありますが、「若い子がすごく熱心に・真面目に仕事に取り組んでいる。みんな謙虚、ちゃんとごめんなさいと謝ることができる。個人、会社、国全体にみんな頑張ろう！という昭和の雰囲気がある」のがおじさん（＝私）のベトナムラブな理由です（笑

 どうやってパートナー企業を探すのか？

ですが、パートナー選びは重要です。これはベトナムだからではなく、日本のIT企業でも一緒ですね。求める技術スキル、開発体制、メンバー、セキュリティや単価などの契約上の諸条件など、、、自分の勘と経験を駆使してよいパートナーを探してください。幸い、Japan IT Week などのイベントにベトナムIT企業がたくさん出展されていますので、まずはカタログなど収集してみてはいかがでしょうか。

私は Japan IT Week 2014 のカタログを眺めて、良さそうな 10社ぐらいに「今度視察したいんだけど！」とメールして、パーティ参加と合わせて日程調整して現地に行きました。大体日本語ができる担当者がいらっしゃいますので日本語で大丈夫です。私は直接コンタクトして、１社２時間程じっくり視察したのですが、雰囲気や開発体制、得意な技術分野は会社によって全く違います。是非現地でじっくり彼らと話をしてください。私英語はよくわかりませんが、会社説明の熱気や技術者の目を見れば、パートナーに選ぶべきかはわかりますよね。

あとはコミュニケーションの問題について。ベトナムのIT企業は日本語が堪能なブリッジＳＥもしくはコミュニケーターを提供してくれます。エンジニアは英語の読み書きは問題ありませんが、上手に話せる人は少ない（発音の問題で聞き取れない）印象です。ですので、日本語で十分コミュニケーションができるブリッジＳＥもしくはコミュニケーターをプロジェクトメンバに１名配置する、この人は十分時間をかけて面接することをお勧めします。

はじめに何をすべきか？

 パートナーを選定したら、いよいよオフショア開発がスタートします。が、いきなり日本とベトナムでのリモートワークは無謀かと思います。ベトナム側からも「最初は１カ月ぐらいベトナムでプロジェクトメンバーと一緒に仕事して業務を理解させてくれ」とお願いされます。

私は開発以外の業務も持っておりベトナム常駐することができなかったため、ブリッジＳＥとリーダーの２名に日本に来てもらい、当社製品についての研修を行いました。教える日本チームもしんどかったですが、この研修の効果は絶大で彼らは製品仕様をほとんど理解することができ、あとはリモートワークでも大丈夫だと確信が持てました。

しかし、２名には慣れない日本での生活、リーダーは生まれたばかりの赤ちゃんもいて家族に大変な苦労をさせてしまったなど、簡単に来日してもらえるわけではないですのでパートナーとよく相談の上、最初の立ち上げを乗り切ってください。

オフショア開発のコツ

まだまだ勉強中ではありますが、オフショア開発をマネジメントするコツみたいなところが少し掴めてきました。

• 最初にしっかり研修しましょう。

先に書いた通りです。業務対象のシステムについて十分な研修を face-to-face で実施することをお勧めします。コミュニケーションの問題、業務やシステム理解度の問題、考え方の違いなどここで把握しましょう。

• ドキュメントはしっかり書きましょう。

正直、日本チームの開発ドキュメントはあってなかったようなものでした。しかし、オフショアで業務依頼をする場合、ドキュメントが全てです。日本語でも英語でもいいのできちんとドキュメントを書いてください。彼らはエクセルに日本語で書かれた業務システムの設計書やテスト仕様書などもきちんと読みこなします。

• 納期は自分で判断しましょう。

私は機能概要書と基本設計書を渡して、詳細設計～単体テストのフェーズをスケジュール含めて見積もり依頼しています。すると、彼らはカツカツなスケジュールを見積もってきます。よくある「バッファ」なんてものは存在しません（笑

実装難易度やメンバーのスキルを勘定して、最終的な納期の決定は自分でしてください。これは彼らの見積もりが甘いとか、納期に対して責任がないということではありません、逆にバッファを設定しない分、スケジュールに対して非常にシビアに仕事をしてくれます。でも、「できないものはできない」じゃないですか。ですから自分でちゃんとバッファを含めた納期設定を行うのが安全ですよ。ということです。

• 作業分担を明確にしましょう。

 ある開発タスクで、日本チームとベトナムチームの作業分担が曖昧になってしまい、作業分担の明確化とスケジュールの再作成をしたことがありました。「何を、誰が、いつまでに」をきちんと提示し、かつ、その作業分担について、日本・ベトナムの双方で合意形成するというのが大事です。彼らは自分たちの守備範囲を明確に持っているようで、自分たちのタスクではない（と彼らが考える）ものを依頼するとプロジェクトが上手く進みません。

• 開発途中での仕様変更はやめましょう。

基本設計を私がやっているので、テストフェーズなどで「あー、ここの設計間違えたなー」など発覚することあります。受託開発だとお客様からの依頼による仕様変更も発生しますよね。しかし、開発中の仕様変更は彼らが一番嫌がります。なぜなら、緻密に計算したスケジュールを全力でこなしている途中で仕様変更なんて入ったら、変更分の仕様理解、影響調査、リスケジュールなどの負担を強いられる上に、当初納期も守れない。これ、すごくやる気なくなりますよね。仕様変更したい場合、現在の開発を完了させてフェーズ２でやりましょう。

• 自分の時間に余裕を持ちましょう。

 レビューやＱＡシート回答などのタスクは彼らのスケジュール内でこなさなければなりません。これは結構しんどいです。自分の時間に余裕がないと開発プロジェクトをうまく運用できないので、最近、毎週木曜日は在宅ワークにして自分のタスクに時間を割り当てるなどで改善を試みています。

 良いこと、悪いこと

オフショア開発に挑戦してみて良かったこと、悪かったことをまとめます。

良いこと

• 開発リソースが容易に調達できるようになった。ベトナムのIT企業は豊富に人材をプールしているので数人～数十人程度の増員・減員は容易に行えます。
• テストがしっかりできるようになった。開発リソースが十分にあるので、単体試験、機能試験などハンドで行った試験をテストスクリプトに落とし込み自動化するところまでできるようなりました。仕様変更しても回帰テストを自動で実施できるのは心強い限りです。また、彼らはテストに対していろんな知見を持っており、かつ、可能な限りいろんな試験をやってくれます。
• ドキュメントをしっかり書くようになった。日本チームのメンバーもベトナムに仕様が伝わるようしっかりドキュメントを書いてくれるようになりました。ドキュメントが残るので製品のメンテナンスにも役に立っています。
• メンバー全員がタスクとスケジュールを意識するようになった。リモートワークで相手の状況がわからないためか、各自がタスクとスケジュールを意識して開発業務を行うようになりました。
• 英語を使うようになった。最初は日本語ドキュメントをブリッジＳＥが英語に翻訳していたのですが、ＱＡシートやメールでのやりとりはリーダーから直接英語で問い合わせがあるので、徐々に英語で開発業務を行うようになり、最近は基本設計書も英語で書いて渡しています。もちろん、意図が伝わっているかなど大事な確認には日本語を使います。
• ベトナムに行けるようになった。四半期に１回はベトナムで彼らとコミュニケーションしようと思っています。ベトナムは何を食べても美味しいですし、彼らは明るく元気なので現地ではとても楽しい時間を過ごせます。

悪いこと

• ホワイトボードに絵を描いて、こうしてこうして・・・と説明して、ふむふむ了解。んじゃ、設計書を書いてみますわ。書き終わったらレビューってことで。みたいな開発ができない。（でもベトナムでもこれができるようにしたい）
• 英語でのコミュニケーションになるので時間がかかる。こちらの思いみたいなところが伝えられない。（ここはブリッジＳＥが優秀ならカバーしてくれる。もちろん自分の英語スキル向上も必要）
• プロジェクトマネージャの手腕が問われる？作業分担とスケジュールの話をしましたが、ブリッジＳＥとリーダーが納得して仕事してくれないと開発がうまく進められないかも。（黙ってしまい、こちらの指示に対して反応がなくなる）
• スーパーなエンジニアは希少。ベトナムオフショアで優秀な人材が確保できると夢を見てはいけません。日本人エンジニアの３年生ぐらいをイメージしてください。大体、彼ら20～25歳ぐらいですから。（リーダーがスーパーならなんとかなります。なんとか１名ゲットしてください）
• 成果物の受け入れが大変。日本人メンバー同士だと密なコミュニケーションと毎日同じ場所で仕事している環境であるため成果物に認識相違はほとんどないですが、オフショア開発ではこちらが下手な英語で書いた設計書で、どこまで意図が伝わっているのか不安です。ソースコードレビューとテストケースレビューで成果物を評価していますが、大規模な開発になってくると全ての成果物をレビューするのは不可能だとおもいますので、どうすべきか検討中です。

終わりに

いろいろ書かせて頂きましたが、とにかくベトナムはいいところです。来年も彼らと一緒に楽しく製品開発をやっていければと思います。モッ、ハイ、バッ、ヨ！！