の3つが必要だと述べました。ステークホルダーの特定と分析ができたら、今度は「必要な情報を、知らせるべき人と共有する」必要があります。プロジェクトリーダーと窓口の顧客とだけで決めてしまい、情報を展開しなかったり、逆に誰かれかまわず「全員に知らせておけばいいだろう」と区別なく全員に情報を配信していると、重要なステークホルダーに必要な情報が届かなくなってしまいます。
それぞれのステークホルダーがプロジェクトのどの要素に、どのような影響を与えるのかを分析するのに役に立つのが、これから説明する「ステークホルダーマトリクス」です(下図)。
ステークホルダーマトリクスは、縦にステークホルダーのリストが、横にプロジェクトの要素が並んでいます。ステークホルダーとプロジェクト要素の交点となるセルには影響の種類を記入します。
ステークホルダーマトリクスを作成するには、まず、プロジェクト要素をリストアップします。上図ではプロジェクト要素のカテゴリーとして「リソース(資源)」「要件」「プロセス」「パフォーマンス評価」の4つを挙げています。これらのカテゴリーに属する要素として、プロジェクトにはどのような要素があるのかをリストアップします。
次に、ステークホルダーとなり得る人をリストアップします。このとき、組織図を手に入れたり、社内の事情を広く知っている顧客側の幹部社員に協力を要請するとよいでしょう。このとき、社内だけではなく、既存システムのベンダーなど、社外も含めて広くみる必要があります。
プロジェクト要素とステークホルダーのリストアップができたら、それぞれのステークホルダーが、プロジェクトのどの要素に、どの程度の影響力を持っているのかを分析し、それぞれの交点に記入します。
先に述べたように、ステークホルダーと共通認識を確立し、維持するためには、「(1)ステークホルダーをモレなく特定する」「(2)影響のある情報をモレなく展開する」「(3)結論を出すまでのプロセスを共有する」の3つが重要になります。ステークホルダーとプロジェクト要素との関連性を考えたとき、結論を出すまでの意思決定プロセスに参加してもらうべき人なのか、出した結論について情報を展開すればいい人なのかを分析します。
図中では「●意思決定プロセスに参加する」「◯意思決定の結果を知らせる」の2つのステータスで分類していますが、ほかにも「影響力がまったくない」「影響力がある程度ある」「影響力が大きい」「影響力が極めて大きい」の4つのステータスで分類するなどのやり方があります。
意思決定のプロセスを共有する
また、それぞれのステークホルダーの必要度に応じて、出した結論を展開するだけではなく、結論を出すまでのプロセス(議論)を共有することも重要です。例えば、システム導入にあたって、プロジェクトメンバーと実務部門の代表だけで要件を決めてしまうと、後になって「俺は聞いてない」「そんなのは無理だ」という話になりがちです。議論のプロセスを共有せずに結論だけを言い渡されれば、反発するのも無理はありません。
しかし、議論のプロセスを共有し、自分の意見も述べた上でなら、最終的に自分の意見とは違う結論になったとしても、納得できます。
キックオフミーティングの重要性
ステークホルダーを巻き込むために、とても重要なイベントが「キックオフミーティング」です。キックオフミーティングは、これからプロジェクトが開始されるということを周知し、プロジェクトの目的や目標、進め方など全体像をステークホルダーと共有する重要な機会となります。
キックオフミーティングの目的には「プロジェクトが正式に承認され、始まることを伝える」「ビジョン、方向性を共有する」「組織としての支援を働きかける」ことがあります。
この中でも重要なのは「組織としての支援を働きかける」ことです。キックオフミーティングは、経営層、関係部署、チームメンバーなど、プロジェクトに関わるステークホルダーをできるだけ広く集めて行います。システム導入などのプロジェクトは、業務を行うメンバーにしてみれば「情報システム部門の話でしょ」「どっかで誰かがやってくれるんでしょ」という認識しかないことがほとんどです。
しかし、システム導入はそれを実際に業務で使う人たちが主体的に関わらなければ成功することはありません。キックオフミーティングに参加してもらうことで「みなさん、当事者なんですよ」ということを認識してもらう必要があるのです。
そして、キックオフミーティングで真っ先に周知しなければならないのが、プロジェクトのビジョンです。プロジェクトには、さまざまな立場、考え方、価値観を持った人たちが関係します。多様なステークホルダーが違いの立場を超越して、共通認識を持ち続けるためには、プロジェクトの目的の共有から始めなければならないのです。
プロジェクトの目的とは「何のためにこのプロジェクトはあるのか」を表現したものです。プロジェクトリーダーを含む情報システム部門のメンバーは、何のためにプロジェクトをやるのかは当たり前のように理解していても、現場である業務部門メンバーには、プロジェクトの目的が知らされていないことも珍しくありません。
システム導入の多くは、「現場の生産性を上げたい」「現場の仕事をラクにしたい」という思いで立ち上がるにも関わらず、現場に目的が理解されていないために「余計な仕事が増える」という誤解を受けているケースも多いのです。
また、長丁場のプロジェクトになると、途中でプロジェクトの目的が見失われ、安易な妥協や、とにかく終わらせることに意識が向かってしまう場合があります。プロジェクトリーダーは、あらゆる機会を通じて、何度でも「何のためにこのプロジェクトはあるのか」を伝え続けることで、共通認識を維持する必要があります。
ステークホルダーとの関係に影響を与えるリーダーの振る舞い
繰り返しになりますが、ステークホルダーをマネジメントするに当たって、最も重要なことは「共通認識を確立し、維持する」ことです。いくらツールを駆使し、分析しても、プロジェクトリーダー自身の振る舞いが、ステークホルダーとの関係を大きく左右することは言うまでもありません。そこで、プロジェクトリーダーの姿勢として気を付けるべき点を挙げておきます。
(1)情報はリアルタイム、かつオープンに展開する
情報の展開はリアルタイム、かつオープンであることが大原則です。プロジェクトリーダーのところで情報が止まっている時間をゼロに近づけるようにしないといけません。よくあるのが、プロジェクトリーダーは「もう少し、詳細が詰まってから話そうと思っていた」のに対して、その情報が別のルートでステークホルダーの耳に入って「なんで、隠してるんだ!」となる場合です。詳細が決まっていないなら「詳細は決まっていない」ということを、リアルタイムに展開すればいいのです。
(2)情報は何度でも伝える
情報は一度伝えれば大丈夫ということはありません。重要な情報は、何度も伝える必要があります。しかし、「1回言ったから分かっているはず」と何度も伝える手間を省いてしまったり、プロジェクトリーダーは多人数を相手にしているために「何度も言った」と思い込んでしまう場合があります。
情報は驚くほど伝わらないものです。例えば、プロジェクトをどのようなプロセスで進めるのか、いつまでに何を終わらせる必要があるのかなど、プロジェクトメンバーでなければ、ほとんどの人は聞いて(覚えて)いないものです。タイミング、伝え方を変えて、何度も伝える必要があります。
(3)考え方の違いを許容する
プロジェクトを推進する立場にあるプロジェクトリーダーにとっては、プロジェクトの成功こそが正義であり、それに協力することが「義務」であると思い込んでしまうことがあります。そうすると「分かって当たり前」という感覚になり、共通認識を確立する努力をしなくなってしまいます。
組織にはさまざまな事情、背景、価値観を持った人がいます。人それぞれに見方が異なるのは当然です。多様なステークホルダーを相手に「共通認識」を確立するには、考え方の違いに敬意を払う必要があります。
まとめ
●ステークホルダーとは「プロジェクトの影響を受ける」と思っているすべての人たち。その人たちを特定する。
●ステークホルダー間で共通認識を確立し、維持していく。
●ステークホルダーの関心を知って、必要な情報を届ける。
日経SYSTEMS/芝本秀徳(プロセスデザインエージェント)