オフショア開発にPMOは必要か？品質・進捗・コミュニケーションの3大課題を解決

「順調です」という報告を信じていたら、納品直前に大量の手戻りが発覚した——オフショア開発でこの経験をした発注側の担当者は少なくないはずです。単価メリットに惹かれて海外チームに開発を出したものの、品質は安定しない、進捗の実態は見えない、そもそも仕様が正しく伝わっているのかすら不安。そんな状態で「PMOを置けば解決するのか」と調べているのだと思います。先に結論を言うと、必要なのはPMOという肩書きの人ではなく、認識のズレを構造的に潰す仕組みです。そして、その仕組みを設計して回し続ける専任機能に名前をつけると、PMOになる。この記事では、受注側・発注側の両方でプロジェクトに関わってきた僕の視点から、オフショア開発の3大課題の正体と、機能するPMO・ブリッジ体制の設計、外部活用の判断基準までを整理します。

オフショア開発で起きるトラブルは無数にあるように見えます。ただ、一つひとつ分解していくと、ほとんどが品質・進捗・コミュニケーションの3つに分類できる。そして後述しますが、この3つの根っこは実は1つです。

品質——「動くけど、想定と違う」が量産される

テスト済みとして納品されたのに、触ってみると想定と違う。バグというより、解釈違い。仕様書に書かれていない「行間」が、国内開発なら暗黙のうちに埋まるのに、オフショアでは埋まりません。つまり品質問題の正体は、コーディングの巧拙ではなく仕様の伝わり方であることが多いんです。開発プロジェクトの7割は上流で決まるというのが僕の持論ですが、行間を口頭で補いにくいオフショアでは、この比率はさらに上がると考えたほうがいい。曖昧な仕様は、曖昧なまま実装されて返ってくる。

進捗——「順調です」の中身が見えない

時差と距離があるぶん、進捗の確認はどうしても報告ベースになります。数字の上では8割完了、でも動くものを見せてもらうと肝心の機能が入っていない。ここで注意したいのは、遅延は症状であって、本当の問題はスコープや仕様の認識がずれていることが多い、という点です。「遅れている」ことを詰めても、ズレたものが速く出来上がるだけ。進捗管理の帳票を増やす前に、そもそも何を作っているかの認識を合わせる仕組みが要ります。

コミュニケーション——「伝えたつもり」が数週間後に発覚する

言語の壁、時差、文化の違い。オフショア特有の課題に見えますが、僕はこれを「国内でも起きている問題の増幅」だと捉えています。日本語同士のチームでも、APIで何を渡して何を返すかの定義が曖昧なまま画面チームとAPIチームがそれぞれ開発を進め、結合の段階で初めて繋がらないことに気づく——そんな現場は珍しくありません。オフショアは、この認識のズレが起きる確率と、発覚までの時間を増幅する装置なんです。品質も進捗も、たどっていくと認識のズレに行き着く。3大課題は独立した3つの問題ではなく、同じ原因から出た3つの症状だと捉えたほうが、対策を設計しやすくなります。

必要性を判断するために、まず前提を一つ共有させてください。コーディング作業そのものは、開発労力全体の30%前後にすぎません。オフショアに出せるのは主にこの部分——コーディングと単体テスト——で、残りの70%にあたる要件定義、仕様化、質疑応答、受入検証、意思決定は発注側に残ります。つまりオフショア開発は「開発を丸ごと外に出す」施策ではなく、「30%を外に出し、70%を自社で回す」という体制変更なんです。この70%を回す専任がいないままスタートすると、仕様の質疑が滞り、受入が後回しになり、ズレが静かに蓄積していきます。

では必ず専任PMOが要るのかというと、そうとも限りません。次の項目に当てはまるほど、専任の管理機能の必要性は高くなります。

• 継続的な開発で、複数チーム・複数案件が並行している
• 仕様変更が頻繁に発生する（新規事業・アジャイル寄りの開発）
• 社内にオフショア管理の経験者がいない
• 初めてのオフショア委託である
• 発注側の窓口担当が他業務との兼務になっている

逆に、数人月の単発案件で仕様が固まりきっているなら、窓口担当と明確なルールで足りる場合もあります。ただしその場合でも、「ルールを最初に設計する」工程だけは省略できません。問題への事後対処のコストは、事前対処の3〜5倍かかります。バグ1つでも、事前のレビューで潰すのと、納品後に発覚して修正・再テスト・横展開の調査までやるのとでは、かかる労力がまるで違う。オフショアでは物理的な距離と時差がここに上乗せされるので、差はさらに開きます。PMOにかかるコストは、この差額を先に払って手戻りを防ぐ先行投資だと考えるのが実態に近いと思います。

まず整理したいのは、ブリッジSEとPMOの役割の違いです。ブリッジSEは仕様と言語の「翻訳者」。発注側の意図を開発チームが動ける粒度に訳し、現地からの質問を日本側に返す役割です。一方でPMOは、その翻訳が正しく行われているかを検証し、翻訳者に頼らなくても認識が合う構造をつくる「設計者」。優秀なブリッジSEがいるからPMOは不要、とはなりません。仕様伝達も進捗管理も品質チェックも一人のブリッジSEに背負わせる体制は、その人が単一障害点になります。ブリッジSEの離任と同時にプロジェクトが崩れる構図は、オフショアの典型的な失敗パターンです。

体制の選択肢は、大きく3つに分けられます。

③の発注側PMOが担う役割は、具体的には次のとおりです。

• ドキュメント標準の整備: 仕様書テンプレート、用語集、Q&A管理フォーマットの統一
• 会議体の設計: デイリー／週次それぞれの目的・参加者・アジェンダの定義（進捗の読み上げで終わらせない設計）
• 課題管理の一元化: 課題・質疑・決定事項を1つのツールに集約し、更新ルールを敷く
• 品質ゲートの設定: 工程ごとの受入基準・レビュールールと、通過判定の運用
• 定量モニタリング: バグ密度・手戻り率・質疑回答のリードタイムなど、報告に依存しない実態把握

なお、海外拠点全体を束ねるガバナンス（いわゆるグローバルPMO）や国内ベンダーも含めたベンダーコントロールの一般論まで広げると論点が変わるため、本記事ではオフショア開発の管理に絞って話を進めます。

体制図を描いただけでは、認識のズレは1ミリも減りません。ここからは、僕がYouTubeでコミュニケーションマネジメントについて話した内容をもとに、ズレを防ぐ仕組みの中身を書きます。土台になるのは、たった一つのマインドセットです。

format_quote

それは、僕が元々いた会社で役員をやっていた方が言っていた言葉で、「伝わったことが伝えたこと」。

伝えたかどうかではなく、伝わったかどうかがすべて。伝わっていなければ、それは伝え方の問題——つまり自分の側の問題だと考える。オフショアでは「仕様書に書いたのに」「メールで送ったのに」と言いたくなる場面が山ほどありますが、書いた・送ったは「伝えた」であって「伝わった」ではありません。このマインドセットをプロジェクトの共通言語にした上で、次の4つの仕組みに落とし込みます。

1. 合意の文書化ルール

電話やビデオ会議で仕様変更を話したのに記録に残さず、後日「言った言わない」になって発注側が押し切られる。国内でもよくある失敗ですが、オフショアでは会話の記憶の精度がさらに落ちるため、致命傷になりやすい。口頭・チャットでの決定事項は24時間以内に課題管理ツールへ起票し、決定内容・理由・影響範囲を残す。起票の責任者をその場で毎回決めるのがポイントです。こうした合意の書面化を軸に仕様齟齬を防ぐ手法は、ベンダーコントロールの技術としてまとめた別記事でオフショアに限らない形で整理しています。

2. 理解確認のプロセス化

format_quote

伝わっていないと徹底的にまずいことになるみたいな場合は、「今僕が言ったことを一応復唱してくれる？」というふうに言うと、意外とわかっていないということがわかったりしますよね。

重要な仕様ほど、相手に自分の言葉で説明し返してもらう。「わかりました」と言ったかどうかではなく、相手の口から出てきた説明が合っているかで判定します。文化によっては「わかりました」が「聞こえました」の意味で使われることもある。復唱を失礼だと気にする必要はなくて、重要事項の標準プロセスにしてしまえば角も立ちません。

3. 図とサンプルで伝える

format_quote

これは図で説明した方がわかりやすそうだなということは、極力図を使って説明するということをしていました。

言語の壁があるなら、言語への依存度そのものを下げるのが正攻法です。画面はモックで、データは入出力のサンプルで、処理の流れは図で示す。用語集を整備して、同じ概念を毎回同じ単語で呼ぶことも地味に効きます。

4. 再説明の定期化

format_quote

僕がもう一つ大事だなと思っているのは、時間が空いたら何度も説明すること。

一度合意したルールや前提も、時間が経つと実行されなくなっていることがあります。そこで相手を責めても何も戻りません。人はそういうものだと織り込んで、重要な前提は節目ごとに再説明する場をあらかじめスケジュールに組み込んでおく。動画ではこの話を国内プロジェクトの文脈でしていますが、メンバーの入れ替わりが起きやすいオフショアでは、なおさら効きます。

この回では、コミュニケーションマネジメントが重要な理由と「伝わったことが伝えたこと」の実践を10分ほどで話しています。動画で詳しく知りたい方は、以下もあわせてご覧ください。

「認識のズレを無くすカギ【コミュニケーションマネジメント①】」

仕組みの必要性はわかった。では、誰が設計して回すのか。選択肢は、社内人材でPMOを立てるか、外部のPMO支援を使うかの2つです。判断軸を表にまとめます。

僕がおすすめしたいのは、二者択一ではなく時間軸で組み合わせる考え方です。立ち上げ期だけ外部PMOに管理の型——ドキュメント標準、会議体、品質ゲート——を設計してもらい、運用が回り始めたら社内メンバーへ移管する。型の設計は経験の差が出やすい仕事で、日々の運用は社内の文脈を知る人のほうが向いているからです。

もう一つ、発注側の方に伝えたいことがあります。オフショアがうまくいかないとき、ベンダーの能力不足を疑いたくなりますが、プロジェクトの失敗原因は発注側にも受注側にもあるというのが、両側に立ってきた僕の結論です。仕様の曖昧さ、質疑への回答の遅さ、受入検証の後回し——発注側起因のズレは、どれだけ優秀なオフショアチームでも吸収できません。だから発注側PMOは「ベンダーを管理する機能」である以上に、「発注側自身の動きを管理する機能」でもある。発注者側PMOの役割設計の全体像は本記事の範囲を超えるため、発注側に置くPMOの設置パターンを解説した別記事に譲りますが、この視点だけは持ち帰ってほしいと思います。

契約面にも一点だけ触れておくと、ラボ型（準委任に近い形態）か請負型かによって、進捗・品質への関与のしかたや指揮命令系統の整理が変わるため、体制設計とあわせて法務担当を交えた確認をおすすめします。

• オフショア開発の3大課題（品質・進捗・コミュニケーション）は、認識のズレという同じ原因から出た3つの症状
• コーディングは開発労力の30%前後。オフショアは「30%を外に出し、残り70%を自社で回す」体制変更であり、その70%を回す機能がPMO
• ブリッジSEは翻訳者、PMOは翻訳に頼らなくても認識が合う構造をつくる設計者。一人のブリッジSEへの依存は単一障害点になる
• 「伝わったことが伝えたこと」を個人の心がけで終わらせず、文書化・復唱・図解・再説明のルールに落とす
• 事後対処のコストは事前対処の3〜5倍。管理の仕組みづくりは、手戻りコストに対する先行投資

オフショア開発の失敗は、とかく海外チームの能力の問題として語られがちです。でも僕の見立ては逆で、成否を分けるのは発注側が仕組みを設計し切れているかどうか。単価の安さは、認識のズレが生む手戻りで簡単に吹き飛びます。いま感じている不安を「相手の問題」ではなく「仕組みの不在」として捉え直せたなら、打ち手は今日から設計できるはずです。仕組みの設計を自社だけで担い切れない場合は、外部PMO支援の活用も選択肢に入れてみてください。

※本記事は一般的な情報提供を目的としたものであり、法的助言ではありません。

---

オフショア開発の管理体制づくりに悩んだら

「オフショア先の品質が安定せず、受入のたびに手戻りが発生している」「ブリッジSE任せで、進捗の実態がつかめない」「発注側に管理の専任を置きたいが、社内に経験者がいない」——そんな状況であれば、一度お話を聞かせてください。

クリエイティブテックスタジオでは、発注側に立つPMOとして、オフショア開発におけるドキュメント標準・会議体・品質ゲートといった管理の仕組みづくりから、立ち上げ期の伴走までを支援しています。詳しい支援内容はPMO支援サービスをご覧ください。

まずは現状の体制と課題を伺った上で、外部PMOが本当に必要なのか、社内の窓口強化で足りるのかを率直にお伝えします。他社のサービスや別の打ち手が適していれば、その旨も正直に言います。無料相談からお気軽にどうぞ。