現場からの報告書、鵜呑みにしていませんか? 「PMO的」報告書の見方と問題点の対処法

はじめに

PMOにはプロジェクトをスムーズに進行する役目があります。報告書をチェックする際は、内容はもちろんのこと、

そんな視点を持つ必要があります。

それでは、現状はどうでしょうか。そうした報告書の内容を見て、みなさんは「はい、分かりました」とただ受け取っていないでしょうか。これでは「ただ情報が目の前を通過している」に過ぎません。本来PMOの役割とは、1枚の報告書からプロジェクトや各チームの見えなかった課題を浮き彫りにする、そんな役目もあるのです。

「たかが報告書でそんなことができるの?」と思われるかもしれませんが、実際に私も報告書によって気付かされたこと、改善できたことが数多くあります。

今回は、そんなPMO的報告書の見方、そして問題がある場合の対処法について解説していきます。

PMOが報告書を鵜呑みにしてはいけない理由

タイトルのように、私が「報告書をそのまま鵜呑みにするな!」と警告するのには、大きく2つの理由があります。

1つ目は「報告の中に虚偽が混在している」ケースがあるからです。

「虚偽」と言うと少し大げさですが、人間「本音をすべて話す」というのは案外難しいもの。ましてや仕事ともなればなおさらです。虚偽が発生する大きな理由としては「予定より少し遅れているが、上から怒られるのは嫌だから何とかごまかそう」「このトラブル、報告の仕方が分からない…とりあえず『問題なし』と報告しておこう」といった「マズイことは隠したい」心理があります。

そのまま虚偽の報告を受け入れれば、その場は何ごともなく済むでしょう。しかし、言うまでもなくプロジェクトは遅延します。それだけならまだしも、その場しのぎで先送りされたトラブルが、後々にプロジェクト完了が危ぶまれるほど大問題になることもあるのです。

こうした事態を防ぐには、手間はかかりますが実際に現場に行き、進捗を確認するのがベストです。ここで大事なのが、嘘をついた人を疑う、責めるなど「人を追い詰める行為はしない」こと。それをしても、何ら解決には結びつきません。

PMOとしてスケジュール管理の任務を遂行するために自分の目で確認する、それだけで良いのです。結果として、このチェックが抑止力になることもありますし、何より現場の様子を直接見ることで、その場で「このタスク遅延は、こうすれば防げるのではないか」と提案できるかもしれません。

2つ目の理由は「プロジェクト進行に必要な内容が足りない」ケースがあるからです。

例えば、進捗確認に必要な情報が書かれていない、逆に不要な情報まで織り込まれている、数値情報の根拠が不明瞭、フォーマットが人によりバラバラ…といった事柄が挙げられるでしょう。これではプロジェクト進行に支障をきたしてしまいます。

なぜ、こうした内容の過不足が発生するのでしょうか。その理由は、さらに以下の3パターンに分類されます。

パターン1：「報告書に何を書けば良いのか分かっていない」

そもそも、報告書の書き方やそれに必要な内容を理解できていないため、「とりあえず報告書を出さなくては」と毎回ただ項目を穴埋めしたものを提出しているケースです。「この数値の根拠は?」「なぜこのタスクの報告をしているのですか?」といった質問にも、はっきり答えることができません。

また、このパターンではPLやPMのチェック機能に問題があることも多いです。PMOが「〇〇チームの報告書は、他チームの報告書とは品質が異なるようです。確認されていますか?」などと聞いた場合に「あいつは仕事ができないんですよね～」「これは外部の会社が作ってきたものなので…」といった他責の言葉が出てくる。そうした現場の報告書は、おそらく毎回読み流されているだけでしょう。

パターン2：「報告書の重要性が分かっていない」

よくあるのが、マネジャー側とプログラマー側で認識違いがある場合です。プログラマーは、現状のプログラムを見れば進捗や目指す形は一目瞭然です。そのため「プログラムが無事に完成さえすれば、報告なんてしなくても問題ない」「いちいちWordやExcelで作成するのは手間」という発想を抱きがちです。一方、マネジャー側はプログラムそのものを見ても何も分かりません。つまり、両者で「報告書の重要性を理解しないまま、プロジェクトが進行してしまっている」のです。

ちなみに、以前私がPMOとして入ったプロジェクトでは開発会社から定期的な進捗報告がなく、いつも「前倒しで進んでいますので」という口頭の報告のみを受けていました。「優秀な会社だな」と思っていましたが、いざ完成前のテストを迎えると「あれ? 動かない! 順調だったんじゃないの?」という事態に陥ってしまいました。開発会社が「これくらい報告はいらないだろう」と思っていたことが原因で、大事に至ってしまったのです。

パターン3：「従来のやり方が正しいと思い込んでいる」

そんな前置きがある報告書ほど、必要事項や重要な数値、その根拠などが抜けていたりするもの。これまで当たり前に使われ続けてきて、誰も疑いを持たないケースもあります。もちろん、その方法で何もトラブルが起きなければ問題はないのかもしれません。しかし、予期せぬトラブルが起きて「あの業務の進捗経緯を明らかにしたい」「あの数値の推移はどうなっている?」といったときに、進捗を追えず困ってしまうのです。

また、他社から転職してきたPMなどにありがちなのが前の会社ではこういう報告書でうまくいったので、ここでも使っています」というパターンです。気持ちは分かりますが、会社も違えばプロジェクトもメンバーも違います。横スライドで踏襲すると、現プロジェクトにはマッチしない部分もあるでしょうし、元々プロジェクトにいるメンバーから反発が起きたり、「あの人はすぐ前社を持ち出すから何を言ってもムダ」と思われたり…あまり良いことは起きません。

私はこのようなタイプの人を「転校生」と呼びますが(笑)、「郷に入っては郷に従え」です。いつまでも転校生のままでは、メンバーとの信頼関係の構築も難しくなります。

このような問題点をはらんでいるのにも関わらず、スルーしてしまう。それこそが報告書を鵜呑みにしてしまう最大の「問題」だと言えるでしょう。

鵜呑みにできない報告書の対処法

それでは、お伝えしてきたようなPMOとして見逃せない報告書が提出された場合、どのような対処をすれば良いのでしょうか。前述の「過不足がある場合」のパターン別に対処法をまとめました。

パターン1：「報告書に何を書けば良いのか分かっていない」の対処法

メンバーの理解度にもよりますが、理解度が著しく低い場合、PMO側が求めるアウトプットのフォーマットを提示して「これに沿って作ってみてください」と伝えます。

必要事項を埋めていくだけなので、誰でも同じ品質の報告書を提出できるようになります。もちろん、これは最低限のスタートラインに立つための対処なので、この先運用していく中でさらに必要事項があれば都度加えていきます。同時に、PMやPLに報告書のチェックポイントなどを共有することも大切です。

パターン2：「報告書の重要性が分かっていない」の対処法

プロジェクトでは様々な人が進捗を知る必要があります。たとえ順調に進行していたとしても、現状の段階や今後でき上がってくるアウトプットなどを皆が理解するためにはドキュメントによる報告が必須です。まず、メンバー全員で「報告書の重要性」の認識合わせをする必要があるでしょう。

本来ならプロジェクト開始前に行いますが、場合によっては始動してから2、3個の報告書をランダムに抽出し、あらためて双方の認識を確認する機会を持つこともあります。いずれにしても「報告書がプロジェクト進行には必要不可欠なんだ」という意識を持つことが大切です。

パターン3：「従来のやり方が正しいと思い込んでいる」の対処法

この場合、少し慎重になる必要があります。なぜなら、例えば何十年も同じやり方で進めてきた場合、いくら正しい改善でも、突如プロジェクトに加わったPMOに「こう直してください」と言われるのは、なかなか受け入れにくいからです。

プロジェクトには自社以外の企業も関わりますし、自社内でも様々なバックグラウンドを持つ人たちが集まっています。そのため、改善の提案をする際は現行の否定から入るのではなく、それぞれの価値観を尊重しながらお互いが納得できるやり方を模索していくと良いでしょう。

「自責思考」が成長を促す!

ここまでお読みになり、そう感じた方もいるかもしれません。確かに、PMOの任務は「プロジェクトを円滑に進行すること」です。そのため、PMOの中にはわざわざ現場を見に行ったり、認識合わせのためのミーティングを開催したりしない人もいるでしょう。「ちゃんとした報告書を提出してください」のひと言で済むのかもしれません。

しかし、それではPMOとしての成長につながらないと私は考えています。報告書に限らず、何か問題が起きるたびに「メンバーやチーム、取引先が悪い」と他責で済ませるのは簡単です。しかし、それでは根本要因が解決されていないため、他所でもまた同じようなことが起こる可能性があります。

一方、常に「自分はPMOとして何かできなかっただろうか」と自責思考で考えることで「そうか、こういう仕組みを作っておけば防げるんだ」といった具体策、次のアクションが見えてきます。このとき学んだことは、プロジェクトやメンバーが変わっても応用できるでしょう。

自責思考は、PMOに限らずどんな職種でも成長につながる能力だと私は思っています。仕事をする中では、悔しい思いや嫌な思いをすることもあります。そんなとき「運が悪かった」「本当は相手が悪いのに」などと思わず、「自分は何か変えられないか」という視点を持つことで自身の学びになるだけでなく、語れるエピソードにもなります。

現に、私はこれまでの学びをこうしてみなさんにお伝えすることができています。「問題が起こったのは自分のせいではないのに、自責思考で考える」というのは精神的につらい側面もあります。しかし、それを乗り越えてこそPMOとしての成長となるもの。ぜひ、このあたりも意識していただければと思います。

おわりに

事例・実践編第5回目の今回は、以下のような内容を解説しました。

• PMOは「プロジェクトを円滑に進める」ことを前提に報告書を見る
• 報告書からチームの課題が見えてくることもある
• 多様なメンバーの価値観を尊重しながら、ベストな着地点を見つけよう
• 相手を責めるより「自分は何ができた?」の自責思考でさらなる成長を

私がPMOとして要請を受けるプロジェクトは、すでに「大変な事態」に陥っているケースが多いのですが、その場合も「報告書時点で問題がある」ことがよくあります。PMOには右から左に流すのではなく、じっくりと見て気になることは放置せず早めの対処を心がけていただきたいと思います。

繰り返しになりますが、多様な人たちが集まって共通のゴールに向かって進んでいくというのがプロジェクトの特徴であり、難しさでもあります。その舵取りをするPMOは大変な仕事ではありますが、その分やりがいもあります。また、自責思考で成長を続けていれば、不思議と同じ思考を持った人たちとご縁がつながり、どんどん仕事がしやすくなるものです。

今回解説したことを、ぜひ日々の業務に取り入れて成長の糧にしていただければ嬉しいです。

次回は、プロジェクトを成功に導くスケジュールの立て方、チェックポイントについて解説します。お楽しみに!