Yahoo! JAPAN

嫌われる優秀なPMO VS 好かれるダメPMO

「クライアントと開発側の意見が噛み合わず、一向に仕様と設計が決まらない──」
そんな現場の“迷走状態“を解決するのが、PMOの役割です。

優秀なPMOは、議論が紛糾した際に情報を整理し、プロジェクトを円滑に進めるための「議論の再起動力」を持っています。一方、ダメなPMOは、意見がまとまるまで粘り強く議論に付き合った結果、会議ばかりを繰り返してプロジェクトを停滞させてしまいます。

今回は、仕様や設計に関する議論が紛糾した際に、PMOとしてどう立て直せばよいのか、実際に私が経験してきた事例を交えながら紹介していきます。

株式会社office Root（オフィスルート）
代表取締役社長
甲州　潤（こうしゅうじゅん）

国立高専卒業後、ソフトウェア開発企業でSEとして一連の開発業務を経験し、フリーランスに転身。国内大手SI企業の大規模プロジェクトに多数参画し、優秀な人材がいても開発が失敗することに疑問を抱く。PMOとして活動を開始し、多数プロジェクトを成功へ導く。企業との協業も増加し、2020年に法人化。さまざまな企業課題と向き合う日々。著書『DX時代の最強PMOになる方法』（‎ビジネス教育出版社）

目次

そもそも、仕様と設計とは？仕様と設計を決める際に生じる「できる・できない」議論優秀なPMOは「議論を中断」して情報を再構成するダメPMOは迷走議論や脱線会議に付き合い続けがちPMOとして身につけたい「議論の舵取り力」チームでやると2倍学べる！？ シミュレーションのススメ紛糾した議論はいったん中断し、新たな視点で再起動を！書籍紹介

そもそも、仕様と設計とは？

本題に入る前に、プロジェクトにおける「仕様」と「設計」について整理しておきましょう。

「仕様」とは、ざっくりいうと「どんな機能を盛り込みたいのか？」「どんな顧客体験を提供したいのか」といった内容をまとめたものです。例えばECサイトの機能であれば、商品の検索、商品一覧の確認、カートへの投入、決済、注文履歴の確認、領収書のダウンロード、会員登録など。これらの機能が必要かどうかを決めて、仕様としてまとめていきます。

一方「設計」とは、決められた仕様を実現する「システムの仕組み」です。例えば検索条件に応じた商品データを表示するなどのSQL処理や、クレジットカード情報の暗号化、顧客データや注文データをどこに、どの形式で格納するかなど、内部的なシステム構造を決定する部分となります。

まとめると、仕様で「盛り込みたい機能（やりたいこと）」を決め、設計で「どう実現するか（やり方）」を決めていくということになります。

仕様と設計を決める際に生じる「できる・できない」議論

仕様と設計は密接に関係しており、通常は仕様を固めてから設計に移ります 。しかし、この過程でよく発生するのが「できる・できない」という議論です。

クライアント側が「こういう機能を入れたい」「こういうサイトを作っていきたい」と要望をまとめ、それを仕様として決定したにも関わらず、いざ設計段階になると、エンジニア側から「技術的に無理」「既存システムと合わない」などの理由で、差し戻しとなるケースが多々あります。

事例：ECサイトの注文受け付け機能

過去に携わったプロジェクトでは、ECサイトで「一分間に何百件、何千件もの注文を受け付けられるようにする」という仕様が決まりました 。それを設計側に持っていったところ、エンジニアからは「現状の性能では捌ききれません」と突き返されてしまいました。

前述のとおり、こうしたやり取りは珍しくありません。そこで、PMOの出番となるのです。仕様と設計を決める議論が迷走した状況では、クライアントと開発側の意見に耳を傾け、「双方が納得できるゴールはどこか？」を探る──そんなコミュニケーション力と調整力が求められます。以下より、具体的に見ていきましょう。

優秀なPMOは「議論を中断」して情報を再構成する

議論が紛糾し、結論が出ない状況で私がよく取る対応は、いったん議論を中断し、「宿題」として双方に持ち帰ってもらい、考え直す時間を設けることです。その際、これまでの議論の経緯、問題点、そして論点をまとめた資料を作成し、全体で認識を合わせることもセットで行います。

とはいえ、日々の業務が忙しい中で、仕様提示側・設計検討側が宿題にしっかり向き合い、新たなアイデアを持ち寄ることは正直なところあまり多くありません。結果として、PMOである私自身が双方の意見を整理し、代替案をまとめた上で、再度議論の場に持ち込むというケースが必然的に多くなります。

ですが、会話をしながらその場で情報を整理するのは大変です。この「大変」は、「PMOの業務的に」というわけではなく、「会議参加者、関係者ごとに思考のスピードが違うため大変」という意味です。そのため、双方が持ち帰っている間に一人でじっくり考える時間を持つことは、会議参加者、関係者それぞれが思考を整理し直すうえでも非常に有効だと実感しています。

事例：紛糾した「ECサイト注文受け付け機能」の着地点

前述のECサイトの事例では、エンジニアからの「できません」という返答を受け、一度議論を中断し、「この仕様で顧客にどんなベネフィットを提供したいのか」「実際、どの性能に問題があるのか」など改めて状況を整理することにしました。

すると、仕切り直しをしたことで、「注文の受付を分散させる仕組みはどうか？」「事前予約、段階的な受付という運用方法に変更すれば実現できないか？」「事前予約をした顧客には、発売日まで楽しみになるような表示やメッセージを発信し、待機期間をポジティブなものに変えるのはどうか？」といった、代替案がクライアントとエンジニアから出てきたのです。

結果として、システムの負荷集中を避けながらも、ユーザーの購買体験を損なわない形に落とし込むことができました。

双方の意見を汲み取った代替案により、紛糾していた議論は無事に着地。止まっていた議題が、再び動き出したのです。

特に設計するエンジニア側は「仕様の指示通りにシステムを構築しなければ……」という思考に陥りがちです。だからこそPMOに求められるのは、情報を整理し、「顧客体験」や「運用の現実性」といった視点を提示したうえで、議論を再起動することなのです。

「できますか？」「できません」というキャッチボールで終わらせるのではなく、「そのままでは難しいけれど、こうすれば実現できる」という、会話のステージを一段上げるようなイメージです。「どうすれば実現可能なのか？」という視点で議論を再開できれば、双方が納得できる解決策にたどり着けるはずです。

事例：本質を整理して仕様を見直した「勤怠管理システム」

前述の事例は設計に関するものでしたが、仕様を決める際にPMOとして意識したいコミュニケーションのあり方を示す事例も紹介します。社内向けの勤怠管理システムの開発プロジェクトに携わった際のエピソードです。

当初、クライアント側が提示してきた希望は「24時間・365日止まらないシステムにしたい」というものでした。もちろん、そういったシステムを設計・実装することは可能ですが、莫大な費用がかかるため、クライアントの希望予算では実現が難しい状況です。そこでPMOとして要望をいったん持ち帰り、「なぜその機能が必要なのか？」といった点から見直すことにしました。

後日、私はクライアントにこのような提案をしました。

「お客さまの場合、深夜帯や休日勤務を行うケースは年間で数える程度しかありません。それに、もしシステムが停止しても、停止時の対応を社員に周知しておき、後日システムにデータ投入することで業務に大きな影響を与えないと考えられます。そうであればシステム自体は平日9時～18時を必須稼働時間帯とし、その他の時間帯にトラブルが起きた場合は、翌営業日以降の可能な限り早急な復旧をする、としても問題ございませんか？」

こうしたより現実的な仕様を提案し、了承をいただいたのです。結果として、コスト全体（設計・開発・運用）が大幅に抑えられ、クライアントにも満足いただける着地となりました。

仕様を決める際、ときに過剰で非現実的な要望が盛り込まれることで話がまとまらないケースもあります。そうしたときこそ、「本質的なニーズは何か」を見極めることが大切です。要望をそのまま受け取るのではなく、「なぜそれが必要なのか？」を問い直し、現実的な仕様へと導くための対話と調整力が、優秀なPMOには求められます。

ダメPMOは迷走議論や脱線会議に付き合い続けがち

一方で、仕様と設計が決まらない状況下において、ダメなPMOがやりがちな対応としてよく見られるのが、粘り強く議論に付き合いすぎてしまい、会議を延長したり、繰り返したりしてしまうパターンです。

おそらくその背景には「専門知識がないことに引け目を感じて意見を言いづらい」といった心理があるのだと思いますが、本来、PMOは専門的な技術や知識をすべて把握する必要はないのです。

あくまでもプロジェクトを円滑に進めるのがPMOの役目。意見ができないからと言って、相手の意見を過剰に求めたり、出てきた意見をそのまま受け止めて話を進めたりと議論に付き合い続け、プロジェクトが停滞してしまっては元も子もありません。重要なのは議論の過程で「今何を決めるべきか」を見極め、「決めてもらうための問いを立てる」ことなのですが、それができていないケースも多いです。

例えば「仕様」を決めるための議論にも関わらず「パスワード設定は何文字にすべきか」「2段階認証の方法はどうか」といった話に飛躍してしまうことがあります。こうした内容は、本来は「設計」の段階で議論されるべきです。

PMOは、そうした議論の脱線に気づき、今決めるべき「仕様」の議題へと引き戻す役割が求められます。ですがダメなPMOはそのまま議論に耳を傾け続けてしまい、結果的に決めるべき仕様を決めきれずに会議を延長──という事態に陥ってしまうのです。

PMOとして身につけたい「議論の舵取り力」

ここまで、仕様と設計を決める議論が迷走した際にPMOに求められる役割についてお話ししてきましたが、まとめると、仕様と設計を決める議論を行うフェーズにおいて、PMOが最も身につけるべき力は「議論の舵取り力」だと私は考えています。そしてその舵取り力を磨くために、強くおすすめしたいのが「会議に臨む前のシミュレーション」です。

シミュレーションでは会議で行われそうな会話の流れ、資料の展開、想定される質問まで全て頭の中で再現し、途中で議論が止まりそうなポイントに気づいたら、補足資料を用意し、当日詰まらないように予め構成を整えておくのです。

具体的には、

「この議題で説明を始めたら、◯◯さんがこういう発言をするだろうから、それに対してはこう答える」
「次にこのスライドに進んだら、△△さんがこういう質問をしてくるだろうから、先にこの資料を準備しておこう」

といったもので、会議中のストーリーをシナリオとして詳細に描き、先回りして対応策を講じておきます。このシミュレーションは、PMOとして議論の舵取り力を高める、とても効果的なトレーニングだと思っています。

「大変そう」と思われるかもしれませんが、慣れてくれば自然とできるようになります。私もジュニアPMO時代は、1時間の会議に１時間かけてシミュレーションをしていましたが、今では15分ほどでサクッとできるようになりました。

チームでやると2倍学べる！？ シミュレーションのススメ

会議のシミュレーションは、一人で行うよりも、同じプロジェクトに参加しているメンバー、可能であれば先輩やPMと一緒に行うとより効果的です。

プロジェクトの内容を深く理解している人であれば、「この説明では、こういった質問が出るのでは？」といった、具体的な指摘や突っ込みが期待できます。その結果、一人では気づけなかった多くの観点に気づくことができるからです。

シミュレーションを通じて、議論中に飛び出してきそうな質問を事前に想定し、それに対するスマートな返答を準備しておくことで、本番の会議の場でも落ち着いて議論をリードすることができるでしょう。

会議を終えた後には、シミュレーションを行ったメンバーで「振り返り会」を行うことも強くおすすめします。振り返ることには「会議で議論した内容そのもの」と「会議の進め方」の二つがあります。

前者は、ラップアップと称して参加者全員で最後に会議を振り返る、など当たり前に行っていると思います。しかし、それとは別に後者の「会議の進め方」の振り返りを会議運営メンバーだけで実施することも重要です。

「なぜ、あの場面であの対応をしたのか？」「あの質問には、他にどう答えられたか？」といったやりとりを都度行うことで、実際の経験から多くを学び、次の会議に活かせるようになります。

紛糾した議論はいったん中断し、新たな視点で再起動を！

クライアントと開発側で話がまとまらないというケースはよくあります。そんなときにこそ、PMOとしての力を発揮し、仕様・設計を決める議論の再起動を実践してください。

その際「前回の議論の経緯」「課題」「着地案」を明確にして共有することも忘れずに、議論が論点から脱線しないように舵を取ることで、PMOとしてプロジェクトを生産的に動かし続けることができることでしょう。

書籍紹介

『DX時代の最強PMOになる方法』
著：甲州潤

▼こんなエンジニアはぜひお読みください。
・今の仕事に不満を持っていて、現状を変えたいと思っている
・給料をアップしたい
・エンジニアとしての将来が不安だ
・キャリアアップをしたいが、何をしたらいいかわからない
・PMOに興味がある
・PMOとして仕事をしたい

【目次】
第1章　一番稼げるIT人材は誰か
第2章　これからはPMOが1プロジェクトに1人必要
第3章　SEとPMOの仕事は何が違うか
第4章　稼ぐPMOになる７つのステップ
第5章　優秀なPMOとダメなPMOの見抜き方
第6章　PMOが最低限押さえておきたいシステム知識とスキル
第7章　システムは言われた通りに作ってはいけない
第8章　どんな時代でも生き残れる実力をつけよう

>>>詳細はこちら