Noを求めよ、Yesを求めるな（2022）

[GN⁺]

Hacker Newsの意見

• 大企業では重要なスキル。みんな忙しく、仕事が忘れられやすい状況で役に立つ。メールで問題を説明し、「もし [N] 日以内に返答がなければ、[DAY N] に XYZ を実行します」と伝える。これは承認を待たず、相手に通知するやり方
  • ときどき数週間後に誰かが XYZ を実行したことに腹を立てるが、それが相手のミスだったことを示す記録が残っている
  • これを「尋ねるな、伝えろ」と呼んでいて、職場の内外でさまざまな用途に使える。明確で決定的な結果を導ける
  • 妻ともよくこういう会話をする。妻は質問するスタイル。夕食会で妻は「何時に到着しますか？」と尋ねたが、私は私たちがいつ到着するかを伝え、バーで待つつもりだと言った。結果として全員が早めに到着し、最小限のやり取りで完璧だった
  • 「許可を求めるな、後で許しを請え」という考え方に関連している。危険なこともあるが、自分は本質的に反抗的。ただし GitHub のような協業環境では、大きな変更を無謀に試すのはよくない
• 同僚に推薦承認を得る方法について助言するとき、似たようなことを言う
  • 「承認しやすいようにしろ」
  • 問題を簡潔に説明し、その解決策がなぜ正しいのかを説明する。もっと詳しく知りたいなら文書へのリンクを添える。すでにチームメンバーやプロダクトオーナーの承認を得ているかを確認する
  • 「私たちは X を解決するために Y を行います。チームは全員同意しています。詳細は [リンク] にあります。追加のフィードバックが必要なければ、火曜日に開始します」
  • 管理者はすべての詳細に時間を割けないので、チームの支持を得ていれば承認しやすくなる
• 「意図を放射する」というアプローチもある。やろうとしていることと計画を知らせ、利害関係者に明示的に反対する機会を与える。一部の状況では機能し、基本的な信頼が必要
• 初めて何かを壊したときには大惨事になりうる。イエスかノーをもらうことは、上司がそれを把握していることを意味する
  • 「誰が承認したのですか？」という問いに、誰も承認していないと答えることになる
• このアプローチは、アメリカ企業やアメリカ式ビジネスに慣れた上司にしか通用しないかもしれない。上司が好まなければ逆効果になりうる。評価で上司が不服従の烙印を押すこともある。ときには許可を求めるのが最善の場合もある
• 「私はこれをやります」というトリックの一部は、質問の形で表現しないこと。そうすれば受信者は返信を書く必要がなく、追加のメールを読む必要もない
  • GitHub や Google Docs の絵文字リアクション機能が好き。簡単な方法で同意を示せる。HN では人気がないが、絵文字リアクションはシンプルなコミュニケーション手段
• OP の立場は理解できるが、許しを優先するかどうかは状況次第。ソーシャルネットワーキングのウェブサイトでは素早く動いてミスもできるが、核発射制御システムでは「許可されるまで発射しない」仕組みが必要
  • 大規模な共同プロジェクトでこの手法を使っている。「合意に達しなければデフォルトの選択に従います」と伝える。若いころはひどいデフォルト値が必要だと思っていたが、これは数回しか機能しない
• これを「合理的なデフォルトを作ること」と呼んでいる。細部ごとに判断を求める代わりに、状況理解を示すデフォルトを選び、それを実行すると知らせる。これは信頼を築き、本当に必要なときに注意を向けてもらえるようにする
• このコミュニケーションスタイルは好きだが、「締め切り」の部分は好まない。報告では、自分が反対できる作業を相手が進めていると分かるようにしてほしい。管理者に締め切りを与えるのは奇妙で、煩わしい脅しのように感じる。チームメンバーには自律性を持ってほしい