要約： オフショア開発が失敗する主な原因は、開発を始める前に仕様が十分に固まっていないことです。エンジニアの腕や、委託先の国の問題ではありません。仕様の抜けは、動くものを触って初めて見えてきます。VAONは、仕様確定フェーズ（要件を書面で確定し、固定価格で見積り、その時点で止める選択もできる）でこの抜けを先に潰します。
目次
- オフショア開発の失敗は、コードと仕様書のどちらが原因なのか
- 仕様書の抜けは、オフショアのチームに渡ったあとどう現れるのか
- 委託先の国を変える、ブリッジSEを増やすだけで解決するのか
- VAONの仕様確定フェーズでは、何をするのか
- 高知工科大学のSeminar Naviでは、何を行ったのか
- 仕様確定フェーズが向かない場合
- 契約前に、どのオフショア会社にも確認したい5つの質問
- よくあるご質問
1. オフショア開発の失敗は、コードと仕様書のどちらが原因なのか
オフショア開発の失敗は、コードの品質よりも仕様書の不足が原因になることが多いと、VAONは考えています。コードは、決まったことを形にしたものです。決まっていないことは、腕のよいエンジニアでも推測するしかありません。その推測が外れるのは、珍しいことではありません。
先に断っておくと、VAONには失敗原因を示す統計がありません。「オフショア開発の○%は要件の不備で失敗する」といった数字はインターネット上に出回っていますが、出典をたどれないものが多く、VAONは使いません。
参考になるのは、オフショア開発白書（2025年版）です。委託企業約1,000社、オフショア開発企業約200社を対象にした調査とされています。この白書の紹介ページによると、委託側がオフショア開発企業に感じる課題は、引き続き「コミュニケーション力」と「品質管理」が上位です。委託先を選ぶ段階の課題は「自社要件とのマッチング」と「初期コミュニケーション」でした。仕様書は独立した項目としては挙がっておらず、原因ごとの割合も示されていません。
VAONの見方は、コミュニケーションや品質の問題の多くは結果であり、根本には仕様の不足がある、というものです。これは調査結果ではなく、CEOが開発の現場で見てきた経験にもとづく見解です。
2. 仕様書の抜けは、オフショアのチームに渡ったあとどう現れるのか
仕様書の抜けは、最初は抜けに見えません。誰かが「このケースはどうなりますか」と聞くまで、完成した資料に見えます。
| 仕様書の抜け | エンジニアの動き | 見つかる時期 |
|---|---|---|
| 業務の例外が書かれていない（一部返金、途中解約など） | 常識的に見える処理を推測で選ぶ | 実データで受け入れテストをしたとき |
| 権限が「管理者と一般」としか書かれていない | 2つの役割だけ作り、残りは例外扱いになる | 実際の担当者が触ったとき |
| 移行する既存データの状態が書かれていない | データはきれいだと仮定する | 最初の移行テスト |
| エラー画面、データが空のときの表示、出力ファイルの形式 | ライブラリの初期設定のまま | 利用者から指摘が出たとき |
| 「現行システムと同じ」という一文 | 双方が別の意味で読む | プロジェクトの終盤 |
共通するのは、どの抜けも、その場でもっともらしい推測で埋められてしまうことです。だれも警告を出しません。費用は後から、手戻りと「それは要件に入っていたか」という議論の形で現れます。
仕事の進め方の違いも重なります。日本では、情報を受け取る側が送り手の立場に立って考え、内容を十分に解釈することが期待されるため、仕様書が簡潔に書かれることがあります。一方、海外のチームは、書かれたとおりに作る傾向があります。どちらが悪いわけでもありません。この2つの読み方のあいだにある距離が、そのまま不足している仕様です。技術的な制約が納期の直前まで伝わらない問題も同じ構造で、契約前に「やらないこと」を伝えるで扱っています。
3. 委託先の国を変える、ブリッジSEを増やすだけで解決するのか
委託先の国を変えても、ブリッジSE（BrSE、日本側とオフショア側をつなぐ技術者）を増やしても、仕様の不足は解決しません。決定が抜けた仕様書からは、どの国でも、国内の会社に頼んでも、よい結果は出ません。
ブリッジSEが解決するのは、言語と仕事の進め方の違いです。仕様が正しく伝わるようにする役割で、まだ誰も決めていないことを決める役割ではありません。業務の知識が一人のブリッジSEの頭の中にしかない場合は、その人が退職した日に、プロジェクトからその知識が消えます。VAONがこの危険をどう減らすか（初期はブリッジSEが主導し、その後は設計するエンジニアがお客様と直接話し、知識をチームと文書に残す）は、ブリッジSEに頼りきらないオフショア開発で説明しています。
4. VAONの仕様確定フェーズでは、何をするのか
仕様確定フェーズは、開発の見積りが出せる水準まで仕様を詰めるための、独立した固定価格のフェーズです。VAONは、コードを1行も書く前にこのフェーズを行います。
| 項目 | 内容 |
|---|---|
| 期間 | 1〜2週間。大きな案件は2〜4週間 |
| 価格 | 固定。事前にお伝えし、追加費用は発生しません |
| 担当 | ブリッジSEとテックリード |
| 成果物 | 要件定義書、全画面のワイヤーフレーム、データベース設計、システム構成（アーキテクチャ）、開発フェーズの固定見積り |
| フェーズ後 | ここで止めることもできます。継続は必須ではありません |
入り口は、お客様の状況に応じて2つあります。
入口A：すでにシステムがある場合。 VAONがコードを読み、運用担当の方にヒアリングし、動いているシステムを計測します。古い資料に書いてあることではなく、実際に何をしているかを把握するためです。
入口B：まだ何もない場合。 業務ヒアリングを行い、お客様と一緒に画面を描き、データを設計します。足りない決定の多くは、画面を描く段階で表に出ます。ボタンが何をするのかが分からなければ、ボタンは描けないからです。
止める自由があるかどうかが、このフェーズの価値を決めます。結果を自由に判断できなければ、意味がありません。
5. 高知工科大学のSeminar Naviでは、何を行ったのか
高知工科大学のSeminar Naviでは、VAONが要件の整理から運用まで、大学と一緒に進めました。構成はLINEアプリ（LIFF）、PWA、管理画面で、要件から運用開始まで約5週間、2026年10月1日に正式に運用を始めています。
コードを書く前に書面で決めておくべき内容の例を挙げます。学生が約1分、4つの手順で使い始められること。氏名を収集しないこと。おすすめの表示は生成AIではなく、ルールで行うこと。どれも小さな決定に聞こえますが、構築後に変えると、画面の流れ、データ、集計のすべてに手が入ります。
システムの利用状況の数字は公開していないため、ここでは触れません。
6. 仕様確定フェーズが向かない場合
仕様確定フェーズが不要なのは、作業が小さく、内容がはっきりしている場合です。画面の修正、レポートの追加、不具合の修正などでは、短い打ち合わせと見積りで足ります。
ほかにも、知っておいていただきたい限界が3つあります。
- 業務を知る方がいなければ、確定できません。 実際の業務の流れを分かっている方に、ヒアリングへ参加していただく必要があります。社内にまだいない場合は、まずその方を見つけることが先になります。
- コードから起こす仕様（入口A）には限界があります。 コードから分かるのは、システムが何をしているかであり、なぜそうなっているかではありません。すでに使われていないルール、システム外の手作業、マスターデータ、本番環境の設定、外部システムはコードに現れません。長年残っている不具合が、仕様として書かれてしまうこともあります。そのため、すべての項目を業務の担当者に確認します。
- 確定は、一切変えないという意味ではありません。 要件はこの後も変わります。違いは、変更のたびに書面の手順を通ることです。詳しくは追加費用が発生しない開発会社の見分け方にまとめています。
また、数日のうちに大人数で開発を始めたい場合は、このフェーズの分だけ開始が遅くなります。その場合、VAONが適切な委託先ではない可能性があります。
7. 契約前に、どのオフショア会社にも確認したい5つの質問
VAONに相談されない場合でも使える質問です。答えが曖昧な箇所に、リスクがあります。
- 開発の見積りを出す前に、どんな文書を作成しますか。そこで止める場合、その文書は手元に残りますか。
- 業務の例外について、どなたが、どんな方法（ヒアリング、ワイヤーフレーム、実データのサンプル）で確認しますか。
- この見積りは、どの文書にもとづいていますか。まだない場合は、どんな前提で価格を出していますか。
- 途中で要件を変えたいとき、作業が始まる前に、書面で何をいただけますか。
- 窓口の担当者が退職した場合、誰が引き継ぎ、知識はどこに残りますか。
具体的な抜けを自分の案件で確かめたい場合は、要件定義にかかる期間と費用の目安もご覧ください。AIでコードを書く開発を外注する予定でしたら、AI駆動開発を外注する前に確認する12項目もあわせてご覧ください。
8. よくあるご質問
仕様書がまったくない状態でも、相談できますか。 できます。仕様確定フェーズの入口Bにあたります。VAONが業務ヒアリングを行い、画面をご一緒に描き、データを設計します。事前の資料は不要です。実際の業務の流れを分かっている方に、打ち合わせへ参加していただければ進められます。
何年も動いているシステムで、資料が残っていない場合はどうなりますか。 入口Aにあたります。VAONがコードを読み、運用担当の方にヒアリングし、動いているシステムを計測して、現行の仕様を整理します。コードからは仕組みの理由が分からないため、すべての項目を業務の担当者に確認します。
仕様確定フェーズのあとも、VAONと続ける必要がありますか。 ありません。このフェーズの後に止めることができます。要件定義書、ワイヤーフレーム、データベース設計、システム構成、開発フェーズの固定見積りをお渡ししますので、続けるかどうかはお客様がお決めください。
仕様確定フェーズを入れると、費用は高くなりますか。 別枠の費用で、固定価格を事前にお伝えします。そのかわり、開発の見積りは前提ではなく具体的な文書にもとづきます。仕様不足による手戻りの費用との比較に使える数字は、VAONにはありません。
オフショア開発への発注を検討されていますか。 第7章の質問を、最初の打ち合わせにお持ちください。VAONの初回のご相談は60分で、CEOが同席します。事前の資料は不要で、契約を前提とするものではありません。無料相談（60分）
執筆者： ダン・ヴァン・ルアン（Đặng Văn Luân）、VAON 創業者・CEO。ハノイ工科大学HEDSPI課程卒業。FPT Software、東京のDigital Plus（5年、1,000万ユーザー規模のシステム）を経て、従業員120名のITO企業でCOOを8年務め、ISO 9001・ISO 27001に沿った管理体制を構築。業界歴15年。
参考資料
- オフショア開発白書（2025年版）、Offshore Kaihatsu：https://www.offshore-kaihatsu.com/offshore_hakusho_2025/（紹介ページ、2026年10月17日確認）
