オフショア開発の失敗はなぜ起きる？よくある原因と回避の進め方

オフショア開発の失敗はなぜ起きる？

オフショア開発の失敗は、委託先の開発力よりも、着手前に前提をそろえきれないまま開発を始めてしまうことから起こります。作るもの、今回の範囲、完了の定義が双方で同じ意味になっていないと、工程が進むほど解釈の差が広がります。

原因は発注側と開発側のどちらか一方ではありません。発注側には要件と優先順位を伝える役割があり、開発側には不明点を確認して合意を記録する役割があります。どちらかが欠けると、ずれは表に出ないまま積み上がります。

失敗の主因は「開発力」より「前提のずれ」にあることが多い

例えば、同じ「ログイン機能」でも、発注側は社内のID基盤との連携を想定し、開発側はメールアドレスとパスワードによる認証だけを想定している場合があります。言葉は同じでも、指している範囲が違うわけです。

技術力が高いチームであっても、ずれた前提のとおりに作り込めば、完成後に「こうではなかった」となり得ます。前提の確認は、開発力とは別の工程として扱うほうが安全です。

ずれは工程が進むほど大きくなる

要件定義で生じた小さな解釈違いは、設計で構造に反映され、実装でコードになり、テストで初めて見える形になります。後工程になるほど修正範囲は広がり、やり直しの工数も増えます。着手前と上流工程での確認に時間を配分するほうが、結果として全体の工数は読みやすくなります。

オフショア開発でよくある失敗パターンとは？

失敗の症状はいくつかの型に分かれます。代表的な5つを、よくある症状、引き金になりやすいこと、予防の方向性という3つの列でまとめました。

いずれも特定の国や企業に限った症状ではなく、進め方の設計で避けられるものが大半です。症状は表に出る場所が違うだけで、根にあるのは同じ前提のずれです。次に、原因を5つに分けて見ます。

失敗の原因はどこにある？よくある5つの要因

要件定義が浅いまま見積もりを取っている

機能一覧はあっても、入力項目や例外処理、業務フローの分岐まで決まっていない状態で見積もりを依頼すると、前提の異なる金額が並びます。見積もりは単価と工数の積み上げなので、単価が同じでも作業範囲が違えば総額は変わります。

非機能要件と優先順位が決まっていない

性能、可用性、セキュリティ、運用といった非機能要件は、機能一覧ほど議論されないまま進みがちです。すべてを同じ優先度で扱うと、限られた期間で何を先に仕上げるかが決まりません。Must（必須）とShould（できれば）を分けると、変更時の判断がぶれにくくなります。

窓口と意思決定の経路が曖昧になっている

現場の担当者と開発チームが直接やり取りし、決裁者が別にいる形では、合意が後から覆ることがあります。誰が最終判断をするのか、確認待ちの質問が誰に届くのかを決めておく必要があります。

品質の判定基準を共有していない

「動けば完了」なのか「業務シナリオを通せば完了」なのかで、テストの量と期間は変わります。基準が共有されていないと、発注側は不具合と捉え、開発側は仕様どおりと捉える状態が生じます。

契約形態とスコープの整合が取れていない

受託開発（請負型）で範囲を確定したのに、途中で仕様を自由に変える運用にすると、契約と実態がずれます。ラボ型開発（準委任契約）は、期間と稼働を定めたうえで作業範囲を都度合意する運用が前提です。契約形態とスコープの決め方は、組にして考えます。

要件定義のずれはどう防ぐ？

要件定義では、決めたことを後から参照できる形で残すことが効果的です。業務フロー、画面、帳票といった単位に分けて合意事項を残すと、認識の違いが見つけやすくなります。

次の順序で進めます。

1. 現状の業務フローと理想の流れを書き出し、今回の開発範囲に線を引く
2. 画面と帳票の単位で、入力項目、出力項目、例外処理を一覧にする
3. 非機能要件を箇条書きで置き、Must（必須）とShould（できれば）に分ける
4. 受け入れテストの判定基準を、要件定義の段階で文章にする
5. 仕様変更の扱い（誰が、どの時点で、どう決めるか）を着手前に取り決める

合意の単位を業務・画面・帳票に分ける

業務・画面・帳票に分けると、発注側の業務知識と開発側の設計知識を対応させやすくなります。とくに帳票は、項目の位置や有無が業務の解釈を表すため、ずれが見つけやすい領域です。

受け入れテストの基準を先に決める

受け入れテストの判定基準を要件定義で決めておくと、後工程での解釈違いを減らせます。「どの画面で、どの操作をして、何が表示されていれば合格か」という形で書いておくと、テスト工程での協議が減ります。

コミュニケーションのずれはどう防ぐ？

コミュニケーションのずれは、頻度を増やすだけでは解消しません。決定した内容が記録され、同じ情報を双方が参照できる状態をつくることが要点です。

BrSE（ブリッジSE）の役割を明確にする

BrSE（ブリッジSE）が間に入ると、言語と業務理解の両面を橋渡しできます。一方で、発注側の意図が一段変換され、窓口が増えて決定経路が見えにくくなる面もあります。BrSEが決めてよい範囲と、発注側に確認する範囲を最初に取り決めておくと、この注意点を打ち消せます。

決定事項を記録に残す

定例の打ち合わせでは、話した内容ではなく決まった内容を残します。議事録には「決定」「保留」「要確認」を分けて書き、保留と要確認には期限と担当を添えます。翻訳だけに頼らず、図や画面で認識を合わせる場も有効です。

品質のずれを防ぐQAの進め方は？

品質のずれは、テストの量ではなく役割分担の不明確さから生まれます。誰がどの工程で何を確認するのかを決め、手動テスト、自動化、アジャイルテスト、テスト駆動開発、ユーザー受け入れテストを目的別に組み合わせます。

テスト工程の役割分担を決める

開発側が単体テストと結合テストを担い、発注側が受け入れテストで業務シナリオを確認する、といった分担を工程ごとに決めます。発注側の確認が特定の工程に集中すると、そこで滞留します。

自動化の範囲を最初に切り分ける

自動化は、繰り返し実行する回帰テストから着手すると効果が読みやすくなります。画面の見た目や業務シナリオの妥当性は人の確認が必要です。すべてを自動化せず、範囲を最初に切り分けます。

当社では、ISOの取得に向けて品質・情報セキュリティのプロセスを整備している段階です。

契約形態はどう選ぶ？受託開発（請負型）とラボ型開発の違い

契約形態は、スコープの決め方と変更の扱いを左右します。受託開発（請負型）は成果物と範囲を確定して進める形態、ラボ型開発（準委任契約）は期間と稼働、体制を定めて継続的に進める形態です。

スコープが固まっている場合

業務フローと画面、帳票が固まり、変更が見込まれない場合は、受託開発（請負型）が向いています。範囲が明確であれば、見積もりの前提もそろえやすくなります。

継続的に優先順位を変える場合

仕様の追加や優先順位の変更が続く見込みがある場合は、ラボ型開発（準委任契約）が選択肢になります。範囲を都度合意する運用を省略すると、契約と実態がずれるため注意が必要です。

失敗を避けるには発注前に何を確認する？

発注前の確認は、要件の内容だけでなく、進め方と判断の仕組みまで含めて行います。以下は、社内の検討資料にそのまま使える粒度のチェックリストです。

• 要件の合意方法（誰が、どの単位で、いつ承認するか）
• 非機能要件（性能、可用性、セキュリティ、運用）の有無と優先順位
• 発注側の窓口と、最終決裁を行う人
• 品質の判定基準と、受け入れテストの合否条件
• テストの範囲と、発注側が確認する工程
• 仕様変更の扱い（判断の期限と、変更に伴う費用の考え方）
• 保守運用の範囲と、引き継ぎで受け取る成果物
• 見積もりの前提（単価、工数、前提条件、含まれない作業）

海外拠点の制度や投資環境は、ジェトロ（日本貿易振興機構）の国・地域情報も参考になります。

提案と見積もりの前提をそろえて比較する

複数社を比較するときは、同じ要件定義書と同じ質問票を渡し、前提条件をそろえて見積もりを依頼します。金額の差だけでなく、前提条件の書き方の差を読むと、どの工程を軽く見ているかが見えます。前提が書かれていない見積もりは、比較しにくくなります。

まとめ

オフショア開発の失敗は、開発力の不足よりも、着手前の前提共有の不足から起こります。要件定義、コミュニケーション、品質基準、契約形態の4点を着手前に整えておくと、ずれは小さいうちに見つけられます。

要件は業務・画面・帳票の単位で合意し、受け入れテストの判定基準を先に決める。窓口と決裁者を明示し、決定事項を記録に残す。テストの役割分担を工程ごとに決め、契約形態とスコープの決め方を組にして考える。どれも特別な手法ではなく、進め方の設計です。

当社は2020年7月にベトナム・ハノイで設立し、日本企業向けのソフトウェア開発とDX支援に取り組んでいます。自社の場合にどこを確認すべきか整理したい場合は、お問い合わせからご相談ください。