RAKUS Developers Blog | ラクス エンジニアブログ

株式会社ラクスのITエンジニアによる技術ブログです。

トップ > エンジニアライフ-ベトナム > 【オフショア】英語が話せない開発エンジニアが感じたギャップ4選

【オフショア】英語が話せない開発エンジニアが感じたギャップ4選

エンジニアライフ-ベトナム

はじめに

はじめまして。ikedamasa1221です。

私は2021年の末くらいからオフショア開発業務に関わりはじめ、
今年度からブリッジSEとしてオフショア開発業務に従事することになりました。

実はこれまではずっと開発者として機能開発などに携わっており、ブリッジSE業務は初めての経験になります。
時には苦戦しつつ、時には楽しみながら、早く一人前のブリッジSEとして仕事ができるように日々頑張っています。

このようにラクスで初めてオフショア開発に従事したのですが、以前からオフショア開発なるものがあることは見聞きしており、
ネットで記事を見たり経験者に話を聞くなどしてある程度のイメージを持っていました。
しかし『百聞は一見にしかず』という言葉にある通り、イメージと違う印象を受けるような出来事がいくつもありました。

私の経験が、

  • オフショア開発に興味がある人
  • これからオフショア開発に従事する人
  • ブリッジSEの道に進むかどうか迷っている人

の参考になれば幸いです。 あくまで私の個人的な体験談であるため、客観性や正確性に欠く記述が多分に含まれると思いますが、どうかご了承ください。

また本記事はブリッジSEとしてオフショア開発業務に携わる一個人としての視点で書かれています。
事業としてオフショア開発に興味がある、またはオフショア開発事業を始めるかどうか検討されている方は、コチラを参考にしていただきたいです。

目次

オフショア開発とは

本題に入る前に、簡単にオフショア開発についてまとめさせていただきます。

オフショア開発とは、自社で行っていたシステム開発業務の全部または一部を海外の現地法人に委託することです。
日本よりも人件費が安い海外でシステム開発を行うことにより、コスト削減などが見込めるというメリットがあります。
また日本では、近年の人口減少によって人材不足が深刻化しており、その解消のためにオフショア開発の活用が注目されているという側面もあります。

以前はオフショア開発の委託先として中国が選ばれることが多かったようですが、最近はベトナムやフィリピンといった東南アジアの国々に人気が集まっているようです。
委託先の国選びにおいては、その国の人件費、教育水準（特にIT教育と言語教育）、国民性などの事情が考慮されることが多いとのことでした。

ラクスもオフショア開発拠点（ラクスベトナム）を2014年に新規で立ち上げており、その規模は年々拡大しています。

オフショア開発に従事して感じたギャップ

それでは私が初めてオフショア開発に従事して感じた、イメージとの違いやギャップについてお話させていただきたいと思います。
読者のみなさんには、みなさん自身が抱くオフショア開発やブリッジSEの仕事のイメージを思い浮かべながら読んでいただけると嬉しいです。

話す言語の違いについて

以前のイメージ「英語すら十分に話せない自分が仕事の依頼やレビューなんてできるだろうか...？」
↓
実際に働いてみて「なんとかなる。でも英語は話せた方が仕事の幅は確実に広がりそう。」

オフショア開発と聞いて最初に思い浮かべるのが話す言語の問題かと思います。
私は今のところ、最低限はどうにかなると感じています。

まずオフショア開発拠点に英語を理解できる方が多く、またチャットなどの文字ベースのコミュニケーションが多いため、英語の読み書きができれば最低限の意思疎通は図ることができると感じています。
特に"書き"の部分が大変ですが、翻訳ツールなどを活用すれば難しい内容や複雑な内容も伝えることができます。

ただし、大学入試程度の読み書きはできた方が良いのではないかと思います。
というのも、翻訳ツールがこちらの意図通りに翻訳してくれない場合があり、そういった誤訳に気づくためです。
（これはツールの問題ではなく元の文章の問題であることが多いで悪しからず。）

加えて、日本語とベトナム語の両方を話せる人の存在にも助けられています。
オフショア開発拠点に通訳の方や日本語が話せるエンジニアがいるため、仕事を依頼するときや会議の時に通訳をお願いしています。
しかし日本語が完璧に理解できるというわけではないので、こちらも難しい言葉や独特の言い回しを避けるなど、相手が理解しやすい話し方を行うことが重要になります。

このように最低限の仕事を行うことはできているものの、英語またはベトナム語を話せた方が仕事の幅は確実に広がると思います。
隣の席のブリッジSEがベトナム人の方なのですが、日々の進捗確認や実装方法の相談、成果物レビューのフィードバックを通訳を介さずビデオ通話されているのを見るとその方が確実に仕事が捗るよなぁと思います。
オフショア開発拠点に英語が話せる方も多いと聞いているので、英会話教室などに通って勉強しようかと少し真剣に考えはじめているところです。

慣習や国民性の違いについて

以前のイメージ「慣習や国民性の違いで諍いや行き違いが頻発してトラブルが多そう...」
↓
実際に働いてみて「相手に配慮することは大変だが、それが信頼関係につながる！」

日本とベトナムでは慣習や国民性が違う点もあり、その違いが原因で失敗したこともあります。
例えば、日本人は直接的な表現よりも間接的または遠回しな表現を好む傾向にあると聞いたことがあります。
ところがベトナムの方は真逆らしく、私が「○○を参考にして欲しい（○○の通りに実装して欲しいな...）」とコメントしたら全く別の方法で実装されてしまったことが何度かありました。
これは文字通り参考例の一つとして受け取られてしまったようで、私も日本人特有といわれる空気の力に頼ったコミュニケーションに慣れていたことを思い知らされました。
（もちろん日本人が相手の場合でも意図が伝わり辛いコメントの仕方なのではないかと反省しています。）

私はこのような地雷を一つずつ踏み抜きながら学んでいる最中なので、ときに疎ましく感じてしまうこともあります。

一方で、私の所属するチームでは週に一回オフショア開発拠点のメンバーに感謝を伝えるという取り組みを行なっています。
これは日本人と真逆で、ベトナム人は自分の仕事に自信や誇りを持つ人が多いという国民性の違いに配慮した取り組みです。
この取り組みは評判が良いようで、モチベーションや帰属意識の向上に繋がっているという声を聞きます。

このように、相手の慣習や国民性に配慮することは一朝一夕にできないことが多くて大変です。
しかしこちらが配慮すれば仕事もうまく進むようになり、この積み重ねが信頼関係の構築につながっているように感じています。

仕事の進め方について

以前のイメージ「オフショア開発拠点から質問や問い合わせが大量に来て、対応するのがとても大変そう」
↓
実際に働いてみて「思ったより質問や相談が来ない！？」

実は私が体験したことの中で、最もギャップを感じたのはこの点です。
オフショア開発先のエンジニアは依頼内容に不明点などがあっても確認せずに開発を進めてしまう方が多い傾向にあるように感じています。

例えば不具合修正の場合、ブリッジSEが依頼内容を整理したドキュメントを作成し、必要があればビデオ通話で内容を説明するなどして修正を依頼します。
このとき依頼ドキュメントの内容に間違いや漏れが出てしまうことがありますが、そういった不明点を確認しないまま仕事を進めてしまう方が多い印象を受けます。
レビューのときに間違いに気付くことができますが、場合によっては手戻りが発生して工数が無駄になってしまいます。

この点についてオフショア開発の経験が豊富な方に聞いてみたところ
「不明点を都度確認したり、曖昧な仕様を少しずつ相談して明確化しながら開発を進める人の方が少数だ」
と教えていただいて、とても大きなカルチャーショックを受けました。

もちろん、オフショア開発拠点側から見ると距離的な問題や話す言語の違いによって気軽に質問しづらい環境であることも理由の一つだと思うので一概には言い切れません。

しかし私自身、このギャップを受け止めて仕事のやり方を変えなければ！と思いました。
例えば、下記の点に気をつけながら仕事を依頼できるように心がけています。

  • 依頼前の準備を怠らず、なるべくブリッジSE自身が不明点を解消してから依頼ドキュメントの作成や仕事の依頼を行う
  • 重要な内容は口頭で伝えるだけでなく資料等に記載し、文字ベースの情報を残す
  • 定期的に声をかけるなどして質問しやすい雰囲気を作る
  • 質問は早めに返す（返事が遅ければ質問しても意味がないと思われてしまい、質問してくれないようになってしまうため）
  • 可能であれば中間成果物を提出してもらい、認識齟齬がないか確認しながら仕事を進める

以上のような互いの考えや癖を知ることができれば対策を立てることができ、お互いに気持ちよく仕事ができるようになると考えています。
こういった小さな違いを敏感に感じ取ることも、ブリッジSEに求められる役割の一つであると感じています。

品質について

以前のイメージ「品質が悪く可読性の低いコードばかりでレビューが大変なんじゃないだろうか...？」
↓
実際に働いてみて「品質はそれほど悪くないが、保守性や可読性に少々難があるように感じる。」

私のチームでは、オフショア開発先が提出した成果物のレビューはブリッジSE→日本のエンジニアの順番で行います。
このため、ブリッジSEがありのままの状態のソースコードをレビューすることになります。

今まで、何回かレビューする機会がありましたが、冒頭の通り品質はそこまで悪くないと感じています。
やはり日本のエンジニアと比べて仕様の理解に差があるためテスト観点の漏れなどが見つかりますが、
主要なケースは一通り網羅されているように感じています。

一方でソースコードの保守性や可読性には少々難があるように感じています。
例えば

  • 命名がわかりにくい
  • コメントがあまり書かれていない
  • ネストが深かったり整理しきれてない分岐がある
  • 責務分割の観点から見て適切なクラスに処理が実装されていない

等、様々な指摘が行われます。

やはり話す言語の問題、仕様理解やアーキテクチャ理解の差、スキルセットの違いなど様々な原因があると思われますが、こういった問題への対応は日本とオフショア開発先の間に立つブリッジSEの重要な役割であると思います。
実際に私の所属するチームでは、英語に訳したレビュー観点一覧を作成したり、オフショア開発先での内部レビューを支援するために日本のエンジニアに聞いたコツやノウハウを共有するなど様々な取り組みを行っています。
こういった取り組みを通して日本とオフショア開発先のエンジニアの両方に貢献できることもブリッジSEの醍醐味ではないかと思います。

まとめ

私自身、初めての経験ということもあり毎日いろんな壁にぶつかっています。
しかしブリッジSEの仕事を経験できたことは非常に幸運だと思っています。

特に話す言語や慣習が違うからこそ、誰かと一緒に仕事をする上で普遍的に重要なことが学べているのではないかと考えています。
また自分と文化的な背景が異なる人と働くことということは、それだけで仕事以外でも様々な気づきを得られてなかなかに知的好奇心を刺激されます。
（私もコロナが落ち着いたらベトナムに行ってみたくなりました。）

以上の内容が、オフショア開発やブリッジSEという仕事に興味を持つきっかけになれば幸いです。
長文になりましたが、最後まで読んでいただき本当にありがとうございました。

◆TECH PLAY
techplay.jp

◆connpass
rakus.connpass.com

ラクスの技術 / デザイン情報サイト
Copyright © RAKUS Co., Ltd. All rights reserved.