ステークホルダーの特定と分析

プロジェクトが止まるとき、原因が技術であることは意外と少ないものです。多くの場合、「聞いていない」「その前提では承認できない」という一言で止まります。つまり、人の問題として表面化します。

ステークホルダー管理は、こうした停止を減らすための活動です。目的は全員を満足させることではありません。誰が、どの決定に、どれだけ関与するのかを先に決めておくことです。

ステークホルダーとは、プロジェクトに影響を与える人、あるいはプロジェクトから影響を受ける人すべてを指します。顧客と上司だけではありません。

この中で見落とされやすいのが4番目です。決裁権は持たないが、反対されると進まない。こうした人を終盤に発見すると、手戻りは避けられません。

全員に同じ密度で関わることはできません。そこで2つの軸で分類し、関わり方を変えます。

関心度と影響力でステークホルダーを四つに分けた図

大切なのは、肩書きではなく実際の影響力で置くことです。役職は高くても実質的に関与しない人もいれば、役職は高くなくても現場を動かしている人もいます。

もうひとつ、この分類は固定ではありません。プロジェクトが進むと関心度は変わります。稼働が近づけば運用部門の関心は跳ね上がります。フェーズの節目ごとに置き直すのが実務的です。

一覧にするなら、名前と部署だけでは足りません。次の項目があると、実際に使える資料になります。

「懸念していること」の欄が特に重要です。人が反対するときには理由があります。多くは、業務が増えること、責任が増えること、これまでのやり方を否定されたと感じることです。懸念を先に書き出しておくと、説明の組み立てが変わります。

なお、この登録簿は姿勢の評価を含むため、本人に見せる資料ではありません。取り扱いには注意が必要です。

反対する人を説得しようとすると、たいてい対立が深まります。順序を変えると結果が変わります。

抵抗する人は、しばしば最も深く現場を知っています。その指摘が正しい場合もあります。反対を「障害」ではなく「情報」として扱えるかどうかで、プロジェクトの精度は変わります。

ステークホルダーを分類したら、それを具体的な段取りに落とします。

これを決めずに進めると、報告が「気づいた人が、気づいたときに」行われることになり、伝わっていない相手が必ず出ます。逆に全員に同じ報告書を送るのも機能しません。役員に20ページの進捗資料を送っても読まれないのと同じです。

ステークホルダー管理で最も効くのは、この一点かもしれません。

遅れや問題は、早く伝えるほど打てる手が多く、遅く伝えるほど選択肢がなくなります。それだけでなく、後から発覚した場合は「なぜ黙っていたのか」という信頼の問題に変わります。報告の内容そのものより、報告されなかった事実のほうが関係を損ないます。

早期に伝えるためには、伝えても責められない関係が前提になります。これはPMだけでなく、組織の側の課題でもあります。

ステークホルダー管理は、人当たりの良さや調整力といった属人的な資質の話に見られがちです。しかし実際には、洗い出し、分類し、関わり方を決めるという、他の管理領域と同じ手順の作業です。感覚に頼らず、書き出すところから始まります。

ユーザーコメント（0）