「最強PMO」が教える、多様な人が集まるプロジェクトのやりにくさ解消術【連載Vol.8】
エンジニア時代に知りたかった「開発現場の難所」突破のコツ
PMOとして数多くのプロジェクトに関わらせていただく中で、一緒のチームになった心優しき人からは「甲州さん、毎回一緒に働くメンバーが変わるなんてやりにくくないんですか？」と言われることがあります。そんなとき私は、「そのために私のような人がいるんですよ」と答えます。
PMOは、縁の下の力持ちとなって様々な人が集まるプロジェクトをスムーズに進行するのが役目。そのために、いくつか実践していることがあります。
今回はPMO的視点で、プロジェクトにおいてやりにくさを感じる三つのポイントをお伝えした上で、それらを解消するためにPMOが行っているプロジェクト体制つくりのコツについて解説していこうと思います。
株式会社office Root（オフィスルート）
代表取締役社長
甲州 潤（こうしゅうじゅん）
国立高専卒業後、ソフトウェア開発企業でSEとして一連の開発業務を経験し、フリーランスに転身。国内大手SI企業の大規模プロジェクトに多数参画し、優秀な人材がいても開発が失敗することに疑問を抱く。PMOとして活動を開始し、多数プロジェクトを成功へ導く。企業との協業も増加し、2020年に法人化。さまざまな企業課題と向き合う日々。著書『DX時代の最強PMOになる方法』（ビジネス教育出版社）
目次
やりにくさポイント①お互いをよく知らず、コミュニケーションしづらいやりにくさポイント②ルールの周知徹底がされておらず、迷うことが多いやりにくさポイント③メンバーの入れ替わりが激しく、プロジェクト進行が遅れてしまう【まとめ】部分最適はNG。全体最適を目指して底上げしていくのがPMOの役目書籍紹介
やりにくさポイント①お互いをよく知らず、コミュニケーションしづらい
プロジェクトに入ったメンバーが一度は「どうすればいいのだろう……」と悩むこと、それがプロジェクトメンバー同士の人間関係づくりではないでしょうか。
メンバーは案件ごとにアサインされることが多いため、「プロジェクトも人間関係も１からスタート」ということもよくあり、その場合は、コミュニケーションに時間がかかってしまいがち。さらに、プロジェクトに関わる人数が多くなれば多くなるほど、人間関係はまとまりづらくなってしまいます。
こうした状態でトラブル等が起こってしまうと、「誰に相談すればいいか分からない」「業務の押し付け合いになって、なかなかタスクが進行しない」ということもあるでしょう。
こんなとき、PMOはまず「プロジェクト進行において押さえておくべき人間」をキャッチアップします。
例えば、プロジェクトにベンダーとして2社、事業会社（クライアント）が入り、その仲立ちと進行を担っているPMOがいるとしましょう。PMOはプロジェクトがスタートする際のヒアリングで、「○○さんと△△さんがこのプロジェクトのキーパーソンだから、何か起こった際にはこの人たちに相談すればOKだ」という「アテ」をつけておきます。
また逆に、その工程で「この人はちょっと要注意人物だ……」というのも見えてくるもの。その点も把握しながら、コミュニケーションを進めていけばいいのです。
みなさんもプロジェクトメンバーの一員となった際には、「誰がキーパーソンか」を押さえておきましょう。例えば、このような人が該当します。
・知識や経験豊富でプロジェクト内容を深く理解している
・コミュニケーション能力が高く、他メンバーともつながりがある
・社内で絶大な信頼感を得ている
・企画部門だが、前職がシステムベンダーのためシステムにも知見がある
実は、このキーパーソンを把握できれば、メンバーの性格や個性といったものはそこまで詳しく把握しなくてもOK。「プロジェクト成功」という目的に向かって必要なコミュニケーションをとれる人間関係さえできていれば、問題ないからです。
逆に、一部の人と仲良くなりすぎてしまうとなれ合いが発生して、業務が進行しづらくなる危険性もあります。「適度に距離を持った」人間関係をつくることがおすすめです。
やりにくさポイント②ルールの周知徹底がされておらず、迷うことが多い
「メンバーにプロジェクトのルールが周知徹底されておらず、収拾がつかなくなってしまう」これもよく発生するプロジェクトトラブル「あるある」です。
では、進捗確認のケースで考えてみましょう。
とある企業では週に1回、各自タスクの進捗を確認をする機会があります。しかし、メンバーには報告方法の周知徹底がなされていませんでした。そのためAさんはメールで、Bさんはチャットで、Cさんはメールにもチャットにも進捗報告を送ってくるというカオス状態に。
そこで、PMOは進捗確認の仕組みを整えました。メンバー全員が見られる管理シートをつくり、自分のタスクが終わったら「対応中」から「完了」にステータスボタンを変更できるようにしました。PMOは「このボタン変更は、必ず忘れずに行ってください」ということだけを徹底したのです。
皆さんのプロジェクトでも、管理体制が「属人化」している部分はありませんか？
冒頭でお伝えしたメールやチャットなどバラバラのツールでの報告は、メンバーの時間もそれを確認する管理者の時間も膨大に奪うことになります。
それを効率化したいのなら「仕組み化」一択です。仕組み化の大きなメリットは、「誰でも見れば立ちどころにわかる」という点です。つまり「管理や報告はどうすればいいですか？」という質問に一回一回答えるのではなく、「管理を含むすべての報告方法はここに書いてあるので、これを参照してください。以上」で済むのです。
「迷う」というのはすなわち、「仕組み化されていない」ことに他なりません。「タスク確認が追いつかないから、そのための人員を増やす」というのは間違った方向です。人員を増やさず仕組みで解決する。これがPMO的発想です。
余談ですが、このように仕組み化しておくと、仮にプロジェクトが上手くいかなくなったとき、「○○さんのせいだ」などという事態がほぼなくなります。
「仕組みはよかったけれど、自分の資質がよくなかったのかな」「やらされ仕事になってしまって、スキルを発揮できなかったかも」と、失敗点を自分ごと化しやすくなるメリットもあります。成長ポイントを見出すためにも「仕組み化」は必要不可欠なのです。
やりにくさポイント③メンバーの入れ替わりが激しく、プロジェクト進行が遅れてしまう
やりにくさポイント①で「要注意人物のアテをつける」というお話をしましたが、長期プロジェクトの場合、メンバーの入れ替わりが特に激しくなることもあります。例えば、何らかのトラブルでベンダーさんが交代し、新しいベンダーさんが入るといったときなど、引継ぎやルールの周知などを1から行わなければならないため、その分、進行が遅れてしまうときもあるでしょう。
そんなときも、PMO的には「リスクに備えておく」ことをおすすめします。
ベンダーさんが交代する場合は、必ず事前に何らかの「予兆」があるものです。例えば「クライアントとの衝突が複数回続いている」「進行が遅れているのに『大丈夫です』と返してくる」など。
1回でもこのようなことが起こった場合は、最悪のケースを考えて、いくつか次のベンダーさん候補を自分の中で持っておくと安心です。
もちろん交代にならなければ、そのカードは切らなくてよいですし、クライアントから「もう無理だから何とかしてくれ」と言われれば、「すでにアテはつけてあります」とスムーズに代案を出すことができるからです。
今回はベンダーさん交代の例を出しましたが、これはメンバーの時でも同じです。
「何だか最近、MTGも上の空だな」
「休みがちになってきているな」
「レスポンスが遅いな」といったことが続くメンバーが見受けられるときは、他のメンバーのアサインも視野にいれておくとと良いかもしれません。
【まとめ】部分最適はNG。全体最適を目指して底上げしていくのがPMOの役目
今回は、プロジェクトにおける三つの「やりづらさ」と解消術をご紹介してきましたが、実は、小さなプロジェクトであれば「仕組み化」や「ルール決め」をしなくても、属人化方式で押し通すことはできます。しかし、中規模以上のプロジェクトでその体制が通用するか、というとそれは難しいです。
そのため、関わるプロジェクトの規模が大きくなったのにやり方を変えないでいると、「これまでと同じ方法を行ったのに、プロジェクトが失敗してしまった」「チームが分裂して業務ごと空中分解してしまった」ということが起こってしまうのです。
「Aさん、Bさん、Cさんの中では、このやり方で通用するから大丈夫」というのは部分最適化をしたに過ぎません。
そうではなく、本記事を読んでくださっている読者の方には、20人、30人、果ては100人規模のプロジェクトを動かす「スキル」と「視点」を持っていただきたいのです。
プロジェクトを成功に導くためには、ぜひ、部分最適だけに目を配るのではなく、「このプロジェクトが目指すことは何か？」を常に振りかえりながら、全体最適化を目指していただければと思います。
書籍紹介
『DX時代の最強PMOになる方法』
著：甲州潤
▼こんなエンジニアはぜひお読みください。
・今の仕事に不満を持っていて、現状を変えたいと思っている
・給料をアップしたい
・エンジニアとしての将来が不安だ
・キャリアアップをしたいが、何をしたらいいかわからない
・PMOに興味がある
・PMOとして仕事をしたい
【目次】
第1章 一番稼げるIT人材は誰か
第2章 これからはPMOが1プロジェクトに1人必要
第3章 SEとPMOの仕事は何が違うか
第4章 稼ぐPMOになる７つのステップ
第5章 優秀なPMOとダメなPMOの見抜き方
第6章 PMOが最低限押さえておきたいシステム知識とスキル
第7章 システムは言われた通りに作ってはいけない
第8章 どんな時代でも生き残れる実力をつけよう
>>>詳細はこちら
