オフショア開発の失敗は、たいてい開発が始まる前に決まっています。進行中に表面化するだけで、原因はもっと手前にあります。
失敗事例を集めた記事はたくさんあります。ただ、その多くは原因を「コミュニケーション不足」や「文化の違い」で片づけています。これでは対策になりません。言語も時差も、発注前からわかっていたはずだからです。
この記事では、原因を発注側が動かせる変数として整理します。外注先の問題にするのではなく、自社で先に用意できるものに目を向けます。
失敗の多くは開発が始まる前に決まっている
問題が見えるのは開発の後半です。納期が近づき、動くものを確認した段階で、認識のずれが表に出ます。
しかし、そのずれが生まれたのはもっと前です。仕様を決める人が決まっていません。完成の定義も共有されていません。質問に答える体制もありません。こうした状態で開発に入ると、現場の努力では取り返せません。
だからこそ、発注前と契約時に決めておく項目を増やすほど、進行中の判断は軽くなります。以下では、よくある5つの原因を順に見ていきます。
原因1：仕様を決める人が決まっていない
最も多い原因です。質問を送っても、誰が答えるのかが決まっていません。関係部署に確認します、という返事が続き、回答が1週間後になります。
開発側はその間、止まるか、推測で進めるかを選ぶことになります。どちらを選んでも損失が出ます。止まれば日程が遅れ、推測で進めれば手戻りになります。
具体的な例を挙げます。ある画面に表示する項目について、営業部と管理部の意見が割れたとします。この調整が2週間かかれば、その画面の開発は2週間止まります。開発側には、待つ以外の選択肢がありません。
対策は単純です。仕様を決める担当者を1人決め、その人に決裁の権限を持たせます。あわせて、回答の期限を社内で合意しておきます。
ここで注意したいのは、担当者の忙しさです。週に2時間しか時間を取れない担当者であれば、開発もその速度に合わせることになります。体制を組む前に、自社が割ける時間を見積もってください。
原因2：受け入れ基準が文書になっていない
「完成したら連絡してください」という依頼は、実は何も指示していません。完成の定義が人によって違うからです。
開発側は、仕様書に書かれた動作を実装すれば完成と考えます。発注側は、実際の業務で使える状態を完成と考えます。この差は、検収の段階で一気に噴き出します。
対策は、受け入れ基準を先に文書にすることです。次の3点を書いておくと、認識がそろいます。
- どの操作が、どういう結果になれば合格か
- 異常な入力をしたとき、どう振る舞うべきか
- どの端末とブラウザで動作すればよいか
この文書は、長くする必要はありません。主要な機能について1画面あたり数行で十分です。重要なのは、開発を始める前に存在していることです。
あわせて、業務で使う実際のデータを想定しておきます。試験用の短い名前では動いても、実務で使う長い名称や特殊な記号で表示が崩れることがあります。これは設計の段階で防げる問題です。
原因3：質問が滞留する
時差が2時間でも、回答に3日かかれば実質的な距離は大きくなります。逆に、時差が大きくても翌営業日に回答が返れば、開発は止まりません。
問題は時差ではなく、滞留です。質問がメールに埋もれます。担当者が不在で止まります。誰が答えるべきかわからなくなります。こうした状態が積み重なります。
対策は、質問の置き場所と回答の期限を決めることです。やり取りの場所を1つに絞り、そこに来た質問は翌営業日までに返す、と決めます。即答できない質問でも、いつ答えるかを返せば開発は進みます。
もうひとつ有効なのは、質問の形式をそろえることです。背景と選択肢を添えて聞いてもらえば、発注側は選ぶだけで済みます。自由記述の質問は、答えるのに時間がかかります。
MOHAでは、日本法人が窓口となり、ブリッジSEとPMが質問の流れを管理します。指揮命令はMOHA側のPMとブリッジSEを通じて行います。
原因4：契約形態と進め方が合っていない
仕様が固まっていないのに請負契約を結ぶと、無理が出ます。請負は成果物の完成を約束する契約だからです。仕様が変わるたびに、金額と期間の交渉が発生します。
交渉が面倒になると、現場は仕様変更を言い出さなくなります。その結果、使いにくいとわかっている機能がそのまま作られます。これは契約の設計が招いた失敗です。
逆に、仕様が固まっているのに準委任で進めると、管理の手間が増えます。発注側が優先順位を決め続ける必要があるためです。
対策は、案件の性質に合わせて使い分けることです。詳しくはオフショア開発の契約で整理しています。仕様が動く前提なら、ラボ型開発のような継続的な体制が向きます。
フェーズごとに切り替える方法もあります。要件を固める段階は準委任で進め、仕様が確定してから請負に移る形です。最初にすべてを決めきれない案件では、現実的な選択になります。
原因5：品質を測る仕組みがない
終盤まで品質の状態がわからない案件は、終盤で崩れます。報告書には順調と書かれていても、実際に動かすと別の姿が見えます。
対策は、早い段階から動くものを確認することです。次の3つを決めておきます。
ひとつめは、確認の頻度です。2週間に一度は、実際に触れる状態のものを見ます。
ふたつめは、確認する人です。開発の担当者だけでなく、実際に業務で使う人が触ります。現場の担当者が触ると、仕様では気づかなかった問題が出てきます。
みっつめは、不具合の扱いです。見つかった不具合をどこに記録し、どの順番で直すかを決めます。記録の場所が分散すると、直したはずの不具合が再発します。
失敗が表に出やすい4つの場面
実際の案件では、次の場面で問題が表面化します。いずれも、事前に手を打てる場面です。
最初の画面を確認したとき。 想像していたものと違う、という反応が出ます。ここで方向を修正できれば損失は小さく済みます。確認を先送りするほど、修正の範囲は広がります。
既存システムとつないだとき。 単体では動いていた機能が、つないだ途端に動かなくなります。データの形式や項目の長さが想定と違うためです。連携の確認は、できるだけ前倒しします。
実際のデータを入れたとき。 件数が増えると表示が遅くなる、想定外の文字で処理が止まる、といった問題が出ます。本番に近いデータで早めに試すことが有効です。
現場の担当者が初めて触ったとき。 仕様としては正しくても、実際の業務の流れに合わないことがあります。画面の行き来が多い、よく使う操作が深い階層にある、といった指摘はこの段階で出ます。設計の途中で現場に見てもらうと、この種の手戻りは減ります。
よくある誤解
失敗の原因について、いくつか誤解があります。整理しておきます。
誤解1：安く発注したから失敗した
費用の水準と失敗の有無に、直接の関係はありません。問題になるのは、安さの理由が範囲の削減にある場合です。テストや要件定義が省かれていれば、その分は後から必要になります。見積もりの前提を読むことで、ほとんどは事前に判別できます。
誤解2：規模の大きい会社なら安心
規模は体制の安定につながりますが、案件ごとの担当者の質まで保証するものではありません。確認したいのは、自社の案件に誰が関わるかです。体制の説明を受けておくと、進め方の認識もそろいます。
誤解3：日本語が通じれば十分
日本語でやり取りできることは前提条件であって、十分条件ではありません。日本語が通じても、決める人がいなければ案件は進みません。言葉の問題と、意思決定の問題は分けて考えます。
言語と時差は本当の原因か
ここまで触れてきませんでしたが、言語と時差についても整理しておきます。
これらは条件であって、原因ではありません。日本とベトナムの時差は2時間です。日本の営業時間内にやり取りができます。日本語で対応できる体制を組めるかどうかが実際の論点であり、距離そのものではありません。
同じことは国内の開発にも言えます。同じ言語と同じ時間帯で進めていても、仕様を決める人がいなければ案件は止まります。オフショアで起きる失敗の多くは、国内でも起きる失敗です。条件が厳しいぶん、表面化が早いだけです。
なお、国内のIT人材の不足は続いており、経済産業省はデジタル人材の育成を政策として進めています。国内外の動向は、IPAのDX白書でも整理されています。体制づくりの前提として、押さえておきたい背景です。
発注側が用意するもの
ここまでの対策をまとめます。開発を始める前に、次のものを用意してください。
いずれも、特別な準備ではありません。担当者を決め、完成の定義を書き、回答の期限を決める。この3つだけでも、進行中の負担は大きく変わります。
逆に言えば、これらがないまま始めると、どの会社に依頼しても同じ問題が起きます。確認の観点はオフショア開発の契約チェックリストにもまとめています。
発注前に確認しておきたい項目
社内で先に確認しておく項目を挙げます。すべてが埋まっていなくても構いません。埋まっていない箇所が、議論すべき論点になります。
- この開発で、何を改善したいのか
- 仕様を決める担当者は誰か
- その担当者が割ける時間は、週にどれくらいか
- 完成の判断は、誰がどの基準で行うのか
- 現在の業務の手順を、どこまで変えてよいか
- 既存システムの資料は、どこまでそろっているか
- 公開した後、誰が運用するのか
この7項目が埋まっていれば、最初の打ち合わせから具体的な話ができます。
進行中の案件で立て直すには
すでに始まっている案件で問題が出ている場合も、打てる手はあります。
まず、認識のずれを可視化します。現在できているものを実際に動かし、期待との差を一覧にします。感覚で議論すると平行線になるため、画面単位で具体化します。
次に、優先順位を決め直します。すべてを直すのではなく、業務が回る最小限を先に確定させます。
そして、残りの期間の進め方を合意します。確認の頻度を上げ、小さい単位で見ていく形に切り替えます。
この3つは、契約を変えなくても始められます。立て直しの初期に必要なのは、新しい契約ではなく、現状の正確な把握です。
よくあるご質問
小さい案件でも同じ問題は起きますか。
起きます。規模が小さいほど担当者が兼務になりやすく、回答が遅れる傾向があります。
途中で開発会社を変えると解決しますか。
原因が発注側の体制にある場合、変えても同じ問題が再発します。まず原因を切り分けることをおすすめします。
仕様書がない状態でも相談できますか。
できます。やりたいことを整理する段階からご相談いただけます。
日本語でのやり取りは可能ですか。
可能です。契約と請求、窓口は日本法人が担当します。
社内にIT担当者がいなくても進められますか。
進められます。ただし、業務を判断できる方の関与は必要です。技術の知識よりも、業務の決裁ができることが重要になります。
開発中の状況は、どの程度見えますか。
確認の頻度と方法を、開始前に決めておきます。実際に動くものを定期的にご確認いただく形が基本です。
小さく始めて、様子を見ながら広げられますか。
できます。範囲を絞って進め、動くものを確認してから次に進む形はよく選ばれます。判断の材料が早く手に入ります。
既存システムの資料が残っていない場合はどうなりますか。
調査から始めます。現行の動作を確認し、必要な範囲を整理したうえで進め方をご提案します。
ベトナムの祝日は、日程にどう影響しますか。
長期の休暇がある時期は、事前に共有します。日程を引くときに、その期間を見込んでおきます。
開発の途中で体制の規模を変えられますか。
準委任の形であれば調整できます。変更の申し出から反映までにかかる期間を、事前に決めておきます。
MOHAにご質問いただきたいこと
- 自社の体制で、どの進め方が合っていますか
- 仕様が固まっていない段階では、どう始めますか
- 質問の回答体制は、どのように運用していますか
- 品質の状態は、どの頻度で確認できますか
- 進行中の案件の立て直しも相談できますか
MOHAは、ベトナムのオフショア開発センターで開発を行い、日本法人が契約と窓口を担当します。これまでに36件の事例を公開しています。
体制づくりの段階からご相談いただけます。お問い合わせフォームからご連絡ください。
