PMOはエンジニアと共通語で話せないと始まらない

はじめに

前回までの基礎編では「PMO(ピーエムオー：Project Management Office)とは、どのような職業なのか」について解説してきました。今回からはさらに深掘りした知識編として「優秀なPMOに必要なこと」をお伝えします。

さて、これまでもお話ししてきましたが、PMOの仕事はただプロジェクトを管理するだけではありません。プロジェクトに関わるさまざまな人とコミュニケーションを取りながら、現状や課題の把握、解決策を検討していくことが最も大切な仕事です。

しかしその際、PMOがプロジェクトの具体的な内容やメンバそれぞれの業務、使われている言葉をあまり理解していない場合、メンバーから「あのPMOは話が通じないから、自分たちで処理しよう」と思われたり、お客様から「あの人にまかせて大丈夫だろうか……」と不信感を持たれたりする事態に陥ってしまいます。そうなれば、当然プロジェクトはスムーズに進行できません。

そこでPMOが身に付けておきたいのが、コミュニケーションを円滑に、正しく行うための「共通語」です。と言っても、ここで言う共通語とはプログラム言語などの専門用語という意味ではありません。プロジェクトを進めていく際の「共通意識」、言うなれば分かりやすくコミュニケーションをとる、という意味です。

Think ITの読者にはエンジニアの方が多いと思いますので、今回はシステム開発プロジェクトを例に、2つの「共通語」と、それらに加えて持っておきたい思考力について解説します。

PMOに求められる2つの「共通語」とは

共通語について解説する前に、PMOとして押さえておきたいことが2つあります。1つは「プロジェクト全体の流れを理解しておくこと」です。例えば、システム開発の場合「システム設計→開発→テスト」と進んでいきます。これはどのようなプロジェクトでも基本的に同じです。

そして、もう1つは「エンジニアと会話をするにあたり、基礎的な専門用語は理解しておくこと」です。仮にエンジニア経験がなくても問題ありません。「基本情報技術者」や「ITパスポート」といった資格を取得することで、エンジニアとのコミュニケーションに必要な用語は理解できるようになります。

その上で、次の2つのポイントを意識しましょう。そうすることで、より「話のわかる優秀なPMO」に近づくことができるはずです。

「白黒をはっきり」させた話し言葉

日本人は特に、あいまいな表現を好むと言われます。

「今日の夕方までに作業をお願いできませんか?」
「ざっくりこんな感じの成果物でいかがでしょうか?」

誰でも、こうしたふわっとした表現を聞いたり、使ったりした経験があると思いますが、プロジェクトにおいてはこれが後々炎上の火種となるケースが多いもの。なるべく断定表現を使い、できる限り曖昧さをなくすことが大切です。

例えば、手作業で行っていた経理業務をシステム化するプロジェクトの場合を考えてみましょう。

さて、みなさんは、この2つのケースを見て、どのように感じましたか。「どちらがお客様のニーズに即したシステムを開発できるか」と言えば、間違いなく＜ケースB＞の方だと感じるでしょう。

＜ケースA＞では、開発を進めるにあたり、いろいろと問題が発生しそうですよね。なぜなら「たくさん」「大変」といった言葉の認識が、開発側とお客様で相違している可能性があるからです。お客様は「500枚で大変」だと思っているのに、開発側が勝手に「1000枚以上なら大変だろう」とシステムを作ってしまったら、お客様から「希望していたシステムと違う」とクレームが来るかもしれません。

今回は分かりやすくするために極端な例を出しましたが、これに近い出来事は意外とみなさんのそばでも起きているのではないでしょうか。例えば「今度注文するシステムは、常に動いていてほしいのです」とお客様から言われた場合、その「常に」とは「月～金の9:00～18:00」かもしれないし、「夜間を含む、月～金の6:00～21:00」かもしれないし、はたまた「24時間365日、盆暮正月も全部」かもしれません。

また「洋服のサイズごとにデータを分類したい」と依頼されたとして「サイズの相場はS・M・L」と思い込んでいたら、実は「XXS・XS・S」のサイズ展開だったなんてこともあるでしょう。

これらはすべて「曖昧」な表現があるため、人によって解釈が変わってしまいます。「これくらいで大きなトラブルには発展しないだろう」と思うかもしれませんが、こうした話し言葉のすれ違いによるトラブルはプロジェクトでしばしば起こります。すると、お客様のオーダー通りにシステムを作れないどころか、そもそもプログラムなどにミスが生じて正常に動かなくなってしまう恐れもあり、プロジェクトの成功からは遠ざかってしまいます。

ゼロなのか1なのかといった数字の確認はもちろんのこと、少しでも曖昧さを感じる言葉、感覚的な言葉は「場の雰囲気を壊してしまうかも……」などと躊躇せず、必ず白黒はっきりさせておく。シンプルですが、PMOが常にこの意識を持って会話することで、その意識はプロジェクト全体に派生し、トラブルはグッと減るはずです。

「誰でも理解」できる書き言葉

私はPMOとしてプロジェクトに参画する際、会議や打ち合わせのほか、メンバやお客様など誰かと会話をするときは、手ぶらでただ話すといったことはまずありません。どうするかと言えば、必ず手元にPCを置いて話した内容をメモしているのです。

この、当たり前とも思える「常に記録する」という意識は、PMOにとって非常に大切です。どのようなプロジェクトでも進行していくと必ず1つや2つ矛盾が出てくるからです。

例えば「お客様からの依頼が、契約当初に受けた内容とは違ってきているようだ。どちらが正しいのだろうか?」といった事象が発生したとします。そのようなときに記録が取られていないと、エンジニアの中で

「お客様がそう言っているのだから、言われた通りに進行しよう」
「頑張れば、何とかなるよ」

などと力技で進めてしまいがちです。そうすると、プロジェクト後半になってその矛盾が露呈しトラブルに陥る……最悪の場合、システムに不具合が起きてしまうといったケースもよくあります。

もしそのプロジェクトにPMOがいて、これまでの記録を残していたらどうでしょう。「前に言われたこととは辻褄が合わないので、お客様が勘違いされているのかもしれません。再度確認してみましょう」といった提案ができ、トラブルを未然に防ぐことができるのです。

ただし、ここで注意したいのは記録の仕方です。「メモを取る」と言っても、単に話したことを記録するだけのいわゆる「文字起こし」では、残念ながら完璧とは言えません。記録した情報はいつ、どこで役に立つか分からないからです。

プロジェクトの開始直後、あるいは終盤で必要になるかもしれないし、そのときには今のメンバとは顔ぶれが変わっている可能性もあります。さらに、そのメモを確認するのがシステムの知識に長けたエンジニアだけとは限りません。

そのため、メモを残す際は「いつ誰が見ても内容を正しく把握できるように要約すること」が重要なのです。例えば、エンジニアとお客様の間で次のような会話が繰り広げられたとしましょう。

この会話の一字一句をそのまま書き起こすのは、ただの「記録」です。無駄な文章もあるため、読み手はすぐに理解できないかもしれません。一方で、「要約」したメモは次のようになります。

要点を簡潔にまとめることで、読み手は短時間で内容を理解できます。

会話をしながら要約するのが難しければ、まずは書き起こして、後で整理しながら要約するのももちろんOKです。文章を書く際は「誰かに見せる」記録として、できるだけ分かりやすい表現を使うことも大切です。例えば「少なくない」「色は青ではない」といった表現は、理解に時間がかかったり、勘違いされたりすることもあります。二重否定文や曖昧な文章は避けるようにしましょう。

「共通語」とともにPMOが持っておきたい思考力

ここまで2つの共通語を紹介しましたが、もう1つ、プロジェクトメンバやお客様とのコミュニケーションをスムーズにするために必要なのは「相手の最優先事項を理解する思考力」だと私は考えています。

プロジェクトでは、分野や規模によってさまざまなバックボーンを持った人たちと一緒に働く機会が多々あります。多様性が広がるほど前述した共通語をいかに使えるかが重要になってくるわけですが、その前に相手にとって何が最も大事なのか、そしてそれが今のプロジェクトとどうつながるのかを思考するプロセスが欠かせません。

例えば、同じシステム開発プロジェクトのメンバでも、エンジニアと営業とでは最優先事項が違います。

エンジニア：売上よりも正常に動くシステムを作ることが最優先
営業：システムの内容よりも売上を増やすことが最優先

PMOの最優先事項はプロジェクトの成功ですが、エンジニアにも営業にも同じことを求めていてはうまくいかないわけです。例えば、より良いシステム開発のための「ITスキルの向上」はエンジニアには必要でも、営業には不要です。

システム仕様を確認してもらうプロセス1つとっても、エンジニアと営業では要点が異なるはずです。それを一律に「確認してください」とただ仕様書を回しても、営業では「システムのことはよく分からないいから、お任せします」と人任せのよそよそしいコミュニケーションになってしまいます。

そこで例えば「これは、営業部門のこの業務を効率化するためのシステムでして……」「営業部門でなぜこの確認が必要かと言うと……」といった切り口で話せば、「そうなんですね。具体的にはどれくらい効率化できるのですか?」など、自分ごととして捉えてもらえると思います。後に「そんな内容とは知らなかった」なんてことも少なくなるでしょう。

PMOが常にこうしたそれぞれの違いを念頭に置いておくことで、前述した2つの共通語の精度も上がります。「エンジニアには、この数字をはっきりして欲しいと言った方がピンときそうだ」「営業には、こういうメモを残せば分かりやすいだろう」といった配慮ができるからです。

そして、どんな人でもプロジェクトが長くなればなるほど「自分は何のためにこの業務を行なっているのか」「そもそもこのプロジェクトは何を目指しているのか」といった目的意識、自分ごととして捉える意識が薄れてしまいがちです。

そのため「なぜこの業務が必要なのか」「（プロジェクト成功により）この部門にはどのようなメリットがあるのか」を日々の会話を通してメンバたちに伝えていくこともPMOの大事な仕事の1つと言えます。

PMOがプロジェクトに関わる一人ひとりをきちんと理解する思考力を持っていれば、それぞれ違う仕事をしているメンバ一たちも、一丸となってプロジェクト成功に向かって業務に取り組むことができるのです。

おわりに

知識編第1回の今回は、以下のような内容を解説しました。

• PMOに求められる2つの「共通語」は「白黒をはっきり」させた話し言葉と「誰でも理解」できる書き言葉
• さらにPMOが「相手の最優先事項を理解する思考力」を持つことでプロジェクト内のコミュニケーションやモチベーションが高まり、プロジェクト成功に向けて加速できる

当たり前のことのように思えて、実はできていない人が多いのではないかと想像します。どれもとてもシンプルなことなのですが、実践してみるとPMOではなくても仕事の質が上がり、プロジェクト内のやりとりも円滑になると思います。ぜひ、日々の業務の中で意識してみてください。

次回からは、PMOに必要とされる、さらに具体的なスキルについて深掘りしていきたいと思います。どうぞお楽しみに!