専門家は楽勝 (2024)

373日前原文(boydkane.com)

概要

専門家 は 初心者 より効率的に高い成果を出せるが、その理由や影響は十分に研究されていない。
初心者は 無駄な努力 や自己作成の問題に苦しみがちで、専門家は問題の本質を素早く見抜くことができる。
専門家の 直感的判断 やネットワークの活用は、初心者にとって見えづらい。
初心者が上達するには、 共感的な専門家 のサポートや観察が重要となる。
インターネットやAIも役立つが、 直接的な対話 の価値は依然として高い。

専門家と初心者の効率性と迷路の比喩

専門家は 短時間で高品質な成果 を出すため、時間単価が高くなることが多いという現象を確認。
初心者は 非効率的な試行錯誤 や自己作成の複雑な抽象に苦しむ傾向が強いことを指摘。
専門家は 問題の本質を迅速に特定 し、無駄な努力を避けることができることを強調。
初心者は 自分で作った問題 に時間を費やしがちで、悪循環に陥るリスクが高いという観察。
迷路における専門家と初心者の行動を例示し、 準備や経験の差 が効率性に直結することを示唆。

初心者の苦労と専門家の直感

初心者は 判断材料が少なく、多くの決断をほぼランダムに行うことが多いという現象を説明。
現実世界は 複雑な依存関係 が多く、初心者は複数の関連決断を同時に行う必要があるため、誤りが連鎖しやすいことを強調。
専門家は 経験に裏打ちされた直感的判断 ができ、不要なトラブルを回避する能力が高いことを確認。
初心者は 重要な判断点自体に気づかない ことが多く、外部から指摘されて初めて認識できる場合があることを指摘。
専門家の 判断基準や直感 は言語化が難しく、初心者が観察を通じてパターンを学ぶ必要があることを提案。

専門家ネットワークと初心者の孤独

専門家は 同業者ネットワーク やオンラインリソースを活用し、効率的に情報収集・意思決定を行うことを確認。
初心者は 有用な情報源の見極め やコミュニティへのアクセス方法が分からず、孤立しやすい傾向を強調。
専門家集団の助言 や知見の共有が、意思決定の質を飛躍的に高めることを説明。
初心者は コミュニティ参加やネットワーク構築 の重要性を理解し、積極的に行動することが推奨される。
オンラインチャットやAIも役立つが、 実際の対話や観察 の価値は依然として高いことを確認。

初心者が成長するための提案

初心者は 共感的な専門家 を見つけ、些細な質問でも気軽に相談できる関係を築くことが重要。
複数の専門家に相談し、 知識や負担の分散 を図ることを推奨。
インターネットやAIツールの活用は有効だが、 微妙な判断や長期的な戦略 には限界があることを認識。
自分の取り組みを専門家に見せて助言をもらう ことが、成長の近道となる。
目的のない雑談や相談 でも、新たな気づきや早期の問題発見につながることを強調。

職場における応用とまとめ

職場では 初心者の失敗や非効率 を責めるのではなく、 成長の機会 と捉えて支援することが重要。
専門家のノウハウやネットワーク を組織的に共有し、初心者の学習を加速させる仕組み作りを提案。
一方的な指摘や「もっと上手くやれ」的な助言 は避け、具体的なフィードバックや観察機会の提供を重視すること。
初心者の視点や苦労を理解し、 持続的なサポート体制 を整備することが、組織全体の成長につながる。
専門家と初心者の相互理解 と協力が、効率性と成果向上の鍵であることを再確認。

Hackerたちの意見

誰かと「ただ話す」時間を過ごすことができるのは、すごく大事だよね。特に、うちのジュニア開発者たちとやるのが好きなんだ。彼らは時々質問があるけど、長い間質問がないときもあるから、今何をしているのか聞いてみるんだ。そうすると、彼らが気づかないうちに行き止まりに5マイルも深く入っていることが多くて、一緒に問題を解決するのに1、2時間かけることになる。そういう時間が大好きで、彼らがどんどん質問をしてきて、自信を持って私の決定に疑問を持つようになると、私も自分のやり方を振り返るきっかけになる。お互いに賢くなれるんだよね。もう一つよく気づくことは、何か得意なことがあると、見栄を張ることに興味がなくなるってこと。知らないことを認めたり、AIに聞いたり、適当にやってみて何がうまくいくか試すのに全く抵抗がないよ。これがジュニアたちとの信頼関係を築く助けになるんだ。彼らも私が一歩ずつズボンを履いているのを理解してくれるからね。もちろん、彼らが目の前の明らかなことを理解するのを待つのは時々フラストレーションが溜まるけど、それもすぐにできるようになるから。ジュニアたちと時間を過ごすことを心からお勧めするよ！

└

ジュニアだけじゃないよ。シニアも！彼ら（私たち！）も、気づかずに間違った道を5マイルも進んでしまうことがあるし、仲間と話し合った後にようやく光が見えることもあるんだ。

└

あなたと一緒に働きたいと思わせるような人だね。

└

(author here) 後輩を助けてくれてありがとう。後輩を育てる文化が全然足りないと思うんだ。

└

君が挙げた理由で、若い人を育てるのが大好きなんだ。やりがいもあるし、楽しいしね。仕事に価値を提供するために出勤するべきだって分かってるけど、若い人が目を輝かせて前に道が見える瞬間を見ることには敵わないよ。それに、ある日教えた人が次の日や次の週に新しい知識で大活躍してるのを見るのは、最高の気分なんだ。人生で一番好きな感覚の一つだよ。それを考えると、ほとんどの人が若い人に持ってる逆の見方には本当に驚かされる。なんか「誰かを育てるのはすごくお金がかかるし、スキルを身につけたらどうやって留まらせるの？」みたいな論理があるけど、マジで？誰かに低スキルのままでいてほしいの？それに、もしその人がいる理由がスキルのなさだけなら、それはその職場の問題だよね。俺には全然意味が分からないけど、今はそれを受け入れてるよ。

└

あなたの下で働けたらいいな。ジュニアデベロッパーよりも9devがもっと必要だし、そうすればこの業界はもっと幸せな場所になるよ。

機械の分解や修理は、そういう分野の一つだね。最近見たのは、ブルドーザーの大きなウインチを分解することだった。金属のプレートに2つのボルトがあって、それを外さなきゃいけないんだけど、何も知らずに両方のボルトを外すと、スプリングが後ろにあるからバラバラになってしまう。やり方を知っていれば、まず1つのボルトを外してから、2倍長いボルトを入れて、次に2つ目のボルトを外すんだ。長いボルトが機構をキャッチして、スプリングのテンションを解放して、すべての部品を一か所に保つことができるんだ。

└

それはメーカーのどこかに文書化されていないの？

└

このモデルに合ったプログラミング言語が恋しいな。Dictionary/Mapのハッシュを学んだとき、d := Dictionary newを入力して、d at: 13 put: 42。d at: 5 put: 7。d at: 13 put: 57。ワークスペースでそれをやって、‘debug it’を押したのを覚えてる。現代のプログラミングエコシステムは、こういう発見や探求を通じて学ぶのをすごく難しくしてるよね。

└

(author here) おお、これはいい例だね、好きだな。ソフトウェアは時々すごく抽象的で難しいけど、物理的なメカニズムはもっと直感的だよね。

指導なしの「ウォータークーラー」的な交流、これにはもううんざり。専門家から初心者への知識の移転は、運任せにするにはあまりにも重要なんだ。しかも、事前にピボットしたStackOverflowのおかげで、少なくともホワイトカラーの業界では、どれだけ効率的にできるかのデータもかなりある。専門家がアドバイスをする手間を減らして、1つの努力で書き留めたことから恩恵を受ける人を増やすのは、運任せよりもはるかに良いんだ。

└

何言ってるの？その自由な形の指導なしの交流は、ほとんどの初心者にとってすごく役立つよ。もっと構造的な知識の移転の代わりにはならないけど、重要な補完になるんだ。確かに、自然に複雑な内容を構造化されたコンテンツだけで理解できる初心者もいるけど、そんなのは少数派だよね。> 専門家の直感はしばしば素晴らしいけど、理解しにくいことが多い。この決定を明確に説明できないことが、初心者が専門家と時間を過ごすのが有益な理由なんだ。しばしば、初心者が注意深く観察することで拾えるパターンがあるけど、専門家も初心者もそのパターンをうまく言葉にできないことが多い。それが一部をうまく説明しているよ。ノーベル賞受賞者の大学院生が、ノーベル賞を受賞した教授やその研究室に関連していることが多いのもこの効果だね。構造化された資料を超えた教訓が共有されるんだ。リモートワークは素晴らしいけど、こういう自由な形の個人的な交流を制限することがあるから、すごく貴重なんだ。VRやARがリモートワークでこういう体験を可能にするポテンシャルがあるのが大好きだよ。

└

どちらか一方ではないよ。どんな正式なプロセスや知識管理システムも、時々人々が良い決定を下すために必要なコンテキストを欠くことがないほど効率的ではない。シニアが自分を利用可能にして、存在感を示すことで可能になる非公式な会話が、その不足を少なくとも部分的に補っているんだ。さらに、非公式な会話は両方の当事者に利益をもたらすことができる。現場のコンテキストが不足しているために、どれだけ多くの悪い戦略的決定が下されているか？これはよく研究された問題だよ。最近の私の本「Wholehearted: Engaging with Complexity in the Deliberately Adaptive Organisation」を見てみて。もし現代の解釈よりも原典を好むなら、スタッフォード・ビアが「Brain of the Firm」の続編として「Heart of Enterprise」を出したことに注目してね。この2冊の間で、彼の実行可能システムモデルの最も重要な変更は、この問題に対処することだったんだ。

└

構造化された知識の伝達だけを行うと、専門家が伝えたいと思っていることや、初心者が学びたいと思っていることを伝えることになりますが、それが必ずしも全ての専門知識を網羅しているわけではありません。

└

そうでもないよ。正式な講義が1対1のメンタリングよりもずっと価値が低いのと同じ理由だね。専門家の価値は、事実の束から来るんじゃなくて、あなたの現在のバックグラウンドに基づいて、今すぐに聞くべき事実を見極めて、それをどうやって特にあなたが適用できるように提示するかにあるんだ。話し合うためのやる気のある問題があると、両者が適切に関与するのにも役立つよ。専用のペアリングタイムを設けたり、メモを取るのは何もしないよりはマシだけど、ジュニアをできるだけ早くレベルアップさせたいなら、確実にその水冷器の時間が必要だよ。

└

(author here) 知識の伝達は偶然に任せるべきじゃないし、これを確実に行うための一貫したプロセスがもっと必要だと思う。でも、専門家と初心者がいろんなトピックについてカジュアルに会話することから得られるものもあると思う。ソフトウェアを始めた頃、最も価値のある会話は技術的な会議の後で、部屋を出るときに先輩にXYZの解決策がすぐに却下された理由を聞くことだった。専門家と初心者の間で頻繁にカジュアルな会話を促すことが重要だね。

「一般的な」ことを勉強するのではなく、ニッチな分野に全力を注げ。一般的なことは、メインの活動に関係なく、自然に学べるほど一般的だから。だけど、ニッチなことは積極的に勉強しないといけないし、ニッチを無視すると初心者のままでいることになる。誰もやりたがらないけどやる必要があるニッチなことに取り組むのがいいよ。そうやって私はキャリアを早く進めて、誰も触れたがらないシステムについて詳しくなったんだ。

└

誰も楽しんでいないことに取り組むのはすごく大事だと思います、特に自分がそれを楽しんでいると気づいたら。私は早い段階で、バグをデバッグして修正するのが、グリーンフィールド開発よりもずっと好きだと学びました。新しいプロジェクトに取り組むことを切望するのが一般的なようですが、私がチームにいることで価値があるのです。デバッグは本当に楽しいです、まるで二層のパズルのようです。「この異常な動作の原因は何か？」という即座のパズルがあって、コードを機械的に解剖していきます。報告された故障を引き起こすためにプログラムがどの状態であるべきかを見つけ出します。これが簡単な場合もあれば、難しい場合もあります。また、「このコードを書いたプログラマーは何を考えていたのか？」という二次的なパズルもあります。これが楽しい部分です。根本的な原因は「53行目でFooをBarで掛け算していたが、FooをScrobbleするべきだった」ということではありません。根本的な原因は、誰かがそれが必要だと思ったからであり（PRがあれば、別の誰かがそれを承認した）、その二次的な側面は魅力的です。製品やAPIについての誤解を明らかにすることもあります。また、時には「もし彼らが正しかったら？」と考えるために立ち止まる必要があるので、内省や反省にもつながります。プログラムのバグはすべて学びの機会です。システムの理解を深める機会であり、次回はバグが出ないように手順やアプローチを修正する機会でもあります。AIの進化に関して悲しいことの一つは、もはやその心理学や学びが存在しないことです。「なぜこのように書かれたのか？」という答えは「LLMがそう言ったから」になってしまいます。# そのプログラマーはあなたの過去の自分かもしれませんが、「過去は異国の地だ」と言われるように、他の誰かの過去の心境に自分を置くよりも、自分の過去の心境に置く方が難しいこともあります。

└

(author here) このアドバイスはちょっと裏表があるなって思う。キャリアを発展させるのには絶対に必要だと思うけど、日常の仕事が100%苦痛になっちゃうのは嫌なんだ。手をつけられていないシステムがめちゃくちゃ複雑なら、それを解明するのは楽しいかもしれないけど、もしそれがただの苦痛なら、失業のリスクを取る方がマシだと思う。

この記事は面白くてよく書けてると思います。理論的な部分もあるかもしれませんが、私の個人的な経験と響き合う部分があります。特にこれ：> 専門家の直感はしばしば素晴らしいけれど、理解しにくいことが多い。彼らの決定を明確に説明できないことが、初心者が専門家と時間を過ごすことがとても有益な理由です。私は初心者と過ごすのが本当に好きで、特に彼らがその分野に本当に興味を持っている場合はなおさらです。これは共生的で、私自身の意見や判断にも挑戦を与えてくれますし、みんなにとってプラスになることが多いです。理由を説明するのが難しいのは驚くことではありません。2年の苦労を一文や一段落、あるいは一日かけて語ることができるでしょうか？直接のやり取りは、正確な個人的レベルでの調整を可能にするので、距離を縮めることができます。私たちは過去の経験に基づいて効率的なコミュニケーションのチャンネルを見つけるので、橋を架けるために一から糸を紡ぐのではなく、ほぼ同じレベルを使って両側から築いていくのです。

└

(author here) ありがとう！これが僕の初めてのネットに公開されたものなんだ、こんなに好評で嬉しいよ。> 僕は初心者と過ごすのが好きだなこのエッセイについてのいろんなコメントを読んでると、初心者と過ごすのが好きな人と、そうじゃない人の間に結構はっきりした分かれ目があるみたいだね。

└

どうやって2年分の痛みを1文や1段落、さらには1日のストーリーに収められるんだろう？俺はこれを圧縮されたバイナリオブジェクトで考えるって呼んでる。まるで、考えずに実行する一連の概念みたいなもので、だってそれをめっちゃ頻繁にやってるから。

このエッセイは、私が研究の旅の中で発見した重要なポイントに触れています；専門家の知識の多くは言葉にできないものです[0]。だから、現在の「AI」の問題はここにあります。言葉にできない知識は含まれていないからです。その知識は象徴的に表現されることがなく、表現されたものから推測することもできません。実際、「公式な」ナラティブはしばしば本当の知識を隠しています。これは、専門家システムの分析的引き出し段階[1]が解決すべきだったことです（今では成熟したが、現在は流行りではない「AI」の一分野です）。[0] https://en.wikipedia.org/wiki/Ineffability [1] https://en.wikipedia.org/wiki/Expert_system

この記事に対する反論があります。専門家と初心者の問題解決を考えると、専門家は自分の領域内では非常に効率的なモデルを活用しますが、外に出ると？硬直性が適応を妨げることが多いです。彼らの根付いたパターンは、慣れた領域では資産ですが、未知の領域では認知的負担になります。初心者の直感に反する強みは、仮定がないことにあり、エゴなしで探求するオープンさを育みます。

└

専門家が良いTスキルの形を持ち、新しいシナリオに対して初心者の心構えを持っている場合、これは当てはまりません。

└

これは、専門家が自分の特定の領域に過度に集中しているオーバーフィッティングの例だと言えるでしょう。

└

(author here) 初心者は仮定が少ないっていう点で有利だと思う。> 独立してできること（専門家の監督なしでやるのがベストかもしれない）としては、分野の探求があるよね。何も知らないし、何が役に立つかについてのバイアスもない。深みがありそうなものに出会ったとき、例えばよく書かれたエッセイシリーズや深い技術的なダイブなどには、しっかり投資する必要がある。初心者としての唯一の利点は、すべてが新しくて、誰も君に速さを期待していないことなんだ。だから、できるだけ多くを学ぶために時間をかける余裕がある。専門家をこの点で特徴づけるのが正しいかどうかは分からないけど、相関関係はあると思う。でも、すべての専門家がそんなに堅苦しいわけじゃないよ。

これは本当に良い記事だね。強い開発者には、面接で選ぶのが難しいけど、実際に働き始めるとすごく価値がある特質があると思う。たぶん「根性」って言葉が一番合ってるかな。ジュニアやインターンの面接をする時に、よく聞く質問がこれなんだ。「LinuxとWindowsの2台のコンピュータがあるとして、Windowsの方に50GBのファイルがあって、それをLinuxに移動させなきゃいけない。時間は1時間しかない。どうする？」経験のある人なら、これはちょっとバカげた質問だって分かるよね。未知の要素がたくさんあって、「正解」も無限にある。でもそれがポイントなんだ。学問的に最適な答えじゃなくて、与えられた制約の中でおそらくうまくいく答えを考えることが大事なんだ。ソフトウェアエンジニアリングでの決定の大半にはコストとトレードオフがあるってことを理解して、同僚とそれについて話し合えることは、グラフのトラバーサルよりも10倍価値がある。何よりも、僕は多くの人がそうだったように、コンピュータの前で多くの時間を過ごした人を選ぶようにしてる。親のコンピュータにUbuntuをインストールする時に学ぶ迷路トラバーサルのスキルは、一生残るからね。選択肢があれば、名門大学の名簿に載ってるような優等生よりも、自分で学んだインディー開発者や州立大学の卒業生を選ぶよ。

└

そもそも、どうやってやるの？ ;p

└

おそらく、HDを別のマシンに入れる必要があるね。「根性」なやり方は何かな？

└

これは面白い質問だね。でも「中くらいのファイルを一台のマシンから別のマシンに移動させる」っていうのがまだ面白い質問だっていうのも、我々の業界に対するかなり厳しい批判だよね :P

└

(author here) ありがとう！優しい言葉に感謝するよ。君が言ってるその「しぶとさ」って面白いよね、確かに何かあると思うし、誰かがそれを持ってるかどうかを評価するのに何ヶ月もかけずに考えるのも興味深いよね。

└

Windowsのマシンを持ち上げて、Linuxのマシンの上に置いてください。ファイルは今、Linuxのマシンにあります。

└

すぐに移動しなきゃいけないの？とりあえず、sftpをディスクとしてマウントして、バックグラウンドでコピーすることはできないの？

（著者です）まあ、これがインターネットの仕組みだって分かってるけど、1ヶ月前にここにエッセイを投稿したんだ（https://news.ycombinator.com/item?id=43664345）けど、静かに死んじゃった。コメント読むの楽しみ！でも、インターネットって時々理解不能だよね。

└

HNの新しい投稿は、通常20〜30分間新着ページに表示されて、その後は下に落ちちゃうんだ。その時間帯に誰かが気づくかどうかは運次第だよ。

いい記事だね、すごく楽しんで読んだよ。ドレイファスモデルの学習についても言及しないといけないね、これがよく関連してると思う。これを読んでるときに気づいたんだけど、> 専門家の直感はしばしば素晴らしいけど、理解しにくいことが多い。彼らの決定を明確に説明できないというこの能力の欠如が、初心者が専門家と時間を過ごすことが有益な理由なんだ。しばしば、初心者が注意深く観察することで拾える基盤となるパターンがあるんだけど、専門家も初心者もそのパターンをうまく言語化できないことが多い。俺は今、プログラミングキャリア20年目だけど、長い間これが真実だと信じていて、ある意味で「最終的な」マスタリーの段階だと思ってた。でも、専門性を超えたマスタリーの段階（もしくは段階があるかも？）があると思う。ほとんどの答えが直感で素早く出てくる段階だね。「実践者 vs 教育者」ってことに帰結すると思う。すごく優れた実践者で、自分のやってることに間違いなく専門的な人もいるけど、彼らに自分のことを説明させると「正しいって分かってるけど、どう説明すればいいか分からない」って状況にぶつかるんだ。これって、その人が優れた教育者ではないからだと思う、これは別のスキルだからね。同様に、実際の条件で実行を求められたときにうまくいかない優れた教育者にも出会ったことがある。これが、「優れた実践者と優れた教育者」の組み合わせが最も珍しい存在だと信じるようになった理由だよ。この能力を持ってる人に出会ったことがあるけど、10倍のエンジニアとは呼べない、100倍か1000倍のエンジニアだね。

ハクソク