基幹システムプロジェクトの成功要因を「3つ」に絞ってみた（後編：情シスPMO編）

前回の続きです

基幹システムプロジェクトで絶対に外せないポイントを「3つ」に絞り、整理してきました。

①トップダウン
②ベンダー選定
③情シスPMO

今回は、最後の「③情シスPMO」についてです。

難航しているプロジェクトの特徴

「PMOは設置していません。ベンダーがしっかりしてそうなので、大丈夫だと思いました。まずかったでしょうか？」

ある現場で、総務部長から言われました。基幹システムプロジェクトが難航しています。

プロジェクト途中でご相談をいただいたとき、私が最初に拝見するものがあります。

「プロジェクト計画書」です。

その計画書の体制図を見ると、ユーザー側にはPM（プロジェクトマネージャー）、リーダー、メンバーの名前が並んでいます。情シスも「システムチーム」の名前で入っています。

しかし、そこにPMO（Project Management Office）がありません。

炎上したプロジェクトで、私はこの体制図を何度も見てきました。

「今回、PMOは設置していますか？」

この回答が、冒頭の部長のコメントです。

PMもいる。リーダーもいる。メンバーもいる。ベンダーもしっかりしている。それで何が足りないのか。

部長は不思議そうに視線を私に向けました。

そもそもPMOとは、何をする人なのでしょうか？

PMOは「事務局」ではない

最初に、誤解を解いておきます。

PMOと聞くと、

・会議の日程調整をする事務局
・進捗表を作る人
・議事録を取る係

といったイメージを持たれることがあります。確かに、そのような役割もあります。しかし、それが本質ではありません。

PMOとは、プロジェクトの「プロ」としてPMを補佐します。言い換えると、PMの「右腕」です。

プロジェクトの各局面で、最終的な意思決定をするのはPMです。

一方で、その判断に必要な情報を集め、整理し、選択肢をつくる。関係者と調整して「PMが決められる状態」をつくるのがPMOです。

私は、PMはユーザー部門の責任者が担うべきだと考えています。業務を変える以上、その領域を合理的に判断し、最後の責任を引き受けられる人が必要だからです。部外の人間が判断しても、誰もついてきてはくれません。

しかし、ユーザー部門の責任者には弱点があります。

業務のプロではあっても、必ずしも「ITのプロ」「プロジェクトのプロ」ではありません。しかも、通常業務も抱えています。自分でプロジェクトの全情報を集め、課題を整理し、システムを把握し、ベンダーと調整する時間などありません。

すると、どうなるか。

「ベンダーさん、どうしましょうか」

となります。

判断に必要な情報を持っていないので、ベンダーに提案させるしか方法がないからです。

こうして、発注側の体制図にPMOの箱がないだけで、プロジェクトの主導権は、静かにベンダーへ移っていきます。

この不足を埋める存在。

それが、PMOです。

PMOの「6つの役割」

では、PMOは何をするのでしょうか？　大きく6つあります。

①PMの「意思決定」を成立させる

PMは意思決定者です。しかし、判断するためには、次のことが整理されていなければなりません。

・何が起きているのか
・何が遅れているのか
・どこにリスクがあるのか
・選択肢は何か
・それぞれのメリット・デメリットは何か
・いつまでに決める必要があるのか

これをつくるのがPMOです。

優秀なPMOは、PMにこう言えます。

「3案あります。私はB案を推奨します。理由はこれです。今日、決めてください」

反対に、

「いろいろ問題が起きています。どうしましょうか」

では、PMも判断できません。

PMOは意思決定者ではありません。しかし、意思決定の「品質」と「速度」を大きく左右します。
 

②計画と現実のギャップを埋め続ける

プロジェクトで難しいのは、計画を作ることではありません。計画通りに、進捗を出し続けることです。そのためには、人と組織を動かし続けないといけません。

計画→実行→ズレの発見→修正→再実行

このループを回し続けるのがPMOです。

進捗管理、課題管理、リスク管理、品質管理、変更管理、コスト管理。名前は違っても、基本はすべて「予実管理」です。予定と現実にズレがあれば、原因を突き止め、元に戻す。場合によっては、予定を見直す。

PMOは、現場のペースメーカーです。進捗状況を確認し、止まっているものを動かす。それを毎週、繰り返す。

PMOがいるから、プロジェクトの「予定」を着実に「現実」に変えていけます。
 

③「相互翻訳」し、合意をつくる

ITプロジェクトには、異なる世界の人たちが集まります。

経営、現場、ベンダー。

そして、それぞれ使う言葉が違います。

経営は「経営目標」を語る。
現場は「業務」を語る。
ベンダーは「システム」を語る。

全員が正しいことを言っているのに、話が噛み合わない。それがITプロジェクトです。

だから、PMOには「翻訳者」としての役割があります。しかも、言葉を訳すだけでは足りません。

業務とシステム。
ユーザーとベンダー。
経営と現場。
部門と部門。

利害の異なる人たちの間に入り、合意をつくる。

この「境界を越える力」は、PMOの大きな価値です。
 

④発注側に「主導権」を持たせる

ITプロジェクトでは、放っておくと、ベンダー側が圧倒的な情報優位に立ちます。

ベンダーは、プロジェクトを何度も経験しています。見積もりを知っている。契約を知っている。要件定義を知っている。開発工程を知っている。リスクを知っている。

そして、顧客が何を知らないのかも知っています。

一方、ユーザー企業はプロジェクト経験があまり多くはありません。その部門で行われる大きなプロジェクトは、5年〜10年に一度です。

最初から経験値に大きな差があります。自分たちがやるべきことを把握し、状況を予測できなければ、ユーザー企業は「受け身」になってしまいます。

だからこそ、発注側にもプロジェクトのノウハウが必要です。

RFI、RFP、提案評価、契約、要件定義、変更管理、成果物レビュー、受入テスト、リリース判定。

これらは、発注者側が持つべきノウハウです。

PMOがこれらのノウハウを駆使することで、初めて、自社がプロジェクトの「主導権」を握ることができます。
 

⑤「部分最適」から会社を守る

ユーザー部門のPMは、自分たちの業務を良くしたいと考えます。当然です。しかし、その判断が会社全体にとって最適とは限りません。

・部門ごとに別々のシステムやSaaSが乱立する
・同じデータを複数の部署で重複入力し、管理する
・個別カスタマイズが増え、標準化から遠ざかる
・セキュリティ水準がバラバラになる
・システム連携が複雑になり、運用負荷や保守コストが膨らむ

業務部門のPMには「業務最適」を見る責任があります。一方、PMOには、連携する部門を含めた「全社最適」を見る役割があります。

ここに、情報システム部門（情シス）がPMOを担う理由があります。

情シスは、間接部門として、独立的かつ客観的に業務を俯瞰することができます。システムを導入する主管部門だけではなく、周囲の部門とも連携しながら進めることができます。

ここに、アーキテクチャ、データ、セキュリティ、インフラ、運用、標準化、コスト、技術的負債といった、IT部門ならではの視点が入ります。

前編で、部門をまたぐ全体最適を選べば必ずどこかに痛みが生じるため、最後は経営トップが決める、と述べました。

しかし、その痛みを伴う論点を整理し、選択肢とメリット・デメリットを揃えてステコミに上げる人がいなければ、経営トップは判断のしようがありません。

業務部門のPMが「その業務にとって正しい判断」をし、情シスPMOが「会社全体として正しい判断」になるよう支える。この構造が、会社を部分最適から守ります。
 

⑥会社に「成功の再現性」を蓄積する

PMは、プロジェクトごとに変わります。ユーザーも変わる。ベンダーも変わる。外部のコンサルタントも、いずれいなくなる。

しかし、情シスは残ります。

しかも、システムは本番稼働した瞬間に終わるのではありません。その後、10年、20年と使い続けます。その運用を背負うのも情シスです。

つまり情シスは、

プロジェクト計画→ ベンダー選定→ 開発→ 本番稼働→ 運用→ 次回刷新

というライフサイクルを、唯一つなげられる存在。

だからこそ、やはり情シスがPMOを担うべきです。

前回うまくいったこと、失敗したこと。その経験を会社の資産として残し、次に使うことができます。

情シスPMOは、単発のプロジェクトのみ関わる人ではありません。

「プロジェクト成功の『型』を会社に蓄積し、再現し続ける人」

なのです。

ベンダーPMOと外部PMO

ここで、実務でよくある話に触れておきます。

ベンダーの提案書に添付された体制図を見ると、ベンダー側にも「PMO」が記載されているケースをよく見かけます。

すると、こう思われるかもしれません。

「向こうにPMOがいるなら、ノウハウもあるだろうし、任せてしまってもいいのではないか」

気持ちは分かります。しかし、ベンダーPMOは、ベンダーの立場でプロジェクトを守ります。ベンダー側の契約範囲を守る。工数を守る。利益を守る。

つまり、発注側を守る人ではありません。

では、外部のコンサルタントがPMOを担う場合はどうでしょうか？

こちらは、立場が違います。発注側に立ち、発注側の利益を守ります。私自身、そのために呼ばれ続けてきました。

ただし、別の限界があります。

外部から情シスPMOを支援してきた私が言うのも変な話ですが、外部PMOは、あくまで期間限定の存在です。プロジェクトが終われば、契約も終わり、いずれ去っていきます。

だから、最後は自社が引き継ぎ、担わなければなりません。

その役割に最も適しているのが、やはり情シスです。

ITという専門性を持ち、特定部門に属さず、会社全体を見ることができる。プロジェクト終了後も、会社に残り続ける。次のプロジェクトにもアサインされる。

だから私は、PMOは情シスが担うべきだと考えています。

情シスにとって最も高いハードル

ここまで良いことばかり書いてきましたが、PMOは決して楽な仕事ではありません。

まず、必要なスキルは4つあります。

・プロジェクト管理
・ファシリテーション
・プロジェクトノウハウ
・業務知識

最初の3つは、ここまで説明してきたPMOの役割そのものです。プロジェクトを経験すれば、少しずつ身につけていくことができます。

問題は、4つ目の「業務知識」です。

これは、情シスにとって、最も高いハードルといえます。

情シスはITには詳しくても、現場業務を実際に担当しているわけではありません。そのため、業務フロー、業務マニュアル、帳票、各種資料を読み込み、地道に理解していくしかありません。

しかし、ドキュメントを読むだけでは十分ではありません。書かれていないルール、例外処理、現場の判断基準。分からないことがあれば、現場の担当者に頭を下げて教えを乞う。その繰り返しです。

そして、やっかいなことがあります。

覚えるべき業務が、毎回変わるのです。

販売管理、生産管理、会計、人事、購買、営業。システムがカバーする範囲によって、対象となる業務は毎回異なります。前回のプロジェクトで必死に覚えた業務知識が、次のプロジェクトでは使えない、ということが普通に起こります。

プロジェクト管理やファシリテーションは、一度身につければ次に使えます。しかし業務知識だけは、プロジェクトごとにゼロから積み上げ直すことになります。

情シスは、他にも多くのタスクを抱えています。業務把握のための時間を捻出するのは、本当に大変です。時間が取れたとしても、定時後の夜遅い時間になることも珍しくありません。

それでも、歯を食いしばって、業務に寄り添う。

ここで「業務は情シスの専門外だから」と線引きをした瞬間、情シスPMOは信頼されなくなります。

正論だけでは進まない

これらのスキル以外にも、重要な要素があります。

プロジェクトでは、人間同士の利害がぶつかるからです。

正論だけでは進みません。泥臭い調整も必要です。ときには反対され、厳しい言葉を浴び、板挟みになることもあるでしょう。

こうした困難を乗り切るために、助けになる考え方が2つあります。

1つは「好奇心」です。

PMOだからといって、プロジェクトのすべてを自分の責任として背負う必要はありません。

それよりも、

「なぜ、こんな問題が起きているのだろう」
「現場では、何に困っているのだろう」
「この業務は、どういう仕組みになっているのだろう」

と、興味を持って首を突っ込む。

そのくらいの感覚でよいと思います。

好奇心があれば、自分の担当範囲に線を引かず、自然と業務部門との会話も増えていきます。

本人は「知りたいから動いている」だけでも、周囲から見れば「自分たちの課題を自分事として考えてくれている」と映ります。

そして、業務部門からは「一緒に考えてくれる仲間」として信頼されるようになります。

背負い込むのではなく、興味を持って首を突っ込む。

PMOには、そのくらいの距離感がちょうどよいのだと思います。

もう1つは「鈍感力」です。

PMOは、必ず「板挟み」になります。現場から反発され、ベンダーから抵抗され、経営から厳しい言葉を浴びることもあります。

しかし、それらをすべて自分への攻撃だと受け取る必要はありません。

「自分が怒られている」のではなく、「プロジェクトを代表して、いったん受け止めている」と考えるのです。

受け止める。でも、真に受けすぎない。

必要な意見だけを拾い、残りはPMOというフィルターを通して流してしまうくらいで構いません。

そして少し距離を置いて「この人は、なぜこれほど怒っているのだろう」と相手の立場から考えてみる。

怒りの背景が見えてくれば、「この人も大変なんだな」と思えるようになります。そうすると、感情に巻き込まれず、相手にも自然と寄り添えるようになります。

一歩踏み込む力と、上手に受け流す力。

この2つが、PMOとして困難な局面を乗り切る助けになります。

PMOだからこそ得られるもの

ここまでPMOの大変さを書いてきましたが、それでも私は、この仕事が大好きです。

一番うれしいのは「ありがとう」と言ってもらえること。

現場からは「本当に業務が楽になりました。ありがとう」。

ベンダーからは「ユーザーとの間に入ってくれたから、最後までやり切れました。本当に感謝しています」。

経営層からは「任せてよかった。ここまでまとめてくれて、ありがとう」。

プロジェクトが終わったとき、立場の違う人たちから、そんな言葉をかけてもらえる。

自分がこのプロジェクトに必要だったこと、自分の仕事が誰かの役に立ったことを、心の底から実感できる瞬間です。

そうした経験を重ねると、情シスを見る周囲の目も変わってきます。単にシステムを管理する人ではなく、会社を一緒に動かす人として頼られるようになる。

頼られれば、その期待に応えたくなる。「やらされる仕事」ではなく、「自分からやりたい仕事」が増えていきます。

もちろん、プロジェクトの最中は苦しいこともあります。意見がぶつかり、関係者と対立することもあるでしょう。

しかし、不思議なもので、本気でぶつかり合い、一緒に困難を乗り越えた人とは、プロジェクトが終わった後に強い絆が残ります。「あのときは大変だった」と笑い合える、いわば「戦友」です。プロジェクトを経験するたびに、そうした仲間が社内外に増えていく。

そして、自分自身も成長します。人を動かす力、話を聞く力、合意をつくる力、経営に説明する力。もちろん、新たなアーキテクチャや技術も習得できます。プロジェクトを一つ乗り越えるたびに「次はもっと上手くできる」という実感と自信が積み上がっていきます。

私は、PMOという仕事は、情シスにとって一つの「到達点」だと思っています。

ITはあくまで武器です。その武器を使いながら、経営、現場、ベンダーをつなぎ、人を動かし、会社を前へ進める。それは、単なるIT人材ではありません。

企業を変革へ導く「リーダー」です。

情シスPMOは、どう育てればよいのか

では、情シスPMOは、どうやって育てればよいのでしょうか？

最初から完璧なPMOを目指す必要はありません。順番があります。

1.体制図に「席」を作る

まず必要なのは、プロジェクトの中に「情シスPMO」の席を作ることです。

情シス責任者が経営層や業務部門と話をつけ、プロジェクト体制図にPMOの箱を作る。そこに、情シスの名前を入れる。すべては、ここから始まります。
 

2.議事録から始める

席を確保できたら、次は人です。

経験がなければ、最初は議事録係でも構いません。

議事録を作るためには、会議の内容を理解しなければなりません。すると、少しずつ業務が分かってきます。やがてアジェンダを作れるようになる。アジェンダを作れば、会議進行を任されるようになる。

すると、進捗管理や課題管理にも関わるようになり、関係者との接点が増えていきます。ステコミ資料を作るようになれば、今度は経営層との接点も生まれます。

このように「影響の輪」を少しずつ広げていけばよいのです。

PMOは、勉強してからなる仕事ではありません。

PMOをやりながら、PMOになっていくのです。
 

3.業務に首を突っ込む

同時に、業務にも積極的に首を突っ込んでください。

進捗管理や課題管理は、そのための絶好の口実になります。To-Doの確認という名目で、業務メンバーと話す機会が毎週生まれるからです。

そこで、分からないことを遠慮なく聞く。

「この帳票は、誰が何に使っているんですか」
「○○○って何のことですか」

最初は的外れな質問でも構いません。私はよく「勉強不足ですみません。教えてください」と頭を下げに行きます。すると、大抵は丁寧に教えてくれます。むしろ、真剣に聞いてくる人を、現場は嫌いません。

やがて、業務部門から

「よく知ってるね」

と言われるようになったら、しめたものです。その頃には相談されることが増え、信頼関係も大きく変わっています。
 

4.「型」を残す

そして、あとはプロジェクトをひたすら経験することです。

プロジェクト計画書、課題管理表、リスク管理表、ステコミ資料、RFI、RFP、提案評価表、リリース判定基準・・・。

プロジェクトを一つ経験するたびに、こうした成果物が残ります。「ノウハウ蓄積」と表現すると大変そうに聞こえますが、意識しなくても、ドキュメント自体が立派なノウハウとして、自動的に蓄積されていくのです。

また、優れたベンダーやコンサルタントと仕事をすれば、その成果物もまた、次のプロジェクトで使える立派な「型」になります。

過去のプロジェクトから似た成果物を探し、少し改良して次に使う。ゼロから作る必要はありません。経験を重ねるほど、仕事は速くなり、品質も上がっていきます。

型をつくり、最初の一人を育てる段階では、コンサルタント等の外部PMOと並走するのも有効です。PMOのノウハウは、横で見て、要領を盗むのが一番早いからです。

外部PMOは、使い倒して、去らせてください。

ノウハウを情シスに残し、次のプロジェクトは自分たちで回す。さらに次は、もっと上手く回せるようになるはずです。

経営の意思を現実に変える仕組み

最後のまとめです。

基幹システムプロジェクトを成功させるために、絶対に外せないものは3つです。

①トップダウン
②ベンダー選定
③情シスPMO

私は、この中でも「③情シスPMO」が最も重要だと考えています。

なぜなら、トップダウンを機能させたり、正しいベンダー選定を実行したりするためのノウハウを持ち込めるのが、情シスPMOだからです。そして、その経験を会社に残し、次のプロジェクトへつなげていくのも情シスPMOです。

そして、この力が求められるのは、基幹システムプロジェクトだけではありません。

経営戦略と深く結びついた「DXプロジェクト」でも、経営肝いりの「事業変革プロジェクト」でも、経営・業務・ITをつなぎ、プロジェクトを前へ進める情シスPMOは、中心的な役割を担うことができます。

情シスPMOの価値は、これからますます高まっていくことでしょう。

貴社のプロジェクト体制図に「情シスPMO」はありますでしょうか？

 

この三部作が、貴社の基幹システムプロジェクト成功の一助になれば幸いです。