@h13web です。
昨年の秋に、「グローバル展開にむけたアプリと基盤の再構築」という技術ブログを読みました。日本を代表するテック企業であるメルカリが、グローバル展開のための基盤を刷新したという話です。
この中で語られている「Microservicesの課題」については、思うところがありました。実は弁護士ドットコムでも、かつて似たような体験をしています。モノリスをマイクロサービスに分割するプロジェクトがあり、内部設計より疎結合化が優先され、ドメインを横断するコンテキストが各サービスにコピーされ、開発速度はモノリスのときよりもむしろ落ちました。
その体験を思い起こしながら読み進めるうち、うまく言葉にできない違和感のようなものが湧き上がってきました。記事の筆致は丁寧で、反省の言葉もあります。「今後マイクロサービスを初手で選ぶことは、特別な理由のない限りしないほうがいい」。その率直さには好感を持ちました。違和感の正体はすぐには整理できなかったのですが、時間が経つにつれて、それが何だったのか少しずつ見えてきたように思います。
ドメインの境界線
記事の中でもっとも示唆的だったのは、こういう趣旨の記述でした。
初期のモノリスでは適切なドメイン分離ができなかったために、コードの密結合と複雑化が発生した
ここで立ち止まって考えてみます。
モノリスの問題の本質は、「モノリスであること」だったのでしょうか。あるいは、ドメイン分離がうまくできていなかったことだったのでしょうか。もし後者なら、マイクロサービスへの移行は、その問題にそのまま効く処方箋だったのでしょうか。
サービスの境界線を引くことと、ドメインの境界線を引くこと。この二つは似ているようで、まったく別の行為です。前者はデプロイや運用の境界であり、後者はモデルの境界です。
もちろん、両者がうまく一致することはあります。けれど一致させるには、先にドメインの理解が要ります。そこが曖昧なままサービスだけを分けても、得られるのは適切に独立したシステムではなく、凝集度の低いサービスの群れです。問題が解決するのではなく、分散して見えにくくなるだけです。
なぜその判断は魅力的だったのか
マイクロサービスを選んだ判断にも合理性はあったはずです。数百人規模のエンジニアが、ひとつの巨大なコードベースの上で開発する。CI のビルド時間は伸び、デプロイは詰まり、チーム間の依存で開発速度は落ちる。こうした問題はたしかに実在し、脱モノリスの圧力になります。
組織境界とデプロイ境界を揃えたい。チームごとの自律性を高めたい。技術的にも、当時の Go、Kubernetes、gRPC などは強く魅力的に見えたと思います。その判断を、単なる浅薄な流行追随として片付けるのはフェアではありません。
ただ、それでもなお気になることがあります。
その圧力に対して、マイクロサービスは唯一の解だったのでしょうか。
モジュラーモノリスという選択肢はなかったのか。ビルドやテストの仕組みを改善する余地はなかったのか。モノレポのままでも、モジュール境界を厳格にする道は検討されたのか。あるいは、分割するにしても、それは本当にドメインの理解に基づいたものだったのか。
わたしが気になるのは、技術選定そのものより、意思決定の過程に設計があったかどうかです。
「この技術が魅力的だ」と感じることと、「この問題にはこの解がもっとも適している」と判断することは、似ているようで別の行為です。前者は動機であり、後者は設計です。公開された振り返りを読む限り、実装や運用上の痛みはよく語られていた一方で、代替案の比較や、どの制約を受け入れ何を捨てるのかという設計判断は、あまりはっきり語られていないように見えました。
内部でどのような議論があったのかは外からはわかりません。だから断定はできません。ただ、もしそこに「何を作りたいか」だけでなく、「何を禁じるべきか」という視点が十分になかったのだとしたら、それは単なる技術選定ではなく、設計の不足だったのだと思います。
これは他人事ではありません。冒頭で触れたとおり、弁護士ドットコムでも同じ痛みを経験しています。当時の振り返りには、エリック・エヴァンスの言葉を引きながら、こう書かれています。
分割をするという結論ありきではなく、巨大なコンテキストである場合は無理に分割はしないという判断も冷静に柔軟に行う必要もあります。
この教訓は、議論の中で発見されたというより、コードの中から、痛みを伴って発見されたものでした。
Design by Constraint
ここで大事になるのが、「制約」(Constraint) という考え方です。
ソフトウェアの世界でこのことを明確に言語化した人物のひとりが、Roy Fielding です。2000 年の博士論文。REST を定義したことで知られるあの論文です。
多くのエンジニアは REST を HTTP メソッドの作法くらいに理解していますが、Fielding が本当に論じたのは、アーキテクチャスタイルにおける制約の意味でした。
An architectural style is a coordinated set of architectural constraints that restricts the roles/features of architectural elements and the allowed relationships among those elements within any architecture that conforms to that style.
（アーキテクチャスタイルとは、アーキテクチャ上の制約を協調的にまとめたものであり、そのスタイルに準拠するあらゆるアーキテクチャにおいて、構成要素の役割や機能、および要素間の許容される関係を制限するものである。）
制約とは、不自由さを持ち込むものではありません。局所最適な判断を抑え、長期的なスケーラビリティや進化可能性を守るためのものです。
型システムは、何でも入れられる変数を禁じることでバグを減らします。リレーショナルデータベースの正規化は、冗長な表現を制約することで一貫性を保ちます。UNIX の「ひとつのことをうまくやる」という考え方は、責務を制限することで組み合わせ可能性を生みました。
先人たちは、自由度を増やすことが常に良いわけではないことを知っていました。だからこそ、あえて制約を置いたのだと思います。
制約は自由の敵ではありません。制約は価値の源泉です。
そして重要なのは、制約を丸暗記することではありません。AI がコードを書く時代になっても人間が RFC や論文を読むのは、読む行為それ自体や、内容の暗記が目的になるわけではないのです。
大切なのは、なぜその制約が置かれたのか、その思想が自分たちの判断の中に継承されているかどうかです。
Design by Buzzword
Fielding は、もうひとつ重要なことも書いています。
design-by-buzzword is a common occurrence. … a good designer should select a style that matches the needs of a particular problem being solved.
（バズワードに基づく設計はよくあることだ。……優れた設計者は、解こうとしている特定の問題のニーズに合ったスタイルを選ぶべきである。）
バズワードに基づく設計は、昔から繰り返されてきました。
REST そのものもそうでした。分散ハイパーメディアの設計原理だったはずのものが、「HTTP メソッドで CRUD するスタイル」へと単純化され、思想との乖離を指摘すると、「理想より、動くコードだ」と返される。その経緯は @koriym さんの「REST はどのようにバズワード化したか」に詳しく書かれています。
マイクロサービスにも、同じことが起きたのではないでしょうか。
Conway's Law（コンウェイの法則）やドメイン駆動設計の文脈から、「適切な境界を持つ独立したコンテキスト」という思想が抜け落ち、「サービスを小さく分ける」という形だけが流通する。そこに「マイクロサービス」という名前が載り、成功事例とチュートリアルだけが再生産される。
道具の使い方は知っている。しかし、なぜその道具がその形をしているのかには関心が向かない。
これは、特定の企業や特定の世代だけの問題ではありません。思想から形だけを切り出して消費する構造は、ソフトウェアの世界に繰り返し現れます。
責任の蒸発
もうひとつ、あの記事を読んで考えたことがあります。
なぜフルリニューアルは、あれほど魅力的に見えるのでしょうか。
既存コードを地道に改善していく仕事より、新しいスタックでゼロから書き直す仕事のほうが、どうしても華やかに映る。そこには学習機会もあり、設計の自由度もあり、キャリア上の魅力もあります。この感覚自体は、多くのエンジニアにとって自然なことだと思います。
問題は、そのあとです。
リニューアルの前半は楽しい。構想があり、図が描ける。しかし後半には、移行、互換性、運用、データ整合性、既存資産との接続、負債の返済が待っています。システム開発の難所は、たいていそこにあります。
そして組織はしばしば、この後半をうまく報いません。新しいものを始める人は評価されやすいのに、それを事業の現実に接続し、泥を被りながら完遂する人は可視化されにくい。結果として、大きな刷新は「始める人」と「最後まで背負う人」が分離しやすい。
実際、リニューアルの前半——技術選定やアーキテクチャの構想——を主導したエンジニアが、後半の泥臭い移行作業を待たずに転職していくケースは珍しくありません。人が環境を変えること自体は自然なことですし、それを責めるつもりもありません。
ただ、会社の主要なサービスの設計を任されるということは、事業の根幹に手を入れるということです。それほどの変更を始めるなら、本来は「始めること」だけでなく、「完遂すること」や「残された組織でも回ること」まで含めて設計されるべきです。
にもかかわらず、現実には、壮大な刷新ほど前半の意思決定が称賛され、後半のしんどさは組織に残る。この現象を、わたしは「責任の蒸発」と呼びたくなります。
ここでいう責任とは、個人の矜持の問題ではありません。むしろ、組織が大規模刷新をどう評価し、どう引き継ぎ、どう完遂責任を持たせるかという設計の問題です。矜持の不足というより、矜持に依存しなければ回らない仕組みのほうに、より大きな問題があるのだと思います。
作り変えられていくわたしたち
いま、「マイクロサービス」の代わりに「AI エージェント」、「サービス分割」の代わりに「業務の完全自動化」が語られています。バズワードが入れ替わり、投資家向けのナラティブが更新され、採用ページの言葉も変わっていく。
けれど問いそのものは、あまり変わっていません。
以前の記事で、ニコラス・カーの「ネット・バカ」を取り上げたとき、こんな一節を引用しました。
以前の脳が恋しくなった。
インターネットがわたしたちの思考の仕方を変えたように、思想から形だけを取り出して高速消費する文化もまた、わたしたちの「設計する脳」を少しずつ変えているのかもしれません。
あの記事を読んで言語化できなかった違和感の正体は、たぶんここにあります。
制約の思想を読み解かずに形だけを消費すること。大きな設計判断を、完遂責任まで含めて設計できないこと。この二つは、根のところでつながっています。どちらも、設計を短期的な魅力や表層的な形へ回収してしまうからです。
コードを読まなくなること自体は問題ではありません。AI がコードを書く時代に、それはある意味で自然な流れです。問題は、コードを読まなくなったとき、制約の思想をどう継承するのかです。
だからこそ、意識的である必要があるのだと思います。
形だけを消費せず、思想まで辿る。バズワードで止まらず、その制約を問い直す。デメリットを含めて選択肢を並べ、何を可能にし、何を禁じるのかを見たうえで判断する。
そういうエンジニアが、これからもっと必要になるはずです。
あなたがいま選んでいるアーキテクチャ。いま導入しようとしているパターン。その背後にある制約の思想を、あなたは継承しているでしょうか。
そして、個人の覚悟に頼らず、design by buzzword を構造的に防ぐにはどうすればいいのか。
アーキテクチャレビューの作法かもしれない。評価制度かもしれない。移行責任の持たせ方かもしれない。あるいは、流行よりも制約を問う文化そのものかもしれません。
まだ、考えています。
