「はい」を求めるのではなく、「いいえ」を求めよ（2022）
(mooreds.com)- 小さな会社で自分の業務範囲内の仕事を進めるときは、許可を待つよりも 断る機会と期限 を与えるやり方のほうが、実行速度を高められる場合がある
- 「action Xを導入してもよいですか？」のような 承認依頼 は、上司に問題の検討、解決方法の判断、優先順位の調整まで委ねてしまい、返答が遅れることがある
- 「月曜日にaction Xを導入します。異論があれば知らせてください」と伝えれば、実行の意思を示しつつ、上司が介入する余地も残せる
- この方法は、仕事が自分の 役割範囲内 にあり、フィードバックは歓迎しつつも、返答がなくても進められるだけの確信があるときに適している
- 近い期限をあわせて示すと、必要な人がより早く反応する可能性が高まり、実行を止めずに関係者へ知らせ続けられる
許可を待たず、断る機会を与える
- ごく小さな一歩でも前に進む 実行バイアス は、停滞状態を打破する助けになる
- 核心となる習慣は、「はい」を求めず 「いいえ」を求める こと
- 経験のベースは従業員200人未満の小さな会社である
- 大企業、非営利組織、政府組織でも同じやり方が通用するかは確実ではない
- 自分の業務範囲内だと感じることを進めたいが、安心感がほしい、あるいは上司に知らせたいとき、通常はまず許可を求めがちである
- その代わりに、上司へ 断る機会 を与え、その判断ができる 明確な期限 もあわせて示す
GitHub Actionの例で見る違い
- 例は、ソフトウェア品質の改善に役立つと判断した新しい GitHub Action をリポジトリに導入する場面である
- 単なる思いつきではなく、調査とローカルテストを経た状態である
- 以前の同僚に、そのGitHub Actionの使用経験を尋ねているかもしれない
- 「action Xを導入してもよいですか？ 私たちが抱えるXYZ問題の解決に役立ちます」と尋ねるやり方は、上司が「はい」と言う前に追加の作業を発生させる
- XYZ問題をあらためて検討しなければならない
- Xがその問題をどう解決するか判断しなければならない
- 他の業務との優先順位を見たり、担当者が知っている内容を先に共有したいと思うかもしれない
- 忙しい上司のもとではこの件が後回しになり、何度もリマインドが必要になることがある
- 代案は、「XYZ問題を解決するaction Xを導入します。別の考えがあれば知らせてください。そうでなければ月曜日に対応します」と伝えるやり方である
- 担当者自身が問題を直接処理するというシグナルになる
- 上司は望めば介入できるが、必ず返答しなければならない負担は軽くなる
- 上司が忘れたり別の仕事が入ったりしても、進行は止まらない
- この方法は個人だけでなく、複数人で構成されるグループ にも適用できる
期限が生む応答圧力
- 期限はこのアプローチの重要な要素である
- 1月15日時点では、「task Xをやります」より「1月17日にtask Xをやります」のほうが、より早い反応を促せることがある
- 「2月15日にtask Xをやります」のような遠い期限より、近い将来の期限のほうが、より即時の応答を引き出せる可能性が高い
- フィードバックの機会は開いたままにしつつ、フィードバックがなくても実行できるだけの確信があるときに最も適している
1件のコメント
Hacker Newsのコメント
誰もが忙しく、仕事が埋もれがちな大企業では、これは中核的な能力です。
メールで問題を説明したうえで、「[N]日以内に返信がなければ、[N日目の日付]にXYZを実行します」と書きます。承認を求めて無力に待ったり催促したりする代わりに、何もしなければXYZが進むという通知を残すやり方です。
ときどき数週間後に、なぜ黙ってやったのかと怒る人が出てきますが、そのたびに相手が見落とした記録を見せられます。
「こういう理由でXYZをしようと考えており、[日付]に進めます。反対や懸念があれば知らせてください」のように言えば十分です。
この方法は、事前にしっかりした根拠を提示することを促し、自分が知らない制約やミスを避けるためのフィードバックも受け取れるようにします。
Amazonのリーダーシップ原則を問題の解決策のようになぞるカーゴカルト的な行動も奇妙です。「行動への偏り」がAmazonで通用するのは、独断で動いて失敗した人はスケープゴートにされて解雇され、そういう人たちは行動への偏りの美徳をブログに書かないからです。
「3月1日にthingamajigをデフラグする予定です。この作業が問題を引き起こす可能性のある方々に事前に連絡しています。懸念があれば知らせてください。3月1日までに返信がなければ、thingamajigはデフラグされます」といった感じでしょうか。
「5日以内に返信がなければXをする」という言葉は、懲戒処分を受け得ることをした場合には何の防御にもなりません。
通用するとしても、せいぜいビジネスと関係のない内部設計上の決定を破る程度です。
こういうことを「いつもやっている」と言いながら、魔法の文句をテンプレートのように書くのが本当に本人の経験なのか、それとも本文のように働きたいという投影なのか疑わしくなります。
怒った同僚たちに記録を見せて勝つ場面を思い浮かべると、でたらめ検知器が赤まで振り切れます。
これを「尋ねずに知らせろ」と呼んでいて、社内外でとても役に立ちます。
基本的なコミュニケーション技術であり、結果を簡潔かつ決定的にしてくれます。
妻ともこうした会話をよくします。妻は「何時に着く？」のようなオープンな質問を8人のグループチャットに投げるタイプです。私たちは子どもを預ける予定のために1時間早く着くことが分かっていたので、単に「私たちはこの時間に着くので、先に飲みたい人はバーにいます」と知らせればいいと言いました。
返信を求める必要もなく、皆が早めに来て、最小限のやり取りでうまくいきました。
「許可を求めるより許しを請え」とも少し関係しますが、GitHubリポジトリのように複数人が協働する場所で、他人に影響する大きな変更をいきなり投げ込むのには向いていません。
他人に調整してもらわなければ楽しめない状態ではなく、自分がやりたいことを始め、他の人には合流できると知らせるやり方です。
同僚から自分の提案を承認してもらう方法を聞かれると、似たような助言をします。「相手がイエスと言いやすいように、できるだけ整えろ」と。
誰かに14段落を投げつけておいて、自分が何時間も問題を掘り下げた水準にすぐ追いつくことを期待してはいけません。
自分のアプローチに自信があるなら、問題と解決策がなぜ妥当なのかを簡潔に説明し、もっと深く見たい人向けに文書へのリンクを付ければよいのです。チームメンバーやプロダクト責任者からは、すでに同意を得ておくのが望ましいです。
例: 「XをYで解決しようとしています。チーム全員が同意しています。詳しい提案書は[link]にあります。追加で扱うべきフィードバックがなければ、火曜日に開始します」
マネージャーはすべての細部を見る時間がなく、広いチームからの支持まで含めて仕事を整理しておけば、承認するだけでよいので感謝されます。
成功確率が10%でも試す理由があるならそう言いますし、成功すると確信しているかのようなくだらない発表で包み隠したりはしません。成功確率が80%なら20%も隠しませんし、98%と言うなら実際にその程度に近いという意味です。
マネージャーの仕事は、こうした統計を扱い、リスクをヘッジすることです。ヘッジファンドはお金で行い、マネージャーは人とリソースで行います。
残念ながら典型的な企業のマネージャーは、成功すると100%言っておきながら実際には50%失敗する人のほうを好みます。
似た表現として、意図を放射する（radiating intent） が気に入っています。
何をいつやろうとしているのかを広く知らせ、利害関係者が明示的に反対できる余地を与える一方で、合意・足並み合わせ・承認を一つひとつ追いかけないやり方です。
一部の状況ではうまく機能し、たいていは先に基本的な信頼を得ておく必要があります。
https://medium.com/@ElizAyer/dont-ask-forgiveness-radiate-in...
Eliz Ayerが付け加えたニュアンスも良かったです。「公平に言えば、意図の放射ではこなせる仕事が少なくなることもある。邪魔したり口を出したりする人に割り込む経路を与えるからだ。また、こうした助言は状況と組織に大きく依存するため、常に適切とは限らない」
こうしたコミュニケーションの取り方は、相手を即座に危険人物として見てしまわせると思う。
表面的には時間を節約してあげているように見えるが、実際には、マネージャーがその社員が何をしているのか常に気にかけていなければ、望ましくない行動を取る可能性があると伝えるやり方である。
本文ではこれを通知のように扱っているが、どれほど善意と理解があっても、通知はシグナルのノイズに埋もれやすく、返事がないことは同意を意味しない。メッセージを受け取っていないという意味かもしれない。
すでに社員とマネージャーが問題について議論しており、あとは解決策を実行する状況なら問題ないかもしれないが、相手がまだ考えたこともない問題を初めて持ち出すときには最悪だ。利己的で、チームワークの正反対である。
伝説的な10x Rockstarエンジニアがこうしているのを見て真似しているようにも感じる。そのエンジニアは常に成果を出し、何をすべきかを分かっており、管理層との相互理解と尊重があるため、自律的な管理を任せる余地がある人だ。それを見た誰かが、なぜそのように扱われているのか、自分はどうすればそれを得られるのかを理解しないまま、自分にも適用されると思い込んだように見える。
3回連続でこうして「やめてほしい」という返事を受けたなら、何かがずれている。3回連続で称賛されたなら、続ければよい。
本当に危険な人は、ダメだと言われても大半をどうにか実行してしまい、あとからイエスを探す人だ。次の仕事でも同じやり方をし、フィードバックに反応しない。
だから核心は、やり方そのものよりも業務上の関係性である。信頼が高く、全員が忙しい環境では試す価値がある。
一緒に働いたことがあり、信頼があり、こちらの時間を尊重してそうしているのだと分かっているなら、まったく別の話である。
初めて何かを壊した瞬間に、これは災厄のレシピになる。
イエスまたはノーを受け取ったということは、上司が把握していたという意味である。問題が起きて「誰が承認したのか？」と問われたとき、正直な答えは、誰も承認していない、ということになる。
組織内にこのように行動できる人が誰もいないなら、リーダーシップチームが委任に失敗している兆候である。
たとえばYチームのXが何かに反対しているような場合である。
上司が1) 何かをすべきだと言い、2) どの計画も承認しないなら、単にやらなければよい。その場合、物事が進むよう指示する責任は上司にある。
「これをやります」と言うのは構わないが、レビューや自動テストのような手順なしに本番環境へ出てはいけない。
もちろん、そうするとボトルネックが生じる。マージリクエストを出しても誰も適時にレビューしなければ、何も起こらない。こういうときは、一定時間内に確認してレビューするという合意をチームリードのレベルで決める必要がある。
このアプローチは、アメリカ企業やアメリカ式のビジネス文化に慣れた上司に対してだけ通用するように思う。
上司が嫌がれば大きく逆効果になり得る。人事評価のときに上司が不服従だとレッテルを貼りやすくなり、必要な証拠を自分からお盆に載せて差し出したようなものになる。
ときにはアメリカでも許可を求めるのが本当に最善であり、リソースに関わることならなおさらだ。
たとえばスカンジナビア文化圏では、管理はかなり手を離し、社員が多くの意思決定を独立して、あるいは互いに相談して行うことを期待する場合が多い。
ただし、その上司たちは全員、アメリカ文化に深く浸っていた。
効果的な軍事的意思決定でさえ、現場部隊が毎回本部に電話せずに適応できるべきだという点に大きく依存している。
これは合理的なデフォルトを作ることと呼ばれる。
あらゆる細部について人々に決定を求める代わりに、状況を理解していることを示す合理的なデフォルトのまとまりを定め、そのまま進めると知らせるやり方である。
こうすると信頼が積み上がり、本当に注意が必要なときに人々がよりよく見てくれる。普段は時間を無駄にしない人だと分かっているからである。
このコミュニケーション方法は良いが、期限の部分はいまひとつだ。
部下が、私が拒否権を行使する可能性のあることをしているなら、知らせてくれればよい。私のほうがより多くの文脈を知っていて、それが時間の無駄だったり優先事項ではなかったりすると判断できるかもしれないからだ。
マネージャーに期限を与えるのは奇妙で、どこか苛立たしい脅しのように聞こえる。
GitHub Actionのような些細なことは、チームメンバーが自分で決められるだけの十分な自律性を与えたと思いたい。
しかし「この日にやります。ほかに何もなければ」を付け加えると、少し攻撃的に感じる。
作業時期だけに触れて「その頃には終わらせるつもりです」程度に留めても、進めないほうがよいと判断できる余地を与えられる。
それでも、以前からもっと断固とした態度を取ることが目標だった。縮こまるだけでは限界がある。
1日あれば十分だと思って進めたのに、相手が2日後に返信したら、すでに指示に反することをした状態になる。
日付を入れれば避けられる。「水曜日（26日）にビルドシステムを移行します。懸念があれば知らせてください」
例を読んでようやく理解したが、実際には期限ではなく作業予定日に近い。
相手に通知期間を知らせ、古いメールをあとから読む人が今も関連があるのか判断できるようにするからだ。
通常、期限は「すでにやると決めており、承認や合意も得ているので、あとは実行する事実を知らせる」という意味で使われる。
「別途指示がなければこれをやります」というテクニックの一部は、質問のように表現しないことでコミュニケーションコストを下げる点にある
そうすれば、受け手は返信を書く必要がなくなり、私やCCされた人たちも追加のメールを読まずに済む
その意味で、GitHubやGoogle Docsの絵文字リアクションのように、読んで同意した印として親指を押せる機能は良い。HNの一部ではなぜか人気がないが、毎回「いいですね、筋が通っています！」のようなコメントを書く手順を踏まずに済む、軽いコミュニケーション手段だ。アップボートに似ている