【GYOMUハックアドベントカレンダー】ステークホルダーとのコミュニケーションを円滑にするには？
こんにちは、きゃらめるです。
こちらは「GYOMUハック/業務ハック Advent Calendar 2020」の5日目の記事です！
今回のブログでは、GYOMUハッカーの皆様が業務で遭遇する「ステークホルダーへの説明やヒアリングが必要な状況」において、円滑に進めるための準備をまとめていけたらと思います。
今回の記事では、以下の3つのプロセスについて、どのように検討していけばいいかをまとめてみました！
- 相手を決める
- 順番を決める
- シナリオを決める
私は前職で社内Salesforceの担当者をしていました。そのためSalesforceに修正を加えることが多々あったのですが、Salesforceを使っている部署は社内全体に存在するため、修正によって複数の部署に影響が出てしまうことがあります。
特に修正内容が大きければ大きいほど、ステークホルダーに対して丁寧に説明やヒアリングをしていく必要が出てきます。
前職で最後に携わったプロジェクトでは、変更内容も影響範囲も大きかったのですが、チーム全体でこの部分に力を注いだことで、なんとか成功で終えることができました。
GYOMUハックは、社内の方に協力してもらって、運用に乗ってこそ力を発揮します。だからこそ、ステークホルダーと直接話ができる場で信頼値を上げておくことが大事です。この信頼値とは、「自分たちのことを気にかけてもらえている」という安心感とも言えます。
業務改善をするとき、「現状を変えてくれないこと」の不満よりも、「現状上手くいっていたもの勝手に変えられたこと」の不満の方が反発されやすい上に、信頼を失います。
正しい相手に・正しい順番で・正しいメッセージを伝えることで信頼値を上げれば、円滑に改善を進められると思っています。
相手を決める
まずは、そもそも誰がステークホルダーなのかを洗い出すことから始めるかと思います。
必要な相手に修正が伝わっておらず、業務に支障が出るようなことがあれば、リリース内容を戻すことになってしまう可能性があります。
それだけではなく、相手に不快な思いや心配を与えてしまうため、関係が悪くなる危険性もあります。
特に大きいプロジェクトであればあるほど、慎重に行きたい部分だなと思います。
普段の会話に着目しておく
普段から、社内の様々な業務に携わって話を聞いておくと、修正をした時にどこに影響があるのかがなんとなく分かってきます。
直近の業務に関係なくても、多くの部署とやり取りをして、どんな業務をしているのかを耳に入れておくだけでも、影響範囲を洗い出すときの取っ掛かりになります。
既知の影響部署の人を頼る
とはいえ、すべての部署のすべての業務を把握するのは無理な話だと思っています。
そんなときは、既に影響の範囲内だと分かっている部署や人を頼るのがひとつの手です。
影響範囲の部署・人に、「ほかにこの機能を使っている部署や人を知っていますか？」もしくは「この機能を修正されて、影響が出る部署や人を知っていますか？」というような質問をすることで教えてもらえることがあります。
もし、依頼部署が存在する場合はラッキーで、その部署から他に影響のある部署を洗い出せる可能性があります。
依頼部署は改修によって恩恵を受ける部署でもあるので、影響範囲を洗い出すことの重要性を説明するこでで、協力的に動いてもらえる可能性が高いです。
なんなら、影響範囲の洗い出し～リリース後の説明についても巻き取ってくださる部署もありました。聞いてみて損はないはずです。
マネージャー層を頼る
一度マネージャー層に状況を伝え、自分の部下に修正箇所を使っているかを聞いてみてもらいます。
ここでの注意点は、マネージャーの方に動いてもらうため、小さな改修であれば割に合わない可能性があるということです。
全体に聞いてみる
最終手段です。全体への確認は、経験上あまり聞いてもらえないことが多いです…。ただ、一度全体に聞いておくことで「確認した」という証拠は残すことができるので、少しだけ自分の身を守ることができます笑
ここで忘れてはいけないと思うのは、こちらが想定していないようなイレギュラーな使い方をしている人の存在です。
想定していない方法で運用が回ってしまっている場合もあり、思ってもいないところから問い合わせがくることがあります；
重要なリリースであればあるほど、できる限り広い範囲に変更を伝えておく必要があるかと思います。
順番を決める
誰に伝えるべきかが決まったら、伝える順番を決めます。言ってしまえば、誰に先に話を通しておけば円滑に話が進むのか？を考えます。
誰を部署の代表とするべきか？
部署単位で何かを伝達する時には、その部署の実質的に一番影響力の高い人を対象にします。これは部署の組織図上のトップでなくてもいいということです。組織図上のトップからの信頼もあり、部下を引っ張ることができる中間層の方には、先に話をつけておいて味方になってもらう方がよかったりします。。
一方でヒアリングの場合は、実際に作業している人に話を聞くことになるかと思います。ただし、後からヒアリングの内容を元にほかの人を説得するため、組織的に説得力のある人を選ぶ or 同席させて一緒に意見を聞くとスムーズかと思います。
部署を跨いだ場合の伝達順番
ヒアリングではなく、説得や説明が必要な場合には、ぜひ伝える順番を考えてみてください。
私はこの順番を考える時、以下の二つに分けて考えています。
- 自分から伝えるべき人か
- 自分の味方になってくれる人（修正によってプラスの影響を受ける人）
- 面倒見がよく、決定権がある人（↑と合わさればなおよし）
- 上層部の決定後に伝えるべき人か
- 反対・難色・不安点があるというマイナスの感情を抱く可能性がある人
- 決定権・決定力がない人
上層部の決定後に伝えるべき人の中でも、なるべく早くに伝えるべき人がいます。それが、修正に一番反対しそうな人です。
反対意見を聞かずに味方ばかりつけても、どこかの部署に大きく反対された場合には後戻りする必要が出てくることがあります。
「会社の上層部が賛成している」という虎の威を借りつつも、なにが反対要因なのかをなるべく早めに洗い出して不安を潰しておく必要があります。
理想の形としては、
１．組織的に説得力があり、一緒に推進してくれる人を味方につける
２．１．の賛成を得られていることを伝えつつ、反対しそうな人の話を聞く＆説得する
３．ほかの人からの同意も得つつ、トップダウンで周知する
組織の性質にも依るかもしれませんが、正規のレポートラインを通る方が遠回りになることもあるので、何か変化を起こしたい時には一度伝える順序も考えてみてください！
※ちなみに、この順番の意識は、プロジェクトのような大きなものでなくても便利に使えます。自分の直属の上司より先に、別の人に話を伝えて了承を得てからの方が、説得力が増して、余計な諍いをなくすこともあります。
シナリオを考える
最後に、どんな伝え方で話をすべきかについてです。
事前ヒアリング
事前ヒアリングをする目標・目的は、現在の運用や業務フローを知ることで「改善に生かすため」「懸念点を最初に洗い出しておくため」という理由があります。
ここで大事なのは、「私たちは味方である」というメッセージをしっかり伝えることです。
事前ヒアリングをする相手が、修正で不利益が発生する場合には、
- なぜこの修正を行う必要があるのか（修正のメリット）
- なるべく不利益を与えないようにしたいので、改善案を考えたい
という視点で話をします。
修正で不利益が発生しない場合は、
- 修正のメリット
- 私たちが知らない運用があると予定外の不利益が発生する可能性があるので、現状の運用を教えて欲しい
という視点で話をすると、後からの問題発生も少なくなります。
意見を通したい場合
決まったことを伝達したい場合など、ヒアリングというよりはこちらの意見に同意してもらうことを目的とする場合は、相手の不安を減らしつつ、自分の身も守ります。
具体的には、通したい内容のメリットを全面的に伝えつつ、やることとやらないことを明確にします。
特に、アフターケアの部分や想定外の不具合があった場合の修正についても触れておくと相手の不安は少し軽減されます。
ただこの時に、すべての不具合を修正することはできない可能性があることを伝え、同意してもらった方がいいと思います。
おわりに
今年の私の一大トピックが転職でした。1年の締めくくりとなるアドベントカレンダーで、前職の振り返りとしてこの記事を残せてよかったです。
アドベントカレンダーへのお誘いありがとうございました！！！
現職での私は、業務改善という動きは全くとれていません。。来年は現職でもアドベントカレンダーのネタになるような業務改善ができたらいいなぁ…。
来年も頑張ります！
