転ばぬ先のベトナム情報（３） オフショア/ラボ開発・騙されないための７項目
すでに流行りは過ぎ急激な円安も進んだ今、オワコンになりつつありオフショア開発ですが、それでも人が足りなかったりDX！というはやりもあり、アプリなどを開発したい、使ってみようか？というケースもあるかと思います。
これまでベトナムで１０数のプロジェクトを観察して得た知見と、日本での２０年以上の開発経験を踏まえてチェック項目をまとめました。
そもそもベトナムの開発ってメリットある？
コロナが終わってベトナムオフショアの広告記事や、募集がネットにだんだんと増えてきているかと思います。
こうした記事や広告は、労力や費用がかかるので企業としては「目的」を持ってそれなりに真面目に行いますが、あくまでその企業の思惑・利益のための「真面目」さであって、事実とは限りません。
海外記事の多くは日本の読者が知識・経験の面から反論しづらいので、言ったもん勝ちになりやすく注意が必要です。
ベトナム開発のデメリットははっきりしていて、言葉や常識の壁があり、その土台となる共通の知識やモラルが日本と大きく隔たりがあることです。
このデメリットを跳ね除ける決定打はまだ発明されていないので、様々な苦労・労力（コスト）を伴います。
会社の金銭的な利益はあっても、働く側にとっては不効率でしか無く、開発に関してのメリットは少ないと言えます。
人不足からの苦し紛れの策なので、デメリットがあるのはもちろん当然ではあるのですが、プロジェクトが進むと関係者以外は不都合なことは忘れ「そんなのはじめから承知の上だろう！」と逆に上から。。。というのもよくある絵です。
担当される方は肝に銘じてください（泣笑）
✅オフショアに本当に頼むべき？チェックリスト
開発管理のノウハウが十分にある
予算は潤沢か
開発期間に余裕がある、未定である
仕様書がある、詳細な仕様を作れる、テスト仕様書も作れる
PM/ディレクターを立てられる
英語で仕事が出来る
論理的・合理的な体質の会社、組織である
TDDをある程度確立している
１．開発管理のノウハウがある
オフショアでは発注側が「レンタルしたベトナム人/チーム」に仕事をしてもらうためには開発ノウハウが必要です。ラボ開発側でPMやBrSEを立ててマネジメントをしてもらう事が出来るようになっていますが、往々にしてうまくいきません。なぜでしょうか？
理由は準委託契約のからくりにある
オフショアラボは開発側に製品の機能や品質や納期について、責任が少ない順委託契約で、発注者に変わり人を集め開発室に座らせて仕事をさせる「開発者レンタル」サービスです。
多くのオフショア会社でPMなど管理者を設定することも出来ますが、受託側と発注側の利害は別なので無理があります。
準委託のラボ開発では「チームのレンタル」ですので開発側に仕様や納期の責任がなく、通常PMが管理する「要件」「仕様」といったものは発注サイドにあり、伝言ゲームになりがちです。
こうした事を防ぐためには、発注側が
要件定義 （BRD,SRD)
仕様書
詳細仕様書
を定義して開発に理解してもらい、場合によってはより効果的に開発が出来るような作業順を示す必要があります。
オフショアのPMはアテにならない
そうはいっても、PMやBrSEに金を払っているのになぜ？と思うのは自然なことです。
同じように受託側にも「自然なこと」があります。
頼んでいる側がなぜ仕様を説明できないのか。受注側は何を作りたいのか知りません。（PM,開発側）
外国語なのでわかりやすい文書・資料がないと理解できない（あっても理解できないくらいなのに。。）
作業は少ないほうが楽なので同じ金額なら簡単で少ない作業が良い。資料がないから最低限でやろう。
開発者は人数が多くPMは１名、同じ場所で（なかよく）働いているので発注側の立場でPMが仕事をするのは無理が有る
（受託側経営者）ながいプロジェクトは有り難い、作業が長引くのはメリット
と、彼らには自然な理由がありますが、これは発注側には全て不利益なことです。
オフショア開発では、こうした事が表面化しないよう、BrSE(ブリッジSE）やBA（ビジネスアナリスト）というポジションを（お金を取って）設定して発注側のストレスを緩和する構造を提案するのが普通です。
ベトナム人開発者は粒ぞろいであることはまず無く、また日系企業では組織内の信頼関係も希薄な部分があるため問題回避的になりやすいこともあり、十分な仕様書・詳細仕様書が提供されない場合はこの部分の問題が大きくなりやすいです。
オフショアのさらにヤバイPMの現実
ベトナムは上下水道や鉄道、電気などのインフラが未だまだ行き渡っていない発展途上国。
日本人であれば「ごく当たり前」の知識、たとえば「よく知られた物の名前」「商売の仕組み」など、「当たり前」の常識・知識がない人が普通です。
また多少知っている人がいても、その人の周りのほとんどの人は知識・経験がない為、『全体の共通認識」としての知識・常識には遠いのが現実です。
日本では、国民一人あたりが読む本は平均２０冊/年といわれていますが、ベトナムは１冊未満。本をまともに読んだことがない人が多数派です。
工場の単純作業でも問題が多いという話もよく聞きますが、ITでは製造業の工員などに比べ、遥かに高い言語・論理能力・幅広い知識が必要なのは言うまでもありません。
そうした中で「少し開発経験がある人」がPMとして、まとめ役やスケジュール管理、品質や工程の監督をしたらどうなるでしょうか。結果は明らかです。
ベトナムオフショアにおけるPMの職務は、作業者が（基本ルーズなので）やってない仕事を指摘したり、出来な言い訳や忘れてしまった作業を説得してやらせたり、とかなり低レベルな進行管理が普通で、当の本人も日本語で全ての仕様を理解できるわけでもないので、ブカブカな品質管理となるのは普通のことです。
2. 予算は潤沢か
予算が少ないのでオフショアに、という話をたまに聞きますが逆じゃないかと思います。 単価は実は割高で、期間も伸びがちだからです。
単価が安くない理由は以下のようなものです。
通訳やBrSE、PM、QAなどで全て合わせると安くならない（が、それらがないと正常に作業が進まない）
技術者が単機能工だったり知識経験が浅いのでチームの人数が多くなる。
人数が多くなるのでコミュニケーションやマネジメントでロスが増え工期が長くなる
作業精度が悪いためテスター必須。QAの質も悪いので人数は多めに必要。
社会主義なので残業がない（するとコストが倍加）
などの理由で積算見積りの時点でもさほど安くないだけでなく、パフォーマンスでは安かろう悪かろう、となり実際に作業が始まると高コストなことに気が付きます。
（初期の段階でも高くなりがちで、オフショア会社の営業マンが受注に苦労すると頭を抱えていくらいです）
日本人であれば F/E, B/E, PM だけでサクサク進むプロジェクトでもベトナムでは
PM, BrSE, FE x2 , B/E, インフラ, QAx2, QAリーダー１、通訳 。。。などとなり１０名もの人が簡単なアプリを作る大チームを構成したりするのはよくある光景です。
人数は３倍以上、スピードは半分以下、バグやトラブルは１００倍、細かい仕様まで書かないと実装されない、、というような状態となります。
さらに、構造的な問題として「オフショラボの準委託では受託側に本質的には納期や製品完成の義務がない」ので、工期が伸びやすく、結果として金額がかさんでいきますし、ラボ経営者の利益の源泉はこの部分です。
3.開発期間に余裕がある、未定である
予算が潤沢で、仕様も確定しておらず、開発期間が決まっていない（伸ばせる）のであれば、オフショアラボ開発は良い選択になるかもしれません。
上記の状態ではそもそも受託開発では話がまとまりづらく、経営判断や担当者の日々の業務も難しくなるからです。
社内で実験プロジェクトのために部門をつくり、人を雇い入れて中長期計画に予算を組み込み、、、というのは経営資源の無駄遣いになりますし、担当者としても無理に通常の委託開発をした場合の成果物の評価などは、無駄な作業となることも多いはずです。
会計や評価システムもこうした実験的なことには適応が難しいため、いつでも終わらせることが出来るラボ開発がマッチングが良いと言えます。
４．仕様書がある、詳細な仕様を作れる
これは主観が入るので「作れる」という状態をどうとらえるか難しいのですが、日本では十分な仕様書でもベトナムオフショアで使う場合にはまず役に立ちません。
理由は開発者は何も考えず、機械的に作業をすれば良い、くらいまで書いてある前提での「エンジニア」だからです。
前述のようにベトナム人は本を読まず教育システムも適当で、かなり低レベルな促成作業者がほとんどですので、読解力は低く基礎知識が圧倒的に不足しているので、細かく書いてあっても前提知識がないため行き違いが多いのが普通です。
結果として細かく書いてないことはトラブルとなり、
「仕様にありませんので工期が伸びます」
「違う解釈で作ったので修正に時間がかかります」
という報告がBrSEやPMから来ることになります。（少なくても現場ではそういう事が起きています）
この仕様書・詳細仕様書は本来は発注者側にある情報であり、
「専門ではないのではっきりは書けません、なんとなくこうしてほしい」
という要素の数だけ、工期は２倍３倍と増えてしまいますし、作り直したり修正をすればバグの発声も増えていきます。
PMなり起案者が作る仕様書などは、受注側が代行して作る場合は開発経験や目的のアプリに関連する知識が豊富な日本人が必須でしょう。 ベトナム人で不可能とまでは言いませんが、日本語や利用者の都合がわからない人に仕様書を書かせ開発できる！というのはさすがに無理があるでしょうか。
また作る意志がある発注者側が明文化できない、決めきれていことを他人が決められる、と考える丸投げ発注には首を傾げざるを得ませんが、作ったのを見てから考えて変更していく、という場合、通常の建築に加えて増改築の技術に加えて非破壊検査的な「作ってしまったものを壊して、またつくる」というより高い技術・別の技術が必要になるのはソフトウェアでも同じで、担当者が離職済みで別の人がこうした作業をする場合、さらにリスクは高まります。
5. PM/ディレクターを立てられる
ベトナムオフショア側のPMの知識・能力は限定的で、遅れても責任を問われなず開発費を払ってもらえる準委任契約ですから、開発費や工期を管理したいとなれば、どうしても発注者側に経験や管理能力が必要となります。
またこれを回避するためにPMだけは日本人で固め、工期をはみ出た分はあるていど受託側が負担してくれるベトナムオフショアもあります。（基本単価・コストは当然高くなります）
しかし遅れたり、トラブルの対応で発注者側のマンパワーが取られるのは結局同じですので、発注者側にある程度専任で動けるPM/開発ディレクターがいて監視や評価が出来る前提は必須と言えるでしょう。
6.英語で仕事が出来る
ベトナム側の基礎的な問題は、知識の圧倒的な欠如とコミュニケーションロスです。
これを緩和する方法は「英語」がベストです。
（知識格差の問題はこちらにくどいほど書きました）
(転ばぬ先のベトナム情報（２） ベトナム人は優秀って本当？
https://note.com/mz700/n/n2148c76c5fd9?from=notice
理由は色々ありますが、双方が英語が出来る人が担当であれば、どちらかが「不利」「アウェー」で仕事をする不均衡がなく、またバイリンガルは一般的に言語能力や語彙力の平均が高く、さらにITの用語は基本英語であるので、「知らない」単語かどうか検出が容易になる、ことなどがあります。
これは日本人どうしてもありがちで、横文字を並べてごまかす、というのは英語話者には通じない、といえばわかりやすいでしょうか。
ベトナム人はごまかすのがうまい
ベトナム人は様々な知識が日本人の平均と比べると圧倒的に低く、ベトナム人同士でも知識のばらつきがあるため、複雑な意思疎通はうまく行かないことがよくあり、地に上的にそうした事を「ごまかして」生活しています。
日本語も主語を明記しないとか、要件をはっきり伝えない傾向があるため（目上の人のに合わせて下が頑張って帳尻を合わせる言語・文化）、外国人とのコミュニケーションでは問題が多いです。
なぜなら外国では「常に相手のせいにするのが前提」だからです。社会主義で外国人の立場が弱いベトナムではおおっぴらに、言った言わないなどの「言い訳」が始まります。
（こちらに関してはおもしろいエピーソードをまとめて別記事にする予定です）
知識無くてわからなくても、普段から分からない事を誤魔化して生活しているので、わかったフリでやりすごしたり「わからないことがわからない」まま進むのがベトナムでは主流です。 道を聞いても知らないのに適当な場所を教えたりは朝飯前、つねに出任せや知ったかぶりを目にする土地柄なのです。
ですので、知らないことがあっても「そこは気にせず、わかることだけやって終わったことにする」という日本では考えられないことが普通に起きますし、その後には１０００の言い訳や「発注側も悪い」といった不毛な話が出がちです。
（作業確定前には知らない・わからない事があると、様々な理由を付けて「それはやらないほうがいい」という方向へ持っていこうとします。知らないと言うと評価などで損だ思っているからでしょう。）
お互いが第２言語の英語をつかい、それなりに勉強した人同士が意見をすり合わせることでこの問題を大幅に緩和することが出来ます。
ただし、日本人側がベトナム人よりも英語の語彙やスキルが高いのは必須となります。日本人の英語能力が低いことを理由に別の言い訳が始まるからです。
7.論理的・合理的な体質の会社、組織である
ベトナムは社会主義であり、多くの人が知識がない子供のような反応をするため、感情的・封建的な言動や「前提」は単純に相手がアレルギー反応を起こして、コミュニケーションが難しくなるだけです。
ベトナム人を使うためには冷徹な合理性・論理性でベトナム人の性質や社会を見極めた上で、合理的な対応・計画が出来いる会社が良いでしょう。
そうでない場合は、ベトナムと対する担当者が非論理のひたばさみになり、やんでしまったり退職となります。
実際に、ベトナム担当の退職者は日本側・ベトナム側共に非常におおく１年程度で燃え尽きてやめてしまうのは珍しくありません。
8.TDDをある程度確立している
様々な作業・知識レベルに問題があるため、テストを中心とっした開発サイクルがない場合、担当者が常にトラブルに忙殺されて本来の意味の品質や工数管理どころではなくなってしまいます。
ベトナム人側もテスト駆動で作業をさせないと、毎回指摘や確認をすると関係性がこじれて、益々真面目に仕事をしなくなりやすいです。
発注側にこのノウハウがまるでない場合は、工期予算が潤沢であることは必須となります。
✅(予告)解決方法
ラボ発注に必要な開発ノウハウとは？
複雑な話なので別記事として後悔しますが、主なものをあげると
自社がオフショア発注に向いているかをまず考える
危ない会社を避ける
ウォターフォールでの開発を前提とする
発注にあたり、管理に開発専門家を最低一人は立てる
などがあるかと思います。
よくアジャイル・スクラムといった高度開発・高サイクルリリースの開発手法を強みとするラボがありますが、それを見て「怪しいな」と思える程度に開発経験や知識がない場合、オフショアラボは危険です。（アジャイルが悪いという意図は毛頭ありません）
なぜなら会社でのパソコン作業経験が５年の人が「ベテラン経験者」とされるベトナムにはめったにS級の開発者はおらず、指示通りに働く単機能工がほとんどだからです。
アジャイルは複数スキルがあり指示が必要ないSクラス人材が少数精鋭が前提で、ハイスピオード・適時開発をする為の手法です。（言い換えると開発合理性よりもマーケティングを優先するための開発手法です。）
物を作るのに近道はなく、必ずメリットデメリットが出てきます。
(なぜアジャイルはいつでも有効でないのか？という記事）
伝統的な開発ができる組織がアジャイルをする場合の話で前提は高度なものです。
「アジャイルジャーニーに突入する前に、確固たる理由が必要です。トレンドを追いたいだけなら、やらないほうがいい。「なぜ欲しいのか」を考えてみてください。」
https://kanbanize.com/blog/agile-challenges/
ソフト開発はビルの建設などと同じで、目的や要件を精査した上で、仕様書を作り込み設計をし、リソースを見積り割り当て、マイルストーン毎のウオーターフォールでの開発が基本となります。 スクラム・アジャイルをうたうオフショア開発がたくさんありますが、開発の知識や経験がなかったり、もっぱら営業文句で内容を理解していないケースがほとんどです。
本来アジャイルは個々の人が指示が必要なく動けるエース級だけでチームを編成する事が前提で、様々なデメリットを置いてもリリーススピード優先の開発を達成するための手法です。
もともと「安く作りたい」というのがオフショア開発なのですから、そこに主眼をおいて「実現できる計画か」を真剣に検討すべきと思います。
（おすすめの方法は別記事を編集中です。もうしばらくお待ちください。）
(転ばぬ先のベトナム情報（２） ベトナム人は優秀って本当？
この記事が気に入ったらサポートをしてみませんか？