問いを立てたものたち
問いを立てたものたち — OOP (Alan Kay), MVC (Trygve Reenskaug), DDD (Eric Evans), Agile, DRY (Dave Thomas), CQRS (Greg Young), DevOps (Patrick Debois)

2000年、Roy T. Fieldingはカリフォルニア大学アーバイン校に博士論文を提出しました。RESTの原典となったこの論文の第1章、読者が最初に目にするページに、Monty Pythonの『建築家のスケッチ』が引用されています。

すみません…「ナイフ」と言いましたか？
— シティ・ジェント #1 (マイケル・パーリン), 『建築家のスケッチ』 [111]

私は以前、この引用の意味が分かりませんでした。なぜREST論文の序章がMonty Pythonのコメディではじまるのか？

屠殺場の建築家

屠殺場しか設計したことのない建築家が、集合住宅の設計を依頼される。彼は集合住宅を屠殺場として設計してしまう。入居者が回転ナイフで切り刻まれる部屋を案内しながら、建築家は誇らしげです。

これは「屠殺場しか設計したことのない建築家に集合住宅の設計を依頼する」——つまり対象を無視したソフトウエア建築手法の適用への戒めなんだと理解しました。（マイクロサービスが頭に浮かびます？）

そしてFieldingはこのコントの直後にこうも書いています。”design-by-buzzword is a common occurrence.”（バズワードによる設計はよくあることだ）

RESTがどのようにバズワード化したかは、別の記事で詳しく書きました。追うと、一つのパターンが浮かび上がります。原典の「問い」が消え、名前だけが権威の器として流通し、有効成分が抜かれ、その欠損を補うエコシステムが積み上がり、次のバズワードが「超えた」として登場する。

これはRESTだけの話ではありません。design-by-buzzword には半世紀以上繰り返されたパターンがあります。

パターンの骨格

  1. 問題の「問い」から始まる。
  2. 問いのWHATが実践のHOWになり普及する。
  3. その時、名前が権威の器になり、核心の落ちた劣化が確信とともに進む。
  4. 有効成分を落として、その欠損を補うエコシステムを積み上げる。
  5. 次のバズワードで「解決」する。

このパターンは、半世紀にわたって繰り返されています。時に普及版が「実用的 vs 教条的」という枠を作り、修正の試み自体が封じられることもあります。

OOP

1967年、Alan KayはSimulaというノルウェー製言語に出会いました。オブジェクトという概念の萌芽がそこにありました。しかしKayが興奮したのはオブジェクトそのものではなく、その先に見えたビジョンでした。生物の細胞が独立して動きながら全体として機能するように、ソフトウェアも自律的なセルの集合として設計できるのではないか。

Kayの問いの核心はメッセージパッシングでした。細胞が化学物質を交換して通信するように、オブジェクトもメッセージを送り合うことで協調する。内部状態は隠蔽され、外部からはメッセージしか届かない。データと手続きの分離ではなく、自律的なエージェントの通信ネットワークとしてシステムを設計する——それがSmalltalkで実現しようとしたものでした。

しかし「オブジェクト指向」という言葉が広まる過程で、メッセージパッシングは消えました。クラスと継承が「OOPの三大原則」に昇格し、カプセル化、継承、ポリモーフィズムという三つの言葉が教科書に並びました。Kayが最も重視した概念が、最も読み飛ばされる前提になりました。

結果として何が起きたか。継承の深いヒエラルキー、神クラス、密結合。「OOPは複雑になる」という不満が蓄積し、関数型プログラミングが「OOPを超えた」として登場しました。しかしKayがSmalltalkで実現しようとした自律的なエージェントの通信ネットワークは、関数型の文脈でアクターモデルとして再発明されました。Erlangが1986年に、Akkaが2009年に。Kayが意図的に中心に置いたものが別の名前で再実装されました。

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.”

「『オブジェクト』という用語を作ったことを後悔している。多くの人が些末なアイデアに注目してしまった。本当に大きなアイデアはメッセージングだった」

この発言の構造を覚えておいてください。後でまた出てきます。

MVC

1978年、Trygve ReenskaugはXerox PARCに滞在していました。そこで彼が向き合っていた問いはシンプルでした。「ユーザーの頭の中にある世界観を、どうコードに写し取るか」。

ユーザーはアプリケーションを使うとき、自分なりのメンタルモデルを持っています。スプレッドシートを使う会計士は、セルと数式の世界を頭の中に持っています。そのメンタルモデルとシステムがどれだけ一致しているかが、使いやすさを決めます。ReenskaugはModelをそのユーザーのメンタルモデルそのものとして定義しました。Controllerはユーザーとシステムの翻訳者。Viewはその表現。

三つのコンポーネントへの分割は、コードの整理のためではありませんでした。「ユーザーの世界観を正確に写し取る」という問いに答えるための構造でした。

しかしWebでMVCが広まる過程で、この問いは消えました。「コードをどの三つのレイヤーに分けるか」という分類問題になりました。ModelはDBアクセスの場所になり、ControllerはHTTPリクエストを処理する場所になり、ViewはHTMLを出力する場所になりました。ユーザーのメンタルモデルという概念は、どの書籍にも出てこなくなりました。

Fat Controller論争とFat Model論争が始まりました。「ロジックをどこに書くべきか」という問いに、フレームワークごとに違う答えが生まれました。WebのMVCとGUIのMVCが別物なのに同じ名前で呼ばれ、「本当のMVC」を巡ってMVPとMVVMとMVIが登場した。名前を奪った結果、名前を巡る戦争が始まりました。一種のコメディです。元々の「本当の」が違ってるのですから。

Reenskaugが問うた「ユーザーのメンタルモデルを写せているか」は、今は誰も気にしてません。25年後、Evansが別の角度から同じ問いを立てることになります。

DDD

2003年、Eric Evansは「Domain-Driven Design」を出版しました。550ページの厚い本でした。その本には二種類のパターンが書かれていました。EntityやValueObject、Repository、Aggregateといった戦術的パターン。そしてUbiquitous LanguageとBounded Contextを中心とした戦略的パターン。Evansが本当に伝えたかったのは後者でした。

Evansの問いは「複雑なドメインロジックをソフトウェアに正確に写し取るにはどうするか」でした。その答えの核心は、開発者とドメイン専門家が同じ言語で話すこと（Ubiquitous Language）と、モデルの境界を意識的に引くこと（Bounded Context）にありました。Repositoryは実装の道具にすぎませんでした。

しかしDDDが広まる過程で、戦略的パターンは消えました。戦術的パターンは具体的でコードに落としやすい。戦略的パターンは抽象的で文脈依存度が高い。「DDDを導入する」がEntityクラスとRepositoryクラスを作ることになりました。

Bounded Contextという境界を引く思考が落ちた結果、境界のないシステムが量産されました。「DDDはコードが増えるだけ」「オーバーエンジニアリングだ」という不満が蓄積しました。

Evansは後に語っています。「戦略的設計を前面に出すべきだった」。この後悔が正しかったことは、マイクロサービスの事例が証明します。

Agile

2001年2月、スノーバードのスキーリゾートに17人が集まりました。彼らが共有していたのは一つの怒りでした。「変化に対応できないウォーターフォールが、動くソフトウェアを届けることを妨げている」。二日間の議論の末に生まれたのが「アジャイルソフトウェア開発宣言」、4つの価値と12の原則でした。

マニフェストの最初の価値はこう書かれています。「プロセスやツールよりも個人と対話を」。

マニフェストは圧縮されすぎていました。4つの価値と12の原則という極度に短い形式で公開されたため、コピーのコピーではなくコピーそのものが流通しました。スクラムというフレームワークがその器になりました。スプリント、デイリースタンドアップ、バーンダウンチャート——儀式が「アジャイル」になりました。

「プロセスよりも個人と対話を」が、プロセスで実装されました。

産業化はRESTやDDDより速く、より大きかった。「アジャイルコーチ」という職業が生まれ、SAFe（Scaled Agile Framework）という、アジャイルが否定したはずの重厚なプロセスが「エンタープライズアジャイル」として売られました。批判者を「アジャイルを理解していない」とコーチする機構がエコシステムに組み込まれた。修正しようとするほど、原理主義者のラベルが強まります。

署名者の一人Dave Thomasは2014年のブログで書きました。”Agile is Dead (Long Live Agility)”——「Agile（名詞）を捨てて、agile（形容詞）に戻れ」。名詞は売れます。認定できます。コンサルできます。形容詞は売れない。

Thomasが代わりに提示したものは、マニフェストですらありませんでした。「今どこにいるかを把握し、目標に向けて小さな一歩を踏み出し、学んだことで理解を修正し、繰り返す」。単なる認識論的な態度でした。

CQRS

Greg YoungはDDDコミュニティの中から出てきました。彼の出発点はシンプルな観察でした。読み取りと書き込みで、最適なモデルが違う。

書き込みはドメインの整合性を守るために複雑なモデルが必要です。読み取りは画面表示のために非正規化されたフラットなデータが欲しい。同じモデルで両方を満たそうとするから無理が生じる。分離すればいい——それだけのことでした。

「Command Query Responsibility Segregation」という名前がついた瞬間に、誤解が始まりました。Commandは業務の意思決定であり、Queryは表示のための構造です。Youngが分けたかったのはこの二つでした。しかし「コマンドとクエリを物理的に分離するアーキテクチャ」として読まれた。データベースを分ける。インフラを分ける。Young本人が「単なるモデルの分離であって、データベースを分けることではない」と何度も言い続けました。Fieldingと同じ軌跡でした。

さらに、Event Sourcingが等式で結びつけられました。「CQRSをやるならEvent Sourcing」。Young自身はCQRSとEvent Sourcingは独立した概念だと明言していましたが、届きませんでした。

CQRSを導入するとEvent Sourcingが必要になり、Event Sourcingを導入すると分散メッセージングが必要になり、それを導入するとSagaパターンが必要になった。前の誤用が次の誤用を要請する連鎖です。各段階で「一生懸命やっている」から、問いに答えているかどうかを検証する余裕がない。

「CQRSは複雑すぎる」という批判が出ました。しかしその複雑さの多くはCQRS本体ではなく、不要な結合から来ていた。誤用が生んだ複雑さが、概念本体への批判になりました。

Youngは言い続けました。「ほとんどのシステムにEvent Sourcingは要らない」。

マイクロサービス

2000年代、AmazonとNetflixはそれぞれ異なる危機に直面していました。Amazonはモノリスが開発速度を制約する問題、Netflixはデータセンター障害でサービスが全停止する問題。しかし彼らが向き合っていたのは、技術の問いである前に組織設計の問いでした。「チームが独立して判断し、独立してデプロイできる構造をどう作るか」。

Amazonの「2ピザルール」はチームサイズの話であり、Netflixの「Chaos Monkey」は障害への耐性を組織に埋め込む話でした。サービスの分割は手段であって、目的ではなかった。

しかし「マイクロサービス」という名前が広まる過程で、組織設計の問いは消えました。「サービスを小さく分割する」アーキテクチャパターンになりました。組織を変えずにシステムだけ分割する「マイクロサービス移行プロジェクト」が各社で始まりました。

サービスは分割されましたが、境界は恣意的でした。Bounded Contextという問いが落ちたまま分割したから、AサービスがBサービスの内部実装を知っている。デプロイは独立しているはずなのに、一つを変えると他が壊れる。ネットワーク越しの密結合——「Distributed Monolith（分散モノリス）」ができました。モノリスの複雑さとマイクロサービスの運用コストを両方引き受ける最悪の状態でした。

「解決策」として登場したのが「モジュラーモノリス」でした。適切な境界を持つモノリス。それはEvansが2003年に書いた「Bounded Context」の再発明じゃないでしょうか？

20年と一度の巨大な失敗を経て、出発点に戻った。

Martin Fowlerは2014年にマイクロサービスの記事を書いた後、2015年に「マイクロサービスの前提条件」を書きました。組織が準備できていないなら、マイクロサービスはモノリスより悪い結果をもたらす。手遅れでした。

DevOps

2008年、Patrick DeboisとAndrew Shaferはアジャイルカンファレンスの廊下で話していました。向き合っていたのは技術の問題ではない。「開発チームがリリースしたものを、運用チームが壊れたまま受け取る」という組織の断絶でした。壁を壊すことが問いでした。

「Dev」と「Ops」を結合しただけの名前は、ソフトウェア開発と運用のすべてに貼れました。RESTやアジャイルと同じく、覆える面積が最大級でした。

しかし組織文化の変革という問いは消えました。CI/CDパイプライン、Kubernetes、Infrastructure as Code——ツールチェーンの導入が「DevOpsを導入する」になりました。

産業化の構造がアジャイルとは違いました。アジャイルの産業化はコンサルと研修が主体でしたが、DevOpsはクラウドベンダーが担った。AWSがDevOpsを定義し、AzureがDevOpsを認定し、GCPがDevOpsを売りました。「DevOpsにはこのツールが必要」という等式は直接売上に繋がる。概念の誤用をビジネスモデルに組み込んだ主体が産業化を担うと、修正はほぼ不可能です。Fieldingがブログで反論できても、AWSのホワイトペーパーには反論できない。

最大の皮肉はここにあります。DevとOpsの断絶を解消するための概念が、Platform Engineeringチームという新しいサイロを生んだ。断絶を解消するための、断絶が作られました。

ロングショットで見れば喜劇

悲劇と喜劇が同居しています。個々の開発者がイベントソーシングのスキーママイグレーションと格闘している姿は、クローズアップで見れば悲劇ですが、引いて見れば「Greg Youngが要らないと言い続けたものを全力で実装している」喜劇です。

「プロセスよりも個人と対話を」をプロセスで実装した組織も、断絶を解消するために新しい断絶を作ったDevOpsも、20年かけてBounded Contextを再発明したマイクロサービスも。クローズアップでは悲劇、ロングショットでは喜劇。

Fieldingは知っていた

冒頭の屠殺場の建築家を思い出してください。

ここまで読んできた事例は、すべてあの一文に収まります。Kayのメッセージパッシングを落としてクラスと継承を取ったのも、Reenskaugのメンタルモデルを落として三層分割を取ったのも、Evansの戦略的設計を落として戦術的パターンを取ったのも。業界は屠殺場の建築家となり、毎回違う名前で屠殺場を設計していた。

Fieldingはこの警告を、論文の本文より前に置きました。最初に目に入る場所です。そして読者はその警告を読んで、警告の通りに論文を誤用した。

Kayの発言の構造を覚えていますか。「自分が名づけた言葉が、自分の意図と違う意味で広まった」という嘆き。Evansも、Thomasも、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.

「自分が対価を得ている理由、優れた仕事で尊敬されている理由は、自分の頭を使って自分のシステムの文脈に合わせた詳細を埋めていける能力があるからだということに、いつになったら気づくのだろう」

その留保が切ない。

警告を理解できる人間は最初から警告を必要としない。警告を必要とする人間は警告を理解できない。

FieldingはREST論文の最初に警告を書いた。その警告、RESTは最大の誤用の源になった。彼は25年間、それを眺め続けた。

なぜ変わらないのか

紀元前399年、アテネ。

民主政で弁論能力は権力に直結しました。その需要に応えたのがソフィスト——「どんな主張でも説得力を持って論じる技術」を報酬と引き換えに教えるプロの弁論家たちです。ソクラテスは「その答えが答えている問いは何か」を問い続けました。若者たちに「自分は何も知らない」と気づかせる対話は、秩序を脅かすと見なされ「神々を敬わず若者を堕落させた」として処刑されました。一方、その声を伝えたソフィストの技術は体系化されて後世に伝わりました。伝える者の力は、問いを発する者より強い。人はwhatを立てた人より、howを売る人の声を聞く。

業界は次のバズワードを待っています。

参照

創始者たちの嘆き