オフショアがうまくいかなかったとき、ベンダーを変える前に見直すべきこと
SOWに署名しました。要件定義書を渡しました。半年後、コンパイルは通るが、ビジネスが実際に抱えていた課題を解決しないコードが手元にありました。
このパターンは、前回のオフショアベンダーを解約された、または切り替えを検討されている、プロダクト・エンジニアリング・情報システム部門の責任者の方々との会話で、繰り返し聞かれます。原因が技術にあることは稀です。チームはコードを書けました。チームはユニットテストを通せました。しかし「仕様書に書いてあること」と「ビジネスが必要としていたこと」のギャップが、納品物を使い物にならなくする、あるいは投入した時間と費用に見合う成果が得られないほどのリワークを要求するほど広かったのです。
このような経験をされた後、優れたエンジニアを抱えたベンダー、または厳格なQAを持つベンダーを探したくなるのは自然な反応です。両方とも重要です。しかし、どちらも根本原因ではありません。根本原因はほぼ常に関与モデル — 具体的には、オフショアチームが参画を許される瞬間 — にあります。
・失敗パターン：「仕様書を壁の向こうに投げる」
多くの日本企業の標準的なオフショア関与モデルは次のようなものです。日本側が要件定義フェーズを社内で完了させる、場合によっては国内コンサルティング会社の支援を受けて。完成した仕様書がオフショアベンダーに「これを作ってください」と渡される。オフショアチームは見積もり、契約し、実装を開始する。
・このモデルには3つの構造的失敗点があります。
① 第一に、要件定義書は決して完全ではありません。登録時のバリデーションルール。エラーメッセージの表示順序。パスワード強度ロジック。通貨の丸め処理。日付処理のエッジケース。何一つ書かれていません。すべてが — 静かに、ジュニアエンジニアによって、別の国で、別の言語で — 決定されます。結果を目にする頃には、20の一方的な決定が既になされています。
② 第二に、仕様書は実装の現実を反映していません。経験豊富なエンジニアが要件を読めば「これはLambdaで簡単に実装できますが、API Gatewayの設定で2週間かかります」と言えます。その声なしに書かれた仕様書は楽観的すぎるか、最悪の場合は実現不可能です — そしてその気づきは第1週ではなく第8週に起こります。
③ 第三に、品質基準のドリフトです。テストカバレッジ目標、セキュリティ要件、パフォーマンス予算 — これらが後付けで課される場合、リビルドが必要になります。要件定義から組み込まれていれば、追加費用が発生しません。
・上流工程からの参画は、実務でどのように見えるか
結果を変える方法は「次回はもっと慎重に」ではありません。構造的なものです。オフショアベンダーは要件定義フェーズそのものに参画する必要があります — その出力を受け取るのではなく。
VAONの日本のお客様との取り組みでは、シニアエンジニアまたはBrSE（Bridge SE）が、お客様のプロダクト・エンジニアリングチームと並んで要件定義ワークショップに参加します。会話は日本語で行われます — VAONのBrSEはJLPT N1を保有しており、これは日本のエンジニアリングチームと共に技術仕様書を共同執筆するために必要な言語レベルであり、単なる翻訳の介在ではありません。アウトプットは両者で共同執筆された仕様書です — ビジネスの意図を捉え、実装の実現可能性を尊重したもの。20〜40時間、最初に投じる時間です。
もう一方の選択肢 — 同じギャップを3ヶ月後に発見すること — は、100〜500時間のリワークを要します。これは理論上の数字ではありません。最初の取り組みが期待通りに進まなかった後にVAONに来られるプロジェクトで、一貫して見られる数字です。
・事例：東京の中堅製造業のお客様
東京に拠点を置く中堅の製造業のお客様（匿名化）が、前のオフショアベンダーとの6ヶ月のご契約を解約された後、VAONにご相談くださいました。前ベンダーは機能する社内物流追跡システムを納品されましたが、運用チームは使用を控えざるを得ませんでした — ワークフローが単一倉庫を前提としていましたが、お客様は複数の倉庫を運営しておられたためです。
VAONが再構築のための要件定義ワークショップを実施した際、マルチ倉庫の要件は最初の1時間で浮上しました。元のキックオフで触れられていましたが、仕様書には反映されていませんでした。前ベンダーは日本語での対話の機会も、上流工程への参画の機会もなく、何を確認すべきかを知る手段がありませんでした。再構築は11週間で完了し、納期通りに納品されました。お客様は現在、VAONとの2回目のお取り組みに入られており、今度は顧客向けアプリケーションです。
上流工程に参画する場合と、しない場合の差
・このパターンは、プロジェクトの規模を問わず一貫しています:
① 上流工程に参画する場合: シニアエンジニアの時間で20〜40時間、2〜4回の要件定義ワークショップに分散。プロジェクト内ではフェーズ1の見積もりの一部として表示されます。
② 上流工程に参画しない場合: 100〜500時間のエンジニアリングのリワーク、加えてスコープを再協議するためのステークホルダーとのミーティング時間。多くの場合、30〜50%のスケジュール遅延を伴います。
③ 累積的な効果は、当社およびお客様が追跡してきた複数プロジェクトのデータに基づき、納期通り・スコープ通りに納品できるプロジェクトの割合が一貫して高くなり、プロジェクト途中でのスコープ再交渉の発生も明らかに減るというものです。
このような経験をされた組織にとって、これは複雑な最適化ではありません。ベンダー選定の瞬間に行う、シンプルな構造的な選択です — その後ではなく。
・FAQ
上流参画は追加費用がかかりますか？ VAONではかかりません。これらの時間はフェーズ1の一部であり、当社の標準見積もりに含まれます。ほとんどのクライアントは、何を受け取っているかを明確に理解するため、上流フェーズが項目別に表示されているのを目にします。
プロジェクト途中でベンダーを切り替えると、追加のリワークが発生しますか？ 恐れているほどではありません — 新ベンダーがリビルド前に既存のものを監査する時間を取る場合は。当社は通常、リビルドのスコープを決める前に2週間の診断を実施します。これにより救済可能なコンポーネントがしばしば浮上します。
前回の契約からのNDAとIPはどうなりますか？ 前ベンダーの納品物は通常、前のSOWに基づいて貴社に移転されます。新ベンダーが必要とするのは、貴社が所有するアーティファクト — ソースコード、ドキュメント、要件 — のみです。当社と貴社の間のNDAは、いずれのアーティファクトが共有される前に署名されます。
上流工程からの参画は新規プロジェクトにのみ有用ですか？ いいえ。プロジェクトが進行中であっても、残りのスコープに対する要件アラインメントを再度行うことで、次のフェーズの軌道を変えることが可能です。これを何度か実施しています — 「スコープリセットワークショップ」と呼んでいます。
・おわりに
貴社が同様のご経験をされている場合、問いは「再度オフショアを試すべきか」ではありません。問いは「次のお取り組みが、オフショアチームの声が最も重要となる瞬間 — 要件定義 — に彼らを含める形で構成されているか」です。最初のコードが書かれる前になされるその一つの選択が、プロジェクト全体の進み方を変えます。
貴社の具体的なご状況をお聞かせいただき、要件定義からのお取り組みがどのような形になるかを次のステップとしてご一緒に考えさせていただきます。ご契約の義務はなく、提案資料もございません。
まずは luan.dang@vaon.com.vn までメールでご連絡ください。