ステークホルダーとのコミュニケーション 〜 11の実績のある戦術

TL; DR: はじめに

ステークホルダーとのコミュニケーション。アジャイルプロダクト開発組織にとって、素晴らしいコードを開発し、完成したプロダクトを時計仕掛けのように提供するだけでは十分ではありません。特に、学習する組織になるための取り組みの最初に、このことについて話をすることが手助けとなります。

組織の他の人たちへ自分自身のジャーニーをマーケティングし、その結果、彼らのサポートやコラボレーション、賛同を確保することは、変革のゲームをステップアップさせるための重要な成功要因になります。あなたは「アジャイルになりたい（become agile）」のであって、「アジャイルをやりたい（do agile）」のではないはずです。

この実現につながる11の実績のあるステークホルダーとのコミュニケーションの戦術の詳細をみていきましょう。

アジャイルへの移行中におけるステークホルダーとのコミュニケーションチャネル

アジャイルへの移行が、時間をかけて組織全体に受け入れられるものであるならば、社内のステークホルダーとのコミュニケーション方法を早い段階で決めておくこと、彼らの評判通りに心を掴むことができることが、最終的には「アジャイルをやる」と「アジャイルになる」の違いを生み出すことが多いです。

多くのステークホルダーのエゴ、組織内でのステークホルダーの地位、ステークホルダーの報酬、個人的な議題は、「ある計画」を実行するために何らかの方法で結び付いていることを忘れないでください。そして、もしステークホルダーたちが「この計画」が、アジャイルや学習、顧客中心の組織に発展させようとするプロダクト開発の展望だと勘違いしているならば、今まさに、「この計画」を止めることが相互に利益になることを伝えましょう。

ステークホルダーの立場になって考えてみてください。ステークホルダーは、パーカーを着たオタクたちに自身のキャリアを託しますか？XPやスクラムを実践しているからといった大きな報酬をコミットできますか？

ステークホルダーへの共感を高めることは、アジャイルへの移行の初期の段階において、エンジニアリングとプロダクトが組織の中で最高の地位を得られていない場合は特に重要になります。幸いなことに、両者がブラックホールとして認識されているかどうかに関わらず、うまく組織化されたコミュニケーション戦略は、組織の他の人たちに勝つチャンスがあるということです。

実績あるステークホルダーとのコミュニケーション戦術

私の経験かさ判断すると、以下のようなステークホルダーとのコミュニケーション戦術は、最初のうちから積極的に推進されていれば、有用であることがわかりました。いずれの戦術も同様のアプローチを採用しています：ステークホルダーによる検査と適応を可能とする完全な透明性を提供し、違いを促進し、すべての人に発言権を与えます。

1. スクラムイベント

ステークホルダーがスクラムチームと責任をもって対話する機会はいくらでもあります。スクラムの公式のイベントとしては、次の2つが考えられます。

スプリントレビュー

スプリントレビュー は、プロダクトインクリメントを検査し、プロダクトバックログを適応する経験主義な作業です。開発チーム、プロダクトオーナー、ステークホルダーは、顧客に価値を提供するための軌道に乗っているかどうか把握する必要があります。プロダクトバックログがスクラムチームのリソースを最大限に活用しているかどうかについて、すべての参加者の間で理解を共有し、顧客に提供する価値を最大化するための絶好の機会になります。スプリントレビューを「スプリントデモ」と呼ぶことがスクラムチームの効果性にとっての重要性と一致しないのも、このような背景があるからです。

このイベントのリズム（ケイデンス）は、スクラムチームのスプリントの長さに依存します。例えば、スクラムチームのスプリントが揃っているかどうか、継続的デリバリーを実践しているかどうかは、プロダクト、マーケット、ガバナンスの要件によって影響されます。

例えば、1週間ごとなど、スプリントレビューの頻度が高すぎると、あまり目新しさを提供することができないため、すぐに消耗してしまう傾向があります。

スクラッチから開発をし始めたばかりでなければ、毎週のスプリントレビューは、チームビルディングと組織全体の調整に最適です。それにより、共通の精神を生み出すことができます。すべての勝利を祝いたいならば、それは手助けになるでしょう。

スプリントレビューでのステークホルダーとのコミュニケーションの基本ルールは簡素です：

• ステークホルダーに協力の重要性を教育する
• 手本を示してリードする
  エンジニアリングチームとプロダクトチームが参加して検討します。もし仲間がスプリントレビューを自分たちの時間にとって価値ある投資だと考えていないならば、なぜステークホルダーは自分の時間を投資するのでしょうか？
• スプリントレビュー は、語るのではなく見せる
  スプリントレビューは、PowerPoint による死から解放されたゾーンです。
• ステークホルダーを招待して、舵取りをしてもらう
• スプリントレビューは、短く、刺激的を維持する
  スプリントレビューを設計するために LS (Liberating Structures) を用いることは、すべての人を巻き込み、すべての人に発言権を与える上で非常に有用であることは幾度となく実績があります。
• ステークホルダーに参加を促す
  初期の頃は、ステークホルダーがスプリントレビューの重要性を十分に理解していない場合があります。この場合は、イベントへの参加を促す必要があるでしょう。必要ならステークホルダーに賄賂を送りましょう。レビュー参加していて説得力のある問題を提示できる人に、レビュー中にいくつかのストーリーポイントを与えるとうまくいきます（ただし、このハックを習慣化してはいけません）。
• もちろん、スプリントレビューは仮想的にセッティングした分散チームとの相性もよい
   参考: Sprint Reviews also work well with distributed teams in a virtual setting
• 典型的なスプリントレビューのアンチパターンを避ける
  参考: Sprint Review anti-patterns

デイリースクラム

開発チームがこのアイデアに納得するならば、ステークホルダーをデイリースクラムに招待して、受動的に参加してもらいます。ただし、　断定的なステークホルダーとは断固とした態度で接する必要があります。そうしなければ、デイリースクラムのあとに報告会をしようとするかもしれません。もし開発チームがこのアイデアに乗り気でないならば、彼らの決定を無視しないようにしましょう。結局のところ、デイリースクラムは開発チームに帰属しているからです。

ステークホルダーレトロスペクティブ

定期的なリズム（ケイデンス）で、おそらくは四半期に一度くらいで、ステークホルダーを含めた参加型のメタレベルのレトロスペクティブ（ふりかえり）を提案しましょう。

メタレトロスペクティブは、拡張したチーム内でのコラボレーションを促進し、全体像を共通理解を生み出し、価値あるアクションアイテムを即座に作り出すための優れたエクササイズです。メタレトロスペクティブは、1つまたは複数のプロダクトチームのメンバー（または、それらの代表者）とステークホルダーで構成されています。ステークホルダー側の参加者は、顧客だけでなく、ビジネスサイドもです。

メタレトロスペクティブについては、  The Meta-Retrospective — How To Get Customers and Stakeholders Onboard で詳しく解説しています。

2. 教育活動によるステークホルダーとのコミュニケーション

ダッシュボードでの情報の集計

「コンピューターに問題を入れる時は、回答を箱に隠しておきます。問題は見えるようにしなければならない！」（YOKOI, Hedeshi 米国ケンタッキー州エルランガー市にあるトヨタ生産システム支援センター元所長）

その精神で、すべての情報を透明にし、ステークホルダーが実際に理解できるように可視化します（アジャイルの文脈では、「情報ラジエーター」と呼ばれることが多いです）。

通常、チームごとにボードを用意するよりも、チーム全体の情報をステークホルダーダッシュボードのようなものに集約する方が便利です（例えば、サブタスクの動きを追跡することは、ステークホルダーにとっては通常、細かすぎます）。

メリットはたくさんあるでしょう。ステークホルダーがレポートを読むことはほとんどありませんが、ダッシュボードをみたいと思うはずです。そしてプロダクトオーナーやスクラムマスター、そしてエンジニアとの会話をしたくなるはずです。プラスの面として、制御された安全な環境になるということです。スクラムチームは、環境も選べます。ダッシュボードはステークホルダーの見えるところに置きましょう。

ただし、単純なバーンダウンチャートには注意が必要です。これらのチャートは、簡単な文脈から引き話されてしまい、一部のステークホルダーとの間でパブロフ的な反射を引き起こし、チームをマイクロマネジメントしたいという衝動に駆られる可能性があります。この件については、「Scrum: The Obsession with Commitment Matching Velocity.」を読んでみてください。

リリースノートを書く

リリースノートを書くことは、ステークホルダーとのコミュニケーションに本当に役に立ちます。しかし、「釣り針を餌にして、魚に餌を与える」ように、ステークホルダーは Jira のリンクをクリックするだけで、最近の成功について学ぶことができることを覚えておいてください。

ストーリーについては説明する必要があります。ストーリーには、ヒーロー（プロダクト、チーム、組織、・・・）、ヴィラン、障害物、そしてヒーローが障害物をどのように克服したのか、つまりストーリーアーク（※訳注: 一つの話をいくつかに分けて伝えること）があります。

リリースノートを正しく理解するために時間をかけることで、組織内のプロダクトとエンジニアリングの地位に好影響を与えることができます（噂によると読むでいても楽しいそうです）。詳しくは、「 5 excellent product release note examples and how to write your own」をご覧ください。

アンバサダーを任命する

各部門の責任者との協働のイニシアティブで、他部門の現場から関心をもっている個人を特定して、プロダクトとエンジニアリングの連絡役として育成していきます。アンバサダーは、フィードバックを収集したり、ユーザー機能の依頼を追跡したり、報告前にバグをチェックしたりします。

アンバサダーとは、定期的に（場合によっては毎週）会うようにします。アンバサダーは、優秀なスパーリングパートナーであり、彼ら自身の部門内であなたの代理人を務め、ユーザーテストの参加者としても重宝されるでしょう。

注意点は、消極的な人を避けてはいけないことです。ハックが逆効果となり、全体の考えと逆の結果になるかもしれないからです。

研修クラスを編成する

他の同僚たちを定期開催の研修クラスに招待して、現在のプロダクトの開発方法（リーンスタートアップ、ユーザーストーリーマッピング、バージョン管理、プロトタイピングなど）を実際に体験したもらいましょう。これらの研修には、コーディングは含めません。プロトタイプは、紙、クレヨン、鉛筆や InVision のようなプロトタイピングアプリで作ります。

マーケティング担当者、セールス担当者、カスタマー対応担当者と一緒に仕事をしたときに学んだことは、「 App Prototyping with Absolute Beginners」に書きました。

3. 定期的なミーティングによるステークホルダーとのコミュニケーション

「なんでも聞いて」（Ask-Me-Anything）セッション

アジャイルプラクティスに関する定期的な質問 (Ask-Me-Anything) セッションを、プロダクト開発組織外の同僚に向けて開催します。リーンコーヒー (Lean Coffee) は、構造化されていますが、アジェンダのないミーティングです。参加者が集まり、議題を作り、話を始めます。ミーティングの議題が民主的に作られるため、会話が促され、生産的になります。

メッセージを伝えるだけでなく、一般的なアプローチに関心のある人を見極めるために理想的な形式です。彼らは、あとの段階で貴重な見方になってくれるでしょう。

ステークホルダー部門での業務遂行

開発者、プロダクトマネージャー、プロダクトオーナー、スクラムマスターなど、誰もが、定期的な仕事をしています。例えば、カスタマー担当のようにです。ドッグフーティングをしながら顧客の作業に参加することほど、効果的に信頼関係を築くことができるものはありません。

短期間のうちに、プロダクトバックログや、ユーザーストーリーまたは、作業アイテムの作成、プロダクトバックログの並び替えの過程が、実施あの顧客の問題を解決するために、より連携するようになります。さらに、プロダクト開発組織全体が、匿名の集団から価値ある仲間へと成長していきます。

なぜでしょうか。それはステークホルダーの現場で仕事をしているからです。ユーザーストーリーやバグレポートは、もはや Jira の番号のついたチケットではなく、名前と顔とストーリーに関連づけられるのです。ステークホルダーは、あなたの経歴について知ることもできます。さらに、ステークホルダーにとっては些細に見えるものでも解決することが大きな技術的に頭痛の原因になる理由についても学ぶことができるでしょう。

ここでは、ポートフォリオ管理、プロダクトロードマップ計画、ユーザーストーリーマッピングなどのステークホルダーレベルでの定期開催するミーティングについては言及していません。これらは今回の記事のスコープの範囲を超えています。

4. メディアチャネル

デイリーニュースレター

あなたの会社や業界に関連する最も重要なニュースのうち、5〜6件を取り上げるユースレターを毎日発行します。スタートアップやテクノロジーに関連した記事をいくつか投げ込みましょう。例えば、「Elon Musk’s part 2 of his manifesto 」は、この条件をみたいているでしょう。または、会社のブログです。

これを本物のニュースレターとして扱い、多くのメールサービスプロバイダーが提供している無料プランを利用しましょう。時間の経過とともにニュースレターを最適化するには、分析機能が必要になります（そのために、人気リンクのクリック率をチェックしたり、別の見出しをつけたりします）。言い換えれば、同僚たちの役に立つということです。

開封率が40％を超える傾向があり、CxO レベルがニュースレターを積極的に呼んでいるという言葉が広まれば、さらに高くなる可能性があります。興味深いリンクを提供してくれる人が増え、ニュースレターに貢献者を記載するようにしましょう。場合によっては、運が良く有益なリンクを提供するために個人間で友好的な競い合いが始まることもあります。私の経験では、この取り組みには1日30分以上は必要ないでしょう。

副作用: 広報部門が混乱するかもしれません。組織文化によっては抵抗にあうかもしれません。

プロダクト＆エンジニアリングブログ

ステークホルダーとのコミュニケーションを改善するために、日々の仕事についてブログで発信を始めましょう。テクノロジー、プロセス、方法論、フレームワーク、つまりは高品質なプロダクトを日々どのようにリリースできるように運営しているのかを発信するのです。詳細なブログ記事へリンクすることができれば、上述したコミュケーション戦略にも大きく貢献できます。

Zalando’s tech blog がよい例になります。プロダクト＆エンジニアリングブログは、定期的なイベントを開催することで、オンラインから採用を希望する志を同じくする人たちとの対面のコミュニケーションまでの溝を埋めるような素晴らしい採用戦略の基盤にもなります。

まとめ

アジャイルへの移行を社内のステークホルダーに正しく伝えることに失敗すると、「アジャイル」は単なるローカルプロセス（おそらくは一時的な流行りのプロセス）とみなされることになってしまいます。なせなら、組織の大半がサイロとコマンド＆コントロール構造に留まっているためです。

その状態になると、アジャイルやリーンのプラクティスを支持しない人たちにとっては、今後のアジャイルによる改善の取り組みに抵抗することになってしまいます。「過去に取り組みましたが、私たちの組織では機能しませんでした」という旗を振り回されてしまいます。詳しくは、「Why Agile Turns into Micromanagement」をご覧ください。

適切なステークホルダーとのコミュニケーションを効力することがアジャイルへの移行で最初に取り組むべき理由がここにあるのです。

社内のステークホルダーの支持をどのように得ていますか？ぜひコメントで教えてください。

 “Hands-on Agile” Slack team にぜひ参加してください。無料です。

関連記事:

• Agile Failure Patterns In Organizations
• Why Engineers Despise Agile
• How to Kick-off Your Agile Transition (Part 1)