🎂

15年のプログラミング歴を振り返って

2024/08/04に公開

はじめに

エッセイを書く人間には2種類しかいない。エッセイを書くことで頭がおかしいことが露呈する人間か、エッセイを書くうちに頭がおかしくなる人間である。

したがって私は普段このようなエッセイは書かないのですが、プログラミング歴15年の節目ということもあり、つれづれなるまゝに、日くらし、硯にむかひて、心に移りゆくよしなし事を、そこはかとなく書きつくれば、あやしうこそものぐるほしけれ。

想定読者は暇な人です。読まなくていいです。

プログラミングと数学の話題が多いです。

人生のアドバイスみたいな態度は一切取らないように注意しますので、コメントや SNS で私に人生のアドバイスをしないでください。やった人は殺します[1]

プログラミングを15年続けた価値はあったか

はい[2]。何かを作りたいとかいろんな実験をしたいという根源的な欲求を満たし続けてくれて、なおかつパソコン1台あればよくて場所を取らないというのが最高です。やりたいことやるべきことが無限にあっていつまでも遊び終わりません。

何よりも最高なのはプログラミングの世界では天才の手練手管は再現性のある状態で公開される点です。数学もそうですが、天才的で効果的な発想ほど一瞬で解析されて誰もが使える形に落とし込まれます。見ているだけでも面白い、使ってみたらさらに面白い、中身を解剖してみたらもっと面白い。それを自分の力にできることが最高に面白いです。

私はごく少数の例外を除けば基本的に人間が大嫌い[3]なので、機械を相手にする仕事をメインにできるというのも幸せポイントです。

就活に役に立ったかどうかは、終わり果てた人間性を擁護し切れるほどではなかったとだけ述べておきます。

プログラミングをしていて後悔したこと

これは特にないです。ただ時間だけは確実に消費するので、以下の3点に気を付けています。

  1. 暇なときはデフォルトでプログラミングの勉強をするよう習慣づける。
  2. ただし他の何か[4]をしたいという気持ちや、単にプログラミングをしたくないという気持ちを我慢してまでプログラミングはしない。
  3. 同様に興味がない分野の勉強も無理にやらない。

興味がないときに無理をして勉強しても全然頭に入らないので結局は時間の無駄になることが多かったです。

たとえば私はフロントエンドの知識が欠けていて、強迫観念にしたがえば今すぐフロントエンドの知識を血眼になって勉強すべきなのですが、いくらやっても一向に身につかない分野というのはあるものです。

逆に業務で使うとか、自分の好みにぴったり合うフレームワークが見つかったというときには、それまでのことが嘘のようにスルスルと身についたりします。

プログラミングで何が重要だと思うか

勉強量です。プログラミングの力量は MAX 値がそれまでの勉強量で、そこに理解力と想像力と記憶力に応じたペナルティを受けます

どれだけ天才に見えるあいつも見たことのない情報を知ることはできませんし、その情報を知っているなら必ず一度は勉強しています。天才はその理解力と想像力と記憶力が並外れているので1回学んだことを完璧に覚えた上で他のことに応用できるというチートが使えるだけです[5]

また、凡人でも理解力、想像力、記憶力といった能力は修練によって次第に強化されていきます。これら3つの能力は新しい知識に触れたときに既に持っている知識量が多いほど鋭敏に働くからです。

理解力はそれまでの知識に関連づけることができれば素早く理解できますし、想像力や発想力はそれまでの知識から大きく影響を受けます。記憶力に関してはよく出てくる概念は反復記憶で強化されていきますし、プログラムやドキュメントに落とし込んでおくことで補助することもでき、そのノウハウも少しずつ蓄積していきます。

人によって向き不向きはあると思いますが、上記のような事情もあるのでそれを早期に判断することはできないと私は思います。また、そう思うので、私は他者にプログラミングの向き不向きについて語ることはしません。

どんな人が生き残るかについても、やり続けている人が残ってやめた人はいなくなるという当然の因果関係だけが存在すると思っています。私も最初の数年間は半年おきに挫折していましたが、それでもなぜかやめなかったのでまだ続けているに過ぎません。

なぜ向き不向きの判断ができないか

実のところ、向いていない人を当てるのは簡単です。日本の人口に占める IT エンジニアの割合はわずか 0.97% であり、全員に対して「向いてないよ」と言っておけば 99% 以上は当たったように見える(プログラミングを生業にしない)からです。したがって「OOだからプログラマーに向いていない」といった言説は「OO」の部分に誰にでも当てはまるような言説を入れておけば当たった気分になれます。

また、向いている人を言い当てるのも簡単です。プログラミングの世界で才能のある人はすぐに成果物を生み出すので一目瞭然だからです。1週間でプログラミング言語を学んだ上に自分でプログラミング言語を作ってしまったり、中学生の頃からプレステのエミュレータを書いてたりします。しかしそれは一部の天才です。難関大学でも全学年にひとりいるかいないかみたいな感じです。

これら2つを組み合わせると向き不向きを当てるフリをすることはできますが、あまり意味のある言説にはなりません。ほとんどの有象無象のプログラマはその中間みたいな存在で際立った才能の差はないからです

かく言う私も、プログラミングを始めたころには数行のコードを3日たりとも覚えておくことができませんでしたし、C言語で簡単な対話プログラムを作るにも1年以上かかりました。同僚や友人たちと比べても適正はかなり低いです。新しい技術を習得しましょう、よーいドンで競争させられたら私は「不向き」の烙印を押されるという自覚があります。

しかし今では 500 行程度を1ページ単位として数千行くらいはすぐに把握してしばらく覚えておくことができますし、低レイヤーから高レイヤーまで扱える技術の範囲もかなり広がっています。見る人から見れば「15年かけてその程度?」みたいなレベルかもしれませんが、チームの主力として十分働ける力量であり、実務で困ることはまずありません。いまの私を見て「不向き」と思う人はあまりいないでしょう。

どうやって勉強しているか

ほとんどは独学です。気が散ってしまうので人と一緒に勉強するのが苦手です。

独学といっても、それができるのはインターネットや書籍に十分に独学ができるほどの情報を共有してくれている誰かがいるからです。ドキュメントや記事を整備してくださっている先人たちへの感謝を忘れたことはありませんし、記事の執筆を続けている動機の根底にはコミュニティへの恩返しの気持ちが強くあります。また、困っていたときに教えてくれた方々にも大変感謝しています。

勉強方法は以下です。

  • 面倒臭いときは生成 AI で。
  • まとまった知識は書籍で。
  • 最先端の知識は X(旧Twitter)で。
  • はじめの一歩はネットのチュートリアルやハンズオンで。
  • 詳細な情報は公式ドキュメントで。
  • エラーの解消はエラーメッセージをよく読んで StackOverflow で。
  • 最新のエラーやバグの対処は GitHub の issue で。
  • それでも解決しなければソフトのソースコードで。
  • ちょっとした実験のやり方はブログや Qiita, Zenn で。
  • あとは実際に手を動かして試行錯誤。

私はあまり使いませんが最近は YouTube などの動画媒体にも重要な情報がまとめられることが増えたと感じます。

自らの生存戦略をどのように定義するか

私はあまり人間とは直接関わらずに生きていきたいですし、今までに積み上げたプログラミングや数学の技術を捨ててはあまり高い収入も望めないので当面は技術力ベースに生きることを目的にしています。自らの人生にあまり興味がないのでよっぽど飽きるまではサラリーマンでいいと思っています。

時代の流れをどう読んでいるか

コンパイラの技術発展によってアセンブリを書ける人材の需要が激減したように、LLM の台頭によって自然言語の命令を受けてプログラムを書くという仕事は消滅路線に入ったと思っています。昨今の生成 AI は私が慣れていないプログラミング言語については私よりもよっぽど早く高品質に理路整然とプログラムを書いてくれます。

現在の AI 技術の延長にはないと思っている能力は以下です

  • 能動的に人間に関わって情報収集や利害調整をする能力
  • 人間の行動原理となる価値基準を把握して定義する能力
  • 現実世界の全体を俯瞰して戦略策定を行う能力
  • 自然言語を用いて精緻な論理推論を行う能力
  • 複数の物事に共通する本質的な法則やルールを見抜く能力
  • 自らが行った提案や判断について責任を取る能力

他にもあるかもしれませんが、上記の6つのように

  • 人間に対して能動的に働きかける能力
  • 人間が標準的に備えている高度な物理インターフェースを駆使した情報収集能力
  • 反復することで精緻化される高度な知的思考能力
  • 人権に基づく法的な責任能力

を伴う思考・判断・行為は AI にはできません。昨今の技術革新の速度を考えれば秒読みなのかもしれませんが、少なくとも未だ実現の目処は立っていないと思います。

この流れを受けて今後の IT 技術者は大きく以下の5つのロールに分かれるのではないかと思っています

  1. 戦略策定や利害調整など人間どうしの活動を円滑にする管理者のロール
  2. AI を駆使して開発の全体を大雑把に担いつつ指揮する管理者のロール
  3. 各個の技術に精通してその部分における詳細な開発を行い責任を負う専門家のロール
  4. AI で代替できない他の専門分野の技術をプログラムに落とし込む専門家のロール
  5. その他、上記に属さない少数のロール

歌って踊れる声優ではないですが、単にプログラムが書けるということを超えて仕事や責任を要求されるようになることは間違いないと思います。

まぁぶっちゃけ私はどれでもいいですが、あまり人間に関わりたくない[6]ので 2, 3, 4 あたりを意識することになります。

生存戦略

当然ですが戦略は個人の特性や能力に大きく左右されます。前提が異なれば結論も異なります。まず前提は以下です。

  • 私はそんなに頭がよくないです
  • じっくり考えるほうなので手を動かすのもそんなに早くないです
  • しかし時間をかけることで他者よりも深くまで潜る根気はあります

したがって以下を基本とします。

  • レッドオーシャンに飛び込んでトッププレイヤーと戦うことはしません
  • 基本はアンテナを張り巡らせてブルーオーシャンを先読みします
  • 同時に身につけておける技術はそこまで多くありません
  • 新しい技術に飛びつくよりも長生きする技術を嗅ぎ分ける必要があります

この戦略に則って、現在はマテリアルズ・インフォマティクスの分野で仕事をしています。医療や医薬の分野に比べてインフォマティクスの普及が遅れており開拓の余地がまだまだある一方で、IT 技術者からは見向きもされない分野なので惨憺たるレッドオーションが広がる AI 分野では競争率が非常に低い穴場となっています。

それはさておいて戦略をより精緻化し、戦術となる技術スタックを導きます。

プログラミングや数学の技術は多岐に渡るので、そのすべてを極めることは少なくとも私には不可能ですその一方でひとつの技術に全振りしたとしても界隈のトッププレイヤーには遠く及びません。受験勉強をしているときからそうですが、全体的に 70〜85 点くらいを取ることで総合評価としては優秀という万能型の性能が他者と比較したときの強みになります。

現在の私がプログラミングや数学の勉強において直面する問題は、自らの記憶力の限界です。中学の頃はいくらでも知識を吸収できる気でいましたが、大したことのない脳みそで15年も知識を蓄え続けるとその圧倒的な情報量と老化の進行が重なり、既に記憶力は飽和しています。新しく何かを覚えると別の何かを忘れる始末で、明確に技術スタックの取捨選択が必要になってきています

以上より、しぶといサラリーマンとして生きるために以下のような戦略が導かれます。

  • 万能型として生きるために汎用性の高い技術スタックを構築する
  • 記憶力の制限があるので学習コストと記憶リソースを最小化する
  • 積極的に自動化することで単位時間あたりのアウトプットを最大化する

これが起業したいとかフリーランスで生きたいとかであれば戦略も技術スタックも変わるわけですが。

このような戦略に基づいて管理している技術スタックが以下になります。

1. 数学

プログラミングか数学のどちらか一方に秀でた人は辺りを見回せばけっこういるのですが、両刀使いは貴重です。当時からプログラミング一本で食っていけるほどの才能はないと思っていたのと、プログラミングだけではできることに限界がある[7]ことを身をもって知ったので追加した技術スタックのひとつになります。

プログラミングの技術は移り変わりが早いですが、数学の理論は一度確立されれば向こう 100 年以上は通用するので、その寿命は折り紙つきです。数学は人類が物事の本質を記号操作で厳密に捉えるためのほぼ唯一の方法であり、科学の分野では共通言語となっている汎用性の高さからも、かなり安心してリソースを割く判断ができる技術になります。

業務に活かすために主に機械学習や数理最適化の分野を対象に学んでいます。

2. Python

機械学習からサーバー構築、処理の自動化など何でも使うことができ、やりたいと思ったことには大体既にライブラリが存在しているという圧倒的な裾野の広さから私のメインアームとなっている言語です。

言語自体はあまり好きではないのですが、データ解析などの業務で使用しているため必然的に触れている時間が長くなり、詳しくなってしまいます。

趣味で遊ぶのであれば、それはいかんでしょ、ってな具合のヤバめの言語ハックができるガバさは嫌いではないです。

3. Docker

コンテナによる仮想化技術はもはや常識と化してきているので特筆すべき項目ではないかもしれません。趣味で遊ぶにしても上に乗っけるものがないのにその下を学ぶのも少々退屈に感じてきているので、学習コストも考慮してオーケストレーションまでは踏み込まずに Docker まで、せいぜい docker compose までで止めています。

私の開発環境や遊び場はすべて Docker で仮想化しています。設定の変えすぎで意味がわからなくなって散々サーバーを立て直したり、いろいろいじってるうちに OS をぶっ壊したことがあれば、コンテナによる仮想化がいかに素晴らしい技術であるかは痛感できるでしょう。

4. TypeScript(React+Vite)

こちらはフロントエンドからサーバー構築あたりに使うサブアームになります。業務でいじることがないため完全に趣味の範囲となり、技術のキャッチアップや突然業務でフロント開発が必要になったときのための保険としていじっている言語になります。

フロントエンドはめちゃくちゃたくさんフレームワークがあり、業務外にちょっくらいじる程度ではまったく話にならないくらい豊富で複雑な機能が目まぐるしく変化しています。リッチなフレームワークは無理だと判断して、いろいろなフレームワークの基礎となっていて比較的開発速度も安定しているピュアな React を勉強することにしました。

ピュアな React を使用する上で、その開発をサポートしてくれる Vite は使い方が簡単で動作も軽快なのでいまのところ TypeScript + React + Vite の組み合わせに満足しています。

5. Apache Cassandra

データベースの勉強はずっとサボってきたのですが、その理由はノードを増やしたときの設定の面倒臭さでした。RDB はその仕組み上、クラスタを組む場合はマスターノードとリードレプリカのように必ず非対称性が生じてしまいます。既に立っているものを使うだけならともかく、インフラ寄りの技術スタックで立てる側の観点からアプローチすることの多い私にとっては、ちょっと片手間で勉強するにはあまりにも興味が失せるものでした。

そしてぶっちゃけ、優秀な人であれば上記1〜4の技術スタックに加えて RDB が使えるなんてザラであり、いざというときにレッドオーシャンを避ける私が獰猛なサメとかち合うことになってしまいます。

その点、Apache Cassandra という NoSQL データベースはクラスタ内のすべてのノードが対称な分散型データベースであり、大規模で可用性の高いデータベースを簡単に構築することができます。この設計思想が非常に美しく好みに合っていることに加え、日本国内ではまだあまり情報が出回っていないこともあり使える人が少ないので、学ぶ価値ありと判断して技術スタックに追加されています。

堅実な技術スタックを選びがちな中で若干のイロモノ枠になります。

6. その他

golang, PostgreSQL, Kubernetes などもちょいちょい勉強していますが、十分な勉強時間は確保できていません。そして時間が十分にあってもアニメ見たりゲームやったりしています。こいつらはその程度の興味ってこと。

おしまい

話が発散し始めたので終わります。ここまで読んでくださった方は、なんで読んでくださったのかよく分かりませんが、ありがとうございました。

脚注
  1. 私は自分で責任を取れないことには絶対に口出しをしないと決めています。すなわち他人の勉強、恋愛、人生です。 ↩︎

  2. 予め断っておきますが、私はゴミはゴミとはっきり言うタイプであり、時間を費やした結果無駄になったことについて無理やり価値を見出そうとする自己欺瞞が反吐が出るほど嫌いです。人生の貴重な時間を無駄にしたという苦悩と己への憎しみだけが私を正しい道へと導いてきました。この苦悩を手軽に味わいたければぜひ『デストイレ』という映画を見てみてください。 ↩︎

  3. 興味がないのに社会の仕組み上関わらねばならないだけでなくあまつさえ配慮することをも強制されるためその歪みが人類全体への憎しみとして蓄積されています。人類絶滅ボタンを拾ったらすかさずケースに入れて飾り、お披露目パーティをしたりロシアンルーレットをしたりしばらくワクワクを楽しんで存分に愛でたあとでスッと真顔になって押すと思います。 ↩︎

  4. 昼寝でもアニメでもゲームでも。 ↩︎

  5. たまにその辺りの過程をすっ飛ばして理論を構築してしまうバケモノもいますが、今まで会ってきた天才だと思う人たちで努力をしていない人は見たことがないです。 ↩︎

  6. なんというか、動物園の檻の中にいる動物を眺めるのは好きですし、ふれあいコーナーにいる動物であればふれあってもいいかなと思うのですが、その辺にいる人間は野生のヒトでこっちに干渉する意思や能力を持ってるので本能的に心理的な警戒心が拭えないんですよね。 ↩︎

  7. たとえば並列化でプログラムを高速化しても数倍速が限界ですが、数学的にアルゴリズムを改良すれば数百倍速になることもザラです。 ↩︎

Discussion