こんにちは、スクーティー代表のかけやと申します。
弊社はベトナムオフショア開発・ラボ型開発や、生成AIコンサルティングなどのサービスを提供しており、私自身、今までベトナムのオフショア開発事業を10年以上やっています。
オフショア開発関連のセミナーや勉強会などでお会いさせて頂いた方々のお話を伺っていると、「以前オフショア開発をやってみたんだけどうまく行かなかった」とご相談をよくいただきます。しかし、よくよくお話を伺ってみると、委託先への仕事の渡し方が非常にまずいなと感じることが、正直よくあります。この場合は開発会社がいくら頑張ってもうまくいく確率は非常に低いと考えられれます。
本記事では、オフショア開発において仕事を委託する側に起因する失敗の原因と、なぜそれが失敗の確率を上げてしまうのかについて解説します。
事例を挙げる前に、日本から海外へ発注するオフショア開発プロジェクトにおけるボトルネックになりやすい点を解説しておきます。
日本人のコミュニケーション方法は独特
『日本でIT人材がみつからないとお悩みのあなたへ！海外IT人材活用のススメ』無料セミナー資料より
Edward T. Hall氏が提唱した、コミュニケーションのハイコンテクスト、ローコンテクストという考え方があります。空気を読む文化と言葉で伝える文化、と言い換えることもできます。
文化なのでどちらが良い、悪いではなく、世界ではコミュニケーションの取り方が地域によって全く異なるということを理解しておく必要があります。
そして、上の図のように、日本は極端にハイコンテクストに寄っているという点を認識しておく必要があります。
ハイコンテクストというのは例えば、下記のようなものです。
- 空気を読む
- 阿吽の呼吸
- よしなにやる
- 行間を読む
このようなコミュニケーションは、日本人同士（あるいは、外国籍であっても日本で生まれ日本で育ったような方々）だからできるコミュニケーションであるということです。
ベトナムは上の図にはプロットされていませんが、「ややハイコンテクスト寄り」の文化と言われています。ただし、日本がハイコンテクストの方に極端に寄っているため、日本から見ると他の国は相対的にローコンテクストになります。つまり、日本から見ると、ベトナムもローコンテクストの文化となります。
ベトナムオフショア開発においてこの理論を解釈すると、「日本人が日本で普段やっているコミュニケーションよりも、意識して言葉で伝えるようにしないと外国人にはうまく伝わらない」ということになります。
いきなり何の話をしだすのかと思われているかもしれませんが、「日本では今までこういう伝え方をしていたんだから、ベトナムでも同じ方法で理解できるよう努めてほしい」というような考え方は根本的に非効率的だということを前提として理解する必要があります。
日本人の労働観も独特
出展: SONYとマッキンゼーとDeNAとシリコンバレーで学んだ グローバル・リーダーの流儀
日本人の労働観も独特です。多くの日本人は「働くことそのものが美徳」「働くもの食うべからず」という考えを持っていると思います。
しかしこの考え方は、世界的に見るとかなり独特です。
上の図は、人生においてプライベートと仕事のどちらを優先するかを国ごとにプロットしたものです。日本はプライベートよりも圧倒的に労働を重要視するという調査結果です。コミュニケーション方法同様、日本人の労働観も世界的に見るとかなり独特のもののようです。
したがって、日本人の視点から他の国の労働観を見ると、相対的にどの国であってもプライベートを重視しているように見えてしまいます。
例えば、外国人と働くプロジェクトがあり、納期前に外国人メンバーが長期休暇をとったというケースがあったとします。日本人の感覚からすると、「納期前に長期休暇などありえない！」と感じるかもしれませんが、海外の視点だと、「日本人は仕事ばかりしすぎている」と見られているかもしれません。
これは労働観、あるいは人生観の話なので、何が良い、悪いではないと私は思います。また当然、単純に「日本人は」「ベトナム人は」と画一的に話せるものではなく、考え方の個人差はあります。
いずれにしても統計的には日本人は独特な労働観を持っており、平均的な日本人の労働観を外国人に押し付けても誰もついてこれません。ベトナムも同様です。
労働観の違いに関しては「SONYとマッキンゼーとDeNAとシリコンバレーで学んだグローバル・リーダーの流儀」に非常にわかりやすく書いてありました。おすすめです。
人生において重要なのは労働だけでは無いということです。この点を無視して外国人と一緒に働くことは難しいと、私は考えています。
→ダウンロード：『日本でIT人材がみつからないとお悩みのあなたへ！海外IT人材活用のススメ』無料セミナー資料
事例１：行間を読ませる仕様
さて本題です。以上を踏まえて、ベトナムオフショア開発で委託側が失敗しやすい事例をいくつか列挙していきたいと思います。
まず失敗しやすい事例のひとつは「行間を読んでもらうことを前提とした仕様書」です。上でも述べたように、行間を読むコミュニケーションは日本人同士で成り立ちやすいものであり、日本人と外国人間では認識齟齬を忌みやすいです。
ありがちなのは「AをBに変更すると記載しているのだから、当然A’をB’にしてくれるだろう」ことを期待することです。長い間一緒に仕事をしている開発メンバーならまだしも、新規プロジェクトで意思疎通できることを期待するのは無理がありますし、むしろ事故の元なので避けたほうが良いでしょう。（もし行間を読んで意図を汲んでくれる人がいれば、その人はかなり優秀なので絶対に手放さないでください！）
ではどうするかというと、私の意見としてはどちらかかなと考えています。
- 腹を括って、抜け漏れのないドキュメントを仕様書として渡し、その通りに作ってもらう。
- 認識相違は起きる（あるいはドキュメントに間違いがある）という前提で、テスト環境へのデプロイとレビューのサイクルを高速にまわし、作りたいモノへ「育てて」いく。
前者の方が確実ではありますが、ドキュメントは一般的にメンテされずプロジェクト後半は何が正解かわからなくなりがちなので、個人的には作成するドキュメントは最小限に抑えて後者の方法で進めることを推しています。
あるいは、新規案件は前者の方法を採用してなるべく細かくドキュメント化し、ローンチ後の運用保守フェーズでは後者に寄せていくという方法も一つの方法です。
とはいえ、バランスは大事です。「赤信号を渡ってはいけない」レベルまで仕様として記載する必要はないですし、ドキュメントに記載が無い部分でも「こういう動作で良いですか？」「こういう動作はどうでしょうか？」と質問なり提案しながら進めることができるのがプロの開発者としての姿勢だと私は思います。
なんでもかんでも「仕様」が決まってないからという理由で先に進まない場合は、開発会社へ改善要求を出すべきところでしょう。
事例２：「品質」として何を求めているかの合意形成をしていない
「以前オフショア開発をやってみたけど品質が悪かった」というお話をよく頂きます。
よくわかります。オフショア開発では期待してた品質を下回ったものが出てくることは、正直なところよくあると思いますし、私もそのような事例をいくつも見てきました。
しかし更に、「では、どんなレベルの品質を求めていて、どのくらいのものが出てきたのですか？」という質問をしてみると、意外に明確な回答が返ってこないことが多いです。「日本のような品質を求めている」とおっしゃられる方もいます。
日本レベルの品質とは具体的にどのような品質でしょうか？
日本国内の開発会社でも、成果物の品質はバラバラですよね。
私の経験では、「品質が悪い」のではなく、「どのレベルの品質を求めているか」という合意形成が出来ていないケースの方が多いです。品質のゴールをプロジェクト着手時に、お互いに客観的、あるいは定量的な表現で合意形成していなかったため、開発側は「問題ない」と評価していても、委託側にとっては低い品質だったという認識の齟齬が生まれてしまうということです。
結論として、「品質」というものを出来る限り定量化し、各プロジェクトでどの指標をどのレベルで維持して納品してもらうかを、プロジェクト開始前に合意形成をとっておくと「品質」は格段によくなるはずです。
弊社スクーティーの品質管理に関しては、「スクーティーの品質保証」を御覧ください。
事例３：マネジメントを開発チームに丸投げ
話を伺っていて驚くのが、「納品時に確認したら品質がとんでもなかった」「気がついていたら遅れていた」というようなケースです。
これも気持ちは非常に良くわかります。仕様とスケジュールを決めたのだから、あとはよしなにやってくれることを期待していたのでしょう。何か問題があれば開発チームから報告があることを期待していたのでしょう。
しかし、途中経経過の確認くらいはすべきだったと思います。それだけでこのようなケースは未然に防げたはずです。
「日報では問題なしとの報告だった」という話もよく聞きます。しかし、事例２でも述べたように、「問題なし」は主観的な表現でしかなく、認識齟齬を生む元凶になります。報告によって状況を把握したいのであれば、開発側に品質を客観的、あるいは定量的な形で評価／報告してもらう必要があります。
せめて、途中まででもいいので、出来ているものを自分の目で確認するリソースは予め確保しておき、できる限り頻繁に確認し、フィードバックするようにしたほうが安全でしょう。
その手間を惜しんだ結果、想像だにしない結果になっていたのであれば、きちんと管理、報告できない開発チームにも当然問題がありますが、その管理を怠った委託側にも大いに問題があるのではないかと思います。
この事例はオフショア開発でなくとも、日本国内で業務委託した場合でも事故になると思われます。しかし、私の経験上、驚くほど多くの方々がこのような事例を口にされていました。
事例４：日本国内で外注してうまくいった経験がない
最後に、日本で外注した経験が無い、あるいはうまくいった経験が無いのにオフショア開発を検討していらっしゃる事例です。
おそらく、開発コストを抑えたい、あるいはエンジニアリソースが足りないなどの喫緊の課題があったのだと思いますが、お勧めできません。自社で開発ができることと、開発業務を他社に外注することは、必要とされるスキルセットは別物です。
かつ、日本国内の業務委託よりも、オフショア開発のベンダーコントロールのほうが難易度は高くなります。コミュニケーションのほとんどがリモートになり、外国人とのコミュニケーションが必要になるためです。
ベンダーコントロールのための人的リソースが社内に無いのであれば、プロジェクト期間、あるいは立ち上げ時だけでも、開発チームの一部人員に御社オフィスで業務をしてもらうという方法は有効です。
金額はその分の費用がかかりますが、予算を確保できるのであれば、コミュニケーションコストも管理コストも下がり、プロジェクトが成功する確度は高くなることが期待されます。
