品質PMOとは？QMOとの違い・支援内容・導入効果を事例つきで解説

テスト工程に入った途端にバグが噴き出し、UATでは業務部門からの指摘が積み上がり、リリース日は後ろに延びていく——。そんな火消しを繰り返す中で「品質PMO」という言葉にたどり着いた方に向けた記事です。品質PMOとは、PMOの機能のうち品質保証・品質管理に特化した支援を担う役割・サービスのこと。僕はシンプレクスでPMをしていた4年間、担当した全プロジェクトでQCD未達ゼロを続け、独立後は自分の会社で、品質が崩れたプロジェクトの火消しをPMOとして支援した経験もあります。その経験から先に結論を言うと、品質PMOに期待すべきは「テスト要員の追加」ではなく「品質保証の設計」です。QMOとの違い、支援内容、導入効果と実際の事例、外注時の比較ポイントまで、発注側の目線で整理します。

品質PMOとは、PMO（プロジェクトマネジメントオフィス）の機能のうち、品質マネジメント領域に特化した支援を担うチーム・サービスを指します。進捗・課題・体制を幅広く見る一般的なPMOに対し、品質PMOは品質計画の策定、品質基準づくり、レビューやテストの管理、品質状況のモニタリングと是正——つまり「品質を守る仕組み」の構築と運用に軸足を置きます。

似た言葉にQMO（Quality Management Office：品質管理オフィス）があります。重なる部分は大きいのですが、使われ方のニュアンスには違いがあります。

ただ、正直に言うと、この呼び分けは提供会社によってかなり揺れています。品質PMOをQMOと呼ぶ会社もあれば、その逆もある。発注側として大事なのは名前ではなく、「品質保証のどこからどこまでを任せるのか」を契約前に定義することです。この記事で支援内容を分解していくのは、その定義の材料にしてもらうためでもあります。なお、PMO全体の類型（支援型・コントロール型・指揮型）の整理は本記事では踏み込みません。

支援内容に入る前に、前提をひとつ共有させてください。シンプレクスでPMをしていた4年間、僕は担当した全プロジェクトでQCD未達ゼロを達成しました。ただ、これを自分の努力の成果と言うつもりはありません。振り返ると、QCDを守れていたのは「予兆を組織で拾う構造」「合意のズレを補正する仕組み」「悪い報告を歓迎する文化」の3つが組織として機能していたからです。この3つが整っていれば平均的なPMでもQCDは守れるし、逆にどれだけ優秀なPMでも、組織側にこの構造がなければ守れない。品質は個人の頑張りではなく、構造の問題なんです。

もうひとつの前提は、品質保証はテスト工程だけの話ではないということ。この点は、僕が主宰しているPMコミュニティの勉強会でも講義したテーマです。

format_quote

システムの品質というのは、全工程の品質保証の積み上げなんですよね。品質保証と言うと連想しがちなのは開発したものに対するテストだと思うんですけれども、要件定義の品質保証もきちんとPMは考えないといけないし、設計の品質保証もきちんと考えないといけない。

要件定義書の記述がゆるすぎて設計に落とし込めない。設計書に数値の丸め方が書かれておらず、実装者が判断に迷う。こうした上流の綻びは、必ず後続工程にしわ寄せとして流れ込みます。開発プロジェクトの7割は上流で決まるというのが僕の持論ですが、品質も例外ではありません。しかも、問題への対処コストは事前に比べて事後は3〜5倍かかる。テスト工程で品質問題をまとめて発見する構造は、実は最も高くつく品質保証のやり方です。

品質PMOの支援内容は、大きく4つに分解できます。順に見ていきます。

1. 品質計画・品質基準の策定

最初の仕事は、プロジェクト全体の品質計画を作ることです。各工程で何をもって品質を保証するのか、その範囲と方法と基準を定義する。ここで重要なのは、品質保証の範囲を各チームの解釈に任せず、全体を見る立場からトップダウンで決めることです。

format_quote

各工程の品質保証やテスト工程間の品質保証範囲は、トップダウン型で決められないと隙間が生じてしまう。ユニットテストとITのどちらでも行われないテストがあるのはNG、という話になります。

たとえば開発チームは「サーバー側のロジックは単体テストで確認済み」と解釈し、結合テストチームは「そこは単体で拾われているはず」と解釈する。この解釈の隙間に、画面とサーバーをつないだときにしか出ない不具合が落ちていきます。各テスト工程の保証範囲を漏れなく重複なく定義し、文書で合意しておく。地味ですが、これが品質計画の中核です。

2. 上流工程の品質保証——レビュー設計とチェックリスト

レビュー自体はどの現場でもやっています。ただ、「誰が、どの粒度で、何を確認するのか」まで定義されているケースは意外なほど少ない。設計書をメンバー同士の相互レビューで済ませるのか、設計リードが必ず見るのか。それだけでも品質は変わります。品質PMOは、レビュアーの設定、レビュー観点の整備、チェックリストの作成といったレビュープロセスの設計を支援します。バッチ設計ならリラン可能な作りになっているか、IF仕様なら項目名だけでなく型や桁数まで書かれているか——漏れがちな点を、属人的な注意力ではなく仕組みで潰すわけです。品質問題も突き詰めれば「起きる前に潰す」リスクマネジメントの一種なので、この仕組みづくりの考え方はリスク管理の5ステップを解説した記事と合わせて読むと立体的に理解できるはずです。

上流工程の品質確認は定性的になりがちですが、定量的なモニタリングも組めます。僕が現場でやっていた例を挙げると、こうです。

format_quote

同じ3億円ぐらいの規模のプロジェクトだったら、過去のプロジェクトでは要件定義書が大体70ページぐらい書かれていた。今やっているプロジェクトも大体3億円ぐらいの規模なんだけれども、どうやら要件定義書のページ数が40ページぐらいしかないぞと。これ、本当に書くべきことが書かれきってるんだっけ、と。

過去の同規模プロジェクトとの比較というシンプルな物差しでも、「検討し切れていない領域があるのでは」という問いを立てられる。上流にもテスト消化率のような数字を持ち込むのが品質PMOの仕事です。

3. テスト管理

テスト工程では、単体・結合・システム・受入といった各テストレベルの範囲定義、消化率や障害検出率のモニタリング、障害の分析と横展開の管理を担います。ヒューマンエラーへの対策もここに含まれます。僕がPMをしていた頃は、テスト実施者に残してもらったエビデンスの20%をPMがサンプリングで再鑑していました。どの程度確認すれば妥当と判断できるか、統計の指標を参考に決めた数字です。実際にやってみると、打鍵方法の誤りに気づけたこともあれば、逆に「その丁寧な作業は目的上不要ですよ」と無駄を省くコミュニケーションが生まれたこともある。検査のための検査ではなく、テストという活動そのものの質を上げるための仕掛けです。

4. 品質状況の見える化と是正——悪い報告が上がる場づくり

品質モニタリングで一番怖いのは、数字がきれいなまま突然壊れることです。金融系プロジェクトは障害の影響が大きい分、問題の報告が遅れると致命傷になります。だから僕がPMとして最も意識していたのは、悪い報告をしてきたメンバーを絶対に責めないことでした。まず「ありがとう、助かる」と返し、そのうえで一緒に対策を考える。この積み重ねがないとメンバーは問題を隠し、隠された問題はテスト工程やリリース直前で爆発します。品質管理の仕組みをどれだけ整えても、報告しにくい空気の組織では品質は守れない。だから品質PMOには、メトリクスの整備と同時に、この「悪い報告が早く上がる場」を作る役割まで期待すべきです。

発注側から見た導入効果は、次の4つに集約されます。

• 手戻りコストの削減：事後対処は事前対処の3〜5倍のコストがかかる。上流からの品質保証は、この差分をそのまま回収する打ち手になる
• リリース後インシデントの減少：保証範囲の隙間を塞ぐことで、本番で初めて見つかる不具合が減る
• 品質判断に根拠ができる：「この品質でリリースして大丈夫か」を、勘や空気ではなくデータで判断できるようになる
• 発注側の可視性向上：ベンダー任せでブラックボックスだった品質の中身が、共通の基準で見えるようになる

そして僕が一番大きいと思う効果は、支援が終わった後に「組織の品質文化」が残ることです。予兆を組織で拾う構造、合意のズレを補正する仕組み、悪い報告を歓迎する文化。QCD未達ゼロを支えていたこの3つは、一度根付くと次のプロジェクトでも機能し続けます。逆に、支援が終わった瞬間に元へ戻るなら、それは品質PMOではなくただの検査外注です。提案を受けるときは、この「何が残るか」を必ず聞いてみてください。

具体的な事例をひとつ。僕の会社が支援した、あるベンチャー企業でのことです。プロジェクトを率いていたのはSIer出身のシニアなPMで、SIer時代は品質保証の計画をきちんと作り上げてきた方でした。ところが、開発文化も組織風土も違うベンチャーという環境で、品質保証の全体計画を立てないままプロジェクトが走り出してしまった。テストのやり方も粒度も、開発者ごとにバラバラのまま。その結果がこれです。

format_quote

うまくいかないどころか大炎上しまして、UATでお客さんからの指摘が70個とか50個とか、それぐらい来ちゃうみたいなことが起きました。

僕の会社は問題が表面化してから、PMO的な立場で火消しに入りました。ただ、品質保証のプロセスが定まっていない現場では、不具合を直しても直してもリグレッションやデグレが新たに発生します。事態の収束には相当な時間がかかりました。このとき実際に踏んだ立て直しの一般的な手順は、炎上プロジェクトを立て直す火消し7ステップの記事で全体像をまとめています。

この事例の教訓は2つあります。第一に、経験豊富なPMでも環境が変われば品質は崩れる——やはり品質は個人ではなく構造の問題だということ。第二に、品質PMOは火消しで入れるより、計画段階から入れるほうが圧倒的に安いということ。前始末は後始末の3〜5倍安い、を地で行く事例でした。

この事例を取り上げた品質保証の講義は、動画としても公開しています。品質計画の考え方を音声つきで詳しく知りたい方は、以下もあわせてご覧ください。

「PMのマスト知識「品質保証」を徹底解説！【PMサロン勉強会 品質①】」

品質PMOを外部委託するとき、一番多い失敗は「テスト実行サービス」と「品質保証の設計支援」を混同することです。提案を受ける際は、次の6点を確認してください。

• 上流工程まで踏み込むか：テスト工程の管理だけでなく、要件定義・設計のレビュープロセス設計まで担うか
• 品質計画を作れるか：過去に策定した品質計画・品質基準のサンプル（マスキング版）を見せてもらえるか
• 保証範囲の定義から入るか：既存のテスト計画を見て「どのテストレベルにも属さない隙間」を指摘できるか
• 定量・定性の両方の物差しを持つか：消化率・障害検出率・レビュー指摘密度など、使うメトリクスを具体的に語れるか
• 是正まで責任を持つか：品質レポートを納品して終わりか、改善アクションの実行まで並走するか
• 仕組みを残す設計か：支援終了後、自社メンバーだけで品質管理が回る状態をゴールに置いているか

とくに5点目は重要です。数字を並べたレポートだけ出して判断は丸投げする「評論家型」の支援は、現場の負荷を増やすだけで品質は改善しません。なお、品質特化に限らない支援会社選び全般の基準は、PMOコンサル会社の失敗しない選び方5つのポイントを整理した記事にまとめているので、そちらを参照してください。本記事の6点だけでも、テスト外注と品質PMOの見分けは十分につくはずです。

• 品質PMOは品質マネジメントに特化したPMO。QMOと重なるが、呼び名より「どこからどこまで任せるか」の定義が重要
• システムの品質は全工程の品質保証の積み上げ。テスト工程だけで担保しようとする構造が、一番高くつく
• 支援内容の中核は、品質計画・品質基準の策定、レビュー設計、テスト管理、そして悪い報告が早く上がる場づくり
• 導入効果は手戻り削減・インシデント減少に加え、支援後も残る「組織の品質文化」で測る
• 外注時は「上流まで踏み込むか」「仕組みを残すか」で、テスト外注との違いを見極める

UATで指摘が積み上がってから品質PMOを探すのと、キックオフの段階で品質保証を設計しておくのとでは、同じ投資でも回収できる価値がまるで違います。いま品質の火が見えているなら、消すのが先。ただ、火が消えたそのときこそ、次は燃えない構造を作る番です。

---

テスト工程で慌てる前に、品質保証の設計を見直しませんか

「UATのたびに指摘の山で、リリース日を守れる気がしない」「ベンダーは『テスト済み』と言うが、何をどこまで確認したのか分からない」「品質会議が障害件数の読み上げで終わっている」——こうした状態は、テスト要員を増やしても解決しません。足りていないのはテストの量ではなく、品質保証の設計だからです。

クリエイティブテックスタジオでは、品質計画の策定から上流工程のレビュー設計、テスト管理、火消し後の再発防止まで、品質に軸足を置いたPMO支援を提供しています。僕自身、受注側PMとしてQCD未達ゼロを経験し、プロジェクトの失敗原因は発注側にも受注側にもあるという前提で支援してきたので、両方の視点から品質保証の穴を探せます。PMO支援サービスの詳細はこちらからご覧いただけます。

まずは現状の品質課題をそのまま聞かせてください。お話を伺ったうえで、品質PMOよりも体制やスコープ定義の見直しが先だと判断すれば、その旨も正直にお伝えします。無料相談から、気軽にご連絡ください。