原題: Buzzwordによる設計
著者: Akihito Koriyama
公開日: 2026-03-25
ソースURL: https://koriym.github.io/blog/2026/03/25/design-by-buzzword/
アーカイブ日: 2026-03-26
Roy T. Fieldingは2000年の博士論文（RESTの原典）の第1章冒頭に、Monty Pythonの『建築家のスケッチ』を引用している。屠殺場しか設計したことのない建築家が集合住宅を屠殺場として設計してしまうコントだ。そしてFieldingはその直後に書く——「design-by-buzzword is a common occurrence.」（バズワードによる設計はよくあることだ）。
この記事は、その警告がいかに正確だったかを、ソフトウェア業界の半世紀にわたる具体例で証明する。OOP、MVC、DDD、Agile、DRY/CQRS、マイクロサービス、DevOps——それぞれに「問いを立てた創始者」がいて、「名前だけが流通した誤用の歴史」があり、「誤用を訂正しようとして届かなかった創始者の嘆き」がある。
すべての事例に共通する構造：
このパターンが半世紀以上繰り返されている。
Alan KayがSimulaで見たのは「生物の細胞のように、自律的なエージェントがメッセージを交換して協調するシステム」だった。Smalltalkで実現しようとした核心はメッセージパッシングだった。
しかし「オブジェクト指向」が広まる過程でメッセージパッシングは消え、クラスと継承が「OOPの三大原則」（カプセル化・継承・ポリモーフィズム）として定着した。Kayが最も重視したものが最も読み飛ばされた。
結果：継承の深いヒエラルキー、神クラス、密結合。「OOPは複雑になる」という不満から関数型プログラミングへの移行が進んだが、Kayが意図したメッセージパッシングはアクターモデル（Erlang 1986、Akka 2009）として「再発明」された。
Kayは1998年のメールで書いている：
“I’m sorry that I long ago coined the term ‘objects’ for this topic because it gets many people to focus on the lesser idea. The big idea is messaging.”
Trygve ReenskaugがXerox PARCで向き合っていた問いは「ユーザーの頭の中にある世界観をどうコードに写し取るか」だった。Modelはユーザーのメンタルモデルそのものとして定義され、Controllerはユーザーとシステムの翻訳者だった。
WebでMVCが広まる過程で、この問いは消えた。「コードをどの三層に分けるか」という分類問題になり、ModelはDBアクセスの場所、ControllerはHTTPリクエストを処理する場所になった。Fat Controller論争とFat Model論争が始まり、MVPとMVVMとMVIが派生した。
Reenskaugが問うた「ユーザーのメンタルモデルを写せているか」は、どの書籍にも出てこなくなった。25年後、Evansが別の角度から同じ問いを立てることになる。
Eric Evansの550ページの本には二種類のパターンがあった。EntityやRepository、Aggregateといった戦術的パターンと、Ubiquitous LanguageとBounded Contextを中心とした戦略的パターン。Evansが伝えたかったのは後者だった。
しかし戦略的パターンは抽象的で文脈依存度が高く、戦術的パターンは具体的でコードに落としやすい。「DDDを導入する」がEntityクラスとRepositoryクラスを作ることになった。
Bounded Contextという境界を引く思考が落ちた結果、境界のないシステムが量産された。Evansは後に「戦略的設計を前面に出すべきだった」と語っている。
「アジャイルソフトウェア開発宣言」は4つの価値と12の原則という極度に短い形式で公開されたため、コピーそのものが流通した。スプリント、デイリースタンドアップ、バーンダウンチャートという儀式が「アジャイル」になった。
「プロセスよりも個人と対話を」が、プロセスで実装された。
産業化はRESTやDDDより速く大きかった。「アジャイルコーチ」という職業が生まれ、SAFe（Scaled Agile Framework）という、アジャイルが否定したはずの重厚なプロセスが「エンタープライズアジャイル」として売られた。署名者の一人Dave Thomasは2014年に書いた：「Agile（名詞）を捨てて、agile（形容詞）に戻れ」。名詞は売れる。形容詞は売れない。
Greg YoungのCQRSは「読み取りと書き込みで最適なモデルが違う」というシンプルな観察だった。しかし「コマンドとクエリを物理的に分離するアーキテクチャ」として読まれ、さらにEvent Sourcingが等式で結びつけられた。CQRSをやるならEvent Sourcing、Event Sourcingをやるなら分散メッセージング、それをやるならSagaパターン——前の誤用が次の誤用を要請する連鎖が生まれた。
Youngは言い続けた：「ほとんどのシステムにEvent Sourcingは要らない」。誤用が生んだ複雑さが、概念本体への批判になった。
AmazonとNetflixが直面していたのは技術の問題である前に組織設計の問いだった。「チームが独立して判断し、独立してデプロイできる構造をどう作るか」。サービスの分割は手段で、目的ではなかった。
しかし「サービスを小さく分割するアーキテクチャパターン」として普及した。組織を変えずにシステムだけ分割した結果、AサービスがBサービスの内部実装を知っているネットワーク越しの密結合——「Distributed Monolith（分散モノリス）」が生まれた。
「解決策」として登場したのが「モジュラーモノリス」だった。適切な境界を持つモノリス——それはEvansが2003年に書いていたことだった。20年と一度の巨大な失敗を経て、出発点に戻った。
Patrick DeboisとAndrew Shaferの問いは「開発チームと運用チームの断絶をどう解消するか」という組織文化の変革だった。しかしCI/CDパイプライン、Kubernetes、Infrastructure as Code——ツールチェーンの導入が「DevOpsを導入する」になった。
アジャイルの産業化がコンサルと研修主体だったのに対し、DevOpsはクラウドベンダーが担った。AWSがDevOpsを定義し、概念の誤用をビジネスモデルに組み込んだ。Fieldingがブログで反論できても、AWSのホワイトペーパーには反論できない。
最大の皮肉：DevとOpsの断絶を解消するための概念が、Platform Engineeringチームという新しいサイロを生んだ。
Kayのメッセージ「自分が名づけた言葉が、自分の意図と違う意味で広まった」という嘆き——EvanもThomasonもYoungもFowlerも、同じ構造の発言をしていた。Fieldingも2021年にツイートで書いた：
“When will people realize that the reason they are paid, the reason they are respected for good work, is because they can use their own minds to fill in the details appropriate to the context of their own systems.”
紀元前399年のアテネ。ソクラテスは「その答えが答えている問いは何か」を問い続けた。しかしその声を伝えたソフィストの技術は体系化されて後世に伝わった。伝える者の力は、問いを発する者より強い。人はWHATを立てた人より、HOWを売る人の声を聞く。
業界は次のバズワードを待っている。
この記事の卓越した点は、バラバラに見えたソフトウェア史の「失敗の物語」を一本のパターンとして見せたことだ。OOP、MVC、DDD、Agile、CQRSを別々に語ることはできるが、「問いを立てた者の嘆き」という共通構造で串刺しにした視点は独創的で、一度見たら目を離せない。
特に印象的なのは末尾のソクラテスとソフィストの比喩だ。「伝える者の力は、問いを発する者より強い。人はWHATを立てた人より、HOWを売る人の声を聞く」——これはソフトウェア業界に限らず、知の伝達一般に関わる構造的な悲劇を指している。
またFieldingが2000年の論文冒頭に「バズワードによる設計への警告」を書き、読者がその警告を読んで警告通りに誤用したという皮肉は、喜劇的でありながら痛烈だ。「警告を理解できる人間は最初から警告を必要としない」という文章は、長く引用され続けるだろう。
10年後、20年後、AIやLLM周辺で同じパターンが繰り返されたとき、この記事を手元に置いておきたいと思わせる。それが採択の理由だ。
タグ: #ソフトウェア設計 #アーキテクチャ #OOP #DDD #Agile #マイクロサービス #DevOps #歴史 #パターン