見出し画像

忘れないうちにステークホルダーマネジメントについて書いておく


前職での経験を言語化しておく

転職する前は複数のステークホルダーの期待を調整したり、それぞれの文化背景に合わせてアプローチを変えたり、フィードバックを自分たちの計画に取り入れたりといったステークホルダーマネジメントを行う機会が多くありました。
転職してからはスモールチームのEMにロールチェンジしたこともあり、タフなステークホルダーマネジメントをするタイミングは今のところありません。
活用しないスキルというのは衰えていきますし、思い出さないナレッジは忘れていきます。今後数年以内には使うことになるだろうスキル・ナレッジなので、覚えているうちに自分のために書き留めておきます。

ステークホルダーマネジメントでやること

ステークホルダーマネジメントは、ざっくり以下のようなことを行うプロセスだと考えています。

  • ステークホルダーの特定

  • ステークホルダーとの協力関係の形成

  • 組織のケイパビリティとステークホルダーの期待の折り合いをつける(期待マネジメント)

  • ステークホルダーと組織の間の情報非対称性を低減させる

ステークホルダーの特定

インセプションデッキでいうところの「ご近所さんを探せ!」です。自分が管掌する組織に対して要望を出す人(経営者、顧客、隣接組織の責任者など)はわかりやすいですが、自組織の活動によって影響を受ける人(使用しているプラットフォームの管理組織など)もステークホルダーです。
後者の巻き込みが抜けていると予期せぬ不具合やインシデントの発生を招いたり、リリース直前で計画が頓挫してしまったりといった望ましくない結果を招くことがあるので要注意です。

ステークホルダーとの協力関係の形成

ともに伴走するのか、最小限のコミュニケーションで協力していくのかはステークホルダーとの関わり方次第で大きく変わってきます。
チームトポロジーで提案されている3つのコミュニケーションパターンがわかりやすいので、まずこの類型に従って分類してみるとよいでしょう。

  • Collaboration: 他のチームと一緒に働く

  • X-as-a-Service: コラボレーションを最小にしてツールやAPIを提供する

  • Facilitation: 他のチームを補助する

この類型に当てはまらないコミュニケーションパターンになる場合、それが適切なものか精査が必要です。たとえばコミュニケーション頻度が低くX-as-a-Service的な関わり方をしているにもかかわらずステークホルダーからの要求変更・追加が突発的かつ緊急でやってくる場合、組織が高負荷にさらされたり他の業務に影響を及ぼす恐れがあります。
たとえば、以下のようなコミュニケーションが発生していたら要注意でしょう。

「要件がまだ明確じゃないので、しばらくは週次で開発中のものを見てもらう時間をとりたいのですが。」
「うーん、出来上がってからでいいよ。途中の見てもしょうがないし。」

この場合、高頻度に見てもらうことで早期に必要なものにたどり着ける可能性があることを伝えたり、どうしても参加が難しい場合は代理を立ててもらったりするよう働きかけましょう。なお、代理に権限委譲されていない場合は共有会の時間を有効に活用することができないので、これも注意してください。

組織のケイパビリティとステークホルダーの期待の折り合いをつける(期待マネジメント)

これがステークホルダーマネジメントを行う上で最も注意を払っていた項目です。

ステークホルダーが単一の場合

ステークホルダーが期待するQCDSと組織のケイパビリティの間でバランスが取れている場合は特に問題ありませんが、QCDSの何かを調整しなければならないときは期待マネジメントが必要になります。
たとえばDeliveryの優先順位が一番高い場合(デッドラインが設定されている場合)、QCSいずれかでバランスをとっていくことになります。@t_wadaさんの「質とスピード」で言及されていることなのでご存知の方も多いとおもいますが、このときに犠牲になりやすいのがQ、その中でも内部品質です。

内部品質を犠牲にしてしまうとのちのち大きなツケを払うことになるので避けたい。では何で調整するか?
コストに関してイコール人件費として捉えると、人が必要になった段階で急に投入してもうまくワークしません。むしろ遅くなってしまいます。
となるとスコープで調整していくことになるのですが、「機能を絞る」ということに慣れていないステークホルダーもいます。
また、「間に合わせるために機能を絞りたい」というアプローチを好まない文化的背景をもつステークホルダーもいます。全部やりきるのがプロフェッショナルだと思っている人には、この提案は消極的なものにうつるのです。
間に合わせるために機能を絞りたいというのはこちらの都合ではあるので、ステークホルダーが理解できないのも仕方ない、という面もあります。
であればどうするか?ステークホルダーの視点に立ちます。「なぜ今か(ホワイナウ)」を問うのです。
このシンプルな問いは、セコイア・キャピタルというベンチャーキャピタルが多用していたそうです。今やると何が得られるのか、今やらないとどのような問題があるのか、などをあきらかにする問いで、本当に欠かすことのできないコアの要件が浮き彫りになっていきます。
明らかになった時点で「では、デッドラインの時点でそのコア機能が備わっていれば期待する提供価値を実現できそうですか?」と確認をとります。そうすれば、ステークホルダーの視点で、ステークホルダーの意思でスコープを絞ることができます。

ステークホルダーが複数の場合

この場合、どのステークホルダーも自分の要求が一番大切だと考えていることが往々にしてあるので、合理的に判断することが難しい場合があります。
法的拘束力、社会的要請、市場力学などを考慮しながら横断的に優先順位をつけていき、それでも平行線になる場合はステークホルダー同士で話し合ってもらう、ステークホルダーの上位者に決定してもらう、といったことが必要になる場面もあります。

ステークホルダーと組織の間の情報非対称性を低減させる

ステークホルダーと組織がコミュニケーションする頻度が少ない場合、情報非対称性が発生してしまいます。できる対策として、組織の中で流通している情報は極力カンバンなどで見える化しておく、SlackでWorking out loudしておくなどが考えられます。

ステークホルダーとの情報非対称性でやっかいなのが、ステークホルダーと組織の間に中間者がいる場合です。仲立ちになる人物がいて、その人越しにステークホルダーの意見が伝わってくる。この場合、不可避的に仲立ちする人物の価値観によるバイアスが加わってしまうため、ステークホルダーの判断が正しくない形で伝わるおそれがあります。

この対策はシンプルで、できるだけステークホルダーと直接コミュニケーションをすることで伝言ゲームによる情報非対称性の発生を防ぐことができます。
たとえば「これはステークホルダーの意向でマスト。来月までに必要だ」と言われていたものが、本人に確認すると「ああ、たしかにあったらうれしいよ。でもマストじゃないし来年くらいで考えてたよ」なんて返されることがあったりします。

ステークホルダーと協力して良いものをつくろう

ステークホルダーと良い関係を築くことは良いプロダクトづくりをするうえでとても重要なポイントです。良好な関係を築いていきましょう。

ざっと、私がステークホルダーマネジメントで気をつけていることを書き留めました。未来の私の、そして今を生きる誰かの役に立てば幸いです。

この記事が気に入ったらサポートをしてみませんか?