人の話を聞くという仕事を、工学的に回避しようとしないこと

• ソフトウェアの現場における核心的な難題は、会話そのものの不足よりも聞くことの不足であり、それをframeworkやsystemのような表現に置き換えて解決しようとするアプローチは、実際に必要な「聞くこと」を避けてしまう
• 誰かの依頼をそのまま実行することは、実際の要求を把握することとは異なり、専門性の効果とtechnical / non-technical の二分法は、相手の知識や文脈を見落とさせる
• 誰もが同じエネルギー、技能、資金を持っていると見なしたり、一人の特性を集団全体に一般化したりすると、人ごとに異なる制約や判断基準を適切に捉えられない
• 人や組織は、時間や役割、ストレス、集団力学によって変化し、発言内容と実際の考えが常に一致するわけではないため、固定的な要件はソフトウェア制作と容易にずれていく
• 聞くことの失敗は、最も価値の高い洞察を取り逃がし、収益機会と競争優位の喪失、誤解の蓄積によるtech debtの増加につながる

---

核心的主張

• ソフトウェアの現場では、人と人との会話の欠如よりも、より大きな核心は聞くことの不足であり、それをframeworkやsystemのような用語に置き換えて解決しようとするアプローチは、実際に必要な作業を避けるやり方である
• デザイナーやproduct担当者は、人との対話をengineeringが受け入れやすい表現へと変えようとしがちだが、より良い仕組みより必要なのは、人の話をきちんと聞くことだ
• 人と会話することよりも、人の話を聞くことのほうが難しいという前提のもとで、実際に聞くことを妨げる代表的な落とし穴を整理する

聞くことを妨げる代表的な落とし穴

• 言われた通りにやることと、聞くことは違う

  • 誰かが望んでいると言ったことをそのまま実行することと、実際の要求を聞き取ることは同じではない
  • このテーマに関する既存のアプローチとして、Jobs To Be Done、Outcome Driven Innovation、UX領域の empathy mapping に言及

• 専門性の効果によって自分の視点を過小評価する

  • 特定分野を長く学ぶと、「これくらいは当然知っているはずだ」という前提が生まれやすい
  • 相手がその分野の専門家であっても、同じ知識を持っているとは限らず、その代わりに別の知識を持っていることがある
  • きちんと聞くには、相手が何を知っているのかをより深く理解する必要がある

• technical を単一カテゴリとして見なす

  • ソフトウェア開発者に特にありがちな落とし穴で、technicalは一つの性質ではなく、異質な知識領域からなる広いスペクトラムである
  • 「technical / non-technical」という二分法で人を見ると洞察を逃し、きちんと聞けない可能性が高まる

• 誰もが同じ資源を持っていると仮定する

  • 同じエネルギー、同じ技能、同じ余裕資金を誰もが持っていると考えると、誤った判断が生じる
  • 同じ健康状態にある人でも、管理の仕方や実際に取れる行動はそれぞれ異なりうる
  • 数学が得意な人、別の能力に優れた人、資金や余裕が少ないためよりリスク回避的に行動する人など、違いがある

• 一人の特性を集団全体に一般化する

  • ある特性を持つ一人に出会ったからといって、他の人も同じだと考えてはいけない
  • 例として、高齢者はコンピュータを理解できないと決めつける態度に言及
  • 女性全体を、個人的な家族関係のイメージへ還元する態度も同じ誤りである

• 人や組織が固定されていると仮定する

  • マクロな水準では、性格は時間とともに変化する
  • ミクロな水準では、職場での persona と家庭での姿は異なり、ストレスや特定の条件下では判断も変わる

• 発言と考えが同じだと仮定する

  • ある人は言った通りの意味で話すが、そうでない人もいる
  • 自分では率直に話しているつもりでも、実際にはそうでない場合が多い

• 人を裁く

  • 不十分に文書化された内容を誤解した人を嫌ったり dismiss したりすると、きちんと聞ける可能性は大きく下がる
  • 相手が仕事ができない、あるいは人生を間違って生きていると決めつける態度も、聞くことを妨げる要因である

• 80人を80人の個別の人間ではなく、一つの集団として扱う

  • B2BはB2Cよりも、むしろ人間的な側面が強く、関係性や力学、組織図の外にある soft power のような要素が働く
  • 集団力学が加わることで、個人単位よりもさらに複雑な変数が生まれる

固定的な要件とソフトウェアのずれ

• 人や組織が変化するという事実のため、fixed project managementはソフトウェア制作に適していない
• 要件を最初に確定しておいても、その間に人は変わり、成果物ができたときに一致しているとしても、せいぜい開始時点の要求とだけである
• リリース時点には、もはや望んでいるものではないかもしれず、人は待つあいだにそれぞれ期待を上乗せするため、現実はそのすべての期待と一致しない

結果と影響

• 人の話をきちんと聞けなければ、最も価値のある洞察を取り逃がし、それは収益機会と競争優位の喪失につながる
• 誤解が積み重なるほど、後で一緒に扱わなければならないコードに新たな要素が追加され、一部のtech debtの原因を最小化することとも、聞くことは結びついている
• 聞けていない瞬間に気づけるほど、よりよく聞ける可能性が高まる

[GN⁺]

Hacker Newsの意見

• 私はかなり精密に言葉を選ぶほうで、ある表現を使ったなら本当にその意味を意図している。ところが多くの人は、私から見るとまるでトーン・ポエムのように話し、手近な言葉で周辺をなぞって共通のニュアンスで理解されることを期待しているので、解釈そのものが疲れる。私が文章を書くときはすべての単語を意図的に選んでいるのに、職場でさえ私の表現が不正確だったかのように解釈されることがほとんど常に繰り返されていて、かなりつらい。スペクトラム傾向があるのかもしれないが、診断を受けたことはない。半年ほど前、別部署が長い作業を始められるように小さなRPCを作って文書を書いたのだが、1ページにも満たない分量ながら完全で正確かつ簡潔だった。ところがマネージャーが理由の説明もなくその文書をAIに通して転送し、私はその事実すら知らなかった。1日も経たないうちに筋の通らないフィードバックが殺到し、実際のリクエスト例を見るとエンドポイント改変が起きていた。単なるタイプミスではなく、完全にでっち上げられたアドレスで、文書ではエンドポイントも必須パラメータも全部間違っており、存在しない機能まで発明されていた。普段は忍耐強いほうだが、あのときほど怒ったことはなく、今でも腹が立つ。雇用市場の状況さえ違えば、すぐ辞めていたと思う。人が自分で読んで解釈すべき言語をAIに任せることは、厳密な言語の死のように感じられるし、生成AIが文明を滅ぼすある種のGreat Filterなのではないかと、ここ数か月かなり本気で考えている

  • 私にはこの見方が少し新鮮に感じられる。言葉が思考の境界を正確に切り分けて収めるとは考えにくく、言語は世界や各自の理解を表現する道具なのだから、似た概念を異なる言い方で説明するのは自然なことだ。思考から言葉へ移した本人にはより明確に見えても、聞き手にはそうでないことがある。だから解釈の労力を軽く扱うことはできないと思う。おそらくその状況の相手側と話してみれば、彼らも結局はあなたの言葉を解釈しづらいと、同じようなことを言う気がする
  • この設定があまりに強烈で、すぐ小説を思い浮かべた。Great Filterと生成AIを結びつける発想がとても良くて、これはCory Doctorowが今すぐ書くべき物語のように感じる
  • まず、なぜマネージャーがその文書をAIに入れたのかを聞くべきだと思う。ときには精密さが増すほど可読性が落ち、圧縮された言語であるほど読者は一語一語により大きな認知コストを払わなければならない。読むというのは、書き手の頭の中のモデルを読者のモデルへ翻訳する過程であって、単語だけで自動変換されるものではなく、解釈という行為が必要だ。簡潔すぎると読者を助ける手がかりが失われることがある。1ページの文書が一般読者には短すぎて理解の助けにならなかったため、AI要約のような迂回が起きた可能性も疑われる。読者のための文章を書くことは、最高コンテクストの読者に向けた正確なメモを書くこととはまったく別の作業であり、特に不特定多数に向けて書くときは、反復、わかりやすい例、馴染みのある文脈、手順の細分化、ときにはユーモアや背景説明まで入れて理解を助けるべきだと思う
  • 私も最近似たことを経験した。私が4ページの仕様を書いたのに、受け取った人はそれを読まずにLLMでいくつかの箇条書き要約だけを抜き出し、その結果、要件に合わない提案書が返ってきた。私が反対すると、彼はその内容は本来仕様に書かれているべきだったと言ったが、実際にはすでに仕様に書かれていて、ただ彼のLLM summaryに入っていなかっただけだった。私は一語一句に執着するタイプではないが、4ページ文書の情報が10個の箇条書きの中に完全に収まるとは思えない
  • むしろこれは、これをnormie speakに変換してくれる専用プロンプトやカスタムLLMがぴったりの事例だと感じる

• このコメント欄を見ているだけでも、文章が指摘した問題をそのまま再現している人が多くて皮肉だと感じる。ここにいくつか付け加えたい。第一に、どれだけ知識と議論を積み重ねても、相手が受け入れたくないことは簡単には受け入れない。第二に、本当に耳を傾けることは、精神的にも身体的にも自分を脆弱な状態に置くことだ。自分の経験や信念、世界観と衝突する話を聞くことになるからであり、人を判断する態度はしばしば自己防衛の仕組みなので、それゆえかえってよく聞けなくなる。第三に、傾聴とはしばしば、すぐ解決策に飛びつくのではなく、相手の苦痛を吸収して処理することだ。たとえばProduct managerはすぐ新機能やチケットに還元しがちだが、本当はユースケースを聞いて痛点を見つけて解決すべきであって、ユーザーが求めた機能名だけを理解しようとしてはいけないと思う

  • この命題をあらかじめ前提にしてしまうのは危険だと感じる。たいていのことには交渉の余地があり、きちんと交渉する方法さえ知っていれば変えられると思う
  • 特に2番はとても深く感じた。この言葉を大切な人にぜひ送ってみたいし、その人にも本当にlistenしてもらえたらと思う
  • 傾聴が脆弱になることだという点には共感するが、その脆弱さが毎回悪用されないと保証されるなら、喜んで時間を取っていつでもちゃんと聞きたいと思う
  • 本当に知りたいのは、他人の苦痛を吸収するとは実際には何を意味するのか、そしてそこからどうやって機能定義やチケット作成へ自然につなげるのかということだ
  • これこそがpresales discoveryの本質だと感じる。本当に技術というより芸術に近い領域だ

• 問題意識には同意するが、この一覧はやや愚痴のようにも読めた。効果的なコミュニケーションは人類全体の中核問題に近く、この文章は開発者が傾聴できないと叱りつけるニュアンスがあって、少し高圧的に感じられた。根本的な問題は、人が自分が何を知らないのかを知らないことにある。最高のコミュニケーターは翻訳者のようなもので、メッセージが相手の理解の中で自明になったときに初めて人は耳を傾ける。みんなが耳を塞いだ幼児のように振る舞うことで起きる単純な崩壊だとは思わない。だから私たちはシステムやエンジニアリングを求め、システムの側にギャップ検知や翻訳フレームワークを組み込もうとする。完璧ではなくても、個人にもっとよく聞けと説教するより、チームや会社やシステムのレベルで環境を変えることのほうが重要だと思う

  • 昔、ある年配の人がこれをNoisy systemとして見ろと言っていたのを思い出す。信号は常にノイズより弱く、その中には限界のある人間が入っている。各人にできることにも上限があり、人の思考モデルが更新される速度にも限界があり、集団の限界は個人よりさらに低い。特に大きな組織は、現実が完全に変わっても既存モデルを変えるのに何十年もかかることがある。だからこうした制約を認めたうえで、自分の時間とエネルギーをどこに使うか決めるのが大事だと感じる
  • これは単なるありふれたself-help記事に見えたし、例も不足していて、それ以上に少し物足りなく感じた
  • 私は開発者でありつつ他の仕事もかなりやってきたので、コミュニケーションの重要性と、開発者がそこでどれほど頻繁に弱いかをよく知っている。よくあるパターンは、開発者が悪い医者のように聞くふりをしながら、早すぎる段階で診断を下してしまうことだ。相手が大事なことを言い終える前に、必要なものはわかったと宣言してしまう。ソフトウェアで顧客が望むものより重要なのは、しばしば顧客が実際に必要としているものだ。ソフトウェアで問題をエレガントに解く方法までよくわかっている顧客はまれで、たいていはソフトウェアを深く考えたことのない誰かがアイデアを持ってくる。そのアイデアに価値がないという意味ではないが、要件整理と解決策の導出はまだ終わっていないということだ。それを完成させる方法は観察と説明、そして対話だ。私の経験では、多くの開発者は本当にうまく聞けず、医者や他の技術職も似ている。自分がどれだけ知っているかを示して早く有能に見せたがり、相手を自分がすでに何度も見た問題類型のひとつに分類してしまう。たまにはうまくいくが、うまくいかない瞬間は必ず来る
  • 冗談半分に言えば、もし本当にコミュニケーションが人類の中心問題なら、Bibleにも何か一節くらいあってよさそうだと思う

• 人が言っていることと実際に考えていることが同じだと簡単に仮定すべきではないと思う。逆に、話し手も聞き手が同じ対象を思い浮かべて理解していると錯覚しやすい。だからできる限り詳しく曖昧さなく書いておくことが重要だ。会議で誰かが6語の箇条書き1つで目標を説明しようとするなら、それは実質的に誰も目標を理解していないというサインだと感じる。1ページの文書もなしに会議に入ってくるなら、その人はまだそれを十分に理解していない状態であり、自分の進捗がその成果物に依存するなら、もっと鮮明な絵を要求すべきだと思う

  • 同僚に対して、1日に何度もabout what? を繰り返し聞かなければならない状況がよくある。どの顧客なのか、どの機能なのか、どの製品の話なのかを具体的に言うまで、4〜5回聞き返すことも多い。自分が彼らの言いたいことを正確にわかっている場合ですら、そうしなければならないことがある
  • 要求の正当性も必ず検証すべきだと感じる。実際の必要がわからない状態を隠す最も簡単な方法が過剰な要求だからだ。私の経験では必要なものの10倍を要求するのはよくあることで、以前には500倍のコスト差がある選択肢を前に、将来を心配したくないなら最高仕様を買うべきだと言われたことさえある
  • 詳しく曖昧さなく書くことは深い相互理解の前提条件にはなりうるが、この数年で人はメッセージやチケット、メールの最初の一文以上を本当に読まなくなったと感じる。だから情報をとても小さな断片に砕いて与えなければならないことが増え、それがかなり嫌だ
  • 現実ではこういうことがあまりに頻繁に起きる。私がproduction readyではないと言うと、経営陣はそれを顧客にacceptance testingとして売れるという意味に受け取ることが多い
  • ここでふとソ連時代の映画Kin-dza-dzaを思い出した。ある人物が別の人物について、彼は自分が考えていないことを話し、自分が考えていないことを考えている、と表現するのだが、この会話の混線を描写するのにかなり合っている気がする

• 私は主に顧客対応の役割を担っているので、最も重要なのは顧客の期待値の調整を現実に合わせることだと考える。何が可能か、どれくらい時間がかかるか、費用はいくらか、いつproductionに載せられるかを顧客の期待と一致させておけば、開始日や費用が気に入らなくても最終的には満足した顧客になる。特にコストはしばしば案件を壊す要素なので、おおよそのレンジを早い段階で合わせておく。どれだけよく聞いて共感しても、現実は現実であり、顧客もその制約を認めるか受け入れる必要がある。顧客の望むことに何でも相槌を打つ顧客担当者は、結局顧客をより不幸にし、よいインターフェース担当者は顧客と内部チームの両方の話を聞いて、実際に提供可能なものと顧客の期待が一致するようにするべきだと思う

• もしかすると、私たちはコミュニケーションに時間をかけすぎているのかもしれない。時間を過剰に割り当てると集中力が散り、どうせ次回また明確にすればいいと先送りしやすくなる。不要な会議を減らしてminimum viable timeだけを割り当てれば、むしろ皆がもっとよく聞くようになると思う

  • この現象を現実でほとんど見たことがない。たいていの会議は実際にはコミュニケーションではなく指示と通達に近く、聞く能力は会議の長さとは無関係な別のスキルだ。傾聴は練習で磨く能力であって、会議時間を減らせば自動的に身につくものではないと思う
  • 結果が次の会議を設定することだけの会議に、私はあまりにも多く参加してきた。しかもさらに多くの人を巻き込み、人数の多いチームが決定を自分たちに有利な方向へ寄せて政治的影響力を確保し、それがまた不要な採用や会議の増加につながるパターンも見てきた。出口はコミュニケーションを増やすことではなく、単一のビジョンを打ち立て、チーム間の依存関係を減らして各チームが独立して働けるようにすることだと感じる
  • ソフトウェアアーキテクチャの仕事をしていて、図ひとつが60分以上の議論と複数回の会議を節約してくれるのをよく見てきた。うまく描けていなくても、事実に忠実な図であれば十分で、複雑または自明でない論理は言葉よりdiagramのほうがずっと明確だった。リモート会議ならAi agentとMermaid.jsで素早く描けばよく、対面ならホワイトボードか紙とペンで十分だと思う
  • コミュニケーションに時間を使うことと、実際にコミュニケーションすることはまったく別のことだと感じる
  • 実際には、私たちはコミュニケーションに時間を使いすぎているのではなく、コミュニケーションしているふりに時間を使いすぎていることのほうが多いと思う。定足数にも満たない会議を無理やり開き、前提条件もなく進め、考えなしに作られたAI slop documentを投げておいて、人々が理解できないと今度は読む側が馬鹿であるかのように扱う場面をよく見る。会議の最初の30分はガスライティングのように進み、最後の10分でようやく時間の無駄だったと認めて収拾する、という具合だ。本来会議とは、よく熟成された考えと一貫した方向性を共有し、明確な主張に意味のあるフィードバックを得る場であるべきなのに、実際には誰かが自分の仕事をstone soup式のグループプロジェクトに変えようとする試みを皆で処理していることが多い。序盤にこの会議の目的は何かと聞けば、主催者が単なる勉強会を開いているだけだとわかる。視座だけ高い管理者は仕事が会議で行われると錯覚するが、良い会議の前に必要な思考作業はよく見えていない。考えが整理される前にコミュニケーションを急ぐと、会議はただのノイズになる。こういう状況で最も強力な対応は今ここで一緒に見つけようという態度で、私はWhy、What、How、Who、Whenの順の依存関係を守らせる。前段が空なら後ろへ進めず、インターンだろうとVPだろうと安易なごまかしは許さない。問題を分解し、その場で考えてみてもチームが変わらないなら、結局は別のチームを探すのが正しいと感じる

• この文章のspecialism effectの指摘はかなり過小評価されていると感じる。私も、ユーザーが自分が何年もかけて体得したものを理解できないことにもどかしさを覚えたことがあるが、すぐに問題は彼らに知識がないことではなく、別の場所に蓄積されていることなのだと気づいた。彼らも同じ時間をまったく別のことを深く学ぶのに費やしてきただけだ

• 人々が話さず、聞かないことが根本原因だという説明には完全には同意しない。漫画の比喩を借りるなら、多くの人は最初から道路そのものよりテープカットを望んでいて、結局それを手に入れたからこうなっているのだと思う

• 人は自分では言った通りの意味だと言いながら、実際にはそうでないことがある、というのを私はかなり滑稽な形で経験したことがある。相手の言葉をほとんどそのまま言い換えて理解確認をしたのに、返ってきた反応は、それは絶対に自分が言おうとしていたことではないという強い否定だった

• 非技術職と話すときに生じる多くの問題の核心は、彼らがコストの文脈なしに、ただXを追加してYを変えようと言うことにあると感じる。もちろん言われたことのほとんどは実現できるが、それぞれの要求にはコストがあり、それを理解しないままでは信頼できる製品リリースと両立しにくい

  • この反応こそが、むしろ文章の核心をそのまま示していると感じる。彼らはコストを理解していないのではなく、単に文脈が違うだけであり、技術担当者の役割は、最初からコストを知って来ることを期待することではなく、彼らが情報に基づいたtradeoffを行えるよう助けることだと思う
  • こういう状況では、なぜ必要なのかを尋ねるwhysが重要だと感じる。非技術的なプロセスを理解してみると、実は追加や変更自体がまったく必要ないかもしれない。何でも入れていけば結局、Turing complete Excel/Email cloneのような怪物になるという点にも同意する
  • この状況では、非技術側はコストを知らず、技術側は便益を知らないという非対称が生じるのだと思う。結局、双方のコミュニケーションがあってこそ、コストに対して便益のよい着地点を見つけられる
  • これはかなり解決可能な問題だと感じる。各要求について、何か月かかるのか、いくらかかるのかを、月単位とドル単位で見積もって答えればいい
  • ただ、最近はAIがcode thingを代わりにやってくれることで、実装コストそのものがかなり下がっているのも現実だと思う。好き嫌いは別として、その変化は認めるべきだ