「ベトナムオフショア に興味はあるけど、コミュニケーションは大丈夫か心配」
「ベトナムでオフショア開発して、失敗したことがある」
ONETECHではベトナムオフショア開発を始めて５年目になります。正直申し上げますと期待していただいたお客様へご迷惑をおかけしたこともありました。この場をお借りしてお詫びいたします。しかしながら失敗したこと「しくじり」は日本サイドとベトナムサイドで必ず時間をかけて振り返っています。そして改善策を講じています。それはプロジェクト管理ルールやフォーマットとして開発者にも伝えて運用しています。
ベトナムでオフショア開発
この記事ではベトナムのオフショア開発の「プロジェクトキックオフ会議」を通じて「しくじり」から学んだ大事なことについてお話しします。
ベトナムでオフショア開発のしくじりの事例
弊社のベトナムオフショア開発で最も多い失敗は、クライアントとのコミュニケーションの問題です。例としては
- ブリッジとのチャットや会話がうまく通じず要求と違うものが出来上がってしまった。
- テスト等の作業範囲が要求と違っていた。
- 納品日とリリース日の勘違い。
- 対応デバイス、バージョンの対応範囲のギャップ
など他にもたくさんの事例がありますが、要は要求と成果物のギャップです。
これには色々な問題が絡んでいます。
例えば、1.についてだけ言っても、チャットや口頭により要求事項が整理されておらずブリッジからベトナムオフショア側のプロジェクトマネージャー（PM）に要求が伝わらなかった。ブリッジの日本語能力の問題と、クライアント側の伝える能力の問題（失礼な言い方ですみません）、要件定義や仕様定義が曖昧で仕様漏れや、仕様変更が多発し納期までの適切な工数を圧迫（オーバーフローが発生）と過去に実際あった原因だけでもたくさんあります。特に安請け合いで行間に潜んでいること(AR/VR開発、CG
制作でよくある)を受けて側が分かったと言ってしまっているケースもあります。ほぼ言った言わないレベルの問題が多いです。また極論するとほぼ要件定義や仕様定義、（スケジュールの確認なども含めた）の段階で防げた問題が多いことに気づきました。
「しくじり」（失敗）から生まれた「プロジェクトキックオフ会議」
上記の様な失敗は、毎回ONETECHベトナムと日本で反省会（振り返り）をしていくわけですが、多くの問題は上流工程（契約、発注書、要件定義、仕様定義）での確認で大概は防げるのではないかということになりました。考え方は着手前に５W１H的にフォーマットを決めて出来るだけ全てのことをクライアントと漏れなく確認しましょうということです。実はこれを機に営業が発行する見積書もかなり細かく前提条件をクライアントに提示するフォーマットに変更しました。また実際の開発現場の関係者の確認会として、発注のあとの開発着手前にクライアントと該当プロジェクトに関わるONETECHのベトナムオフショアスタッフ全員参加で「プロジェクトキックオフ会議」を開催することになりました。
「プロジェクトキックオフ会議」の内容
プロジェクトキックオフ会議ですが以下の様に行います。
参加者：クライアント側PM、営業担当者
ONETECH営業担当者、PM、オフショア責任者、エンジニア、ブリッジ
開催タイミング：開発着手前に実施（３０、４０分程度）
内容：
1. プロジェクトの体制と担当者の紹介
2. 要件の確認、システムの目的（業務フロー）の確認、納品方法の確認
3. 仕様書の確認（事前確認しておいてQA）
4. マスタースケジュールの提示（詳細スケジュールは後日提出するケースもあります）
5. マイルストーンでの成果物の確認
6. 報告の仕方（成果物の段階納品や、定例会議の有無など）
7. 開発管理ツールやコミュニケーション方法の確認
8. セキュリティポリシーの確認
9. プロジェクトのリスクの提示と確認
上記の6.7.を補足しますと、
- 日次・週次報告が必要か、定例会議をするのか
- チャットなどは利用するか、QAリストの運用方法など
- ソースは定期的にプッシュするか
- コミュニケーションのTIPS（やさしい日本語や、図式化や画像を利用してコミュニケーションして欲しい）
上記の様なアジェンダを作ってオンライン会議で進行します。
実は以前もやっていた「プロジェクトキックオフ会議」
「しくじり」（失敗）から生まれた「プロジェクトキックオフ会議」- Onetech Asia
実は「プロジェクトキックオフ会議」は以前やっていたことがあります。数年前に今のベトナムオフショアサイドのゼネラルマネージャー（GM）、ベトナムオフショア開発責任者が就任した頃です。上記の様な非常に良いフォーマットだなと思っていたのですがいつの間にかなくなってしまいました。おそらく現場からは、必要から生じたものでないので負荷だけが増える様に見えて敬遠されてなくなったのではないかと思っています。よくある話です。目的を伝え切ることができなかったのかもしれません。人間は痛い目に合わないと本気で改善しようとしない性があるようです。
「しくじり」（失敗）から学んだ大事なこと
ONETECHのベトナムオフショア開発では毎回、毎回この様な大小様々な「しくじり」（失敗）を反省しています。これによって数年前より断然バグも少なくなり、残業や休日での駆け込み開発も減りました。しかしながらある一定の周期でまた同じ様な「しくじり」が発生します。「これ、１年前も話したよね」なんて会話が「しくじり」の内容とその反省会という二重のデジャブの様に発生します。一度決めたことを日本サイド、ベトナムサイドもルールとすることはできます。しかしながらそのルールは一時的に現場に浸透し運用が始まるのですが、いつの間にか忙しさにかまけてルールが形骸化してしまいます。１年くらい経つとルールでなくなってしまうのです。かつてあった「プロジェクトキックオフ会議」の消滅もこのパターンです。
要はルールを定義するが粘り強く運用ができていないということです。この悪い習慣に明確に気づかずに毎回、毎回同じことを繰り返していました。例えばレビューを必ずしようというルールにしてもいつの間にかレビューを怠ってしまう。二重チェックをせずに同じミスを繰り返す。これは組織でも個人でも同じことが言えると思います。習慣化することが大事です。
実は一番大切なことはルールを維持改善しながら運営していくこと、組織として良い習慣を身につけることでした。
最近経営陣でもグループ会社の「バインミーバーバー 」（東京でバインミー の専門店を経営しています）を例にして話をしています。
バインミーが美味しくなかったらプロモーションしても無駄だ、お店のサービスが行き届いていなかったらお客さんを読んでも不満しかない。
これはシステム開発に置き換えるとしっかりとお客様の要望に応えること、品質や納期をしっかりと守ることにつながります。
大事なことをどの様に定着させるか
この大事なことは「プロジェクトキックオフ会議」維持改善、運用だけでなくあらゆる改善活動で重要です。
具体的には以下の様に維持改善しています。
・ベトナムオフショア 開発拠点での朝礼での「しくじり」の共有
・「しくじり」のリスト化
・新入社員への「しくじり」とルールの共有
・ONETECHの日本サイドとベトナムサイドの管理者で「しくじり」の共有
・品質信頼が大切だということ「TRUST BUILD TRUST」ONETECHのスローガンの浸透
・ルールの定期的な見直し
まとめ
今回の記事を書いて分かったことは、粘り強く良い習慣をつけることは、お客様を第一に考えてより良い品質やサービスを提供することに他ならないと思いました。またベトナムオフショア関係のスタッフ全員にそれを粘り強く説き続けることが大事です。いくら部分的にフォーマットを作ったり、ルールを決めてもそこに目的がともなわいないと形骸化してしまいます。そしてそれを実行するには粘り強さ、情熱が必要です。
今後は「プロジェクトキックオフ会議」を粘り強く、情熱を持って維持改善、運営をしてまいります。
ベトナムオフショア開発のONETECH
オフショア開発でも「トラブルがほとんどない」、プロジェクトマネジメントと技術力に強みがあります。
株式会社One Technology Japan | ベトナムオフショア開発 | 信頼第一のONETECH
当社のオフショア開発では、日本の拠点にいるプロジェクトマネージャーとブリッジSE、ホーチミンにいる日本語でのコミュニケーションが可能なブリッジSEが、常にプロジェクトを管理しています。日本側では、おもにお客様と日本人のプロジェクトマネージャーが直接にお客様に応対をし、上流工程を担当。開発をホーチミンで担当しています。
日本側でプロジェクトの進行管理、コミュニケーションのサポートを常にしており、そのうえで案件ごとにプロジェクトチームを作り、オフショア開発全体の責任者、技術サポートと品質管理の責任者を配置することで、品質を保っています。オフショア開発の体制をきちんと整備して、プロジェクトを推進していることが当社の特長です。
ベトナムオフショア開発についてご質問があればお気軽にお問い合わせください。
