品質低下につながる「コミュニケーションロス」

オフショア開発というと「品質が悪い」「バグが多い」「要件が間違って理解される」などなど、こういったイメージを持たれる方は未だ少なくありません。

実際にGoogle検索で「オフショア開発」と検索すると、「オフショア開発　課題」「オフショア開発　失敗」といったワードが検索候補に並んでいることからも、オフショア開発に対する課題感・懸念を持たれている方が一定数存在しているということが見て取れます。

オフショア開発における品質課題については様々な原因が考えられますが、多くの場合「オフショア開発会社の技術力・開発力」に問題があるというよりも、日本とオフショア開発会社との間における「コミュニケーションロス」に根本の原因が潜んでいることが多いのです。

本記事では、オフショア開発における品質課題の原因として「コミュニケーション」に着目し、ベトナムでソフトウェアテスト・オフショア開発に携わった経験から、その原因と対策について掘り下げてご紹介します。

日本側にありがちな、表現や要求における「曖昧さ」

オフショア開発では、一般的に日本側で要求定義・要件定義を行い（更に基本設計まで行うことも多い）、その後オフショア開発先の言語に合わせて設計書を翻訳し、開発を進めます。

この翻訳の過程で仕様が間違って翻訳されることでいわゆる「仕様バグ」が発生し、それが実装を通じてシステムに欠陥が作りこまれる１つの原因となっています。

ではなぜ仕様が間違って翻訳されるのかというと、もちろん翻訳者のスキルによるものもありますが、それ以上に「日本特有の曖昧さ」がその原因となっているケースが多く見られます。

ここではベトナムでオフショア開発を行う場合を例として挙げますが、開発工程において上流工程のどこかのタイミングで日本語からベトナム語へのドキュメント翻訳を行います。
この日本語からベトナム語への翻訳を円滑に行うためには、翻訳者による定義や仕様に対する解釈の違い・誤解が発生しないよう、解釈の自由度を極力限定するように明確な言葉で定義した上で、詳細に記述する必要があります。
もし元となるドキュメントに多義的な解釈ができる曖昧な記述が含まれていると、それが仕様の矛盾や誤りといった仕様バグ発生の原因となり得ます。

しかし日本国内での開発（あるいは日本人同士での開発）を前提としてドキュメントを作成した場合、そのドキュメントをそのままベトナム語に翻訳すると、曖昧な記述が多すぎるために日本側が意図したとおりに翻訳されず、それが認識の相違やイメージのズレにつながることも少なくありません。

ドキュメントだけに限らず、ミーティングにおける会話や普段のチャットやメールでのやりとりに関しても同様です。普段のコミュニケーションの中に含まれる曖昧さが、少しずつ積み重なるようにお互いの認識のズレへとつながり得ます。

ハイコンテクストな日本の文化

そもそもなぜ日本人の表現や要求が曖昧になってしまうのかというと、日本語という言語自体が曖昧な表現をしやすいという理由もあるものの、その背景には「そこまでは言わなくてもわかるだろう」という日本特有の「行間を読む文化」があります。

日本は世界有数のハイコンテクスト文化と言われ、「言葉にせずとも理解する」「言葉以外の意味に重きを置く」という、コミュニケーションが言葉そのものよりも文脈や背景に強く依存する文化を有しています。
言葉に出さずとも相手の状況や意図を察し、いわゆる「空気を読む」ことが大事とされる文化です。

これは日本人同士では共通の文化としてコミュニケーション上でプラスに機能し得るものの、異なる文化をもつ外国人と仕事をする際には極めて注意深く意識する必要があります。
明確に言葉として伝えていないものは理解されておらず、伝えたつもりでも実は伝わっていないというケースは、異なる文化をもつ人々と仕事をする上で１つの典型的なコミュニケーションロスになります。

普段の何気ない会話ならまだしも、これが開発の上流工程において発生した場合、以降の工程に大きな影響を与えることは想像に難くありません。
仮にハイコンテクスト・ローコンテクストの文化差異を全く意識しないまま開発を進めてしまうと、このコミュニケーションロスが積み重なり成果物の品質低下といった形でその結果が表れてくることになります。

オフショア開発におけるコミュニケーションロスを防止するには

オフショア開発におけるコミュニケーションロスを防止するための対策として、大きく２つのアプローチが挙げられます。
既に表れた状況に対応する「対症療法」的なアプローチと、根本的な原因に対応する「原因療法」的なアプローチです。

ドキュメントのインスペクションによる対症療法

既に作成されたドキュメントに対し、「内容に矛盾が生じていないか」「定義や表現が曖昧でないか」「翻訳前後で異なった内容になっていないか」といった観点で専門家がチェックをするというアプローチです。
実装に入る前の上流工程のうちに曖昧さ（記述内容に加え、ルールや定義、フォーマットといった範囲も内包します）を是正し、要求・要件が正しく伝わる形に修正します。

ドキュメントインスペクションによってドキュメント品質が上がることで、以降の工程で作りこまれるバグの減少に寄与する他、開発スピードの向上にもつながります。
またインスペクションを通じた指摘により、ドキュメントの作成側に対しても、よりコミュニケーションロスが少ないドキュメンテーションを実現するためのインサイトを提供します。
それによってドキュメンテーション自体のルールやプロセス自体の改善をはかることが可能です。

しかしインスペクションは「既に出来上がったもの」に対してのアプローチとなることから、これだけでは根本的な解決には至りません。

コミュニケーションにおける徹底したローコンテクスト化

ここまでで、そもそも解釈の違いを生み得る「多義的で曖昧な表現」が、オフショア開発におけるコミュニケーションロスの１つの根本的な原因であり、それが成果物の品質低下につながっているということはおわかりいただけたのではないでしょうか。

そういったなかで、「言葉にしないことは理解されない」「言葉にしたことがそのまま理解される」ということを前提とし、要求や要件、ドキュメントの作成といったことはもちろん、チャットや会話などあらゆるコミュニケーションにおいてその前提を意識することが極めて重要です。
日本人のみが参加する開発プロジェクトにおいてすら、依頼の仕方が曖昧だったために本当に必要だったものと出来上がったものの乖離が生じるというケースもある中で、外国人を含むプロジェクトの場合はなおさら注意する必要があります。

特に最上流にあたる要求・要件に関しては、明確に記述をし解釈の自由度を限りなく下げることが重要なポイントにおける認識のズレを防止する上で有効です。
もちろん自然言語である以上完璧な記述は不可能ですが、その品質如何が以降全ての工程に大きな影響を与えるということをしっかりと意識することが、ひいては成果物の品質向上につながります。

同時にオフショア開発側もドキュメントを注意深く扱い、上流であればあるほどローコンテクストのコミュニケーションを意識することが大切です。
ローコンテクストを共通の前提とした上で双方が歩み寄り、丁寧なコミュニケーションを積み重ねることによってコミュニケーションロスの最小化がはかれると言えるでしょう。

発注元も受託先も、原因を安易に他責にせず、「こちらにも原因があるのではないか」「改善の余地があるのではないか」と真摯に問いかけ改善を続けることが、更なるオフショア開発の品質向上につながるのではないでしょうか。