オフショア開発の品質は低い？管理体制で決まる

01はじめに｜この記事でわかること

要点：この記事では、オフショア開発の品質が下がる本当の場所と、それを止める管理体制の中身を整理します。はじめてご検討中でしたら、まずオフショア開発の基本を押さえてからお読みください。

「オフショア開発は品質が心配で」。ご相談の入り口で、いちばん多くいただくお言葉です。

ただ、心配の中身は会社によってちがいます。バグが多いのではという方もいれば、別のものが出てくるのが怖いという方もいます。この2つは、原因も対策も別ものです。

そこでこの記事では、2000年創業のWeb制作・システム開発会社ZenWeb Japanが、実際の案件で品質をどう作っているかをご説明します。読み終えるころには、委託先に何を求めればよいかが言えるようになります。

次の動画では、そもそもソフトウェアの品質とは何を指すのかが、短くまとまっています。あわせてご覧ください。

02「品質が低い」と言われるとき、何が起きているのか

要点：「品質が低い」という言葉の中身は、動かないバグより「頼んだものとちがう」が多数です。つまり多くは技術力の問題ではなく、伝え方と確認の仕組みの問題です。詳しくはオフショア開発の失敗例でも触れています。

「これは品質が低い」とおっしゃるとき、指さされているものは、だいたい次の3つです。

• 頼んだものとちがう。画面の作りや業務の流れが、想像していたものと合っていない。
• 決めていなかったところが、勝手に埋まっている。指示していない部分を、開発側の解釈で作られている。
• 動かない。ボタンを押しても反応しない、エラーが出る。いわゆるバグ。

3つ目だけが、いわゆる技術の話です。1つ目と2つ目は、仕様が言葉になっていなかったことが原因で起きます。

そして現場で多いのは、1つ目と2つ目です。技術の問題だと誤解したまま委託先を替えても、同じことが繰り返されます。国別のちがいを調べる前に、まず自社の伝え方を疑ってみてください。

03品質は買うものではなく、決めるもの

要点：品質とは「完成と呼べる条件」のことです。その条件を発注側が書いていなければ、どの国のどの会社に依頼しても、出てくるものは開発側の解釈になります。オフショア開発で最初に整えるのは、体制よりも先にこの条件です。

多くの記事は「品質の高い会社を選びましょう」と書いています。ただ、その考え方だと、品質は商品棚に並んでいて、お金を出せば良いものが買えることになります。実際はちがいます。

ソフトウェアの品質は、決めた条件を満たしているかで測ります。条件がなければ測れませんし、測れないものは上げようもありません。

たとえば「検索が遅い」という指摘。何秒なら合格かを決めていなければ、これは指摘ではなく感想です。開発側は直しようがありません。

なお、この「条件を書く」作業は、そのまま要件定義の一部です。国内開発でも同じように必要なもので、距離があるぶん曖昧さのツケが大きく出るというだけです。

04発注側の指摘は、どこに集まっているのか

要点：ZenWeb Japanの案件で発注側からいただいた品質の指摘を分類すると、純粋な不具合は全体の2割弱でした。残りは仕様の解釈と、決めていなかった部分の埋め方に関するものです。Webシステム開発でも同じ傾向が出ています。

下の表は、受け入れ確認でいただいた指摘を内容ごとに分けたものです。

上の2行、あわせて57%。ここが本丸です。どちらも「書いていなかったから、こうなった」という種類のものです。

逆に言えば、条件を先に書くだけで指摘の半分以上は起きません。テスト工程を増やすより先に効果的です。

05発注側が先に決めておく3つの品質基準

要点：決めておくのは「動きの合格ライン」「速さの合格ライン」「見た目の合格ライン」の3つです。この3つを文章にしておけば、受け入れ確認が感想ではなく判定になります。RFPの書き方にも同じ考え方を入れています。

難しいことは要りません。次の3つをA4で1枚に書くだけです。

1. 動きの合格ライン。どの操作をしたら、どうなれば正解か。異常な入力をしたときにどうなるかも書きます。
2. 速さの合格ライン。「一覧の表示は3秒以内」のように、秒数で書きます。何件のデータで測るかもあわせて書きます。
3. 見た目の合格ライン。参考にするデザイン、対応するブラウザと画面幅、文字の表記ルール。

3つ目は軽く見られがちですが、指摘の18%はここから出ています。「スマートフォンは幅375ピクセルで確認する」と一行あるだけで、やり取りが一往復減ります。

書式に迷われる場合は、IPA（情報処理推進機構）が公開している情報システム・モデル取引・契約書（第二版）が参考になります。検収や瑕疵をどの粒度で書面にするかの目安が示されています。

06見つかるのが遅いほど、直す手間は重くなる

要点：同じ1つのズレでも、要件定義中に気づけば数十分で済み、公開後に気づけば数日仕事になります。品質管理とは、この差を前倒しで回収する活動です。費用感はシステム開発の費用相場もご参照ください。

下の表は、同じズレが「いつ見つかったか」で直す手間がどう変わるかを整理した参考値です。実装中を1として比べています。

注目したいのは受け入れテスト中の「4〜6」です。多くの案件で指摘が集中するのは、まさにこの時期です。

だからこそ確認は前倒しします。画面が1つできた時点で見る。まとめて最後に見るやり方が、いちばん高くつきます。

07管理体制の中身｜レビュー・テスト・報告の3層

要点：品質を支える体制は、作ったものを別の人が見るレビュー、作った人以外がやるテスト、そして毎週同じ形で届く報告の3層です。窓口となるブリッジSEがいても、この3層がなければ品質は安定しません。

「品質管理をしています」と説明されたら、次の3つに分けて聞いてみてください。

• レビュー。設計書とコードを、書いた本人以外が読む工程です。誰が、いつ、何を見るのかを確認します。
• テスト。単体・結合・システムテストの担当が誰か。開発チームと独立したQA担当がいるかどうかで、見つかる不具合の量が変わります。
• 報告。毎週、同じ様式で届くかどうか。様式が毎回ちがう報告は、比べられないので意味を持ちません。

この3つで見落とされやすいのが報告です。「順調です」の一言だけが2週続いたら、体制を疑う合図だとお考えください。

逆に様式さえ決まっていれば、遠くのチームでも状況は読めます。時差や距離そのものが品質を下げるわけではありません。ラボ型開発で長く組む場合は、この報告の型を最初に作っておくと後が楽になります。

08管理体制の4段階｜どこまで整っているかで結果が変わる

要点：管理体制は、丸投げから独立QAつきまで4段階に分けて考えられます。上の段階ほど、発注側の作業は増えるのに手直しは減ります。会社ごとの差はオフショア開発会社の選び方で整理した6項目からも読み取れます。

下の表は、体制の段階ごとに現場で何が起きるかをまとめたものです。ご自身の案件を当てはめながらご覧ください。

ただし④が常に正解ではありません。独立QAを置けば費用は上がります。社内用の小さな管理画面に、そこまでの体制は要りません。

一方で、②で止まっている案件が多いのも事実です。窓口を置いて安心し、条件書を渡していない。指摘の57%が仕様のズレなのは、ここが理由です。

09契約と検収に、品質をどう書き込むか

要点：契約書に書くべきは「検収の基準」「直しの範囲と期限」「担当交代時の引き継ぎ」の3点です。ここが空白だと、品質の議論はすべて力関係で決まります。見積りの読み方はシステム開発の見積もりの見方で解説しています。

品質の話は、最後は契約の話になります。書いていないことは請求できないからです。

• 検収の基準。何をもって合格とするか。第5章の3つの合格ラインを、そのまま添付資料にするのがいちばん確実です。
• 直しの範囲と期限。納品後、どの範囲の不具合を、いつまで無償で直してもらえるか。日数で書きます。
• 担当交代時の引き継ぎ。開発メンバーが替わるときの通知期限と、引き継ぎ期間の重なりを決めておきます。

3つ目は忘れられがちですが、品質に直結します。人が替わった直後に不具合が増えるのは、どの会社でも起きることだからです。

外に出すか社内でやるかを迷っている段階でしたら、外注と内製の判断基準を先にご覧ください。品質を管理する人が社内にいるかが、そのまま判断材料になります。

10経過月別｜品質のサインはいつ出るか

要点：品質の危うさは、納品時ではなく開始1か月目から表に出ています。質問の量、報告の粒度、直しの速さ。この3つを毎週見ていれば、崩れる前に手を打てます。進め方の全体像はオフショア開発サービスでもご説明しています。

下の表は、どんなサインがいつ出るかを月ごとに整理したものです。

1か月目の「質問が来ない」は、いちばん危ういサインです。順調なのではなく、わからないところを自分で埋めているだけ、という場合が多いからです。

質問が多いチームは面倒に見えます。でも、その面倒を1か月目に払うか、受け入れテストで4〜6倍にして払うかのちがいです。

11品質を落としてしまう、発注側の3つのクセ

要点：「あとで決めます」「いい感じにしてください」「まとめて確認します」。この3つの口ぐせが、品質をいちばん確実に下げます。どれも国内開発なら通っていた言い方です。詳しくは失敗しやすいパターンもあわせてご覧ください。

1. 「あとで決めます」。決まっていない箇所は、開発が進めば誰かが埋めます。埋めるのは、たいてい開発側です。
2. 「いい感じにしてください」。日本語圏では通じることもありますが、翻訳を挟むと何の情報も残りません。
3. 「まとめて確認します」。第6章のとおり、確認を後ろに寄せるほど手間は重くなります。

この3つが出やすいのは、社内に判断できる方がいないときです。担当者が現場を兼務していて、確認の時間がとれない。よくあるご事情です。

IPA（情報処理推進機構）のDX動向2026でも、DXを進める人材の過不足は主要な調査項目として扱われています。人が足りない前提で体制を組む発想が、ここでも要ります。

12品質を確かめる5つの手順

要点：条件書を1枚書き、レビューとテストの担当を分け、週に見る数字を3つ決め、受け入れ項目を先に渡し、直し方を契約に入れる。この5手順で、体制は②から③に上がります。委託先探しは会社の選び方とあわせてお進めください。

着手される際の順番です。上からお進めください。

1. 完成の条件をA4で1枚書く。動き・速さ・見た目の3つの合格ラインを書きます。完璧でなくて構いません。
2. レビューとテストの担当を分ける。書いた本人が確認する体制になっていないか、委託先に確認します。
3. 毎週見る数字を3つ決める。未解決の指摘件数、直しの平均日数、新しく出た不具合の数。この3つで十分です。
4. 受け入れテストの項目を先に渡す。最後に出すのではなく、着手前に共有します。答えを見せてから作ってもらう形です。
5. 直し方のルールを契約に入れる。無償で直す範囲と期限、判断が割れたときの決め方を書面にします。

4番目に抵抗を感じる方もいます。ただ、テストで落とすことが目的ではありません。落ちないものを作ってもらうのが目的です。

13まとめ｜品質は体制と契約で作れます

要点：オフショア開発の品質は、国や単価ではなく、合格の条件とレビュー・テスト・報告の体制で決まります。まずはA4で1枚、完成の条件を書くところから始めてください。オフショア開発のご相談は随時承っています。

ここまでご説明したとおり、「オフショアだから品質が低い」は実態と合っていません。指摘の57%は仕様の書き漏れで、国内開発でも同じように起きるものです。

変わるのは、曖昧さのツケの大きさだけです。距離と言語があるぶん、書いていないことは別の形で返ってきます。

逆に、書いてさえあれば結果は安定します。ZenWeb Japanは日本人窓口とベトナムの開発チームの体制で、条件書づくりから受け入れ確認までをご一緒しています。費用は案件ごとのお見積りです。

14よくある質問

要点：品質のご相談でよくいただく質問をまとめました。国内開発との差、基準の細かさ、テストの分担など、判断に直結するところを中心に整理しています。国ごとの傾向はオフショア開発の国別比較でも扱っています。

1. オフショア開発は国内開発より品質が落ちますか

体制が同じなら、大きくは変わりません。差が出るのは、曖昧な指示が通用しない点です。国内で「察してもらえた」部分が指摘として表面化します。落ちているのではなく、隠れていたものが見えている状態です。

2. 品質基準はどこまで細かく書けばよいですか

最初はA4で1枚、主要な画面だけで構いません。全機能を網羅しようとすると、いつまでも着手できません。よく使う3画面の合格ラインから始めてください。

3. テストは発注側でもやるべきですか

受け入れテストは発注側でお願いします。実際の業務を知っているのは発注側だけだからです。単体テストや結合テストまで担う必要はありません。

4. 品質が悪いとき、契約でどこまで求められますか

検収基準に書かれている範囲までです。書いていない事項は、交渉で決めることになります。だからこそ、合格の条件を契約の添付資料にしておくことをおすすめしています。

5. 小さい案件でも品質管理の体制は要りますか

独立したQA担当までは不要です。ただし、完成の条件を書くことと、週次で実物を触ることの2つは、規模を問わず行ってください。これだけで指摘の半分以上は防げます。