私たちはあまりにも多くの抽象化レイヤーを使ってきた
(unixsheikh.com)- 技術業界では、ツールや自動化の使い方だけを身につけた人が増えるにつれ、下位レイヤーの動作原理を理解する技術的な深さが弱まっている
- 抽象化はハンドルやパワーステアリングのように作業を簡単にするが、故障や障害が起きたときに内部を知る人がいなければ復旧能力が低下する
- 迅速なリリースとコスト削減の圧力は、DevOps・DevSecOpsのように複数の役割を一人に集中させ、より多くの自動化と、より少ない深い理解につながる
- セキュリティ分野では、GUIベースの侵入テストツールの青信号だけを信じた結果、実際の侵害が長期間発見されない状況が起こり得る
- 技術を学ぶ人は流行だけを追うのではなく、ツールが代替している作業を自分で試し、コードや下位レイヤーを掘り下げるエンジニアとしての姿勢を保つべき
抽象化が覆い隠す技術理解の空白
- 今日、多くの「専門家」はツールの設定方法は知っていても、技術がより深いレイヤーでどのように動作しているのかを理解していないという問題がある
- 抽象化そのものは必要である
- ハンドルは自動車の運転を簡単にする抽象化である
- パワーステアリングは運転体験をさらに改善する別の抽象化である
- 問題は抽象化が壊れたときに露呈する
- 内部技術を理解している人がいなければ、壊れたレイヤーを直すのは難しい
- ツールが正常に見えても、実際のシステム状態を判断できないことがある
- 技術業界は収益とリリース速度に強く押されて動いている
- その結果、より多くの抽象化と自動化が導入される
- より少ない人数がより多くの仕事を担うようになる
- 深い理解よりも、特定のツールの使い方が重視される
- 従来のプログラマーとシステム管理者の役割は、DevOps、DevSecOpsのように、開発・セキュリティ・運用を一人の職務に入れ込む方向へ変わった
- 一人が開発、セキュリティ、システム管理のすべてを完全に習熟するのは難しいため、できるだけ多くの作業を自動化するようになる
- その結果、現代の技術人材は特定のツールの使い方は学んでいても、内部技術についてはほとんど知らない場合がある
技術を学ぶ人に必要な姿勢
- 現代生活は技術に大きく依存しているが、技術そのものはますます理解しにくくなっている
- セキュリティ分野でも、既製の侵入テストツールの使い方だけを知っていて、セキュリティ自体はよく知らない人が多いという批判がある
- ツールのWeb GUIに青信号が表示されれば、すべて問題ないと仮定してしまうことがある
- 実際の攻撃者がすでにシステムを突破し、データをdarknetで売っていても、流出や侵害が発見されない可能性がある
- 一部の学生がファイルやフォルダの概念すら知らないという事例として、Slashdotの記事がリンクされている
- 技術を学ぶ人に必要な実践は次のとおり
- 流行やトレンドだけを追わない
- ツールだけを学ぶのではなく、基盤技術がどのように動作しているのかを理解する
- 可能であれば、設定ツールが代わりに行っている作業を一度は手動でやってみる
- 可能であれば、ツールのコードを見てみる
- 学び続け、実験し、関心のある技術をより深く掘り下げる
- 可能であればhomelabを作り、学び、壊すための遊び場として使う
- 理解できないことは質問し、誰かが自分よりよく知っているとデフォルトで仮定しない
- すべての人がすべてを第一原理から理解すべきだとか、ツールを使ってはいけないという意味ではない
- 抽象化は必要である
- トラック運転手が運転し、整備士がトラックを修理するように、専門分野は存在する
- 核心的な問題は、技術を扱う人が持つべきエンジニア的な姿勢が弱まっていることにある
- ソフトウェア開発では、あまりにも多くの専門家の役割がツールと自動化に置き換えられている
- ますます少ない人しか、自分が作業しているレイヤーのすぐ下のレイヤーさえ理解していない
- Web開発者がTCP/IP、DNS、HTTP、TLS、セキュリティ知識なしに、既製のツールやフレームワークだけでサイトを作ると、問題が起きたときの有用性は大きく低下する
1件のコメント
Hacker News の意見
航空の歴史にも、飛行機を操縦できる人が設計や製作までできた時期があったし、そのころも機械の第一原理を本当に理解していない人がコックピットに座る未来を心配していたのか気になる。
今では操縦と製作は別々の技術・職業だという考えに慣れているし、航空エンジニアがボーキサイト採掘やアルミニウム製錬を知らなくてもよいことも自然に受け入れている。
論理ゲートから Web リクエストまで全体の経路を見渡せれば安心ではあるが、必須ではない。そうした概観を持つエンジニアが減っているのは警告サインというより、技術産業の成熟と分野の分化を示す現象に近い。
たとえば「みんなでアセンブリに戻ろう」といった話でも、高級言語が主流になった後もしばらくの間、プログラマーはアセンブリを知っている必要があった。C や Pascal で大半の作業をしていても、コンパイラやデバッグツールの抽象化が漏れていたからだ。
今日の問題は、成熟する時間を与えないまま漏れのある抽象化を何層にも積み重ねていることにある。開発者が常にハッピーパスにいるという誤った前提のもとで作業時間を短縮する方向に設計するが、実際の時間の大半は設計どおりにいかない状況をデバッグすることに費やされる。ハッピーパスを速くする代わりにアンハッピーパスを遅くすると、たいていは純損失になる。
Airbus の自動化は、何かが大きく間違って手動法則に戻らない限り失速をほぼ不可能にするため、彼は失速がどのように起きるのかをきちんと理解していなかった。その飛行でまさにそれが起こり、機長がコックピットに戻ったときにはすぐ深い失速だと気づいたが、すでに遅すぎた。
関連する Mentour Pilot の動画: https://invidious.protokolla.fi/watch?v=e5AGHEUxLME&t=1
飛行のプロセスには最初から物理的な限界があるが、コンピューティングとそれを考える枠組みは果てしなく可変で、適用範囲も広い。最近売られているたわごとを航空の比喩に置き換えるなら、飛行だと言ってロバ乗りを売っているようなものだ。顧客のかなりの数は、その違いを見分ける知識を持っていない。
進歩に重要な要素は、何かを単純にする方法を見つけたときにだけ、その基盤の上で大きく飛躍できるという点だ。複雑になりすぎると、進める距離や到達できる高さに限界が生じる。技術的負債を人類規模に拡大したようなものだ。
残念ながら私たちは、歴史の中で何かが一段階単純になった瞬間をうまく見抜けない。振り返ると自然に当たり前に見えるからだ。
最近の子どもたちは十分に評価されていない気がする。数週間前、友人の息子が友だちと作っていたRoblox ゲームを本当に楽しそうに見せてくれた。
カナダの感謝祭で家族や知人が大勢いたのだが、彼はそれぞれが興味を持ちそうな部分をすでに選んでいて、私は「Lua を見せる相手」だった。
人々は、スマートフォンやノートパソコンがロックされていて好奇心を刺激しないから子どもたちもそうなのだろうと思っているが、むしろ大人のほうが好奇心を失っているように思う。
もちろん抽象化の上に成り立ってはいるが、高い抽象化の山々の間にも、好奇心旺盛な少数が入り込む谷は常にあった。C64 BASIC はどんなメモリアドレスにも POKE できるようにしてくれたが、10 歳の子どもから FPS 要素のある複雑な 3D コレクションゲームの説明を聞くのも、かなり素晴らしいことだ。
雲に向かって怒鳴る老人のような雰囲気だ。
ある人は専門家で、ある人はそこそこできる程度だというのは、別に新しい話ではない。この短い文章の半分を自慢話に使っている筆者のように、誰もが救世主になれるわけではない。
この記事は抽象化とはほとんど関係がない。筆者は最初の 2 段落の後で、自分の論点への興味を失っている。
例もひどい。「誰かが現代的なフレームワークを使ってハッキングされたが、性能問題はハッキングのせいではなく、そのフレームワークがひどく遅かったせいだった」というのだが、どのフレームワークだったのか、diff を見ただけでどうやって遅いとわかったのか、ツールを性能に合わせて調整できないことが抽象化と何の関係があるのか、わからない。
もう一つの問題は、私たちが何度も誤った抽象化を採用してきたことだと思う。今日のソフトウェア業界には、歴史の終着点にたどり着き、すべてを理解したと信じている傲慢な単一文化がある。
実際には、近年の技術のかなり多くで間違った道に進んできたのだと思う。2014年ごろまではすべてが正しい方向に進んでいるように見えたが、その後は進歩が後退し、誰もが同じ誇大宣伝されたフレームワークを使い始めたように感じる。企業がこうしたフレームワークを全員に押し付けることで、ソフトウェア開発は非効率で士気をくじくものになった。
私は個人プロジェクト用に使うSDKを作ったが、会社の仕事で使っていた主流フレームワークより少なくとも10倍は生産的で、コードもはるかに読みやすく保守しやすい。フレームワークを知らないジュニアに見せても、生産的に作業できるほどだ。このSDKでノーコードBaaSプラットフォームをパートタイム2か月で作ったが、主流のツールやフレームワークでは、私でも他の誰でもフルタイム12か月以内に作るのは難しかったと思う。
もちろん他のフレームワークより優れた点があるかもしれないが、慣れは専門性を生み、専門性は生産性を生む。
石膏ボード用ねじが普及する前の熟練作業者の多くは、ねじのほうが遅くて劣っていると確信していたが、釘打ちの専門家もねじ作業の専門家も、どちらも作業を速くうまく終える。
フロントエンドであれバックエンドであれ、私たちが「これらのフレームワーク」を使うのには理由がある。その理由が気に入らないことはあるかもしれないが、エンタープライズ開発では言語の純粋性だけでなく、採用しやすさ、保守性、継続性など、収益につながる要素が重要だ。
会社があなたのカスタムSDKを使っていて、あなたが去ったらどうなるのか。他の人に簡単に教えられると思うかもしれないが、会社の技術判断にはそれよりはるかに多くの要素が関わる。
「最近のいわゆる専門家の多くは、流行りのツールを設定する方法だけは知っているが、より深いレベルで物事がどう動いているのかはまったく理解していない」という言葉が強く刺さる。
みんな「Xをするには設定ファイルにこの行を追加せよ」のような暗記式の手順は知っているが、Xとは少し違うこと、あるいはXの変種をやる必要があるときに台本から外れる方法を知らない。さらに悪いことに、人々が会話を not-quite-X から再び X に戻そうとして時間を浪費させる。なくした財布を街灯の下だけで探すたとえを思い出す。
ごく狭い知識だけでも貢献できる技術エコシステム、一種の「techosystem」を作ったのは素晴らしいと思う。あまり前向きでない言い方をすれば、会社がより少ない技術だけで済む、より安い労働力を雇えるようになったということでもある。
多くの場合、平凡な解法は解法がまったくないよりましだと信じている。1995〜2005年のインターネットは平凡な解法の上に作られていて、本当に面白かった。
深く掘り下げる専門家は絶滅危惧種でも、抽象化以前の時代の秘密知識を持つ限られた資源でもない。むしろ今のほうがかつてないほど多い。彼らはスタックの上から下まで経験したかどうかで定義されるのではなく、自分の階層ではない場所まで覗き込む好奇心によって定義される。
上に抽象化レイヤーが追加されるだけでなく、下のレイヤーもNVMe、WebGPU、WebAssembly、QUIC、AVX512のように変わっているからだ。
ただし、深く掘り下げる専門家はほとんどのチームにとって不要な贅沢であり、技術マネージャーにとって最も重要な能力の一つは、いつ必ずそういう人を採用すべきかを知ることだと思う。
抽象化レベルの増加は必要だ。人間の脳が年々はるかに有能になるわけではない一方で、利用可能なツールの数は増えるので、集中するには抽象化が必要になる。
それがただちに未来が暗いという意味ではないと思う。ビジネス上の問題を扱うプログラマーは、EUV、コンパイラ、アセンブリ、命令セット、カーネル、USBプロトコル、HTTP、ダイ、基板などを知らなくても、高級言語で非常に生産的でいられる。パイロットも空気力学、引張強度、アルミニウム、ゴム、GPSなどをすべて知る必要はない。
ただし、現代社会のインセンティブの不一致は十分に議論に値する。私はパイロットを、ビジネスソフトウェア開発者、研究者、銀行家よりも概して信頼している。墜落すれば、パイロットが最初に現場に到着するからだ。
投石機用ソフトウェアには、あなたが持っている豪邸の数のようなものを公開する過度に一般的なCRUDアプリとは異なるアプローチが必要だ。
世の中には愚かなソフトウェアが多く、それで構わない。多くの「本当の問題」もかなり愚かで、英雄的なエンジニアリングを必要としない。
恐ろしいほど多くの場合、ただ適当に貼り合わせたでたらめなソフトウェアで十分だ。
私も嫌だが、自分の優れたエンジニアリングで事業を自ら作り、競争に勝って彼らが間違っていることを証明するか、さもなければ自分が雲に向かって叫んでいるのだと受け入れるしかないのだと思うようになった。
病院は購入判断をする際、「このボタンが押せない」程度を少し超えるくらいのこと以外、ソフトウェア品質を確認しない。
抽象化を批判する記事が「最近の学生の中には、ファイルやフォルダが何かすら知らない場合がある」という文にハイパーリンクを張っているやり方が、妙に適切だ。
そのリンクはSlashdotのスレッドに行き、そこからPC Gamerの記事につながり、その記事はVergeの記事を言い換えてリンクし、Vergeの記事はStack Exchangeの質問につながる。
言い換えると、これはカーゴカルト・プログラミングだ。2年前にこの件について記事を書いたが [1]、反応は全面的に同意するか、ゲートキーピングだと激しく攻撃するかに二極化した。
好きな技術に深く投資しているエンジニアたちの職業的な免疫システムを刺激せずに、この病を治すもっとよい方法があればいいのだが。
[1] https://medium.com/the-engineering-manager-guide/cargo-cult-...
2人は質問を理解していなかったのに、彼は質問を明確にしたり、問題が質問の側にある可能性を考えたりもしなかった。
「React.js の専門家に、直接的な DOM 操作、MVC ベースのクライアントサイド・テンプレート、コンポーネントベースの DOM 操作、バニラ JS にコンパイルする方式といったさまざまな SPA アプローチを比較してもらった」という文は、正直私にも何を意味しているのか分からない。
「バニラ JS にコンパイルする」というのが TypeScript を JavaScript にコンパイルするという意味なのか、それが DOM と何の関係があるのか分からない。「MVC ベースのコンポーネントベース DOM 操作」というのも変だ。デザインパターン本を読んで、自分と同じ用語を使わない人を減点する人のように感じられ、開発をより深く理解している人には見えない。
仕事をうまくやり遂げたときの満足を本当に楽しむ人は、単に仕事を終わらせたいだけの人よりも、たいてい何かを本当に理解しようとしてより多くの時間を使うと思う。
しかし、その好奇心は私たちに何をもたらすのか。fortune(6) のこの逸話を思い出すし、好奇心のない人のうちどれほどが理解するのか気になる。
ある初心者が、故障した Lisp マシンの電源を入れ直して直そうとしていた。Knight はその様子を見て厳しく言った。「何が悪いのか理解もしないまま電源を入れ直すだけでは、機械は直せない。」Knight は機械の電源を切って入れ直した。機械は動いた。
「あなたはゲートキーピングをしている、だから私の勝ちだ」というような決め手として使われるが、ばかげた考えだ。高い専門性の基準を擁護することに間違いはないし、それこそが本質的にゲートキーピングだ。医者にかかるとき、医学がゲートキーピングされた職業であることを非常にありがたく感じる。