はじめに

私は中国・フィリピン・ベトナムとのオフショア開発を経験してきました。
また、ベトナムに四年間住み、オフショア側からもプロジェクトに参画してきました。
開発モデルはゴリゴリのウォーターフォールであったり、Scrum、Agile、Hybrid Agile等であったり、一般的な請負開発や、ラボ型開発、グローバルチームモデル開発等様々なスタイルでした。

プロジェクトを振り返ってみると、あの時ああ言っていればもっと、オフショアメンバーとスムーズに協業できただろうな等、思うところが多々あります。

この記事では

オフショア開発のプロジェクトを行っているけど、なんだかうまくいっていない方。
オフショア開発のプロジェクトを計画しているけど、品質や進め方などに不安を持っている方。

を対象に、私が出会った失敗談と、そこからどうすべきだったのかを共有して、うまくいくためと不安を解消するための手助けになればと思います。

リモートワークが増えた昨今では、物理的な距離は問題ではなく、オンラインミーティングの利用など、オフショア開発を行うハードルが低くなってきました。
オフショア先の技術者は勤勉な方が多く、開発スピードがものすごく早ので、ちょっとしたコツさえ掴めれば、Quality・Cost・Deliveryすべてにおいて、非常に満足いくプロジェクトになると思います。

失敗談前提が違った編

前提条件、バックグラウンドが違うことを理解していなかった

オフショア開発をして一番よく聞く失敗談は「自分が想定した内容と全然違うアウトプットが返ってきた」じゃないかと思います。

解決方法は、実際に手を動かす（設計、コーディング等を行う）前にアウトプットのすり合わせを行うことか、もしくは、とにかくデモとフィードバックを繰り返すことだと思います。
これはこれでコツがいるので、その内容はいずれまとめようと思います。

ここでは、もっと前提になる「なぜ想定が違うのか？どうすればいいのか」の部分について書きたいと思います。

私の失敗談でいうと「今月の働いた時間を計算しておいて」とベトナムメンバーに依頼したことがありました。
「働いた時間＝出社した時間～退社した時間　－　休憩時間」という計算を期待していましたが、実際には、休憩時間が引かれない時間で計算されたものでした。

「いやいや休憩時間は働いてないのだからマイナスするでしょ」というやり取りを数回したところベトナムでは以下のように休憩時間も有給労働時間として計算する法律があって、それを元に考えた結果でした。（ちなみに、この休憩時間を労働時間に含むかどうかの認識はベトナム人のなかでもバラバラでした。）

①休憩時間
休憩時間は、1日8時間もしくは連続6時間の勤務につき30分以上、深夜勤務の場合は45分以上で、いずれも有給労働時間として計算されます。
（ベトナム改正労働法第7章勤務時間、休憩時間第2節休憩時間第108条勤務中の休憩時間）
残業時間を含めて1日10時間以上働いている場合はさらに最低30分以上の休憩が必要で、この休憩も有給労働時間として計算されます。
（政令45号第2章労働時間・休憩時間第2節休憩時間第5条労働時間中の休憩）

このように、前提（生まれ育った環境・習慣・法律・価値観）が違うので、想定は違ってきます。
もちろん、お互いの国の法律や一般常識をすべて把握するのは不可能ですが、相手のことや、前提が違うことを認識し、できるだけ相手の国を理解するということをすべきでした。
また、オフショアベンダーを探す際は、日本の商習慣等・文化を教育している会社を探すべきでした。

失敗談コミュニケーション編

主語・述語・目的語の何かが抜けていた

以下の様なやりとりで、認識が違くなってしまったこともありました。

日本側「○○画面に××という新しい機能を付けて」
オフショア側「あれ、じゃあ"△△画面"にも新しい機能を付けることになる？」
日本側「同じで良いですよ」

この時、"△△画面"に新しい機能を付けるかどうか？

「なぜ同じで良い」のかの理解が違う時、結果が変わってきてしまいます。

例えば、「（"○○画面"を直すときに共通部品を直すことになって"△△画面"も同じ共通部品を利用している、だから）同じで良い」という理解の場合、"△△画面"に機能を付けますし

「（修正箇所を"○○画面"のみに抑えた方が工数が浮くはず、だから）同じで良い」という理解の場合、"△△画面"には新しい機能は不要となります。

この例で言えば、日本側は「それは"現状"と同じで良いですよ」「それも"○○画面"と同じで良いですよ」等、「何と同じ」なのかを明確に伝えるべきでしたし、オフショア側も、何と同じになるのか明確に確認するべきでした。

具体的な名前が抜けていた

先ほどの例で「それは"現状"と同じで良いですよ」「それも"○○画面"と同じで良いですよ」
と書きましたが、「それ」「あれ」「これ」というのもよく認識がズレる原因になりました。
「△△画面は"現状"と同じで良いですよ」と主語を明確に言うべき・確認すべきでした。

失敗談　やること編

パターン網羅する？しない？

日本側「本番環境で、AがBの状態のときなど、不具合が発生するようです。修正お願いします。」

こんな依頼が来たら、”AがBの時に不具合が発生しないように修正”以外に何をするでしょうか？

気が付いた人・気が付かない人がいると思いますが、依頼では「AがBの状態のときなど」と言っているので、AがB以外のCの時、Dの時etc.も確認・修正する必要がありました。

また、もしかしたら人によっては「本番環境と言っているのだから不具合が判明しているパターンをとにかく早く直さないといけない」と感じる人もいると思います。

これらの情報は依頼するときに伝えてあげた方が、
「"など"ってこのパターンのことであっているか？」「優先度はどれくらいか？」
というやり取りが省けるので、早く済むことが多かったです。

例えば、以下のように依頼した方がよかったと思います。
「AがBの状態で不具合が発生しています。（わかっている事象を伝える）
　Aがとりうる状態のパターンを洗い出して動作確認してください。（パターンを網羅するタスクを伝える）
　そのうえで、不具合が発生するパターンすべてを修正してください。（不具合修正するタスクを伝える）」

結局自分で作業やっているのと変わらない状態になってしまった

日本側「本番環境で、AがBの状態のときなど、不具合が発生するようです。修正お願いします。」
オフショア側「Cの時も発生するんですか？」
日本側「Cの時はわからないです。確認しておきますね。」
オフショア側「そもそも何パターンあるんでしたっけ？」
日本側「5,6パターンくらいだと思うけど。。。確認しておきます。」
オフショア側「本番環境のログは運用部門からもらってますか？」
日本側「あー、もらってきます」
オフショア側「あ、不具合が発生している機能は○○画面と××画面の両方から呼び出されますね。発生しているのはどっちですか？」
日本側「○○画面で発生したと聞いてますが、××画面は発生するかどうかわからないですね。確認しておきます。」
　（会議終了時）
日本側「では、確認しておきますね。（自分の確認タスクが増えただけで、結局タスクをふれなかった。。）」

何らかの不具合が発生した際は、オフショア側はできるだけ情報を引き出そうとヒアリングしてきます。
このヒアリングは「判明しているのかどうなのか？」を確認したい場合の方が多く、日本側で調査してほしいという意味でないことが多いです。（アクセスできない環境であったり情報の場合以外）
判明していることを伝え、調査・確認タスクが必要なことを明確にすべきでした。

なので、
「Cの時も発生するんですか？」という質問が来た時には
「Cの時は発生するかどうかは不明です。（現状を伝える）
　確認しておいてください。（調査・確認するタスクを伝える）」

と伝えてあげれば、タスクとしてやることが明確になり、スムーズになると思います。

まとめ

まとめると

前提条件、バックグラウンドが違うことを理解した上で
主語/述語/目的語・代名詞が明確な文で
現状と期待内容を伝える

と、大体の失敗は回避できていました。

オンサイトとオフサイト、オフショアとニアショア、日本人かどうか、などなど関わらず、なんだか仕事をするうえで当たり前ですね。

ただ、当たり前だからこそ奥が深く、世の中に「伝え方」が云々という記事やプラクティスがあふれているのだと思いますし、日本人同士でさえ難しいのだと思います。
オフショア先のベンダーを探すときは、いかに「あたりまえ」の溝を埋める施策をしているかというのも重要な点の一つかと思います。

例えば弊社ベトナムオフィスパーソルプロセス＆テクノロジーベトナムでは「グローバル開発モデル」なるものを推進しており、お客様の依頼の意図や背景を、チームとして理解/行動できるモデルになっていて、いわゆる行間を読んで作業することも可能になっています。
また、ベトナムオフィスのBSE/SMの多くは、CSPO/CSMの資格取得者で、海外リモートチームならではのプラクティスを組み入れたAgile/Scrum手法を採用することにより、シームレスに協働できます。
ベトナムでのオフショア開発をお考えの担当者様はぜひご検討ください。