複数人から合意をとって進めていくこと


概要

いわゆるコンセンサスの取り方についてまとめました。
仕事は、重要なことを進めていけばいくほど「複数人から合意をとって進めていくこと」が必要になります。
「誰に何の確認が必要か見極めること」「合意をとっていくこと」両方が重要です。
開発プロセスの話や、組織によって異なることもありますが、一例として、チームごとにどのようなことを考えているか確認するべきかも書きました。

合意が必要なこととは?

「もっと早く知りたかったこと」です。
例えば、あるプロダクトのKPIが減った、お客さんからこんな意見があった、お客さんに別のことを伝えていた、こんな機能を開発していくことを知らなかった場合に、もっと早く知りたかったとなります。
明確でないのは、確認したけど、後で十分に知らなかったとなることや、issue上やメールでは伝えたけど伝わってなかったことなどあり、極論相手の重要視しているポイントが異なるという意味で流動的です。
一方で、全てのことを伝えても伝わらなく、確認すべきでないことを確認すべきでない人に伝えることもよくありません。
確認すべきことを、確認すべき人に最小限の情報で伝え、合意を取るテクニックを身につけることが、合意形成で重要です。

コミュニケーションは双方の問題

伝えたけど、伝わってないことは双方の問題になります。
リーダーになっていく上で、双方の問題でも自分ごととして考えていくことが重要です。
また、自分が任されたプロジェクトで、合意が取れてなかった場合は、自分の責任が大きいと思って、丁寧に進めることが大切です。

コミュニケーションのタイミング

いつ確認するのかも重要になります。プロジェクトが進んで確認すると無駄になることもあります

開発は、
アイデア -> 企画 -> デザイン -> プロトタイピング(動く) -> 開発デモ(動く) -> 本番リリース前(デザイン反映) -> 本番(パフォーマンス反映)
と、色々な段階で確認することができます。
もちろん早い段階で確認する方がよいが、早いから伝わらないこともあるし、リリースをしないと伝わらないこともあります。
プロジェクトのリスクはどこか把握した上でいつ何を確認するか確認する計画を立てる必要があります。

また、例えば人を増やさないと対応できないことはすぐにはできません。
どこかのチームの工数がかかることについては、早い段階で確認することが重要です。リソースがないために進まないといわれるとプロジェクト自体が止まるからです。

コミュニケーションの方法

コミュニケーションの方法は以下のように8つに分かれています。

  • 1on1で直接会って話す
    • 説得でも議論でもヒアリングでも使いやすい
  • 関係者で直接会って話す
    • 基本的にはいきなりゼロだと無駄になる可能性があるので、事前に何人か同意をとる
    • 関係者同士で意見が必要な場合に使う
    • 1on1よりも多くの人の時間を奪うので、準備をする
  • 電話で話す
  • ダイレクトメッセージで話す
    • 議論が長引かないことに使う
  • 共通のルームでメンションして伝える(同期)
    • 同期的に確認できる
    • 議論が必要な場合は使わない
    • 基本的には多用しない!
  • issueでメンションして伝える(非同期)
    • 非同期で同意が取れる
    • 議論がまとまらない場合は手段を変えることも重要
    • 一番よく使う!
  • 共通のルームで伝える(同期)
    • ルームにいる人に見られる可能性が高い
    • ある程度多い人に伝われば良いこと
    • 議論が必要な場合は使わない
    • 特定の人に確認が必要なことには使わない
    • 例えば、リリースを共有すること
  • issueに書く
    • 決まったタグがあり、気になったら、見ることができる

伝えることの、重要性や緊急性に加えて、伝える人の受け取りやすさによっても使い分けることが重要です。

重要性の高いものは、確認したことを文字で残す必要があります。
例えば、直接会ったり電話で話したあと、議事録を残すことや、issueに確認項目を明示的に書いてチェックすることです。

議論がスムーズに進むのかどうかも重要です。
集まって話す方が良いか、グループのチャットルームで話す方が良いか、1on1が良いか関係者で集まるのが良いかなど議題によって変わります。合意を取ることに加えて、プロセスが短いかも重要です。1週間以上issueで議論していて遅いとしたら、それは集まって速く合意を取れたかもしれません。
集まって話す場合も、何人かは知っていて同意が取れているのか、集まった全員同意が取れていないかでも合意の取りやすさは変わります。
議論を進める上での方法はこちらも参考になります。 https://qiita.com/reikubonaga/items/f51d03b6455c1f6e45ab

緊急性が高いことは、近くにいる場合は直接伝える、ダイレクトメッセージで伝えることが必要です。

非同期でコミュニケーションすることについては、こちらを確認ください。 https://qiita.com/awakia/items/c571e93e96a1ec28044f

各チームが考えていること

普段何に責任を持っているか、後で何か言われるとしたら何か理解しましょう。
自分の関心ごとに近いことに影響があることは聞きたいし、伝えるべきことになります。
組織によって確認するべきことやチームは異なりますが、例えば以下のように考えていきます。

  • 経営
    • 事業計画の数字に影響がないか
    • 会社のブランディングに影響がないか
    • 長期の戦略に矛盾しないか
    • => 大きな事業上の問題が発生してびっくり
  • プロダクトマネージャー
    • プロダクトKPIにどう影響があるか
    • 想定以上に工数がかからないか
    • => このKPIが落ちたし早めに言って欲しかった
    • => この機能は開発する必要なかったのに
  • デザイナー
    • ブランディングにあったデザインか
    • 納得できるクオリティが担保できているか
    • => このクオリティでリリースはないよ
  • リードエンジニア
    • 納得できるコードクオリティか
    • 技術選定が正しいか
    • => このコードは後で書き直しが必要で大変
  • インフラエンジニア
    • サーバーへの負荷、ジョブの数、新しい高負荷スケジューラー
    • (安定性は問題ないか。基本は安定して出すので関係ないが)
    • => 夜にアラートがなって起こされた。早めに知って対応したかった
    • 問題が起きている時に対応していること
    • => 調べていたことを知らなかった。一緒に調べたかった
  • セールス
    • お客さんは困らないか
    • 普段説明していることと変わらないか、資料の作り直しは発生しないか
    • => お客さんに説明していることと、実際のことが違って信頼を失った
    • 利用しているツール(Salesforce, domo)に影響がないか
    • SaaSのセールスチームだと以下の3つに分かれている
    • インサイドセールス = 新規のクライアント・新規有料会社数
    • クライアントサクセス = 既存のクライアント・継続率
    • アカウントセールス = たくさんお金払っているクライアント・1企業辺りの単価
    • => それぞれのクライアントに影響がないか
  • マーケティング
    • 広告(メールとか通知)や広告の成果に影響はないか
    • KPIのボードに影響がないか
    • 利用しているツール(Karte, Marketo, domo)に影響がないか
    • => 見ていた数字が違った。広告お金かけてたのに無駄になった
  • カスタマーサポート
    • 問い合わせは増えないか
    • 問い合わせに答えらるか、答えていたことは変わっていないか
    • => いきなり問い合わせが来たが、何が起きたか分からなかった
  • オペレーション/経理
    • 請求や請求関係の連絡が問題ないか
    • 普段のオペレーションに変更がないか
    • => いきなり新しいプランが増えて対応の準備ができてなかった
  • 海外チーム
    • 日本語が出ていないか
    • => 日本語のメールが届いた!!
    • 売り上げに影響する開発に取り組めているか
    • 要望が取り入れられているか
  • 法務
    • プライバシーポリシー・利用規約に影響はないか
    • 個人情報の扱い方に問題がないか
    • => 早めに確認できていれば規約に盛り込めたのに
    • => 炎上して対応は嫌だ

各チームから共通した開発への要求

  • 売り上げが大変なのに開発で売り上げに繋がらない、効率化が進んでない
  • マーケティングが大変なのに開発で効率化が進んでない
  • 海外事業が大変なのに開発で効率化が進んでない
  • オペレーションが大変なのに開発で効率化が進んでない
  • カスタマーサポートが大変なのに開発で効率化が進んでない

効率化や商品開発など、開発チームのリソースに対して要求は増えがちです。
「リソースをうまく使っていることを伝える」ことは非常に難しいことです。
開発の場合、常に、本当はこんなことをして欲しいのに、これができてないと思われていることは多いです。
チームを見ていく立場になると、他のチームの要求に対して「優先度を決めて進めている」ことや、「要求の具現化の仕方/要望のissueの作り方」など伝えなど、「他のチームが合意形成が取りやすい地盤を作る」ことも大切です。

各チームからの意見を吸い上げる時にオススメの方法

  • 定期的に関係者と1on1
    • ヒアリングしないと聞き出せない要望もあります
    • 定期的にコミュニケーションが必要なチームとは、定期的にコミュニケーションを取るとスムーズに進みます。
  • 定期的にアンケートを取ること
    • 人によって情報の取り方は変わるので、「自分のチームは透明性がある」と思っているか聞く、定期的に聞くことで改善を進めていけます。
    • また、聞くことで、自分のチームが意識をしていることを伝えることができます。

関連