コンテンツにスキップ

第5部 構造と生成 2021-2026

前の4部で獲得したものが、プラットフォームの層に沈殿し、既定値になる時代。そして書き手が人間だけではなくなり、この文書のテーゼ — 規約を構造に — が、思想から生存条件に変わる。

言語 — スキーマ駆動と、MDA の夢の回収

Section titled “言語 — スキーマ駆動と、MDA の夢の回収”

「定義から生成する」が支配的パターンになる。OpenAPI(Swagger から2015年に改名、3.0 は2017)からクライアントとサーバーの雛形を、protobuf/gRPC(2015年公開)から型付きの RPC を、SQL から型付きのデータアクセス(sqlc、2019)を、JSON Schema から検証を。手書きしていた整合性 — API ドキュメントと実装のズレ、SQL と Go の型のズレ — が、生成によってズレようがない形に変換された。

ここで第1部の2つの伏線が回収される。第1に、XML Schema と WSDL が持っていた「契約を機械可読に書き、検証し、生成する」は、第2部で重さと一緒に捨てられた。OpenAPI と protobuf はそれを拾いに戻ったものだ。違いは記法の軽さと、エコシステムがベンダーでなく OSS であること。思想は WSDL と同じである。第2に、MDA の「定義から生成すればズレない」という問い。MDA は UML という人間向けの図を起点にして失敗した。スキーマ駆動は、すでに実行されている定義を起点にする。SQL は DB が実行する。OpenAPI はゲートウェイが検証する。真実であるものから一方向に生成するので、往復の問題がそもそも起きない。情報隠蔽(1972)の最新形は「隠すべきものを人が触れないよう、境界面を機械が生成する」である。

MDA の夢は、起点を図から「実行されている定義」に変えて叶ったMDA(2001): 図が起点。生成物を手で直した瞬間に往復が壊れる図に戻さない → 図が古くなるUML の図(人向け)コード生成コード締切の夜に手で直すスキーマ駆動(2015-): すでに実行されている定義が起点。生成物は人が触らないschema.sqlDB が実行する = 真実sqlc型付きの repositorySQL と型はズレようがないopenapi.yamlゲートウェイが検証 = 真実generatorclient と server の雛形文書と実装はズレようがない

上は往復を人が維持する規約、下は往復がそもそも存在しない構造。生成という道具は同じで、起点の選び方だけが違う。

2021年の Copilot 以降、AI がコードを書き始め、2024-26年にはエージェントが並行してコードベースを変更するようになった。ここで型・テスト・lint の意味が反転する。人間の書く速度が制約だった時代、動的の柔軟性は美徳だった。機械の書く量が前提の時代、静的の制約は検証装置である。

第2部の規約の限界を思い出してほしい。規約は破っても壊れないから破られる。人間は時々破る。AI エージェントは、文書の規約を読んでも確実には守らない。しかしコンパイルエラーと CI の赤には確実に反応する。構造で守られた境界だけが、エージェントの世界で守られ続ける境界だ。レビューで人が守っていた規約は、人がレビューできる量を超えた瞬間に守られなくなる。後に DORA が言う「AI は増幅器」は、ここですでに見えている。

データ — マイグレーションが「設計」になる

Section titled “データ — マイグレーションが「設計」になる”

オンライン DDL はついにエンジンに内蔵された。MySQL 8.0.12 の ALGORITHM=INSTANT(2018) — メタデータだけの数十ミリ秒の変更 — で、カラム追加は第2部の数時間から瞬時になった。外部ツール(gh-ost)の出番は行の再構築を伴う変更(型の変更、主キーの変更)に縮小し、Aurora の fast clone と Blue/Green(2022)が本番相当のデータでのリハーサルを安くした。

ツールが軽くなるほど、残るのは設計である。 デプロイが段階的になったということは、新旧のバイナリが同じ DB を同時に触る時間が必ずあるということだ。この「互換性の窓」をどう設計するか。答えが expand/contract である。カラム名を変えたいなら、新カラムを足し(expand)、両方に書くバイナリを出し、データを埋め、新カラムだけを読むバイナリを出し、最後に旧カラムを消す(contract)。1つの変更が複数のリリースにまたがる。面倒に見えるが、どの瞬間にロールバックしても壊れない。そしてどの変更を窓に置けるか(INSTANT 判定の機械化)、置けないものをどう計画するか。マイグレーションは DBA の職人技から、リリースを跨ぐ手順の設計 — つまりアーキテクチャの一部 — になった。

expand/contract: 1つの変更を、どこで戻しても壊れない手順に分ける例: カラム name を display_name に改名するR1 expand新カラムを足すINSTANT、数十msR2 両方に書く新旧どちらを読んでも同じ値になるbackfill既存行の旧→新を小さく埋めるR3 新だけ読む旧にはもう誰も依存しないR4 contract旧カラムを消すここだけ不可逆互換性の窓: どの時点で 1 つ前に戻しても、新旧のバイナリが同じ DB で動く手順は面倒に見えるが、「深夜のメンテナンス」と「戻せないデプロイ」の両方が消えるR3 が安定してから

緑の帯の中は、どこでロールバックしても壊れない。帯の外にあるのは最後の削除だけで、それは新だけ読むバイナリが安定してから行う。

アーキテクチャ — コモディティ化と、太い境界への回帰

Section titled “アーキテクチャ — コモディティ化と、太い境界への回帰”

デリバリーの装備は買うものになった。ECS は Blue/Green とカナリアをネイティブで持ち、Argo Rollouts は Kubernetes の標準になり、フラグは OpenFeature(2022)でベンダー中立の差し込み口を得た。第4部で名前が付いた実践が、プラットフォームのチェックボックスになった。

同時にアーキテクチャはモジュラーモノリス回帰へ。Shopify の packwerk(2020)が「モノリス内の境界を構造で守る」を実演した。Ruby のモノリスをパッケージに分け、パッケージ間の依存を宣言し、宣言にない依存は CI で落ちる。Prime Video の事例(2023、マイクロサービスをモノリスに戻してコストを 90% 削減)が、マイクロサービスの無条件優位という神話に留めを刺した。

Ford らの『Software Architecture: The Hard Parts』(2021)が結合を静的(コードとデータの依存)と動的(実行時の呼び出し)に分けて理論を精緻化し、実務の収束点はこうなった。モノリスかマイクロサービスかという二択は、3つの軸の混同だった。

軸問い可逆性いつ決めるか
コード境界どのパッケージがどれに依存できるか不可逆に近い(後から引くのは高い)最初から
データ所有どのテーブルを誰が書けるか不可逆に近い(共有したテーブルは分けられない)最初から
デプロイ単位何を別々に出すか可逆(後から割っても、戻してもよい)測ってから

境界はコードとデータに最初から引く(不可逆で、待つほど高い)。デプロイと物理分離は測ってから割る(可逆で、待つほど安い)。 第3部の分散モノリスは、可逆な軸(デプロイ)を先に動かし、不可逆な軸(データ)を放置した結果だったと整理できる。分散させる場所は、アカウントやセルといった太い境界に揃えるのが新しい既定である。境界の数は少なく、境界の壁は厚く。

ここで SOA の系譜を振り返ると、面白いことが分かる。Don Box の4テネットは、モジュラーモノリスの中でもそのまま成り立つ。境界は明示的(パッケージの公開 API だけ)、モジュールは自律的(自分のテーブルしか触らない)、共有するのは契約(生成された client)、互換性は宣言(バージョン付きのイベント)。SOA の思想は、ネットワークを必要としていなかった。 ネットワークは実装の選択であり、思想はコード境界とデータ所有の話だった。20年かけて、それが分かった。

DevOps は「文化を変えよう」から「プラットフォームという製品を作ろう」へ進化した。プラットフォームエンジニアリング、Backstage(Spotify、2020年公開)、ゴールデンパス。文化は説得だが、製品は選ばれる。一番楽な道が一番正しい道であるように舗装すれば、統制は申請書でなくアーキテクチャで表現できる。開発者は何も選ばず、判断はプラットフォームに1回だけ埋め込まれる。CAB は消えたのではない。CAB の審査基準が、apply の順序と CI のゲートになった。 会議は要らない。基準を満たさない変更は、そもそも本番への経路が存在しない。

計測の線には重要な補正が入った。Four Keys の成功は「デリバリーは測れる」を常識にしたが、その勢いで「開発者個人も1つの指標で測れる」へ滑る誘惑を生む。2023年に McKinsey が「開発者の生産性は測れる」という記事を出し、Kent Beck と Gergely Orosz が反論した論争がそれだ。SPACE(2021) はそれへの先回りの反論である。開発者の生産性は、満足度(Satisfaction)・パフォーマンス(Performance)・活動量(Activity)・コミュニケーション(Communication)・効率とフロー(Efficiency)の多次元でしか記述できない。活動量(コミット数、PR 数)を単独で目標にすれば必ずゲーム化して腐る。Goodhart の法則(指標が目標になったとき、それはよい指標ではなくなる)の実装ガイドと言ってもよい。

DevEx フレームワーク(2023)がフィードバックループ・認知負荷・フロー状態の3軸でこれを実務化し、DORA の AI レポート(2024-25)が最後のピースを置いた。AI は増幅器であり、組織の既存の強みと弱みを拡大する。 良い構造と計器を持つ組織は AI で加速し、持たない組織は事故も加速する。2024年のレポートは、AI の採用がデリバリーのスループットと安定性を下げたという結果を正直に報告している。変更が大きくなったからだ。小さく出す構造を持たない組織に AI を入れると、大きい変更がさらに大きくなる。

greenfield の現在形: 本部そのもの。「既定形は1本、開発者は何も選ばない」「規約を構造に」「主張→実験→期待」は、この部の到達点の実装であり、並行エージェント開発(goose 欠番検出の背景)は AI 増幅時代への先回りである。sqlc と OpenAPI からの生成は、MDA が向きを逆にして叶った姿。