背景
2024年、ある消費財メーカーが1億円規模のECアプリリニューアルプロジェクトに着手しました。
クライアント側が「品質保証部」と「全体PMO（Project Management Office：プロジェクトマネジメントオフィス）としてのITコンサル」という体制で、そして開発ベンダーがいるという体制でした。
クライアント側に品質保証部がいるということもあり、ベンダー側には、進捗や品質に関する丁寧な評価・報告が求められていました。
開発ベンダーはエンジニア集団として高い技術力を持つ一方、QCD（Quality, Cost, Delivery：品質、コスト、納期）で言えばD（開発スピード）を重視する社風。
「プロダクト（設計書やソースコード）」を作る作業には長けているものの、進捗管理や品質管理、工程評価といった「プロセス」を意識した運営には不慣れでした。
2024年8月に要件定義が開始されました。
一見、順調に進行しているように思えましたが、同年12月、要件定義工程の完了報告の際に事態は暗転します。
品質保証部や全体PMOから要件の網羅性・妥当性について厳しい指摘が入ったのです。
ベンダーはその指摘に対して明確な回答ができず、結果的にクライアントからの信頼を大きく損なう状況になりました。
このような「逆風」の中で、JQがベンダー側PMの補佐として参画することになったのです。
なお、本案件は、予算の関係上、PMと現場実態を把握するPMOをチームとしてで支援する「プロジェクトマネジメント支援サービス」ではなく、プロジェクトマネジメントのプロコンサルタントが、計画書や進捗報告書、工程終了報告書といったマネジメント成果物や工程成果物をベースに最適な計画やリカバリプラン、報告書作成をスポット的にご支援する「プロジェクトプランニング伴走サービス」として提供した初の案件になります。
プロセス
プロセス1：現状把握と立て直しの方針策定
私がプロジェクトに参画したのは2024年12月末で、ポジションはベンダー側PMの補佐（裏方）でした。
要件定義工程には参画しておらず、要件定義書そのものやそれ以降の工程のプロジェクト計画作成に関与していなかったため、クライアント側とどのようなコミュニケーションが取られ、どの程度の逆風にあるのか充分に把握できない、という状況でした。
そこで、JQが最初に取り組んだのは、要件定義の成果物を徹底的に分析することでした。
成果物の一覧と各成果物の関係性、記載粒度の確認を実施。さらに、ベンダー内レビューやクライアントレビューのプロセス確認と実施実績の確認を行いました。
分析の結果、画面や機能、非機能に関する要件はおおむね作成できていることが判明。
一方で、その後の開発計画や管理ルールが不明確な状態であることが課題として浮かび上がりました。
要件の品質という点では、要件の網羅性や妥当性を説明するために、要件定義工程の実施プロセスやチェック観点の見える化を改めて行い、品質保証部やPMOに提示しました。
開発計画や管理ルールについては、開発計画書やルール案を再作成し提示するというアクションを取りました。この一連のプロセスを通じて、クライアント側の懸念点や期待値の解像度が高くなり、信頼回復に向けた具体的な道筋を築くことができました。
この一連の取り組みは、後のフェーズで品質管理体制を確立する上での基盤となりました。
プロセス2：役割の明確化と品質評価プロセスの構築
次に取り組んだのは、チーム内の役割の明確化とプロセス整備です。
プロのエンジニア集団は、全員がプログラムに関することなら何でもできると自負しています。
しかし、統制の取れた組織運営には不慣れ。
そこで、チーム内での役割を明確化し、その役割に応じたプロセスをしっかり回していくことを提案しました。
最も困難だったのは、ベンダー側の品質分析担当者との役割のすり合わせです。
品質評価では、不具合やミスに対して「なぜ混入したのか」「なぜ事前に発見できなかったのか」という2つの側面から分析します。
しかし、プロのエンジニアだからこそ、分析が「人の問題」「技術力の問題」に帰責しがちでした。
JQが大事にしている考え方は、可能な限り人の問題に帰責させず、プロセス上の抜けやガイドラインの不足といった、ルール面の問題を探るというものです。
ルールの課題を分析し、解決すれば、その改善されたルールは、横展開でき、プロダクト「全体」の品質向上につなげることができます。
この考え方を浸透させるため、まずベンダーの品質分析担当者に寄り添うことから始めました。
「いきなり完璧な分析をもってこなくてよい。まず一次分析を持ってきてほしい。それをもとに次のアクションを一緒に考えよう」と伝えました。
さらに、このやりとりをベンダーの責任者や各開発リーダーも同席する会議体で行いました。
JQがどのような視点で、どのような情報を求めているかを全員が知ることで、品質分析担当者に自然と情報が集まり、分析しやすい環境を整えることができました。
プロセス3：プロセス管理とプロダクト品質向上の体制分離
プロジェクト成功の最大のポイントは、「プロセス管理」と「プロダクト品質向上」を体制として明確に分けたことです。
プロセス管理とは、ルール整備とそれに即した運営のこと。
プロダクト品質向上とは、設計書やプログラム、テスト自体の品質を上げること。
これが混在すると、エンジニアは不慣れな管理業務とプログラム開発の両方を担当せざるを得ず、プロダクトの品質も下がり、プロジェクト状況の適切な把握もできなくなります。
本案件では、日々の進捗管理や課題対応、品質分析といった「管理実務」はベンダーに残し、JQは各工程の推進計画立案といった「計画実務」や、管理実務を通じて得られた情報の整理・評価・改善案提示といった「推進実務」に徹する枠組みで参画しています。
週次報告では、遅延が発生すれば必ずその原因とリカバリプランを提示し、対応結果も常に報告。
各工程完了報告書も、単なる完了報告ではなく、課題や発生不具合をベースにした分析、品質強化策とその対応結果までストーリーを組み立てて報告しました。
この分離により、プロジェクト状況が適切に可視化され、効率的なマネジメントが実現。
エンジニアはプロダクトに集中でき、品質の底上げにもつながりました。
結果
2025年7月、新しいECアプリ開発プロジェクトは無事にベンダー側のテストを予定通り完了しました。
完了期限までにすべての開発および不具合修正を終わらせることができ、要件定義時にはまったく信頼されていなかったベンダーが、設計完了時には「最も丁寧に分析・評価していて、説明も非常にわかりやすい」とクライアントから評価されるまでに信頼を回復しました。
もちろん、このテスト完了のタイミングも同等の信頼を維持し続けています。
プロジェクトの成功要因として、以下の点が挙げられます。
- 第三者的ポジションからの論理的な課題の抽出：強い不信感を持たれている中でも、問題の所在を論理的に整理し、問題自体をクライアントと共有。それぞれの問題に対する対策をプロダクト・プロセスの両面から説明し続けることで相互理解が深まり信頼関係を取り戻すことができました。
- 意思決定者直下での実行力：裏方のポジションながら、ベンダー側の意思決定者直下で動けていたため、立てた対策を現実的に実行に移すことができました。
- プロセス管理とプロダクト品質向上の明確な分離：エンジニア集団というプロダクト至上主義の中に、プロセス管理の重要性とその活用方法をJQが注入。主担当を立て、自立した評価ができるよう支援したことでプロダクトの品質も向上。クライアントの信頼獲得につながりました。
結果として、クライアント、ベンダー、関係者全員から高い評価と感謝の言葉をいただきました。
特にクライアントから「他社に比べて一番丁寧に分析・報告してくれる」という言葉をいただけたことは、プロジェクトマネジメントを生業としている身としては、とても嬉しいことでした。
本案件は、現場にプロマネ、PMO要員を投入するのではなく、JQの持っているノウハウ、方法論を投入することによっても、プロジェクトの推進力を生み出せるということを証明できた案件でした。
JQの新しい支援方法を確立したという意味で、JQにとってもとても意義のある案件となりました。
