2026年1月1日。
最近は year++ とは書けないらしい。
進歩とは何かを考え込んでしまう、Abyss Brave Company の Abe だ。一応、社内では CTO という肩書きを名乗っているが、実態はただの旧型エンジニアである。
便利になりすぎた現代の開発環境は、誰が書いても安全で均一なコードを量産する一方で、エンジニアから リソースを直接扱っているという手応え を静かに奪っていった。
抽象化され、保護され、整えられたその環境は、確かに多くの人を幸せにした。だが私は、その過保護なゆりかごの中に、どうにも拭えない居心地の悪さを感じ続けている。
今の私を突き動かしているのは、その安全で均一な世界を否定したいという高尚な理念ではない。ただもう一度、コードとハードウェアの距離が近かった頃の感触を、この手で確かめたいという、旧型エンジニア特有の、極めて不純で、しかし正直な衝動だ。
この違和感は、やがて「何を書くか」だけでなく、「何を使って書くか」という道具の選択にまで及んでいく。
最近の若い人たちは、なんでもビジュアルスタジオコードだかなんだかいう、コードを一行書くたびに「これじゃないか？」「あれじゃないか？」と横から口を出してくる画面でプログラムを紡ぐらしい。
まるで、開発標準 という名目で現場に常駐する、近所のお節介なおばさんのようだ。
便利なのはわかるが、我々のような人種にとっては、己の記憶力とコンパイラの怒号だけが道標となるストイックな空間 こそが理想なのだ。
おばさんは、善意でやってくる。
だが、帰るタイミングだけは誰も教えてくれない。
昔は Emacs 派 だった。C-x C-s は今でも反射で指が動く。
ただし、使いこなす前に小指が壊れたので Vim に転向した。
あれは宗教的対立ではなく、単なる身体的敗北 だった。
正しさより、楽な逃げ道を選んできた人生だったのかもしれない。
今日、私は決めた。
2026年、私は Rust という「現代の矯正ギプス」を装着し、格闘することにする。
かつて「JavaのAbe」と呼ばれた男の、虚無な生産性
私の IT エンジニア人生は25年以上にもなる。
前職の役員からは「JavaのAbe」なんて呼ばれていた時期もあった。
当時は、たった一つの機能を実装するのに「将来の拡張性のために」と、UserDataAccessObjectFactoryImpl だの AbstractSingletonProxyFactoryBean だのをいくつも作り、結局一度も拡張されないままプロジェクトを終える。そんな「Javaの様式美」に酔いしれていた。
で、超すごいオブジェクト指向設計でひと仕事終えた後は、事務のお姉さんばりの超高速タイピングか、何度目かの究極の再発明 「VBA で Excel から自動生成」 か、とにかく手段を選ばず getter/setter を量産し、激重 Eclipse を固まらせては「ふぅ、今日もたくさんコードを書いたぜ……」とタバコを吹かす。今思えば、単なる「行数を稼ぐ作業」に酔いしれていただけのタイピング職人だった。
そしてその仕事は、いつしか Lombok とかいうプラグインに奪われた。
OOP から AOP へ。Java は中途半端に関数型言語の流行りを取り入れながら、アノテーションをうまく貼る言語へと変わり、オフィスに響き渡っていた私のハードパンチ音は、誰にも必要とされなくなり、Java の Abe はひっそりと転職した。
「ベテランC++使い（という設定）」の焦り
そんな ISDN テレホーダイ世代の私が Web 2.0 やら iOS やら Android やら SaaS やらの紆余曲折を経て今、社内唯一の C++ 使いとして レジェンド （・・・化石？）扱いされている。
C/C++, VB/VBA, PHP, Java, JavaScript, Objective-C/Swift, Python, Kotlin ……一通りの修羅場はくぐってきたが、実は C++ の実務経験は通算で6年（サバを読んだ。本当は4年だ、化石ですらもない）。
今の職場では、C++ の話題になると自然と私の方を見られる空気に甘えて、ベテランネイティブプログラマー のフリをして生き延びている。だが、内心は冷や汗の連続だ。
C++11/14 あたりから雲行きが怪しくなり、最新の C++23 に至ってはもはや未知の言語。
顧客の前で「あー、その仕様ね、モダンだよね」「そろそろ使ってもいいかもね」と知ったかぶりをしながら、裏で必死に ChatGPT で仕様を検索する……そんな綱渡りのレジェンド生活にも、そろそろ限界が来ていた。
なぜ今、Rustなのか
最近の若手は Python などでサクッと魔法のようなコードを書く。
正直、羨ましい。便利そうでいいな、と思う。
だがその一方で、「そんな、AIに言われるがまま書いたようなコードで、ITエンジニアを名乗るのか？」という、古参特有の黒い感情が燻っているのも事実だ。
「AIがコードを書く時代だからこそ、人間はもっと原理原則に潜るべきじゃないか？」
そんな、半分は正論、半分は「若手になめられたくない」という、CTO にあるまじき幼稚な独占欲を胸に、私は Rust という最もストイックな言語に手を出すことにした。
Python のような お任せ の対極にある、コンパイラという名の審判に一文字の妥協も許されない 究極の太刀筋。それこそが、私の化けの皮を本物の肌に変えてくれるはずだ。
5,280円の心理戦: 自分を追い込む技術
学習の相棒に選んだのは、オライリーの『プログラミング言語 Rust 第2版』。
通称「カニ本」。
著者名を見て、少しだけ背筋が伸びた。
Jim Blandy ..., Jason Orendorff ...
……ピンとこない？ まあ、そうだろう。私も偉そうなことは言えない。
ただ、Emacs を触っていた人間なら、この名前を見て居住まいを正すくらいの礼儀はあっていい。
なるほど、これは生半可な覚悟で読む本じゃなさそうだ。
どうする？
軽い気持ちで買っても、きっと最初の数ページをめくって、後は生成AIにコード書かせて「完全に理解した」とか言って、最終的にその本は、オヤジがやってるぜ感をアピールするためだけの 威圧的置物 になるに決まっている。
5,280円。高級な寿司なら数貫で消える金額だ。
さて、ここで私は戦略的な判断を下した。
この本を、会社の経費で買うことにした。
「48歳、CTO、小遣いくらい持ってるだろ」と思われるかもしれない。
確かに、自腹で買える金額だ。
でも、あえて経費で買う。
なぜか？
理由はこう。自分の金で買った技術書は、絶対に読まないからだ。
『Docker実践ガイド』（なんとなくのノリで使っている）
『関数型プログラミングの基礎』（Haskell に憧れて買ったが1章で頓挫）
『達人プログラマー』（名著らしいので買った）
自分の金で買うと、読まなくても罪悪感が薄い。
「まあ、自分の金だし」
「いつか読むし」
そうやって、積読の山は高くなっていく。
しかし、会社の金で買った技術書は話が別だ。
読まなければ、会社に申し訳ない。
経費精算システムに書いた理由が、ウソになる。
私が率先して学ばない姿を見せるわけにはいかない。
つまり、経費申請は、自分への強制装置 なのだ。
5,280円という金額を会社に負担してもらうことで、
「読まなきゃいけない」
「やらなきゃいけない」
という適度なプレッシャーを、自分に課す。
これは、意志の弱い人間が、自分を強制的に動かすための、セルフマネジメント技術 である。
うちの会社には「技術書は経費で買える」という、ありがたい制度がある。
エンジニアにとっては最高の環境だ。
私はこの制度を、学習のモチベーション維持装置として、戦略的に活用することにした。
経費精算システムの申請欄には、こう書いた。
「業務とは直接関係ないが、コードレビューの質向上および技術的視野の拡大のため」
それっぽい、うさんくさいごたくを並べてみた。
まあ、ウソは書いていない。レビューの質は上がるはずだし、視野も広がるだろう。たぶん。
申請、完了。
あとは本が届くのを待つだけだ。
そして、届いたら最後、もう逃げ場はない。
会社の金で買った。
チームのエンジニアたちが見ている。
「やっぱり読みませんでした」なんて、口が裂けても言えない。
こうして完璧な自縄自縛が完成した。
これからどうなるか
この日記では、48歳の脳みそが Rust の「所有権」や「借用チェッカー」という名のルールにボコボコにされ、コンパイラに罵倒される姿を晒していく。
AIに「正解」を聞くことはできる。だが、私の指先には25年分の手癖が染み付いている。AIが「綺麗に書け」と言っても、私の脳は勝手にメモリをいじり回そうとして、Rust の門番に叩き出されるに違いない。
AIの提示する「スマートな解決策」を、私の古い血がどう拒絶し、そしてどう受け入れていくのか。
CTO という看板をかなぐり捨て、一人の「不器用な初心者」として格闘してみようと思う。
さて、まずはカニ本の1ページ目を開くところからだ。
……と言いたいところなのだが、実は肝心の「カニ本」がまだ手元に届いていない。
そんな私の心を見透かしたかのように、今日、ふるさと納税の返礼品で巨大なタラバガニが届いた。
本より先に「本物のカニ」が届いてしまったのだ。
所有権も借用もない。ただ殻を割って、食う。
Rust より先に、こっちのカニの方がよほど私向きかもしれない。
Abe
「2026年、カニを頬張りながら、もう一度エンジニアの端くれに戻ってみる。」