変数名は「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と踊る

50代半ばのじいさんが、AIを目の当たりにした『大学に入ってから自分の無力感がエグい』という大学生にかけることば

老兵は死なず、AIと踊る

大学入ってから自分の無力感がエグいというXの投稿が話題になっているのですが、要約すると「AIの能力に圧倒されて、自信をなくした自分はどうしたらよいか?」という趣旨の投稿です。
文面を読んだ限りになりますが、この方は正しい感覚を持っているかと思います。
一方で、『この方がどうしたらよいか?』ということについては残念ながら責任を持った回答はできないです。いろいろ言えるでしょうが、この方の将来(つまり向こう50年)にわたってどのように行動すればよいか回答できる人はいないでしょう。
もっとも、何も言えないということでもないので、言えることについて話したいと思います。

1.自身の能力について客観的に見れている

 将来、エンジニアになる為には、このような『無力感』はある意味必要で、これはつまり自分自身を客観的に見つめることができた結果であるとも言えます。当然私もはるか昔に同じように自分の無力感を感じまして『それでもプログラミングが好き』ということで精進してきました。したがって「AIの方が圧倒的に良いコードを書く」、「自分は無力だと感じる」という反応はエンジニアとしてある意味順調な歩みを踏んでいます。

『なぜ無力感が出るのか?』というとこれは脳内にある種の矛盾が起こっているからのようです。
つまり、自分のレベルを客観視したときに、思ったより自分のレベルが低かったということに対して、脳内のある種の自己保護回路が反応して、拒否反応を起こし、このような無力感が出てるのではないか?と推測しています。
これを克服することがエンジニアとしての第一歩かと思います。

つまり勉強するしかないのですが、AIの出力をお手本としてそれを真似るようにしても良いですし、『なぜAIがこのような出力したのか?』考えるのもよいですし、『なぜ○○としたのか?』とAIに質問するのも良いかと思います。

ちなみに、AIが作ったモノという表現がありますが、今の生成AIについていうと『オリジナルの作成者』が存在します。つまりAIは模倣を行っている訳です。つまり一見、AIに丸投げして直ぐに答えが返ってくると思っているモノが、実は先人が苦労して作成したものであるということもできます。AIはそのエッセンスをアレンジしているということになります。

2.その職業に将来性があるのか?

 学生さんで今は勉強中の身なので、AIの出力が洗練されているように見えますが、細かく見れば完璧ではなく、プログラミング一つをとってもまだまだ熟練したエンジニアの方が良いコードが書けます。このあたりは大量生産された即席めんとお店で食べるラーメンとの違いということも言えます。もっとも将来的にこのような棲み分けができるのか?という問題は常にあります。伝統工芸と言えば職業として素晴らしいものと思われるかもしれませんが、実際には大量生産により駆逐された大勢の職人さんがいらっしゃいますし、絶えた伝統技術もあるでしょう。

自身が進もうとしている道が『機械と人間で棲み分けられる』のか『そのまま人間の職業としては絶滅する』かの見極めですが、向こう40年以上、職業として働く可能性がある若者に対しては『自己責任でよく考えてください』としか言えないのが実情です。

以下、ヒントになるかどうかですが、50代のじいさんがあと2,30年生きていく為に考えていることをお話してみます。
最近よく言われている、単なる通訳とか翻訳は『絶滅』の方向に行くように思えます。『通訳ガイド』も一見絶滅するように見えますが、今のところあと10年は持ちそうです。これは通訳ガイドが単なる言葉の通訳だけでなく、その場所のガイドをしたり、旅行のスケジュール管理をしたり、時には雑談相手になったりするところにあります。つまり様々な業務を複合的に行う必要があり、機械が全てを賄うのはもう少し時間がかかりそうです。通訳ガイドの仕事をもう少し説明すると、例えば若い旅行者は頼もうと思わないかもしれません。必要な情報は検索したら出てくるので、ガイドに払うお金は無駄なコストに見えるでしょう。お金に余裕のある人は、お金を払うことは苦にならないでしょう。加えて、『現地の人と交流ができる。』というのは旅の楽しみの一つでもあります。つまり、そもそも通訳ガイドを使うような人は『機械』ではなく『人間』がやるから良い(お金を払う)となります。

プログラミングに関していうと、脱落する人は多いかと思います。そもそもプログラミングと一口に言っても40年前と今では異なる部分が多いです。『Coboler』という言葉が25年程前に流行りましたが、これは当時需要が減ったCobolというプログラミング言語しかできないプログラマを揶揄する言葉ですが、Cobolしかできないプログラマはその時に転職をするか新しい言語を覚えるか?の選択を迫られました。同じようなことが今度は『全てのプログラマ』に突き付けられようとしているかと思います。
『どう作るのはなく何を作るのかを考えれば良い』という考え方もあります。要は今までは作ることに対してお金をもらっていたのだが、これからは自分でお金を生み出すようなものを作ればよい。ということのようです。この考え方ですが、通訳案内士の場合とはちょっと異なるということが分かるかと思います。このあたりにIT技術というある種の合理的な職種が持つ脆弱性が見えます。

一方で、あまり大声では言えませんが、今まで開発者として接してきた顧客の中にはIT技術は無いが長年IT関連で働いている人もいます。その人達はどのようなスキルを持っているのでしょうか?残念ながら私にはわからない世界があるようですが、ある一面ではありますが共通しているのは、下請け会社に対してごねるのが上手いまたは上手くのせて仕事をさせるのが上手い、上司に対してやる気があるように演じる能力に長けている等、その職場に居続ける嗅覚や能力が高い人が多いように思います。

最近やっている私のミッションの一つに『猫カフェの店長』があります。猫カフェ自体は大きくは儲かりませんが収入源にはなっています。当然ですが、人は生きた猫に会いに来るので『ロボット猫の猫カフェ』というのは今のところ成立しないかと思います。『ロボット猫が流行るとそもそも猫カフェに行く人が減るのではないか?』と思われるかと思いますが、うちの猫カフェですが、猫を飼っている人も来ます。猫は一匹、一匹個性があるので、新しい出会いを求めて猫カフェに来る人もいるようです。このあたりの考え方がAI(機械)によって消える職業と消えない職業をかぎ分ける目安になるかもしれません。ちなみに猫カフェを維持するミッションに「部屋や猫トイレの掃除」がありますが、これも今のところ人間しかできないようです。

失敗例を書いておいた方がよいかと思いますので追記します。AI時代のプログラミングスクールとの付き合い方にも書いているのですが、私は学生相手にプログラミングスクールをやろうとして、今はやめた方がよいと思いましてやめました。

3.大学教育について

 課題に対する評価が低いということで、『どうすれば良いのか?』ということになりますが、これは難しい問題です。
そもそも論として、生成AIが出した回答を見抜けない教授達がおかしいのですが、大学の評価が怪しいということは今に始まったことではなく、ある意味「失われた30年」の原因というのは大学にもあるということになります。

 これも昔話になりますが、私は大学時代よく「レポートの書く量が少ない」とコメントをもらっていまして落第ギリギリまたは落第点を食らっていました。ある時、課題とはまったく関係のない話を書いて量を埋めたのですが、このレポートを読んだTAがA判定を付けたのを見て、「あぁ、この大学は通う価値がないな」と実感しまして、後に大学をやめることになりました。当時はバブル崩壊直前で、私が通っていた大学はさながら就職予備校のようなものでした。学生が考えて悩むというよりも、与えられた課題をそつなくこなすという対応が求められました。このように学生に思考停止させて、社会の歯車として養成する機関はやめて正解だったと改めて感じています。

じゃ、「大学に行く価値はないのか?」ということになるのですが、『大学は、企業から新卒採用をとってもらう為の手段』と割り切れるかどうか、さらに『この大学を卒業したらきちんとした企業雇ってもらえるかどうか?』ににかかっているかと思います。

4. 日本の雇用慣行について

日本の雇用慣行、特に年功序列と終身雇用は、AI時代を迎える中で見直されつつあります。若い世代から見直されるのも当然です。終身雇用は労働者に安心感を与える一方、企業にとってはリスクが大きい制度です。1990年代以降のリストラや倒産は、この矛盾が露呈した結果でしょう。経済環境の変化に対応できず、企業は成果を上げながら雇用を維持できなくなり、労働者を非正規化せざるを得ませんでした。これも「失われた30年」の一因となっています。

さらに、AIや自動化が普及する現代では、終身雇用が労働者の成長を阻害する側面も見逃せません。例えば「働かないおじさん」と呼ばれる層は、制度に甘んじてスキルアップを怠る傾向があります。一方、SES(システムエンジニアリングサービス)や保険セールスなど、高ストレス職種では体力や精神力の限界から早期退職を余儀なくされ、非正規雇用へと転落するケースも少なくありません。

今後の課題は、終身雇用と成果主義のバランスをいかに取るかです。AIが人間の仕事を代替する中で、労働者が継続的にスキルを磨ける環境を整える必要があります。同時に、企業は非正規労働者の処遇改善や、リスクを分担する新たな雇用モデルを模索すべきでしょう。2025年現在も黒字企業がリストラを行う状況は、雇用慣行の抜本的な見直しを迫っています。

AIが今後どのように発展するか?日本の経済は今度上向くのか?、あまりにも不透明で私も含めて今の労働者にとって将来を見通すことは無理だといえるでしょう。ということで頑張ってくださいとしかいいようがないのが現状かと思います。

この記事ですが、「若者に寄り添っていない」という指摘を受けまして、プログラミングスクールとの付き合い方ということで若者向けの記事をアップしました。

老兵は死なず、AIと踊る

AIを使用した記事については素直にAIを使ったと書いた方がよいのではないか?

老兵は死なず、AIと踊る

世の中猫も杓子もAIで、「AIで○○しました」という記事が見受けられるが、最近ではさらにAIで生成した文章と思われるがそれを隠してしれっと記事にしているものも見かけるようになりました。
ちなみに、私のブログの場合は、どこまでAIが関与したかを、『この文章は、ChatGPTとの共同作業により作られています。』等と文末に書くようにしています。

もちろん、ある程度の文章を生成させようとすればそれなりのプロンプトが必要なのでそのオリジナリティはあるだろうが、AIに丸投げしたような文章はそのうち飽きられるかと思います。
私の場合、最近はAIが生成したと思われる動画を見ないようになった。生成AIが出だした当初はそのクオリティに驚かされたが、ある時からAIで作ったかどうかがなんとなくわかるようになり、違和感が許容できないようになった。もちろんこれはあくまでも主観になるが、ある意味人間の学習能力も捨てたものではないなと感心した次第です。

で、自分でAIと共同で記事を書くようになると他のWEB記事を読んだときに「これはChatGPTだ」と分かるようになってしまった。やはりそういう記事は読まなくなる。

だからと言ってAIを否定することもないしAIを使って記事を書くこと自体はよいが、例えば単なる情報ではなく、個人主観や主張を持った記事に関してはAIを使ったどうかを書いてもらった方が読み手に対してある程度安心感を与えるのではないでしょうか?

老兵は死なず、AIと踊る

35歳からのSESについて考える

老兵は死なず、AIと踊る

 以前にYoutubeでアップした動画(デジタル人材育成のための「実践の場」開拓モデル事業に与太話的に物申す)にコメントをもらいました。

 コメントされた方は、『この事業に参加してSES企業に入り2か月の研修で経歴詐称して客先に派遣されそうになった』ということで、大変憤慨されておられるようです。実は日本の中小のIT会社の多くはSES企業(つまり人売り企業)になります。見分け方の一つになりますが、入社したい会社の会社概要のページに「労働者派遣事業 許可番号 」というものがあればSESもやっている企業になります。もっとも全ての会社がきちんと労働者派遣事業許可番号をとっているか怪しいところもあるのでこの番号がないからといってSESをやっていないとは限らないので注意が必要です。

 SESとは「システムエンジニアリングサービス」の略で、要は派遣なのですが、派遣と言えば場合によっては違法になるので、客先常駐といったりSESといったりしています。私の知る限り少なくとも35年以上前からあり、30年前にはSESという言葉ができていたかと記憶しています。15年程前にはデジタル土方と言われるようになったかと記憶しています。経歴詐称も昔からあり、業務経歴書を見ながら面談をして『これは嘘だな』と思ったこともありました。ちなみに、建前上は面談(面接)はご法度ですが、実際にはコメント主のように『未経験者が偽って入ってくる』ということもあるので面談してある程度(実際の実力)を見てフィルターをかけないとお金をドブに捨てることになります。

このSESですが、悪しき習慣といわれていますが、一向になくならないだけでなく、最近では裁判沙汰になったりもしています。求職者の方々はこういうヤバイ会社には引っかからないようにしたいところですが、SESにもメリットというのは存在します。

SESのメリット

  • 顧客:雇用の調整弁になっている。正規や非正規でエンジニアを雇うよりも簡単に首が切れる。
  • SES企業:請負契約でシステムを構築するよりリスクがない。収支が読める。
  • 労働者:未経験者でも就業ができる(経験ができる)。短期かつ残業代がでるのなら正規雇用より儲かる。嫌なら後腐れなく辞めれる。向いている人がいる。

 顧客企業にとっては、非正規社員以上に合法的に労働者の首を切れることになります。あまり具体的なことは言えませんが、長い年月を経て多くの人が職場を去っていった後に、私自身も去ったことがあります(もっともこれは自らになりますので首を切られたというのはちょっと違います)。

本来ソフトウェア開発というのは請負契約で行うものなのですが、これは受注企業にとってはリスクがあります。特に顧客企業にソフトウェア開発の知見が無い場合は案件が赤字で終了する可能性があります。これを避ける為に準委任契約(SES契約)を行い、要は定額料金ではなく労働者が稼働したらその分課金するということを行います。
自ら作ったサービスを売るということもあります。こちらは王道と言えますが、当然にサービスが売れないというリスクがあり、赤字になれば、SES契約でエンジニアを売り、日銭を稼ぐという手段に出ます。
このようにSES契約が全て悪ということもないのですが、一度SES契約の味をしめると企業自体が努力をしなくなります。つまり請負契約で失敗しないように経験を積むとか顧客が求めているサービスをひねり出すという努力をしなくなります。

労働者にとってのメリットは『SESは未経験者の登竜門』ということも言えます。『経歴詐称はどうなるんだ?』と思われるかと思いますが、多くの場合、雇う側も経歴詐称であることを気が付いています。また、経歴書に詐称がなくても実際にプロジェクトに貢献していたかどうかというのもあり、実務的な観点からみると経歴詐称が一概に悪いとも断言できないところもあります。『じゃなぜ経歴詐称をするんだ』と思われるかと思いますが、これは受け入れ側の企業が書類選考をちゃんとしているという安心感を得る為にあります。もちろんですがプロジェクトによっては、経験者が求められていることがあったりするのでその場合に経歴詐称されると労働者があとで困ることになります。

SESのデメリット

もちろんSESのデメリットもあります。

  • 中間搾取、人月商売の横行が横行する こういう商習慣(人もモノとして扱う)が蔓延すると業界のレベルアップにならないです。個人のスキルに依存するのでチームとしてやプロジェクトの成長が期待できない。日本のITが伸びない理由の一つになっているかと思う。
  • エンジニアとして現場で使う以外の技術が身につかない 余暇を利用して新しい技術を吸収する(自己学習ができる人)が求められます。
  • IT土方として雇われてるのでエンジニアの社会常識が育たない 本人達は社会常識を持っていると思っているようで厄介ですが、ビジネスの話ができない人が多いです。実際にSESエンジニア上がりのある人に仕事の依頼の話をしたら、なぜかこちらが受注者として話が進んことがあり、こっちは発注者として仕事を頼んでいるのだが、なぜこのような勘違いをするのか相手の社会的な常識を疑ってしまった。ちなみに通訳案内士界隈も癖のある人が多いが、それでも友人と呼べる人はいるが、ITエンジニアの友人は残念ながら少ないです。
  • 顧客からのフィードバックが「契約終了」でエンジニアとしての見通しがたてられない 契約終了に関してエンジニア自身に具体的な原因がある場合、本来ならそのフィードバックがないとエンジニアが育たないが、そういう学習機会がそがれるので成長ができない。また、突然に契約終了となるとある種の失業状態になるので、エンジニアのライフスタイルが見通しにくい、40代ぐらいでSESが終了した場合割と困る。

労働者にとっての最大のデメリットは『SESは人売り』になるということで、これに耐えられない人が一定数います。このような方はSES企業には近づかない方がよいです。

ちなみに、私自身は総合的にはむしろSESで客先に常駐する方が気が楽な面があります。それでも会社として誰かを客先に出すというのはやりたくないです。

アドバイス

最後になりますが、未経験で35歳からIT業界に転職させる方に対してアドバイスするとなると以下の点を考慮されたうえでどうするか考えたほうがよいかと思います。

  • 未経験者がIT業界に入るとSESに捕まる確率が高い。実力がないうちはSESを避けて通るのは厳しい。SESに関しては向いている人と向いていない人がいるので、SESが嫌なら日本のソフトウェア開発会社は避けたほうがよい。
  • 本来、中途採用となると即戦力が求められ、新卒採用とは異なることを理解する。先輩とか上司に頼ることはできないと考えたほうがよい。
  • そもそも、SES企業の先輩とか上司自体がエンジニアとしてもいわゆるメンターとしてもきちんとしているかどうか怪しい。
  • 職場環境やその会社の業界の位置づけ、今やっている仕事等を考慮すると、キャリアアップするには転職が必要となる場合がある。実力が付いたらそれに相応しい会社に転職することも視野に入れる。
  • その職場に居続けるという選択肢もあるが、SES企業の場合、終身雇用との相性が悪い(辞めていく人間が多い)。その会社の規模や将来性、社歴と年齢構成(例えば創業から40年のSES企業で、50代の社員が少なく若い人しかいない会社というのは歳をとったら辞めていくと考えたほうがよい)、等を考慮する必要がある。例えば、今、新卒で入った会社で本当に将来性がないのか?、定年まで働けないかを今一度自問自動したほうがよい。
  • IT業界は『モノづくり』範疇に入るが、モノづくりの難しさ(完成させなければならない)を理解して、自分自身がモノづくりの適性(プログラムが意図どおりに動くと何とも言えない高揚感がある等)があるかどうか見極める。
  • 仕事に対しての困難さをどこかで楽しめるようでないと厳しい。
  • 自己学習を続ける必要がある。平均、一日に2,3時間は勉強時間を確保する必要がある。もちろん仕事が忙しいときは仕事に集中する必要がある。暇なときに勉強ができるかどうかがカギになる。
  • AIの台頭についてアンテナを張る。悲観的な見方をすると将来は開発の仕事はAIにとって代わられる。それが何時かということで他の職種も並行して勉強しなけれならない。

と厳しいことを書いていますが、実際には、きちんとできていないエンジニアが多いのも事実です。また、仕事が好きになれるのなら割と何とかなったりします。(私の場合、コンピュータが動いている様をみるのが好きで、面倒な顧客対応をしてイライラしてたのですが、そのあとコンピュータをいじっていたらやる気が出たりしてました。)

SES契約についてChatGPTで遊んでみました。

追記、少し別の角度ですが、AIによる自己学習の可能性について、プログラミングスクールとの付き合い方という記事にしました。

老兵は死なず、AIと踊る

怖いわChatGPT

老兵は死なず、AIと踊る

 クソコードを書けの記事でChatGPTを使いながら論点の整理をしていて、ChatGPTの指摘がなかなか面白いのと、どうもおべっかが過ぎるので他の記事はどうなんだろうということで、過去の記事をChatGPTに入れました。おべっかを除けば指摘はなかなか的確に感じ感想文のトーンから判断すると「つまらない記事」というのがあるんだなと気づきました。ちなみにChatGPTの指摘は有用で私自身はためになるのですが、今のところ過去の記事自体を修正するのは控えています(校正はやっています)。
「まぁ、AIが作った記事ってつまらんよね」と思っていたのですが、オブジェクト指向再考についていろいろ議論をしてましたところ、なんと途中からクソコードを書けオブジェクト指向再考についての記事の類似点を指摘しだしました。

やりとりはこちら

 こちらとしては、オブジェクト指向再考についての議論をしているつもりでしたが、ChatGPTがいきなりクソコードを書けとの類似点を指摘してきました。長いのでタイトルを出しますと「共通している本質」のところになります。ChatGPTの指摘が「つまり、どちらも“思考停止の信仰”からプログラマを解放する話なんですよね。」ということで逆に私が「なるほど」と思ったのですが、私自身はそこまで明確に自覚していませんでしたが、言われてそうだと気づいた次第です。

私自身、ブログやYoutubeをやるときに心構えとして「表層的だったり扇動的な議論ではなく、本質を追求する」とやっておったのは事実で、改めてそれを指摘された次第です。ChatGPTの指摘に「余計な指摘をしやがって」と思うと同時に、「こいつは良く分かっているな」というある種の満足感も得られました。

いままではChatGPTは主に文書校正とか簡単な論点チェックのみ使っており、あまり真剣に使っていませんでしたが、プログラミング関連の議論で、今回なかなかの突っ込みを見せてきましたのでその技術革新に驚きました。

このブログもしばしば過去に様々な議論を行ってきました。この議論はもちろん「世間の誤解を正す」という目的もありますが、「有益なツッコミによって自分自身、新しい発見をする」というものもありました。つまり相手からの反論を自身への攻撃とはみなさないで、「何が言いたいんだろうか?」とその意図を考えるようにしてました。つまり相手の話を聞くようにはしていました。もっともこちらは十分に下調べをしてから書くので簡単には反論できないのも事実で、特に感情的な人にとっては逆襲をうけたでしょう。ちなみにこの記事のコメント欄の「あいださん」2016-02-22 13:10:37(投稿)が理解されているとおり、私としては「変なコメントでも議論を続ける」ことが誠意を示しているつもりでした。

もっとも、上記の記事のあいださんの前のnagiさんとのやりとりですが、今、読み返すと「不毛」の一言につきるかと思います(10年経った今読み返すと論点が直感的にわからないのと、それが分かった時のレベルの低さを鑑みるとがっかりしました)。また、このやりとりのあと、当時としても明らかに不毛なコメントが入ってきたのでコメント欄を承認制しました。

コメント欄を承認制にしたので、有益なツッコミもなくなり、ある種つまらなくなったのですが、私自身通訳案内士としての活動も開始したので、あまりプログラミングについては記事を書くこともなかったのです。

今回改めて、「クソコード」で記事を書くにあたり、当然、AI(ChatGPT)を利用した次第ですが、ChatGPTの場合、傾向としては相手に寄り添うような表現を使うが、きちんと反論をしたり、こちらが気が付かない論点を持ってきたりします。活発な議論ができることになります。

つまり、ChatGPTを使うと私の中で議論が完結するという感覚になります。本来議論は人と行うものだったのですが、なんとも言えない味気ないものになったと同時に、私自身はそれで満足してしまっているわけです。

ELIZA効果など昔からAIを知っている人たちは、過度に機械との対話に依存することに警戒を持つのですが、ちょっとフェーズが変わったかもしれません。

というわけで当然この記事もChatGPTに評価させました。

老兵は死なず、AIと踊る