しかし、プロジェクトではもう一つ設計しなければならないコミュニケーションがあります。

それがエスカレーションです。

私は人見知りだったこともあり、問題が起きてもすぐに相談することができませんでした。

• 「原因を整理してから報告しよう。」
• 「対策を考えてから相談しよう。」
• 「相手が納得できるように説明できる状態にしてから伝えよう。」

そう思っているうちに時間だけが過ぎ、気付けば問題が大きくなってしまうことが何度もありました。

当時の私は、「もっとコミュニケーション能力があればすぐに相談できたのに」と考えていました。

しかし今振り返ると、問題は性格ではありませんでした。

エスカレーションの仕組みを設計できていなかったのです。

人見知りほど「準備してから相談しよう」としてしまう

プロジェクトで問題が発生したとき、多くの人はすぐに相談できます。

一方、人見知りの人は違います。

• 「原因を調べてから。」
• 「対策を考えてから。」
• 「質問されたら答えられるようにしてから。」

そんなふうに、相談する前の準備に時間をかけてしまいます。

私もそうでした。

原因分析を行い、対策案を考え、相手が納得できる説明を用意してから報告しようとしていました。

しかし、その間にも時間は過ぎていきます。

プロジェクトでは、問題そのものよりも、問題への対応が遅れることの方が大きなリスクになる場合があります。

準備をしているつもりが、結果として問題を大きくしてしまっていたのです。

実は、原因より「速報」の方が価値がある

PMとして経験を積む中で、私の考え方は大きく変わりました。

今は、問題だと思った時点でエスカレーションするようにしています。

そのときに伝えることは、とてもシンプルです。

「問題だと思ったので、まずは報告します。まだ原因分析や対策案はできていません。」

これだけです。

以前の私なら、「そんな状態で報告してはいけない」と考えていたでしょう。

しかし実際には、この伝え方の方がずっと良い結果につながりました。

なぜなら、自分だけが問題だと思っていただけというケースが意外と多かったからです。

私にとっては重大な問題でも、上司や顧客からすると、

• 「それなら問題ありません。」
• 「そのまま進めて大丈夫です。」

と言われることも少なくありませんでした。

もし一人で抱え込んでいたら、必要のない不安を抱えたまま時間を使っていたことになります。

エスカレーションは、問題を報告するだけではありません。

自分一人の不安を、チームで確認するためのコミュニケーションでもあるのです。

エスカレーションは「原因」を共有するものではなく、「不安」を共有するもの

私は、エスカレーションの考え方を次のように変えました。

以前

「原因が分かったら報告する。」

現在

「問題だと思ったら報告する。」

原因分析や対策案は、その後にチームで考えれば十分です。

プロジェクトは、一人で解決するものではありません。

チームで解決するものです。

だからこそ、エスカレーションで最初に共有すべきなのは、

「私はここに不安を感じています。」

という事実なのだと思います。

エスカレーションにも「設計」が必要

PMBOK®^®︎では、コミュニケーションは計画し、管理するものとされています。

私は、エスカレーションも同じだと考えています。

「問題があれば相談してください。」

これだけでは、人によって判断が変わってしまいます。

だから私は、プロジェクトの規模に応じてエスカレーションの基準を決めるようにしていました。

小規模なプロジェクトの場合

ルールはとてもシンプルです。

「問題だと思った時点で相談してください。」

必要なのは次の2つだけです。

• 何が起きたのか
• 何を問題だと感じているのか

原因や対策は、一緒に考えます。

大規模なプロジェクトの場合

関係者が多くなるため、PMだけで全てを管理することは難しくなります。

そのため、課題管理表に必要な情報を記録し、その登録を連絡してもらう運用にしていました。

こうすることで、情報が漏れず、対応状況もチーム全体で共有できます。

もちろん、これが唯一の正解ではありません。

プロジェクトの規模や特性に応じて運用を変えることが大切です。

私はこれも、PMBOK®^®︎でいうテーラリングの考え方だと捉えています。

PMの最初の反応が、チームの文化を作る

エスカレーションしやすいチームには、一つ共通点があります。

それは、PMの最初の反応です。

私はまず、

「報告してくれてありがとう。」

と伝えるようにしています。

それだけで、相手は

「報告して良かった。」

と思えます。

逆に、

• 嫌そうな表情をする
• ため息をつく
• 責めるような質問をする

こうした反応をしてしまうと、次から相手は相談をためらうようになります。

私は人見知りだったからこそ、この影響を強く感じました。

相手の表情から「嫌だな」という感情を読み取ってしまうと、

「次はもう少し整理してから相談しよう。」

と思ってしまうのです。

その結果、エスカレーションは遅れます。

だからこそ、PMは問題の内容よりも先に、

相談しやすい空気を作れているかを意識する必要があります。

PMBOK®^®︎でも重要なのは「早く見える化すること」

PMBOK®^®︎では、リスクや課題は継続的に監視し、必要に応じて関係者へ共有することが重要だとされています。

私は、この考え方はエスカレーションにも当てはまると思っています。

大切なのは、完璧な情報を持ってから報告することではありません。

問題を早く見える化し、チームで対応を考えられる状態を作ることです。

エスカレーションとは、責任を手放すことではありません。

問題をチーム全体で管理できる状態へ変えることなのです。

おわりに

新人の頃の私は、

「原因が分かるまで相談してはいけない。」

そう思い込んでいました。

しかし今なら、当時の自分にこう伝えます。

「まずは問題だと思ったことだけ伝えよう。」

原因は、そのあとみんなで考えればいい。

プロジェクトマネジャは、一人で戦う仕事ではありません。

チームでプロジェクトを成功へ導く仕事です。

だからこそ、エスカレーションは問題を報告するための仕組みではなく、

一人で抱え込んでいた不安を、チーム全体の課題へ変えるための仕組みなのだと思います。

あなたへの問いかけ

あなたのプロジェクトでは、エスカレーションしやすい仕組みが設計されていますか。

そして、もし誰かが勇気を出して相談してきたとき、あなたは最初にどんな言葉を掛けるでしょうか。

その最初の一言が、チームのコミュニケーション文化を作るのかもしれません。

The post 人見知りのPMが問題を抱え込まないためのエスカレーション設計 first appeared on PM道場.

「PMに必要なのはコミュニケーション能力ではなく、コミュニケーションを設計する力」

という考え方について書きました。

では、そのコミュニケーションは、いつ設計すればよいのでしょうか。

私の答えは、プロジェクト開始時のキックオフミーティングです。

キックオフミーティングというと、次のような「説明会」のイメージを持っている方も多いでしょう。

• プロジェクトの目的を説明する
• スケジュールを共有する
• 体制を説明する

もちろん、それらも大切です。

しかし、人見知りだった私にとって、キックオフミーティングの一番の目的は違いました。

「初対面」を終わらせること。

これが、私にとってのキックオフミーティングの本当の価値でした。

人見知りにとって一番難しいのは「最初の一言」

私は昔から人見知りでした。

特に苦手だったのは、初対面の人との会話です。

プロジェクトが始まると、多くのメンバーやステークホルダーとは初めて仕事をします。

本来であれば、自分から声を掛けて関係を築いた方が良いのでしょう。

しかし私は、

• 「何を話せばいいんだろう。」
• 「今話しかけても迷惑ではないかな。」

そんなことばかり考えてしまい、自分から話しかけることができませんでした。

「そのうち話す機会があるだろう。」

そう思って先延ばしにしていたのです。

しかし、その「そのうち」は、決まってトラブルが起きたときでした。

キックオフをやらないと、プロジェクトは「いつの間にか」始まってしまう

ある時、キックオフミーティングを実施しなかったプロジェクトがありました。

気付けば、それぞれが作業を始め、プロジェクトは静かにスタートしていました。

しかし、そのプロジェクトではチームマネジメントがうまくいきませんでした。

プロジェクトメンバーは、

• 何のためにこのプロジェクトをやるのか
• どれほど重要なプロジェクトなのか

を十分に理解できていませんでした。

そのため、当事者意識も生まれにくく、PMである私が後から一人ひとりとコミュニケーションを取り、プロジェクトへの意識を高めていく必要がありました。

人見知りの私にとって、それは非常に大きな負担でした。

今振り返ると、問題はコミュニケーション能力ではありません。

プロジェクトのスタートを設計できていなかったのです。

キックオフは「説明会」ではなく「チームを作る場」

それ以来、私は必ずキックオフミーティングを実施するようになりました。

ただし、目的は説明ではありません。

私が一番大切にしているのは、

「このプロジェクトを成功させるチームを作ること」です。

そのために、必ず次のことを伝えています。

• このプロジェクトの目的
• なぜ今このプロジェクトが必要なのか
• ステークホルダーが期待していること
• 会社として期待していること
• PMとして、このプロジェクトにかける思い

スケジュールや体制は資料を見れば分かります。

しかし、

「このプロジェクトは重要なんだ。」

という熱意は、PM自身の言葉でしか伝えられません。

私は、この時間がプロジェクトメンバーの当事者意識を育てるのだと思っています。

不安を話してもらう時間が、未来のリスクを減らす

キックオフでは、もう一つ必ず行っていることがあります。

一人ひとりに、不安なことを話してもらうことです。

プロジェクトの規模によって時間は調整しますが、できる限り全員に話してもらいます。

すると、

• この技術は経験がありません
• スケジュールが少し心配です
• 他案件との兼務があります

など、さまざまな声が聞こえてきます。

これは単なる自己紹介ではありません。

私はこの時間を、リスクを見つける時間だと思っています。

さらに、この時間にはもう一つ大きな意味があります。

全員が一度は発言することで、

「話してもいい場なんだ。」

という空気が生まれます。

この最初の一言が、その後の相談のしやすさにつながっていくのです。

最初の30分が、その後数か月のコミュニケーションを変える

キックオフが終わると、不思議なくらいコミュニケーションが楽になります。

• チャットを送る
• 電話を掛ける
• 相談する

どれも心理的なハードルが下がるのです。

特に電話では、その効果を強く感じます。

相手は、私の顔を思い出しながら話してくれている。

私も、「一度話した相手だから」という安心感があります。

トラブルが起きたときも、

「すぐ連絡してください。」

と言えば、すぐに対応してくれることが増えました。

私はこれを、キックオフで築いた信頼関係のおかげだと考えています。

PMBOK®には「キックオフをやりましょう」とは書かれていない

PMBOK®には、

「必ずキックオフミーティングを実施しましょう。」

とは書かれていません。

しかし、コミュニケーション・マネジメントでは、必要な情報を必要な人へ適切なタイミングで届けることが重要だとされています。

また、ステークホルダー・エンゲージメントでは、ステークホルダーとの良好な関係を構築し、維持することが求められます。

私は、この考え方を実践する最初の機会がキックオフミーティングだと考えています。

単なる説明会ではありません。

チームを作り、信頼関係を築き、コミュニケーションを始めるための最初のイベントなのです。

おわりに

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

初対面の人と話すことが得意になったわけではありません。

それでも、キックオフミーティングを大切にするようになってから、コミュニケーションに対する苦手意識は大きく減りました。

理由は簡単です。

自分を変えたのではなく、コミュニケーションが生まれる環境を設計したからです。

キックオフミーティングは、プロジェクト開始の儀式ではありません。

チームが同じ方向を向き、安心して相談できる関係を作るための第一歩です。

だから私は、人見知りのPMほどキックオフミーティングを大切にしてほしいと思っています。

あなたへの問いかけ

あなたのプロジェクトのキックオフミーティングは、「説明会」で終わっていませんか。

それとも、チームを作るための最初のコミュニケーション設計になっているでしょうか。

The post 人見知りのPMほどキックオフミーティングをやるべき理由 first appeared on PM道場.

プロジェクトマネージャについて学ぶと、必ずと言っていいほど耳にする言葉です。

そのため、「話すのが得意な人」「誰とでもすぐに打ち解けられる人」がPMに向いていると思われがちです。

しかし、PMBOK®を読むと少し違った景色が見えてきます。

PMBOK®では、コミュニケーション・マネジメントについて、「必要な情報を、必要な人へ、適切なタイミングで届けるための計画・実行・監視」を重視しています。

一方で、「社交的になりましょう」「話し上手になりましょう」とは書かれていません。

私はこの違いに救われました。

なぜなら、私は人見知りだったからです。

私は「コミュニケーション能力を身に付けなければPMは務まらない」と思っていました。

しかし10年以上PMとして仕事を続ける中で気付いたのは、PMに本当に必要なのはコミュニケーション能力ではなく、コミュニケーションを設計する力だったということです。

私が一番苦手だったのは「初対面の人」と話すこと

人見知りにもさまざまなタイプがありますが、私が特に苦手だったのは初対面の人との会話でした。

プロジェクトが立ち上がると、多くのメンバーやステークホルダーとは初めて仕事をします。

本来であれば、自分から積極的に声を掛けて関係を築いた方が良いのでしょう。

しかし私は、

• 何と話しかければいいんだろう。
• 今話しかけても迷惑ではないかな。

そんなことばかり考えてしまい、自分から声を掛けることができませんでした。

「そのうち話す機会があるだろう。」

そう思って先延ばしにしていたのです。

ところが、その「話す機会」は決まってトラブルが起きたときでした。

トラブルのときに初めて話すのでは遅い

問題が発生すると、PMは多くの人と連携しながら状況を整理し、対応方針を決めなければなりません。

しかし、お互いに十分な関係性ができていない状態では、

• 相談しづらい
• 本音を引き出しにくい
• お願いもしづらい

という状況になります。

私は何度も、

「もっと早く話しておけば良かった。」

と後悔しました。

当時は「コミュニケーション能力が足りないからだ」と思っていましたが、今振り返ると違います。

コミュニケーションが生まれる場を設計できていなかったのです。

私を変えたのは「キックオフミーティング」だった

転機になったのは、キックオフミーティングの目的を変えたことでした。

以前の私は、キックオフはプロジェクトの目的やスケジュールを説明する場だと考えていました。

しかし今は違います。

私にとってキックオフの最大の目的は、

「最初のコミュニケーションを設計すること」

です。

自己紹介をする。

挨拶をする。

顔と名前を一致させる。

ほんの数分の会話でも構いません。

一度でも会話していると、その後のコミュニケーションは驚くほど楽になります。

チャットを送る心理的なハードルが下がります。

電話を掛けるときも、

「相手は自分の顔を思い出しながら話してくれている。」

そんな安心感があります。

私は社交的になったわけではありません。

社交的でなくても話せる環境を作っただけだったのです。

振り返ってみると、私は無意識のうちに「コミュニケーション・マネジメント計画」を見直していたのだと思います。

「誰と、いつ、どのようにコミュニケーションを取るか」を計画することは、情報共有だけではありません。

コミュニケーションが自然に生まれるきっかけを設計することでもあるのです。

PMBOK®の「テーラリング」を、自分自身にも適用してみた

PMBOK®では、プロジェクトの特性に合わせてプロセスや手法を調整することをテーラリングと呼びます。

私はこの考え方を、プロジェクトだけでなく自分自身にも当てはめるようになりました。

以前は、

• もっと話せるようになろう。
• 人見知りを克服しよう。

と考えていました。

しかし、それでは長続きしませんでした。

そこで発想を変えました。

「人見知りでも成果を出せるプロジェクト運営を設計しよう。」

そう考えるようになったのです。

キックオフを実施する。

定例会を設ける。

レビューの場を作る。

相談しやすいルールを決める。

これらはプロジェクトを管理するためだけではありません。

自分の苦手を補うための仕組みでもありました。

PMは「人を変える」のではなく、「行動しやすい環境」を設計する

この考え方は、プロジェクトメンバーにも当てはまります。

PMは、

「もっと相談してください。」

「もっと報告してください。」

と言うだけでは十分ではありません。

相談しやすいタイミングを決める。

報告する基準を決める。

定例会や1on1を設ける。

つまり、行動しやすい環境を設計することが重要です。

これは、PMBOK®のステークホルダー・エンゲージメントの考え方にも通じます。

ステークホルダーを動かすために必要なのは、「相手の性格を変えること」ではありません。

相手が行動しやすい環境を整えることです。

そして、この考え方は自分自身にも使えます。

人見知りという性格を変えようとするのではなく、

人見知りでも行動できる環境を設計する。

その方が、ずっと現実的で、再現性があります。

私が考えるPMのコミュニケーション能力

私は昔、コミュニケーション能力とは、

• 話すのが上手なこと
• 誰とでも仲良くなれること

だと思っていました。

しかし、今は違います。

私にとってPMのコミュニケーション能力とは、

「必要な情報が、必要な人へ、必要なタイミングで届く状態を設計する力」

です。

話すことが目的ではありません。

プロジェクトを前に進めることが目的です。

だからこそ、PMに必要なのは社交性ではなく、

必要なコミュニケーションが自然に生まれる仕組みを作る力なのだと思います。

おわりに

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

初対面の人と話すことが得意になったわけではありません。

それでもPMとして仕事を続けられているのは、自分を変えたからではありません。

自分に合った環境を設計するようになったからです。

これは、プロジェクトマネジャという仕事の本質にも通じています。

PMは、プロジェクトを成功へ導くために、計画を立て、仕組みを作り、人が動きやすい環境を整えます。

それなら、自分自身に対しても同じことができるはずです。

苦手なことを無理に克服しようとするのではなく、

苦手でも成果を出せる環境を設計する。

私は、それこそがプロジェクトマネジメントの考え方を、自分自身に活かすことなのだと思っています。

あなたへの問いかけ

あなたは、苦手なことに出会ったとき、自分を変えようとしていませんか。

それとも、苦手でも成果を出せる環境を設計しようとしていますか。

プロジェクトマネジメントは、プロジェクトを管理するための知識だけではありません。

自分自身をマネジメントするための考え方でもあるのではないでしょうか。

まずは一つだけ、環境を変えてみる

もしあなたが私と同じように人見知りで悩んでいるなら、性格を変えようとする必要はありません。

まずは一つだけ、コミュニケーションが自然に生まれる仕組みを作ってみてください。

例えば、キックオフで必ず全員と自己紹介をする、定例会を設ける、1on1の時間を確保するなど、小さな工夫で十分です。

自分を変えることは難しくても、環境を変えることはできます。

その小さな仕組みが、プロジェクトだけでなく、あなた自身をきっと助けてくれるはずです。

The post PMに必要なのはコミュニケーション能力ではない。「コミュニケーションを設計する力」だった first appeared on PM道場.

プロジェクト憲章は、プロジェクトの正式なスタートを宣言し、プロジェクトマネージャへ権限を与える重要な文書です。

この記事では、プロジェクト憲章の意味や目的、記載内容、プロジェクト計画書との違い、実務での活用方法までわかりやすく解説します。

一言でいうと

プロジェクト憲章とは、「プロジェクトの開始を正式に承認し、プロジェクトマネージャへ権限を与える文書」です。

プロジェクト憲章とは

プロジェクト憲章（Project Charter）は、PMBOK®でも重要な成果物の一つとして位置付けられています。

プロジェクトの目的や背景、期待される成果、主要な関係者などを整理し、「このプロジェクトを開始する」という組織としての意思を明確にする役割があります。

また、プロジェクトマネージャは、この文書によって正式にプロジェクトをマネジメントする権限を与えられます。

プロジェクト憲章に記載される主な内容

組織によって書式は異なりますが、一般的には次のような内容が記載されます。

• プロジェクトの目的・背景
• 期待される成果
• プロジェクトの概要
• 成功基準
• 主要なステークホルダー
• プロジェクトマネージャ
• 予算やスケジュールの概要
• 前提条件・制約条件
• スポンサーの承認

なぜプロジェクト憲章が必要なのか

プロジェクトが始まる際、「何のためにこのプロジェクトを行うのか」が曖昧なまま進んでしまうと、途中で方向性がぶれてしまうことがあります。

プロジェクト憲章を作成することで、次のようなメリットがあります。

• プロジェクトの目的を関係者で共有できる
• プロジェクトマネージャの権限を明確にできる
• 関係者の認識を合わせられる
• 途中で目的がぶれることを防げる

プロジェクトの土台となる文書だからこそ、開始時にしっかりと作成することが重要です。

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

例えば、新しい販売管理システムを導入するプロジェクトを考えてみましょう。

プロジェクト憲章には、次のような内容がまとめられます。

• 目的：販売業務を効率化する
• 背景：現行システムの老朽化
• 納期：2027年3月末
• 予算：○○円
• スポンサー：営業本部長
• プロジェクトマネージャ：山田氏

これらを関係者全員で共有することで、「何を目指すプロジェクトなのか」が明確になります。

プロジェクト計画書との違い

プロジェクト憲章は「始めるための文書」、プロジェクト計画書は「成功させるための文書」と考えると違いが理解しやすくなります。

よくある勘違い

プロジェクト憲章は形式的な文書ではない

「テンプレートを埋めるだけ」と考えられることがありますが、プロジェクトの方向性を決める重要な文書です。

プロジェクト計画書があれば不要ではない

プロジェクト計画書は実行方法を示す文書です。

一方、プロジェクト憲章は「なぜ実施するのか」「誰が責任を持つのか」を明確にする役割があり、それぞれ目的が異なります。

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

IPAのプロジェクトマネージャ試験では、「プロジェクトの目的を関係者と共有すること」「プロジェクト開始時の合意形成」は論文でも頻繁に登場するテーマです。

午後Ⅱでは「背景」「目的」「制約条件」「成功基準」を明確にして論述すると、プロジェクト憲章の考え方を自然に取り入れることができます。

PMBOK®でも、プロジェクト憲章は立上げプロセス群を代表する重要な成果物です。

PM道場のワンポイント

プロジェクト憲章は「承認をもらうための資料」ではなく、「迷ったときに立ち返る原点」です。プロジェクトが進むと、「本当に目指していたことは何だったのか」が見えにくくなることがあります。そんなときこそ、プロジェクト憲章に書かれた目的や成功基準を確認することで、意思決定の軸を取り戻すことができます。

実務では、キックオフ後に一度も見返されないケースもありますが、本来はプロジェクト全体を通して活用すべき文書です。

関連用語

• プロジェクト
• プロジェクトマネジメント
• プロジェクトマネージャ（PM）
• スポンサー
• ステークホルダー
• プロジェクト計画書
• WBS
• ベースライン

まとめ

プロジェクト憲章とは、プロジェクトの開始を正式に承認し、目的や成功基準、責任者を明確にする文書です。

プロジェクト計画書とは役割が異なり、「なぜこのプロジェクトを行うのか」という原点を示す重要な役割があります。

プロジェクトを成功へ導くためには、開始時にプロジェクト憲章をしっかり作成し、プロジェクト中も必要に応じて立ち返ることが大切です。

関連記事

• プロジェクトとは？
• プロジェクトマネジメントとは？
• プロジェクトマネージャ（PM）とは？
• スポンサーとは？

よくある質問（FAQ）

Q. プロジェクト憲章は誰が作成しますか？

A. 一般的にはスポンサーが発行し、プロジェクトマネージャや関係者が内容の作成を支援します。組織によってはPMがドラフトを作成し、スポンサーが承認するケースもあります。

Q. プロジェクト憲章とプロジェクト計画書は同じですか？

A. いいえ。プロジェクト憲章はプロジェクト開始を承認する文書であり、プロジェクト計画書はプロジェクトをどのように進めるかを示す文書です。

Q. 小規模なプロジェクトでもプロジェクト憲章は必要ですか？

A. 必ずしも大規模な文書は必要ありませんが、目的や責任者、成功基準を明確にして関係者で共有することは、小規模なプロジェクトでも有効です。

The post プロジェクト憲章とは？目的や記載内容を初心者向けにわかりやすく解説 first appeared on PM道場.