※本記事は非常に古いため、新しく書き直した下記の記事を参照することをおすすめいたします。
勉強会などでお会いさせて頂いた方々のお話を伺っていると、「昔オフショアやってみたんだけどうまく行かなかったんだよな。。。」というお話をよくいただきます。しかしよくよくお話を伺ってみると、委託先への仕事の渡し方が非常にまずいなと感じることがあります。この場合は開発会社が頑張ってもうまく行く確率は非常に低いです。どのようなケースでしょうか、列挙してみたいと思います。
本記事は「ベトナムオフショア開発で失敗する事例 〜受託側編〜」の続編になります。
前提：日本人のコミュニケーション方法は独特
これは私の持論なのですが、日本人のコミュニケーション方法は非常にユニークで、日本人同士のコミュニケーションに特化したものであるということです。裏を返すと、日本人の通常のコミュニケーション方法は、外国人とコミュニケーションを取るときには全く向かないということです。
日本人のコミュニケーションを一言で表すと「聞き手主体で曖昧な表現」です。例えば、
- 聞き手側が理解しようと努める
- 全てをストレートに伝えない（伝えなくても伝わる）
- 行間を読む
- 空気を読む
一方、様々なバックグランドを持つ人達が集まっている国では、意思は伝わりづらいというのが前提となり、「話し手主体で明確な表現」を取る傾向にあるようです。ベトナムもそうです。つまり、何かうまく伝わらなかった場合、話し手側がうまく伝えられないことに責任があるという考え方です。
この点に関してはこの論文に、日本語のコミュニケーションモデルは「モノローグ」、英語圏は「ダイアローグ」であると紹介されています。
いきなり何の話をしだすのかと思われているかもしれませんが、「日本では今までこういう伝え方をしていたんだから、ベトナムでも同じ方法で理解できるよう努めてくれ」というようなコミュニケーション方法というか仕事の仕方は根本的に非効率的だということを前提として理解する必要があるということです。
前提：日本人の労働感も独特
日本人の労働感も独特です。“働くことそのものに価値がある”という労働観を持っている点です。人生において、プライベートよりも圧倒的に労働を重要視します。これは他国と比較すると一般的でないどころか、かなり変わった労働観です。これを外国人に押し付けても誰もついてこれません。ベトナムも同様です。労働観の違いに関しては「SONYとマッキンゼーとDeNAとシリコンバレーで学んだグローバル・リーダーの流儀」に非常にわかりやすく書いてありました。おすすめです。
これは国民性の話であって、人には国民性以上に個性があります。したがって、「私生活を顧みずにひたすら働くのが好きなベトナム人」も当然いますが、大多数ではないという話です。多くのベトナム人にとって、仕事よりも家族が大切だったりします。
日本人の感覚では「働かざるもの食うべからず」で、「叔父のいとこの具合が悪くて早く帰らないといけないです」みたいなことを言われると、「仕事のあとではダメなのか？」と感じてしまいます。しかし、これは労働観であり人生観なので、何が大事なのかという正解があるわけではありません。むしろその国の尊重しなくてはいけない部分です。人生において重要なのは労働だけでは無いということです。この点を無視して外国人と一緒に働くことは難しいでしょう。
行間を読ませる仕様
さて本題ですが、一番失敗しやすいのは「行間を読んでもらうことを前提とした仕様書」です。上でも述べたように、これが通じるのは日本人同士だけです。
ありがちなのは「AをBに変更すると記載しているのだから、当然A’をB’にしてくれるだろう」ことを期待することです。長い間一緒に仕事をしている開発メンバーならまだしも、スポットのプロジェクトでこのレベルを期待するのは無理ですし、むしろ事故の元なのでやめるべきです。（もし行間を読んで意図を汲んでくれる人がいれば、その人はかなり優秀なので絶対に手放さないでください！）
ではどうするかというと、私の意見としてはどちらかかなと考えています。
- 腹を括って、抜け漏れのないドキュメントを仕様書として渡し、そのとおりに作ってもらう。
- 認識相違は起きる（あるいはドキュメントに間違いがある）という前提で、テスト環境へのデプロイとレビューのサイクルを高速にまわし、作りたいモノへ「育てて」いく。
前者の方が確実ではありますが、ドキュメントは一般的にメンテされずプロジェクト後半は何が正解かわからなくなりがちなので、個人的には作成するドキュメントは最小限に抑えて後者の方法で進めることを推しています。
とはいえ、バランスは大事です。「赤信号を渡ってはいけない」レベルまで仕様として記載する必要はないですし、ドキュメントに記載が無い部分でも「こういう動作で良いですか？」「こういう動作はどうでしょうか？」と質問なり提案しながら進めることができるのがプロの開発者としての姿勢です。なんでもかんでも「仕様」が決まってないからという理由で先に進まない場合は、開発会社へ改善要求を出すべきところでしょう。
「品質」として何を求めているかの合意形成をしていない
「品質」として何を評価するのかをすり合わせないと、一生「品質」は上がりません。
「昔オフショアやってみたけど品質が悪かった」というお話はよく頂きます。
よくわかります。オフショアでは期待してた品質を下回ったものが出てくることはよくあります。
しかし更に、「どんなレベルの品質を求めているのですか？」という質問をしてみると、意外に明確な回答が返ってこないことが多いです。「日本のような品質」とおっしゃられる方もいます。
日本レベルの品質とは具体的にどのような品質でしょうか？
日本国内の開発会社でも、成果物の品質はバラバラですよね。
つまり、「品質が出ない」のではなく、「どのレベルの品質を求めているか」という合意形成が出来ていないケースの方が多いということです。
また、発注側である日本人が求める品質と、ベトナムで良しとされる品質レベルにも差があります。そもそも品質として評価する基準が違ったりします。（バグがでない＝高品質と思っているベトナム人エンジニアはかなり多いです。）
結論として、「品質」というものを出来る限り定量化し、各プロジェクトでどの指標をどのレベルで維持して納品してもらうかを、プロジェクト開始前に合意形成をとっておくと「品質」は格段によくなるはずです。
マネジメントを開発チームに丸投げ
話を伺っていて驚くのが、「納品時の品質がとんでもなかった」「気がついていたら遅れていた」のようなケースです。
これも気持ちは非常に良くわかります。仕様とスケジュールを決めたのだから、あとはよしなにやってくれることを期待していたのでしょう。何か問題があれば開発チームから報告があることを期待していたのでしょう。しかし、途中経経過の確認くらいはすべきだったと思います。それだけでこのようなケースは未然に防げたはずです。
「日報では問題なしとの報告だった」という話もよく聞きます。しかし、よくよく認識しておく必要があるのが、日本人の思う「ノープロブレム」と、ベトナム人の思う「ノープロブレム」はレベル感が全く違います。率直にいうと、ベトナム人の「ノープロブレム」は、日本人にとっては「ノープロブレム」で無いことの方が多いです。
やらなければいけなかったのは、途中まででもいいので、出来ているものを自分の目で確認することです。その手間を惜しんだ結果、想像だにしない結果になっていたのであれば、きちんと管理、報告できない開発チームにも当然問題がありますが、その管理を怠った委託側にも大いに問題があるのではないかと思います。
日本国内で外注してうまくいった経験がない
最後に、日本で外注した経験が無い、あるいはうまくいった経験が無いのにオフショアを検討していらっしゃるお話をたまに伺います。おそらく、開発コストを抑えたい、あるいはエンジニアリソースが足りないなどの喫緊の課題があったのだと思いますが、お勧めできません。自社で開発ができることと、開発業務を他社に外注することは、必要とされるスキルセットは別物です。外注した開発案件をハンドリングできるリソースが社内に無いのであれば、外注先が日本であってもベトナムであってもうまくいかないです。
