「PMとしてもっと成長したい」

そう思ったとき、何を身につければよいのでしょうか。

コミュニケーション能力でしょうか。

リーダーシップでしょうか。

ロジカルシンキングでしょうか。

あるいは、プロジェクトマネジメントの専門知識でしょうか。

PMに求められるスキルは非常に多くあります。

そして、PMとして経験を積めば積むほど、

「PMに必要なスキルは一つではない」

ということを実感するようになります。

私は、PMに必要なスキルを大きく4つに分けて考えています。

• 対人スキル
• 思考系スキル
• PM専門系スキル
• 業務・技術系スキル

そして、私が重要だと考えている順番もこの順番です。

特に重要なのは、対人スキルです。

PMは「人を通じて」プロジェクトを動かす

なぜ対人スキルが一番重要なのでしょうか。

PMは、必ずしも自分自身が専門技術を使って成果物を作る仕事ではありません。

プログラマーのようにプログラムを書くわけでもありません。

ハードウェア設計者のように設計をするわけでもありません。

品質保証の担当者のように、品質そのものを管理するわけでもありません。

もちろん、こうした業務や技術を理解することは重要です。

しかし、PMの仕事の中心にあるのは、人と人の調整です。

• プロジェクトメンバーとの調整
• チーム間の調整
• 顧客との調整
• 上司との調整
• ベンダーとの調整
• ステークホルダーとの調整

つまり、

PMは、人を通じてプロジェクトを動かす仕事です。

だからこそ、私は対人スキルを最も重要だと考えています。

① 対人スキルはPM戦闘力の土台になる

PMに必要な対人スキルには、さまざまなものがあります。

コミュニケーション

自分の考えを伝えるだけではありません。

相手の理解度を確認し、認識を合わせ、必要な情報を必要な人に伝える。

PMにとって基本となるスキルです。

ファシリテーション

会議を開催するだけではありません。

• 論点を整理する
• 意見を引き出す
• 対立を整理する
• 合意形成する
• 次のアクションにつなげる

といったことが求められます。

交渉

プロジェクトでは、すべての要求をそのまま受け入れられるわけではありません。

納期、コスト、品質、スコープなど、さまざまな制約の中で関係者と合意を作る必要があります。

リーダーシップ

PMは、役職上の上司とは限りません。

自分の部下ではないメンバーや、別会社のベンダー、顧客などを巻き込みながらプロジェクトを進める必要があります。

そのため、単純な「指示する力」だけでは足りません。

傾聴

PMが話すだけでは、プロジェクトの状況を正しく把握できません。

• メンバーが何に困っているのか
• 顧客が何を不安に思っているのか
• ステークホルダーが何を求めているのか

こうした情報を拾うためには、傾聴する力が必要です。

サーバントリーダーシップ

PM自身がすべてを指示するのではありません。

メンバーが力を発揮できる環境を作ります。

必要な障害を取り除き、メンバーを支援する。

こうした考え方も、PMにとって重要なスキルだと考えています。

コミュニケーションが苦手でもPMはできる

ここで、私自身の経験を少し紹介します。

私は、もともとコミュニケーションが得意なタイプではありません。

それでもPMとして仕事をする中で、

「コミュニケーションが苦手だからPMができない」わけではない

と感じるようになりました。

私の場合、コミュニケーションそのものを得意にするというより、

コミュニケーションを仕組みとして設計する

ことを意識するようになりました。

その一つが、キックオフミーティングです。

キックオフでは、単にプロジェクトの予定や役割を説明するだけではありません。

• なぜこのプロジェクトをやるのか
• プロジェクトの目的は何なのか
• 何を大切にして進めるのか
• メンバーにはどのように関わってほしいのか

といったことを、最初にしっかり伝えるようにしました。

すると、プロジェクトメンバーがプロジェクトの目的や重要性を理解しやすくなりました。

モチベーションを高めることにもつながりました。

結果として、プロジェクトをより効果的にマネジメントできるようになりました。

これは、

コミュニケーションが得意だからできたことではなく、コミュニケーションをどう設計するかを考えた結果

だと思っています。

② 思考系スキルは問題を解決する力になる

2つ目は思考系スキルです。

具体的には、次のようなスキルです。

• ロジカルシンキング
• 問題解決
• 判断力
• リスクを予測する力
• 政治力
• 全体を俯瞰して見る力

PMは、日々さまざまな問題に直面します。

そのとき、

「何となく問題がありそう」

だけでは、適切な対応はできません。

• 何が問題なのか
• なぜ問題なのか
• どこに影響するのか
• 何を優先すべきなのか
• 誰に相談すべきなのか
• どうすれば問題を防げるのか

こうしたことを考える力が必要になります。

「全体を見る力」がPMには必要

PMは、個別のタスクだけを見ていてはいけません。

例えば、あるチームの作業が1週間遅れるとします。

単純に、

「1週間遅れているから、そのチームに頑張ってもらおう」

と考えるだけでは不十分です。

その遅れによって、次のような影響を考える必要があります。

• 次のチームにどんな影響があるのか
• スケジュール全体にどう影響するのか
• コストは増えるのか
• 品質に影響するのか
• 顧客への説明が必要なのか
• 他のリスクが増えるのか

つまりPMには、

個別の問題を見ながら、同時にプロジェクト全体を見る力

が求められます。

③ PM専門系スキルはプロジェクトを管理する専門力

3つ目は、プロジェクトマネジメントそのものに関する専門スキルです。

例えば、次のようなものがあります。

• スコープマネジメント
• スケジュールマネジメント
• コストマネジメント
• リスクマネジメント
• コミュニケーションマネジメント
• ステークホルダーマネジメント
• リソースマネジメント
• 品質マネジメント

こうしたPMの知識を体系的に学ぶことは重要です。

PMBOK®︎などを通じて、プロジェクトマネジメントの考え方を体系的に学ぶこともできます。

ただし、ここでも注意したいことがあります。

知識を知っていることと、PMとして使えることは別です。

「知っている」と「できる」は違う

例えば、リスクマネジメントについて知識があったとしても、

「このプロジェクトでは、どんなリスクが重要なのか？」

を判断できなければ、実務では十分に活用できません。

コミュニケーションについて知っていても、

「誰に、いつ、何を伝えるべきなのか？」

を判断できなければ、プロジェクトはうまく動きません。

つまり、

PMスキルは、知識を持っているだけでは完成しません。

私は、

知る → 身につける → 体現する

という3段階が必要だと考えています。

④ 業務・技術系スキルはプロジェクトを理解する力になる

最後が、そのプロジェクトに関する業務・技術系スキルです。

例えば、次のようなものがあります。

• プログラミング
• ハードウェア設計
• 品質保証
• 製造
• 建設
• ITインフラ
• 業界固有の知識

PMが必ずしも専門家である必要はありません。

しかし、そのプロジェクトで何が行われているのかを理解するためには、一定の業務・技術知識が必要です。

技術的な難しさを理解できなければ、リスクを把握できないこともあります。

顧客の要求の難しさを判断できないこともあります。

そのため、業務・技術系スキルもPM戦闘力を構成する重要な要素です。

ただし、私はPM専門系スキルよりもさらに上位に、

対人スキルと思考系スキル

があると考えています。

専門技術が高い人が、必ずしも強いPMになるわけではない

ここはPMを目指す人に伝えたいポイントです。

技術者として非常に優秀だった人がPMになるケースは多くあります。

そして、技術を理解していることは大きな武器になります。

しかし、

技術力が高い＝PMとして強い

ではありません。

PMになった瞬間、仕事の中心が変わるからです。

自分で設計する。

自分でプログラムを書く。

自分で成果物を作る。

という仕事から、

人を動かし、調整し、判断し、プロジェクト全体を成功に導く仕事

へ変わります。

そのため、技術力をさらに高めるだけではなく、対人スキルや思考系スキルを身につける必要があります。

スキルは「持っているだけ」ではPM戦闘力にならない

ここまで、PMに必要なスキルを紹介してきました。

しかし、PM戦闘力という観点では、もう一つ重要なことがあります。

それは、

スキルを持っているだけでは不十分

ということです。

例えば、ファシリテーションの本を読んだ。

研修を受けた。

資格を取得した。

これらはスキルを身につけるための重要なステップです。

しかし、それだけで実際のプロジェクトをうまくファシリテーションできるようになるとは限りません。

実際の会議では、想定外の意見が出てきます。

参加者同士が対立することもあります。

話が脱線することもあります。

誰も発言しないこともあります。

そうした状況の中で、実際にスキルを使ってみる。

そして、うまくいかなかったところを振り返る。

次の会議で改善する。

この繰り返しによって、スキルが「自分のもの」になっていきます。

PMスキルは「知る→身につける→体現する」

私は、PMスキルを身につける流れを、

知る → 身につける → 体現する

と考えています。

① 知る

まず、そのスキルが存在することを知ります。

例えば、

「ファシリテーションというスキルがある」

と知ることです。

② 身につける

本を読んだり、研修を受けたり、実際に勉強したりします。

スキルの考え方や方法を理解します。

③ 体現する

実際のプロジェクトで使ってみます。

そして、

「自分だったらどう使えばいいのか」

を考えます。

ここまでできて、初めてそのスキルがPM戦闘力につながっていくと考えています。

知るための方法として、プロジェクトマネジメントに関わる本を読んではいかがでしょうか。おすすめ本をまとめました。

【厳選】プロジェクトマネジメント（PM）のおすすめ本12選！フェーズ・悩み別に徹底解説

スキルは才能ではなく、意識して伸ばせる

ここまでの話をすると、

「コミュニケーションが苦手だからPMには向いていない」

と思う人もいるかもしれません。

しかし、私はそうは考えていません。

もちろん、人によって得意・不得意はあります。

私自身も、コミュニケーションが得意なタイプではありませんでした。

それでも、

「どうすればプロジェクトメンバーに必要なことを伝えられるか？」

を考えました。

そして、キックオフという場を使って、最初にプロジェクトの目的や方針を共有する方法を実践しました。

その結果、コミュニケーションをPMの武器として使えるようになりました。

大切なのは、

「自分には才能がない」と考えることではありません。

まず、自分に必要なスキルを知ります。

そして、そのスキルについて学びます。

実際のプロジェクトで使ってみます。

振り返ります。

また使ってみます。

このサイクルを繰り返します。

そうすれば、PMスキルは意識して伸ばしていくことができます。

経験とスキルは、お互いにPM戦闘力を高める

前の記事では、PM経験の「質」について考えました。

今回の記事では、PMスキルについて考えました。

この2つは、別々のものではありません。

むしろ、

経験とスキルは相互に作用します。

プロジェクトを経験する。

↓

そこから問題や教訓を得る。

↓

スキルを身につける。

↓

次のプロジェクトで使う。

↓

新しい経験を得る。

↓

さらにスキルを高める。

この循環によって、PM戦闘力は高まっていきます。

だからこそ、

経験年数を増やすだけでもダメ。

スキルを勉強するだけでもダメ。

経験とスキルを、自分自身でつなげていくことが重要なのです。

まとめ：PMスキルは「知識」ではなく「使える力」にする

PMに必要なスキルは、大きく4つに分けられます。

対人スキル

コミュニケーション、ファシリテーション、交渉、リーダーシップ、傾聴、サーバントリーダーシップなどです。

思考系スキル

ロジカルシンキング、問題解決、判断力、リスクを予測する力、政治力、全体を俯瞰して見る力などです。

PM専門系スキル

プロジェクトマネジメントに関する体系的な知識や実践力です。

業務・技術系スキル

そのプロジェクトに必要となる業務知識や技術知識です。

私は、この中でも特に対人スキルを重要だと考えています。

PMは専門技術を自分で使って成果物を作る仕事というより、人を通じてプロジェクトを動かす仕事だからです。

そして、どのスキルについても、

知っているだけではPM戦闘力にはなりません。

知る → 身につける → 体現する

というところまで進める必要があります。

研修や書籍、資格などを通じてスキルを学ぶことは、そのための重要な手段です。

しかし、最終的にそのスキルを自分のものにするのは、実際のプロジェクトで使うことです。

だからこそ、PMスキルは才能だけで決まるものではありません。

自分に必要なスキルを知り、学び、実践し、振り返る。

この繰り返しによって、PM戦闘力は少しずつ高めていけるのだと思います。

あなたは、今どのPMスキルを伸ばしたいでしょうか？

そして、そのスキルを実際のプロジェクトで「体現」できているでしょうか？

PM戦闘力シリーズ

• PM戦闘力とは？PMとしての強さを決める要素を考えてみた
• PM経験年数だけでは戦闘力は上がらない？経験の質が重要な理由
• PM資格は本当に必要？資格を「戦闘力の装備」として考える
• PMの実績とは何か？「トラブルを解決した」だけが実績ではない
• なぜトラブルを起こさないPMは評価されにくいのか？
• あなたのPM戦闘力はどれくらい？PM戦闘力を自己診断する
• PM戦闘力を高めるには？「経験→実践→振り返り」の成長サイクルを回そう
• PM戦闘力と市場価値の関係とは？PMとしての実力を転職市場でどう伝えるか

The post PM戦闘力を高めるPMスキルとは？重要な4つのスキルを考えてみた first appeared on PM道場.

そう聞くと、PM経験5年の人よりもPMとして強そうに感じるかもしれません。

確かに、PMとして長く仕事をしてきたことは、それだけで一つの強みです。

さまざまなプロジェクトを経験し、さまざまな問題に向き合ってきた可能性があります。

しかし、私はPM経験年数だけでは、その人のPM戦闘力を判断できないと考えています。

なぜなら、同じ「PM経験10年」でも、経験してきたプロジェクトの難しさや、そこから何を学んできたかによって、PMとしての強さは大きく変わるからです。

PM戦闘力を高めるために重要なのは、単純な経験年数ではありません。

どのような経験をしたのか。

そして、その経験から何を学び、次のプロジェクトで何を変えたのか。

今回は、PM経験の「質」について考えてみます。

PM経験年数は重要。でも、それだけでは足りない

まず、誤解のないようにしておきたいのですが、私は「PM経験年数なんて意味がない」と考えているわけではありません。

むしろ、経験年数はPM戦闘力を考えるうえで重要な土台です。

1年目のPMと10年目のPMでは、経験してきたことに大きな差があるでしょう。

ただし、

経験年数＝PM戦闘力

ではありません。

重要なのは、

経験をどのようにPMとしての能力に変えてきたか

です。

同じ10年間でも、毎回似たようなプロジェクトを、同じような方法で進めてきた人と、異なる環境・難易度のプロジェクトに挑戦し、そこで得た教訓を次のプロジェクトに活かしてきた人では、経験の価値は変わります。

だから私は、

PM経験年数は「経験の量」を表す一つの指標であって、経験の質まで表しているわけではない

と考えています。

PM経験の「質」は何で決まるのか？

では、どのようなプロジェクトを経験すると、PMとしての経験値が高まるのでしょうか。

私自身の経験から考えると、特に重要なのは次の5つです。

• ステークホルダーの難しさ
• メンバーの多さ
• 技術の難しさ
• メンバーの質
• ベンダーの多さ

もちろん、これだけが全てではありません。

しかし、こうした条件が複雑になるほど、PMにはより高度なマネジメントが求められます。

① ステークホルダーが難しい

私が経験値が高いと感じるプロジェクトの中でも、特に重要なのがステークホルダーの難しさです。

例えば、次のような状況です。

• 初めて取引する顧客
• 自社に対して良い印象を持っていない顧客
• 要求が非常に多い顧客
• 意思決定者が複数いる
• 顧客と自社で利害が一致していない
• 社内でもプロジェクトに対する考え方が異なる

プロジェクトマネジメントは、計画を作って、その通りに進めれば終わる仕事ではありません。

人が関わる以上、認識の違いや期待値の違いが生まれます。

ステークホルダーが難しくなるほど、PMに求められる能力も増えていきます。

• コミュニケーション
• 交渉
• 期待値のコントロール
• 合意形成

そのため、難しいステークホルダーとのプロジェクトを経験することは、PMの戦闘力を高める大きな経験になると考えています。

② メンバーが多い

メンバーが増えると、単純に管理する人数が増えるだけではありません。

例えば、10人のメンバーを一つのチームとして管理するのではなく、複数のチームに分ける必要が出てくるとします。

すると、次のような新しいマネジメントが必要になります。

• チーム間の認識合わせ
• チーム間の依存関係
• チーム間の優先順位
• チーム間のコンフリクト
• 情報共有

人数が増えることで、

「一人ひとりとコミュニケーションを取ればいい」

というマネジメントから、

「チームという単位をマネジメントする」

という段階に変わっていきます。

これもPMとして重要な経験です。

③ 技術的な難しさ

技術的に難しいプロジェクトも、PMにとって貴重な経験になります。

• そもそも技術的に成功する可能性が低い
• やってみなければ結果が分からない
• 前例がない

このようなプロジェクトでは、単純に「計画通りに進める」だけでは対応できません。

例えば、

「もし技術的に実現できなかったらどうするのか？」

というところまで考えておく必要があります。

場合によっては、失敗した場合の代替案や関係者への説明方法まで、事前に準備しておく必要があるでしょう。

つまり、技術的な難しさが増えるほど、

不確実性をマネジメントする力

が求められます。

こうした経験は、次のプロジェクトでリスクを考えるときにも活きてきます。

④ メンバーの質

メンバーの経験やスキルも、プロジェクトの難易度を大きく左右します。

例えば、経験豊富なメンバーが揃っているプロジェクトであれば、PMが細かく指示を出さなくても、それぞれが自律的に動けるかもしれません。

一方、若手メンバーが多いプロジェクトでは、そうはいきません。

プロジェクトを進めるだけではなく、

メンバーを育成すること

も必要になります。

• 何をすべきなのか
• なぜそれをするのか
• どういう観点で仕事をしてほしいのか

こうしたことを伝えながら、プロジェクトそのものも前に進めなければなりません。

これは、単なるタスク管理とは違うPM経験です。

⑤ ベンダーが多い

複数のベンダーが関わるプロジェクトも、PMにとって難易度が上がります。

ベンダーごとの管理だけならまだしも、複数のベンダーが関係すると、

ベンダー同士をどう連携させるか

という問題が出てきます。

例えば、次のような状況です。

• A社の作業が終わらないとB社が作業できない
• A社とB社で責任範囲の認識が違う
• ベンダー間で優先順位が異なる
• 問題が発生したときに責任の所在が曖昧になる

ここではベンダーマネジメントだけではなく、ベンダー間の調整も必要になります。

これもPMとして重要な経験になります。

重要なのは「難しいプロジェクトを経験した数」だけではない

ここまで読むと、

「では、とにかく難しいプロジェクトをたくさん経験すればいいのか？」

と思うかもしれません。

私は、それも少し違うと考えています。

もちろん、さまざまな状況のプロジェクトを経験したほうが、PMとしての引き出しは増えます。

しかし、同じようなプロジェクトでも、経験から教訓を得て、より良いマネジメントができるようになれば、経験値は上がります。

例えば、前回のプロジェクトで、

「メンバーへの指示がうまく伝わらなかった」

という問題が起きたとします。

その原因を分析し、

「メンバーがプロジェクトマネジメントの意図を理解していなかった」

と分かった。

そこで次のプロジェクトでは、

「なぜこの指示をするのか」

まで説明するようにした。

これだけでも、同じような規模のプロジェクトを経験しているにもかかわらず、PMとしての能力は変わっています。

つまり、

経験の質は、プロジェクトそのものの難しさだけで決まるわけではありません。

経験から何を得たか。

これも、経験の質を決める重要な要素です。

失敗は、失敗のまま終わらせなければ戦闘力になる

私は、失敗した経験もPM戦闘力を高める重要な材料になると考えています。

例えば、次のような経験です。

• スケジュールが遅れた
• 顧客との認識が合わなかった
• メンバーへの指示が伝わらなかった
• リスクへの対応が遅れた
• ベンダーとの調整に失敗した

こうした経験は、決して無駄ではありません。

ただし、

「失敗した」という事実だけでは、PM戦闘力にはなりません。

重要なのは、その後です。

• なぜ失敗したのか？
• 原因を分析する
• 次はどうすれば防げるのか？
• 対策を考える
• 次のプロジェクトで実際に対策する
• その結果を確認する

こうして初めて、失敗が「教訓」に変わります。

私は、

失敗を失敗のまま終わらせなければ、その経験は戦闘力になる

と考えています。

私自身の経験：若手メンバーとのプロジェクト

ここで、私自身の経験を紹介します。

ある小規模なプロジェクトで、私以外のメンバーは入社3年以内の若手が2人。

そこに50代の営業担当者が1人。

そして、顧客は要望が多く、プロジェクトを失敗させると厳しいクレームにつながる可能性がある顧客でした。

人数だけを考えれば、それほど大きなプロジェクトではありません。

しかし、PMとしては簡単なプロジェクトではありませんでした。

特に課題だったのが、若手メンバーとどのようにプロジェクトを進めるかでした。

そこで私は、プロジェクトのマネジメント方法を一から伝えることにしました。

そして、キックオフミーティングでは、

「このプロジェクトでは、メンバーとしてこういうことを意識してほしい」

ということを伝えました。

単に「これをやってください」と指示するのではありません。

なぜ自分がその指示をしているのか。

プロジェクトマネジメントの観点から、なぜその行動が必要なのか。

そこまで理解してもらおうとしました。

なぜ、そこまでやったのか？

実は、これは前のプロジェクトから得た教訓でした。

前のプロジェクトでは、メンバーがプロジェクトマネジメントについて十分に理解していませんでした。

そのため、私が出した指示の意図がうまく伝わらず、結果として納期遅延を起こしてしまいました。

そこで私は、

「次のプロジェクトでは、メンバーに指示を出すだけではなく、プロジェクトマネジメントそのものを理解してもらおう」

と考えました。

これが、次のプロジェクトでの行動につながりました。

そして、そのプロジェクトでは、前回の教訓を活かしてプロジェクトを進めることができました。

これこそが「経験が戦闘力になる」ということ

この経験から、私はPMにとって重要なのは、

「何年PMをやったか」ではない

と改めて感じました。

もちろん、経験年数は重要です。

しかし、

前のプロジェクトで何が起きたのか。

↓

なぜ起きたのか。

↓

次はどうするのか。

↓

実際に次のプロジェクトで行動を変える。

このサイクルを回すことが重要です。

前のプロジェクトでの失敗が、次のプロジェクトでの成功につながった。

そして、その成功体験が、さらに次のプロジェクトで使える。

こうして経験が積み重なっていきます。

経験とスキルは相互に作用する

親記事では、PM戦闘力を、

（経験 × スキル × 適用力）＋（資格＋実績）

と考えました。

ここでいう「経験」と「スキル」は、一方通行ではありません。

経験 → スキル

という流れもあれば、

スキル → 経験

という流れもあります。

プロジェクトを経験することで、

「こういうときには、こう対応すればいい」

というスキルが身につく。

一方で、すでに持っているスキルを使うことで、

「このプロジェクトでは、ここが問題になりそうだ」

と気づくこともあります。

つまり、

経験とスキルは、お互いを高め合う関係

なのです。

ただし、ここでも重要なのは、自分で考えることです。

経験しただけ。

研修を受けただけ。

資格を取っただけ。

これでは十分ではありません。

経験から考える。

考えたことをスキルに変える。

スキルを次のプロジェクトで使う。

その結果を振り返る。

また次のプロジェクトで活用する。

この循環を自分自身で作る必要があります。

「経験年数」ではなく「経験をどう変えたか」を考える

PMとして経験を積んでいると、いつの間にか、

「PM歴○年」

という数字を自分の強さの指標にしてしまうことがあります。

しかし、PM戦闘力を高めるうえで重要なのは、単純な年数ではありません。

• どんなプロジェクトを経験したのか
• どんな難しさに直面したのか
• 何に失敗したのか
• 何を教訓にしたのか
• 次のプロジェクトで何を変えたのか

そして、

その経験を、次のプロジェクトで再現できる能力に変えられたのか。

ここまで考えて、初めて「経験」がPM戦闘力につながるのだと思います。

まとめ：経験を積むだけではなく、経験を戦闘力に変える

PM経験年数は、PM戦闘力を考えるうえで重要な土台です。

しかし、

PM経験10年＝PM戦闘力10

のように単純に考えることはできません。

経験の質によって、得られるものは大きく変わります。

特に、次のような要素が複雑になるほど、PMにはより高度なマネジメントが求められます。

• ステークホルダーの難しさ
• メンバーの多さ
• 技術の難しさ
• メンバーの質
• ベンダーの多さ

一方で、難しいプロジェクトだけが価値のある経験というわけでもありません。

同じようなプロジェクトであっても、

過去の教訓を活かして、前回より良いマネジメントができた

のであれば、それもPM戦闘力を高める重要な経験です。

そして、失敗も同じです。

失敗する → 原因を分析する → 対策を考える → 教訓にする → 次のプロジェクトで活かす

このサイクルを回すことで、失敗は戦闘力に変わります。

PMとして大切なのは、

経験年数を増やすことではなく、経験を戦闘力に変え続けること。

私はそう考えています。

あなたは、これまでのPM経験から、どんな教訓を得てきましたか？

そして、その教訓を次のプロジェクトで活かせているでしょうか。

経験を「年数」で終わらせず、「次のプロジェクトで使える力」に変えていく。

それが、PM戦闘力を高める一つの方法だと思います。

PM戦闘力シリーズ

PM戦闘力について、さらに詳しく知りたい方はこちらもどうぞ。

• PM戦闘力とは？PMとしての強さを決める要素を考えてみた
• PM戦闘力を高めるPMスキルとは？重要な4つのスキル考えてみた
• PM資格は本当に必要？資格を「戦闘力の装備」として考える
• PMの実績とは何か？「トラブルを解決した」だけが実績ではない
• なぜトラブルを起こさないPMは評価されにくいのか？
• あなたのPM戦闘力はどれくらい？PM戦闘力を自己診断する
• PM戦闘力を高めるには？「経験→実践→振り返り」の成長サイクルを回そう
• PM戦闘力と市場価値の関係とは？PMとしての実力を転職市場でどう伝えるか

The post PM経験年数だけでは戦闘力は上がらない？経験の質が重要な理由 first appeared on PM道場.

PMになったばかりの頃、私はそんなことを考えていました。

PMにはコミュニケーション能力が必要です。

プロジェクトメンバーと話し、ステークホルダーと調整し、時には多くの人の前で説明する必要があります。

人と話すことが苦手な自分には、向いていない仕事なのではないか。

そう思うこともありました。

しかし、PMとして10年以上仕事を続けてきた今、少し違った考えを持っています。

人見知りだからPMに向いていないわけではありません。

かといって、人見知りだからPMに向いているわけでもありません。

大切なのは、自分がどのような性質を持っているのかを理解し、その性質を補う方法を身につけることです。

私の場合、それが次のようなPMスタイルにつながっていきました。

• 準備する
• よく聞く
• 相手を観察する
• 仕組みを作る

この記事では、私が10年以上PMを続ける中で感じた「人見知りだからこそ身についたPMスタイル」について紹介します。

人見知りだからこそ、準備を意識するようになった

私は今でも、初対面の人と話すことが苦手です。

懇親会も得意ではありません。

突然話を振られることも苦手です。

これは10年以上PMを経験したからといって、完全になくなったわけではありません。

ただ、PMとして仕事をする以上、人とコミュニケーションを取らなければなりません。

そこで私は、自分の性質を変えるのではなく、自分の性質を補完する方法を考えるようになりました。

その一つが「準備」です。

会議の前に、次のようなことを考えておきます。

• 何を話すのか
• 何を確認するのか
• 相手からどんな質問が来るのか

初対面の人と話す必要があるなら、事前に相手の立場や役割を確認しておきます。

問題が起きたときには、以前のように完璧な原因分析や対策を準備してから報告するのではありません。

「問題だと思った時点で報告する」というルールを自分の中に作りました。

こうした工夫によって、人見知りという性質を補ってきました。

もちろん、社交的なPMでも準備はできます。

人見知りだから特別な能力を持っているわけではありません。

ただ、自分が人見知りだと理解しているからこそ、何を準備すれば自分が動きやすくなるのかを、より意識するようになったのだと思います。

「話す力」より「聞く力」がPMを助けてくれた

PMとして仕事をする中で、もう一つ自分の強みだと思うようになったものがあります。

それが、人の話を聞くことです。

私は、人前で話すことや初対面の人と会話することは得意ではありません。

一方で、相手の話を聞きながら、次のように考えることは比較的得意です。

• この人は何を伝えたいのだろう
• 本当に困っていることは何だろう

そして、相手の話を聞きながら質問することで、相手自身が気付いていなかったことに気付いてもらうこともあります。

これはPMにとって、非常に重要な能力だと感じています。

リスク検討の場で気付いた「自分の考えだけでは足りない」ということ

以前、リスクを検討する打ち合わせで印象に残っている出来事があります。

ある先輩PMが、事前に洗い出したリスクをプロジェクトメンバーに説明していました。

経験も豊富で、非常に社交的なPMでした。

そのため、自分の考えに自信を持ってプロジェクトを進めていました。

打ち合わせも終わりに近づいた頃、あるプロジェクトメンバーが、

「他にもリスクがあるのではないか。」

と発言しました。

ところが、その先輩PMは、その意見を十分に聞こうとはしませんでした。

結果として、その場では見逃されていたリスクを、そのメンバーの発言によって見つけることができました。

私はこの出来事を見て、

「PM自身が考えたことだけが正解ではない」

と強く感じました。

どれだけ経験があっても、どれだけ社交的でも、一人で考えられることには限界があります。

だからこそ、プロジェクトメンバーの意見を聞くことが重要なのです。

人見知りだった私は、もともと相手の話を聞くことを意識していました。

その経験が、PMとしての「聞く力」につながっていったのだと思います。

質問することで、相手自身に気付いてもらう

PMにとって、「聞く」とは、ただ黙って相手の話を聞くことではありません。

私は、適切な質問をすることも重要だと考えています。

例えば、次のような質問です。

• 「それはなぜ問題だと思いますか？」
• 「もしそのリスクが発生したら、何が一番困りますか？」
• 「他に影響を受ける人はいませんか？」
• 「今の話をもう少し詳しく教えてもらえますか？」

質問を重ねることで、相手自身が考えを整理できます。

そして、

「そうか。ここもリスクになるかもしれない。」

と、本人が自分で気付くことがあります。

PMが答えを教えるのではなく、質問によって相手を導く。

これは、私が人見知りであることをきっかけに身につけてきた、PMとしての一つのスタイルです。

人見知りだからこそ、相手を観察するようになった

もう一つ、PMとして意識していることがあります。

それは、相手によってコミュニケーションの方法を変えることです。

これはステークホルダーマネジメントにもつながります。

私はプロジェクトの中で、ステークホルダー登録簿などを活用しながら、次のようなことを考えていました。

• この人にはどのように連絡した方がよいか
• どのくらいの頻度で情報共有した方がよいか
• メールがよいのか、電話がよいのか

人によって、コミュニケーションの取り方は違います。

こちらが話しやすい方法ではなく、相手が受け取りやすい方法を考える。

これは、PMにとって重要な考え方だと思います。

先輩PMを「そのまま真似しない」という学び

私がPMとして成長してきた過程では、先輩PMから多くのことを学びました。

先輩のやり方を真似することもありました。

しかし、すべてをそのまま真似したわけではありません。

むしろ、

「このやり方は、この人だからできるのではないか。」

と考えることもありました。

例えば、非常に社交的な先輩PMなら、初対面の相手とも自然に雑談をします。

そして、いつの間にか信頼関係を作ってしまいます。

その方法をそのまま人見知りの自分が真似しても、うまくいかないことがあります。

そこで、

「自分だったらどうするか。」

と考えるようにしました。

• キックオフミーティングを設ける
• 会議の前に準備する
• 質問を用意する
• 定例会で話す機会を作る
• エスカレーションのルールを決める

こうして、自分に合った方法を少しずつ作ってきました。

人見知りを克服する必要はなかった

ここまでの話をすると、

「では、人見知りを克服したのですか？」

と思われるかもしれません。

答えは「いいえ」です。

私は今でも人見知りです。

初対面の人との会話も苦手です。

懇親会も苦手です。

突然人前で話すことも得意ではありません。

それでもPMを続けることはできました。

なぜなら、人見知りを克服することと、PMとして成果を出すことは別の話だからです。

必要なのは、自分を別人に変えることではありません。

自分の性質を理解し、その性質を補う方法を身につけることです。

PMには「絶対の正解」がない

PMとして10年以上仕事をしてきて、強く感じることがあります。

それは、

プロジェクトマネジメントには、これが絶対に正しいという方法はない

ということです。

プロジェクトによって、条件は変わります。

• 規模が違う
• メンバーが違う
• ステークホルダーが違う
• 組織が違う
• 目的が違う
• リスクが違う

だからこそ、同じ方法がすべてのプロジェクトで通用するわけではありません。

これは、自分自身についても同じです。

社交的なPMには、社交的なPMのやり方があります。

人見知りのPMには、人見知りのPMのやり方があります。

重要なのは、自分に合った方法を選ぶことです。

自分に合ったPMを作るために、知識と経験を増やす

ただし、

「自分に合った方法でやればいい。」

というだけでは不十分だと思います。

自分に合った方法を見つけるためには、知識と経験が必要だからです。

例えば、次のような知識を学びます。

• PMBOK®︎
• リスクマネジメント
• ステークホルダーマネジメント
• コミュニケーションマネジメント

そして、実際のプロジェクトで試してみます。

うまくいかなければ修正します。

先輩PMのやり方を見て、

• これは自分にも使える
• これは自分には合わない

と考えます。

こうした経験を積み重ねることで、少しずつ自分なりのPMスタイルができていきます。

まとめ：人見知りを克服するより、自分に合ったPMスタイルを作ろう

私は、PMになったばかりの頃、

「人見知りだからPMには向いていないのではないか。」

と思っていました。

しかし、10年以上PMを続けてきた今は、そうは思いません。

人見知りであることが、特別な強みだったわけではありません。

むしろ、自分が人見知りであることを理解していたからこそ、自分を補完する方法を考えるようになったのだと思います。

その結果、次のような自分なりのPMスタイルを作ることができました。

• 事前に準備する
• 相手の話をよく聞く
• 質問によって相手の考えを引き出す
• 相手に合わせてコミュニケーション方法を変える
• コミュニケーションを仕組み化する

だから、もし今、

「自分は人見知りだからPMに向いていない。」

と思っている人がいたら、私はこう伝えたいです。

無理に社交的になる必要はありません。

プロジェクトマネジメントには、絶対の正解はありません。

自分に合ったやり方を選んで、マネジメントしていけばいいのです。

そして、自分に合ったやり方を見つけるためには、知識と経験が必要です。

たくさん学んで、たくさん経験してください。

その中から、

「自分だったらどうするか」

を考えてみてください。

きっと、少しずつ自分に合ったPMのスタイルが見えてくるはずです。

あなたへの問いかけ

あなたは、自分の性格や得意・不得意を理解した上で、どのようなPMスタイルを作っていますか？

そして、今の自分に合っていないと感じるプロジェクトマネジメントのやり方はありませんか？

「正解を探す」のではなく、「自分に合ったやり方を作る」。

それも、プロジェクトマネジメントの一つの楽しさなのではないでしょうか。

The post 人見知りはPMに向いていない？10年続けて分かった本当の強み first appeared on PM道場.

プロジェクトでは、多くのステークホルダーが関わるため、意見や立場が異なることは珍しくありません。

そのような状況で、プロジェクトを前へ進めるために重要なのが合意形成（Consensus Building）です。

この記事では、合意形成の意味や目的、進め方、実務で意識したいポイントについて解説します。

一言でいうと

合意形成とは、「関係者が十分に話し合い、それぞれの立場を理解したうえで、プロジェクトとして進むべき方向を決定するプロセス」です。

合意形成とは

合意形成とは、関係者同士が対話を重ね、共通の理解を持ちながら意思決定を行うことです。

プロジェクトでは、スコープやスケジュール、コスト、品質など、さまざまな場面で意思決定が必要になります。

PMBOK®︎では、ステークホルダーエンゲージメントやコミュニケーションマネジメントの中で、合意形成はプロジェクト成功のために欠かせない活動とされています。

合意形成が重要な理由

プロジェクトでは、正しい判断をすることだけでは十分ではありません。

関係者が決定内容を理解し、納得して行動できる状態を作ることが重要です。

例えば、次のようなケースがあります。

• 仕様変更を一部の関係者だけで決定してしまう
• スケジュール変更の理由が十分に共有されていない
• 役割分担について認識が一致していない

このような状態では、後から反対意見が出たり、作業の手戻りが発生したりする可能性があります。

そのため、プロジェクトでは意思決定だけでなく、合意形成のプロセスも重要になります。

合意形成の進め方

1. 関係者を明確にする

まず、誰の意見を確認する必要があるのかを整理します。

意思決定者だけでなく、影響を受ける関係者も把握することが重要です。

2. 情報を共有する

判断に必要な情報を関係者へ共有します。

情報量や認識に差があると、建設的な議論ができません。

3. 意見を整理する

賛成・反対だけではなく、それぞれの理由や懸念事項を整理します。

背景を理解することで、新しい解決策が見つかることもあります。

4. 意思決定を行う

議論を踏まえて、最終的な方針を決定します。

全員が完全に同じ意見になる必要はありませんが、決定内容を理解し、受け入れられる状態を目指します。

合意形成とネゴシエーションの違い

ネゴシエーションが合意形成の一部として行われることもありますが、合意形成はより広い概念です。

実務ではこんな場面で活用される

例えば、プロジェクト途中で顧客から新機能の追加要望があったとします。

プロジェクトマネージャは、開発チーム、顧客、スポンサーと話し合い、次のような点を整理します。

• 追加機能の必要性
• スケジュールへの影響
• 追加コストの有無
• 優先順位の変更が可能か

その結果、「一部機能は今回対応し、残りは次回リリースで対応する」という方針で関係者が合意しました。

このように、異なる立場の意見を調整しながら、プロジェクト全体として最適な方向を決めることが合意形成です。

よくある勘違い

全員が100％賛成する必要はない

合意形成は、多数決や全会一致とは異なります。

最終的な判断に全員が完全に賛成していなくても、決定理由を理解し、協力できる状態であれば合意形成は成立します。

時間をかければよいわけではない

議論を続けるだけでは、プロジェクトは前へ進みません。

必要な情報を整理したうえで、適切なタイミングで意思決定することもプロジェクトマネージャの重要な役割です。

プロジェクトマネージャ試験ではここが重要

IPAのプロジェクトマネージャ試験では、関係者との調整や意思決定のプロセスが頻繁に問われます。

午後試験では、次のような観点を説明できることが重要です。

• どのような関係者と調整したか
• 異なる意見をどのように整理したか
• 最終的な意思決定に至った理由
• 合意形成によって得られた効果

「承認を得た」だけではなく、「関係者の理解と納得を得ながら意思決定を進めた」と説明できることが評価につながります。

PM道場のワンポイント

合意形成とは、「全員を同じ意見にすること」ではなく、「全員が前を向いて行動できる状態を作ること」です。

プロジェクトでは、立場が違えば意見が違うのは当然です。

優れたプロジェクトマネージャは、誰かを説得することよりも、互いの考えを理解し、共通のゴールへ向かえる環境を作っています。

そのためには、十分なコミュニケーションとファシリテーション、そして適切なネゴシエーションが欠かせません。

関連用語

• ネゴシエーション
• ファシリテーション
• コミュニケーションマネジメント
• ステークホルダー
• ステークホルダーエンゲージメント
• 意思決定
• エスカレーション
• リーダーシップ

まとめ

合意形成とは、関係者が十分に話し合い、それぞれの立場を理解したうえで、プロジェクトとして進むべき方向を決定するプロセスです。

重要なのは、全員を同じ意見にすることではなく、決定内容を理解し、協力して行動できる状態を作ることです。

プロジェクトマネージャにとって、合意形成はプロジェクトを円滑に進めるための重要なマネジメントスキルと言えるでしょう。

関連記事

• ネゴシエーションとは？
• ファシリテーションとは？
• コミュニケーションマネジメントとは？
• ステークホルダーとは？
• エスカレーションとは？
• リーダーシップとは？

よくある質問（FAQ）

Q. 合意形成とは何ですか？

A. 関係者が十分に話し合い、それぞれの立場を理解したうえで、プロジェクトとして進むべき方向を決定するプロセスです。

Q. 合意形成とネゴシエーションの違いは何ですか？

A. 合意形成は関係者全体の共通認識を作る活動であり、ネゴシエーションは利害が異なる相手と条件を調整する交渉活動です。

Q. 合意形成では全員が賛成する必要がありますか？

A. いいえ。全会一致である必要はありません。決定理由を理解し、協力して行動できる状態を作ることが重要です。

The post 合意形成とは？プロジェクトを円滑に進めるための意思決定プロセスを解説 first appeared on PM道場.

「限られた人員を複数のプロジェクトで取り合っている。」

プロジェクトでは、このように利害や意見が異なる場面が数多くあります。

そのような状況で、お互いが納得できる結論を導くために必要なのがネゴシエーション（Negotiation）です。

この記事では、ネゴシエーションの意味や目的、進め方、プロジェクトマネージャが意識すべきポイントについて解説します。

一言でいうと

ネゴシエーションとは、「利害や意見が異なる相手と話し合い、お互いが受け入れられる合意を目指す交渉活動」です。

ネゴシエーションとは

ネゴシエーションとは、相手と対立することではなく、双方にとって最適な解決策を見つけるための話し合いです。

プロジェクトでは、顧客、スポンサー、チームメンバー、他部署など、多くのステークホルダーと調整を行います。

PMBOK®︎でも、プロジェクトマネージャに必要な対人スキルの一つとして、ネゴシエーションが挙げられています。

プロジェクトマネージャは、自分の主張を押し通すのではなく、相手の立場や背景を理解しながら合意形成を進めることが求められます。

ネゴシエーションが重要な理由

プロジェクトでは、すべての関係者の要望をそのまま実現することはできません。

例えば、次のような場面があります。

• 納期を短縮してほしいという顧客の要望
• 予算を増やせないというスポンサーの判断
• 人員不足を訴える開発チーム
• 品質を優先したい品質保証部門

このような状況で一方的に要求を受け入れると、別の問題が発生します。

ネゴシエーションによって、それぞれの立場を理解しながら、現実的な解決策を見つけることが重要です。

ネゴシエーションの進め方

1. 相手の目的を理解する

まずは、自分の要求ではなく、相手が何を実現したいのかを理解します。

要求の背景を知ることで、新たな解決策が見つかることがあります。

2. 自分たちの制約を整理する

納期、コスト、品質、人員など、自分たちが譲れない条件を整理します。

何でも受け入れるのではなく、現実的な範囲を明確にしておくことが重要です。

3. 複数の選択肢を提示する

「できる・できない」の二択ではなく、複数の案を提示します。

例えば、

• 納期は変更しない代わりに機能を一部見直す
• 追加予算があれば短縮可能とする
• 優先順位を変更して段階的にリリースする

など、相手が選択できる余地を作ります。

4. 合意内容を明確にする

交渉がまとまったら、決定事項を文書化し、関係者全員で認識を合わせます。

曖昧なまま終わらせると、後から認識違いが発生する原因になります。

実務ではこんな場面で活用される

例えば、顧客から「予定より2週間早く納品してほしい」と依頼があったとします。

プロジェクトマネージャは、「できません」と断るのではなく、まず背景を確認します。

その結果、顧客はすべての機能ではなく、主要機能だけを先に利用したいことが分かりました。

そこで、主要機能を先行リリースし、残りは予定どおり開発する案を提案しました。

このように、相手の本当の目的を理解することで、お互いに納得できる解決策を見つけることができます。

よくある勘違い

ネゴシエーションは勝ち負けではない

交渉は相手に勝つことが目的ではありません。

双方が納得できる合意を目指すことが重要です。

譲歩することがネゴシエーションではない

相手の要求をすべて受け入れることは、良い交渉とは言えません。

プロジェクト全体の成功を考え、適切なバランスを取ることが重要です。

プロジェクトマネージャ試験ではここが重要

IPAのプロジェクトマネージャ試験では、関係者との調整や利害対立への対応が頻繁に出題されます。

午後試験では、次のような観点を説明できることが重要です。

• 相手の要求や背景をどのように把握したか
• どのような代替案を提示したか
• 双方が納得できる合意をどのように形成したか
• 交渉結果をどのようにプロジェクトへ反映したか

「要求を受け入れた」ではなく、「プロジェクト全体を考慮して最適な合意を形成した」と説明できることが評価につながります。

PM道場のワンポイント

ネゴシエーションで大切なのは、「自分の要求を通すこと」ではなく、「相手が本当に求めているものを理解すること」です。

プロジェクトでは、表面的な要求だけを見ると対立しているように見えることがあります。

しかし、その背景にある目的を理解すると、双方が納得できる解決策が見つかることも少なくありません。

優れたプロジェクトマネージャは、交渉を対立ではなく、価値を生み出すためのコミュニケーションと考えています。

関連用語

• ステークホルダー
• コミュニケーションマネジメント
• ファシリテーション
• エスカレーション
• 意思決定
• コンフリクトマネジメント
• リーダーシップ
• スポンサー

まとめ

ネゴシエーションとは、利害や意見が異なる相手と話し合い、お互いが納得できる合意を目指す交渉活動です。

重要なのは、自分の要求を押し通すことではなく、相手の目的や背景を理解し、複数の選択肢を提示しながら最適な解決策を見つけることです。

プロジェクトマネージャにとって、ネゴシエーションはプロジェクトを前進させるために欠かせないスキルと言えるでしょう。

関連記事

• コミュニケーションマネジメントとは？
• ファシリテーションとは？
• ステークホルダーとは？
• エスカレーションとは？
• リーダーシップとは？
• コンフリクトマネジメントとは？

よくある質問（FAQ）

Q. ネゴシエーションとは何ですか？

A. 利害や意見が異なる相手と話し合い、双方が受け入れられる合意を目指す交渉活動です。

Q. ネゴシエーションで最も重要なことは何ですか？

A. 相手の要求だけでなく、その背景にある目的や事情を理解し、お互いにとって最適な解決策を見つけることです。

Q. ファシリテーションとの違いは何ですか？

A. ファシリテーションは会議や議論を円滑に進める技術、ネゴシエーションは利害が異なる相手と合意形成を行うための交渉技術です。

The post ネゴシエーションとは？プロジェクトを前進させる交渉の考え方を解説 first appeared on PM道場.

「発言する人が限られ、結論が曖昧なまま会議が終わってしまう。」

プロジェクトでは、このような会議が少なくありません。

そこで重要になるのがファシリテーション（Facilitation）です。

ファシリテーションとは、会議や議論を円滑に進め、参加者全員が意見を出し合いながら、合意形成や意思決定へ導くための技術です。

この記事では、ファシリテーションの意味や目的、実践方法、プロジェクトマネージャが意識すべきポイントについて解説します。

一言でいうと

ファシリテーションとは、「参加者が建設的に議論し、納得感のある結論へ到達できるように会議を進行・支援する技術」です。

ファシリテーションとは

ファシリテーションとは、会議やワークショップなどで参加者同士のコミュニケーションを促進し、目的達成を支援する活動です。

プロジェクトマネージャは、自分の意見を押し通すのではなく、参加者から必要な情報や意見を引き出し、適切な意思決定ができる環境を作ることが求められます。

PMBOK®︎でも、ステークホルダーとの協働やコミュニケーションを円滑に進めるための重要なスキルとして位置付けられています。

ファシリテーションが重要な理由

プロジェクトでは、多様な立場や専門性を持つメンバーが参加します。

そのため、何も工夫せずに会議を進めると、次のような問題が発生します。

• 一部の人だけが発言する
• 議論が脱線する
• 結論が曖昧なまま終了する
• 決定事項や担当者が決まらない

ファシリテーションによって議論を整理し、参加者全員が目的を共有できるようにすることで、会議の質を高めることができます。

ファシリテーションで意識したいポイント

目的を最初に共有する

会議の冒頭で、「今日は何を決める会議なのか」を明確にします。

目的が曖昧なままでは、議論が脱線しやすくなります。

参加者全員が発言できる環境を作る

発言が偏らないように、意見が少ない参加者にも声を掛けます。

異なる立場の意見を引き出すことで、より良い意思決定につながります。

議論を整理する

話題が広がりすぎた場合は、論点を整理し、本来の目的へ戻します。

ホワイトボードや画面共有を活用し、議論を見える化することも効果的です。

結論とアクションを明確にする

会議の最後には、次の内容を確認します。

• 何が決まったか
• 誰が担当するか
• いつまでに実施するか

これにより、「話し合っただけ」で終わる会議を防ぐことができます。

実務ではこんな場面で活用される

例えば、システム開発プロジェクトで仕様変更について議論する会議を考えます。

営業部門は「顧客要望を優先したい」、開発チームは「納期への影響を抑えたい」と考えており、意見が対立しています。

ファシリテーターは、それぞれの意見を整理し、共通の目的を確認したうえで、実現可能な対応案を検討します。

このように、ファシリテーションは「誰が正しいか」を決めるのではなく、「どうすればプロジェクトにとって最適な結論になるか」を支援する役割を担います。

よくある勘違い

ファシリテーターは会議の主役ではない

ファシリテーターが多く話すことが良い会議ではありません。

参加者同士の対話を促し、必要な意見を引き出すことが役割です。

全員の意見を一致させることが目的ではない

全員が同じ考えになる必要はありません。

異なる意見を整理し、納得感のある意思決定へ導くことが重要です。

プロジェクトマネージャ試験ではここが重要

IPAのプロジェクトマネージャ試験では、会議運営や関係者調整、合意形成について問われることがあります。

午後試験では、次のような観点を説明できることが重要です。

• どのように議論を整理したか
• 対立する意見をどのように調整したか
• 参加者の理解をどのように促したか
• どのように合意形成へ導いたか

単に「会議を開催した」ではなく、「参加者全員が納得できる結論へ導いた」と説明できることが評価につながります。

PM道場のワンポイント

ファシリテーションとは、「上手に話す技術」ではなく、「参加者が話しやすい場を作る技術」です。

プロジェクトマネージャがすべての答えを持っている必要はありません。

むしろ、チームの知識や経験を引き出し、より良い結論へ導くことが重要です。

私は企業研修でも、「会議を成功させるのは、話す力ではなく、聞く力と整理する力です」とお伝えしています。

優れたプロジェクトマネージャは、自分が目立つのではなく、チームが成果を出せる環境を作っています。

関連用語

• コミュニケーションマネジメント
• キックオフミーティング
• ステークホルダー
• エスカレーション
• 意思決定
• レビュー
• ステークホルダーエンゲージメント
• リーダーシップ

まとめ

ファシリテーションとは、会議や議論を円滑に進め、参加者全員が納得できる結論へ導くための技術です。

重要なのは、自分が話すことではなく、参加者同士の対話を促し、議論を整理することです。

プロジェクトマネージャにとって、ファシリテーションはチームの力を最大限に引き出し、プロジェクトを成功へ導くための重要なスキルと言えるでしょう。

関連記事

• コミュニケーションマネジメントとは？
• キックオフミーティングとは？
• ステークホルダーとは？
• エスカレーションとは？
• リーダーシップとは？
• 意思決定とは？

よくある質問（FAQ）

Q. ファシリテーションとは何ですか？

A. 会議や議論を円滑に進め、参加者が建設的に意見を出し合い、納得感のある結論へ導くための技術です。

Q. ファシリテーターの役割は何ですか？

A. 議論を整理し、参加者全員が発言しやすい環境を作り、目的達成を支援することです。

Q. プロジェクトマネージャにファシリテーションスキルは必要ですか？

A. はい。プロジェクトでは関係者との合意形成や意思決定が不可欠であり、ファシリテーションはそのための重要なスキルです。

The post ファシリテーションとは？会議で合意形成を促進する進行技術を解説 first appeared on PM道場.

実は、キックオフミーティングは単なる説明会ではありません。

プロジェクト開始時に、チーム全員が同じ方向を向き、円滑にコミュニケーションできる環境を作るための重要な場です。

この記事では、キックオフミーティングの意味や目的、進め方、実務で意識したいポイントについて解説します。

一言でいうと

キックオフミーティングとは、「プロジェクト開始時に、目的・役割・進め方・コミュニケーション方法を共有し、チームの共通認識を作るための会議」です。

キックオフミーティングとは

キックオフミーティングとは、プロジェクト正式開始時に開催される最初の会議です。

プロジェクトの目的や背景、目標、体制、スケジュールを共有し、関係者全員が同じ方向を向いてスタートできる状態を作ります。

PMBOK®︎ではキックオフミーティングという名称のプロセスはありませんが、プロジェクト憲章やコミュニケーションマネジメント計画などを関係者へ共有し、共通認識を形成する重要な活動として位置付けられています。

キックオフミーティングが重要な理由

プロジェクト開始時に認識を合わせないまま作業を始めると、後から多くの問題が発生します。

例えば、次のようなケースがあります。

• プロジェクトの目的をメンバーごとに違って理解している
• 役割分担が曖昧で作業が重複する
• 報告方法が決まっておらず情報共有が漏れる
• 問題発生時のエスカレーション先が分からない

キックオフミーティングで最初にルールを共有することで、このようなトラブルを未然に防ぐことができます。

キックオフミーティングで共有する内容

一般的には、次のような内容を説明します。

重要なのは、一方的に説明することではなく、参加者全員が内容を理解し、疑問点を解消できることです。

実務ではこんな場面で活用される

例えば、新しいシステム開発プロジェクトが始まるとします。

キックオフミーティングでは、プロジェクト概要だけでなく、次のような内容も共有します。

• 毎朝の進捗確認方法
• 課題管理表の登録ルール
• リスクの報告方法
• エスカレーションの基準
• 成果物レビューの進め方

このように、プロジェクト開始時にコミュニケーションのルールを決めておくことで、その後の運営がスムーズになります。

よくある勘違い

キックオフミーティングは説明会ではない

資料を読み上げるだけでは、キックオフミーティングの目的は達成できません。

参加者がプロジェクトの目的や自分の役割を理解し、安心して動き始められる状態を作ることが重要です。

スケジュールだけを共有すればよいわけではない

スケジュールだけを説明しても、情報共有の方法や意思決定の流れが決まっていなければ、後から混乱が生じます。

コミュニケーション方法まで含めて設計することが重要です。

プロジェクトマネージャ試験ではここが重要

IPAのプロジェクトマネージャ試験では、プロジェクト開始時の体制づくりや関係者との合意形成が問われることがあります。

論文では、次のような観点を具体的に説明できることが重要です。

• どのような目的でキックオフミーティングを実施したか
• 何を共有したか
• コミュニケーションルールをどのように決めたか
• その結果、どのような効果が得られたか

単に「キックオフミーティングを開催した」ではなく、「プロジェクト運営の仕組みを設計した」と説明できることが評価につながります。

PM道場のワンポイント

キックオフミーティングは、説明会ではなく「最初のコミュニケーション設計」を行う場です。

プロジェクトマネージャは、最初からメンバー全員と良好な人間関係を築こうと頑張る必要はありません。

それよりも重要なのは、困ったときに誰へ相談するのか、どのように報告するのか、問題が起きたらどう動くのかというルールを最初に決めることです。

この仕組みがあることで、人見知りのプロジェクトマネージャでも安心してプロジェクトを運営できます。

優れたプロジェクトマネージャは、人に頼るのではなく、最初にコミュニケーションの仕組みを設計しています。

関連用語

• コミュニケーションマネジメント
• プロジェクト憲章
• ステークホルダー
• エスカレーション
• RACI
• プロジェクトマネージャ
• コミュニケーションマネジメント計画書
• ステークホルダーエンゲージメント

まとめ

キックオフミーティングとは、プロジェクト開始時に目的や役割だけでなく、コミュニケーションの進め方まで共有する重要な会議です。

プロジェクト成功のためには、説明資料を共有することではなく、チーム全員が同じルールで行動できる状態を作ることが重要です。

キックオフミーティングを「最初のコミュニケーション設計」と考えることで、その後のプロジェクト運営は大きく変わります。

関連記事

• コミュニケーションマネジメントとは？
• プロジェクト憲章とは？
• ステークホルダーとは？
• エスカレーションとは？
• RACIとは？
• プロジェクトマネージャとは？

よくある質問（FAQ）

Q. キックオフミーティングとは何ですか？

A. プロジェクト開始時に、目的・役割・進め方・コミュニケーション方法を共有し、チームの共通認識を作るための会議です。

Q. キックオフミーティングでは何を共有すればよいですか？

A. プロジェクトの目的、成果物、体制、スケジュール、役割、コミュニケーションルール、エスカレーション方法などを共有します。

Q. キックオフミーティングで最も重要なことは何ですか？

A. プロジェクトの説明だけではなく、情報共有や意思決定の仕組みを設計し、チーム全員が安心して動き始められる状態を作ることです。

The post キックオフミーティングとは？プロジェクト成功を左右する最初のコミュニケーション設計を解説 first appeared on PM道場.

プロジェクトでよく聞く言葉ですが、本当に重要なのはコミュニケーションの量ではありません。

重要なのは、必要な情報を、必要な人へ、必要なタイミングで届ける仕組みを作ることです。

この仕組みづくりをコミュニケーションマネジメント（Communications Management）と呼びます。

この記事では、コミュニケーションマネジメントの意味や目的、PMBOK®︎における考え方、実務で活用するポイントについて解説します。

一言でいうと

コミュニケーションマネジメントとは、「プロジェクトで必要な情報を、適切な相手へ、適切な方法・タイミングで届ける仕組みを設計・運用する活動」です。

コミュニケーションマネジメントとは

コミュニケーションマネジメントとは、プロジェクトで必要となる情報の収集・作成・共有・保管・活用を計画し、実行・管理する活動です。

PMBOK®︎では、単に「会話を増やすこと」ではなく、情報共有の仕組みを設計することが重視されています。

例えば、次のようなことを決めます。

• 誰が誰へ情報を共有するのか
• 何を共有するのか
• いつ共有するのか
• どの手段で共有するのか
• 誰が承認するのか

これらを明確にすることで、情報共有漏れや認識のズレを防ぐことができます。

コミュニケーションマネジメントが重要な理由

プロジェクトの失敗原因として最も多いものの一つが、コミュニケーション不足ではなく、コミュニケーションの設計不足です。

例えば、次のような問題があります。

• 進捗報告の頻度が人によって異なる
• 重要な決定事項が一部のメンバーしか知らない
• 最新版ではない資料で作業してしまう
• 顧客への報告タイミングが遅れる

情報共有のルールが決まっていないと、小さな認識の違いが大きなトラブルにつながります。

そのため、プロジェクト開始時にコミュニケーションを設計しておくことが重要です。

PMBOK®︎におけるコミュニケーションマネジメント

PMBOK®︎では、コミュニケーションマネジメントは次のプロセスで構成されています。

計画・実行・改善を繰り返すことで、プロジェクト全体の情報共有品質を高めます。

コミュニケーションマネジメント計画書とは

コミュニケーションマネジメント計画書は、情報共有のルールをまとめた文書です。

一般的には次のような内容を記載します。

この計画書によって、「誰が何を共有するのか」が明確になります。

実務ではこんな場面で活用される

例えば、20名規模のシステム開発プロジェクトでは、毎日全員が自由に情報共有すると、必要な情報が埋もれてしまいます。

そこで、コミュニケーションマネジメントとして次のようなルールを決めます。

• 毎朝15分の進捗確認ミーティングを実施する
• 課題は課題管理表へ登録する
• リスクは週次会議で確認する
• 仕様変更はメールではなく変更管理会議で承認する
• スポンサーへは月次報告を実施する

このように情報共有を標準化することで、認識違いや伝達漏れを防ぐことができます。

よくある勘違い

コミュニケーション量を増やせばよいわけではない

会議やチャットを増やしても、必要な情報が適切な相手へ届かなければ意味がありません。

重要なのは、情報共有の目的と方法を設計することです。

コミュニケーション能力だけの問題ではない

「話すのが苦手だからPMに向いていない」と考える人もいます。

しかし、優れたプロジェクトマネージャに必要なのは話術ではありません。

情報共有の仕組みを設計する力です。

適切なルールや仕組みがあれば、個人のコミュニケーション能力に頼らなくても、プロジェクトは円滑に進められます。

プロジェクトマネージャ試験ではここが重要

IPAのプロジェクトマネージャ試験では、関係者との情報共有や調整方法が頻繁に問われます。

午後試験では、次の観点を具体的に説明できることが重要です。

• 誰へどのような情報を共有したか
• 共有方法を選択した理由
• 共有頻度をどのように決めたか
• 情報共有によってどのような効果があったか

単に「定例会議を実施した」と書くのではなく、「情報共有の仕組みを設計した」ことまで説明できると評価が高くなります。

PM道場のワンポイント

コミュニケーションマネジメントとは、「話し上手になること」ではなく、「情報共有を仕組み化すること」です。

私は企業研修でも、「PMに必要なのはコミュニケーション能力ではなく、コミュニケーションを設計する力」とお伝えしています。

会議の目的、報告ルール、エスカレーション方法、情報共有ツールなどをあらかじめ決めておけば、チームは迷わず行動できます。

優れたプロジェクトマネージャは、人に頼るのではなく、仕組みによってコミュニケーションを円滑にしています。

関連用語

• コミュニケーションマネジメント計画書
• ステークホルダー
• エスカレーション
• キックオフミーティング
• 報告
• 課題（Issue）
• リスク（Risk）
• ステークホルダーエンゲージメント

まとめ

コミュニケーションマネジメントとは、必要な情報を、適切な相手へ、適切なタイミング・方法で届ける仕組みを設計・運用する活動です。

プロジェクト成功の鍵は、コミュニケーション量ではなく、情報共有の質にあります。

情報共有を個人の能力に任せるのではなく、チーム全体が迷わず行動できる仕組みを作ることが、優れたプロジェクトマネージャの重要な役割です。

関連記事

• ステークホルダーとは？
• エスカレーションとは？
• キックオフミーティングとは？
• リスクマネジメントとは？
• 課題（Issue）とは？
• ステークホルダーエンゲージメントとは？

よくある質問（FAQ）

Q. コミュニケーションマネジメントとは何ですか？

A. プロジェクトで必要な情報を、適切な相手へ、適切な方法・タイミングで共有する仕組みを計画・運用する活動です。

Q. コミュニケーションマネジメント計画書には何を書きますか？

A. 共有する情報、共有先、共有頻度、共有方法、責任者など、情報共有のルールを記載します。

Q. コミュニケーション能力が高くないとプロジェクトマネージャは務まりませんか？

A. いいえ。重要なのは話術ではなく、情報共有を仕組みとして設計・運用する力です。

The post コミュニケーションマネジメントとは？情報共有を設計してプロジェクトを成功へ導く方法を解説 first appeared on PM道場.

プロジェクトの現場では、このように問題を抱え込んでしまうケースがあります。

しかし、問題への対応が遅れるほど、プロジェクトへの影響は大きくなる可能性があります。

そこで重要になるのがエスカレーション（Escalation）です。

この記事では、エスカレーションの意味や目的、適切なタイミング、プロジェクトマネージャが実践すべきポイントについて解説します。

一言でいうと

エスカレーションとは、「自分や現在のチームだけでは解決できない問題や判断事項を、適切な権限を持つ人へ共有し、支援や判断を求める活動」です。

エスカレーションとは

エスカレーションとは、問題やリスク、判断が必要な事項を、上位者や関係する意思決定者へ引き上げることです。

プロジェクトでは、プロジェクトマネージャだけでは判断できない問題が発生することがあります。

例えば、

• 予算追加が必要になる
• 納期変更の判断が必要になる
• 組織間の調整が必要になる
• 重要なリスクが顕在化する

このような場合、適切なタイミングでエスカレーションを行うことで、迅速な意思決定につなげることができます。

エスカレーションが重要な理由

プロジェクトでは、問題そのものよりも「発見後の対応の遅れ」が大きな影響を与えることがあります。

例えば、以下のようなケースです。

• 小さな遅延を報告せず、後から重大な遅延になる
• 品質問題を抱え込み、リリース直前に発覚する
• 判断待ちの事項が放置され、作業が停止する

早い段階でエスカレーションすることで、選択できる対応策が増えます。

つまり、エスカレーションは「問題が大きくなってから助けを求める行為」ではなく、「問題を大きくしないための予防的な行動」です。

エスカレーションするべきタイミング

エスカレーションの判断で重要なのは、「解決策が決まってから報告する」のではなく、「問題だと認識した段階で共有する」ことです。

例えば、以下のような状況ではエスカレーションを検討します。

• プロジェクト目標へ影響する可能性がある
• 自分の権限では判断できない
• 複数チームに影響する
• 期限までに解決できない可能性がある
• 追加予算や人員が必要になる

エスカレーションで重要な報告内容

エスカレーションでは、単に「問題があります」と伝えるだけでは十分ではありません。

最低限、以下の内容を整理して共有します。

原因分析や対策案が完成していなくても、まず状況を共有することが重要です。

エスカレーションと報告の違い

エスカレーションは単なる報告ではなく、問題解決のために適切な人へ判断をつなぐ活動です。

実務ではこんな場面で活用される

例えば、システム開発プロジェクトで、重要な機能の開発が遅れる可能性が判明したとします。

プロジェクトマネージャが一人で原因分析や対策検討を続けると、対応が遅れる可能性があります。

そこで、以下のようにエスカレーションします。

• 現在判明している事実を共有する
• 納期影響の可能性を伝える
• 原因分析中であることを説明する
• 必要な支援や判断を依頼する

この段階では、完璧な解決策を提示する必要はありません。

重要なのは、問題を早期に共有し、組織として対応できる状態を作ることです。

よくある勘違い

エスカレーションは失敗報告ではない

エスカレーションを「問題を起こしたことを認める行為」と考えてしまうことがあります。

しかし、実際にはプロジェクトを成功させるためのマネジメント活動です。

原因分析が終わるまで待つ必要はない

原因分析や対策検討には時間がかかります。

その間に問題の影響が広がる可能性があります。

まず事実を共有し、その後詳細分析を進めることも重要な判断です。

プロジェクトマネージャ試験ではここが重要

IPAのプロジェクトマネージャ試験では、問題発生時の対応や関係者調整が重要なテーマになります。

論文では、以下のような観点が評価されます。

• 問題をどのタイミングで認識したか
• 誰へどのように共有したか
• 必要な判断や支援をどのように得たか
• その結果、プロジェクトをどう改善したか

優れたPMは、問題を隠すのではなく、適切なタイミングで組織の力を活用します。

PM道場のワンポイント

エスカレーションで大切なのは、「解決してから報告する」ことではなく、「問題だと思った時点で共有する」ことです。

プロジェクトマネージャは、すべての問題を一人で解決する役割ではありません。

必要な人へ情報を届け、適切な判断を引き出すことも重要な役割です。

特に、コミュニケーションが苦手なPMほど、「原因を整理してから伝えなければならない」と考えがちです。

しかし、早期共有によって、より多くの選択肢を持って対応できます。

優れたプロジェクトマネージャは、エスカレーションによって問題解決のスピードを高めています。

関連用語

• リスク（Risk）
• 課題（Issue）
• 問題管理
• 意思決定
• ステークホルダー
• コミュニケーションマネジメント
• 報告
• プロジェクトスポンサー

まとめ

エスカレーションとは、自分やチームだけでは解決できない問題や判断事項を、適切な相手へ共有し、支援や判断を得る活動です。

重要なのは、問題が大きくなってから行うのではなく、影響が広がる前に実施することです。

プロジェクトマネージャに求められるのは、すべての問題を一人で解決する力ではありません。

組織の力を活用し、プロジェクトを成功へ導くための判断を行う力です。

関連記事

• リスク（Risk）とは？
• 課題（Issue）とは？
• ステークホルダーとは？
• コミュニケーションマネジメントとは？
• プロジェクトスポンサーとは？

よくある質問（FAQ）

Q. エスカレーションとは何ですか？

A. 解決が難しい問題や判断事項を、適切な権限を持つ人へ共有し、支援や判断を求める活動です。

Q. エスカレーションはいつ行うべきですか？

A. 問題の影響が広がる可能性があると判断した時点で、早めに実施することが重要です。

Q. 原因分析や対策案がなくてもエスカレーションしてよいですか？

A. はい。まず事実や影響を共有し、必要な支援を得ることが重要です。

The post エスカレーションとは？プロジェクトを成功に導くための問題共有の考え方を解説 first appeared on PM道場.

しかし、プロジェクトではもう一つ設計しなければならないコミュニケーションがあります。

それがエスカレーションです。

私は人見知りだったこともあり、問題が起きてもすぐに相談することができませんでした。

• 「原因を整理してから報告しよう。」
• 「対策を考えてから相談しよう。」
• 「相手が納得できるように説明できる状態にしてから伝えよう。」

そう思っているうちに時間だけが過ぎ、気付けば問題が大きくなってしまうことが何度もありました。

当時の私は、「もっとコミュニケーション能力があればすぐに相談できたのに」と考えていました。

しかし今振り返ると、問題は性格ではありませんでした。

エスカレーションの仕組みを設計できていなかったのです。

人見知りほど「準備してから相談しよう」としてしまう

プロジェクトで問題が発生したとき、多くの人はすぐに相談できます。

一方、人見知りの人は違います。

• 「原因を調べてから。」
• 「対策を考えてから。」
• 「質問されたら答えられるようにしてから。」

そんなふうに、相談する前の準備に時間をかけてしまいます。

私もそうでした。

原因分析を行い、対策案を考え、相手が納得できる説明を用意してから報告しようとしていました。

しかし、その間にも時間は過ぎていきます。

プロジェクトでは、問題そのものよりも、問題への対応が遅れることの方が大きなリスクになる場合があります。

準備をしているつもりが、結果として問題を大きくしてしまっていたのです。

実は、原因より「速報」の方が価値がある

PMとして経験を積む中で、私の考え方は大きく変わりました。

今は、問題だと思った時点でエスカレーションするようにしています。

そのときに伝えることは、とてもシンプルです。

「問題だと思ったので、まずは報告します。まだ原因分析や対策案はできていません。」

これだけです。

以前の私なら、「そんな状態で報告してはいけない」と考えていたでしょう。

しかし実際には、この伝え方の方がずっと良い結果につながりました。

なぜなら、自分だけが問題だと思っていただけというケースが意外と多かったからです。

私にとっては重大な問題でも、上司や顧客からすると、

• 「それなら問題ありません。」
• 「そのまま進めて大丈夫です。」

と言われることも少なくありませんでした。

もし一人で抱え込んでいたら、必要のない不安を抱えたまま時間を使っていたことになります。

エスカレーションは、問題を報告するだけではありません。

自分一人の不安を、チームで確認するためのコミュニケーションでもあるのです。

エスカレーションは「原因」を共有するものではなく、「不安」を共有するもの

私は、エスカレーションの考え方を次のように変えました。

以前

「原因が分かったら報告する。」

現在

「問題だと思ったら報告する。」

原因分析や対策案は、その後にチームで考えれば十分です。

プロジェクトは、一人で解決するものではありません。

チームで解決するものです。

だからこそ、エスカレーションで最初に共有すべきなのは、

「私はここに不安を感じています。」

という事実なのだと思います。

エスカレーションにも「設計」が必要

PMBOK®^®︎では、コミュニケーションは計画し、管理するものとされています。

私は、エスカレーションも同じだと考えています。

「問題があれば相談してください。」

これだけでは、人によって判断が変わってしまいます。

だから私は、プロジェクトの規模に応じてエスカレーションの基準を決めるようにしていました。

小規模なプロジェクトの場合

ルールはとてもシンプルです。

「問題だと思った時点で相談してください。」

必要なのは次の2つだけです。

• 何が起きたのか
• 何を問題だと感じているのか

原因や対策は、一緒に考えます。

大規模なプロジェクトの場合

関係者が多くなるため、PMだけで全てを管理することは難しくなります。

そのため、課題管理表に必要な情報を記録し、その登録を連絡してもらう運用にしていました。

こうすることで、情報が漏れず、対応状況もチーム全体で共有できます。

もちろん、これが唯一の正解ではありません。

プロジェクトの規模や特性に応じて運用を変えることが大切です。

私はこれも、PMBOK®^®︎でいうテーラリングの考え方だと捉えています。

PMの最初の反応が、チームの文化を作る

エスカレーションしやすいチームには、一つ共通点があります。

それは、PMの最初の反応です。

私はまず、

「報告してくれてありがとう。」

と伝えるようにしています。

それだけで、相手は

「報告して良かった。」

と思えます。

逆に、

• 嫌そうな表情をする
• ため息をつく
• 責めるような質問をする

こうした反応をしてしまうと、次から相手は相談をためらうようになります。

私は人見知りだったからこそ、この影響を強く感じました。

相手の表情から「嫌だな」という感情を読み取ってしまうと、

「次はもう少し整理してから相談しよう。」

と思ってしまうのです。

その結果、エスカレーションは遅れます。

だからこそ、PMは問題の内容よりも先に、

相談しやすい空気を作れているかを意識する必要があります。

PMBOK®^®︎でも重要なのは「早く見える化すること」

PMBOK®^®︎では、リスクや課題は継続的に監視し、必要に応じて関係者へ共有することが重要だとされています。

私は、この考え方はエスカレーションにも当てはまると思っています。

大切なのは、完璧な情報を持ってから報告することではありません。

問題を早く見える化し、チームで対応を考えられる状態を作ることです。

エスカレーションとは、責任を手放すことではありません。

問題をチーム全体で管理できる状態へ変えることなのです。

おわりに

新人の頃の私は、

「原因が分かるまで相談してはいけない。」

そう思い込んでいました。

しかし今なら、当時の自分にこう伝えます。

「まずは問題だと思ったことだけ伝えよう。」

原因は、そのあとみんなで考えればいい。

プロジェクトマネジャは、一人で戦う仕事ではありません。

チームでプロジェクトを成功へ導く仕事です。

だからこそ、エスカレーションは問題を報告するための仕組みではなく、

一人で抱え込んでいた不安を、チーム全体の課題へ変えるための仕組みなのだと思います。

あなたへの問いかけ

あなたのプロジェクトでは、エスカレーションしやすい仕組みが設計されていますか。

そして、もし誰かが勇気を出して相談してきたとき、あなたは最初にどんな言葉を掛けるでしょうか。

その最初の一言が、チームのコミュニケーション文化を作るのかもしれません。

The post 人見知りのPMが問題を抱え込まないためのエスカレーション設計 first appeared on PM道場.