PMO（プロジェクトマネジメントオフィス）を生かす_7

第61回 「嘘ではないが，真実でもない」報告を見抜くには

進捗会議において、すべてが順調であるかのような進捗報告の信ぴょう性を確認せず、すべての報告を鵜呑みにしてはいないだろうか。世の中、「嘘では ないが、真実でもない」という報告がまかり通っている。今回は、進捗報告においてプロジェクトマネジャやPMOが「進捗の真実を見抜くためのポイント」に ついて考えたい。

後藤 年成
マネジメントソリューションズ マネージャー PMP

 

　プロジェクトマネジャあるいはPMOの立場で進捗会議に参加する場合、皆さんはどのような姿勢で進捗会議に臨んでいるでしょうか。一般に進捗会議には、下記のような大きな目的があると思います。

（1）プロジェクトの進捗状況の共有（上位者および上位組織への報告）
（2）遅延しているタスクに対する対策の妥当性の確認
（3）複数のチーム／プロジェクトをまたがる問題の調整
（4）プロジェクトの進捗を妨げる、問題の発見、課題やリスクの解決

　この目的を達成するために、筆者が進捗に際して心がけている姿勢は、次のような点でしょう。

（a）言いにくいことを言いやすくする雰囲気づくり
（b）報告内容は性悪説を前提に聞く
（c）評論家にならず、解決につながるような提案をする

　この3つの点で、筆者が一番重要視しているのは何か、お分かりでしょうか。それは、「報告内容は性悪説を前提に聞く」という点です。その理由は、報告する立場になって考えてみるとよく分かります。

　進捗を報告する方としては、「少しでも問題がないように報告したい」「無難に進捗会議を済ませたい」という心理状態になっていると思います。報告する立場になったことがある方は心当たりがあると思いますが、「嘘ではないが真実でもなく、根拠がない楽観的な報告」をしてしまいがちです。

　例えば、報告書に「あるタスクが10日遅延している」と記載されていたとします。その際、プロジェクトマネジャやPMOが「このタスクは10日遅れてい るが、キャッチアップできますか？」と指摘したことに対して、報告担当者が「メンバーが残業と休日出勤で対応するので問題ありません」と答えたとします。

　当然ながら、ここで報告者の言葉を鵜呑みにすべきではありません。

• 遅れているのは本当に10日なのか？（根拠は？）
• 残業や休日出勤でカバーするという対応は本当に正しいのか？（根拠は？）
• 遅れの対応によって他のタスクが遅延しないのか？（根拠は？）

　このように問い返し、『進捗報告に根拠がないことを証明し、担当者に正しい現状を認識させる』ことが重要だと考えているからです。

　もちろん、前述したとおり「遅延の原因は誰なんだ！」というような犯人探しをして、悪いことを言いにくくする雰囲気を作るのはNGです。さらに言えば、解決につながるような提案ができなければ、“進捗にケチをつけるだけの嫌な人”になってしまいます。

嫌われても、「都合のいい根拠」を打ち砕け

　このような姿勢で進捗会議を続けていると、報告者は進捗報告に際して、根拠をもって報告するようになってきます。「正しい」根拠をもって報告をすることは、とても重要なことです。

　しかし、ここに大きな落とし穴があります。それは、報告者は「都合のいい根拠」を集めるようになる恐れがあるのです。

　ここでPMOは、あえて嫌われ役になる必要があります。つまり、「都合のいい根拠」を覆す「都合の悪い根拠」を探して、やはり『進捗報告に根拠がないことを証明し、担当者に正しい現状を認識させる』ことをしなければならないのです。

　例えば、品質に問題があるとき、担当者はある品質の良い部分の根拠だけを提示して「品質が良いから問題ない」と主張するかもしれません。しかし、よく考えてみれば分かることですが、成果物の一部が良いからといって、全体の品質が良いという証拠にはなりません。

　また、進捗の遅れが発覚した時、ある担当者は「スケジュールに余裕があるので、問題ない」と主張するかもしれません。しかし、そのスケジュールは勝手にリスケジュールされた後のスケジュールなのかもしれません。このようにPMOは常に「この根拠の真実は何か？」を念頭において進捗を分析する必要があるのです。

「嫌われ役」と「献身的な味方」の役割分担が決め手

　ただし、このように性悪説に基づいた進捗会議ばかり繰り返していると、PMOはメンバーから“総スカン”をくらってしまうでしょう。孤立してしまう危険性もあります。

　そこで必要なのは、PMOの内部での役割分担です。PMOメンバーのうち1人は、前述のように多少嫌われても「プロジェクト成功のために嫌なことを言 う」役割を演じる。一方、ほかのメンバーは献身的にプロジェクトメンバーの相談に乗ったり、進捗報告の後で一緒に対応策を考えたりするなど、メンバーの味方役を演じる（というか、それが本来の仕事ですが）。そうした役回り・機能を持つことで、組織的にプロジェクトの問題をあぶり出し、プロジェクトを推進さ せることができるのです。

　もちろん、プロジェクトのために、進捗会議では少々嫌なことを言わなければならないと理解してくれるメンバーもいます。進捗会議において、先に述べたと おり「個人を責めない」「批判ではなく建設的な意見を言う」ことを心がけていれば、メンバーも必ず理解してくれることと思います。

第62回 トラブル対応に必要な“余裕”をどう作る？

第22回の『PMOは火消しの「遊軍」たれ』 で述べたように、不測の事態に即時対応できるよう、PMO（あるいはプロジェクトマネジャ）は常にある程度の余裕を持っているべきだ。それでは、PMOは どのように余裕を作り出せばよいのか。今回は、PMOが余裕を作り、本来PMOがすべき仕事に時間を割くにはどうすればよいのかを考えてみたい。

後藤 年成
マネジメントソリューションズ マネージャー PMP

 

　PMOは、進捗報告書のとりまとめやプロジェクトの課題管理など、それなりのルーティン業務を持っていることと思います。PMOが“余裕”を作り出すためのポイントは、ルーティン業務を徹底的に自動化することです。

　多くのプロジェクトでは、進捗管理や課題管理などにMicrosoft OfficeのWordやExcel、Outlook、Projectなどを利用していることと思います。これらのツールには、ルーティン作業を自動化するために便利な「関数」や「マクロ」といった機能があります。重要なことは、最初は多少工数をかけてでも、これらのツールを駆使するために徹底して自動化 を進めることです。

　自分でマクロなどを組むのが苦手な方も、少し勉強すればすぐに慣れます。「いまさらマクロなんて」と抵抗のある方は、ツール作成の部分を他の人に依頼してもいいと思います。大抵、マクロが得意なメンバーはプロジェクトに1人ぐらいはいるものです。とにかく、「徹底的」に作り込むことが重要です。

PMOとしての存在価値を間違えるな！

　例えば、私が実際に在籍したあるプロジェクトでは、進捗管理に関して下記の11種類の資料を取りまとめて、1つの進捗資料を作っていました。

（1）進捗アジェンダ
（2）前回の議事録
（3）マスタースケジュール
（4）各チームのWBS
（5）各チームの進捗報告書
（6）課題一覧
（7）課題解消状況のグラフ
（8）変更管理一覧
（9）各チームごとの変更管理状況のサマリー
（10) テストの障害状況（障害数や障害解消数などのグラフ）
（11) テストの進捗状況（テストケース消化数や残ケースのグラフ）

　進捗会議の準備をしたことのある方はすぐ分かると思いますが、上記の資料を取りまとめたり、グラフを作成したり、印刷やホチキス止めなどをしたりすると、場合によっては半日以上の時間をとられてしまいます。当時の進捗会議の準備担当者は、毎週の準備に半日以上かけて取り組むことが自分の仕事だと思い込 み、それを自慢にさえ感じていました。

　この作業が1回きりであるならば仕方がないでしょう。しかし、毎週の進捗会議のたびに半日も時間をとられるのでは、生産性の低さから見てたまったものではありません。

本当にPMOにしかできないことか？

　筆者からみれば、これはPMOの仕事でもなんでもありません。上記の例で言えば、PMOの仕事は徹底的に自動化して生産性を上げ、誰でも同じ準備ができ るようにすることなのです。理想を言えば、マクロのボタンを一押しすれば、進捗報告に関するすべての資料が取りまとめられ、必要な部数が印刷される状態です。「ボタン一押し」は言い過ぎかもしれませんが、実際にルーティン作業を自動化した結果、半日かかっていた作業は1時間もかからずに完了できるようになりました。次のページに、進捗会議資料の自動作成例をまとめました。参考にしてください。

　進捗管理資料の準備は、PMOとしての重要な仕事には変わりありません。しかし、進捗について言えば、PMOとしての存在意義は決してきれいに進捗資料 を一式印刷することではありません。「PMO以外の人間でもできる仕事を極力減らすこと」です。例えば、進捗報告に記載された問題を一緒に解決していくことなど、「PMOにしかできない価値を提供すること」にあるはずです。

ツールを部品化して蓄積する

　ツールを作成して自動化する際に気をつけたいポイントは、「ツールを作ること自体を省力化すること」です。例えば、「他のプロジェクトで利用している便 利なツールはないか？」「過去に作ったツールは再利用できないか？」など、極力ツールを作る時間を短くし、ツールを作ること自体が目的化しないように注意しなければなりません。そのためにも、プログラムマネジメントオフィスや標準化推進などの組織が、現場のプロジェクトと連携して様々なツールを収集・部品 化し、プロジェクトに公開するなどの取り組みがあると望ましいでしょう。

　自戒の意味も込めて言えば、ルーティン業務で一杯いっぱいになり、周囲から「PMOは一体何をやっているのか分からない組織だ」と言われないようにしなければなりません。そのためには、「PMOとして提供できる価値は何なのか」を常に問いかけて仕事をしていきたいものです。

進捗会議における資料作成の自動化例

下記（1）～（12）までを自動化するツールを作成した。

（1）進捗アジェンダ
　前回の内容を自動的にコピーする。
（2）前回の議事録
　配布した議事録を自動的に進捗管理フォルダにコピーする。
（3）マスタースケジュール
　最新版のフォルダから自動的に進捗管理フォルダにコピーする。
（4）各チームのWBS
　Microsoft Office Projectで管理している各チームのWBSを1つのWBSに自動的に統合する。
（5）各チームの進捗報告書
　各チームの進捗報告書を1つのファイルに自動的に結合し、進捗管理フォルダにコピーする。
（6）課題管理一覧
　最新の課題管理一覧を自動的に進捗管理フォルダにコピーする。
（7）課題解消状況のグラフ
　Excelで管理している課題管理一覧から、各チームの課題管理状況（課題管理ステータス、新規発生数、完了数）のグラフを作成する。
（8）変更管理一覧
　最新の変更管理一覧を自動的に進捗管理フォルダにコピーする。
（9）各チームごとの変更管理状況のサマリー
　Excelで管理している変更管理一覧から、自動的に各チームの変更管理状況（変更管理ステータス、新規発生数、完了数）のグラフを作成する。
（10）テストの障害状況（障害数や障害解消数などのグラフ）
　Excelで管理している障害管理一覧から、各チームの障害管理状況（障害管理ステータス、新規発生数、完了数）のグラフを作成する。
（11）テストの進捗状況（テストケース消化数/残数のグラフ）
　各チームのテスト進捗状況の管理表から、サマリー表を作成する。
（12）印刷
　進捗管理フォルダにあるドキュメントを順に印刷する。

63回 リスク管理がうまくいかない7つの理由（前編）

プロジェクトマネジメントの中で「重要だと知りながら、うまく実践できていないこと」の筆頭にあるは「リスク管理」だろう。取り組んだとしても、プ ロジェクトの初期にリスク管理表を作っておしまい、というケースが多すぎる。これでいいはずはないが、一体なぜ、そうなってしまうのか。

後藤 年成
マネジメントソリューションズ マネージャー PMP

 

　PMBOOKやプロジェクトマネジメント研修、書籍などで学習したことがある方は、必ずと言っていいほど「リスク管理」の重要性について語ります。それは皆さん周知のことでしょう。プロジェクトマネジャやPMOにとって、リスク管理は疑いなく重要な責務の1つです。

　しかし、リスク管理の重要性について、頭では重要だと分かっていても、プロジェクトの現場ではなかなか真剣に取り組めていないのが実情でしょう。筆者の経験から言って、名だたるシステム・インテグレータや大手企業であっても、PMBOKやプロジェクトマネジメントの書籍通りに、まじめにリスク管理を実施できている現場はほとんどありません。今回は、なぜリスク管理にまじめに取り組まれないのか、その理由を探っていきたいと思います。

　さて、リスク管理がうまくいかない理由として、会社の文化や業界の慣習、さらに言ってしまえば日本の国民性など、さまざまな原因を挙げることができます。これはこれで議論に値するテーマではありますが、ここでは「なぜ現場でリスク管理がうまくいかないか」というミクロの視点で考えてみたいと思います。 筆者の経験から、次の7つの理由が考えられます。

［理由1］リスクは一意に特定、定義できない
［理由2］リスク管理のやり方が分からない
［理由3］標準タスクだからやるのであり、裏を返せば「やらされ感」がある
［理由4］リスク管理の成果が見えない
［理由5］メンバーにとっては余計な負担
［理由6］管理者にとっては、本当にやる意義があるのか確信が持てない
［理由7］“作りっぱなし”の最たるもの

 

　上記の7つの理由は、最初の2つの技術的な理由と後の5つの心理的な理由に大きく分けることができます。それでは、それぞれの理由についての詳細を考え てみましょう。コラムにおいては解決策までは記載しませんが、他に理由はないのか、あなたならどうするか解決策を考えながら読んでみてください。

［理由1］リスクは一意に特定、定義できない

　最初の理由は、そもそも「リスクとは何か分からない」という理由です。PMBOK（第3版）ではリスクを『もし発生すれば、プロジェクト目標にプラスあるいはマイナスの影響を及ぼす不確実な事象あるいは状態』と定義しています。

　皆さんの現場で「このリスクの定義に従ってプロジェクトにある一番大きなリスクを1つ挙げてください」と問いかけたとしたら、どうなるでしょうか。おそ らく10人が10人とも同じリスクを挙げることはまずないと思います。なぜならば、その人の立場や視点、今までの経験、あるいはプロジェクトにかける思いや生まれ持った性格によって、リスクの捉え方が違うためです。

　この、一意に特定できないリスクの性質が「管理」のハードルを高くしています。ただ単に「プロジェクトが遅延するリスク」と言ってもさまざまな原因が考えられますし、そのどれもが100％正しくもなく、100％間違っているとも言い切れません。この特性がリスクを「つかみどころのないもの」にしてしまっているのです。

［理由2］リスク管理のやり方がわからない

　2つめの大きな理由として、リスク管理のノウハウがないという現実があります。品質管理や進捗管理と比べれば、圧倒的に不足していると言っていいでしょう。もちろん、PMBOKなどの知識体系があり、どんな作業をどのような順番で実施するかまでは記載されています。とはいえ、どうすれば効果的に実施できるかという「How To」の部分は、実際に関与したメンバーの経験として蓄積していくしかありません。

　つまり、知識として「何をすればよいか知っている」ということと、実作業として「滞りなく効果的に実施できる」との間には大きな溝があるのです。リスク管理の「How To」本はたくさん出ていますが、書籍どおりに実施できず頓挫してしまうのはそのためです。

　上記の2つのできない理由は、どちらかというと知識やHow Toなど、テクニック的な面が強いものです。だが、本当にリスク管理が定着しない理由は、［理由3］～［理由7］の心理的な要因が大きいと筆者は考えています。

第63回 リスク管理がうまくいかない7つの理由（前編）

［理由3］標準タスクだからやるのであり、裏を返せば「やらされ感」がある

　筆者が今まで経験した現場で、「リスク管理」を実施する理由の一番は「社内標準で決められているから実施しなければならない」という、なんとも後ろ向きな理由でした。筆者が実際に経験した話をしましょう。あるフェーズの最後になって「社内標準で決められたリスク管理表を作っていない、と社内の品質管理担 当部門から叱られた。次のフェーズに進めないから作っといて」ということもありました。

　このように、「未来に発生するリスクに対して事前に対処する」という主体的な行為・目的とはほど遠く、後ろ向きな動機でリスク管理を実施しても「リスク管理表を作ることが目的」となってしまいます。「形式的に作る」だけであれば、リスク管理表を作る負荷だけが増えてしまい、プロジェクトにとって何のメ リットもありません。

　案外、このような現場が多いのではないでしょうか。

［理由4］リスク管理の成果が見えない

　リスク管理が他のタスクと大きく異なる点は、「起こるかもしれないこと」に対しての予防的な作業だという点です。この特徴のせいで、リスク管理の成果が見えづらいことがあります。

　極端な話、そのリスクが顕在化しなければ、予防のために実施した作業はスポットライトを浴びることがありません。誰にもリスク管理の成果を評価してもらえないのです。

　自分が実施した作業の成果が見えない、あるいは成果となって実現しないかもしれないのであれば、他の作業と比べてリスク管理の優先順位は下がります。モチベーションも下がるでしょう。それが現実です。そのためにも、まずはプロジェクト全体としてリスク管理の価値を認めてあげる必要があります。

　ただし、前述したように、リスク管理の作業自体が成果として見えづらいだけに、「価値を認めたくても見えない」というジレンマに陥ってしまうのです。

　今回は、リスク管理がまじめに取り組まれない理由について、前半の4つを見てきました。次回は残りの理由について見ていくことにしましょう。

第64回 リスク管理がうまくいかない7つの理由（後編）

リスク管理の重要性については、頭では重要だと分かっていながらも現場のプロジェクトではなかなか真剣に取り組めていないのが実情だ。前回は、リス ク管理がまじめに取り組まれない理由のうち、前半の4つの理由を見てきた。今回は、リスク管理がなぜ現場でまじめに取り組まれないのか、その残りの理由に ついて考えていきたい。

後藤 年成
マネジメントソリューションズ マネージャー PMP

 

　前回のおさらいとして、リスク管理がまじめに取り組まれない7つの理由を再掲します。下記の7つの理由は、最初の2つの技術的な理由と後の5つの心理的 な理由に大きく分けることができます。今回は、心理的な理由にあたる［理由5］～［理由7］を皆さんと一緒に考えていきましょう。前回と同様、解決策までは言及しませんが、「ほかに理由はないのか」「あなたならどうするか」を考えながら読んでみてください。

［理由1］リスクは一意に特定、定義できない
［理由2］リスク管理のやり方が分からない
［理由3］標準タスクだからやるのであり、裏を返せば「やらされ感」がある
［理由4］リスク管理の成果が見えない
［理由5］メンバーにとっては余計な負担
［理由6］管理者にとっては、本当にやる意義があるのか確信が持てない
［理由7］“作りっぱなし”の最たるもの

 

［理由5］メンバーにとって、リスク管理作業は余計な負担

　一般的にリスク管理は、事前にリスクを洗い出してそのリスクに対する予防策を考えます。しかし、そのリスクの予防策を実施するメンバーにとっては、新しいタスク（負担）となってしまいます。

　しかも、リスク予防のために実施するタスクは、プロジェクトに必要な成果物に直結しません。さらにリスク管理というのは、前回の［理由4］でも述べた通 り「成果が見えづらい」という特徴があります。リスクの予防策の実施を任された担当者にとっては、目の前のアウトプットがはっきりしている作業を優先しがちです。

　また、リスク予防策はそれ自体実施しなくても、目に見えて進捗が遅れるといった実害がありません。「まぁ、時間があるときに実施しよう」という誘惑にとらわれてしまいます。普通、リスク対応は「緊急でないけれど、重要な事項」に分類されます。担当者が「緊急でないけれど、重要でない事項」と勝手に重要度 をすり替えてしまわないよう、リスクに対する予防策の重要性、すなわち「リスクの予防策を実施することは重要なタスクなんだ」という意識をしっかりと持ってもらう必要があります。

［理由6］管理者にとっては、本当にやる意義があるのか確信が持てない

　リスク管理を推進するPMOとしての立場で、リスク管理を見てみると［理由5］で述べたように目の前の作業に追われているメンバーに向かって「リスク対応の計画を立ててください」とか「リスク対応が進んでないので計画通り実施してください」とはなかなか強く言えません。筆者もリスク管理者として「今、こ の忙しい時期に、本当にリスク対応なんかをやるべきなんだろうか？」と自信が揺らぐ経験を何回もしています。

　しかし、結果論ではありますが、今思い返してみれば、「あの時リスク対応をしていれば、トータルでスケジュールが遅延せずに済んだし、余分なコストを抑えられた」と後悔することがあります。

　例えば、「要件定義フェーズで確定した要件が設計フェーズで変わる危険性がある」というリスクがありました。その予防策として、「要件定義フェーズの最後に全体の要件を横串で確認する全体確認会を開催し、要件の漏れを防ごう」という対策を計画しました。しかし、要件定義フェーズが遅れ、全体確認会を開催 する時間的余裕がなくなり、計画した予防策は実施しませんでした。

　その結果はどうだったでしょうか。案の定、設計フェーズにて機能間の連携が取れていないことが発覚し、設計フェーズが3カ月延期になりました。リスク予防策を実施するための1週間を惜しんだばかりに、3カ月の遅延を招いてしまったのです。

　万が一、リスク予防策を実施していたとしても、それなりの不整合が発生したかもしれません。それでも、3カ月も遅れることはなかったはずです。

［理由7］“作りっぱなし”の最たるもの

　重要な資料でありながら、リスク管理表ほど「一度作ってしまうと見向きもされない管理資料」はないかもしれません。理由は、リスク管理表を作った経験のある方なら、すぐに思いあたると思います。「リスク管理表を作ったことで満足してしまう」からです。

　本来のリスク管理は、リスクを抑えるために「予防策を推進していくこと」が重要です。しかし、その目的はあっという間に忘れ去られ、リスク管理の第一歩に過ぎない「リスク管理表を作ること」が目的化してしまいがちです。

　リスク管理表をレビューする上位者も、管理表に記載されているリスクや予防策のその後をモニタリングしている方は、実際のところ、ほとんどいません。あ んなに一生懸命リスクを洗い出し、予防策を考えて一覧化したのに、それを取りまとめた瞬間に満足してしまっているのです。

　また、［理由3］でも述べたように、多くの会社では、社内の品質管理標準でリスク管理表を作ることを義務付けているだけです。その後の予防策の実施状況や新しいリスクの発見といったモニタリング作業まで、きちんと定義している会社は案外少ないのです。

　まして、［理由4］～［理由6］で見たように、リスク管理表を作ることでさえ多大な労力や気苦労が要るものです。そんなリスク管理をプロジェクトの最後まで継続していくには、よほどリスクを重要視する文化や危機感がなければ実行できません。

　「リスクが取り除かれるまで、ずっとモニタリングしなければならない」というこの継続性がリスク管理のハードルをまた高くしています。［理由5］で述べ た「緊急ではないけれど、重要な事項」であるリスクを、プロジェクトの期間中ずっと見続けるのはいかに根気と労力のいることか、経験者には分かっていただけることと思います。

現場の実情に沿った解決策を考えてみよう

　今回は、なぜ重要だと認識しつつリスク管理が現場でまじめに取り組まれなくなってしまうのかを考えてきました。各理由を反面教師として見て頂ければ、解 決策はいくつか浮かんでくると思います。筆者の経験から言うと、リスク管理ほど「管理担当者（プロジェクトマネジャやPMO）がリスク管理を完遂するん だ」という「強い意思」とメンバーを説得するための「根気」、さらに「トップマネジメントの強力なサポート」が必要な作業はありません。

　そして、間違いなく言えることは、リスク管理を徹底的に実施すれば、プロジェクトの成功確率は間違いなく高まるということです。今回のコラムがリスク管 理担当者（PMO）に対するプロジェクトメンバーの理解と皆さんの現場におけるリスク管理定着化の手掛かりになればと思います。

　今回は、皆さんに自らリスク管理のあり方を考えていただきたいため、意図的に解決策までは踏み込みませんでした。7つの理由に対する解決策については、いずれ別の機会に筆者の考えを書いてみたいと考えています。

第65回 保守・運用を適切にマネジメントする「仕組み作り」

システム関連のプロジェクトにおいて、PMO（プロジェクトマネジメントオフィス）の活動範囲は、必ずしもシステムを稼働させるまでのフェーズだけではない。とかく後手に回ったり、属人的になったりしやすい保守・運用フェーズにおいても、PMOのマネジメント能力を生かせる場がある。

長谷川 竜
マネジメントソリューションズ マネージャー

 

　一般的にシステムの保守・運用フェーズでは、障害や問い合わせの発生数を最小化し、リソースとコストを最小化することが求められています。あるいは、保守・運用の現場が既存システムの改善や新システムの企画立案をすることで、プロフィットセンター化しようとする動きもあります。

　しかし、現実はどうでしょうか。多くの保守・運用の現場では、まだ十分にマネジメントできているとは言い難い状況です。キーワードを挙げるとするなら、「後手の対応」「情報共有不足」「属人的」といったところでしょうか。今回はこの課題を取り上げ、適切にマネジメントするための仕組み作りについて考えて いきましょう。

問い合わせ発生数を減らすために

　保守・運用フェーズにおいて、システム利用者からの問い合わせ発生数や解消数を把握することは簡単ですが、それが健全なマネジメントの本質でないことはご存知のとおりです。重要なのは、障害の根本原因を追及し、適切な対策をとるための活動を続けることです。

　ただし、問い合わせ発生数を抑えようとする場合、「適切な対策をいつ打つか」という点で、マネジメントのレベルが違ってきます。

　例えば、昨日と今日でユーザビリティが少し違うだけでも、利用者から何件もの問い合わせが発生するかもしれません。また、決算期や繁忙期には、利用者数が通常より大幅に増えたり、日頃は行わない例外的なオペレーションが増えたりして、一時的に問い合わせが増加するものです。

　このような傾向はある程度予測できますが、実際には問い合わせが増加することを黙認していたり、問い合わせが来てから対応するケースが多いのではないでしょうか。ユーザーの満足度や問い合わせ・対応にかける時間コストを判断基準にしないまま、こうした対応を続けることは、適切なマネジメントとは言えませ ん。

　本来なら、問い合わせを発生させないための手を事前に打つべきです。問い合わせの発生数を、年間を通して平準化しなければ、発生数の多い期間に対応できるだけのリソースを準備しなければなりません。問い合わせ数の変動をできる限り減らし、最小限のリソースに抑える努力が必要でしょう。

　適切にマネジメントするには、システムのオーナー（発注者側）が主導的な立場をとり、例えば「問い合わせ発生数○○件以下」といった年間目標を立て、目 標達成に向けたアクションを継続的に実施する必要があります。PMOの役割としては、目標の設定、情報の収集、原因の追及、事後・事前対策の検討、効果測 定をはじめ、これらを実施するための計画立案に主体的に参画し、関係者に働きかけていくでしょう。PMOが得意とする任務です。

障害対応の迅速化、再発防止策の品質アップのために

　繰り返しになりますが、問い合わせやシステム障害の発生・解消数を把握することは簡単です。しかし、稼働してから半年以上経つのに、一向に障害の発生数が減らない、ときには障害が増え続けるケースにさえ出会うことがあります。保守・運用フェーズになると、1件の問題解消にかかるコストが設計/開発フェー ズに比べて増大します。そのコストを削減するための仕組み作りが必要です。

　これも問い合わせ件数をマネジメントする場合と同じように、根本原因を追究し、その原因に対して直接的な対応をとることで再発を防ぐ活動を継続することが基本です。

　ただし、障害への対応は問い合わせのケースとかなり異なる部分もあります。事前に手を打てるタイプの障害は比較的少ないので、障害発生後の復旧の迅速さや再発防止策のクオリティを高める仕組みの巧緻さでマネジメントのレベルが決まります。障害の影響度、同一原因による別の障害の可能性、類似した別の原因 による障害の可能性に目を配りつつ、障害対応時には、プログラムのバージョン管理や、改修によってほかの機能に影響が出るデグレーションを防ぐための対策も考慮しなければいけません。

PMOとしては、1つの障害を取り巻く広範囲の情報を可視化してメンバー間で共有し、適切な対策を検討できる仕組みを導入すべきでしょう。障害の発生から解消までを追跡できるような運営を目指すのが望ましい形です。障害管理や構成管理のツールも多く出ているので、運用現場のニーズに合ったものを導入 してもよいでしょう。

　ツールがなかったとしても、上記のようなポイントを押さえ、障害対応の現場担当者や責任者に的確な情報を報告させ、メンバー間で共有する「習慣」を身に 付けさせることが重要です。テスト・フェーズでも同様の考えが求められますが、テスト・フェーズの障害と稼働後の障害では、その重みが異なります。保守・運用フェーズでは、1つの障害対応をより深いレベルでマネジメントする必要があります。

　よく起こる問題として、設計書の不備やシステムの品質が悪く、対応者や責任者が影響範囲を正確に割り出せないことがあります。この場合、設計書のレベルから見直すなど、時間をかけて粘り強く対応していくことが求められるでしょう。

保守現場の属人化を解消するために

　保守フェーズにおけるマネジメントで悩ましいのは、メンバーが固定化されやすく、システム仕様や障害対応に関するナレッジが属人化しやすいことでしょ う。いざというときに、ほかの人に引き継げなくなってしまうケースが多々あります。できればプロジェクトの初期段階からドキュメントを体系化し、管理資料、設計資料、運用資料、申請資料、補足資料（ナレッジ資料）などに、日頃から整理できるようにする必要があります。

　また、メンバーには常に引き継ぎを念頭に置いたアウトプットを出させ、ブラックボックス化することを防ぐ必要があります。こうすることで、引き継ぎにか かるコストの削減だけでなく、問い合わせや障害への対応時に過去のナレッジを利用でき、対応が完了するまでにかかるコストやリードタイムも削減できます。

　運用や保守のフェーズにおける3つの課題について、適切にマネジメントするための施策を見てきました。いずれも「仕組み作り」という共通項があることをご理解いただけたでしょうか。「仕組み作り」はPMOのミッションの1つです。PMOのマネジメント能力はシステムの稼働後でも生かせるわけです。さら に、保守・運用フェーズを見据えた、設計開発段階からの準備（運用計画の立案やドキュメント整備など）にも大きな役割を果たします。

第66回 組織力を駆使したプロジェクトマネジメント

PMOとプロジェクトマネジャの大きな違いの1つに、「PMOは組織として機能しなければならない」という点がある。PMOの重要なミッションは、 決して属人化させずに、いつもPMOという組織が同じサービスをプロジェクトに提供できる体制や仕組みを作ることである。PMOが実施する作業を「プロ ジェクトに提供するサービス」と捉え直すなら、PMOの機能要件が見えてくる。

後藤 年成
マネジメントソリューションズ マネージャー PMP

 

　読者の皆さんは、PMOに何が求められていると思うでしょうか。私見ですが、プロジェクトにおいてPMOは、進捗管理や課題管理、変更管理、会議のファシリテーション、次の工程の準備など、いわゆる「プロジェクトメンバーが気持ちよく作業できる環境を提供すること」にあると考えています。逆の言い方をす れば、その環境を提供できなければプロジェクトは円滑に活動できなくなってしまうでしょう。その意味では、PMOはプロジェクトを実施するための“インフ ラ・サービス”を提供すると言っても過言ではありません。

　ここで、PMOに求められる重要なことは、「PMOは組織として機能する」という点です。もう少し具体的に説明すると、「PMOはいつでも必要なサービスを同じサービスレベルでプロジェクトに提供できなければならない」ということです。

PMOは、機能停止してはならない組織

　先ほども述べた通り、PMOを「プロジェクトに“インフラ・サービス”を提供する組織」とするなら、PMOが機能停止してしまうと、プロジェクトの活動に支障が生じます。そこで、PMOの機能を継続させ、さらに活性化させるために重要なポイントは以下の3つです。

（1）属人的なサービスをなくす
（2）同じサービスを“仕組み”として提供できるようにする
（3）個人ではなく組織としてのサービス提供の観点を持つ

　（1）については、改めて言うまでもありません。例えば、PMOのAさんが風邪で休んだからといって、「今日は進捗状況を把握できないので、進捗会議は やりません」とは行かないでしょう。Aさんが休んだ場合には、PMOのBさんが代役を務められるように、日ごろから準備しておかなければなりません。

　ただし、特定の課題に対する解決や次工程の計画書作成など、どうしても属人的にならざるを得ない作業も出てくると思います。その点については、プロジェクト運営への影響の大きさを考慮すべきです。つまり、「日々のサービス提供が停止したら、すぐにプロジェクト運営に支障が出るのか」、それとも「ある程度 サービス提供が止まっても大丈夫なのか」を判断して、プロジェクト運営に支障を来たさないための「最低限のサービスレベル」を決めておく必要があります。

　（2）の「同じサービスを“仕組み”として提供できるようにする」とは、（1）の「属人的なサービスをなくす」ための仕組みを構築することです。第62回の「トラブル対応に必要な“余裕”をどう作る？」でも述べたように、可能な限り作業を自動化し、PMOメンバーの誰でも、同じサービスレベルを提供できるような環境をあらかじめ用意しておく必要があります。

例えば「1人は嫌われ役、ほかの人は献身的」という組織力

　（3）の「個人ではなく組織としてのサービス提供の観点を持つ」については、まず具体例を示したほうが分かりやすいかもしれません。例えば第61回の『「嘘ではないが、真実でもない」報告を見抜くには』 では、PMO内部での役割（機能）分担について触れました。PMOメンバーのうち1人は、多少嫌われても「プロジェクト成功のために嫌なことを言う」役割を演じ、一方、ほかのメンバーは献身的にプロジェクトメンバーの相談に乗ったり、進捗報告の後で一緒に対応策を考えたりするような役回りをする、といった ことです。

　このように、「PMOの組織力を駆使してプロジェクトを運営していく」という意識を強く持ち、組織力を生かしたプロジェクト運営手法を徹底的に考え、議論していくことが重要です。その際、PMOの組織だけにとらわれず、必要に応じてプロジェクトマネジャや上位組織を巻き込む視点も忘れてはいけません。プロジェクトマネジメントの組織力が大きいほど、プロジェクトを成功に導く力も大きくなります。

第67回 事件は現場だけで起こっているのか？

システム開発プロジェクトでは、組織間のコンフリクト（対立）がよく起こる。第35回の『アプリvs.インフラ、担当者はなぜ分かり合えない？』で は、アプリケーション担当者とインフラ担当者の対立を取り上げたが、もう1つ、やっかいな対立関係がある。それは「現場と上位組織の対立」だ。

後藤 年成
マネジメントソリューションズ マネージャー PMP

 

　プロジェクトで仕事をしていると、プロジェクトのメンバーから必ずといっていいほど耳にする文句があります。「“上”は現場のことを何も分かっていない！」と。ここでいう“上”とは、プロジェクトマネジャより上の関係者、“上位組織”を指します。

　PMOは立場上、プロジェクトの現場の状況を上位組織に伝え、上位組織での決定事項をプロジェクトの現場に浸透させるという役割を担っています。ここで、いくらPMOがコミュニケーションのハブとしてがんばっても、プロジェクトの現場と上位組織がお互いを理解し合えない限り、このような不満はなくなりません。

上位組織は「何も分かっていない？」

　自分自身を振り返ってみても、プロジェクトのメンバーやチームリーダーとして仕事をしていたころは、「“上”は何も分かっていない、本当に現場のことを 分かっているのか？」などと愚痴をこぼしていました。特に、忙しいときに限って「報告用の資料を作れ」だとか「遅れの説明とリカバリー・プランを説明しろ」などと言われたりします。さらにひどい時は、皆が徹夜明けでぐったりしているところへ、久しぶりに“上”の人が来たと思ったら、「今日は飲みに行く ぞ！」と現場の状況を全く無視した発言をしたり…。このような経験をされた方も多いと思います。

　その頃は、「事件は会議室で起きてるんじゃない。現場で起きているんだ！」というセリフを何度も思いました。

　しかし、私がプロジェクトマネジャやPMOをやるようになって実感したことがあります。それは、「事件は会議室でも起きている」ということです。“上”の人と直接話す立場になってみないと、なかなか理解できないのかもしれません。

メンバーから上位組織が見えない理由

　私の経験から言って、プロジェクトの一メンバーとしての視点から上位組織を見ると、上位組織はブラックボックス化していることが意外と多いのではないでしょうか。つまり、プロジェクトの現場からはどのような情報が報告され、どのようなことが話し合われ、その結果どのような指示が出てくるのかの経緯が全く 見えず、唐突に上からの指示だけが与えられる、という印象を受ける方が多いと思います。そのような印象が強い現場には、以下の2つの共通点があると考えて います。

（1）上位者はプロジェクトの現場にほとんど顔を出さない
（2）プロジェクト組織としての情報連携がうまくできていない

　（1）については、例えばプロジェクト体制図に“上”の人の名前が載っているにもかかわらず、「メンバーは顔も見たことがない」あるいは「飲み会にしか 来ない」という状況を指します。現場のメンバーから見ると、そのような人たちが現場の状況を本当に理解して、正しい判断ができているのかと疑問に思うのも無理はありません。

　（2）については、本来、上位組織との橋渡しをして情報を伝達すべきプロジェクトマネジャやPMOが、その情報伝達機能を果たしていないケースです。公にできない事項（機密事項など）もありますが、それはほんの一部です。むしろ、「上位組織で話し合った内容を伝えなくても現場レベルでは困らない」「聞か れたら話すけれど、わざわざこちらからは話さない」というスタンスの人が、プロジェクトマネジャやPMOを含め、上位組織のメンバーには案外多いのではな いでしょうか。

　上記の（1）や（2）の結果、現場の不信感が生まれ、現場では上位組織に正しい情報を上げなくなる可能性があります。なぜならば、現場を理解していない上位組織に情報を不用意に上げてしまうと、「的外れの、余計な仕事が増える」と現場が思い込んでしまうためです。情報の重要度にかかわらず、上位組織に正 しい情報を上げなくなる状況は、なんとしても避けなければなりません。

会議室でも事件は起きている！

　改めて言うまでもありませんが、上位組織の会議では、プロジェクトマネジャやPMOからの情報を基に、要員調整や外部組織との交渉など、ハードな調整や決定が行われています。特に難しい局面にあるプロジェクトの上位組織では、“事件”の連続です。きっとプロジェクトメンバーの想像を超えていると思います。

　ただし、会議室での決定事項がプロジェクト全体に伝わり、プロジェクト全体が一丸となって同じ方向に進むためには、上位組織と現場がお互いに信頼し合 い、お互いの顔や気持ちが見えていなければなりません。プロジェクトメンバーが上位組織の役員に直接会いに行くことはまずありませんし、経験上、現場から上位組織への不満がゼロになることはまずありません。

　そこで、上位組織の方々が少し下に下りてきてみたらどうでしょう。例えば、たまには現場に顔を出すとか、プロジェクトの進捗会議にも出てみて、現場の雰囲気を実際に見てみるとか。そういう行動が重要だと思います。

　そして、プロジェクトマネジャやPMOは、プロジェクトの重要なイベントには“上”の人に参加を依頼するなど、上位組織を巻き込んだプロジェクト運営を 心がけてみてはどうでしょう。もちろん、忙しい“上”の人の代弁者として、プロジェクトマネジャやPMOがしっかりと上位組織の思いや考えをプロジェクト 全体に伝えていくことも忘れてはなりません。

第68回 「息苦しい管理」からの脱却

　PMO（プロジェクトマネジメントオフィス）というと、どうしても「管理屋」のイメージが先行するのではないか。しかし、数々のプロジェクトを見てきた中で、現場がPMOに一番求めていることは、進捗管理や課題管理を厳格に実行してメンバーを追いつめていく役割でない。実は、一緒に考えて、一緒に行動し、ときには行動するためのお膳立てを実施し、メンバーの背中を少し押してあげることが必要とされている。

後藤 年成
マネジメントソリューションズ マネージャー PMP

 

　「プロジェクトを管理すること」――。PMOがプロジェクトから期待されていることを一言で言えば、こうです。さて、プロジェクトを管理するとは一体どういうことでしょうか。

　それは、あらかじめ立てられたプロジェクト・ベースラインに沿って、予定通りにプロジェクトが進んでいるかを見える化することでしょうか。それとも、遅れに対して、原因を追究して課題を解決していくことでしょうか。あるいは、マネジメント層に対してプロジェクトの状況報告のためのレポートを取りまとめる ことでしょうか。上述したことは、すべてPMOにて「管理すること」にあてはまります。

　しかし、重要なポイントは、それらの活動にPMOがどのようにかかわっていくかです。PMOとして「やってはいけない」管理スタイルとしては、「評論家にならないこと」です。

　例えば、「この課題の根本原因は、要員のスキル不足が原因だから、要員交代を検討すべきだ」「このリスクは、総合テストまでに解決すべきだ」「進捗状況をもっと見える化すべきだ」などの言動は評論家的です。プロジェクトに対して、他人事のように“アドバイスしてやっている”というようなPMOは、あなた の周りにはいないでしょうか。

管理を厳重にしても進捗は進まない

　経験上、進捗報告を毎日させるなど、管理を厳格にしても、メンバーが息苦しくなるだけです。管理工数が増えるばかりで、決して進捗するわけではありません。

　かく言う私も、進捗の遅れなどに際して、こと細かに報告させていた時期もありました。しかし、「進捗管理を実施しているのだ」と自己満足していただけであり、「管理のために管理することが目的化」していました。

　当然、そのような管理はうまく行かず、メンバーのモチベーションを下げてしまうことが多々ありました。言い換えれば、「どのようにやればうまく管理できるか？」が目的となってしまい、本来のプロジェクト管理の目的である「どうすれば、プロジェクトを成功に導けるか？」という視点が抜けてしまっていたので す。

現場に求められる本当の「管理」とは

　前段で述べたように、「どうすればプロジェクトを成功に導けるか？」という視点でプロジェクト管理を考えれば、自ずとPMOとしての活動スタイルが決まってきます。

　プロジェクトの進捗を把握するために必要な情報を見える化し、課題に対する原因を究明し、マネジメント層が意思決定するためのレポートを取りまとめるこ とは単なる「手段」です。PMOとしての本当のプロジェクト管理は、「プロジェクトの成功」という目的のために「手段」をうまく活用することです。

　つまり、適切な手段を講じながら期待通りの結果が出るように「プロジェクトを推進すること」がPMOとしての活動の中心になるはずです。理想論かもしれませんが、メンバーにアドバイスや指示をするのではなく、メンバーと一緒に解決策を考えて、開発作業に直接関係しない領域の作業（枠組みや仕組み作りな ど）をPMOが主体的に担っていくことが重要なのです。

　PMOとプロジェクトメンバーの関係について、わたしたちの意識も変わるべきなのでしょう。「PMOがプロジェクトメンバーを“管理する”」のではなく、「プロジェクトメンバーが、自分の活動を進めやすくするために“PMOを使いこなす”」という発想への転換が大切だと考えています。

第69回 たかが議事録、されど議事録

会議の進行どおりに発言を記録していくような議事録は、あえてムダだと言いたい。それぞれの会議には、それぞれの目的がある。その目的達成を助けるような議事録を作れなければ、議事録の作成時間は大いなるムダとなるはずだ。

後藤 年成
マネジメントソリューションズ マネージャー PMP

 

　皆さんの仕事場では、議事録を残しているでしょうか。PMOとして仕事をしていると、会議のファシリテートと同じぐらい、会議の議事録をとる機会（仕事）が多く、筆者も議事録の作成をどのように効率化しようかといろいろ悩みました。

　特に最初は、「どの程度まで議事を記録すればよいのか？」「何を言っているのか分からず議事録がとれない！」「議事録にしたくとも、結局、何も結論が出ていない！」など、議事録の作成で苦労した経験があります。今回はPMOとして議事録にどのように向き合い、どのような議事録を作成すればよいか考えてみたいと思います。

会議によって議事録の目的は違う

　さて、議事録をとる目的は何でしょうか。後から「言った、言わない」という問題を防ぐためでしょうか。それとも、決定事項を関係者に周知するためでしょうか。会議の決定事項を再確認するための正式ドキュメントとするためでしょうか。あるいは、会議の中で出た課題やリスクを記録して、次のアクションを促す ためでしょうか。

　すべて正しいのですが、会議によって議事録のあるべき姿は変わってきます。「会議の目的」が違うからです。例えば、ステアリングコミッティーのようなプロジェクトの重要事項を決める会議と、プロジェクト内での週次進捗会議、突発的な問題が起こった場合の対策会議では、それぞれ会議の目的が異なります。

　議事録は、この会議の目的に沿うものであるべきです。議事の進行どおりに、機械的に記録するような議事録ではダメです。「この会議の目的からして、どのような議事録を作成すれば会議の目的達成の助けになるか？」という視点で議事録を考えると、議事録として残す情報のポイントが自ずと見えてきます。

　先に挙げた例で言うと、ステアリングコミッティーの議事録は、「何が決定されたのか」が最重要であり、その補足情報として「誰が、どのような意見、懸念点を持っている」という情報をまとめていきます。

　プロジェクト内での週次進捗会議なら、「プロジェクトの進捗を阻害している課題は何か？」が最重要です。その補足情報として「課題」や「リスク」「対応方針」などの情報を議事録にまとめます。

　また、突発的な問題が起こったときの対策会議の場合、「問題に対する原因の究明とその解決策」が最重要となります。補足情報として「解決のためのアクションプラン」や「解決のための役割分担」をまとめるべきでしょう。

　このように、それぞれの「会議の目的」を意識することによって、様々な議論の中から議事録に残すべきポイントを抽出できるようになります。すべての議事録に言えることは、「会議の目的を達成するための『過程の議事』はさほど重要でない」という点です。

　ただし、公官庁や大企業では、「関係者を集めて問題を共有した」という行為そのものが目的の会議も少なくなりません。このような場合は、問題を共有した過程を記録すべきこともあります。

議事録を見た後に何を期待するか？

　ドキュメントを作成するときの鉄則は、「読む側の立場になって考える」ですが、議事録についても同じです。議事録を送るメンバー自身が議事録を読み直し、その後に自分が何をするべきか、はっきりと記されていることが重要です。

　例えば、議事内容から「課題」や「ToDo」「決定事項」「リスク」などを拾い上げ、担当者や期限を議事録の最初に明記しましょう。議事録は、会議の参 加メンバーによる合意事項を記載したものです。議事録に明記されたアクションプランや担当者名は、メンバーにアクションを促すきっかけとなります。

　さらに定期的な会議では、前回の議事録に記された「持ち帰り事項」を次の会議の始めに確認すれば、プロジェクトに必要なアクションがとられたかどうかをチェックできます。

このように議事録には、議事録を見た関係者に何を期待するかによって、その書き方や議事録の運営方法を工夫できるのです。うまく運用すれば「皆に見られる議事録」「アクションに結びつく議事録」にすることができます。

議事録の作成を効率化するポイント

　もう少し具体的に議事録の書き方を考えてみましょう。皆さんはすべての会議について同じようなレベルで議事録を録ってはいないでしょか。筆者の場合、会議の内容やレベルに応じて、議事録への記載レベルを使い分けています。

　例えば、前述した「突発的な問題が起こった場合の対策会議」に関する議事録の場合は、個条書きレベルのメモで「本質的な原因」と「誰が、いつ、何をする」のみを記載しています。会議中にノートPCで議事録を作成し、会議が終わったら、その場ですぐ関係者に送っています。

　ノートPCがない場合は、ホワイトボードにまとめた事項を携帯のカメラで撮り、それを議事録として展開します。なぜならば、「問題をいかに早く解決するか」が重要だからです。もしかしたら、議事録というよりは、単なる「議事のメモ」に近いかもしれません。

　また、プロジェクトの週次進捗会議などでは、ポイントとなる議事を記載し、そこから「課題」や「ToDo」「決定事項」「リスク」などを抽出して、一度ほかのPMOメンバーの確認を得てから全体に展開しています。こうする理由は、現在のプロジェクト上の問題で見落としがないかを確認したいからです。

　これら2つの議事録にかける仕事量は違いますが、議事録としての有効性は2つとも同じです。このように、会議のレベルに応じて記載内容を使い分ければ、効率的に議事録を作成できます。

完璧な議事録はいらない

　一般に、ICレコーダーで会議の内容をすべて録音し、一言一句漏らさず一生懸命に議事録をとり、どんなにきれいに体裁を整えたとしても、一度作成してしまったら、その後見向きもされないのが議事録の実態でしょう。ほとんどの議事録は有効に活用されていません。

　とはいえ、長い会議になると議事録の量も膨大になり、議事録を作成するだけで丸1日とられてしまうこともあります。そのような努力にもかかわらず、見向きもされないのは、なんとも寂しい限りです。監査のために議事録をとらなくてはならない場合もありますが、どんなに立派な議事録を何百枚作ろうとも、それ でプロジェクトが成功するわけではありません。

　それよりもPMOとしては、「この会議で議事録を作る意味はなんだろう？」と一度考えて、会議の目的に合った議事録を作成できているか、そこに過剰な工数をかけていないか、点検してみてはいかがでしょうか。

第70回 PMOの“クラウド化”

PMO（プロジェクトマネジメントオフィス）のスキルや成果物は、さまざまなプロジェクトで有効に再利用できる貴重なリソースだ。そんなリソースを特定プロジェクトだけで専有していてはもったいない。PMOを“クラウド的”な共有リソースと考えてみてはどうだろうか。

後藤 年成
マネジメントソリューションズ マネージャー PMP

 

　ある一つのプロジェクトの「専任PMO」として実際に業務遂行したことがある方は実感できると思いますが、プロジェクトのフェーズや状況によってPMO の仕事量には大きな波が生じます。寝る暇もないぐらい忙しい時期があるかと思えば、ルーチン的な業務を回していくだけの、余裕がある時期もあります。

　PMOの業務は、特にプロジェクトや各フェーズ（設計フェーズや開発フェーズなど）の立ち上がりと終結の時期に負荷が大きくなります。なぜならば、立ち上げ時にはそのフェーズでのプロジェクト運用ルールの整備、ひな形の作成、定着化などで作業量が増えます。また、終結の時期では、そのフェーズの成果物の 取りまとめや次のフェーズの計画作りで作業負荷が増えます。

　一方、当該フェーズを立ち上げて軌道に乗り、プロジェクトメンバーが運用ルールとWBS（Work Breakdown Structure）に従って粛々と作業を進めていく期間は、PMOとしては課題管理や進捗管理といったルーチン的な作業が中心になります。加えて、「第62回 トラブル対応に必要な“余裕”をどう作る？」でも述べたように、PMOの作業をある程度自動化してしまえば、比較的余裕を作り出すことができます。

PMOをクラウド的に利用する

　こうした作業負荷の波は、できるだけ平準化する必要があります。また、PMOのスキルや成果物は、さまざまなプロジェクトで有効に再利用できる貴重なリソースです。そんなリソースを特定のプロジェクトだけで専有するのは、もったいないと言えましょう。

　そこで、各プロジェクトに散らばっているPMOメンバーを組織的に管理することによって、「PMOを“クラウド的”に利用する」という使い方が見えてき ます。つまり、PMOメンバーのリソースプールを作り、必要なときに、必要なだけ、必要なPMOスキルを持った人材を各プロジェクトのPMOメンバーとし て割り当てていくのです。そのためには、「第66回 組織力を駆使したプロジェクトマネジメント」でも述べたように、「PMOを組織として機能させる」必要があります。

　PMOをクラウド的な共有リソースとして定義すると、下記のようなメリットがあるのではないでしょうか。

（1）あるプロジェクトが忙しいときには、当該プロジェクトに対するPMOメンバーのアサインを増やせる。これにより、PMOがボトルネックとなってプロジェクト運営が停滞するリスクをなくす。

（2）PMOメンバーが各プロジェクトでの教訓や良い所を知識化してPMO組織に持ち帰ることができる。これにより、PMO組織としてのスキルや知識が向上し、各プロジェクトにも還元できる。

（3）あるプロジェクトにアサインされているPMOメンバーがスキル不足の場合でも、「一時的に必要なPMO知識」を共有リソースから調達できる。

　ただし、PMOを“クラウド化”すると、プロジェクト専任担当ではなくなるため、プロジェクトへの帰属意識が薄まる可能性があります。また、大手のシステムインテグレータなどでよく見られるように、PMOメンバーが複数の組織（事業部など）に分散している場合があります。このようなケースでは、PMOメ ンバーの統合・組織化を巡って「組織的にどう位置づけるか」といった問題も発生し得ると思います。

　上記の懸念に対しては、各プロジェクトには数人のプロジェクト専任のPMOメンバーを固定的に割り当て、必要に応じてPMOメンバーを追加するような方法でもいいでしょう。また、組織の問題として全社的な実施が難しければ、まずは1つの事業部や部の単位で実施してみるのがよいかもしれません。

既存組織との違い

　プロジェクトマネジメントを“クラウド的”に支援する組織として、既に「品質管理部」といった名前の組織が中堅・大手企業ならばあるかもしれません。しかし、一概には言えませんが、そのような組織の多くはプロジェクトの「アドバイザー」や「監査者」のような存在と位置づけられているのではないでしょう か。もしそうなら、プロジェクトの現場でプロジェクトメンバーと一緒に汗を流し、プロジェクト成功のために尽力するPMO組織とは様相が異なります。

　プロジェクトの品質を担保するためには、アドバイザーや監査者としての客観的な視点でプロジェクトの状況を判断する機能も必要だと思います。しかし、実際に現場に入って働くプロジェクトマネジメントのプロフェッショナルを組織として育成していけば、プロジェクトの成功確率はもっと上がると思います。