オフショア開発の品質は、ベンダーに任せて祈るものではありません。発注側が仕組みとして確認できます。
この記事では、品質が落ちる場所を3つに整理し、定例会でそのまま使える5つの数字を示します。根拠は経済産業省とIPA（情報処理推進機構）が公開している資料です。「コミュニケーションを密に」という助言はここには書きません。
MOHAはハノイに開発拠点を持ち、日本法人が契約と窓口を担当しています。自社の進め方も最後にまとめます。
品質が落ちる場所は3つに絞れます
オフショア開発の品質問題は、散らばって起きているように見えて、実際は3か所に集中します。
上流：仕様の解釈がずれます
不具合の多くは、コーディングではなく仕様の読み違いから生まれます。日本語の仕様書は「書かなくても分かる」前提で書かれがちです。海外の開発チームはその前提を共有していません。
ここで効くのは、仕様書を厚くすることではありません。解釈が分かれた箇所を記録して、次の仕様書に反映する流れを作ることです。同じ種類のずれが2回起きたら、書き方の問題だと考えます。
中流：レビューとテストの密度が見えません
開発が進んでいる間、発注側に届くのは進捗率だけという現場が少なくありません。進捗率は作業量の報告であって、品質の報告ではありません。
90%まで進んだと報告された機能が、実はテストをほとんど通していない、という事態はここで起きます。密度の数字を毎週見ていれば、この状態は数週間前に見えます。
下流：受け入れ基準が曖昧です
受け入れテストの段階で「思っていたものと違う」と言う状況は、基準を先に決めていなかった結果です。この段階での手戻りは、上流で直す場合の何倍もの工数になります。
「経験と勘」から数字へ
品質管理を定性的な助言から切り離す考え方は、公的機関がすでに示しています。
IPAは「ソフトウェア開発分析データ集」の説明で、次のように述べています。「技術者の経験と勘に頼った方法ではなく、実際のプロジェクトデータに基づいた開発プロセスの改善を行う定量的なプロジェクト管理が必要です」。IPAは2005年から開発データを収集し、ソフトウェア開発分析データ集として5,546プロジェクトの定量データを分析・公開してきました。事業終了に伴い、2022年版が最終版です。
経済産業省も同じ方向を示しています。産業構造・市場取引の可視化のページには、次の一文があります。「ソフトウェアメトリクスによる定量的マネジメントは、ソフトウェア開発プロジェクトでの品質管理をはじめとした各種マネジメントの鍵として認識されています」。同省は「定量的マネジメントのための公開データ利用ガイド」を公開しており、発注者と受注者それぞれの公開データ利用方法をまとめた資料も含まれます。
つまり、発注側が数字を求めることは、過剰な管理ではありません。国内で推奨されている進め方です。
定例会で見る5つの数字
毎週の定例会で、進捗率に加えて次の5つを出してもらいます。どれも開発チームがすでに持っているか、少しの手間で出せる数字です。
レビュー指摘密度は、レビューで見つかった指摘の数を規模で割った値です。極端に低い場合、レビューが形式的になっている可能性があります。
テスト密度は、テストケース数を規模で割った値です。工程や機能の重要度に対して薄い箇所が見えます。
不具合密度は、検出した不具合の数を規模で割った値です。レビュー指摘密度と合わせて見ると、どの工程で品質を作り込めているかが分かります。
工程別の工数比率は、設計・実装・テストに実際どれだけ時間を使ったかです。テスト工程が計画より大幅に短い場合、品質は後工程に先送りされています。
未解決不具合の滞留日数は、見つかった不具合が何日放置されているかです。総数より滞留のほうが、チームの処理能力を正直に示します。
大切なのは絶対値ではありません。推移と、変化の理由をチームが説明できるかどうかです。数字が動いたときに「なぜそうなったか」が即答できるチームは、自分たちの状態を把握しています。即答できないチームは、数字を集めているだけです。
数字が出てこないときの進め方
初回の依頼で全部そろうことは、まずありません。それ自体は問題ではありません。
まず1つだけ選びます。未解決不具合の滞留日数が最も始めやすい指標です。課題管理ツールの記録からそのまま出せるため、新しい計測を追加せずに済みます。
2週間続けてから、2つ目を足します。いきなり5つ求めると、報告のための作業が増え、肝心の開発が遅れます。指標は、見て行動を変えるためのものです。集めること自体が目的になった時点で、形骸化します。
どうしても出せないという回答が返る場合、理由を聞きます。計測していないのか、ツールが対応していないのか、工数がないのか。理由によって、こちらの打ち手が変わります。
受け入れ基準は非機能から先に決めます
機能要件は仕様書に書かれます。問題になるのは、書かれない非機能要件のほうです。応答時間、同時接続数、稼働率といった性能面の条件があります。さらに、バックアップの方式や障害からの復旧時間も決めておく必要があります。これらを受け入れテストの直前に持ち出すと、追加費用と納期の遅れに直結します。
経済産業省は、ユーザー企業とベンダー企業が合意する非機能要求項目のリストを「非機能要求グレード」として整理し、平成21年5月に報告書を公表しています。項目の抜けを防ぐチェックリストとして、開発開始前に目を通す価値があります。同じページには情報システム・モデル取引・契約書も掲載されています。
受け入れ基準は、開発が始まる前に文書にします。後から足すものではありません。
ブリッジSEは品質の担当者ではありません
ブリッジSEを置けば品質が安定する、という理解は半分だけ正しいです。
ブリッジSEは翻訳者ではなく、日本側の意図を設計に変換する役割です。優秀なブリッジSEは上流のずれを減らします。ただし、レビューの仕組みとテストの設計がなければ、1人の力量で品質を支える構造になります。その構造は、その人が異動した瞬間に崩れます。
ラボ型開発では、指揮命令はMOHA側のPMとブリッジSEを通じて行います。発注側が個々のエンジニアへ直接指示を出す形にはしません。契約の形と実態を一致させるための線引きです。
契約形態で責任の範囲が変わります
同じ「品質」という言葉でも、契約によって誰が何を負うかが変わります。
請負契約では、受注者が完成責任を負い、契約不適合責任も生じます。成果物の品質に対する責任は受注者側にあります。
準委任契約、いわゆるラボ型開発では、受注者が負うのは善管注意義務です。成果物の完成責任は負いません。そのぶん仕様変更に柔軟に対応できます。品質を担保する仕組みは、発注側と受注側の共同作業になります。
どちらが良いという話ではありません。仕様が固まっていない段階で請負を選ぶと、変更のたびに契約変更が必要になります。逆に、仕様が確定しているのに準委任を選ぶと、完成の責任があいまいになります。
契約条項の詳細は、オフショア開発の契約と失敗を避けるためのチェックリストにまとめています。
発注側がすると品質が上がる4つのこと
ここまでを、発注側の行動に落とします。
受け入れ基準を開発開始前に文書化します。非機能要求グレードの項目を出発点にします。
定例会で5つの数字を見ます。値そのものより、推移と説明を聞きます。
仕様変更の窓口を1本にします。複数の担当者から別々の指示が届く状態は、品質が崩れる最短の経路です。
ドキュメントを成果物の定義に含めます。設計の根拠が文書に残っていれば、担当者が代わっても品質は落ちません。
工程ごとに発注側が確認する項目
指標は全体の健康状態を示します。工程ごとの確認は、別に用意します。
要件定義では、用語集があるかを見ます。同じ言葉を両者が同じ意味で使えているかどうかが、後のずれを決めます。あわせて、決まっていない事項の一覧と、いつまでに誰が決めるかを確認します。
設計では、画面や帳票の一覧と、データの持ち方を確認します。細部まで読む必要はありません。自社の業務にとって重要な3つか4つの箇所だけ、深く見ます。
実装では、コードそのものより、レビューの記録を見ます。誰が、いつ、何を指摘したか。記録が残っていないレビューは、行われていないのと同じ扱いになります。
テストでは、テストケースの一覧と、実行結果の推移を見ます。ここで初めて不具合が大量に出る場合、上流の工程に原因があります。
4つの工程すべてに同じ時間をかける必要はありません。要件定義と設計に重みを置くと、後の手戻りが減ります。
MOHAの進め方
契約と請求、日々の窓口は日本法人（横浜市西区みなとみらい）が担当します。開発はハノイのチームが行い、日本との時差は2時間です。日本の営業時間内に、その日のうちに確認が取れます。
上流の抜け漏れには、自社で開発したAIツールを工程に組み込んで対応しています。SpecLensは要件定義書を分析します。Design Checklistは設計チェックリストとテストケースを自動生成します。人の読み落としを前提に、仕組みで二重に見る設計です。
PMP資格を持つプロジェクトマネージャーが在籍し、ベトナムソフトウェア・ITサービス協会（VINASA）に加盟しています。これまでの進め方は導入事例でご覧いただけます。
体制の選び方は、ベトナムオフショア開発（ODC）とシステム受託開発のページにまとめています。
ご相談ください
品質管理の進め方は、システムの性質と現在の体制によって変わります。どの指標を定例会で見るべきか、受け入れ基準に何を入れるべきかは、案件ごとにご提案します。
現在お困りの点をお聞かせください。お問い合わせ・ご相談からご連絡いただけます。
