最強PMOこと、甲州潤が教える！
嫌われる優秀なPMO VS 好かれるダメPMOプロジェクトのスムーズな進行を進め、成功に導くのがPMOの役割ですが、開発現場からは「ただの御用聞き係でしょ？」「進行管理などの事務作業をしている人」と思われていることも......。ではPMOの本来あるべき姿はどのようなものなのでしょうか？ 本連載では、『DX時代の最強PMOになる方法』の著者であり、PMOとして多くのIT利活用や経営相談をこなす甲州潤さんが「嫌われる優秀なPMO」と「好かれるダメPMO」で対比しながら、優秀なPMOの価値観やマインド、行動を伝えていきます！
「甲州さん、プロジェクトが思うように進まないんです」
そんな相談をPMOから受けたとき、私は必ずこう問いかけます。
「“要件定義”と“管理”を混同していませんか？」
この二つを混同した状態でプロジェクトを進行すると、結果的にプロジェクトの停滞を招くことがあるからです。
優秀なPMOは、要件定義と管理を「スイッチを切り替えるように」整理しています。今回は、プロジェクトを滞りなく前進させるために欠かせない「要件定義と管理の分割」について、具体的な事例も挙げながら分かりやすくご紹介します。
株式会社office Root（オフィスルート）
代表取締役社長
甲州 潤（こうしゅうじゅん）
国立高専卒業後、ソフトウェア開発企業でSEとして一連の開発業務を経験し、フリーランスに転身。国内大手SI企業の大規模プロジェクトに多数参画し、優秀な人材がいても開発が失敗することに疑問を抱く。PMOとして活動を開始し、多数プロジェクトを成功へ導く。企業との協業も増加し、2020年に法人化。さまざまな企業課題と向き合う日々。著書『DX時代の最強PMOになる方法』（ビジネス教育出版社）
目次
要件定義とは、プロジェクトの骨格を決める重要なフェーズです。例えば、対象・目的・範囲を明確にし、そのプロジェクトで「何をするのか」を言語化していくフェーズで、プロジェクトの肝とも言えます。
「そんなの簡単に決められるでしょう」と思うかもしれませんが、多くの人が関わるプロジェクトであるほど、一筋縄ではいかないものです。例えば、たくさんの意見が出過ぎてまとまらなかったり、話の方向性が定まらなかったりするわけです。
そんなときデキるPMOは、以下の三つをポイントに置き、要件定義を進めていきます。
要件定義は、最初から「あれはダメ」「これはできない」と制限をかける必要はありません。むしろ、「最終的にどうなりたいのか」という理想の姿を自由に語るところから始めます。
「せっかくならこれもしたい」「こういうこともできるのでは？」「こうあるべきだ！」など意見や議論が活発化したらOK。この時点で「実際にできるか、できないか」は考えなくて大丈夫です。
そうして風呂敷を広げたら、次に理想をはばむ「現状の課題」をできるだけ多く洗い出します。そのうえで、これらの課題はどうなれば解決と言えるのか、現実的に解決可能な課題はどれか、優先的に解決すべき課題は何かを明確にしていきます。
とはいえ、本題の「やること」を決めるのはクライアント自身です。PMOの役割は、「これをやるなら、このくらいの作業期間やリソースが必要」と「スコープを決める」ことにあります。要件案が出たら、「この案は現実的に実行可能か？」「必要な予算や人員は？」といった選択肢をPMOが整理することで、クライアントは適切な判断ができるのです。
例えば、「半年以内に実現したいA案」を検討する場合。PMOが「それならば、人員を十人追加する必要があります」と、具体的な数字を提示できたならどうでしょう？クライアントは「そこまでリソースを割けないから、A案は見送ろう」あるいは「重要な案件だから、予算をかけてでも取り組もう」など、優先順位を付けやすくなるでしょう。
要件定義を進める過程で、さまざまな意見やアイデアが出てきます。中には、残念ながら「非現実的」あるいは「優先度が低い」などの理由から対象外となるものも出てくるでしょう。しかしそれは今回は見送られたとしても、別プロジェクトや会社の状況が変われば対象になる可能性も十分あります。ぜひ捨てることなく、次回以降に引き継ぎましょう。
「やること」が決まれば、次に考えるべきは「それをどう進めるか」で、これこそがプロジェクトにおける「管理」です。
プロジェクト全体を通して、「いつまでに」「誰が」「どのように進めて」「どのように完了・承認するか」を設計、実行するための枠組みをつくるのです。進行管理はもちろん、スムーズな承認フローの設計や情報共有の仕組みづくりなども、管理の領域に含まれます。
ただし、単に「◯月×日までに△△の作業が終わればよい」といった期日管理のみをするのはダメPMOと言わざるを得ません。そうではなく、デキるPMOは、「期日内に完了するために必要なステップ」までしっかり決めて管理することが大事なのです。
例えば、「どのように完了・承認とするか」なら、「作業終了 → 報告 → 有識者のレビュー → レビュー結果反映 → 正式な完了」といった流れを明確に決定し、関係者全員が共通認識を持てるようにするまでがPMOの仕事です。
（レビュー結果反映の期間を見積もらずに、「期限に間に合いませんでした」といったケースは多いです）
「管理」のフェーズでデキるPMOが意識している二つのポイントを紹介しましょう。
管理を行う際に重要なのは「とにかくプロジェクトを前進させること」です。例えばPMOによっては、「作業終了 → 報告 → 有識者のレビュー → レビュー結果反映 →正式な完了」と流れを決めると、「この流れを完璧に守らねば」と思ってしまう人もいます。
しかしそれだと、もし有識者が一人しかいない場合、レビューが集中して流れが滞ることもありますよね。その場合、プロジェクトを停滞させないため臨機応変に流れやルールを「あえて変える」選択をするのも、管理の一部なのです。
ちなみに私なら、有識者レビューは当初のフローには含めず「作業完了」まで行い、その後、有識者レビュー、指摘修正を行うというタスクの組み換えを検討すると思います。
過去に私が参画したある案件では、PMが独断でシステムの仕様を決めた上に、各々のタスクなど情報共有がしっかりされないままプロジェクトが始動したことがありました。その結果、多くの関係者が「私は何をすればいい？」「今どういう状況ですか？」と不安を抱え、作業が進まない事態に陥ったのです。
別の案件では、情報共有の手段が月に一度の全体会議しかありませんでした。そのため、会議には毎回関係者全員が三〜四時間も拘束され、本来業務に注力できないばかりか、各チームから報告される内容は違うタスクや方向性の違う作業を行っていたという、非生産的な状況でした。
どちらのケースでも私が行ったのは、「決定事項を周知するための仕組みづくり」です。具体的には、以下の三つを意識しました。
【1】決定・未決事項を「見える化」する
共有の課題管理表で未決事項や達成状況を管理し、決定事項は成果物に反映するなど
【2】決定事項に変更が生じた際の連絡手段の明確化
プロジェクト内Wikiなどへ決定事項を反映し、チャットツールでも全体連絡をするなど
【3】事前にドキュメントで伝え、伝わりにくい内容は会議で周知
会議でいきなり初見や初耳の情報は共有せず、決定事項はまず文書で連絡。その上で、より詳細な説明が必要な場合は会議を実施するなど
他に、「Slack上に確認専用のチャンネルを設ける」、「会議の目的とゴールを事前にクリアにする」、「ドキュメントの格納場所を一元化する」なども効果的です。情報管理の精度がアップすれば、プロジェクト全体の生産性も大きく改善されます。
お伝えしてきたように、優秀なPMOは要件定義と管理を、それぞれ別の工程として考え実行しています。しかし実は、この二つを混同したまま進行しているプロジェクトも数多くあるのです。
では、実際に混同するとどんな困ったことが起きるのか。私がPMOとして関わったプロジェクトの事例をご紹介します。
このプロジェクトは、ライセンスの期限切れを一年後に控えて立ち上がった会計システム刷新プロジェクトでした。当初の計画は「現行と同じ処理ができるシステムに入れ換える」とシンプルなものでした。しかし、要件定義で各所から要望がどんどん出て収拾がつかなくなり、管理もきちんとできていない状態となったため、私にサポートの依頼がきたのです。
事の経緯を確認すると、まず、経理担当者とPMOが話した段階では、刷新後のシステムに必要な勘定科目などしっかり目合わせできており順調だったといいます。しかしその後、合意を得るため経営層に説明すると、「せっかくなら経営判断に役立つ機能を盛り込みたい」と新たな要望が出たのです。たしかに価値のある機能でしたが、本来ならこの時点で当初計画から範囲が広がってしまうため、PMOはあらためて必要人員や納期など見直すべきでした。しかし「では対応しましょう」と二つ返事で受けてしまったのです。
さらにその後、システム部門に説明すると、「そもそも営業管理システムや生産管理システムとの連携は考慮されているか？」という新たな指摘が入りました。「たしかにそれもそうだ」と思ったPMOはこの指摘も「対応が必要ですね」と受けてしまい、要件が当初よりだいぶ増えてしまったのでした。
一見すると、このPMOは、「課題を丁寧に拾い上げながら進行している優秀なPMO」に見えます。関係者も「あのPMOは何でもリクエストに答えてくれてありがたいな」と思うかもしれません。
しかしプロジェクト全体を俯瞰すると、全ての要件を実現しようとするあまり、「それをどう進めていくのか」という管理の観点が抜けています。結局このプロジェクトはスタートしたものの、リソースや納期に限界が生じ、終わりが見えなくなっていました。
そこで状況を改善すべく私がとった対応は、あらためて各部署にヒアリングをしながら「やることを決める」要件定義を行いました。
何百人、何千人とリソースがあるわけでもなく納期も限られているのですから、その中で全てを一度に実現することは難しい。そこを理解いただき、現時点で挙がっている要望に必要なリソースや予算感をお伝えした上で、クライアント自身に、今現実的にできること、最優先すべき要件を判断してもらったのです。
そうしてきちんと要件が定義された後で、「じゃあどのように進めていくか」という「管理」のプロセスに入り、何とか当初予定していた納期を大幅に超過する事なくプロジェクトを終えることができました。
「できる限りの要望に応えてクライアントに喜んでもらいたい」というPMOの気持ちもよく分かりますが、「全ての要件を満たすこと」だけが正解ではありません。
むしろ「今回のプロジェクトのゴールはここなので、この要件は見送ります」と冷静にプロジェクト全体を俯瞰し明確な“区切り”を提案することが、PMOとして果たすべき役割であり、腕の見せ所なのです。
「でもそんなことしたら関係各所から『私たちの意見は反映されていないのか？』と文句を言われそう……」と不安になるかもしれません。ですが、そんな場面こそ、PMOとしての管理能力が問われます。
重要なのは、各所全ての意見を把握していることを前提に、「プロジェクトのゴール、そしてリソースや予算などを考えると、今回取り組むべき要件はこれです。他の意見は次回以降に検討しましょう」ときちんと説明できることです。
そうすればクライアントも、「出した要望は無視されたわけではなく、全体を見据えた上で、今はこの要件に注力するんだな」と納得できるはずです。
関係各所からの要望量が多かったり、重要な要望が先送りされる場合は、３年間、５年間などのロードマップを作成し、段階的に複数のプロジェクトで要望を実現していくような資料を別途作成して、合意を得ることを行います。
私が考える優秀なPMOとは、どんな状況でも「プロジェクトを止めない」PMOです。みんなに好かれようと、寄せられる要望を全て受け入れ、プロジェクトが停滞してしまっては意味がありません。
時には嫌われ役になろうとも、スムーズな進行のために「やらない」判断を下す。それをチームや関係者全員に理解してもらう力があるPMOこそ、真の「デキるPMO」だと思っています。
特に、プロジェクトが大規模、あるいは複雑になるほど、「要件定義」と「管理」の境界線はあいまいになりがちです。プロジェクトに入る際は、両者の違いをしっかり認識し、明確に切り替えながら前進していくことを常に意識していただけたら幸いです。
『DX時代の最強PMOになる方法』
著：甲州潤
▼こんなエンジニアはぜひお読みください。
・今の仕事に不満を持っていて、現状を変えたいと思っている
・給料をアップしたい
・エンジニアとしての将来が不安だ
・キャリアアップをしたいが、何をしたらいいかわからない
・PMOに興味がある
・PMOとして仕事をしたい
【目次】
第1章 一番稼げるIT人材は誰か
第2章 これからはPMOが1プロジェクトに1人必要
第3章 SEとPMOの仕事は何が違うか
第4章 稼ぐPMOになる７つのステップ
第5章 優秀なPMOとダメなPMOの見抜き方
第6章 PMOが最低限押さえておきたいシステム知識とスキル
第7章 システムは言われた通りに作ってはいけない
第8章 どんな時代でも生き残れる実力をつけよう
>>>詳細はこちら
タグ