仕様駆動アーキテクチャという考え方 ― 仕様駆動開発を、経営に広げる

in

はじめに

『仕様駆動開発 実践入門』を出してから、二ヶ月がすぎました。たくさんの方に手にとっていただき、時に厳しいご意見もお伺いすることがあります。

もっとも私が厳しいなと思うご意見は、「仕様駆動開発をやっていないのではないか？」というものです。

仕様駆動開発をやっているかどうかは、なんとも主張のしにくいところですが、当社としては、全面的に仕様駆動開発を取り入れ、自らが実験台となり、日々ブラッシュアップを続けています。

私は、従前より、こんなことを主張していました。

「ソフトウェアは、手に触れられないものがすべて該当する。だから、開発方法論は、すべてソフトウェアに適用可能だ」

『仕様駆動開発 実践入門』を執筆した時にも、日経BP社の編集者様に同様のことを主張し、

「書籍もソフトウェアの一種であるから、仕様駆動開発の本を出すなら仕様駆動開発で作るべきだ」

と無茶、ですけれども私からすると正論を主張し、最後、すなわち出版まで付き合ってもらいました。

書籍を作ったプライベートリポジトリは、今もなお、存在していて、日経BP社さまとの架け橋になっています。

仕様駆動開発は、有効に機能したのです。

ここ最近、さらに仕様駆動開発に傾倒しているのですけれども、そんな中、最近、あることに気づきました。

この方法論は、ソフトウェアを書くためだけのものではないのではないか。会社そのものの動かし方にも、同じ構造が効くのではないか、と。

実際、私はいま自社の経営・顧客対応の基盤を、この考え方で動かしています。手応えがあったので、その背後にある設計思想に名前をつけたいと思いました。

仕様駆動アーキテクチャです。

なぜ、開発方法論が経営に効くのか

先ほどの私の持論を、もう一度。「ソフトウェアとは、手に触れられないもの、すべてを指す」。

だとすれば、ソフトウェアのための開発方法論は、手に触れられないものすべてに使えるはずです。書籍がそうでした。そして、会社の運営もまた――判断、経緯、関係、手順、そして成果物――その大半は、手に触れられない情報です。

ならば、仕様駆動開発が会社に効かないはずがない。

仕様駆動開発の核は、こうでした。仕様こそが一次成果物であり、実装はそこから導出される。人が意図を決め、AIと道具が生成する。 書籍では、これを 仕様駆動開発「3つの技術要素」「4つの原則」「7つの工程」 として体系化しました。

この構造を、ソフトウェアではなく組織の運営に当てはめたとき、私の目の前に現れたものを、5つの特徴として整理しました。

5つの特徴

  1. 全部をコードのように git で扱う ― Management-as-Code
    経営の状態・判断・成果物・手順を、版管理・差分・レビュー・来歴のある「コード」と同じ作法で扱う。誰が・なぜ・いつ変えたかが、すべて残ります。
  2. 真実は1か所、表示は導出
    原データは1か所だけに置き、一覧やダッシュボードはそこから生成する。二重に持たないので、ズレません。
  3. 自由に貯めて、検査で締める
    平文で柔軟に貯め、整合性は「検査」で担保する。硬さを、効く場所に置き直します。
  4. 平文ファイルが土台
    Markdown・HTML・JSON。独自形式もロックインもない。人もAIも読めます。
  5. AIが操作・人が判断
    AIが労働を担い、人が判断を握る。AIネイティブだが、AI非依存。

なかでも 1 の Management-as-Code（経営をコードとして扱う） が、この思想の核です。

既存の用語との関係

名前をつけるにあたって、私どもが社内で議論している用語が既出かどうか、調べました。

  • 英語の “Spec-Driven Architecture (SDA)” は、すでに使われ始めています。INNOQ の Philipp Beyerlein 氏が2026年2月に提唱したもので、その意味は「複数のソフトウェアシステムを、版管理されたエージェント可読の契約で整合させる」――ソフトウェアのアーキテクチャ統治の話です。
  • “Management-as-Code” も既出の言葉で、IT運用に開発の作法（プルリクエスト・追跡可能性）を持ち込む文脈で使われています。
  • そして英語圏では、“Spec-Driven Development” 自体が2026年に大きな潮流になっています（GitHub Spec Kit ほか）。

私がここで言う「仕様駆動アーキテクチャ」は、これらと地続きの発想です。ただし、適用先が違います。既存の SDA が「ソフトウェアをどう束ねるか」であるのに対し、私のものは「会社・組織をどう動かすか」――経営への適用（Management-as-Code）です。

世界はソフトウェアの領域でこの方向へ動いている。私はそれを、経営に広げたい。そう考えています。

なぜ、この設計なのか

かつての「システム化」は、曖昧さをゼロにすることでした。硬いスキーマで、書いた瞬間に不正を弾く。強力ですが、関係性・経緯・判断といった人間の機微は、そこに収まらず、外へ追い出されていました。

仕様駆動アーキテクチャは、硬さを捨てません。効く場所に置き直す。構造化すべき背骨は検査で締め、自由であるべき文脈は平文で活かす。

もう一つ大事なのは、AIが消えても回ることです。土台が平文で、手順が文書で、検査がスクリプトなら、AIがいなくなっても、人が――あるいは別のAIが――引き継げます。AIで速く回るが、AIに依存しない。

おわりに

これはまだ、生まれたばかりの考え方です。「これが唯一の正解だ」と言うつもりはありません。

ただ、自社をこの形で動かしてみて、確かな手応えがあります。そして、世界の潮流とも方向は一致している。だから、名前をつけて、議論の土台にしたいと思いました。

仕様駆動開発をやっているのか、と問われたら――やっています。ソフトウェアでも、会社でも。その先に見えてきたものを、これからも正直にお伝えしていきます。

ご意見・ご批判、歓迎します。一緒に考えていただけたら嬉しいです。

参考

  • Spec-Driven Architecture ― INNOQ, Philipp Beyerlein（2026-02-24）
    https://www.innoq.com/en/blog/2026/02/spec-driven-architecture-contracts-fuer-agenten/
  • Spec-Driven Development（”When Architecture Becomes Executable”）― InfoQ（2026-01-12）
    https://www.infoq.com/articles/spec-driven-development/
  • Management as Code ― Dima（Medium, 2020-07-14）
    https://medium.com/dima-korolev/management-as-code-88919b00f6a8
  • 『仕様駆動開発 実践入門 〜 AIで実現する開発方法論』― 日経BP（2026-03）