PMOは要件定義で何をすべきか？進め方・成果物・合意形成の実践手順を解説

要件定義が始まったのに、会議のたびに新しい論点が湧き、先週決まったはずのことが今週ひっくり返る。PMOを入れているのに、増えていくのは議事録ばかり——この記事は、そんな状況にいる発注側のPM・情シス担当者に向けて書いています。結論を先に言うと、要件定義フェーズのPMOがやるべきことは3つです。討議すべき論点の全量を序盤で可視化すること、「何を作らないか」まで含めて合意を設計すること、そしてその合意の鮮度を保ち続けること。僕はシンプレクスで金融系プロジェクトのPMとして要件定義を回す側におり、いまはPMO支援を提供する会社を経営しています。その経験をもとに、要件定義フェーズのPMOの動き方を実務の手順に落として解説します。

開発プロジェクトの7割は上流工程で決まる。僕はこう考えています。システム開発の成功率は3割と言われるほど失敗の多い世界ですが、赤字や大幅遅延といった「大コケ」をしたプロジェクトを遡ると、行き着く先はほぼ例外なく要件定義です。テスト工程で噴き出した品質問題も、設計の途中で発覚した認識齟齬も、生まれた場所はそこではない。根は上流にあります。遅延の最大要因もまた、多くの場合は上流の詰めの甘さに行き着くと僕は見ています。

YouTubeで要件定義の進め方を話したときも、僕はここを一番強く言いました。

format_quote

要件定義のミスというのは、プロジェクトを運営していく中で最も大きなリスクになるんですよね。赤字になってしまうとか、納期に間に合わないとか、こういった大炎上みたいなものは、だいたい全部要件定義が原因になっています。

だからこそ、要件定義フェーズにこそマネジメントの専門部隊、つまりPMOを効かせる価値があります。誤解されがちですが、このフェーズのPMOの仕事は議事録取りでも日程調整でもありません。決めるべきことを漏れなく洗い出し、決まる順番を設計し、決まったことを風化させない——一言でいえば「合意の設計者」です。

なお、PMOの業務全般をタスク一覧として網羅する話は本記事では扱わず、要件定義フェーズに絞って深掘りします。発注者側PMOとベンダー側PMOの役割分担という論点も別稿に譲り、ここでは立場を問わず共通する動き方を書きます。

要件定義フェーズのPMOの役割は、大きく4つに分解できます。自社のPMOが機能しているかを判定する材料として、「機能していないサイン」もあわせて載せておきます。

このうち、検索してもあまり情報が出てこないのが上の2つ、論点の全量管理とセッション設計です。ところが実際のプロジェクトでは、ここの巧拙が要件定義の成否をほぼ決めます。次の章で具体的な手順を見ていきましょう。

ステップ1：ビジネスモデル・利用ユーザー・業務フローで全体像をつかむ

要件定義の前半には、個別の機能の話ではなく、全体に関わるトピックを持ってきます。順番は3つ。

1. ビジネスモデルの整理。システムは何かしらのビジネス要求を実現するためにあります。「そもそも何のためにやるのか」が言語化されていないと、実現方式のA案とB案で迷ったとき、選び取る軸がなくなる。
2. 利用ユーザーの洗い出し。エンドユーザーだけでなく、管理者、さらにその上位の管理者まで、システムに触れる登場人物を漏れなく挙げます。ユーザーが1人漏れると、そのユーザーに必要な機能群がまるごと漏れます。
3. 業務フローの明確化。アクティビティ図の形式で、登場人物ごとの列を作り、システムをどう使うかを分岐まで含めた流れで描く。これができると、必要な機能の全体像が概要レベルで見えてきます。

発注側の担当者に強調したいのは、ビジネスモデルと利用ユーザーの整理は、受注ベンダーに丸投げできる仕事ではないということです。ここの解像度は発注側にしか出せません。PMOには「この整理が要件定義の開始前に済んでいるか」の点検役を担わせてください。

ステップ2：業務フローの各パーツに「3つの問い」を当て、不明点をアジェンダ化する

全体像ができたら、業務フローの1ボックスごとに次の3つを自問していきます。

• その機能は、具体的にどういうものであればよいか（プロダクトスコープの詳細）
• その機能を、どうやって実現するか（自前で開発するか、外部サービスを使うか）
• 実現に必要な作業を、どの会社が分担するか（プロジェクトスコープ）

頭の中でシミュレーションすると、明らかになっていない部分が大量に出てきます。「プロフィールを入力する」と書いてあるが入力項目は何か。決済は自前で組むのか、外部の決済サービスを使うのか。外部サービスを使うなら、そのベンダーとのやり取りはどちらの会社が持つのか。この「どうしたらいいんだろう」という疑問が、そのまま要件定義のアジェンダになります。PMOの腕の見せどころは、この洗い出しを個人の頭の中で終わらせず、組織としてやり切って課題管理表に積み上げることです。

ステップ3：積み上げた論点をセッションスケジュールに落とし込む

最後に、洗い出した課題を「いつ、どのセッションで話し合うか」に配置します。並べる順番のポイントは3つあります。

• 業務の流れに沿わせる。前段の業務が決まっていたほうが、後段の議論はしやすい
• スコープへのインパクトが大きい論点を先に。決済方式のように関係会社や費用が大きく変わる論点は、早く解消するほど要件定義全体のリスクが減る
• 依存関係に注意する。Aが決まらないとBを検討できないなら、必ずAを先に置く

ここまでやると、要件定義は「毎週アジェンダをひねり出す営み」ではなくなります。

format_quote

全体像が明らかになれば、その時点で一週一週アジェンダを考えていく必要なんてなくて、全体像がわかっているんだから、もう全部アジェンダを最初から最後まで全部出してしまえばいいんですよ。

僕自身の運用も、動画でこう話しています。

format_quote

僕の場合、3、4,000万ぐらいまでのプロジェクトだったら、要件定義のセッションを始めて2週目が終わったタイミングぐらいでは、もう要件定義3ヶ月の中でどのタイミングで何を話し合うかというのを完全に確定した状態に持っていってます。

もちろん、進める中で追加要望や新しい論点は見つかります。それでも「これを話し切れば要件定義は完了する」と言えるスケジュールを序盤に書き切っておくかどうかで、後半の安定感がまるで違う。架空プロジェクトのセッションスケジュール例も含めて、動画で詳しく知りたい方は、以下もあわせてご覧ください。

「【炎上回避】敏腕PMの要件定義の進め方を完全公開」

要件定義フェーズの主な成果物と、PMOがレビューで見るべきポイントを一覧にしました。

大事なのは、成果物が「ある」ことではなく、「決めるべきことが決まった状態」を成果物で証明できることです。品質レビューというと文書の体裁チェックになりがちですが、PMOが見るべきは網羅性と整合性。業務フローには存在するのに機能一覧にない箱はないか、課題管理表では保留のままなのに要件定義書では確定扱いになっている項目はないか。成果物同士を突き合わせて、初めてレビューは意味を持ちます。

要件定義の合意形成で、僕がPMとして一番こだわってきた部分です。

金融系プロジェクトで最初に叩き込まれたのは、品質問題の大半はテスト工程で発見されるが、テスト工程で生まれたものではない、ということでした。根はほぼ例外なく上流にある。だから僕は、仕様を合意するたびに「何を作るか」「何を作らないか」「判断が変わりうる条件は何か」の3点確認を徹底していました。特に効くのがスコープ外の言語化です。作るものリストだけでは、後工程で必ず「これも入ると思っていた」が出てくる。作らないものを文字にして合意しておくと、この認識齟齬を大幅に減らせます。「作らないもの」まで書面に落としてベンダーと握る具体的な進め方は、ベンダーコントロールというテーマとして独立した論点になるため、本記事では割愛します。

もうひとつが、合意の鮮度管理です。要件定義で合意した内容は、時間とともに必ずズレます。生鮮食品と同じで、合意は放っておくと鮮度が落ちる。人の記憶は上書きされ、口頭の補足が独り歩きし、放置されたズレはテスト工程で爆発します。だから僕は「合意は鮮度が落ちる」という前提をチームで共有し、週1回の合意確認をプロジェクトの定型業務に組み込んでいました。ポイントは、PMの記憶力や注意深さに依存させないこと。組織のルーチンとして合意点を維持する仕組みをつくるのが、PMOの仕事です。

手間に見えるかもしれません。ただ、問題への事後対処のコストは事前対処の3〜5倍かかります。要件定義での1時間の確認をサボった代償は、テスト工程の手戻りや本番障害の対応となって返ってくる。前始末は、後始末より圧倒的に安いんです。ちなみに、プロジェクト中盤以降の遅延も多くの場合は症状にすぎず、真因はこのフェーズで仕込まれたスコープ認識のズレです（遅延の原因分析やリカバリの方法論は、それだけで一本の記事になるためここでは踏み込みません）。

それでも要件定義が停滞することはあります。症状別に、PMOが打てる手を整理します。

症状1：セッションで何も決まらない

論点は出ているのに、毎回「持ち帰り」で終わるパターン。多くの場合、決裁できる人が場にいないことが原因です。PMOの介入は、論点ごとに「誰なら決められるのか」を事前に特定し、重い論点を決裁者が出席するセッションに寄せること。アジェンダに「本日の決定事項」を明記し、報告の場ではなく決める場だと参加者の認識を変えるだけでも効きます。

症状2：論点が場当たり的に増え続け、終わりが見えない

毎週のセッション前夜にアジェンダを考えているプロジェクトは、この症状の予備軍です。動画でも言いましたが、僕の立場ははっきりしています。

format_quote

毎週毎週、1週間ごとにアジェンダを考えているみたいなプロジェクトがあると思うんですけど、これは僕は本当に論外だと思っていて。

介入はシンプルで、一度立ち止まってステップ1〜3をやり直すことです。全体像を描き直し、残っている論点を全量出しし、残りのセッションに配置し直す。遠回りに見えて、これが最短ルートです。

症状3：後から要件が次々に湧いてくる

「全体像はわかったつもり」で始めた要件定義に典型的な症状です。原因はステップ2のシミュレーション不足。業務フローの各パーツに3つの問いを当て切れておらず、深掘りされていない箱が残っています。PMOは、湧いてきた要件をその都度アジェンダに足すだけで済ませず、どの箱の検討漏れだったのかまで遡り、同じ種類の漏れを面で潰しにいくべきです。

介入の初動では、次の点検が使えます。

• 残論点の一覧が存在するか（存在しないなら、まず全量出しから）
• 各論点に「いつ・誰と・何を決めるか」が紐づいているか
• 直近2週間で「決定」に変わった論点がいくつあるか
• 「作らないもの」の合意リストが更新されているか

この点検で抜けが多く、社内だけでの立て直しが難しそうな場合は、上流フェーズから入れる外部PMO支援も選択肢として検討してみてください。

• 大炎上の原因のほとんどは要件定義にあり、プロジェクトの7割は上流で決まる
• 要件定義フェーズのPMOの中核業務は、論点の全量可視化とセッションスケジュール設計
• 手順は「全体像の把握→3つの問いで不明点をアジェンダ化→スケジュールへ配置」の3ステップ
• 成果物レビューは体裁ではなく、網羅性・整合性・「作らないもの」の明記を見る
• 合意は鮮度が落ちる。週1回の合意確認をルーチン化して風化を防ぐ

要件定義のPMOというと、会議調整と議事録の人、というイメージがまだ根強いと思います。でも本来は、プロジェクト最大のリスク発生源に最初に手を打てる、いちばん割のいいポジションです。いま要件定義を控えている方も、すでに渦中にいる方も、まずは「論点の全量が見えているか」から点検してみてください。

---

要件定義フェーズのPMO活用を検討している方へ

「要件定義が始まったが、論点を出し切れている自信がない」「PMOを入れたのに議事録係になっている」「『何を作らないか』が曖昧なまま設計に進みそうで怖い」——そんな状態でしたら、一度お話を聞かせてください。

クリエイティブテックスタジオでは、要件定義フェーズからのPMO支援を提供しています。現状のセッションスケジュールと課題管理表を拝見できれば、初回の会話でも論点の抜けはある程度お伝えできます。支援の型はPMO支援サービスにまとめています。

無料相談から、プロジェクトの状況をお聞かせください。外部PMOを入れるより社内で立て直せるケースや、弊社より適した支援先があるケースでは、その旨も正直にお伝えします。