我がマシン達のWindows 11 25H2のインストール状況(2025/10/23）
Windows 11 の25H2がリリースとなり、我がマシンたちにインストールし始めました。その状況
2025/10/23 現在（アップデート完了）
Ryzen 9 5950X：25H2を新規（22H2→23H2→24H2→25H2（破損）、25H2（新規））
Ryzen 9 3950X : 24H2 → 25H2
Core i9-10980XE : 24H2 → 25H2
Core i7-7820X : 24H2 → 25H2
Core i7-6950X : 23H2 → 25H2
Core i7-6850K：23H2 → 25H2
Core i7-5960X：23H2 → 25H2
Core i7-4960X : 24H2 → 25H2
Core i7-990X : 24H2 → 25H2
Win11 25H2を新規インストール予定
Core i7-3970X
正解主義の文化とプログラミング教育の危うさ
―「考える力」と「信じる安心感」のあいだで―
前回は「staticおじさん」現象を手がかりに、
ネット社会における“同調の構造”と“技術信仰”について考えました。
今回はそこから一歩進めて、
「なぜ私たちは“正解”を求めすぎるのか？」というテーマを扱ってみたいと思います。
「正しい答え」を求めすぎる社会
技術の世界、とくに日本のエンジニア文化では、
「正しい答えを知ること」自体が目的化してしまう傾向があります。
これは学校教育の影響が大きいでしょう。
正解が一つに定まるテスト文化の中で、
「悩むこと」や「保留すること」が評価されにくかった。
プログラミング教育にもその名残があります。
クリーンアーキテクチャ、デザインパターン、SOLID原則……
“正しい書き方”は数多く提示されますが、
それらがどんな文脈で、どんな痛みから生まれたのかを学ぶ機会はほとんどありません。
結果として、手法は暗記され、思想は抜け落ちる。
そして、「何が正しいか」だけが一人歩きするのです。
「正しさ」の呪い
こうした文化の中で、「正しさ」は一種の呪いになります。
何か新しい設計を提案すれば、すぐに「それは間違いだ」と反応が返ってくる。
それが本当に間違いなのかどうかではなく、
“教科書(コードコンプリート)に書かれていない”というだけで排除されるのです。
この現象の根底には、「考えることの恐怖」があります。
自ら考えるという行為は、
自分の中に“わからない”を抱えることでもある。
しかし、わからないままでいることに耐えられない人々は、
「答えを持つ人」に安心を求めてしまいます。
それが宗教のように“信じる技術文化”を生むのです。
プログラミング教育の逆説
教育現場では、「考える力を育てる」と言われます。
しかし、現実には「模範解答を暗記する力」が評価されがちです。
プログラミング教育においても、
“どの言語を使うか”“どの設計が正しいか”といった形式面に議論が集中し、
「なぜそうするのか」「どんな痛みを避けたいのか」といった
本質的な問いが置き去りにされています。
たとえば、「グローバル変数は悪」という常識があります。
しかし、それがどのような歴史的背景で「悪」とされたのかを知る学生はほとんどいません。
そこに文脈がないまま、「禁止事項」としてだけ教えられる。
それでは“思考するエンジニア”は育ちません。
「正解」よりも「判断」
これからのプログラミング教育、あるいは技術文化全体に必要なのは、
「正解を教える」ことではなく「判断を育てる」ことだと思います。
正解は、過去のある時点で有効だった一つの答えにすぎません。
しかし判断とは、目の前の状況・制約・目的に照らして、
「今回はこうする」と決めることです。
そしてその判断の積み重ねが、経験であり、設計力になります。
つまり、“正しさ”は借りられるが、“判断”は自分でしか育てられない。
その違いを理解しないまま、
「正解主義」に取り憑かれた技術文化はいつまでも他人の理想を追い続けるだけです。
「考え続ける」という勇気
結局のところ、プログラミングとは「考え続ける行為」です。
最適解など存在せず、昨日の正解が今日には不適切になっていることも珍しくありません。
それでも、他人の正解にすがらず、
自分の頭で考え続ける――その不安を抱えながらも歩み続けること。
それこそが、技術者（エンジニア）としての誇りであり、自由の証なのではないでしょうか。
この文章は、ChatGPTとの共同作業により作られています。
「staticおじさん」現象とは何だったのか
―「クソコード」批判に姿を変えたネット社会の同調圧力―
前回、「クソコード」という言葉がバズワード化していることについて触れました。
今回は、少し歴史をさかのぼって「staticおじさん」現象を振り返りながら、
“コードの正しさ”がどのようにして社会的な信仰に変わっていったのかを考えてみたいと思います。
「staticおじさん」というレッテル
「staticおじさん」という言葉を聞いたことがある方も多いでしょう。
２０１０年代初頭、オブジェクト指向が声高に唱えられていた時代、
C言語的な書き方――たとえばstatic関数やグローバル変数――を使い続けるベテランエンジニアを
揶揄するために生まれたネットスラングです。
当時、オブジェクト指向は“正しい設計思想”として教育現場でも現場でも広まり、
メソッド呼び出しこそが美徳であり、static（関数）を使うことは“時代遅れ”だとされていました。
しかし今振り返ると、彼ら（staticおじさん）が使っていた手法の多くは、
単なる無知ではなく、実務的な妥協や効率化の知恵だったように思えます。
プロジェクトの制約、納期、パフォーマンス、チーム構成――
そうした現実の制約を理解したうえで“あえて”選ばれた手段であったことも少なくありません。
「信仰」としてのオブジェクト指向
オブジェクト指向の時代には、「staticを使うのは悪」という単純な善悪構造が形成されました。
その背景には、エンジニア教育や資格試験、ネット上の設計論争などを通じて
「OOPこそが唯一の正解」とされる雰囲気があったのです。
この構図は宗教的です。
人々は“正しい設計”を信じることで安心し、
他者の異なるやり方を排除することで、自分の信仰を強化していきました。
それは技術的な議論というよりも、
「自分が正しい側にいる」という心理的な安定を得るための行為でもあったのかもしれません。
繰り返される「同調の構造」
staticおじさんを笑っていた人々が、
いま“クソコード狩り”をしているとしたら、
それは同じ構造の繰り返しです。
かつて“staticおじさん”を嘲笑していた人々の中には、
いま現場を離れてしまった人も少なくありません。
壮大なオブジェクト指向の実験の果てに、
多くのプロジェクトが炎上し、多くの人が疲弊しました。
その中で「失敗の原因は古いやり方にある」として、
staticを使う人々が“悪役”として語られたのです。
時が流れ、オブジェクト指向の幻想が薄れた今、
新たな“敵”として登場したのが「クソコード」でした。
コードの品質を語ること自体は重要ですが、
他者のコードを嘲笑し、排除しようとするその姿勢は、
十年前の“staticおじさん狩り”とまったく同じ構造をしています。
人を揶揄する文化は定期的に生まれ、やがて消えていきます。
そのたびに誰かが傷つき、誰も幸福にはならない。
そこに残るのは、「正しさ」を求めすぎた社会の冷たさだけです。
「正解主義」とどう向き合うか
この現象の根には、「正解を求める文化」があります。
多くのエンジニアは、「何が正しいのか」を明確にしたいと願います。
しかし、プログラミングという行為の本質は、
常に“仮の正解”を探りながら進む試行錯誤の連続にあります。
「わからないままにしておく」ことを許せない風潮は、
議論を貧しくし、思考を停止させます。
結果として、「○○はクソ」「△△は正義」という単純化が進み、
技術が信仰へと変わっていくのです。
次回予告
次回は、こうした「正解主義」の文化がどのようにしてプログラミング教育や職場文化に根を下ろしていったのかを掘り下げ、
「正しさ」と「自由な思考」のバランスを考えてみたいと思います。
この文章は、ChatGPTとの共同作業により作られています。
クソコードとコードコンプリート症候群
―「正しさ」を振りかざすエンジニアたちへ―
「クソコード」という言葉が、いつのまにかネットに氾濫しはじめた。
これは、冗長で、意図が読めず、保守性に欠けるコードを指して揶揄するものです。
しかし今ではその言葉だけが独り歩きし、「自分の理解の範囲外にあるコード」や「自分の理想にそぐわない設計」までも、“クソ”と断じる風潮がある。
この背景には、「コードコンプリート症候群」とでも呼ぶべき現象がある。
コードコンプリート症候群とは何か
「良いコード」を追い求める活動は昔からある。
古くは構造化プログラミングが提唱され、今ではそれが当たり前になった。
しかしそれだけでは解決できない問題が現れ、次々と新しい手法やデザインパターンが現れそして新しい問題が発生する。複雑さへの挑戦は終わりのない戦いである。
様々な手法が出てきてそれら自体の存在が複雑化した。そしてそれらの手法を体系化した書籍が登場してきた。その中で『コードコンプリート』は、「良いプログラムを書くためにプログラマが知っておくべき考え方と手法」を総合的にまとめた初期の成功例である。
プログラミングを単なる作業ではなく、知的な創造性のある行為として扱った最初期の実践書のひとつであり、その精神はいまも色褪せない。
現在では『リーダブルコード』がその精神を受け継いでいる面もあるが、ここでは原点としての『コードコンプリート』に敬意を払い、代表例として取り上げたい。
問題は、その内容に感銘を受けたエンジニアが、その理念を「唯一の正解」と信じてしまうときに始まる。
彼らはコードレビューでこう言う。
「この変数名は短すぎる」「コメントが少ない」「このクラスは単一責任原則に反している」「これはスパゲッティコードだ」――。
そして最後に決まって、「コードコンプリートにも書いてありますよ」と付け加える。
まるで聖典の一節のように。
だが現場は常に、時間とコストとレガシーの中で動いている。
理想を追うことと、現実を生きることは別問題だ。
理想の“押し付け”が生む現場の停滞
優れた原則や設計思想は、状況に応じて取捨選択されるべきものだ。
だが「教義化された正しさ」は、しばしば現場を麻痺させる。
新しいアイデアが「原則違反だ」として却下され、古くても信頼できるコードが「レガシー」と称され書換えを強制される。進行中のプロジェクトが“改善活動”という名の足踏みを始める。
そして気づけば、誰もコードを書かなくなり、議論だけが増えていく。
「クソコード」というレッテルは、往々にして相手の努力や文脈を切り捨てる言葉でもある。
そこには、相手への敬意よりも、「自分は理解している側だ」という安心感がある。
それが一番、危険だ。
クソコードを超える視点
本当に優れたエンジニアは、「なぜこう書かれたのか」を考える。
時間的制約、チームのスキル、利用可能なライブラリ、歴史的経緯――すべてを踏まえて設計を評価する。
そこには「正しいコード」ではなく、「今ここで生き残るコード」という現実的な視点がある。
『コードコンプリート』の精神とは、本来この“文脈理解”そのものだったはずだ。
それを「規範の棒」として他人を叩くのではなく、「共通の言語」としてチームをつなぐために使う――。
その姿勢を忘れたとき、私たちは“コードコンプリート症候群”に陥る。
結びに
良書は人を育てるが、同時に、信者も生む。
それを避ける唯一の方法は、「本の中にある正しさ」よりも、「現場で生きる知恵」を信じることだ。
“クソコード”と笑うより先に、「なぜそうなったか」を問おう。
そこからこそ、真のプログラミング文化が始まる。
この文章はChatGPTが原稿を書き、人間が修正を加え、再度ChatGPTが校正・編集したものです。
炎上プロジェクトとクソコード
――「クソコードを書け」と私が思うようになったもう一つの理由――
「クソコードを書け」という主張はいささか偏っていますが、思えば私は他人のコードを「くそ」と思ったこともなければ、「直せ」と思ったこともほとんどありません。
では、なぜそう思うようになったのか。
キャリアのごく初期――35年程前になります――には、「コードの美学」というものが確かにありました。しかしそれは1、2年で消えました。
さらに数年後、決定的な出来事が起き、その美学は吹っ飛びました。
30年近く前、1996年前後のこと。私が担当していたプロジェクトが炎上しました。
どのくらい炎上したかというと、残業が170時間、それが3か月ほど続いたのです。
残業代で数十万円入ったものの、翌年の社会保障費が爆上がりし、給与の支給額が「14万円」とかになった。
総務に「なんでやねん！」と詰め寄ったら、「あなた去年170時間残業したから…」と言われたのを今でも覚えています。
ちなみに、そのときの数十万円がどこに消えたのかは、いまだに謎です。
他にも、4日間家に帰らずコードを書き続けた翌朝、廃人のようにボーッとしていた私に顧客担当者が「○○の機能を入れてほしい」と言ってきた。
相手の言うことが理解できず、とりあえず「無理です」と返して、担当者がすんなり帰っていったこともあります。
int型で定義した変数を、なぜかshort型でexternして、朝の4時にバグを仕込んだり、
風邪で寝ていたら上司に呼び出され、現場で顧客から「ボーっとするな！」と説教を受けたり。
炎上プロジェクトの「あるある」は、わりと経験しました。
その後、私は数年間体調を崩しました。
体調を直すのに苦労しましたが、それ以上に、「何が悪かったのか？」をずっと考え続けました。
そこで学んだことは、
- 顧客からの無理な要求は受け入れないこと（プロジェクトマネジメントの重要性）
- 一日の労働時間には限界があること（体調管理の重要性）
- 信頼できるメンバーを見極めること
- テストコードの必要性
- そして何よりプログラミングテクニックだけでは炎上プロジェクトは救えない
ということです。
もちろん、開発プロジェクトに必要なプログラミング技術は存在します。
しかし、一度炎上した現場では、もっと広い範囲で問題を見抜く力が必要になります。
たとえば、最近のマイナ保険証の問題。あれは「プログラミングが悪かった」という話ではありません。
私たちが学ぶべきことは、コードの書き方だけではなく、プロジェクト全体を見渡す力です。
ただし、だからといってプログラミングの勉強をやめてよいという話でもありません。
幸い、その反省が生かされたのか、私が担当して炎上したプロジェクトは一度きりでした。
その後は、いくつかの炎上現場に「助っ人」として呼ばれる側になり、記憶にある限り3回ほど大炎上の火消しに入りました。
では、火消し屋にとって最も重要なプログラミングスキルとは何でしょうか？
あまり知られていないかもしれませんが、コードを読む力（リーディング能力）です。
コードリーディング能力を高めるには、まず自分がCPUになったつもりでコードを読むこと。
つまり、「このコードはどのように実行されるのか？」という観点で、主観や美学を捨てて追うのです。
次に問うべきは、「このコードの動作は正しいか？」ということ。
ここで確認するのは仕様との整合性であって、コードが綺麗かどうかではありません。
論理的な間違いを追い、問題箇所を見極めることが目的です。
バグを探しているときにコードを見て「クソコードだ！」と思った瞬間、冷静な論理的判断はほとんど不可能になります。
私の経験では、感情的な印象を保ちながら正確に問題箇所を指摘できる人はほぼいません。
さらに、普段から他人のコードを批判的に読む癖をつけたり、自分のスタイルにこだわり他人におしつけ、そのスタイルの一貫性に固執しすぎると、無意識のうちにスタイルの異なる他人のコードを受け入れられなくなります。
つまり、コードの「あるべき姿」を追い求めすぎたがために、多様な書き方を認められなくなってしまうのです。
確かに、コードの出来が悪くてバグが潜むこともあります。
しかし、それを炎上中に嘆いたところで、現場は何も救われません。
コードの美しさよりも、まず動作の理解。
「クソコード」と切り捨てる前に、CPUのように冷静に読み、仕様との整合性を確認すること。
それこそが、火消し屋としての第一歩であり、炎上を防ぐための最良の訓練でもあるのです。
この文章は、原稿を元にChatGPTが校正・編集しています