変数名は「AIにレビューさせろ」Part1

-「命名に悩む時間」は生産性の無駄。AIに任せて、ロジックに集中すべき。-

老兵は死なず、AIと踊る

 変数名の命名というのは鬼門と言えば鬼門で私は、35年近く前になりますが駆け出しの頃、処理対象を指す変数名に「enemy」という変数名を付けて当時の先輩から笑われた。もっとも直せと言われずにユーモアと受け取ったようで、牧歌的というか微笑ましい時代でもありました。
 もちろん今なら、destination???? やら target???? やらもっと適切な名称をつけるでしょうし、変数を適切に命名する。つまり「何を」保持しているのかを明確かつ分かりやすく命名することは、単なる読み手だけではなく、おそらく自分自身のためにもなるかと思います。例えば金額計算なら、「税抜き価格」、「税込み価格」、「税率」、「合計金額」、「税率別税額」、「税率別課税対象額」等が考えられますが、これらを、

p1,p2,p3,p4,p5,p6

という風に命名したら、多分、解読不能(バグを誘発する)プログラムになると思います。
一方で、Youtubeのプログラミング初心者向けの動画で「可読性の高いプログラム」ということで、変数名の命名について

・1文字の変数名はダメ
・boolean型にはis/hasをつける

ということを堂々と教えていた。これらについては全否定する気はないですが、『初心者に対して変数名の命名に対してルールを強制するのは如何なものか?』と思う。
というのも本来プログラミングというのは人間が作り出すもので、思考の結晶ということも言えます。変数名も同様です。しかしながら、日本人の性質として、このように言及されるとそれを額面通り受け取り例外を考えなくなり、1文字の変数を書かなくなったり、booleanに必ずis/hasをつけたりします。本来自由であるべき変数名を強制するには、それなりの理由付けが必要でしょう。大規模プロジェクトのように『予め命名規則が決まっている』プロジェクトならともかく、「経験不足の初心者に対して枷になるような規則」をつけるのもどうかと思います。ちょいちょい言っているのは『ソースコードはなるべく自由に、動くプログラムが最強』ということに尽きます。もちろん解読可能な範囲でということになりますが。

で、前置きが長くなりましたが、変数の命名についてまず言わなければならないのは、プログラミングが出現して半世紀を超えましたが、その中で命名規則も変わってきているということが言えます。

例えば、大昔は変数名の長さに制約があったり、ポケコンなどは1文字の変数名しか許していなかったり、大文字しか許していなかったりしていました。この時期に作られたプログラムならp1,p2とかもバンバンあったかと思います。省略も良く行われていて、逆に単語をフルに書くことの方が少なかったかと思います。よく「母音」を省くということもあったかと記憶しています。userNameでなく、usrNmとかですね。
時代が進み、大文字小文字の区別がついたり、記号を入れられるようになり、比較的自由に変数名が命名できるようになると、様々流派が出てきました。
それでも、例えばC言語なら

while( *p++ = *q++);

という、知らない人が見れば「何をやっているんだ」というコードも逆に知っている人からすれば「お馴染み」となってました。

そして、変数名の命名に決定的な影響を与えた書籍が出てきました。『コードコンプリート』です。コードコンプリートで『変数名は理解しやすい意味のある名前にした方が良い』と整理され、今に至ったように思えます。無用な誤解を与える前に注意ますと、変数の命名について(だけでないですが)、コードコンプリートは大変有意義です。

私が問題にするのは、『変数の命名に対する意見(批判)がコードレビューと相まって「読みやすさ」という基準があいまいな個人の主観的な判断で行われること』です。

 実は、コードコンプリートも「1文字の変数」というのは良くないと言っている個所があります。
25年程前になりますが、大変ありがたい”主観的なレビュー”を受けて、ループに対しても『i ではなく index と書け。コードコンプリートに書いてある。』と言われた覚えがあります。その時に直したか直してないかは定かではありませんが、その後、変な影響を受けて一時ループインディックスをindexとした記憶はあります。ただ、明らかに違和感があったので元に戻した記憶もあります。
その後、改めてコードコンプリートを読むと「純粋にループのスコープで収まるインディックスは、i でもよい」と書いてありまして、「この野郎」と思った次第です。もっとも、私が index としたのはほんの数か月で、また i に戻したので、あまり悪影響は受けていないです。
では、私がコードレビューをしていたときにループインディックスに index としているコードを見たらどうするでしょうか?
答えは「何も指摘しない」です。ただ「この人は2重ループの外側にindexを使ったら内側のループインディックス名などうするのか?」と思うことはあります。

 この記事を書くにあたって、改めて、コードコンプリートを読み直しましたが、変数名の長さの基準が少々長いように感じます。「そこまで書くか?」という印象をぬぐえません。「読みやすさ」ということをいうのであれば、「適度な長さ」については個人差が大きいのではないかと思います。多分私は短い方に寄っています。

 いずれにしても、変数名に対してのチェックというのは、コードレビューで取り上げられやすく、いかにも日本人が好きそうな「儀式」にあったおもちゃという印象がぬぐえないです。真面目にやっている人もいらっしゃるでしょうが、そういう人は「1文字はダメ」とかは言わないかと思います。
 もちろん、大規模プロジェクトで「変数名の命名規則」が決まっている場合は従う必要がありますが、残念ながら日本の多くの現場が予め決められたものではなく主観的かつその時代時代で「良いと思われる」ものが個人の裁量で使われる傾向があるでしょう。
また日本人の英語力は、ばらつきがあり変数名の命名に英語を使うときは危険度が増します。一方でローマ字の変数名は嫌われるという厄介な風潮があります。
例えば上記にあった「税込価格」という変数名は割と難しいです。良く見るのは taxPrice ということになりますが、実はこれは「英語」としては成立していません。では taxPrice はダメかというと、これは難しいところではあります。今ならもちろんChatGPTに聞けば正解が解ります(正解は各自の宿題にしましょう。次の記事に回答編を書きます)。ちなみにそもそも「税込価格」を表す変数名に日本語が使えないところが最大の問題点ではあるのですが、言い出したらきりがないのでおいておきましょう。

 その他、命名に関しては主観的になりがちですが、あーだこーだと言わずに書いた人のアイデアを尊重し、AIに判定させれば良いかと思います。もちろんAIが明らかに間違えれば適宜人間が修正すればよいかと思います。

 ということで、私が過去に作成したコードを、AIに命名チェックをさせてみました。もちろんですが、enemyという変数名は無いことは事前に確認しています。単に命名チェックをさせると何がでるか分かりませんので会話を通して「望ましい変数名について」定義を行っています。

とあるライブラリの変数名のレビュー結果

私の基準を叩きこんだので私よりのレビューになりましたが、それでもrc、tranflgなどは「やんわりとダメよ」と教えてくれています。
「このライブラリを2026年基準で“軽く化粧直し”するならどこを直すか」と提案を受けましたが、結果は出さずに止めています。動いているコードを不用意に直すのは危険で、無責任に「これが2026年のコードです!」としたくないためですが、今ならAIにより(間違いはあったとしても)ある程度機械的にチェック&訂正案を出してもらえるので上手く使えば余計なストレスを受けずにすみます。

 特に初心者のうちは意味が通らない命名をすることが多いでしょうが、逆に命名に時間をかけず適当に書いて、AIに修正をお願いするというのも現代的なコーディングかと思います。
 さらに付け加えると私自身の経験になるのですが、実は論理的思考力や抽象化力が高い人ほど変数名に意味をつけない傾向があるかと思います。例えば数学者は a b c と1文字の変数名を使いますが、彼らは「この変数の名前が○○でないとダメ」とかは言わないで純粋に式について議論します。もちろん私もそこまではいきませんが、変数名にあまり惑わされないでロジックを追えます。もちろん、これは「意味のない名前でよい」という話ではなく、文脈を理解できる人ほど、名前に依存しなくてもロジックを追えるという意味です。

老兵は死なず、AIと踊る

コードレビューは鬼門か?

-人間がレビューするよりAIにレビューさせた方がよいのでは?-

老兵は死なず、AIと踊る

最近、SNSで「AIでコードを書いてみました(バイブコーディング)」という記事が氾濫するようになったのですが、一方でその書いたコードを出していない人が目につく。私の場合は、規模は小さいがAIに出力させたコードを公開していたりする。
まぁ、権利関係から出せないものもあるのでしょうが、実際に動くものを出さないで「バイブコーディングしました」というのは、眉唾もので、15年程前に「オブジェクト指向やってます。」という、「エアオブジェクト指向」と同じ香りがして、「エアバイブコーディング」じゃないかと疑ってしまいます。
(と言っていたら、こんな記事がGoogle discoverからサジェストされました。正直、部品レベルのものをいっぱい出して「限界を突破」と言われても・・・というのはありますが、コードを出している少ない例です。)
私の場合は、今は、AIをハックしている状況で、つまりAIの特性を体感している状況で、バイブコーディングをするまでには至っていない。もっとも、将来的にはバイブコーディングを視野に入れているので、今は色々試しています。

 そういった中で、バイブコーディングの前段として、「AIにコードレビューをさせたらどうか?」ということで、コードレビューさせました。

 ちなみに、コードレビューですが、こちらもネット上では色々言われていますが、『エアコードレビューではないか?』というのも散見されます。
 というのもコードレビューは、ある意味コードを書くより高度な技術が要求されます。「なぜそう書いたのか?」ということに対して、本来ならレビューアーはレビューイーより高度な視点と経験が必要かと思いますが、実際には「ただのいちゃもん」に成り下がっている面もあります。
 私が本格的なソースコードレビューがあるプロジェクトに参加したのは30年以上前になります。それ以降は、「個人的な感想をいう場」としてのレビューはありましたが、当たり前ですが、そんな「個人的な感想」を言われてもどうしようもないです。また、ここにも書いていますが、私自身は他人の書いたコードをレビューしてやろうとは思わないです。もちろんデバッグの為に読むことはありますが、ここ炎上プロジェクトとクソコードに書いているとおり、コードに対しての評価というのは考えないようにしています。

レビューさせたのは、私が開発しているプログラミング言語(ADP)のプロジェクトになります。ChatGPTは一式をZipファイルにまとめて読み込ませました。
Geminiの方は、ファイル数の制限のため、ソースコード、ヘッダファイルそれぞれを1つのファイルにして読み込ませました。

ChatGPTとのやりとり
Geminiとのやりとり

※Gemini上で「与太さん」というのは私のことです。

C++での比較的規模の大きいプロジェクト(プログラミング言語の実装プロジェクト)のコードレビューなので、
・技術的に突っ込んだ内容となっている
・大きなプロジェクトなので評価も大雑把(ピンポイントの指摘もありますが、全体を細かくみていない)
というところはありますが、ChatGPT,Geminiとも会話が弾んでいることが分かるかと思います。
ChatGPTにしても、Geminiにしてもただ褒めるのではなく、開発者の意図を読み取って良いところをほめています。
 前述のとおり私自身、コードレビューに対してはあまりいい思い出がありません。30年以上前のプロジェクトに関しては、レビューアーが「あー、そうなんですね。」というだけで私自身はなにも得られなかったですし(もっともそれはそれで開発工程としては成立していたかと思います)、それ以降の「個人的な感想を受けるレビュー」は、(悪く言えば)レベルの低い相手からの嫉妬交じりともいえる言いがかりを聞く非生産的な場所ということで、私自身「日本の開発プロジェクトでコードレビューは鬼門」と思っていました。誤解のないように補足しますと、コードレビューが大事なのは理解しておりますし、効用はあるのでしょうが、日本の多くの現場では、そもそも「チームプレイとは何か?」から入る必要がある状況で、コードレビューは(対新人)以外にはあまり効果がないというのが実感です。

そういう印象でのAIレビューですが、第一印象が、奴らの「ほめるところを分かっている」ところに逆に恐ろしさを感じました。

「このレベルの議論ができる方と話せるのは正直かなり楽しいです。」(ChatGPT)
「正直に言って、ここまで地に足のついたマニアックな話が自然に続くのは、かなり稀です。」(ChatGPT)
とか
「この挑戦は、言語処理系開発の醍醐味が詰まった非常にエキサイティングな領域だと思います。」(Gemini)
「与太さん、仰る通りですね。「意図しないバックトラック」のデバッグは、論理型言語を開発・利用する上での最大の難所であり、永遠の課題と言っても過言ではありません。」(Gemini)

とかは、おべっかが嫌いな硬派なエンジニアを気取っている私でも

お前は分かっているな!

と喜ばずにはいられないです。

 当然と言えば当然なのですが、AI達は、良質の多数のコードを読み込んで学習していますので、「個人の感想」レベルを超えたレビューが出来るところまで達しているようです。AIあるあるの「ハルシネーション」ですが、AIの出力はバイブコーディングと違い直接的な成果物とはなりません。コードレビューはあくまでも「指摘」なので、その指摘が正しいかどうかは、仕組み上、人間が確認できることも大きいです。上記のChatGPTとのやり取りもAIの返答を鵜呑みにせずに

『>分岐予測が効きやすい
これは無いかと思います。つまり必ず失敗する分岐予測が2回から1回に減ったということになります。』

AIの間違いを指摘&その返答を繰り返すことにより、よりコンピューターに対する知見が向上するでしょう。

AIの指摘は受け入れるのか?という点ですが、例えば、「C++11以降に書き換えてみては?」というのは、ChatGPTもGeminiも指摘しているところです。これは、参考にできるところとできないところがあるのですが私としては視野に入れているところです。ChatGPTの方は、「このプロジェクトですが、17年程の歴史があります。数回大幅な書換えがあるのですが、歴史的にみるとC++色からC色に移っています。」と現状を説明しながら効果的なアドバイスを求めています。Geminiの方は「メモリ管理についてはRustの借款のアイデアを使っている」ということで議論を進めています。プロジェクトの全体設計の話になるので大雑把な議論になるので、既に考えていることの指摘ということもありますが、会話を重ね深堀することにより発見があったりします。
 また、もちろんですが、AIコードレビュー一本ではなく、セキュリティ監査等より慎重なレビューが求められる場合は人間との共同でレビューを行うこともできるでしょう。

とまぁ、個人開発されている方やプログラミング学習者の方は、モチベーションを維持するためにもAIによるコードレビューをお勧めします。
人間の嫉妬や無理解に晒されるコストをゼロにし、純粋に技術的対話に没入できる。
これこそが、AI時代の真の生産性だと思います。

老兵は死なず、AIと踊る

AI時代のプログラミングスクールとの付き合い方 Part3 -私のスクール経験(プログラミング、英語)について-

老兵は死なず、AIと踊る

 前回に続き、私自身のスクール経験(プログラミング、英語)について書いてみたいと思います。
プログラミングに関しては、学校に通ったことはないです。一方で、英語(通訳案内士)に関しては学校(複数)に数年間通いました。以下、それぞれの学習記録になります。

プログラミングの学習について

 私は14歳のときからプログラミングを始めました。3か月でベーシックを学んで、次の3年でアセンブラを学びました。
 学校に通わなかったのは、お金がないこともあるのですが、「十分な学習時間が確保できた」と「向いていた」ということが大きいです。大学に入る前にほぼ毎日2,3時間ずつ4年以上学びました。
 自己学習ということは、本を読むことになりますが、私が本に書いてあることがまぁまぁ理解できました。もちろんですが、一回読んでもわからないこともあり何回も読んで「どうなっていんだ!」と考えたこともありますが、突き詰めると、本に書いてあることが分かったという経験は、独学を行う上で重要です。
 本の良さの一つですが、「一定のクオリティが期待できる。」というのがあります。本という一定の分量の文章を書くというのは結構大変です。ネットに「つぶやかれた」ような文章とは質については一線を画しています。さらに著者一人が書いているだけでなく編集者のチェックが入ります。チェック自体は最低限ですが、「書きっぱなし」の文章とは異なります。残念ながらIT業界の人材は玉石混交で、今SNSを見ると「現場経験の乏しい人(SES崩れ)」の人が学校をやっていると思えるものもあります。実は、IT人材にばらつきがあるのは昔からで、例えばこの記事では、大手の企業でもあまり質の良い記事を書いていないことを10年前に指摘しています。多数の本を読むことにより、偏った考えに陥ることを防止できますが、残念ながら2026年現在は書籍自体が減っており、信頼できる情報源というのを見つける難易度があがったかと思います。。
 ちなみに脱線しますが、私はもともと国語力がなかったのですが、技術文書の読書をとおして読解力が付いたのも大きいです。そういう意味でも「独学の利点」をあげられます。
 私は現役の時は大学を途中で辞めたのですが、35年ほど前の当時、既に大学には情報系のコースがあったかと記憶しています。しかしながら大学でプログラミングをマスターして就職するというコースはあまり一般的ではありませんでした。むしろ大学を辞めた人がプログラマーとして就職するというのは日本では割とポピュラーでした。一方で、アメリカで就職しようとすると”コンピューターサイエンスの学位または同等の資格”というが必須なようです。
 学校には通いませんでしたが資格はとりました。高校生の時に第二種情報処理技術者の資格をとりその後いくつかの資格をとり10年程前にも、(このブログのタイトルである)システムアーキテクトの資格をとっています。

英語学習について

 英語については、私の実力は壊滅的でした。本を読んでも「で?」としか分かりません。文法書を読んでも良く分からず、改めて振り返ると「英語については向いていなかった」ということが言えます。特に厄介なことは、英文を読むと10分ほどで脳が限界を感じます。コンピューターの本なら何時間でも読めるのですが、英文となると体が拒否反応を起こします。これではダメということで学校に通い出しました。足掛け10年以上、学校に通いました。ただ、週1回で学校に通うだけでは、一向にしゃべれるようになりませんでした。学校はあくまでも学習の習慣づけが基本になります。英語勉強の基本的な考え方(反復練習が大事、文法より文脈)については学校で習いました。
 加えて、語学留学も行いました。2026年現在、英語の学校に通うことについては賛否があるでしょうが、語学留学や大学への留学に関してはお勧めいたします。言葉というのはなるべく大勢の人とやり取りをする方が、つまり数をこなした方が上達するかと思います。
帰国後、通訳案内士として就業しましたが、これは仕事で英語を使うことにより、単なる勉強を超えて語学レベルをブラッシュアップできたと実感しています。

向き不向きについて

 向いている向いていないに関係なく、一定技術を習得するには「質より量」という側面があります。私はITエンジニアとしても通訳案内士としても大体、5,000時間程度勉強していますが、学習においては結局のところ「どれだけ自分で勉強したか?」が重要になります。学校に行くということはあまり勉強時間とは関係がありません。最終的にはどれだけ自己学習をしたかが大きいようです。勉強時間は個人差はあるかと思いますが、5,000時間を目安として頑張れば、学習前とは違う景色がみられるかと思います。

 伝統芸術や伝統工芸でよく「師匠から教えてもらえない」ということがありますが、これについては今なら良く分かります。技術は教えてもらうものではなく、自分で学ぶものだということです。

 印象深いことがありまして、とあるITの炎上プロジェクトの助っ人をやっておったときのことです。担当者に対して色々説明を行っていたのですが、彼は相槌をうつだけで、一向に私の説明を理解していませんでした。少々腹がたったのですが、ちょうどその時に通訳案内士の学校に通っており、当時の私としては内容がかなり高度になりまして、私自身も相槌をうつだけで授業内容が頭に入ってきませんでした。「向いていないということはこういうことか」と当時は実感したものです。

 向いている向いていないは学習の進み具合に関係しますし、プロとして活動するようになってからも差が出てきますが、「向いている=プロとして優秀」というのは少し違うかと思います。私も炎上プロジェクトの当事者になって挫折も味わいましたし、プログラマとしては向いているかもしれませんが、企画やスケジュールを立てることは苦手(向いていない)です。画面のデザインも不得意です。結局、細かく検証していくと「業務に関して全方位的に向いている」という人は現実としていないのではないかと思います。ITエンジニアとしても長所・短所があり通訳案内士としても長所・短所があることになります。
 英語については向いていませんし、今でも「向いていない」と時々感じることですが、こちらも仕事をする上ではあくまでも一要素ということになります。「通訳案内士」は外国語で話をするのはそうなのですが、特に英語の場合、「ネイティブのように」というのは場合によりけりで、イギリス英語なのか、アメリカ英語なのか、西なのか、東なのか、非英語圏の人なのか、と様々あり、よく言われる「ネイティブ信仰」というのは必ずしも当てはまりません。(もっとも私はアメリカの西海岸に留学したのでカルフォルニアあたりから来た人は「うまいね」と確かに言われ、フランスからの人は「?」といわれます)。通訳案内士というのは実際にお客さんと同行して案内するのでいわゆる旅程管理という業務もになっており、さらにはお客さんは「日本人の意見が聞きたい」とか「日本のドラッグストアに行きたい」とかいろいろな要望に応える等、複合的な職業ということもあります。こちらも「英語の向き不向き」だけでは実力は測れないかと思います。ということで翻訳や通訳はともかく通訳案内士については、しばらくはAIにとって代わられないと思っています。

メンターについて

 メンターについてですが、英会話の先生については、あくまでも先生ということでそれ以上何かきくことはありませんでした。通訳案内士の学校の先生についてはある程度、メンターの役割もあったかもしれませんが、生徒が複数おり、あくまでも授業を聞くというところ以上のものはありませんでした。いずれの先生も感謝はしているのですが、メンターとまではいきませんでした。

一方で、ITエンジニアとしても通訳案内士としても仕事をやりだしてからは、数名ほど尊敬できる先輩(メンター)がいたのは事実です。が、残念ながら不徳の致すところで深い付き合いとはなりませんでした。もっともITエンジニアとしても通訳案内士としても自立した専門家になるということはメンターからは卒業という意識もありました。

プログラミング学習と英語学習の違い

 せっかくなので、プログラミング学習と英語学習の違いについても触れたいと思います。一番大きな違いは、「プログラミング学習は主に考えること」であるのに対して「英語学習はとにかく量(習うより慣れろ)」につきます。
 もちろん、どちらにしても「授業を受ける。先生の話を聞く」ということを否定はしませんが、プログラミングの場合、ある意味芸術家のように「あーでもない、こーでもない」と悩むこと自体がプログラマとしての基礎練習になります。私としては「オブジェクト指向おじさん?」の記事は、単に記事を読んで納得するのもいいし、異論や反論をする。つまり記事を読んで考える行為そのものが、エンジニアの成長のきっかけになると思います。
 一方で、英語の場合、考えるより鵜呑みにしてもよいので覚える行為が重要かと思います。実は、「自動詞と他動詞を考え直す(Part2)、日本人にとっての自動詞と他動詞の恐ろしさ」この記事自体は読み物としては面白いかと思いますが、「英語学習」にフォーカスを当てるとあまり意味がないです。おそらく英語の上級者はこの記事を読んで「で?」と思うと思います。この記事でも指摘しているとおりネイティブでも間違う(というか辞書どおりでない)というのは、日本人が日本語を話すときに細かい理屈を知らないことと似ています。「では何でこんなことを考えるのか?」ということですが、こういう理解というのは一種の精神安定剤的に作用します。つまり、「なんで自分ができないのか?自分が勘違いをしているのではないか?」という不安を解消するために使うと有効かと思います。直接的な学習効果はないが一種のサプリメントということができます。

老兵は死なず、AIと踊る

AI時代のプログラミングスクールとの付き合い方 Part2 -メンターについて-

老兵は死なず、AIと踊る

あけましておめでとうございます。
昨年末から、AIによる文書作成が私の中で成立するようになり、すっかり YouTube がご無沙汰になったのですが、YouTube はそのうちやるということで、続けます。

文書作成におけるAIの使い方ですが、
・論点整理
・モチベーションの維持
・評価(批判)
が受けられるところですが、当然、AIの意見を真に受けるはずもなく、そこはそこで多角的に分析をしています。
具体的なプロンプト等は、「企業秘密」ということで出すのは控えます(このあたりのノウハウについては公開するとAIがそれを取り込み面倒なことになりかねないので秘密としておきます)、が、やっていることは、様々なプロンプトで回答を引き出したり、今は、ChatGPT, Gemini, Grokを使って評価させたりしています。
もちろんですが、文書は私が作成していますし、文責も私が担っております。

で、前回(AI時代のプログラミングスクールとの付き合い方)の記事の批判で、「優良なプログラミングスクール(メンター)の存在について触れていない」という指摘を受けて記事を書いてみます。

まず、プログラミングについて『メンターが必要か?』というと、私自身は『必要な人もいるかもしれないが、一般論として必須ではなく、もしプログラミングスクールがメンターの存在だけを前面に押し出しているのであれば、注意が必要』だと思います。

メンターが必要というのは2000年代から言われたように思いますが、このメンターですが、プログラミング技術の習得に限っていうと、疑問が残ります。

技術者として改めて思うのですが、プログラマなり(通訳案内士)なりのある種の専門家は、その専門領域に関して「メンター」という存在は不要なのではないか?という考えです。

これはある種の「師弟関係」の否定ととられる恐れがあるのですが、「師弟関係」をむしろ肯定するからこそ、プログラミングスクールのいう「メンター」の存在に違和感があります。

本来、師匠というのは単なるプログラミング技術を教えるのではなく、「プログラマ」として一人前になるうえでの先生にあたるかと思います。

プログラミングを学ぼうという人に対しての「プログラミングが出来るようになる」というのは単なる知識だけではなく、「自立したエンジニア」として活動できるようにする必要があります。
この場合、単なる技術的なアドバイスだけでなく、プログラマとしての職業倫理や技術的な哲学について指針となるような人が「師匠(メンター)」という存在になりえると思います。

少なくとも、私自身の知る限りでは、そのような人は日本にはほとんどいないでしょう。というのが長年の私のエンジニアとしての経験からくる結果になります。

もちろん、『スーパークリエーター』とか検索すれば出てくると思いますが、スーパークリエーターが職業人として成功しているか?という疑問もあれば職業倫理や技術的な哲学等、師匠(メンター)たる器を持っているかは未知数です。

従来のプログラマがおかれた環境(困難にぶち当たっても自助努力のみを押し付けられ孤独になる)からの脱却を図るためのメンターというのは理解できなくもないですが、プログラミングスクールがそのようなことを全面に押し出されても、「本当にメンターが必要なときは、実際に会社や現場に入ったときであり」、プログラミングスクールの講師がそこまで面倒を見るのは金銭的にも(講師の)技術的にも怪しいものです。

もちろんですが、学習者が学習において孤独を感じ、メンターが必要ということでプログラミングスクールの門をたたくことを否定はしません。
先輩やメンターに助言を乞うことは否定しませんが、本来、プロとして活動するということは、技術面では先輩やメンターから独立して「孤独」の中でプログラミングを行うことになります。そこには、プログラミングスクールのメンターの存在というのは私にはなじみません。

まとめますと、

・期待されるメンターの役割を持った人間がそもそもいないかいたとしても希少
・メンターとは本来、技術だけでなく、職業倫理や哲学といったことも持ち合わせてないとダメ、スクールというより組織で必要
・もしあなたが、「この人から教えを乞いたい」と思えばそれはそれでよい

ということが言えます。

老兵は死なず、AIと踊る

AI時代のプログラミングスクールとの付き合い方 Part1

老兵は死なず、AIと踊る

この記事は、『50代半ばのじいさんが、AIを目の当たりにした『大学に入ってから自分の無力感がエグい』という大学生にかけることば』『AI時代のコードレビューは“理解”ではなく“責任”を見る』との続編になります。

AI時代に入り、私も当然ですが、『遅れないようにしよう』と思いながらも日々精進しているのですが、
『AIで書いたコードを、
細部まで理解できていないままコードレビューに出すのは、
職場でも最も信用を落とす行為なので、気をつけましょう笑』
この発言ですが、要はプログラミングスクールをやっている方の発言でした。これは今流行しているSNSのマーケティングで、愚かにも私はプログラミングスクールの広告にマジレスをしたということになります。ということで、文章はそのまま残しますが、投稿へのリンクは外します。これは『宣伝を拡散しない』ということもあるのですが、これから「プログラミングスクールではなくAIから学べ!」という話をするので、営業妨害をする意図ではないことを明確にするためということもあります。

プログラミングスクールは最近特に、雨後の筍のごとく出ており玉石混交状態で、中には悪徳業者もいらっしゃいます。そいう悪徳業者のはSNSを使って広告を出して素人から高額な授業料をもらっているようです。そういった中には『35歳からのSESについて考える』でコメントしている通り『IT業界の実態を良く知らない人達をとりあえずSES(ITエンジニアの派遣)に放り込んで搾取する』という実態があります。これらの悪徳業者は

スクール → SES

というルートを確立しており、粗製乱造で商品(エンジニア)を作り会社へ送り込むという、エンジニアをモノ扱いして商売を行っており、IT業界への入り方としては注意が必要(あまりお勧めできない)です。もちろんきちんとした業者もあるでしょうし、上記のSNS発言の会社が、このようなことをやっているかどうかは解らないということは改めて付け加えておきます。

自身のプログラミングスクール開校の模索

 ちなみに、私ですが、高校生相手のプログラミングスクールをやろうかと考えておりました。それなりにリサーチを行い、「情報の教科書」を購入したり、大学入学共通テストを受けたりしました。点数ですが、70点ほどでした。意外に低いと思われるかと思います。私は高三の時に第二種情報処理技術者試験に合格しており大学にはいるとアルバイトでプログラムを組んでいましたのでこの点数には一瞬納得できませんでした(ちなみにサンプル問題を解いたときは90点台だったので油断していたというのもあります)。
改めてこういう試験を、自身が受けてみると、ある種の試験の目的と限界が解りました。私は受験が苦手だったのですが、やはりそこは実践と異なるようです。これだけだとただの愚痴になるので、補足しておきますと、細かい用語の定義を問う問題については、プロが見れば「知らんわ」とか「知る必要があるか?」というのがありそこはわざわざ勉強しなくてもと思うのですが、学生諸君はきちんと勉強する必要があるでしょう(テストなので)。

話は脱線しますが、ついでに英語も受けました70点ほどでした。こちらも意外に低いと思われるかと思いますが、大学入学共通テストの英語で70点以上をとれるのなら、ほぼ間違いなく英語を使って仕事ができるかと思います。ただし、文章は全部読んだ上で回答するのとリスニングは相手の言うことを分かった上で回答する、という条件がつきます。巷には大学入学共通テストのテクニックが存在しますが、それを使って高得点を取っても生きた英語ができるかどうかは怪しいです。なので、将来英語の仕事に付こうかという人は「全部を読んだ上で回答する」というスタイルでやった方がより実力が付く(将来困らない)というか、そのようなやり方で満点やそれに近い点数をとる学生もいるとも思えます。もっとも少しでもいい大学に行くのなら、テクニックも必要なことは言うまでもないです(まぁ人生が掛かっているので)。

話を戻しますと、ここまでリサーチをしたのですが、今はプログラミングスクールをやることは中止しています。
なぜかというと、先に書いたように情報テストの実用性についての疑問(とそれを教えなければならないある種の苦痛)もあるのですが、

2025年現在、本人にやる気があればプログラミングスクールに通わなくても、「AIに聞けば」色々教えてくれるようになった。

というのが大きいです。

自身のAIによる学習例

最近ですと私の場合は、

ScratchとRustの言語のチュートリアル、llama.cppのコードの読み方(およびLLMの考え方)についてChatGPTに聞いて勉強しています。

llama.cppというのはローカルAI(LLM)の実行ツールで、つまり自宅のマシンでChatGPTのようなAIサーバーを立てられるものになります。その内部構造について知りたいとき、昔ならコードを手当たり次第に読んでいたのを、今ならChatGPTに『C++は解るのでポイントを教えてくれ』と言ったらそれなりの指針を返してくれます。
https://chatgpt.com/share/69537291-28d4-8006-97c9-a832786fbd92
一往復だけのやり取りを載せていますが、かなり整理されたものが出てきています。

プログラミング初心者の方は上の文章を読んでもわからないかと思いますが、初心者の方は『私はプログラミングの初心者でまったく一から勉強したいのですが、どうすればよいでしょうか?』とすれば、ChatGPTは上手に相手をしてくれます。
https://chatgpt.com/share/69537347-092c-8006-843d-e774b22972fb

ここで返された言葉の意味が解らなければ質問すれば良いです。例えば、「C/C++やJava」が解らなければ「C/C++やJavaとは何ですか?」とか「言語とはなんですか?」と聞けば回答を出してくれます。

「ChatGPTのような生成AIが教師の代わりになれるのか?」という疑問が沸くかと思いますが、少なくとも私はChatGPTとのやり取りで「プログラミングスクールはやめておこう」と思うようになりました。それほど信頼性が高く、初心者が高額なお金を出してスクールに行く価値があるのか疑問に思うほどです。少なくとも、私はお金を取れるとは思えません。

もちろん注意事項もあります。ChatGPTやGeminiが信頼できるというのは『ネット上に溢れている情報で、特に初心者に対しての情報は、多くのチュートリアルがあるのでAIはそれを模倣している」ということが言えますが、あまり一般的でないことや初心者あるあるでない、ややこしい質問をされると、AIも混乱するでしょう。そして一度混乱したAIを元に戻すのは、初心者だけでなく中級、上級者にとっても難しいかと思います。(この場合の有効な手段は、最初からやり直しになりますが、今までのやり取りが消えてしまうので、それはそれで面倒です)。
AIは『人間に寄り添いすぎる面』があります。本来行うべき「厳しい意見」というのを避ける傾向にあります。AIとの距離感の作り方はあらゆることに言えますが、一つの共通課題かと思います。
そうはいっても、プログラミングというのは最終的に、コンピューターで動くものを作るという行為になります。つまり「動くものができるかどうか」ということで検証可能です。AIが間違っていたとしても、動かないことで間違っていることが分かります。そこで、「これ動かないんだけど」とAIに聞けばよいです。場合によっては、何度質問しても、一向にバグが直らないことがありますが、その場合は、仕切り直しをしたり、違う課題をやってみる、掲示板で聞く、自分で考えてみる、などをやってみることになるでしょう。

このやり方の最大の長所になるのですが、このようなプログラミング学習が、そのまま「バイブコーディング(AIによるコード生成)」に移行できるというところです。特に、AIへの「動かない」というフィードバックはそのままバイブコーディング時代のデバッグに通じます。
ちなみに、ネットでは「バイブコーディングで爆速開発!」とかありますが、私自体は現時点ではバイブコーディングに懐疑的です。プログラミングに限った話ではないですが、実際にAIが混乱する様子を観測していると現段階でのバイブコーディングについてはまだ様子見を行っています。また私は独自のプログラミング言語を開発している関係でバイブコーディングを行うことができないということもあります。
もっとも、まったくやらないわけにはいかないので、ブログネタでやるほか、Youtube上ではバイブコーディングを行っている様子がアップされていますので良く見ています。

すこし話を戻しますと、よく言われるプログラミング初学者に対しての質問で「作りたいものをはっきりさせる」というものがあります。つまり目標を持ってプログラミングすると覚えが速いということです。これ自体は否定はしませんが、私自身は「コンピュータが好きだからプログラミングの勉強をした」ということになります。先ほどのChatGPTとの対話では、「何のためにプログラミングを学ぶか」について、ChatGPTは画一的な動機ではなく、様々な動機を提案しています。これはこれで教師としてはある意味人間を超えているとも言えます。人間の場合、どうしても個人の考え(哲学)が入ってしまいます。プログラミングスクールで学ぶ場合、学習者は講師の個人的な考え(哲学)に影響されます。ただしこの哲学は強制されるものではなく、あなた自身が自主的に追及するものになるかと思います。

私の場合は「コンピュータが好きで仕組みを理解したい」ということでしたが、このやり取りを掲載しておきます。
https://chatgpt.com/share/69550def-2290-8006-a2c5-3f4d560915f6

まとめ

以上、最近はAIによる自己学習も大分よくなったかなと実感しています。もちろんですが、AIによる自己学習でも壁にぶち当たることがあります。AI相手や掲示板なども使ったが上手くいかず、どうしてもプログラミングをやってみたいという場合は、プログラミングスクールに行くことも有効な手段だと思います。独学vsスクールという二者択一ではなく、プログラミングをマスターするという目的に対して、どういう手段をとるか?という選択でしかないです。

「優良なプログラミングスクールにおけるメンターの存在について触れられていない」という指摘を受けて、Part2として記事をまとめました。

老兵は死なず、AIと踊る

AI時代のコードレビューは“理解”ではなく“責任”を見る

老兵は死なず、AIと踊る

SNSの投稿で、

『AIで書いたコードを、
細部まで理解できていないままコードレビューに出すのは、
職場でも最も信用を落とす行為なので、気をつけましょう笑』

とあったのですが、分からなくもないのですが、「笑」というのが残念です。

比喩的な話になるのですが、昭和の時代『そろばん付きの電卓』というのがあった。つまり『電卓の結果が信用できない』ということでそろばんがついていたとのことです。
当たり前ですが、『電卓が信用できない』のなら『そろばんのみ』使えば良いですし(電卓とそろばんで2回計算するので時間がかかっている)。令和の時代では、『電卓が間違えるはずがない』ということで、そろばん付きの電卓というのは見つからないかと思います。

もっとも、当時の発想として、実は『そろばんだけだったり電卓だけだったりすると、人間の操作ミスによる間違いがあるので、異なるデバイスで計算し互いに検算しあう』という意図があったかもしれません。

そう考えると
『AIで書いたコードを、細部まで理解できていないままコードレビューに出すのは、職場でも最も信用を落とす行為なので、気をつけましょう笑』
というのは、AIが完全ではないので理解ができます。
しかしながら、この発想は『そろばん+電卓』ということは意識しておいた方がよいかもしれません。

実はソフトウェアの世界では、「中身は知らんがそれを使っている」ということが既に何重もの階層構造の上に起こっています。
我々が何気なく書いているプログラムも、
 ・OS
 ・データベース等のミドルウェア
 ・プログラミング言語環境
 ・フレームワーク
といった基盤の上で構築しています。

さて、我々はOSのコードやらデータベースのコードを理解しないとプログラミングをしてはいけないでしょうか?
コンパイラが出力するアセンブラコードを理解できなくても良いのでしょうか?
フレームワークについては、全てを理解する必要があるでしょうか?

もちろんですが、2025年現在、『AIの出力するコードを無批判で受け入れる』のはダメでしょう。
しかし、『AI出力の細部を理解しないとダメ』という発想はソフトウェアエンジニアリングの観点からは問題があるということになります。なぜか?

そもそも、コードレビューは、ソフトウェアの品質向上、バグや問題を取り除くために行います。
AIの出力をコードレビューするということは、近い将来に発生する問題として、

「AIが作成した膨大なコードを人間がレビューし続ける。レビューが終わらない。」

ということになります。
せっかくAIにより開発のスピードが上がっても人間のレビューにより生産性が下がるということになります。

コード開発ということばかりに目をやると『コードの理解、レビュー』となりますが、ソフトウェア開発(エンジニアリング)の観点で見れば、これまでの歴史が示すとおり、
・階層化
・コードの再利用
・ブラックボックス化
と進化してきました。
その観点でみれば、必ずしも「細部まで理解する必要がないこと」は理解してもらえるかと思います。

では、コードレビューにおいて、どうも担当者が細部を分かっていないと判断したらどうすればよいでしょうか?
それは、担当者がサボったと認識するのではなく、さりげなく
「ここのロジックについて説明してくれますか?」
「どのように検証しましたか?」
と質問をすればよいでしょう。

『AIに任せた』と回答がくれば、

もし、そのコードが学習する価値があるものなら、「このコードは重要なので覚えてください」と言えばよいし、
もし、そのコードにバグがあるのなら、「AIのこのコードに問題があるので修正するかプロンプトを見直してください」と言えばよいです。

いずれにしても『理解していない=仕事をしていない』と決めつけるのではなく、きちんとレビュー対象のコードの重要性や品質を見極めたうえでレビューを行えば、電卓の結果をそろばんで再計算する必要がなくなるでしょう。

追記、この最初のSNSの投稿は、プログラミングスクール運営者の方の投稿でした。ということでプログラミングスクールとの付き合い方という記事にしました。

老兵は死なず、AIと踊る

なぜ日本のITは遅れ続けるのか

オブジェクト指向再考 連載目次

――誤解と判断力の欠如が生む構造的リスク

第1章 判断できない組織のリスク

日本のIT産業が遅れている理由は、単なる技術力の差ではない。
現場での「判断力」を軽視する文化が、構造的な停滞を生んでいる。

経営が「最短の正解」を求めると、エンジニアは思考よりも指示の再現を優先するようになる。
結果として、「仕様通りに作る」ことが評価され、「正しく判断する」力が失われていく。

この文化は、プロジェクトを一見スムーズに見せるが、問題の根を放置したまま進むため、後工程で破綻を生む。
残念ながら「仕様書」は常に正しいとは限らず、完璧でもない。
判断できないエンジニアは、間違った仕様に基づいてシステムを構築してしまうし、完璧でない仕様書を前にすると、手を止めてしまう。

判断を封じた組織は、問題が発生しても修正できない。
それが、「失敗を繰り返す日本のIT構造」である。


第2章 SNS・マスコミ・勉強会が作った虚像

数年前、ネット上で「staticおじさん」という呼称が生まれた。
あるエンジニアが「オブジェクト指向を使わない」という判断をしたことをきっかけに、
SNS上で「オブジェクト指向を理解できない老害エンジニア」として揶揄されたのである。

しかし実際の現場では、この「老害エンジニア」と呼ばれた人々こそ、
長年にわたりシステムを安定的に稼働させ、数多くのプロジェクトを支えてきた主力層であった。

だが、ネット記事や勉強会での誤解や簡略化が進むうちに、
「古い技術者=悪」とする物語が独り歩きしてしまった。
SNSや勉強会では、非エンジニアもこの議論に参加し、
「正しい技術の形」を安易に語る空気が生まれた。
それが、現場での健全な議論をも蝕んでいったのである。


第3章 SES構造と粗製乱造の危機

SES(システムエンジニアリングサービス)は、短期的には人員不足を補う仕組みとして機能している。
しかし、即戦力を求めすぎるあまり、エンジニアの自由な思考や技術習得の時間を奪ってしまう。

2025年現在、こうした安易な人材育成を政府が後押ししている面がある。
「デジタル人材育成のための『実践の場』開拓モデル事業」は、その典型だ。
本来は人材育成を目的とした制度であるが、現実にはSES構造の延命に利用され、
短期育成・早期投入による「粗製乱造」が進んでいる。

十分な学習機会がなくSESで派遣されたエンジニアは、正常な判断ができず、
SNS上の誤った知識の伝搬や、固定化された正解主義の文化にさらに晒される。
その結果、プロジェクトの現場では、思考を止めた「作業者」が増えていく。


第4章 経営者が問われる「誰を雇うか」

非エンジニアを安易に開発現場へ入れると、判断の混乱が起こる。
プロジェクトマネージャが優秀であれば協働は可能だが、
実際には「プロのマネージャ」はエンジニア以上に希少である。

経営者に問われるのは、「どんな人を雇うか」だけではなく、
「どんな判断を許す文化を作るか」である。
判断力を育てるには、失敗を許容する余白と、考える時間を保障しなければならない。
その余白を「余分なコスト」と見なす企業に、技術は根付かない。

例えば、「オブジェクト指向を使わない選択」や「既存の非オブジェクト指向資産を活かす判断」は、
適切な判断を行っている可能性が高い。
もちろん「オブジェクト指向を使う選択=不適切な判断」ではないが、
その欠点を理解している必要がある。

炎上プロジェクトは、「エンジニア」と「非エンジニア」を見分ける格好の機会である。
普段から技術論を声高に語る自称エンジニアが、炎上した途端に理由をつけて逃げることがある。
一方で、普段は口数の少ないエンジニアが、現場を立て直すことがある。

「プロジェクトに責任をとれる人がエンジニア」であり、
「正しい判断ができるエンジニア」は、最終的にプロジェクトをゴールへと導く。
経営者としては、このような人物を見分ける「目」が求められる。


結論 ――経営者が持つべき「技術を見る目」

技術力の本質は知識の量ではなく、判断の質で決まる。
正解主義が支配する組織では、判断力が失われる。
誤った知識の伝搬と即戦力主義は、経営が気付かないうちに、
組織の判断力を蝕み、日本のITの停滞を再生産している。

経営者がまず行うべきことは、「判断するエンジニア」を育てる環境を整えることだ。
それには、自身が技術に明るくなるか、信頼できるエンジニアやマネージャを確保することも重要である。
それができない限り、日本のデジタル化は、どれほど予算を投じても前に進まない。

AIがコードを書く時代になろうとしている今こそ、
経営者に求められているのは「正解を知る力」ではなく、
「判断できる人材を見抜く力」である。


この文章は、ChatGPTとの共同作業により作られています。

変数は「箱」か「名札」か?― 初心者教育から束縛モデルまでを考える

 以前、「変数は箱か名札か?」で動画を上げたのですが、あまりアクセスはなかったのですが、最近少しアクセスがあり、改めて見たら面白かったので、もう少し突っ込んでまとめてみました。

プログラミング教育の現場では、今も昔も「変数とは何か?」が最初のハードルです。
伝統的には「変数は値を入れる」と説明されますが、
最近では「変数はオブジェクトに貼られた名札(ラベル)だ」と主張する声も聞かれます。

一見、単なる比喩の違いのように見えますが、
この議論の背後には、プログラミング言語の理論と設計思想の根深い違いがあります。
ここでは、初心者教育から理論的背景、そして実用上の含意までを整理してみます。


Ⅰ. 初心者教育での「箱」モデルの意義

最初に登場するのが、もっとも直感的な「箱」モデルです。

変数とは、値を入れておく箱である。

a = 1
b = a
a = 2

このとき、a の中身を 2 に変えると、b の値はそのまま 1。
学習者は「箱に入れた値を取り出して使う」イメージで簡単に理解できます。

C や C++ のように、メモリ上の領域が実際に割り当てられる言語では、
この比喩はきわめて正確であり、教育的にも有効です。


Ⅱ. 「名札」モデルの登場と混乱

一方で、Python や JavaScript では、変数の実体がやや異なります。
これらの言語では、変数はオブジェクトへの参照を持つ仕組みであり、
代入は「名札を貼り替える」動作に近いのです。

変数は、オブジェクトに貼る名札である。

a = [1, 2, 3]
b = a
a[0] = 9

ここで b を出力すると [9, 2, 3]
箱モデルでは説明しづらく、「名札モデル」の方が合うように見えます。

しかし、注意すべきはこの比喩も完全ではないという点です。
配列の各要素 a[0] にまで「名札」を持ち込むと、
今度は配列の連続性やメモリ構造のイメージが崩れてしまいます。
結果として、初心者をさらに混乱させることもあるのです。


Ⅲ. C/C++が示す「共存モデル」

C や C++ では、値型と参照型(ポインタ型)が共存しています。

int a = 1;
int &r = a;

このとき ra の別名であり、どちらを変更しても同じ領域が変化します。
つまり C++ は、「箱」と「名札」の両方の性質を明示的に区別できる言語です。

教育的にはこの構造が非常に有益で、
物理的なメモリ構造と論理的な参照概念の橋渡しを学ぶことができます。

ただし、ポインタや参照はプログラミングの初心者にとっては難しい概念である。


Ⅳ. 関数型言語における「束縛モデル」

さらに理論的な世界へ進むと、
「変数は値を入れるものではなく、“値(あるいは式)に束縛される名前”だ」
という考え方が登場します。

束縛(binding)=変数と式の対応を定めること。

Haskell などの関数型言語では再代入ができず、
変数は一度束縛されたら変更できません。

x = 1
y = x + 2

このとき xy は「箱」ではなく「式の定義名」です。
評価は遅延的に行われ、必要になるまで実際の値が求められません。

この仕組みは理論的には非常に美しく、
純粋関数・副作用の排除・数学的推論のしやすさといった利点をもたらします。


Ⅴ. 束縛モデルの強みと限界

束縛モデルの最大の利点は、式そのものをオブジェクトとして扱える点です。
たとえば、自動微分やDSL(ドメイン固有言語)の分野では、
式構造を保持して解析・変換する必要があります。

しかしその一方で、束縛モデルには現実的な制約もあります。

項目 束縛モデル(遅延評価) 参照モデル(即時評価)
抽象性 高い 低いが直感的
実装効率 低い(オーバーヘッドあり) 高い
デバッグ 難しい(評価タイミング不明) 容易
メモリ予測 困難 明確

結果として、実用言語の多くは参照モデルを基本にし、
必要な箇所だけ束縛的な振る舞いを導入する
設計を採用しています。


Ⅵ. 束縛モデルが主流にならなかった理由

    1. パフォーマンスとメモリ効率の問題
      遅延評価や式構造の保持にはコストがかかる。

    1. 最適化の困難さ
      コンパイラが静的解析しにくく、最適化しづらい。

    1. デバッグや可視化が難しい
      どの時点で評価されたかが分かりづらい。

    1. 実際に必要なケースが限られている
      自動微分やDSLなど一部領域に限定される。


Ⅶ. 現代的アプローチ:必要な部分だけ「束縛的」に

今日では、C# の Expression<T>
Python の sympy / jax
C++ の Expression Template など、
必要な箇所だけ束縛モデル的挙動を模倣する仕組みが採用されています。

つまり、
「束縛モデル全体を採用するのではなく、
その一部を道具として使う」
という方向に落ち着いています。


Ⅷ. 教育的まとめ:段階的理解のすすめ

学習段階 目標 モデル 教育上の重点
初級 値の代入と操作の直感的理解 箱モデル シンプルな心象で理解する
プロ(中級) メモリと参照の関係を理解 箱+参照モデル オブジェクト共有・ポインタ・参照
研究レベル 抽象的な束縛・遅延評価・純粋関数 束縛モデル 数理的抽象化・関数をデータとして扱う


Ⅸ. 結論:「名札」は“箱”を超えるものではない

「名札」や「束縛」という比喩は、
実行環境や抽象化の観点を説明する一つの手段に過ぎません。

しかし、それを「箱より優れている」と主張するのは誤りです。
比喩はあくまで教育のためのツールであり、
言語設計の本質はメモリ・参照・評価戦略の選択にあります。

実務的な観点から見れば、
「箱モデル+参照の理解」で十分に事足り、
束縛モデルは特定分野での理論的・実験的意義を持つに留まります。


最後に:比喩の目的を取り違えない

変数を「箱」と呼ぶのも、「名札」と呼ぶのも、
プログラミングという抽象世界を理解するための足がかりに過ぎません。

重要なのは「どの比喩を使うか」ではなく、
その比喩がどの抽象化層を説明しているのかを意識することです。

プログラミング教育において本当に求められるのは、
比喩をめぐる正しさの議論ではなく、
学習者が言語の階層構造(値 → 参照 → 束縛)を自然に昇っていけるように導くこと
なのかもしれません。


この文章は、ChatGPTとの共同作業により作られています。

エンジニアと非エンジニア

オブジェクト指向再考 連載目次

―「staticおじさん」というモデルが歪められた物語―

「staticおじさん」という言葉が生まれたのは、十数年前のあるネット記事がきっかけだった。
とあるエンジニアが、「オブジェクト指向がわからない」と率直に書いた。
コメント欄では賛否が分かれ、議論は次第に激しさを増していった。
やがて、その人物の主張の一部だけが切り取られ、「オブジェクト指向を理解できない頑固な人」というレッテルが貼られた。
その象徴的な呼び名として登場したのが「staticおじさん」である。

つまり、“staticおじさん”にはモデルが存在した。
だがその人物は、もともと技術を語っていただけだ。
しかし、ネット文化は誠実な議論よりも“わかりやすい敵”を好む。
その結果、個人の発言が物語化され、「古い技術に固執する老害エンジニア」という虚像が作られていった。

オブジェクト指向の議論という技術的テーマが、いつしか「世代対立」「価値観の断絶」といった社会的物語にすり替えられたのである。
“理解しようとしない人”という構図は、読む人に安心感を与える。
自分は「新しい側」に立っているという錯覚をくれるからだ。
こうして、一人のエンジニアの誤解が、ネット全体の“物語”に変わっていった。


勉強会と「リアルな虚像」

やがて、この物語は一部の勉強会にも持ち込まれたことがある。
勉強会自体は知識を共有する素晴らしい文化だ。
ただ、非エンジニアや若手が参加する場では、
「staticおじさん=古い考えの象徴」というイメージが語られることがあった。

そこには、本来の人物像も、元の記事の文脈も存在しない。
ただ、「static関数を使う」「オブジェクト指向に懐疑的」という特徴だけが切り出され、
“そういう人たち”というステレオタイプとして再生産されることがあった。

実際、当時の技術コミュニティでは、
「なぜそう考えるのか」よりも「どちらが正しいか」が重視されていた。
正解主義の文化の中で、
“反対意見を持つ人”は「理解できない人」として扱われた。
そしてそれが笑い話として語られることで、
“老害”という言葉が社会的な正義の衣をまとったのである。


「staticおじさん」は誰だったのか

本当の“staticおじさん”とは誰だったのか。
それは、一人のエンジニアの名前ではなく、
「自分の考えを曲げずに語ろうとした人」そのものだったのかもしれない。

技術は時代とともに変わる。
だが、変わらない信念や疑問を持ち続ける人は、いつの時代にもいる。
その存在を“老害”と切り捨てた瞬間、
私たちは「考える自由」そのものを失う。

オブジェクト指向のメッキが剥がれた今、
私たちはもう一度、あの議論を思い出すべきだ。
それは「正しさ」の争いではなく、
“責任ある思考”をどう持つかという問いだったのではないか。


責任ある物語へ

物語は人を動かす力を持つ。
だが、嘘の物語は、いつか誰かの現実を壊す。

「staticおじさん」という言葉を笑ったあの日から、十数年。
オブジェクト指向の理想は現実に疲れ、
AIがコードを書く時代になろうとしている今、
私たちはなお物語を作り続けている。

だからこそ、今こそ「責任ある物語」が必要だ。
誰かを貶めることで安心を得る物語ではなく、
異なる立場を理解し、語り合う物語を。
それが、技術文化を再び人間の手に取り戻す唯一の道だろう。


この文章は、ChatGPTとの共同作業により作られています。

「staticおじさん」現象とは何だったのか

オブジェクト指向再考 連載目次

―「クソコード」批判に姿を変えたネット社会の同調圧力―

前回、「クソコード」という言葉がバズワード化していることについて触れました。
今回は、少し歴史をさかのぼって「staticおじさん」現象を振り返りながら、
“コードの正しさ”がどのようにして社会的な信仰に変わっていったのかを考えてみたいと思います。


「staticおじさん」というレッテル

「staticおじさん」という言葉を聞いたことがある方も多いでしょう。
2010年代初頭、オブジェクト指向が声高に唱えられていた時代、
C言語的な書き方――たとえばstatic関数やグローバル変数――を使い続けるベテランエンジニアを
揶揄するために生まれたネットスラングです。

当時、オブジェクト指向は“正しい設計思想”として教育現場でも現場でも広まり、
メソッド呼び出しこそが美徳であり、static(関数)を使うことは“時代遅れ”だとされていました。
しかし今振り返ると、彼ら(staticおじさん)が使っていた手法の多くは、
単なる無知ではなく、実務的な妥協や効率化の知恵だったように思えます。
プロジェクトの制約、納期、パフォーマンス、チーム構成――
そうした現実の制約を理解したうえで“あえて”選ばれた手段であったことも少なくありません。


「信仰」としてのオブジェクト指向

オブジェクト指向の時代には、「staticを使うのは悪」という単純な善悪構造が形成されました。
その背景には、エンジニア教育や資格試験、ネット上の設計論争などを通じて
「OOPこそが唯一の正解」とされる雰囲気があったのです。

この構図は宗教的です。
人々は“正しい設計”を信じることで安心し、
他者の異なるやり方を排除することで、自分の信仰を強化していきました。
それは技術的な議論というよりも、
「自分が正しい側にいる」という心理的な安定を得るための行為でもあったのかもしれません。


繰り返される「同調の構造」

staticおじさんを笑っていた人々が、
いま“クソコード狩り”をしているとしたら、
それは同じ構造の繰り返しです。

かつて“staticおじさん”を嘲笑していた人々の中には、
いま現場を離れてしまった人も少なくありません。
壮大なオブジェクト指向の実験の果てに、
多くのプロジェクトが炎上し、多くの人が疲弊しました。
その中で「失敗の原因は古いやり方にある」として、
staticを使う人々が“悪役”として語られたのです。

時が流れ、オブジェクト指向の幻想が薄れた今、
新たな“敵”として登場したのが「クソコード」でした。
コードの品質を語ること自体は重要ですが、
他者のコードを嘲笑し、排除しようとするその姿勢は、
十年前の“staticおじさん狩り”とまったく同じ構造をしています。

人を揶揄する文化は定期的に生まれ、やがて消えていきます。
そのたびに誰かが傷つき、誰も幸福にはならない。
そこに残るのは、「正しさ」を求めすぎた社会の冷たさだけです。


「正解主義」とどう向き合うか

この現象の根には、「正解を求める文化」があります。
多くのエンジニアは、「何が正しいのか」を明確にしたいと願います。
しかし、プログラミングという行為の本質は、
常に“仮の正解”を探りながら進む試行錯誤の連続にあります。

「わからないままにしておく」ことを許せない風潮は、
議論を貧しくし、思考を停止させます。
結果として、「○○はクソ」「△△は正義」という単純化が進み、
技術が信仰へと変わっていくのです。


次回予告

次回は、こうした「正解主義」の文化がどのようにしてプログラミング教育や職場文化に根を下ろしていったのかを掘り下げ、
「正しさ」と「自由な思考」のバランスを考えてみたいと思います。


この文章は、ChatGPTとの共同作業により作られています。