はてなブックマーク

はじめに 本稿はなぜクソコードが趣味のプログラミングではあまり発生せず、仕事のプログラミングで集中的に発生するのかを説明するためのレポートです。 ここで言うクソコードとは単に見た目が汚いコードではなく、保守不能であり全体構造が理解できず、修正が指数関数的に困難になる成果物を指します。 本稿では精神論やモラル批判を避け、能力分布と制度設計、評価構造という観点から事実を積み上げます。 特定個人の資質を責めることが目的ではなく、再現性のある生成条件を明らかにすることが目的です。 趣味のプログラミングがクソコードにならない理由 趣味のプログラミングには最初から強力なフィルタが存在します。 それは自発性、理解欲求、自己完結責任です。 分からないことを分からないまま続ける動機が存在しないため、理解できない地点で自然に撤退します。 結果として趣味コードは奇妙でも一貫性があり、破綻する前に止まるという特徴

はじめに 「ウォーターフォールでソフトウェアを作れる」という言説は、現場感覚を持つ人間ほど違和感を覚えるにもかかわらず、一定数の人に強固に信じられ続けています。これは単なる開発手法の好みの問題ではなく、人間のウォーターフォール神話とソフトウェア開発を巡る成功体験、そしてそれを支える認知構造が絡み合った現象です。 ソフトウェア開発の歴史を振り返れば、ウォーターフォールが教科書的に語られ、正統な方法論として扱われてきた時代が確かに存在します。しかし、その「正しさ」は結果から逆算された物語であり、検証可能な事実とは必ずしも一致しません。 本レポートでは、ウォーターフォールが実際に機能していたのかという事実認定を起点に、なぜそれでもなお「作れる」という嘘が信じられ続けるのかを、心理、組織、歴史、そして認知の観点から整理します。 感情論や宗派論争を避け、できるだけ冷静に、しかし現場の肌感を失わずに論

はじめに 本稿は、近年流行語のように語られるバイブコーディングという概念について、それが現在主流のLLMではなぜ成立し得ないのかを技術的かつ論理的に整理することを目的とします。単なる感情論やではなく、要件定義、責任構造、解釈主体という観点から冷静に分解します。 結論ありきで否定するのではなく、なぜそうならざるを得ないのかを構造として示します。世間一般に共有可能な形で、現場エンジニアの判断材料となることを意図しています。 本稿は人間同士では成立してきた開発手法が、なぜLLM相手では破綻するのかという一点に集中します。 バイブコーディングの成立条件 バイブコーディングとは、厳密な仕様や手続きを逐一記述せず、背景となる思想や目的、いわば「ノリ」や「空気感」を共有することで実装が自然に収束するという開発スタイルを指します。ここで重要なのは、これは暗黙知、責任共有、失敗コストの理解という前提条件の上

はじめに IT業界においてWeb系とSIerを比較する議論は長年繰り返されてきましたが、その多くは技術的優劣という形で語られています。 しかしこの議論をよく観察すると、技術そのものではなく認知の歪みが話題の中心に据えられていることが分かります。 とりわけITのにわか層においては、Web系は技術的に優位でSIerは劣位であるという単純化された幻想が強固に信じられています。 本稿では、この幻想がどのような構造によって生まれ、なぜ再生産され続けるのかを論理的に整理します。 議論の対象は技術文化ではなく、人事文化とマネジメント構造、そしてそれを誤認する人間側の認知メカニズムです。 技術は個人にしか宿らないという前提の欠落 技術は組織や業界に自動的に蓄積されるものではなく、あくまで個人の思考と試行錯誤の結果として身につくものです。 この当たり前の前提が抜け落ちた瞬間、「場所に行けば技術が身につく」と

はじめに 本稿では、変数と定数を二項対立としてではなく、変更頻度や時間軸に沿ったグラデーショナルな存在として捉える視点が、なぜ多くのプログラマーに共有されていないのかを論じます。結論を先取りすれば、これは個々人の能力不足や理解力の問題ではなく、教育構造、評価制度、実務経験の質、そしてソフトウェア開発という営みそのものが持つ時間的特性に深く根ざした問題です。プログラミング教育や新人研修では、即効性と説明容易性が優先される一方で、時間を跨いで効いてくる設計感覚は切り落とされがちです。その結果として、多くのプログラマーは長年コードを書いていても、変数と定数を固定か可変かという二値でしか捉えられない状態に留まります。本稿ではその背景を段階的に整理し、なぜこの気付きが遅れて訪れるのかを、構造的な観点から説明します。 二値思考として教えられるプログラミングの出発点 初学者向けのプログラミング教育では、

はじめに ソフトウェア産業は、見かけ上ハードウェア産業と似た構造を持つように見えます。どちらも工学的な手法を用い、製品を量産し、利用者に提供するという点では共通しています。しかし本質的にはまったく異なる原理で動いており、ハードウェアの世界で成功してきた「マスプロダクションの原理」は、ソフトウェア業界ではほとんど機能しません。なぜなら、ソフトウェアは「作る」ことが生産ではなく、「複製」そのものが供給行為になるからです。つまり、ソフトウェアには「製造」という工程が存在せず、工業社会が築いてきた品質向上のメカニズムが入り込む余地がありません。本稿では、量産という原理が持つ意味を整理し、ソフトウェアにおいてそれがなぜ働かないのかを論理的に明らかにします。 ハードウェア産業におけるマスプロダクションの構造 ハードウェアの品質は、統計的工程管理によって支えられています。つまり、同じ製品を大量に作ること

はじめに デジタル化が進む社会において、私たちは頻繁に「従来よりセキュリティが強化されます」という言葉を耳にします。特に行政や金融サービスのデジタル移行に関しては、暗号技術を活用したデジタル鍵によって、物理鍵に比べて圧倒的な安全性が確保できています。それにもかかわらず、多くの人々は「デジタル＝危険」「紙や物理の方が安全」という印象を持ち続けています。この違和感は、単なる知識不足ではなく、人間の心理構造と情報の伝わり方に起因しています。本稿では、なぜ人は「現実と逆の感覚」を抱くのか、その根本理由を掘り下げて考察します。 見える危険は安心し、見えない危険は恐怖になる 人間は、理解できる危険には冷静でいられますが、理解できない危険に対しては強い不安を覚えます。物理鍵には壊すための「手順」が存在し、それを想像することが簡単です。泥棒が工具を持ってきて壊す姿は、映画やドラマでよく描写されるため、イメ

はじめに アジャイルという言葉は広く普及していますが、その本質を正確に理解している人は多くありません。表面的には「変化に強い開発手法」「小さく作って早く回す」という説明が一般的ですが、実際のアジャイルははるかに本質的で、人間の認知能力と組織構造に強く依存した哲学的な方式です。本レポートでは、アジャイルの本質を掘り下げ、なぜ特定の条件を満たすチームでのみ成立するのかを論理的に整理します。そのうえで、アジャイルが成功するために必要な“人の条件”と組織の前提について考察します。 アジャイルとは「真実 × 目的 × 推論」が揃う方式である アジャイルが他の開発方式と決定的に異なるのは、根幹に「真実を操作しない」という前提が置かれている点です。嘘や政治的配慮を最小化し、現実をありのまま扱います。これにより、チーム内の各メンバーが事実を基点として矛盾なく行動できます。しかし、事実の共有だけでは組織は前

はじめに 世の中ではしばしば、情報を「氷山」に例える比喩が使われます。水面上に見えているのはほんの一部であり、大部分は水面下に隠れているという構図です。この考え方は、機密情報を氷山の下に、公開情報を上に置き、見えない部分こそが価値の本質だとみなす発想に結びつきます。 しかし実際の社会では、価値を生むのは「隠された情報」そのものではなく、「見えている情報をどう扱うか」です。つまり、公開情報の読み解きと運用こそが実務で決定的に効きます。 本稿では、なぜ公開情報が機密情報以上に重要なのかを、情報構造・知識形成・理解力という観点から論じ、氷山の上に見えている部分こそが社会における知的競争力の源泉であることを明らかにします。 公開情報の価値は「誰でも理解できる」ものではない 多くの人は「公開されている情報＝誰でも理解できる」と誤解しています。しかし実際には、公開情報を活用できる人は限られています。た

はじめに Unityは2005年以降、PC、モバイル、コンソール、VR/ARといった幅広いプラットフォームに展開できる強みを持ち、世界で最も普及しているゲームエンジンのひとつとなりました。その開発言語としてC#が用いられていますが、この理由に迫ります。さらにUnityは、ビルド時にC#を直接ネイティブ化するのではなく、C# ⇒ MSIL ⇒ C++ ⇒ マシン語という一見遠回りに見えるプロセスを採用しました。これはIL2CPPと呼ばれる仕組みであり、iOSのJIT禁止ポリシーやクロスプラットフォーム展開と深く関わっています。本稿では、UnityがJavaからC#に至った経緯、C#が「スクリプト」と呼ばれる理由、iOSでのJIT禁止の背景、そしてIL2CPPの合理性を考察します。 なぜ、UnityはJavaを採用しなかったのか？ Unityの開発初期、候補に挙がっていた言語にはJavaも含ま

はじめに 近年、Rustという新しいプログラミング言語が注目を集めています。その安全性や抽象化能力の高さから、「システムプログラミング言語としてC言語を置き換えることが可能である」と広く宣伝されています。しかし、組込開発の現場において、RustがCを完全に置き換えることが難しいことは周知の事実であるにもかかわらず、非組込開発者は安易にその置換が可能だと誤解しがちです。本稿では、なぜこうした誤解が生じるのか、その理由を明らかにします。 1. Rustが「システムプログラミング言語」という宣伝を真に受け過ぎている Rustは「安全でモダンなCの代替言語」としてのマーケティングが非常に成功しており、しばしば「OSまで書ける」「no_stdでベアメタルもOK」と強調されます。これを聞いた非組込開発者は、あたかもCの使用領域すべてをRustだけでカバーできると思い込んでしまいがちです。しかし実際のと

はじめに 組み込みソフトウェア開発の世界では、プログラミング言語の選択が製品の品質、開発効率、そして長期保守性に大きな影響を与えます。近年、メモリ安全性や並行処理の安全性を強みとするRust言語が様々な分野で注目を集め、採用が進んでいます。Webバックエンド、システムプログラミング、そしてLinuxカーネルのような重要なプロジェクトでもRustの導入が進んでいるにもかかわらず、組み込み開発の現場では依然としてC言語が主流であり続けています。本稿では、最新の安全な言語であるRustが、なぜ組み込み開発において広く採用されず、数十年の歴史を持つC言語が今なお主要な選択肢であり続けているのか、その技術的・実務的な要因を詳しく検討します。 1.ヒープを使わない開発が多いのでRustの本領が発揮されない 組み込み開発では、動的メモリ管理を避ける（ヒープを使わない）設計が一般的です。 Rustの特徴で