- 現代の技術システムは、あまりにも複雑で一個人が全体を理解できない構造へと発展してきた
- ソフトウェア開発とAI活用が増えるにつれ、開発者が内部メカニズムを理解しないまま構築する事例が増加している
- Simon Wardleyは理解なしにシステムを作る危険性を、Adam JacobはAIが開発手法を変えつつあることを、Bruce Perensは複雑性がすでに限界を超えていることを指摘する
- Louis Bucciarelliは電話システムの事例を通じて、技術が複数の層で絡み合っており、誰も完全な理解には到達できないことを示す
- この記事は、AIがこの複雑性を深める一方で、実際には人間はずっと以前から部分的な理解の中で技術を扱ってきたことを強調している
技術の複雑性と理解の限界
- Twitterの衰退後、LinkedInでは技術理解と複雑性に関する議論が活発に行われている
- Simon Wardley、Adam Jacob、Bruce Perensの投稿が相互に関連するテーマとして紹介される
- Wardleyは基礎原理を知らないままシステムを構築する危険性を警告する
- 「Magic」という表現は内部動作を隠すフレームワークを批判的に指し、Ruby on Railsが代表例として挙げられる
- JacobはAIがソフトウェア開発のやり方を根本的に変えつつあると指摘する
- AIは効率を高める一方で、開発者が下部構造を理解しないまま作業する傾向を強める
- PerensはWardleyが懸念した状況はすでに現実になっていると述べる
- 現代のCPUとオペレーティングシステムの複雑さにより、多くの開発者が実際の動作原理を誤って理解している
Louis Bucciarelliの「電話機」の事例
- Bucciarelliは1994年の著書 Designing Engineers で、技術的リテラシーの限界を論じている
- ほとんどの人は電話機の動作原理を物理レベルで説明できない
- 通信網のルーティング、信号処理、衛星伝送、企業運営、規制構造など多層的な要素が絡み合っている
- 彼は「誰も自分の電話がどう動いているのかを完全には知らない」という結論に至る
- これは複雑な技術システムが人間の完全な理解を超えていることを象徴している
技術面接と「知識の限界」
- 著者はNetflix勤務時代のBrendan Greggとの会話を振り返る
- Greggは面接で応募者の知識の限界と、それにどう反応するかを評価していたという
- 彼は「誰もシステム全体を完全には理解していない」という事実を前提に面接を行っていた
- このアプローチは、知らないことを認める姿勢が技術的能力と同じくらい重要であることを示している
複雑性の本質とAIの影響
- Wardley、Jacob、Perens、Bucciarelliの見解は、それぞれ異なる層で複雑性の不可避性を示している
- Wardley: 理解なき構築の危険
- Jacob: AIがもたらした効率と距離感
- Perens: すでに存在する複雑性の現実
- Bucciarelli: システム全体理解の不可能性
- この記事はAIがこの問題を深刻化させるだろうと認めつつ、部分的な理解の中で技術を扱ってきた人類の長い現実を思い起こさせる
読者議論の要約
- コメント欄では、AIが学習と理解を弱めるという懸念が多く示されている
- 一部では「LLMがコードを代わりに書くことで理解の連鎖が断ち切られる」と指摘される
- Wardleyは「以前は階層的なチェーンの中で理解が維持されていたが、LLMはそのチェーンを取り除く」と説明する
- 別の読者は「AIの利点がリスクより大きいと断定するのは早計だ」と反論する
- 全体として、AI時代における技術理解の喪失と学習の断絶が主要な論点として浮かび上がっている
1件のコメント
Hacker Newsの意見
最近のプログラミングで気になるのは、上の層（製品の目的）も下の層（実装方法）も分からない 「中間層開発」 が増えていること
昔はビジネスを知らなくてもコードの意味は理解していたが、今ではコードがどう動くかすら知らなくていいという空気がある
Claudeを使っていると、だんだん 状況認識能力 が落ちていく感覚がある。テストが通ってボタンが押せれば終わり、という開発文化の中で、もう自分には学ぶことも貢献することもない存在のように感じる
特に大企業ほど透明性が低い。締め切りに間に合わせるために残業したのに、自分にだけ知らされず日程が延期されていたこともあった
もし自分が単なる道具として扱われるなら、その役割だけを果たす。だが本当にオーナーシップを求めるなら、意思決定のテーブルに着く席が必要だ
以前は反復的な設定作業に時間を無駄にしていたが、今はコア機能にだけ集中できる。そのおかげで頭の中に全体構造をよりよく保てる
たとえばIDEで数行を選んでから音声で「この部分をこう変えて」と言えば即座に反映されるような形だ
速度が十分に速ければ、マウス＋音声制御は アクセシビリティツール としても優れていると思う
LLMはむしろこうした複雑さを減らしてくれるかもしれない。自分は適度な抽象化は好きだが、中身をまったく知らないのは嫌だ
この記事は、人々が内部を知らないまま 抽象化（abstraction） を使う現象についての話だ
だがそれは自然な発展過程でもある。誰かがその抽象化を設計し、上の層で使えるようにしてくれた
「自分はWi-Fiドライバを知らないのだからコードも分からなくていい」という理屈は成り立たない
昔は「必要な複雑さ」を自分で扱いながら思考力を鍛えたが、今は単にパイプ役になっていることが多い
解決策は、汎用言語の代わりに DSL（ドメイン特化言語） で抽象化を包むことだ。SaaSならAPI-firstよりDSL-firstの方がよいと思う
AIがそれよりひどいとは思わない。重要なのは、自分が土台としている抽象化を理解することだ
依存関係ツリー が実際には最も大きな問題を引き起こしている
Node.jsプロジェクトを見るだけでも数百の依存パッケージがある。たいていは中身を知らなくても問題ないが、インターフェースが頻繁に壊れると危険になる
チームがEOL（サポート終了）や脆弱性を追跡していないことも多い。「これはまだ保守されているのか？」すら分からないのが現実だ
だがAI以前から、すでにバージョン衝突による 依存関係地獄 に陥ったプロジェクトは多かった
人はすべてを知る必要はないが、基礎を失う無知 は危険だと思う
料理でいえば、小麦を育てる必要はなくても、卵を焼く方法すら知らないのは問題だ
企業がすべての食べ物を標準化して調理してくれるなら、それは進歩なのか退歩なのかという問いだ
いつかロボットが食料生産を完全に置き換えるなら、料理法を知らなくても構わなくなるだろう
依存を避けるために材料科学まで知っている必要はないだろう？
CPU命令やキャッシュのような下位層は、何十年にもわたって 検証と文書化 が徹底されてきた
一方でLLMが作るコードはそれほど信頼できず、明日にはリファクタリングが必要になるかもしれない
自分は下位層の詳細な動作は知らなくても、自分のコードがどう動くかは理解している
下の層を知らないことと、自分の責任範囲を知らないこと はまったく別だ
今は 誰も分からないコード片 が生まれることこそ本当の危険だ
AIが状況をさらに悪化させているという主張には同意しない
むしろLLMはほぼあらゆる知識を学習しているので、「電話はどう動くのか？」のような問いにも 体系的に説明 できる
人間には「何を知らないのかすら分からない」という限界があるが、LLMは言語で表現された知識ならほぼ扱える
もちろん推論やコード生成は弱いが、知識を統合する能力 は人間より優れている
本物の文書の代わりにはならない。ただし人間のように「何を調べるべきか」を教えてくれる点では非常に有用だ
良い設計とは、全体を知らなくてもシステムが動く ようにすることだ
問題はAIが作ったシステムそのものではなく、私たちがその 失敗モードと限界 をまだよく分かっていないことだ
結局のところ、人間とAIをどう調整して必要なシステムを作るかという 組織的設計能力 が核心になる
自分はコンピュータの内部を完全に知っているわけではないが、実用的な スクリプト自動化 で問題を解決している
x86アセンブリを学ばなくてもPythonでインフラを管理できる
だが経験豊富な開発者には、その知識を 共有する責任 があると思う。自分もいつかその役割を引き継ぎたい
好奇心を失わず、先輩開発者たちと積極的に対話すべきだ
だが 基礎理解の重要性 をどれだけ強調しても無視される現実にはもどかしさを感じる
「URLを入力すると何が起こるのか？」のような問いにも実際に答えられる
自分は米海軍の 潜水艦原子炉技術者 として働き、電子理論からシステムのトラブルシューティングまで学んだ
その後ITへ転じてからも、同じ姿勢で文書と実験を通じて最後まで掘り下げてきた
こうした習慣のおかげで、問題解決では ランダムな知識のつながり が大きな助けになる
VMEbusのWikipedia記事 も参考になる
ただ、自分は 分からないことを放っておけない性格 なので、おそらく例外的なケースだろう