はじめに
「なぜマネージャーはこんなことをしているのか？」とマネジメントについて、メンバーの方が疑問に思うことがあります。
この記事は、そんなマネジメント”される”人のための解説記事です。
「マネジメントされる人」の方が人数は多いにも関わらず、「マネジメントされる人」のための文章は多くはありません。
◆記事のねらい
マネジメントの背景に着目して、メンバーとPMの相互理解を深め、衝突を少しでも減らすことを目指します。
◆着目すること
マネジメントの中でも、プロジェクトマネジメントを扱います。そしてメンバーとPMの関係に着目します。
「エスカレーションの方法は・・・」といった具体的な行動ではなく、視野を広げて、なぜそれが求められるのか？といった構造的な背景に着目していきます。
プロジェクトの時系列は①立ち上げ②計画③実行④終結ですが、
メンバーの人数が多い順と考えられる③実行 → ②計画 → ①立ち上げ → ④終結の順番でご紹介します。
プロジェクトは、そのプロジェクト固有の難易度や新規性があります。
そのため絶対的な法則はありません。例外があることは認めつつも、本記事がメンバーの方にとってPMの理解が深まると嬉しいです。
実行フェーズ
①なぜPMは自分で手を動かさないのか？
メンバー目線だと、「PMは指示や調整ばかりしている。なぜPMは手を動かさないのだろう？PMは何もしていないのでは？」と疑問に思うかもしれません。
PMの役割を把握することで疑問の解消に繋がりやすくなります。
PMは「手を動かす」仕事ではなく、「全体を動かす」仕事です。例えるなら「木」ではなく「森」をみる仕事です。「全体の視点を保つために作業はできるだけしない」というのは一つのセオリーです。
木の前に森を見る
(中略)
プロジェクトを進める時には、プロジェクトの目的地と進路を見失わないために、プロジェクトの航海図が必要です。そして、多様な視点からプロジェクトの全容を明らかにしていかなければなりません。
「PMBOK対応 童話でわかるプロジェクトマネジメント」より
また、PMの成果は、極端に言えば「問題が起きないこと」であるため、PMの仕事は目立ちにくいです。そのため、「何もしていないのでは？」とそもそも感じやすい性質があります。
PMの役割に着目すると、メンバーの方は納得感が高まりやすくなります。
②なぜエスカレーション時にメンバーに推奨案を出させるのか？
エスカレーションで、メンバーは①課題②推奨案③根拠を伝えるべきだと言われます。
エスカレーションの鉄則
(中略)
こんなとき、プロは①課題の説明、②推奨案の提示、③根拠の説明、の３つで対処する
メンバー目線だと、「なぜPMは推奨案を考えてくれないのだろう？」と疑問に思うかもしれません。
これは様々な観点から説明できます。
よく聞くのは「育成のため」です。メンバーの教育のために推奨案をメンバーが考えるというものです。
視座を高めて中長期的に考えると、メンバーが推奨案を提示できる状態にする、つまりプロジェクトのリスクを減らすためとも考えられます。
エスカレーションしなければならない大変な場面で、きっと時間も限られており、そこで推奨案をメンバーの方が考えるのは大変な状況かもしれません。
短期的な視点ではなく中長期的に全体をみると、メンバーの方は納得感が高まりやすくなります。
③なぜ「見つけ損」は起きるのか？
改善点を見つけてPMに共有すると、PMから「ではあなたがやっておいて」などのように言われたことがあるかもしれません。そしてメンバー目線だと「見つけ損」のように感じるかもしれません。
前述のように、推奨案を提示するのも、作業するのもPMというよりはメンバーの役割となることが多いです。
もし「見つけ損」のように感じ、モチベーションが下がるのであれば、それは構造に問題があるのではなく、「なし崩し的に」対応するようになってしまったのが問題かもしれません。
「ソフトウェアテストのセオリー」では次のように述べられています。
開発途中で、ソフトウェアに関する事象を発見した際に、その原因分析や対応を、なし崩し的に発見者に担当させることは行ってはいけない。(中略)組織内で事象を発見しようというモチベーションが下がってしまう。
なぜ自分が対応するのか？他の人が対応するほうが良いのでは？などの役割に関して対話することで、メンバーの方は納得感が高まりやすくなります。
④なぜ定例会議は必要なのか？
プロジェクトでは定例会議が設定される場合がほとんどです。
メンバー目線だと、「PMが設定したこの定例会議は不要なのでは？」と疑問に思う場面があるかもしれません。
よく聞くのは「目的がわからない」です。ここではさらに深掘り、なぜ目的がわかりにくいのか？なぜ疑問が生じやすいのか？という背景に着目します。
様々な背景がありえますが、一つの背景はPMがマネジメントすべき多様な領域を一つの「定例会議」で解消しようとすることかもしれません。
プロジェクトマネジメントにおいて検討すべき分野は9つあると言われます。
- スコープ
- 時間
- コスト
- 品質
- 人的資源
- コミュニケーション
- リスク
- 調達
- ステークホルダ
そして、これらをまとめ、調整する「統合」があります。
検討すべき分野が複数ある中で、これらを「定例会議」という1つの抽象的な枠組みでマネジメントしようとすると、会議の目的を見失いやすくなります。目的を見失うと、「この会議は不要なのでは？」という疑問が生じやすくなります。
目的をより明瞭にするために、「定例会議」という名前をやめる方法があります。
例えば、書籍「Amazonのすごい会議」では、4種類の会議が紹介されます。
意思決定会議、アイディア出し会議、進捗管理会議、情報伝達会議です。名前をつけることで目的が明瞭になりやすいです。
これはあくまで一例ですが、「いま何をマネジメントしようとしているか？」に着目し、その目的を考えることでメンバーの方は納得感が高まりやすくなります。
⑤なぜリーダーシップがないのか？
プロジェクトを推進していると、「このPMはリーダーシップがないのでは？」と感じる場面があるかもしれません。
そもそもリーダーとマネージャーの違いを把握することで、疑問が解消しやすくなります。
「PMBOK第7版実践活用術」では次のように述べられています。
リーダー：ビジョンを提示し、人々を鼓舞し、動機づける。そしてリスクを取り、イノベーションを促し、信頼を築く。
マネジャー：タスクを割り当て、計画を進め、リスクを低減する。プロジェクトの流れをうまく掴み、計画通りに仕事を進めることに注力する。
一方で、「プロジェクトマネジメントをする上でリーダーシップが完全にない」ということはほとんどないでしょう。
「リーダーロール」と「マネジメントロール」は、AかBかのような二項対立ではなく、グラデーションです。
状況によって使い分けることがほとんどです。いまの「リーダーロール」と「マネジメントロール」の力点を考えることで、メンバーの方は納得感が高まりやすくなります。
計画フェーズ
⑥なぜ時間がないときにも計画は必要なのか？
時間がないときでも、PMからまず計画の作成を指示されることがあります。
メンバー目線だと、「時間がないので、計画策定よりも先に着手したほうがいいのでは？」と思う場面もあるかもしれません。
これは様々な理由があります。一例を紹介します。
- 時間のムダを最小限に抑えるため
- 限られた時間で最大の成果を出すため
- 致命的ミスを防ぐため
- 改善に繋げるため、仮に失敗したとしても次に繋げやすいため
「計画策定の時間がないのに」と感じたときは、中長期的な視点に立つと計画を作成したほうが早いかもと気づけるかもしれません。
「PMプロジェクトマネジメント」の「計画策定の時間がない・・・？」のコラムでは次のように述べられます。
プロジェクトマネジメントのセミナーなどで計画の大切さを強調すると、受講者から受ける指摘（反論？）がある。それは「計画が大切なことはわかったが、計画策定の時間はない。忙しくて！」というものだ。この指摘は世界中で出されるものだが、洋の東西を問わず、コンサルタントの回答は同じである。「なるほど、確かにみなさんとても忙しそうだ。計画策定の時間がないというのも本当かもしれない。でもよく見てみると、やり直しをする時間はいくらでもあるんだね。」
そのときの計画策定のことだけでなく、実行、そしてうまくいかない場合までを想像すると、メンバーの方は納得感が高まるかもしれません。
⑦なぜ計画修正が起きてしまうのか？きちんと計画しておくべきでは？
プロジェクトでは計画修正がおきることがほとんどです。
メンバー目線では「計画フェーズできちんと計画しておくべきでは？」のように思うこともあるかもしれません。
そもそもプロジェクトの計画は変更される前提です。PMのバイブルである「PMBOK」では、計画＝「ベースライン」+「変更管理」のように、変更が前提で考えられます。不確実性は常に存在し、予測できないためです。
また、「計画性重視vs柔軟性重視」の構造を把握することで、メンバーの方は変更への納得感も高まりやすくなります。
状況によって計画性を重視した方がいい場面と、柔軟性を重視した方がいい場面は異なります。
立ち上げフェーズ
⑧なぜプロジェクト目標は必要なのか？
プロジェクトには「MM月までにリリース完了」のようなプロジェクト目標があります。
特に、PMが設定した目標に対して、メンバー目線だと「目標はなぜあるのか？」と疑問に思うこともあるかもしれません。
これはプロジェクトの成功とは何かを言語化するためです。目標がなければ、何をもって「成功」と言えるかが不明確です。加えて、方向性が明確になり、協力しやすくなります。
さらに目標を考えること自体が重要な場合があります。プロジェクトのことを考えること自体が重要だからです。例えば、目標策定時に気づきを得ることがあります。
目標は自分で決めると自発的になりやすいです。
自分たちで目標を決めると自発的になる
「PMBOK対応 童話でわかるプロジェクトマネジメント」より
すでに目標が決まっているのであれば、プロジェクト目標を再考することで、メンバーの方は納得感が高まりやすくなります。
⑨なぜドキュメントを使い回さないのか？プロジェクトのたびに作成しているのか？
プロジェクトでは、たくさんのドキュメントを作成します。
その際に、メンバー目線では「過去のプロジェクトからもっと転用できるのでは？」と疑問に思うことがあるかもしれません。
これは、プロジェクトそのものの性質を知ることで疑問の解消に繋がります。
プロジェクトは日常業務とは違う (中略) 今までやったことがない、特別な仕事です（独自性・新規性）
「PMBOK対応 童話でわかるプロジェクトマネジメント」より
当たり前のようにプロジェクトに関わるので、プロジェクトそのものの性質を忘れがちですが、「プロジェクトは新しくて固有のものだ」ということを理解することで、メンバーの方は納得感が高まりやすくなります。
終結フェーズ
⑩なぜ評価をするのか？
プロジェクトの終盤、プロジェクトの振り返りや評価を行うことがあります。
メンバーの方は「もう終わったのに、なぜ評価をするのだろう？」と疑問に思うことがあるかもしれません。
プロジェクトの評価は、次のプロジェクトに繋げるために必要なものです。
プロジェクトは固有のものではあるとはいえ、共通点もあります。知見を整理して次に繋げる必要があります。
重要なのは、成功からも失敗からも学ぶということだ。プロジェクトが成功したら小さからぬ達成である。素直に喜ぼう。そして、その成功の要因（と、さらなる改善点）を文書化し、次のプロジェクトに申し送る。失敗については、改善点に関する具体的な提案を文書化して次のプロジェクトに申し送る。
そのプロジェクトだけでなく、プロジェクトとプロジェクトの関係のような視座の高い目線を持つことで、メンバーの方は納得感が高まりやすくなります。
この記事を書くきっかけ
最後にこの記事を書くきっかけをご紹介して結びとさせていただきます。
本記事執筆は、「両利きのプロジェクトマネジメント」を読んだのがきっかけでした。
私たちは、同じものを見ているようで同じものを見ていません。それぞれの視点からプロジェクトの状況を「見たいように見ている」に過ぎないのです。
プロジェクトを進めると、メンバー目線とPM目線ですれ違うことがあります。「PM目線の意図や背景、そして構造を、ある一例だけでも説明できれば衝突を減らせるのでは？」と考え、本記事の執筆に至りました。
興味が湧いた方は「両利きのプロジェクトマネジメント」をぜひ手に取っていただければと思います。
また、「両利き」を身近なテーマで説明しようと試みて「両利きの夫婦運営」という記事も書きました。もしよければこちらも読んでいただけると幸いです。「両利き」を理解しやすくなると嬉しいです。
おわりに
この記事では、マネジメントされる人向けに、プロジェクトマネジメントの背景をご紹介しました。
一言でまとめると、「中長期的な視点を考える」ことで、PMの意図が掴みやすくなると思います。 加えて、本記事で見てきたように、PMとメンバーの「役割の違い」を意識することや、プロジェクト特有の「不確実性・固有性といった前提」を理解することも、すれ違いを減らす鍵となるでしょう。
参考になれば幸いです。