ステークホルダーを洗い出して、関わり方を決める

プロジェクトの終盤で「そんな話は聞いていない」と言い出す人が現れる。これは、立ち上げ期にその人を関係者として認識していなかったことが原因です。

ステークホルダーの洗い出しは、立ち上げ期の地味な作業です。しかし、ここを省略したプロジェクトは、後で必ず余計な調整に時間を取られます。

■ 体制図に載っている人だけが関係者ではない

多くの場合、体制図には「作る側」の人しか載っていません。ところが、プロジェクトを止める力を持っているのは、体制図の外にいる人であることが少なくありません。

洗い出しは、3つの切り口で行います。

切り口1：使う人

成果物を日常業務で触る人です。現場の担当者、問い合わせを受ける窓口、運用・保守を担当する人。この人たちは決裁権を持っていませんが、「使えない」と言われると稼働できません。

切り口2：決める人・承認する人

予算の決裁者、部門長、情報システム部門、セキュリティや監査の担当、法務。とくに情報システム部門とセキュリティは、終盤に登場して要件を追加してくることがあります。早い段階で巻き込んでおきます。

切り口3：作業をお願いすることになる人

他システムの担当者、外部ベンダー、データ移行元の部署、インフラ担当。「あとでお願いすればいい」と考えていると、その人の繁忙期とぶつかって動けないことがあります。

■ 洗い出しただけでは意味がない

名前を並べた一覧を作って満足してしまうのが、よくある失敗です。大事なのは、1人ずつ「その人とどう関わるか」を決めることです。一覧には次の項目を入れます。

• このプロジェクトへの期待　その人が何を得たいと思っているか

• 懸念していること　その人が何を心配しているか

• 関与度　高・中・低の3段階で十分です

• 接し方と頻度　いつ、どの場で、どうやって情報を届けるか

とくに「懸念していること」の欄が効きます。ここが埋まらない相手は、まだ本音を聞けていないということです。関与度が高いのに空欄なら、個別に話す時間をとります。

■ 関与度に応じて、接し方を変える

全員に同じ情報を同じ頻度で送る必要はありません。むしろ、関心のない人に細かい報告を送り続けると読まれなくなります。

• 関与度が高い人　定例に出てもらう。決定前に個別に相談する。悪い情報は即日伝える

• 関与度が中の人　節目のレビューに招く。月次で状況を共有する

• 関与度が低い人　稼働前の案内と、変更が影響するときだけ連絡する

「関与度が低い」と判断した人でも、影響が及ぶときには必ず連絡します。後から知らされた人は、内容よりも「知らされなかったこと」に反発します。

■ 反対しそうな人を、早めに見つける

どのプロジェクトにも、変化を歓迎していない人がいます。業務のやり方が変わることに不安がある、以前の失敗を覚えている、単に忙しくて関わりたくない。理由はさまざまです。

この人たちを避けて進めると、終盤に必ず問題になります。早い段階で会って、次のように聞きます。

• 「今回の変更で、困りそうなことはありますか」

• 「前に似たような取り組みがあったと聞きました。何が大変でしたか」

反論を封じるためではなく、懸念を設計に反映するために聞きます。聞かれた側は、それだけで扱いが変わります。

■ 一覧は、途中で更新する

ステークホルダーの顔ぶれは変わります。人事異動で決裁者が代わる、運用フェーズが近づいて保守部門が登場する、といったことが起こります。

• フェーズの変わり目（要件確定、テスト開始、稼働前）に一覧を見直す

• 決裁者が代わったら、改めて概要シートを説明しに行く

• 新しく登場した人は、関与度と接し方をその場で決めて一覧に足す

とくに決裁者の交代は要注意です。前任者と合意した内容が、後任者には引き継がれていないことがあります。早めに挨拶し、合意内容を確認します。

■ まとめ

ステークホルダー管理は、「誰がいるか」を知る作業ではなく、「誰に、いつ、何を伝えるかを決める」作業です。

立ち上げ期に一覧を作り、関与度と接し方まで決めておけば、進行中に「誰に確認すればよいか」で迷うことがなくなります。まずは3つの切り口で名前を書き出すところから始めてください。