本文へ
ハクソク

世界を動かす技術を、日本語で。

詳細は必要ありません。

元記事: 原文(michaelheap.com)

概要

  • SVPが「詳細は不要」と発言した背景 の解説
  • 組織での失敗対応の本質 にフォーカス
  • 「なぜ起きたか」より「何を変えるか」 の重要性
  • 人ではなくシステムの改善 を重視
  • 信頼と変化への姿勢 の提案

「詳細は不要」—SVPの真意とその学び

  • 数ヶ月前、 エンジニアリングSVPとの会議 に呼ばれる事態発生
  • 重大ではないが 重要な問題 が発生し、説明を始めたところで「 詳細は不要」と遮られる
  • SVPは「 詳細を聞けば納得できる理由があるのは分かっている。だが、それではまた同じことが起きる」と発言
  • 詳細を求めない態度 は軽視ではなく、「 あなたたちを信頼している。次に何を変えるのか話そう」というメッセージ

問いの転換—「なぜ?」ではなく「何を変える?」

  • 多くの組織は問題発生時に「 なぜ起きたか?」を問う傾向
  • 時系列や意思決定プロセス をまとめ、最終的には「納得できる説明」に落ち着く
  • 理解=解決ではない。良い説明は時に「変えなくても良い」という空気を生む
  • 誰も責めず、合理的な判断の積み重ね として片付け、半年後に再発するリスク
  • 変化を生み出すには「 同じクラスの失敗を次回減らすには何を変えるか?」を問うべき

合理的な人たち—変えるべきは人ではなくシステム

  • SVPは「 誰が悪いか」や「合理性の説明」には興味がない
  • 例:
    • 「Aliceが休暇で、BobはWidgetsチームの担当と思っていた」→ 不在時のオーナーシップ明確化
    • 「リリース3日前に要件変更」→ リリース直前の要件変更プロセス設計
    • 「アラート多発で重要なアラートを見逃した」→ アラートの質向上
  • システムの改善 に注力。人の努力や注意力に依存しない設計

良い説明=解決策ではない

  • 「サポートを早く巻き込むべき」「もっとコミュニケーションを」など 希望的観測だけの対策 はNG
  • 記憶や善意に頼る修正案 は「組織の伝説」に過ぎず、システムとして残らない
  • 「 同じ状況が明日起きたら、違う結果を生む仕組みがあるか?」が本質的な問い
  • 仕組みやプロセスの強化 が持続的な改善に直結

プロセス過剰のリスクと意識的なリスク受容

  • すべての失敗に 新たなプロセス追加 は現実的でなく、働きづらい環境を生む
  • 再発防止コスト>失敗コスト の場合、リスク受容も選択肢
  • 「 意識的にリスクを受け入れる」と「 努力目標で満足する」は全く異なる

信頼と変化へのリーダーシップ

  • SVPの「詳細は不要」は 信頼の宣言
  • 関係者の能力や善意を前提 とし、例外があれば別途対応
  • 共感や合理性の説明 が「変わらなくても良い理由」になるのを回避
  • 人は通常、与えられた情報や制約下で 最善を尽くしている
  • 変えるべきは人ではなくシステム
  • リーダーが発すべきメッセージは
    • 「 信じている。詳細は不要。何を変えるか教えてほしい」

提供: ハクソク · 要約更新:

AIによる日本語要約です。内容は原文とあわせてご確認ください。

Hacker Newsの議論を読む

Hackerたちの意見

それで気づいたんだけど、「詳細は要らない」っていうのは、軽視してるわけじゃなかったんだ。経営者は私たちが有能だと信じていて、「もう信じてるから、次に何をするかを話そう」って言ってるんだよね。これにはちょっと違和感がある。 - 完全に信頼してるなら、次に何が起こるかも知る必要ないじゃん。ただ彼らが正しいことをするのを信じればいいし、リーダーシップは必要ない。 - もし完全に信頼してないなら、「次に何が起こるか」が適切かどうかを詳細を知らずに判断できるわけがないよね。これって、リーダーシップが現場の状況を把握する必要がないっていう考えを強化してるだけじゃない?私が今まで働いた中で一番良いリーダーたちは、下から上への視点も持っていたよ。

└

私が今まで働いた中で一番良いリーダーたちは、下から上への視点も持っていたよ。もし私が下から上までの状況を把握しているなら、彼らに細かい技術的な詳細を再度説明してもらう必要はない。何を変えるつもりなのかを教えてほしいし、それは大きなシステム的な変化でなきゃダメ。細かいことじゃなくて、そういうところで多くのエンジニアが活躍するんだよね。

└

この記事はそんな風には読まないな。チームの自律性とリーダーシップの責任が交わるところで線を引くのは、経営者としてはかなり理にかなってると思う。「あなたたちは正しいことをして目標を達成したけど、問題が発生して、もう二度と起こらないようにする必要がある。これを解決するために何を変えるべきか話そう」って感じだよね。

└

彼は戦略を指示したり調整したりしたいんだよ、戦術じゃなくて。これは責任の良い分担だと思うから、あなたの反対意見が理解できないな。

└

誰かを信頼して、何が起こったのかの詳細や理由を知っていることができても、「二度と起こらないように何をするつもりなのか」という具体的な指示を出したいと思うことはあるよね。組織のデフォルトは、しばしば欠陥を説明すること(あるいはもっと悪いことに、責任を追及すること)に偏りがちだけど、再発防止のためのプロセス改善を具体的に考えることは少ないんだ。

└

自分で自分の質問に答えてるよ。 > 完全に信頼してるなら、次に何が起こるかも知る必要ないじゃん。正しいことをするのを信じればいいし、リーダーシップは必要ない。 > 私が今まで働いた中で一番良いリーダーたちは、下から上への視点も持っていたよ。この二つの発言は矛盾してるよね。最初に信頼の欠如が彼が次に何が起こるかを知る必要がある唯一の理由だと仮定して、その後に彼と大きな組織がもっと知ることで得られる利益を説明してる。これは単に信頼の問題じゃない。チームが何をしているのかを知ることで、必要なリソースを提供し、障害を取り除いて彼らが仕事を進められるようにすることが大事なんだ。これが良いマネジメントだし、低信頼の組織では誰もが歯車のように扱われて、誰も自分の意思で物事を進めることを信じられていないから、そういうのは珍しいんだよね。

└

大きな組織では、経営者が他の全員と同じフロアにいるのは単純に不可能だよね。そして、それだけじゃなくて、時間の無駄でもある。彼らは同時にせいぜい数プロジェクトにしか関わることができないかもしれない。組織の規模やプロジェクトの範囲によって全く文脈が異なると思う。スタートアップでは「経営者」やVPが他の全員と並んで働いたり、現場の運営について聞いたりすることができるけど、SVPという役割の性質上、もうそういうわけにはいかない大きな会社だと思う。ある時点で、それはチームに近い誰かの仕事になる。役割は完全に変わって、彼らの仕事はチームを支援し、障害を取り除き、権限やプロセスを迅速に進めたり、ビジネス価値を生まないアイデアを却下したりすることになる。だから、このシナリオでは、経営者が次に何が起こるかを文字通り聞くことが目的ではなく、適切なステップが踏まれていることを確認し、「誰か」が次に何が起こるかを処理していることを確かめることが目的だったんじゃないかな。それによって、チェーンを通じて報告したり、その「次に何が起こるか」のタスクを委任したりできるようにするために。

└

「信頼」って、通常は限界があるよね。小学生の息子が一人で学校に行く準備をするのは信頼してるけど、キャンプファイヤーを一人で始めるのは信頼してない。シェフが新しい従業員が一生懸命働くことを信頼しているかもしれないけど、オリジナルの料理を作って出すことを信頼しているわけじゃない。ここで「悪い結果にもかかわらず、みんなの行動は合理的だったと信じている」と言うのを、「あなたが私の指導なしで完全に解決するだろうと信じている」と言い換えている。両方の文に「信頼」という言葉が出てくるからって、同じ意味にはならないよね。人々が能力があって善意であることを信じるのと、あなたなしで同じことを達成するだろうと信じるのは別物だよ。

└

多くの場合、人々は必要な変化を進めるために、優しい後押しや権威者からの公式な承認が必要なんだよね。「上に管理しろ」とか、「自分の仕事とプロセスを完全に持て」って言っても、多くの人は他人の足を踏みたくないし、行動が行き過ぎていると見られたくない。組立ラインの作業員は、ラインをスムーズに動かす最良の方法を知っているかもしれないけど、「それは私の仕事じゃない」とか「私の給料の範囲を超えている」と思うのは簡単だよね。時には「はい、やっていいよ」と言うだけで済むこともある。これをもっと自動的に実現するのが一つの解決策だけど、それは責任や権限の境界があいまいになる問題を引き起こすことが多い。だから、比較的フラットな組織構造でうまくいくけど、大きな組織ではあまり使われていない。

└

いいリーダーは、何に注意を払うべきかを知っている。全てを知ることはできないからね。何か一つ(あるいは複数)を知ることはできるけど、知るべきことは生涯で学ぶ時間よりも多い。大事なのは、自分が知っておくべきことと、他の誰かに任せるべきことを見極めること。誰かが詳細を理解して、合理的な解決策を見つけてくれると信じなきゃいけない。時にはその解決策を知っておく必要があるし、時には詳細まで知っておく必要がある。時には、ただ解決したことを知っていればいいこともある。自分がどちらの立場にいるのかを知ることが重要だね。

└
  • 完全に信頼しているなら、次に何が起こるかも知る必要はない。彼らが正しいことをするのを信じていれば、あなたのリーダーシップは必要ない。タイムスケールを知っておく必要があるかもしれないけど、それは上層部や他の人に伝えるために。必要かもしれない他のリソースが利用可能であることを確認する必要があるかもしれない。計画された「次は何か」と提案されたタイムスケールは、彼らが気づいていない他の場所に影響を与えるかもしれない(今まで気づく理由がなかったかもしれない)。もし彼らが次は何かを教えてくれて、そういった複雑さがなければ、彼らはそのまま進めるだろう。そうでなければ、計画や他の計画に変更を加えて、時間やリソースをこの計画に確保する必要があるかもしれないし、潜在的な近い未来の対立を避けるためにそうする必要があるかもしれない。信頼するけど、確認もする。そして、場合によっては助けることも。

著者はまだSVPを誤解している気がする。もし私がエンジニアリングのSVPで、特にプロダクトのようなコアでないエンジニアリングの役割の人にこれを言っているなら、彼らが口に出してばかりいる傾向があることを認識していて、リスク軽減と対応計画に集中してほしいと思うだろうね。私はすでに自分のエンジニアリングリーダーと話をしたし、彼らがすぐに教えてくれたから、インシデントの詳細も読んでいる。でも、この記事は未熟なサービス組織からのもののように感じるから、彼らは運用対応プロセスを整理しているだけかもしれないね。

Hacker Newsで議論の続きを見る