クソコードを書け

　ちょっと気づくのが遅い面がありますが、ネット界隈ではクソコードというワードが広がっているようです。要は品質の悪いコードを指して”くそコード”と称しているというこです。
ひと昔前に流行った「オブジェクト指向」と同様に今度は「クソコード」がある種のバズワードになっている感があります。
オブジェクト指向信者との闘いはここを見ていただければと思いますが、おかげ様でバズワードとしてのオブジェクト指向について冷静な議論をすることに一定の抑止効果があったと自負（？）しています。
一方で、今度はクソコードというバズワードが流行っていると認識しています。

実は、私自身ですが、他人のコードを見て「くそ」と思ったことはほとんどありません。「あーそう書くのか」と思うことがあります。そこに自分の常識にとらわれない新しい発見があるからです。

ちょっと古い２５年前の例になるのですが、新人が書いたVBScriptの

name = "与太"
output = "ようこそnameさん"

というコードで、新人からの質問が「なぜoutputが "ようこそ与太さん" ではなく "ようこそnameさん"と表示されるのですか？」と質問を受けて逆に感銘を受けました。
ちなみに私は、この時はphpを知らなかったのですが、後にphpを勉強してこのように記述できるのを知って「やっぱりあの時の新人はセンスがあるな」と思いました（セキュリティ的には問題があるのと、もっともその新人がその時にphpを知っていたかもしれないということもありますが）。
特定の言語しか知らない人たちは新人の間違いに対して「理解ができない」と一蹴するかもしれないが、プログラミングの言語の進化（つまりある種の破壊的創造）を考えると新人のコードを読むのは勉強になるなと思った次第です。

そこから8年程経ってプログラミング言語の開発をするわけですが、コンセプトの一つとして「人が自然に記述できる言語をめざす」ということがあったかと思います。
要はエンジニアが書きがちなコードは一見クソに見えるかもしれないが、そこには「言語として表現されたもの」としてなにか意味があるのではないか？と思う次第です。

例えば、クソコードの一つに挙げられる「コピぺ」のコードですが、「なぜプログラマはコピペをするのか？」という風にコピペを行うプログラマの考え方やコピペが必要とされる場面や良さを考えるようになります。
オープンソースとかであるフォークもある種のコピペだと思います。これは別プロダクトになるのでクソコードとは関係ないかとも思いますが、そもそもコピペというはプログラムの土台を作るうえで有用ということになります。
誤解のないように言いますと、ある種の品質が問われる場面ではコピペは避けています。例を挙げると、私の場合、料金計算を行うコードは「一か所」と決めています。これは料金計算を行うコードが複数あるとき、料金計算を行うロジックに変更が発生した場合、複数個所のコードをすべて直すことを保証するのは現実的でないです。むしろ関数なりクラスなりにして料金計算は１か所で行う方が最終的に品質を確保できます。
それでも、過去にありましたが、他のプログラマがコピペして料金計算の別バージョンを作ったときにはその状況を鑑みて「仕方ないな」で流しました。

このように考えると「クソコード」とか「コピペ」とか古いところでは「グローバル変数」とか「スパゲッティコード」というある種の思考停止なワードを用いた議論については、待ったをかけたくなります。

別の観点でいいますと、プロジェクトの開発・保守の現場では、個々のコードについてはそこまで保守性が重要ではない場面があります。
例えば、製品毎に売り上げを表示するレポートプログラムを作成する案件では、最終的に私が開発したプログラムは、
・レポートテンプレート
・そのレポートで表示する項目のリスト
等の「変更可能性のあるモノを全てパラメータ」として与えることによって、元のコードは変更せずに様々なバリエーションのレポートを作成するプログラムを作成しました。
保守業務において、もはや元のコードは「そのままでよい」というこになり実際にコードを変更することはあまりありませんでした。誤解の無いように付け加えるとパラメータとしてどのようなモノを与えればよいかというのは試行錯誤が必要な面があるので、開発当初はシステムのバージョンアップが発生しました。

これはある種のプログラミング言語を開発し、その言語の上で開発を行っているという状況になります。この場合、私たちの目は元のシステムのコードに行くべきなのか新たに作った言語に行くべきなのか？ということが言えます。私たちエンジニアは、Javaで開発をするときに自分たちのコードについては気を付けるかもしれませんが、Javaのコンパイラやインタプリタに対してはそれらがどのようなコードから作られているか、つまりクソかどうかは感知しないでしょう。

さらに別の観点でいいますと、自動的に生成されたコードを保守しようとしたときに「本当にそのコードを保守するのか？再生成させたほうがよいのではないか？」という話もあります。
比喩的にいうと、Javaでコンパイルしたマシンコードの可読性をいちいち気にしないということと同じです。
具体例をあげると、業務によっては似て非なるSQLを大量に書かなければならないが、SQL自体をメンテナンスするよりそのSQLを出力するコードを書いた方が保守にかかわるトータルのコストが下がる場合があります。この場合、当然ですが、出力後のSQLを確認する意味では読みますがその可読性は問題視しません。
ちなみに私はコンパイルしたC++のアセンブラコードを読むこともあります。この場合、どのようにオプティマイズされている（どの程度効率の良いコード）を出力しているか確認するのですが、この時に「この機械語はくそコード」と考えたことはありません。もっとも、すでに２０年以上前からコンパイラは腹が立つぐらいに（私的には）美しいコードを吐いてきます。

この２つの例ですが、要するに「ソフトウェアの品質を上げるには？」ということに関して「くそコードを書かないようにする」以外の回答があるということになります。

さて、AI時代になると、もはや人間がコードを書くことは減るかと思いますが、それでも人間がコードを読む時間は増えるでしょう。
この時に、AIに向かって「くそコードを書くな！」とかおっしゃるのでしょうか？

最後にChatGPTで遊んでみました。

P.S.
「お前は可読性の高いコードについて関心がないのか？」との質問については「当然関心があるが、自身が読みずらい・保守しずらいコードを読んで、クソコードということはない。もちろん個別の問題点については指摘する」ということが言いたいことです。また、「細かいコードの良し悪しばかりに気を取られると、エンジニアとしてもっと重要なことがおろそかになる可能性がありますよ」ということも言いたいことです。

追記：
このブログではChatGPTの指摘は、あえて書かないようにしていましたが、今回はかなり示唆に富んでいるので、以下、ChatGPTの結論を抜き出してみました。正直、そこまでは明確に意識していませんでしたが言われたらそうだと気付きました。

さらにChatGPTで遊んでみました。

ChatGPT１の 結語：「クソコードを書け」

クソコードを恐れるな。
クソコードを書け。

そこにはあなたの思考、試行錯誤、そして創造の痕跡が残る。
真にクソなのは、挑戦をやめて他人の美学に従うことだ。

さらにさらにChatGPTで遊んでみました。

ChatGPT２の結論

この文章は「クソコード＝悪」という単純な構図を脱し、
「コードという文化現象」や「言語進化」「AI時代の人間の役割」まで踏み込む、
非常に知的で示唆に富む論考です。

ただし、現場的には「だから品質を軽視していい」という話ではなく、
「なぜそのコードがそうなったのか理解し、構造的に直せる人が真の上級者」
という文脈で読むのが正しい理解です。

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

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

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

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

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

SESのメリット

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

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

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

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

SESのデメリット

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

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

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

マルチスレッド＆アセンブラプログラミングをしてみる（コラッツ予想のプログラム）

　多コアCPUのコアを使い切るにはどうするか？とここ数年考えていたのですが、そういえばコラッツ予想（3n+1問題）を確認するプログラムはちょうどよい例だと思いプログラムを作成してみました。

CollatzAsmについて

　せっかくなので64ビットアセンブラで作成し、128ビット（2の128乗）までの数を扱えるようにしました。ちなみに64ビットだと入力が数百億程度（35ビット程度）で内部の計算が桁あふれを起こします。
Visual Studio 2022(C++/Asm)で作成しています。ここからプロジェクトファイル一式をダウンロードできます。

　Visual C++ですが32ビットバージョンはインラインアセンブラが使えるので、お手軽にアセンブラを使えたのですが、64ビットになりなぜかインラインアセンブラをサポートしなくなりました。ということで約30年ぶりにアセンブラのソースコードを書きました。
ちなみに、16ビット時代はアセンブラプログラミングの参考書が豊富にあったのですが、64ビットになりあまり見当たらなくなりました。昔はミックスドランゲージといって、Cからアセンブラを呼び出す方法もよく解説をされていたのですが、今では、ここに資料があるくらいで、基本的なことが分かっている人じゃないと意味不明かと思われます。
詳しい解説はご希望があればやりますが、このプロジェクトをサンプルとしてもらえればと思います。

　また、このサンプルはC++14のマルチスレッドのサンプルにもなっています。長い間マルチスレッドプログラムと言えばOSのAPIかランタイム関数を使って作っていたのですが、C++14からプログラミング言語にサポートされたということで作成してみました。

実行例は以下のとおりとなります。

最初の引数で何処までの数を確認するかを入れ、2つ目の数は並列度（スレッド数）になります。
サンプルでは10になっていますが、当然コア数以上の値をいれます。32論理コアに対して100とかにしてもパフォーマンスが上がります(後述）。

CollatzAsmBenchについて

　アセンブラでのプログラミングに限った話ではないのですが、プログラムの最適化の過程で試行錯誤を行うことがあります。特にアセンブラでプログラムすると様々な命令を使うことができるのでそのバリエーションが増えるかと思います。
ということで試行錯誤の記録として10個程アセンブラのコードのパフォーマンスを比較するプログラムを書いてみました。
以下、実行結果になります。

ChatGPTの出力コードとの比較

　いわゆるバイブコーディングということで専用のツールも出てきていますが、コラッツ問題を扱うプログラムに関していうと、どこにでもあるのでChatGPTでも簡単なプロンプトでかなりいい感じのコードを出力しています。ということでChatGPTでプログラムを出力させてみました。、実際に試してみたところ可能でしたがあまり速度が変わらなかったので、今回はアセンブラでの出力はしていません。ChatGPTが作成したマルチスレッドのものを掲載します。

　私が作ったコードと比較するとマルチスレッドの初期化の取り扱いがうまいです（emplace_backを使っている）。一方で、データ長は64ビット止まりで、並列性も論理コア数に従ってスレッドを作成していますが（hardware_concurrencyメソッドを呼んでコア数を取得している）、このプログラムの場合、各スレッドの実行時間が必ずしも同じではないので、スレッド数をより多くして各スレッドのタスクを細かくした方が、実行時間のばらつきの減少が期待できます。一方で、一般論になるのですが、論理コア数以上のスレッドを実行させると各スレッドがCPUのリソースを食い合いすることになるので、実行スレッド数を論理コア数に合わせるのも一つの手になります。

　今回はアセンブラでは比較をしませんでしたが、CやC++のコードを単純にアセンブラにしてもあまり早くならないということもあります。一方で128ビットのような桁数の多い計算をさせる場合、アセンブラには桁あふれを処理する命令があり、CやC++で組むよりはるかに効率的なプログラムが記述できます。機会があればChatGPTでアセンブラプログラムの最適化を行いたいですが、↑の例にあるようにAIに任せるより、自分で工夫をした方が手っ取り早い面があります。もちろんですがアイデア出しをAIに頼ることもできますので、こういうことではあまりAIと人間の比較は意味がない（人間からしたらAIも利用する）ということになりますが、2025年9月現在、このあたりのチューニングはまだ人間の方に一日の長があるかと思います。（追記）この記事の公開後、１週間でClaudebotと名乗るロボットからZipファイルがダウンロードされたのでひょっとしたらClaudeにコードがパクられるかもしれません。

　最後に実行結果を

ということで、倍以上のパフォーマンスを示しています。逆にいうと倍程度にしかならないのですが、ある処理時間が半分になるということは2020年代のCPUの進化でいうとほぼ10年に相当します（この場合シングルスレッド性能の比較になる）。つまり上手くアセンブラでプログラムを書き直すことができればCPUの進化を１０年先取りできるとも言えます。CPUのシングルスレッド性能の向上が顕著だった90年代ですと概ね1，2年でパフォーマンスが倍になっていました。
余談ですが、アセンブラでのプログラミングは8ビットや16ビットの時代は割と一般的でした。90年代以降ではCPU自体の進化が早かった為、アセンブラでのプログラミングがエンコードなど、いわゆるSIMD命令を使うためとか、ニッチになった感がありました。CPUのシングルスレッド性の向上が見込めなくなった昨今、アセンブラでのプログラミングが見直されるかもしれません。
話を戻すと、コラッツ予想の確認プログラムの場合、スレッド数を100にしても性能が伸びていることを確認できます。これは、前述のとおり値により処理ステップにばらつきがあるためで、区間を細かくした方が（スレッド数を多くし多方が）、CPUから見た場合のトータル処理時間が平均化される為です。

マイナ保険証（2025年7月）資格確認証を入手しました

　Youtubeの方ではマイナンバー問題ということでちょいちょい動画をアップいましたが（こちらが再生リストになります）、ここ数か月動画の更新をさぼっていましたが、この度資格確認証を入手しましたのでそれについての記事になります。

資格確認証を取得するメリット（ほぼ今までどおり保険診療が受けられる）

　マイナ保険証については過去にトラブルが発生しその検証・対策もまるで素人がやっているようで（詳しくはマイナンバー問題）、今後もきちんと運用がされるかどうか怪しいところがあります。
こういう状況で安心して保険診療を受けられるようにするには『資格確認証を取得する』ことが選択肢になるでしょう。具体的には、マイナ保険証の利用登録解除（および場合により多少の追加手続き）を行うと「資格確認証」が送られてくるようになります。これは従来の保険証とほぼ同じものであり、今後も従来どおりの保険診療が受けられるようになります。政府は「デジタルだ！」といいながら、不完全な（ベータ版としか言いようのない）システムを導入しているが、そんな不完全なシステムが引き起こすトラブルにいちいち付き合う必要はないでしょう。
ちなみに、2025年7月時点での利用登録解除は数万件程度であり、今の段階では比較的スムースに登録解除ができるようです。今年は私のマイナンバーカードの更新年で、新しいカードを取得するのに2か月半かかったが、利用登録解除はそれよりはるかい迅速に手続きができるようです。一度登録解除を行い、二度と登録しないようにすれば、今までどおり安心して保険診療が受けられるようになります。

マイナ保険証でよいのではないか？

　現在、マイナ保険証を利用しており特段問題がない方はそのまま利用するのも手であります。
もっとも、マイナ保険証を利用するには２つ程注意点があります。
1点目は、マイナ保険証での受付が出来ない場合があるということで政府をそれに対する対応策を示しています。要はマイナ保険証だけでなく「資格情報のお知らせ」を持った方がよいということで、マイナ保険証だけでは窓口でトラブルとなる可能性がある。
2点目は、マイナンバーカード（電子証明書）の有効期限を意識しなければならないことで、5年目（5回目の誕生日）で電子証明書の更新があり、10年目（10回目の誕生日）でマイナンバーカードの更新があります。更新を忘れるとマイナ保険証が使えなくなる。『その場合どうなるか？』ということがあるが、最終的には資格確認証が送られてくることになるが、それなら資格確認証でよいということになる。
もちろん、今後システムの完成度が上がり、マイナンバーカードの更新が習慣化すればマイナ保険証で受診するのが当たり前となるかと思われるが、時間はかかるかと思われる。

マイナ保険証の利用登録解除とそのデメリット

　利用登録解除を行うには、保険者（保険証に記載がある）に連絡することになる。保険者の名称からWEBで検索を行ってホームページから『利用登録解除』の方法を調べることになる。国民健康保険・後期高齢者医療保険は市町村に問い合わせることになる。サラリーマン等のいわゆる厚生年金加入者は健康保険組合と呼ばれる団体に問い合わせることになる。
サラリーマンの方が利用登録解除を行い、資格確認証を取得しようとすると、場合によっては資格確認証が会社に送られてくるかもしれない。多くの中小企業が入っている全国健康保険協会（いわゆる協会けんぽ）の東京支部の場合は、会社に送られてきた。また全国健康保険協会は会社に対して従業員に『マイナ保険証を使うように』と通知を行っており会社員の方にとってはプレッシャーとなるかもしれない。その他、確定申告時に医療費控除を受ける際に領収書を集めておかなければならないとか一定の不便さがある（このあたりは従来どおりと言えば従来どおりである）ので今一度、マイナ保険証のメリットを再確認して、メリットが失われた場合に本当に困らないかどうか、念の為、確認する必要があるでしょう。

PHPのバージョンアップの激しさに閉口する

Wordpressのお知らせで、わざわざPHPのサポート終了について知らせてくれるのだが、Rocky Linux9（要はRHEL9）の場合、PHP 8.0系でも2032年までサポートするらしい。というこで気にはなるが今のところは放置でよい。
もっとも、過去にWordpressがPHP5系のサポートを止めて7系に強制アップデートしたときがありその場合（Centos5か7）の時はPHPのバージョンを気にしないとダメだったので面倒だった。
プログラミング言語のサポート期間が4年とか5年というのは、短すぎると思うのだが、如何でしょうか？