面白いnoteの記事を見つけました。
未経験でSES会社に入社したらスキルシートで経歴詐称されて会社都合退職した話
先ず、私としてはこの記事にいちゃもんをつけようという意図はなく、書いてあることはその通りなので、むしろ「もっと世間に広めないと」ということでリンクを張ります。
私が驚いたのは、一見するとITとは関係ない職種である夜職を10年やっていたIT未経験の方が、曲がりなりにも会社に採用されたことです。
ここ5年くらいでしょうか？「未経験者でも出来る！」みたいな感じで、転職サイトやらスクールやらが雨後の筍のように出てきます。こういう記事で警鐘を鳴らしたりしていましたが、昔はある程度自分で勉強した人がこの業界にチャレンジしていたような気がします。
長年この業界にいる人間からしたら「未経験者で出来るわけないだろ」と思いますし、ＩＴ業界は昔からブラックと言われていましたが、SNS時代に入りさらに悪い方向にいっているんだろうなと実感されるところにあります。
記事をよく読んでいくと当の会社ですが（異論はあるでしょうが）そこまで悪徳ではないかと思います。一応、事前にテストをしてさらに2か月研修をした上での、SES（経歴詐称）ということですが、これはよくある会社となります。
経歴詐称は良くないことではありますが、そもそもなぜこういう商習慣が成立するのでしょうか？
一番の理由は、「こういう条件でもプログラマーとして何とかやっている人がいる」ということにつきます。
ポイントは、2か月みっちりやれば、出来る人は最低限のプログラミングが出来るようになるということです。私の他の記事を見た方は「5,000時間勉強が必要なのではないのか？」と思われるでしょう。その記事にも書いていますが、私がBASICを出来るようになったのは3か月（概ね100時間）です。その後、プロになるのに「5,000時間以上」勉強したということになります。
会社に入って2か月ということは約300時間程度勉強したということですので、（プロになれるかどうかは別として）最低限のプログラミングは、（人によっては）出来るようになっているということです。
どのくらいの割合の人間が300時間で最低限のプログラミングができるかどうかは客観的なデータは持っていませんが、今までの経験上、体感では2割ぐらいは出来るようになった記憶があります。ちなみに、過去に私が勤めたわりときっちりとした会社は、大学卒業（新卒）で、おおよそ3か月ぐらい研修します。そして大体5割ぐらいはプログラミングが出来るようになっていました。
明確な根拠があるわけではないですが、要するに、概ね2,3カ月研修をすれば、2割くらいの人間は、最低限SESとして送り込めるようになるということになります。また、ちゃんとした企業でも正社員で入った新卒の半分はプログラミングが出来なかったケースがありました。ちなみにこの半分のプログラミングができない人達がプログラミングが出来るようになったかというと残念ですがあまりいなかったかと記憶しています。このように正社員で雇ってもプログラミングが出来ない場合、ほぼその会社のお荷物になるという実態があります。
2，3か月で最低限のプログラミングが出来ない場合、この人達がプログラミングが出来るようになるかというと難しいものがあります。「向いていなくても5,000時間やればプログラミングが出来るようになると言っていたのではないか？」とご批判がきそうです。一番大きな要因ですが、「本人のやる気」があります。言葉を変えると「馬を水飲み場に連れて行くことはできても、馬に水を飲ませることはできない」というイギリスのことわざに尽きます。そして大体、会社に入って最初の2,3カ月で「最低限の適性と本人のやる気」を確かめているということが言えます。
もちろんですが、やる気があっても3か月では無理という人もいます。そういう人は「規格外」ということなのでしょうが、SES会社ではそういう判断を「受け入れ先の企業」に委ねるでしょう。つまり出来ない場合でもSESとして就業させられることになります。
これは、SESの受け入れ企業が「経験者」しか受け入れないことが大きいかとおもいます。もちろん探せば「未経験OK」というのもあるかと思いますが、そもそも未経験者OKの会社がSESを頼むはずもないでしょう。
SESというのはいわゆる準委任契約ということで、請負契約と異なり「完成保証がない」契約となります。つまり出来なくても契約違反とならないということもあります。で、実態としてですが、結構な割合で、完成しなかったりします。実は「末端のプログラマに完成保証を行わせる」のは現実的でない。完成保証させるには仕様を確定させなければならない等それはそれで厄介だったり、あまり大きな声では言えないがそもそも完成させる必要がないもの（例えばデモの開発とか）もあります。そうすると「未経験者でも良いのか？」という風になりますが、「完成保証」はしなくても「作業した人間自体はプロフェッショナルが行った」というのが発注者側の論理となるでしょう。
一方で、誰でも最初は未経験者で、かつ最低限のプログラミングが出来る、つまりSESでの就業も実質可能ということであれば、ということで「嘘も方便」ということで経歴作業が行われます。また、実際にここからきちんと成果を上げるプログラマもいらっしゃるかと思います。そういう人は「嘘から出た真」と言えるかもしれません。また、完成しなくても「未経験者」ということがばれにくいということもあります。
話がややこしくなったかと思いますが、要するに例えば夜職の場合、お客に夢を語ったこともあったかと思います。たとえ夢が実現しなくても、それに対していちいち「嘘つき」という方がおかしい、というのが還暦を控えたおじさんの意見になりますが、一方で「いただき女子」のようなことをするとダメですよということかと思います。
政府は、DXと言ってデジタル化を推進しますと言いながら、このような業界のタブーについて触れないだけでなく、逆に推進するようなことをしています。本気でデジタル化を考えるのなら、このように人材を粗製乱造するのではなく、しっかりと地に足がついたキャリアパスを業界全体で考え、政府が後押しするようにしなければならないかと思います。
そもそも「経験者はSES会社に入らない」ということが言えます。私ですが、SES会社に行こうとも思いません。強いて言えばユーザ企業に直接売り込みを掛けるでしょうが、実は日本の大きな企業は「経験年数」以上に「見知らぬフリーランスと直接契約はしない」というのもあります。直接契約が難しいのはどちらかというと「利権」ということになりますが、このあたりがもう少し風通しが良くなると「人材不足」ということも減るかと思います。
また既にみてきたようにIT業界のSESとは「ライオンが子供を谷底へ落とすような場所」と言えるかもしれません。そうして這い上がった子供は当然ですが、親から独立します。そうすると親は別の子供を探すということになります。
それ以外の未経験が採用される理由ですが、「ルッキズム」ということもあるかもしれません。あまりこれ以上踏み込むと炎上するかもしれませんが、ご自身がルッキズムで採用されたかもといういうのは知っておいても損ではないかもしれません。私が担当したプロジェクトのメンバーにそういう人がいましたが、あまりプレッシャーを与えるようなタスクは割り振らなかった（サポート業務を任せた）経験があります。
プログラマではんく、「メンバーの雑用」、「補助」、「テスト要員」ということで採用されることもあります。これは最初から補助やテスト要員ということではなく、「こいつはプログラムが組めなさそう」と現場のリーダーが思ったらそういう割り振りをされるかと思います。私もそういう割り振りをした経験があります。
一方で、この方の記事を読むと「働く側の矛盾」を感じます。
記事を引用しますと、
『スキルが足りなくて辞めさせられるとかそういうことなら私も悪かったと思う』と書いてありますが、少なくともご本人としては、一定のスキルは身についているという認識だったように読めます。さらに『できない仕事を「できる人」として振られるのは相当なストレスだと思う』とおっしゃっています。つまり「額面通り2，3か月のスキル」で就業したいと思っていたかもしれません。
しかしながら、一方では、この方は、『社長は面接で「経験を2〜3年に見せなければいけない」と言っていたが、それはスキル面の話だと思っていたので面食らった。』と書いていますが、この方は「経歴2,3年のスキル」をどうやったら手に入ると思ったのでしょうか？
例えば「1週間で英語が話せる」とかでしたらほとんどの人が「眉唾」だと思うかと思います。同時に、2か月の勉強では、どうやっても２年の実務スキルは獲得できません。
（ちなみに、この人は「その会社に入って2か月間の給料をもらったかと思うし加えて、解雇予告手当ももらっているということでなかなかのやり手ではあると思う）。
「IT未経験」でネットを検索すると「未経験歓迎の会社や転職サイト」と色々出てきますが、実態としては経歴詐称を行うSESが多いということで、「まったくの未経験者がIT業界に就業できるほど甘くはない」ということは働く人も覚えておいた方が良いかと思います。
別の記事では、「AIを使って学習すればよい」と書いていましたが、「未経験者が就業目的で勉強をする」ということを少し真面目に考えてみます。
私の中では「5,000時間勉強しろ」ということなのですが、それではあまりにも漠然としていますので、就業までのステップごとに見ていきます。
もちろん、各ステップで、躓いたらAIを用いて補習をすればよいということになります。
Step1 基本情報技術者試験の合格
経験がないとなると資格を取得するのが策の1つになるかと思います。
さらに、プログラマーとして就業を目指すなら、最初に
基本情報処理技術者試験の科目Bの攻略
が優先されるかと思います。
たとえば300時間勉強すれば、基本情報の午後の試験は解けるようになるかと思いますし、300時間勉強しても解けなければ「向いていない」と判断しても良いかもしれません。
試しに一回問題を読んでみることをお勧めします。
例えばですが、令和5年の基本情報技術者試験の科目Bのリンクを掲載します（時間が経つとリンク切れになるかもしれません）。
正解はこちらです。
Step2 通信大学に通う
放送大学やサイバー大学などがあります。これらは安価で学習内容も最低限のクオリティは保証されているかと思います。
私は放送大学を卒業しましたので、放送大学について説明します。
放送大学の情報コース
ちなみに私は、目的が違いますが、放送大学に3年次で編入し卒業しました。例えば大卒や中途退学等の方は単位が認定されるので、卒業を目指すなら3年次編入を行い情報系の単位を取得して卒業を目指すということもできます。卒業までの費用はHPによると77万円とあります。3年次編入をすれば費用は大雑把にいうと半額近くになるでしょう。多くのプライベートのプログラミングスクールがほぼ同程度の数十万円になっていますので、どうせやるなら学位の資格をとった方が励みになるでしょう。
「大学を卒業したからどうやねん」という話もあるのですが、資格をとったり大学を卒業したりするということは「計画的に物事を進めることができる」ということでその点をアピールすれば、経歴詐称を行うSES企業ではなく、いわゆるクライアント企業への就業も目指せるかと思います。
また、アメリカの企業は本来、プログラマーで採用するにしても「コンピュータサイエンスの学位」を求めています。これはいわゆる基礎学力を求めていることになります。私のこの記事では大学教育について批判していますが、そうはいっても改めてシラバスをみると現在受講する方にとっての理想を追求しているかと思います。
（強いて、僭越ながらダメ出しを行うとすれば「OS」と「プログラミング言語処理（コンパイラの作成）」とかはあった方が面白いかとは思います）
また、就業に際してですが、中途採用ということになりますとどうしてもハードルが上がるかと思いますが、「門前払いを食らう＝SES企業」と考えて大丈夫かと思いますし、自社開発を行っている人材不足の企業にとっては「未経験者でも実力のある人」は歓迎するでしょう。
Step3 アルバイトを目指す
既に書きましたが、企業がなぜ「プログラマ」を正社員として入れたがらないか？「SESが跋扈するのか？」というと「プログラマとして雇い、プログラミングが出来ないと分かっても、安易に首が切れない」というのがあります。試用期間があるのでちゃんとしている会社はそこで判断をするでしょうが、「この人はプログラミングが出来ない」という判断をするのも日本の雇用慣行に馴染まないということが言えます。
一方で、アルバイトなら比較的楽に就業が出来るかと思います。私も大学生の頃、ゲーム会社や計測ソフトを作成している会社にアルバイトでプログラミングを行っていました。雇用者、被雇用者、両方にとって気が楽な面があります。
「未経験がIT企業に就職できる」広告として氾濫していますが、例えば転職サイトなどは「転職者のその後」をどこまでケアしているか怪しいですし、未経験＝スキルなしでもOKということではないです。
この話も嘘ではなく、むしろ「給料が出ているのかどうか不明ですが2か月間研修する」というのはむしろちゃんとしている方の会社になります。
経歴詐称はダメでしょうが、逆に「うちは経歴詐称はしません」と言われても、真の悪徳企業はそれを回避するでしょう。
また、今の多くの企業が実態として「法的にグレーな行為」を行っている面を鑑みると、個別の企業の問題ではなく、日本での働くことの問題としてとらえた方がよいかと思います。
ITエンジニアと名乗る人でも、プログラミングが出来る人と出来ない人がいます。これは「適性（向いている向いていない）」もありますが同時に「本人がどれだけプログラマーになりたいかという意欲（熱望）」もあります。「適性がない＝プログラミングが出来ない」というよりも実際は「あきらめる」ということが多いです。
また、現場でのプログラミングは思った以上にプレッシャーが掛かります。リンクの方もそれが分かったので辞めたということもあるでしょう。
中長期的な就業を考えるとSESというのはお勧めは出来ないので、きちんと勉強して資格や学位を習得すれば必要以上の寄り道をしなくてもよいかと思います。
基礎がしっかりとしていれば時代が変わっても、AIが台頭しても、その変化についていくことも出来るようになるでしょう。
前回、前々回で、概ね言いたいことは言ったので与太話的にはOKなのですが、多くの日本人プログラマが経験するであろう業務アプリの開発を想定した変数の命名について、「アーキテクト」的な補足を行います。
前回、前々回の記事の要点をいうと「命名は主観的になりがちなので、ルールを決めない状況でのレビューは危険」、「初心者は先ずはプログラムを書くことを学習する」ということを言ったのですが、今回の要点は、広域だったり業務用語に対応する変数の命名というのは、「個人の主観ではなくチームとしてきちんと定義しましょう」という話になります。
コーディング規約については既に説明しましたが、一言でいうと「命名についての一般ルール」で主にスタイル（単語の書き方や熟語の書き方が主軸）のルールになるかと思います。
一方で、「プロジェクト用語集」なるものも存在します。これは、プログラマが予め知っておいた方がよい、専門用語や業務用語についての項目と説明があります。
もっとも、実態としては「カバーしている用語の数が少なかったり」「ピント外れ」だったりもありますし、多くのプロジェクトでは「そんなものは存在しない」です。実は「プロジェクト用語集」に準じるものとして、「データベースの定義書（スキーマ）」が挙げられます。例えばECサイトなら、商品テーブル、注文テーブルなどがあり、以下のようになるでしょう。
商品テーブル：Goods
商品ID(id)
商品名(name)
単価(price)
注文テーブル(Orders)
注文ID(id)
注文主氏名(orderer_name)
送付先氏名(shipping_name)
送付先住所(shipping_address)
送付先電話番号(shipping_tel)
税抜価格(sub_price)
税込価格(tax_price)
送料(sipping_fee)
合計価格(total_price)
注文明細テーブル(Order_items)
注文明細ID(id)
注文ID(oid)
商品ID（sid）
個数(number)
税抜価格(price)
（当たり前ですが、細かいところは端折っていますが）、最低限、このような項目があるかと思います。
まったくの初心者の方はついてこれないかと思いますが、送付先とか送料、合計価格などの名称は馴染みがあるでしょう。各々の項目に英語名がカッコ内にあります。大体、この英語名がＤＢのカラム名（テーブル名とあわせて、グローバル変数名のようなモノ）になります。今回はこの英語名をAIでレビューさせます。
さて、これをChatGPTにかけた結果がこちらになります。
https://chatgpt.com/share/695f48aa-9450-8006-ae08-f7941ab5e69c
上記はChatGPTとのやり取りですが、ChatGPT,Gemini,Copilotでレビューした結果（それぞれの推奨の名前）を表にまとめます（やり取りの詳細は省略します）。
| 元 | ChatGPT要修正 | ChatGPT推奨 | Gemini | Copilot |
| Goods | products | products | products | products |
| name | - | - | - | - |
| price | - | unit_price | unit_price | - |
| Orders | - | orders | orders | - |
| orderer_name | - | customer_name | customer_name | customer_name |
| shipping_name | - | - | - | - |
| shipping_address | - | - | - | - |
| shipping_tel | - | - | - | - |
| sub_price | - | - | - | net_price |
| tax_price | - | - | - | gross_price |
| sipping_fee | shipping_fee | shipping_fee | shipping_fee | shipping_fee |
| total_price | - | total_amount | total_amount | - |
| Order_items | - | order_items | order_items | OrderItems |
| oid | - | order_id | order_id | order_id |
| sid | - | product_id | product_id | product_id |
| number | - | quantity | quantity | quantity |
| price | - | unit_price | price_at_sale | - |
| - | - | subtotal_amount | - | - |
さて、このようにデータベースの定義ができますとおのずと、「これらを扱うプログラム」で上記のカラム名に対応する変数名は、当然カラムの英語名を使うことになります。ORMを使えば自然にそうなりますし、手でSQLを書くことになっても敢えて違う名称にする意味はないだけでなくバグにつながるでしょう。
もちろんですが、これは「ある種の理想論」になります。現実的には「カラムの追加削除や変更」があり、それに伴い、プログラム上の変数名とDBのカラム名が時間と共に徐々に異なっていくこともあるかと思います。それを直すかどうかはまた別問題になります。
レビュー時のプロンプトについて
プロンプトの与え方ですが、私の意見になりますが、このように「関連するものはまとめて問い合わせる」方がよいかと思います。サンプルはDBのテーブル定義になりますができれば全部を与えます。プログラミングの場合（作成したプログラム全体）を渡した方がよいでしょう。
これによりAIが、意図を理解して用語間（変数間）の調整も考えてくれます。
感触になりますが、バイブコーディングが実用化されようとしている現在、このような割と突っ込んだ問い合わせにもAIはちゃんと対応できます。
ちなみに、私の場合のように「ある程度名前が用意できる」人はプロンプトとして、
「致命的な間違いを指摘してください」、「海外でも通用する名前を提案してください」
とかにすれば良いかと思いますし、まったく名前が思いつかない人は
「英語名を提案してください」
とすればよいでしょう。
AIの評価について
表を見ますと
・致命的なもの、誤字(sipping_fee)
・不適切なもの（Goods, orderer_name, sub_price, tax_price, number）
・推奨されるもの（price → unit_price）
があります。命名は主観と書きましたが、AIも同様に個性があるようで微妙に違うのもがあります。これらをどう処理するかは、話し合って決めることになりますが、基本的には、誤字や誤訳のように致命的なものを直せばよいかと思います。
ちなみに、tax_priceですが、表には出ていませんが、price_with_taxやgross_priceがあるのですが、そもそも「税込価格」という直接の対訳が無いようです。この対訳が無いという判断はAIではちょっと厳しいかもしれません。このあたりは命名を行う人の英語力ということになります。要はprice_with_taxのようにいかにも説明的な訳だったり、gross_price（合計金額）のように漠然とした訳を見たときに、『「税込価格」というのを海外ではあまり使わないな』と判断するのですが、これはこれで業務知識と英語力が問われるところです。
日本の場合、
・税率の違い（8%、10%）
・外税表示、内税表示がある
などがあります。海外でのこのようにしている国もあるのかもしれませんが、英語の名称（いかにも説明的な訳）を鑑みるとどうも税込価格と税抜価格をいちいち用語として区別することがないように感じられます。これらを踏まえて、ChatGPTと対話してみました。
https://chatgpt.com/share/695f63c1-7ef8-8006-a943-9e946dfce54c
完璧ではないですが、税込価格、税抜価格の候補として、
price_including_tax / price_excluding_tax
tax_included_price / tax_excluded_price
price_with_tax / price_without_tax
gross_price / net_price
base_price / total_price
があるようです。「これ！」という一組でなく、いくつもの組み合わせがあるということで、どれにするのかを決めるとともに、「このように変数名に対して複数の候補が考えられるときは、メンバー各位に命名を任せたらばらつく可能性がある」ということもプロジェクトリーダー・マネージャは頭に入れる必要があるかと思います。
まとめますと
・データベースと関連付けられた名称や、グローバル変数等、複数の人間が関与する変数名は予め決めておいた方がよい。
・税込価格など「専門用語」の場合、対訳も専門用語の対訳にした方がよい（ただし常に対訳があるとは限らないので臨機応変にする必要がある）。
・複数の対訳が考えられるときは「どれを使うのかを」決めておく。できれば使わない候補を（使わない変数名）とすると無用な混乱を事前に防ぐことができる。
・人が作るアプリケーションは大体決まっていることがあるので、慣用表現（GoodsではなくProducts）があればそちらを使う
ということが言えるかと思います。
あまり明確に言われていないかもしれませんが、以上のように考えながらスキーマ設計を行ったり、用語集の必要性を考えるのがシステムアーキテクトの仕事の1つになります。
変数名は「AIにレビューさせろ」Part1を公開したのですが、同時にAIから
「これは初心者向けの記事ではないのでは？」
と散々、指摘を受けたので初心者とスクールで教えようとしている方向けに補足を行います。どちらが最初でも構いませんが、初心者の方は本記事を最初に読んだ方がよいかもしれません。
例えばですが、Google C++ スタイルガイドや、Linux Kernel 2.6 Documentation- CodingStyle を参照してみてください。変数名の記載の項目になります。
何を言っているかわからないかと思います。それが答えです。
という、哲学的な問答はやめてストレートに言いますと、「まったくの初心者の方は、まずはプログラミングの書き方を学習するべきであり、コーディングスタイル（変数の命名だけでなく、あるべきコードの書き方の基準）は、後回しにしてもかまわない」ということになります。つまり今は考えなくてよい（もし気になるのならAIに聞け）ということになります。
それでも、気になる方はもう一度Google C++スタイルガイドの「命名規則」を読みましょう。引用しますと、
・命名に関するスタイルルールはかなり恣意的なものです
・あなたにとってわかりやすいと感じるかどうかに関わらず、「ルールはルール」と考えるようにしてください。
ということです。これの意味するところを大げさにかくと、「変数名は「AIにレビューさせろ」Part1」の記事になります。
加えて、日本人に対する補足を行います。（通訳案内士の観点になりますが）、日本人というのは「言われなくても規律を守る」民族のようで、一方で欧米（というか民主主義の国の人は）、「自由が基本、必要ならルールを作る」という文化的な違いがあります。主にアメリカからくるルールを日本人に当てはめると、必要以上に日本人が守りすぎるという傾向があるので注意しましょう。という話です。
上記の2つのスタイルガイドをみて、「言っていることは解る」という人はもう、命名規則については卒業ということになります。
「これでは不安」だという方は、一つ卒業試験をしましょう。上記の2つのスタイルは真逆のことを言っている部分がありますがどれでしょうか？
私が見つけた正解の1つは、
Linux Kernel 2.6のコーディングスタイルは、変数名の省略を許容しており、Google C++の方は許容していないということがあります。
（もっともどちらのスタイルもループカウンタは i でよいとしています）。
私の観点（理解）になりますが、これらの違いを補足すると、カーネルは基盤ソフトウェアで、Googleが作ろうとしているものはアプリケーションということも言えます。
コーディングの文化というか、作成しているもののレイヤーが異なります。
例を挙げると、変数の値を交換する swap関数 というものがありますが、Linuxの方はswap関数を作る方、Googleの方はswap関数を使う方ということです。
swap関数を C言語風に 書くと
void swap( int *a, int *b) {
int t = *a;
*a = *b;
*b = t;
}
となるかと思います。ここで、a,b,tと出ましたが、これに対して「変数名が、意味のない1文字だろ！」という人は（０ではないかと思うが）私の周りではいません。逆にここで変数名に対してとやかく言う人とは距離をとった方がよいです。（実は変数名以外には問題があります。ヒントは型、エラー処理あたりです）。
一方で、Googleの方は、swap関数を使う側、例えば、
swap( oldMachineStatus, newMachineStatus);
と言ったコードにフォーカスを当てているということになるかと思います。
コードコンプリートやリーダブルコードなど実績のある書籍を読むことをお勧めします。
「1文字変数はダメ。booleanは○○。」と言ったような断片的な情報ではなく、「なぜこのように命名すると良いのか？」についてできるだけ主観を抑える努力を用いて書かれているでしょう。
また、上記のようなスタイルガイドも併せて読むことを勧めします。書籍やガイドによって矛盾点が見つかります。それに対して『自分はどうするか？』と自問してみましょう。
2026年現在確認できる多くのコーディングスタイルでは、ループカウンタには i でよいとしていますが、意味のある名前にしましょうという書籍もあるようです。「○○にこう書いてある」ではなく、あなたの正解を見つけてみましょう。
（Grokの指摘を受けての追記）私自身ですが、アマチュア時代を入れると４０年以上プログラミングをやっており、使った言語も、BASIC、アセンブラからC/C++、Java、perl, php, Ruby、python, ADPと多岐にわたるので、「これ」と言った基準はないです。と言っても傾向はあるのでご紹介します。基本的にlinuxのコーディングガイドが近いかもしれませんが、業務アプリも作成するので混ざっています。下記を見てもらえますと私が「１文字変数はNG」、「booleanはis/has」と言われると反発する理由が良くわかるかと思います。
さらに、実際のコードがどうなっているかを調べることも重要です。
以下、Linux kernel 6.18.3 で適当に選んだファイル(acct.c)からの変数名（と引数名）を出現順で10個を列挙します。
acct
sbuf
p
ns
res
pin
work
acct
file
name
私には大変馴染み深い名称ですが、皆様どうでしょうか？
これだけだと何なので、同プロジェクトから適当に選んだpythonのファイル（check-perf-trace.py）からの変数名（引数名）を10個ほど列挙します。
event_name
context
common_cpu
common_secs
common_nsecs
common_pid
common_comm
common_callchain
vec
call_site
理解できるかはともかく、分かりやすい名前になっているかと思います。
ここまでで述べていない論点としては、「プログラミング言語」の言語的な側面があります。我々は言語を使うときに「単語」を使っておりますが、いちいち命名をする機会はあまりないかもしれません。命名と言えば、子供の名前など「固有名詞」が頭に来るかもしれませんが、どちらかというと「数学や物理の計算式の変数」だったり「作文の章立ての題名」だったり「その間の感覚のもの」だったりします。いずれにしても「内容を簡潔に説明するもの」として命名が存在しますが、プログラミングは文学ではないのであまり深入りはやめましょうという話になります。
変数名は「AIにレビューさせろ」Part2（税込価格の回答例）
-「命名に悩む時間」は生産性の無駄。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にレビューさせろ」Part2（税込価格の回答例）
-人間がレビューするよりAIにレビューさせた方がよいのでは？-
最近、SNSで「AIでコードを書いてみました（バイブコーディング）」という記事が氾濫するようになったのですが、一方でその書いたコードを出していない人が目につく。私の場合は、規模は小さいがAIに出力させたコードを公開していたりする。
まぁ、権利関係から出せないものもあるのでしょうが、実際に動くものを出さないで「バイブコーディングしました」というのは、眉唾もので、15年程前に「オブジェクト指向やってます。」という、「エアオブジェクト指向」と同じ香りがして、「エアバイブコーディング」じゃないかと疑ってしまいます。
（と言っていたら、こんな記事がGoogle discoverからサジェストされました。正直、部品レベルのものをいっぱい出して「限界を突破」と言われても・・・というのはありますが、コードを出している少ない例です。）
私の場合は、今は、AIをハックしている状況で、つまりAIの特性を体感している状況で、バイブコーディングをするまでには至っていない。もっとも、将来的にはバイブコーディングを視野に入れているので、今は色々試しています。
そういった中で、バイブコーディングの前段として、「AIにコードレビューをさせたらどうか？」ということで、コードレビューさせました。
ちなみに、コードレビューですが、こちらもネット上では色々言われていますが、『エアコードレビューではないか？』というのも散見されます。
というのもコードレビューは、ある意味コードを書くより高度な技術が要求されます。「なぜそう書いたのか？」ということに対して、本来ならレビューアーはレビューイーより高度な視点と経験が必要かと思いますが、実際には「ただのいちゃもん」に成り下がっている面もあります。
私が本格的なソースコードレビューがあるプロジェクトに参加したのは30年以上前になります。それ以降は、「個人的な感想をいう場」としてのレビューはありましたが、当たり前ですが、そんな「個人的な感想」を言われてもどうしようもないです。また、ここにも書いていますが、私自身は他人の書いたコードをレビューしてやろうとは思わないです。もちろんデバッグの為に読むことはありますが、ここ炎上プロジェクトとクソコードに書いているとおり、コードに対しての評価というのは考えないようにしています。
レビューさせたのは、私が開発しているプログラミング言語（ADP)のプロジェクトになります。ChatGPTは一式をZipファイルにまとめて読み込ませました。
Geminiの方は、ファイル数の制限のため、ソースコード、ヘッダファイルそれぞれを１つのファイルにして読み込ませました。
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時代の真の生産性だと思います。