できるPMOは何が違う?
勝てるvs崩壊チーム「個人の力」を「組織の成果」へ。 数々のプロジェクトを支えてきた甲州潤氏が、PMOの視点から「勝てるチーム」の作り方を明かします。崩壊するチームとの比較を通じて、現場で求められる振る舞いや具体的なマネジメント手法を紹介。プロジェクトを成功へ導く、PMOの新常識をお届けします。
NEW! スキル
できるPMOは何が違う?
勝てるvs崩壊チーム「個人の力」を「組織の成果」へ。 数々のプロジェクトを支えてきた甲州潤氏が、PMOの視点から「勝てるチーム」の作り方を明かします。崩壊するチームとの比較を通じて、現場で求められる振る舞いや具体的なマネジメント手法を紹介。プロジェクトを成功へ導く、PMOの新常識をお届けします。
「それでは定例会を始めます。まずは各担当から進捗の報告を……」
30人が集まり、1時間にわたるオンライン会議が終了。
「お疲れ様でした」と画面が閉じられた瞬間、参加者の多くが「で、結局、明日から何をすればいいんだっけ?」と首をかしげる。
あるいは、PMが一人で1時間延々と悩みや持論を語り、メンバーは「分かりました」と定型文を返すだけ。そして1週間後、チャットには「先週の件、ファイルの場所が分からず進めていません」というメッセージが流れる――。
これは、多くの現場で起きている「生産性のない会議」の実態です。
あなたも、経験があるでしょうか?
一方で、PMOが介入する会議は、これとは真逆の「生産性の高い会議」です。
その定義はとてもシンプルで、言い換えれば「行動に起こせる会議」。
つまり、会議が終わった瞬間に、全員が「次に踏み出す一歩」を解像度高く見えている状態です。
では、どうすれば、そのような会議を作れるのか。
シリーズ4回目の今回は、私がPMOとして実践している会議の設計術を解説します。
株式会社office Root(オフィスルート)
代表取締役社長
甲州 潤(こうしゅうじゅん)
国立高専卒業後、ソフトウェア開発企業でSEとして一連の開発業務を経験し、フリーランスに転身。国内大手SI企業の大規模プロジェクトに多数参画し、優秀な人材がいても開発が失敗することに疑問を抱く。PMOとして活動を開始し、多数プロジェクトを成功へ導く。企業との協業も増加し、2020年に法人化。さまざまな企業課題と向き合う日々。著書『DX時代の最強PMOになる方法』(ビジネス教育出版社)
目次
生産性のない会議には、共通する「負の構造」があります。
一例を紹介しましょう。
■独演会と化したPM
「客先ではこう言われたけど、僕はこう思う。でもこれだとマズいかな……」など、PMがひたすら自分の思考のプロセスを垂れ流し、結論が見えない無駄な時間。
■「分かりました」という名の思考停止
エンジニア特有の力学(早くコードを書きたい、議論が不毛だと判断したなど)で、その場を早く終わらせるために返事をするだけで、あとから確認すれば良いか、という状態になっている。
■コスト意識の欠如
週に何度も何十人も集まって、会議をしている。10人が1時間集まれば、10時間分の人件費(コスト)が発生することの認識がない状態。会議によるアウトプットが見合っていない状態。
こうした負の構造が見られる会議において、多くの場合、招集したPMなどは「これだけ丁寧に情報共有しているんだから伝わっているはずだ」と思い込んでいます。
しかし、集まった参加者たちにはまるで響いていません。この深刻な「認識のズレ」が発生することにより、せっかくの会議はただ各々の大事な時間を奪い、コストの無駄遣いにつながってしまうのです。
【実録】その「分かりました」は、Yesを意味しない
私もかつて、この言葉の定義のズレでプロジェクトを停滞させたことがあります。 会議で作業を依頼した際、エンジニアから「分かりました」と快諾を得たので安心していたのですが、2週間後に状況を確認すると、なんと作業は1ミリも進んでいませんでした。
彼らにとっての「分かりました」は、単に「あなたの言っている意味(日本語)は分かりました」であって、「タスクとして着手します」という承諾ではなかったのです。「正式な指示や承認がないので動かなかった」という彼らの言い分を聞き、会議での合意がいかに虚無であったかと痛感しました。
では、会議を「行動の場」に変えるにはどうしたらよいのでしょうか。
PMOなら、当日の進行よりも「事前の設計」に心血を注ぎます。
具体的には、次のことを行います。
[1]会議通知の「型」を徹底する
一人一人に自分ごととして会議に参加してもらうため、「定例」というぼんやりしたタイトルだけのカレンダー招待は送りません。
以下の項目をセットで通知します。
●目的:何を決めるための時間か(例:A機能の仕様確定)
●アジェンダ:何をどの順番で話すか
●役割:誰がどのパートを報告し、誰が判断するのか
●事前のお願い:「この資料を読み込んで、懸念点を一つ出しておいてください」といった具体的な宿題
[2]役割を可視化する
例えば、新しくチームに加わった人には「自己紹介の時間を5分取る」。
報告者には、事前に「結論から話すようにお願いします」と伝えておく。
会議の要約まとめ・共有役を輪番で設定するなど、参加者が「ただ座っているだけ」にならない仕掛けを施します。
また、PMOは会議で発する質問も工夫します。これは、単なる確認ではありません。目的は、「情報の解像度を強制的に上げる」ことにあります。
例えば、ある事項についてメンバーが「確認しておきます」と言ったとき、PMOはこう質問します。
「具体的にどうやって確認しますか? 電話ですか? 相手が不在なら誰に聞きますか?」
あるいは、「一覧を更新します」といった報告にはこう質問を返します。
「どのフォルダのファイルですか? 最新版だと判別するルールは何ですか?」
少し細かすぎるように感じるかもしれませんが、これらの質問は全て「もし自分がその作業をやる立場なら、何が不明か?」というシミュレーションに基づいたものです。
つまり、会議が終わった後の「次の一歩」を踏み出す際に、つまずいたり誤解が生まれたりしやすい部分を、あらかじめあぶり出しているわけです。
質問を受けて、その場で
「メールで確認しようと思っていましたが、納期を考えると電話のほうが早そうですね」
「あ、私は古い方のファイルだと思ってました」
といった声が上がれば、1週間後の次の会議での手戻りを防げたことになります。
チーム内で、前回の記事(「最終版ファイル」が乱立する現場はチーム崩壊の危険信号!「情報格差」をゼロにする五つのチェックリスト)にて紹介した情報格差が少ない状態であれば、このような確認が不要になることが多いので、合わせて確認しましょう。
また、上記に挙げた例は基本的な確認やファイルの更新についての話ですが、作業の進め方や仕事を行う順番などに関しては、曖昧なまま依頼したり受け取ったりする場面が意外と多いです。
作業の具体イメージが無いままとりあえず進めて、「思っていたのとは違った」ということはよくあります。
その場合は、個別に時間をとって、進め方やアプローチの方向性をすり合わせるようにしましょう。
「自分は技術に詳しくないから、高度な会議のファシリテートは無理だ」という人もいるかもしれませんが、諦める必要はありません。PMOが技術の深いところまで理解している必要はありませんが、「ロジックの整合性」を問うことはできます。
例えば、エンジニアから信頼されるPMOは、単に「分からない」と聞くのではなく、システムの「例外パターン」を問う形で、あえて無知を晒します。
そんなときに実践する質問例をご紹介しましょう。
「正常系」の先を問う
「今の説明で、正常に動くケースは理解できました。では、もしDBがダウンした瞬間にこの処理が走ったら、データはどうなりますか?」
「例外系」の定義を促す
「先ほど『エラー時はよしなに対応する』とおっしゃいましたが、それは具体的に成功するまで何度か自動でやり直すということですか? それともそれとも、エラーが出た瞬間に作業前の状態に直す設計ですか?」
このように、エンジニアが最も神経を研ぎ澄ませる「例外処理」や「整合性」にスポットを当てる質問は、結果としてチームの「分からないこと」を可視化させ、設計漏れを防ぐことにもつながります。
PMOが「分からないこと」を晒すのは、恥ではありません。むしろ、曖昧な言葉(「よしなに」「確認する」)を技術的な解像度まで引きずり出すことで、チーム全体の認識のズレを未然に防ぐ「防波堤」になれるのです。
もちろん、自分で調べれば分かるような基本的な知識や一般的な知識を身に付ける努力は必要です。
その上で、質問するようにしましょう。
あなたのチームが「価値を生む会議になっているか」を判断する五つの指標をまとめました。ぜひチェックしてみてください。
| チェック項目 | 判定基準 |
|---|---|
| 次の一歩 | 会議直後、全員が迷わず作業に着手できるか? |
| 決定と意見の分離 | 「決まったこと」と「個人の見解」が明確に区別されてまとめられているか? |
| プロセス | 「1.ビルド実行、2.ログ確認、3.疎通確認……」 |
| 費用対効果 | 参加人数 × 時間に見合う「決定」「議論」がなされたか? |
| 認識の不一致 | 「あの件、どうなってたっけ?」「〇〇だと思っていました」という後日のチャットが減ったか? |
| 当事者意識 | 参加者全員が、一度は発言または役割を全うしたか? 「耳だけ参加する」という参加者はいなかったか? |
あなたが主催する会議において、「意見はありますか?」と問いかけても何もリアクションがない。
そんなときは、「一体、これは何のための会議なんだ?」と疑問を持つこともあるでしょう。
なかなか意見が出ない会議を改善しようと、
「雰囲気を盛り上げるために、メンバー同士仲を深める機会をつくろう」
「雑談の時間をもっと入れ込んでみようか」などと考える人もいるかもしれません。
しかし、会議の目的は、仲良く話すことではありません。
あくまでもプロジェクトを前に進めるための「意思決定と行動のトリガー」となる場であるべきだと私は考えています。
会議を経て、どのような行動につなげれば、プロジェクトを円滑に前進できるのか。
PMOは、そうした「結果(ゴール)」を見据えて行動しているのです。
もし、今のチームの会議に手応えを感じていないのなら、まずは次の会議通知に「この会議のゴールは〇〇が決まることです」と一行書き添えることから、ぜひ始めてみてください。
PMOの視点を少し取り入れるだけでも、停滞していたチームは驚くほどスムーズに動き始めるはずです。
「こんなトラブルで困っているんだけど、どうすればいい?」
「PMOなら、こんなときどんな手を使う?」などの質問や、今後取り上げてほしいテーマなどがあれば、ぜひ下部の「ご意見・ご要望はこちら」までお気軽にお寄せください。
『DX時代の最強PMOになる方法』
著:甲州潤
▼こんなエンジニアはぜひお読みください。
・今の仕事に不満を持っていて、現状を変えたいと思っている
・給料をアップしたい
・エンジニアとしての将来が不安だ
・キャリアアップをしたいが、何をしたらいいかわからない
・PMOに興味がある
・PMOとして仕事をしたい
【目次】
第1章 一番稼げるIT人材は誰か
第2章 これからはPMOが1プロジェクトに1人必要
第3章 SEとPMOの仕事は何が違うか
第4章 稼ぐPMOになる7つのステップ
第5章 優秀なPMOとダメなPMOの見抜き方
第6章 PMOが最低限押さえておきたいシステム知識とスキル
第7章 システムは言われた通りに作ってはいけない
第8章 どんな時代でも生き残れる実力をつけよう
>>>詳細はこちら
タグ