どうも、私です。
眠れないので最近考えていることを書きます。まとまりはないです。

私は比較的幼い頃からコンピュータ漬けの日々を送ってきた気持ちの悪いオタクですが、大したスキルも獲得しないまま大人になってしまいました。
一方で世の中を見渡すと、大半はコンピュータのイロハも分からない人ばかりで、少し扱えるだけで詳しい人であるかのような扱いを受けます。実際、それで得意になっている部分もありますし、同時に、実際は分からないことだらけである現実に焦りと罪悪感を覚えています。

TwitterやMisskeyのTLを眺めていると、私にはとても理解できない高度な話をしている方々がいます。
羨ましいですし、憧れに近い気持ちがあります。実際、私には理解できなさそうな難しいことを難しそうに話す姿に惹かれてフォローした方もかなりいます。逆に、初歩的なことをわかったように断定する人は苦手です。見ていて不快だからというのもありますが、それ以上に、私が優越感を覚えるような状況をそもそも発生させるべきではないと考えているためです。

現実として、私は指折りの優秀な技術者ではありませんし、人格者でもなければ、世間で広く知られるような有名人にもなれません。おまけに怠惰なので努力も苦手です。
ただ、それ以上に私が恐れているのは、自分よりできない人ばかりを見ているうちに、相対的な位置を能力と勘違いして、さも優れた人間であるかのように錯覚してしまうことです。放っておけば、私だって誰かに優越をひけらかすようになってしまうかもしれません。

であるから、せめて自分よりすごい人の言葉で世界を埋めつくしたいと思います。傲慢な話ですが、そこに流れてくるものは私が学ぶ必要のあるものばかりで、それを理解しようとすること自体が、最底辺にいる自分が這い上がるために必要な行為になります。おそらくそれがモチベーションでもあるのかもしれません。

例え話をしましょう。
私はKubernetesを知っています。仕事では前任者の残していったクラウドと(無駄に巨大な)オンプレに跨った構成の複数クラスタを管理していましたし、今も自宅でクラスタを動かしています。構成は全てGit上で管理していて、一式を一人で運用していると言えば、まあそれなりに詳しい人に見えるはずです。(ですよね？)

が、私はこれらを理解していません。恥ずかしい話ですが。

このクラスタがどうやってできたかと言えば、その場で動かすことを目的として、調べて調べて試行錯誤を繰り返した結果のものになります。私の知り得ることのほぼ全ては何かしらのドキュメントに書いてありますし、何かが壊れれば、kubectl describeでEventsを眺めて、エラーメッセージで検索して、GitHub issueの下の方に貼られた何か解決してくれそうな気配のあるworkaroundを適用します。すると不思議なことに直ります。なぜそれで直るのかは分からないまま、直ったのでコンソールを閉じてしまいます。

では一体私はKubernetesの何を説明できるのでしょうか。
なぜPodごとにIPを配るフラットなネットワークを敷き、Pod間のNATを禁じたのか。前身のBorgがホストIPを共有させ、ポート番号を割り当てて凌いでいたことの何がそんなに苦しかったのか。コントローラが通知の取りこぼしを前提に、イベントではなく現在の状態そのものを見に行くlevel-triggeredな設計になっているのはどんな故障モデルを置いているからか。List-WatchとresourceVersionは、どんな整合性とスケーラビリティのトレードオフから生まれたのか。なぜコントローラは古い状態を読む可能性まで受け入れて正しく収束できるように作られているのか。
どれも、動かして運用する分には知らなくて済むことで、実際、私は簡単に答えられません。
Podが今日も健全に通信できているのは、私の理解の成果ではなく、CNIが私の根本的な理解とは無関係に正しく動いてくれているためです。

結果として手元に残ったのは、なんか動いているクラスタと、わかった気になっている私です。運用のノウハウは溜まりましたが、これは資産というより負債だと感じています。次に何かしらのトラブルが発生したとき、おそらく私はまた検索から始めるでしょうから。

結局のところ、場当たり的に習得できてしまうようなすぐに役立つ知識は、どこまで行っても場当たり的なものに過ぎず、何にもなりません。

ここで言うすぐに役に立つこととは、あるツールの使い方だとか、そのツールで何ができるだとか、そんな感じの浅くて平たい非本質的な知識のことを意図しています。ただし、パラメータとして役に立つか立たないかの極端な二値ではなく、段階的な深さのある話であるとは思いますが。

例えば古典的なリレーショナルデータベースだと、CREATE INDEXをつけると検索が速くなります。今時誰でも知っているような当たり前の知識ですが、これを知ることによって、今からすぐに役立てることができます。
もう少し深堀ると、実態はB-Treeで、探索が対数時間で終わることをアルゴリズムごと説明できるようになります。ですが、ここまで来ても結局は仕組みを覚えただけに過ぎません。
もっと深掘って、なぜ二分探索木ではダメで、ハッシュテーブルでもダメなのか。ストレージへのアクセスがページ/ブロック単位になり、ランダムI/Oのコストが高い中で、1ノードに多数のキーを持たせてfan-outを大きくし、木を浅くする選択を行った。この設計上の制約とトレードオフから今の形を再構成できる段階まで来て、はじめてその技術を実態を伴って理解したと言えるはずです。

すごく難しいですが、そこまで行こうとする姿勢こそが技術者に求められている(べき)ものなのだろうと私は考えています。

では低レイヤな領域や学問としての計算機科学をやればいいのか、というとそういう話でもない気がします。結局、システムコールであれ命令セットであれプロトコルスタックであれ、全て単純な使い方として覚えることができてしまうためです。それは見識を深めたのではなく、ただ単に横に移動しただけで、新しいフレームワークを追い回して驚いているのと同種の、すぐに役に立つことの一つに過ぎません。レイヤの上下(深浅？)と理解の深さはそもそも別の軸にあると思います。

汚い表現ですが、私が学びたいのは携わった人間のエゴそのものです。この技術を作った人はどんな問題を解こうとして、なぜ他ではなくこの仕組みを選んだのか。それを自分の言葉で説明できる状態を、私は理解と呼びたい。そして、そこまで深堀した知識のみが汎化できるのだと思います。B-Treeを選ばせた制約を頭の片隅に置いておくことで、LSM-Treeが何を捨てて何を得たのか理解できるでしょう。特定のツールの流行り廃りと無関係に、生涯ずっと役に立つ、けれどすぐには役に立たない有用な知識です。

同様の理由から、ハーネスエンジニアリングがなんだとか、ループエンジニアリングがなんだとか、似たようなことを手を替え品を替え驚き続けている人たちが苦手です。あれはすぐに役に立つことに毎回驚いているだけで、驚きは理解の代わりになりません。

すごく傲慢ですが、私は正しく物事を理解したいと願います。切実に。