はてなブックマーク

はじめに プログラマーの三大美徳は、ラリー・ウォールが Perl の文化とともに提示した有名な言い回しですが、日本ではそれが単なる Perl の格言にとどまらず、広くエンジニア一般の心得として知られるようになりました。現在の Perl 公式文書でも、この三つは「Laziness, Impatience, and Hubris」として明記され、由来はラクダ本の通称で知られる『Programming Perl』にあると案内されています。出発点は明確に Perl 文化の内部にあります。 ところが日本語圏では、この言葉が Perl を知らない初学者や転職希望者にまで届いています。技術系媒体や転職媒体、学習媒体に至るまで、三大美徳は「プログラマーに向いている人の特徴」や職業理解の一部として紹介されています。一般化の度合いが、日本ではかなり高いのです。 ここで問いの立て方を少し正確にしておきます。英語

なぜ、日本のITシステム開発は丸投げユーザー企業と御用聞きベンダーという相容れない組合せで成立していたのか？ はじめに 日本のITシステム開発が丸投げ型のユーザー企業と御用聞き型のベンダーという相容れない組合せで成立していた理由は、両者の間に配置された 一人、多くても数人 の吸収役が矛盾のすべてを引き受けていたからです。本稿の結論はこの一点に尽きます。以下の議論は全部、この結論を補強するために並べます。 ここで扱う吸収役は、組織図に書かれた上流SEや業務SEの役割と重なる部分があります。重要なのは、彼らが制度的な工程分業の結果として配置されていたのではなく、契約書や組織図の外側で機能的に成立していた点です。「隠れた」という言い方がしっくり来ない読者は、契約関係の外側で実質的な設計判断を担っていた少数 と読み替えてもらって構いません。呼び名よりも、その人物が不在になると案件が止まるという属人

はじめに ウォーターフォール開発がなぜおかしくなりやすいのかを説明するうえで、弁護士が通常は請負契約で仕事をしないという事実は、非常に強い比較材料になります。なぜなら、両者はともに、依頼者が自分では十分に理解できない対象について、専門家に助けを求める知的専門業務だからです。それなのに片方は委任で運用され、もう片方は長年請負で大量流通してきたからです。 もちろん、厳密には「ウォーターフォール=必ず請負」「アジャイル=必ず準委任」と言い切るのは雑です。経済産業省のモデル契約でも、フェーズごとに請負と準委任を選択するとされており、要件定義のような不確実性の高い段階は準委任に寄り、成果物が具体的に特定できる段階は請負に寄ると整理されています。同じ留保は弁護士側にも必要で、契約書作成のように成果物が明確な業務では定額受任もあり得ますし、日本の着手金+報酬金という慣行は純粋な準委任とも少し違います。し

はじめに 「AIが文章を勝手に書くのだから、タイピング能力の価値は下がる」という見方は、一見するともっともらしく見えます。ですが実態は逆です。生成AIが安くしたのは初稿生成であり、価値の中心に残ったのは指示・修正・検証の反復です。しかも実際のChatGPT利用では、会話の多くが実用的助言、情報探索、文章作成に集中しており、仕事用途でも文章作成が中心です。つまりAI時代の仕事は、ますます文字を出し入れして詰める作業へ寄っています。 さらに重要なのは、LLMの利用が「一回聞いて終わり」の道具ではないことです。OpenAIの大規模分析では、利用は時間とともに深まり、判断支援や知識労働での生産性向上につながると整理されています。これは、価値の源泉が単発の生成ではなく、やり取りの往復回数にあることを意味します。往復回数が価値を生むなら、入力摩擦の小ささはそのまま実力差になります。 本稿でいうタッチタ

はじめに 「バイブコーディング」という語は、実際の作業内容をかなり不正確に表しています。 2025年2月にアンドレイ・カーパシーがこの語を出したときの説明は、AIに大きく任せて差分も細かく見ず、エラーをそのまま貼り返し、低リスクの試作を面白がるというものでした。そこにあったのは、厳密な工学用語というより、半ば冗談を含んだミームでした。 ところがその後、この語は「AIでコードを書くあらゆる行為」のように拡大解釈されました。 本来の意味は「コードを理解せずにAIへ任せる狭い流儀」であり、レビューし理解したうえでAIを使う実務的な開発とは別です。つまり最初から、本来の意味と世間の受け取り方にはずれがありました。 本稿の結論を先に言えば、世間がこの語を好んだ理由は、作業の中身にバイブ感があったからではありません。 むしろ、軽く見える名前で参入障壁を低く見せられ、非技術者に希望を売りやすく、企業にも

はじめに ソフトウェア設計の初学者がまず戸惑うのは、原則が一枚岩ではないことです。DRY原則は重複を嫌いますが、SOLID原則の1番目にあたる単一責務原則では変更理由の分離を求めます。表面だけ見れば、同じものをまとめよと言う原則と、違うものを分けよと言う原則が、真正面から衝突しているように見えます。 しかも厄介なのは、この二つの原則のどちらを優先して適用すべきかを、ソースコードのその場の見た目だけでは決められないことです。今は同じように見える処理が、将来も同じようであり続けるとは限りません。逆に、別々の部門に存在する処理であっても、背後では同じ法律や同じ規格に従っているため、本来は一つの知識として扱うべきこともあります。ここに設計判断の難しさがあります。 さらに新人にとっては、この判断が覚えにくいだけでは済みません。正しいかどうかを常に考えさせられ、しかも外したときには責任だけが残ります。

はじめに 優秀なエンジニアほど、短命に見える補助スクリプトや一時的な検証ツールに対しても、名付けやUIを雑に扱いません。表面的には過剰品質に見えることがありますが、実際には逆です。そこにこだわるのは余裕があるからではなく、ソフトウェア開発の本当のコストがどこにあるかを知っているからです。 プログラムというものは、最初から思った通りに動くことのほうがむしろ少ないです。多少なりともバグを含み、想定外の入力や環境差、状態遷移の食い違いを抱えています。したがって開発とは、書く作業以上に、疑い、試し、切り分け、直す作業の連続です。 このとき開発者を最も苦しめるのは、計算量の大きさや文法の難しさだけではありません。実際には、理解しづらい名前、迷いやすい操作、責務の見えない構造といった、認知の摩擦こそが調査と修正を大きく妨げます。だから優秀なエンジニアは、短命なコードであっても、その摩擦を最初から減らそ

はじめに ウォーターフォール開発は、要件定義書、基本設計書、詳細設計書、テスト仕様書、受入条件といった文書体系によって語られがちです。たしかにそれらは必要です。しかし、実際の大型案件が前へ進んだ理由を観察すると、中心にあったのは紙そのものではなく、紙に書き切れない判断、政治調整、優先順位づけ、そして誰かが引き受ける非文書の責任でした。ロイス の 1970 年論文も、分析とコーディングだけでは不十分で、多くの追加工程が必要になり、それらは顧客も開発側も進んで負担したがらないため、管理はそれを売り込み、順守させる役割を持つと述べています。ここには、工程や文書だけでは回らないという事実が最初から表れています。 問題は、文書が不要だったことではありません。問題は、文書が担えるものと担えないものが混同されたことです。文書は、承認、境界、納期、受入条件、変更履歴を残すには向いています。しかし、何を捨て

はじめに 結論から言えば、その理由は 歴史認識の遅れ と 可視性の偏り と 責任境界の理解不足 と AI適性の誤認 が重なっているからです。多くの人は、どの仕事が先に消えるかを、どの仕事が目立つかで判断しており、どの仕事が仕様化しやすく責任から遠いかでは判断していません。 AIが得意なのは、まず 反復的 で 文章化しやすく て 入力と出力の対応が比較的安定 している仕事です。GitHubの調査でも、Copilotの効果は反復作業の精神的負荷軽減や、コンテキストスイッチの削減として現れています。これはまさに、定型的なバックエンド実装と親和性が高いということです。 一方で世間は、AIが最も派手に見せやすい領域を見て、「そこが最も代替されやすい」と短絡しがちです。v0のような製品は生成UIを前面に出し、Figma Makeもノーコードでアプリを作る物語を押し出しています。見た目が一瞬で出るので、

なぜ、なぜなぜは、やっても無意味なのか？ はじめに 製造業の品質管理から始まり、ソフトウェア開発、医療、サービス業に至るまで、「なぜなぜ分析(5Whys)」はあらゆる分野の根本原因分析ツールとして広く普及しています。トヨタ生産方式の生みの親である大野耐一が提唱し、実績を上げたとされるこの手法は、そのシンプルさゆえに研修でも定番の題材となっています。しかし実際の現場で5Whysがまともに機能しているケースは驚くほど少ないです。 本稿では、5Whysが大抵無意味に終わる構造的な理由を複数の観点から分析します。問題はファシリテーションの巧拙や現場の練度にあるのではなく、手法そのものの設計と、それが投入される組織の力学にあります。特に本稿では、「部屋の中の象（elephant in the room）」――全員がその存在を知っているのに誰も指摘しない重大な問題――という比喩を軸に、マネジメントの判

はじめに プロジェクトの失敗要因は、一般には進捗管理や報連相やリスク管理の不足として語られます。もちろんそれらは重要です。ですが、客先常駐や準委任のように顧客が日々の挙動を直接見ている現場では、それより手前にある決定的な変数が見えてきます。それが、案件の要求水準に対して基準未達のメンバーを入れてしまうことです。 しかも問題の中心は、アサインされた本人そのものではありません。本人の力量が不足していることを知りながら、あるいは見極めずにその案件へ投入し、その後の吸収を現場へ押しつける側にあります。ここで起きているのは単なる教育不足ではなく、編成判断の誤りを現場の自己犠牲で埋め合わせさせる構造です。 この問題が厄介なのは、プロマネ研修ではほとんど教えられないことです。研修で扱われるのは体系化された管理技法であり、基準未達の人員投入がどれほど顧客価値と現場負荷を壊すか、その現実は抜け落ちやすいです

車載組込みが専門のソフトウェア開発エンジニアです。アジャイルについて一家言持ってます。

はじめに LSPは長くSOLIDの一角として扱われてきましたが、現在の設計実務から見ると、もはや独立した柱として強く意識する必要はかなり薄れています。これはLSPが間違っていたという話ではなく、LSPが効いていた時代の前提そのものが崩れた、という話です。バーバラ・リスコフとジャネット・ウィングの1994年論文は、上位型で証明できる性質が下位型でも成り立つという 行動的型付け を定式化しましたし、ロバート・C・マーチンも1990年代にはこれをC++のパブリック継承を律する原則として説明していました。 ただし、ここで一つ引っかかる点があります。もし現代の設計がそもそも継承を中心にしていないなら、その継承を安全に使うための原則を、なおも五大原則の一つとして抱え続ける意味はどこまであるのでしょうか。継承を主役から降ろした言語、継承を持ちつつも言語機能で危険を制御する方向へ進んだ言語、いずれもLSP

はじめに 単一責務の原則(SRP)は、SOLIDの中でも最も有名でありながら、最も誤解されやすい原則の一つです。名前だけ見ると、いかにも分かりやすそうです。単一責務という四文字は、いかにも「一つのことだけをやれ」と言っているように見えます。ところが現場では、この原則ほど人によって解釈がぶれるものもあまりありません。 ある人は、SRPを「一つのクラスは一つのことだけをするべきだ」と理解します。ある人は「変更理由が一つであるべきだ」と理解します。さらにある人は「一つの関係者にだけ責任を負うべきだ」と理解します。どれも全くの外れではないのですが、どれか一つだけを掴むと、すぐに話が崩れます。ここに、分かりやすそうで分かりにくいという、この原則特有の厄介さがあります。 しかもSRPは、コードの見た目だけでは判断できません。短くて綺麗なクラスがこの原則を守っているとは限りませんし、少し大きめのクラスで

はじめに 「2020年代はオブジェクト指向が衰退した」という言い方は、事実の一部だけを見て全体に拡張した見方です。実際に弱くなったのは、深い継承ツリーやUMLの完全記述、XMLやSOAPと結びついた重い企業開発の作法であって、オブジェクト指向の中核そのものではありません。 むしろ2020年代の主流言語や設計実践は、オブジェクト指向を否定する方向ではなく蒸留する方向に進みました。Goはinterfaceを暗黙実装にし、TypeScriptは構造的部分型を採用し、Swiftはプロトコル合成を前面に出し、Rustはtraitとトレイトオブジェクトで共有振る舞いと多相性を扱います。共通しているのは、固定的な階層より役割と合成を重視することです。 ところが現場で見えやすく弱くなったものが、ちょうど2000年代に「オブジェクト指向らしさ」の看板になっていました。そのため、看板が外れると建物まで消えたよ

はじめに LLMの普及は知識へのアクセスの形を大きく変えました。人間は膨大な文章を瞬時に生成できる装置を手に入れました。しかし同時に避けられない問題としてハルシネーションが存在します。これはAIが誤った内容をもっともらしい文章として生成してしまう現象です。 ハルシネーションは単なる技術的欠陥ではありません。むしろ人間の認知と深く結びついた問題です。AIは確率的な言語生成装置であり、真理を直接扱っているわけではありません。それにもかかわらず人間は流暢な文章を読むとそれを知識として受け取ってしまいます。ここに問題の本質があります。 この問題に対して、モデル改良やRAGなどの技術的対策は重要です。しかしそれだけでは十分ではありません。AIが生成する文章を適切に扱うためには、人間側の思考の枠組みが必要になります。その枠組みを提供するのが哲学です。本稿では、なぜLLM時代に哲学を学ぶ必要があるのかを

はじめに 2026年2月に「ChatGPTからClaudeへ乗り換える人が続出した」と感じられた現象は、単なる流行ではなく、複数の要因が同時に噛み合った結果として説明できます。本レポートは、当該時期に観測された出来事とプロダクト変更を材料に、なぜ移住の波が立ったのかを因果の形で整理します。なお、「続出」という表現自体がSNS上の可視性に引きずられている可能性がある点は、あらかじめ留保しておきます。 結論を先に言うと、不満の蓄積と大義名分の供給と乗り換え摩擦の低下が同時発火したのが本質です。加えて、Claude側が「同僚化」する体験を前面に出し、比較の土俵そのものを変えた点が波の増幅器になりました。以降、時間軸と構造の両面から、やや辛口に分解します。 2026年2月に何が起きたか まず時間軸を確認します。2026年2月13日にChatGPT上でGPT-4o等が提供終了になり、ユーザーにとって

はじめに アジャイルという言葉は日本でも広く使われているが、その成立背景や思想的前提が正確に理解されているとは言い難いです。とくに日本では、アジャイルが単なる開発手法やプロジェクト管理技法として矮小化され、なぜそれがアメリカで生まれ、日本ではなかったのかという問いが正面から扱われることはほとんどありません。 しかしこの問いは、単なるIT史の話ではなく、労働観、人間観、能力分布、社会構造にまで踏み込まないと解けない問題です。 本レポートでは、アジャイルを技術論や精神論から切り離し、生産方式の進化史として捉え直し、なぜアジャイルが日本ではなくアメリカで生まれたのかを論理的に整理します。 トヨタ生産方式が成立した日本的前提 トヨタ生産方式は、日本の高度経済成長期における労働人口の質と雇用慣行を前提として成立しました。長期雇用、現場教育、改善文化が組み合わさり、オペレーターが単なる作業者ではなく、

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

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

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

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

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

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

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

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