ハクソク

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

人の話を聞くことから逃れようとするのはやめなさい

16時間前原文(ashley.rolfmore.com)

概要

  • ソフトウェア業界でよく見られるコミュニケーションの問題について解説
  • 「話す」より「聞く」ことの難しさとその落とし穴を指摘
  • フレームワークやシステム導入より本質的な対話の重要性を強調
  • 聞く力を妨げる一般的な誤解や偏見を具体的に列挙
  • 最後に、聞く力の欠如がもたらすリスクとその対策を提案

ソフトウェア開発における「聞くこと」の重要性とその課題

  • ソフトウェア業界では人同士の対話不足がしばしば問題となる現状
  • 対話を「フレームワーク」「システム」「socio-technical system」などの用語で技術的に包み込もうとする傾向
  • 問題の本質は新しいシステム不足ではなく、「聞く」という地道な作業の回避
  • 「聞くこと」は「話すこと」よりもはるかに難しい業務である現実
  • 多くの設計者やプロダクト担当者が「話す」を技術者向けの言語に変換しがちだが、根本解決にはならない

「聞くこと」で陥りやすい主な落とし穴

  • 「聞くこと」と「相手の要求をそのまま受け入れること」は別物
    • 既存のフレームワーク例：Jobs To Be Done、Outcome Driven Innovation、UXのエンパシーマッピング
  • 自分の専門性による視野の偏り
    • 自分が知っていることを相手も当然知っていると誤解しがち
  • 「テクニカル」の一括り思考
    • 技術領域は多様であり、「テクニカル」と「非テクニカル」の二元論は誤り
  • 全員が自分と同じリソースを持っているという思い込み
    • 能力、体力、資金、リスク許容度など個人差を無視しがち
  • 一人の特性を全員に当てはめる誤解
    • 年齢や性別でのステレオタイプ的な判断
  • 人や組織は変化しないという固定観念
    • 性格や状況は時間とともに変化する現実
    • プロジェクト開始時の要件が途中で変わることへの無理解
  • 「言っていること＝考えていること」と思い込む
    • 発言と本音が必ずしも一致しないケース
  • 相手を評価・判断してしまう癖
    • ドキュメントの誤解や理解不足を相手の能力のせいにしがち
  • 「80人＝1人×80」ではないという認識不足
    • B2Bの現場では人間関係や組織ダイナミクスの複雑さが顕著

「聞くこと」ができない場合の影響と今後のヒント

  • 「聞く力」が不足すると重要な情報やビジネスチャンスを逃すリスク
  • 誤解やズレが蓄積し、技術的負債（tech debt）の増加にも直結
  • 日常の業務で「自分は本当に聞けているか？」を常に振り返る意識
  • 聞く力の向上が競争優位や組織の健全化に直結する可能性

Hackerたちの意見

> この概念に関するフレームワークはたくさんあるから、他の人がすでにうまくやっていることを繰り返すつもりはないよ。Jobs To Be Done、Outcome Driven Innovation、UXの分野ではエンパシーマッピングもあるしね。理解はできるけど、著者が他の良い記事やリソースへのリンクを含めてくれたら嬉しいな。
└
>> この概念に関するフレームワークはたくさんあるから、他の人がすでにうまくやっていることを繰り返すつもりはないよ。> 理解はできるけど、著者が他の良い記事やリソースへのリンクを含めてくれたら嬉しいな。著者はこの記事で主な問題点を指摘していると思う：必要なのはより良いシステムではなく、仕事を避けていることが問題なんだ。
もしかしたら、コミュニケーションに時間をかけすぎてるのかもね。時間をかけすぎると集中力が続かなくなるし、次の機会に明確にすることができるから。無駄な会議は全部カットして、最低限必要な時間だけコミュニケーションに割り当てれば、みんなちゃんと聞くようになるよ。
└
> もしかしたら、コミュニケーションに時間をかけすぎてるのかもね。これはまだ実際には体験したことがない現象だな。> 無駄な会議は全部カットして、最低限必要な時間だけコミュニケーションに割り当てればいい。ほとんどの会議はコミュニケーションのためじゃないし、形式的で独裁的なものが多いよ。> そしたらみんなちゃんと聞くようになる。聞くことはスキルで、練習すれば上達するんだ。会議やその時間の長さはこのスキルには寄与しないよ。
└
これまでに、結果が次の会議を計画することになる会議にたくさん参加してきたよ。さらに多くの人を含めるチームが、決定を自分たちに有利に進めるんだ。そうやって政治的な意志で無駄な社員を雇うことになるから、さらに会議が増えるんだよね。解決策は、リーダーシップのような単一のビジョンを作り、そのビジョンに向かって独立して取り組める目標をチームに与えることだと思う。チーム間の依存関係をなくして、コミュニケーションの必要を減らすことが大事で、コミュニケーションやJiraチケット、ガントチャート、RACIマトリックスを増やすことじゃないよ。
└
これって、実際にはコミュニケーションを装っている時間が多すぎるってことだと思う。必要な人数が揃ってない会議に参加していることが多いけど、それでも人々は会議を続けようとする。もっとひどいのは、有意義な会議にするための前提条件が整っていない会議に参加することが多いってこと。結局、AIが作った適当なドキュメントが目の前に置かれて、まともな考えや責任感はほとんど無視される。30分間、読者をガスライティングして「理解できてないからバカだ」と感じさせた後に、「この会議は時間の無駄だった」と修正する10分間が続く（会議の最初にドキュメントを読むから）。問題は、コミュニケーション（またはアラインメント）が会議の目的であるべきなのに、よくあるのは誰かが自分の仕事をグループプロジェクトにしようとしていること。現代ビジネス界の石のスープみたいなもんだよね。「この会議の目的は何？」って早めに聞いて、会議の主催者がただの勉強会を開こうとしているわけじゃないことを確認するのが良いよ。上から見下ろすだけのマネージャーは、会議で仕事が進むのを見ているだけだから、会議が仕事をする場所だと思い込んでいる。会議を成功させるために必要な準備にどれだけの労力がかかっているかを理解していないんだ。思考の明確さを見つける前に「コミュニケーション」を急いでしまうと、会議はただの雑音になってしまう。こういう持続的な不満に対するシンプルだけど強力な反応がある。それは、心の奥で無能な人たちに恐れを抱かせる言葉だ。「わからないけど、今すぐ解決しよう。」問題をじっくり考える時間が必要なときは、依存関係の順序を守ってもらう。「なぜ」「何を」「どうやって」「誰が」「いつ」… もし、前提条件（例えば「なぜ」「何を」「どうやって」）を知らないのに「誰が」を考えようとしているなら、進めないよ。インターンでもVPでも関係ない。いい加減な答えにショートカットはできない。問題を分解して、考えを整理して、その場で理由を考えて、もしチームが行動を変えないなら、別のチームを探すべきだ。適切な環境では、何人かは責任を持って大人として一緒により良いものを作ろうとする意欲がある。でも、残念ながら、そういう呼びかけに応えられない（または応えたくない）人が多いから、また別の目的のない会議を開くことになる。
└
ソフトウェアアーキテクチャの経験から言うと、図を描くことで60分以上の議論と複数の会議を節約できることが多いよ。たとえ下手に描かれていても、真実を伝える図なら効果的だ。リモート会議ならAIエージェントとMermaid.jsを使ってサッとメモを取るといいし、対面の会議ならホワイトボードやペンと紙を使うといい。図は言葉よりもずっとわかりやすいから、特にその概念や論理が単純じゃないときはね。
└
コミュニケーションに「時間をかける」ことと、実際にコミュニケーションすることは同じじゃないよ。
問題には同意するけど、このリストは愚痴みたいに読めるな。効果的なコミュニケーションは人類全体の中心的な問題だよ！この愚痴は開発者が聞くことを知らないことを批判してるけど、それが上から目線に感じる理由だね。根本的な問題は、人々が自分が知らないことを知らないってことだよ。最高のコミュニケーターは翻訳者なんだ。人々は、メッセージが自分の理解において明白になるからこそ聞くんだよ。これは壊滅的な状況じゃなくて、みんなが耳を塞いでいる幼児のように振る舞っているからなんだ。皮肉なことに、だからこそ私たちはシステムやエンジニアリングに頼るんだ。システムはギャップ検出や翻訳のためのフレームワークを組み込むことができる。完璧ではないし、自分自身の問題を生むけど、各ユニットの人間にもっと聞くように叱ることは、チームや会社…システム全体には何の役にも立たないよ。
└
そうだね。これってただのランダムな自己啓発の話だよ。でも、自己啓発本よりも少し悪いかな。自己啓発本は少なくともいくつかの例を提供してくれるから。
└
古いグレイブレッドが言ってたことを伝えるね。彼は、常にノイズの方が信号よりも大きい「ノイジーシステム」として考えるべきだと言ってた。中には限界のあるチンパンジーがいるって。限界があるってことは、誰もができることには上限があるってこと。そして、チンパンジーの脳のモデル更新がどれくらいの頻度でできるかにも上限がある。グループ全体の限界はもっと低い。極端な話、大きな組織は現実のモデルが定まると、根本的に更新するのに何十年もかかることがある。たとえ現実が完全に変わったサインがあってもね。だから、その制約を考慮して、自分がエネルギーと時間をどこに使いたいか決めてね。
└
> 効果的にコミュニケーションすることは人類全体の中心的な問題だ！もしそれが本当なら、聖書にも何か書いてあるはずだよね。
└
私は開発者だけど、他の仕事もたくさん経験してきたから、コミュニケーションの重要性と、開発者がそれが苦手なことをよく知ってる。私が認識した典型的なパターンは、多くの開発者が悪い医者のようにコミュニケーションすることだ。「うーん、あー」って言った後、すぐに必要なものの診断を出してくる。時には、まだ関連することを全部言ってないのにね。ソフトウェアの世界では、時々人々があまり良いコミュニケーターでないのは新しいことじゃない。最初の部分で面白いのは、クライアントが何を望んでいるかじゃなくて、彼らが何を必要としているかだよ。彼らがソフトウェアがどのように問題を優雅に解決できるかをよく理解している珍しい顧客でない限り、何かを考え出すのは誰かの仕事だったはずで、その誰かはソフトウェアについてあまり考えたことがないことが多い。だから、彼らのアイデアが無価値だというわけじゃないけど、要件を見つけて解決策を考える作業は、あなたが到着したときには通常終わっていないんだ。解決するためには、コミュニケーションが必要で、観察や彼らにプロセスを説明してもらうことが大事。私の経験では、多くのソフトウェア開発者は本当に聞いていない。開発者だけじゃなくて、医者や他の技術者にも同じことが言える。彼らは自分の専門知識をアピールしようとして、急いで有能に見せようとすることが多い。彼らにとって、あなたは彼らが何度も対処してきた問題の明確なケースなんだ。これが彼らにとってうまくいくこともあるけど…うまくいかない時もある。
> もしこれがなぜ起こるのか疑問に思っているなら、通常は次の理由からだ：1. 人々が人々に話していない 2. 人々が聞いていない これが正しいとは思わない。理由は、上の漫画の比喩を使うと、話さない人や聞いていない人たちが最初に求めていたのは、道ではなくリボンカットだったからだと思う。
あなたは、彼らが言うことが彼らの考えていることと同じだと仮定している。でも逆もまた真なりだよ。何かを言っている人は、聞いている人が同じことを理解して考えていると仮定しているんだ。だからこそ、詳細に書いてできるだけ明確な形で伝えることが重要なんだ。会議中に、6語の箇条書きで「説明」するスライドを出されたら、それは誰も目標を理解していないサインだよ。もし会議に参加するのに1ページのドキュメントも書かずに出てきたら、その内容を十分に理解していないってことだ。もしあなたの進行がそのことにかかっているなら、もっと明確なビジョンを求めるべきだよ。
└
彼らに要求を正当化させることも必要だよ。実際に必要なものを超えたものを求めるのは、彼らが本当に必要なものを理解していないことを隠す簡単な方法だから。私の経験では、実際の要件の10倍を求める人は結構いるよ。でも、たまに「最高のものを買うべきだ、そうすれば将来心配しなくて済む」って言う人もいる（私が聞いたときは、500倍のコスト差があった）。
└
私が言うこと：これは製品化にはまだ早い。経営陣が聞くこと：これを顧客に受け入れテスト用に売れるよ。
└
> 同じことについてね、そうだね。私は同僚に「何について？」って4～5回連続で言わなきゃいけないことがあって、少なくとも1日2回はそうなる。やっと彼らがどのクライアント、機能、製品について話してるのか教えてくれるまで。私が彼らの言ってることを正確に理解しててもね。
└
> だから、詳細に書くことが重要なんだ。できるだけあいまいさを排除してね。それが深い共有理解の前提条件かもしれないけど、ここ数年の経験で、メッセージやチケット、メールの最初の文を超えて本当に読んでいる人の数がどんどん減っていることに気づいた。私はしばしば、彼らに情報を小さくて消化しやすい部分で提供しなきゃいけない。これが本当に嫌なんだ。
問題の大半は、技術に詳しくない人と話すのがイライラすることだね。彼らはよく「1. Xを追加できる？ 2. Yを変更できる？」みたいに始めるけど、これらを実行するコストを理解していない。確かに、君が頼むことは全部できるけど、どのアクションにもコストがかかるってことを理解してほしい。信頼できる製品をリリースするためには、何でもできるわけじゃないんだ。
└
そのコストは今やかなり下がったよ。AIがコードを書くことをやってくれるからね。好きか嫌いかは別として、それが現実なんだ。
└
この記事がまさにそのことについてなんだよね。彼らはコストを「理解できていない」わけじゃなくて、ただ異なる文脈を持っているだけ。君の仕事は、彼らが情報に基づいたトレードオフをする手助けをすることであって、彼らが頼む前に何がどれくらいのコストかを知っていることを期待することじゃないんだ。
└
こういう状況では、非技術者はコストを理解せず、技術者はメリットを理解しない。両方のコミュニケーションが必要で、良いコスト対効果のバランスを見つけることが大事だね。
「専門性の効果」についての指摘は過小評価されてると思う。自分が何年もかけて内面化してきたことを、ユーザーが理解していないことでイライラすることもある。でも、彼らはその間に全く別のことを内面化しているわけだから、知識がないわけじゃないんだよね。ただ、別のところにあるだけなんだ。
コメント欄でも、この記事を読んでその指摘に引っかかってしまう人がいるのを見ると、皮肉だよね。いくつか追加させて。1. どんなに知識や議論を重ねても、受け入れたくないことを受け入れることはない。2. 本当に聞くということは、精神的にも肉体的にも脆弱な状態に自分を置くことだ。なぜなら、自分の経験や信念、世界観に反することを聞く可能性が高いから。人を判断することは、しばしば自己防衛のメカニズムで、つまりほとんど誰かの話を聞かないことになる。3. 聞くことは、すぐに解決策に飛びつくことではなく、誰かの痛みを吸収し、処理することを意味する。たとえば、プロダクトマネージャーはすぐに解決策や新しい機能に飛びつくか、「ああ、じゃあ、そのためのチケットを作るよ」とリクエストを流してしまう。でも実際には、彼らはユースケースを聞いて、痛みを探し、その痛みを解決する方法を見つけるべきなんだ。ユーザーがリクエストしたい機能を理解しようとするのではなくてね。
└
> どんなに知識や議論があっても、受け入れたくないことを受け入れる人はいない。事前にそう思うのはあまり良くないかも。ほとんどのことは交渉できるから、上手に交渉できればね。
└
プレセールスの発見を一言で言うと、まさにアートだね。
└
> 本当に聞くということは、精神的にも身体的にも脆弱な状態に自分を置くことだ。もし双方向でないなら、無理に続けようとせず、立ち上がって出て行くべきだよ。
└
"実際には、彼らはユースケースを聞き、痛みを探し、その痛みのポイントを解決する方法を見つけるべきだ。" これで、製品デザインの価値を説明したことになるね（その人がPM、UX、製品デザイン、または他の何かと呼ばれていても関係ない）。
└
そんなことは心配しないよ。だって、まだ間違ったことはないから。
└
"本当に聞くということは、精神的にも身体的にも脆弱な状態に自分を置くことだ。" もしこれがどんな状況でも悪用されず、私にとって後々の悩みにならないと保証してくれるなら、喜んでいつでも時間を割いてちゃんと聞くよ。 :)
└
いろいろ聞いてきたけど、時々人は考えすぎちゃうよね。特に自分の痛みのポイントについて。誰かが解決策を提案してくれると、考え方が変わるのを助けてくれるんだよね。そうすると、解決策について話すことができるし。一方で、私の共感が足りないように感じられることもあるかも。
面白いね。すごく共感できる。)) 特に最近たくさん学んだ中堅の専門家にとっては、声を上げて自分の知識をアピールしたいって気持ちが強いと思うな =D。でも、知識が豊富で多才な人たちにも当てはまるよね。そういう人たちが、あまり読書をしていない人や経験が少ない人の話を聞かなくなるのは間違いだと思う。彼らは「真実の源」としての立場を取ろうとするけど、実際には、あまり偏見のない人たちがオリジナルな—たぶん未熟だけど—アイデアを出すことが多いと思う。そういうアイデアを聞くには、抑え込むんじゃなくて、ちゃんと聞いて考えを引き出すスキルが必要だよ。
私の主な役割はカスタマーリレーションシップマネージャーなんだけど、一番大事なのは顧客の期待を現実に合わせることだよね。顧客の期待が実現可能なことや、それにかかる時間、費用、実際に使える時期と一致すれば、たとえ開始日や費用に不満があっても、ハッピーな顧客ができるんだ。最初から大体の見積もりを合わせておくのがポイントだね。どれだけ話を聞いて共感しても、現実は現実だから、顧客もその現実を認めたり受け入れたりしなきゃいけない。クライアントの要望に何でも同意するカスタマーリレーションシップマネージャーがいると、すごく不満な顧客ができちゃうよ。顧客と社内チームの両方の意見を聞いて、顧客の期待が実際にチームが提供できるものと一致しているか確認する必要があるんだ。