目次
Introduction
Two months have passed since I published Spec-Driven Development: A Practical Introduction (『仕様駆動開発 実践入門』, Nikkei BP). Many people have picked it up, and now and then I hear pointed criticism.
The criticism that stings most is this: “Aren’t you actually not doing spec-driven development?”
Whether one “is doing” spec-driven development is a hard thing to claim about oneself. But at our company we have adopted it wholesale, made ourselves the test subject, and we keep refining it every day.
I have argued, for a long time, something like this:
“Software is everything you cannot touch. So a development methodology can be applied to all software.”
While writing the book, I made the same argument to my editor at Nikkei BP:
“A book is a kind of software too. If you’re going to publish a book on spec-driven development, you should make it with spec-driven development.”
It was an unreasonable demand — though to me, sound logic — and they stayed with me all the way to publication. The private repository we built the book in still exists today, and remains a bridge between us and Nikkei BP.
Spec-driven development worked.
Lately I’ve leaned into it even further, and in the middle of that, something occurred to me.
This methodology may not be only for writing software. The same structure might work for running the company itself.
In fact, I am now running my company’s operations and client work on exactly this idea. It has held up well — so I wanted to give the design philosophy behind it a name.
I call it 仕様駆動アーキテクチャ — Spec-Driven Architecture. (A note on that name in a moment, because in English it deserves a caveat.)
Why a development methodology works for management
Let me return to my long-held claim: software is everything you cannot touch.
If that’s true, then a methodology for building software should work for anything intangible. The book was one such thing. And the running of a company — its decisions, its history, its relationships, its procedures, its outputs — is, for the most part, intangible information too.
So there is no reason spec-driven development wouldn’t work for a company.
The core of spec-driven development was this: the specification is the primary artifact, and the implementation is derived from it. Humans decide intent; AI and tooling generate. In the book, I organized this into spec-driven development’s three technical elements, four principles, and seven processes.
When I applied that same structure not to software but to the running of an organization, what appeared in front of me, I organized into five characteristics.
Five characteristics
- Treat everything like code, in git — Management-as-Code
The state of the business, the decisions, the deliverables, the procedures — all handled with the same discipline as code: version-controlled, diffable, reviewable, with full history. Who changed what, when, and why — all of it remains. - One source of truth; views are derived
The source data lives in exactly one place; lists and dashboards are generated from it. Nothing is kept twice, so nothing drifts out of sync. - Store freely, tighten with checks
Keep things in plain text, flexibly; guarantee integrity with checks. Put the rigor back where it actually helps. - Plain-text files as the foundation
Markdown, HTML, JSON. No proprietary formats, no lock-in. Both humans and AI can read it. - AI operates; humans judge
AI does the labor; humans hold the judgment. AI-native, but not AI-dependent.
Of these, the first — Management-as-Code (treating management itself as code) — is the heart of the idea.
A note on the name
When naming this, I checked whether the terms we were using internally already existed. In the spirit of honesty, here is what I found.
- The English term “Spec-Driven Architecture (SDA)” is already in use. Philipp Beyerlein of INNOQ introduced it in February 2026, and it means “keeping a portfolio of software systems coherent through versioned, agent-readable contracts.” It is about software architecture governance.
- “Management-as-Code” also already exists — used since 2020 (Dima) for bringing software-development practices (pull requests, traceability) into IT management.
- And in English, “Spec-Driven Development” itself has become a major current in 2026 (GitHub Spec Kit and others).
What I mean by 仕様駆動アーキテクチャ shares the same DNA as these — and the resemblance is striking. INNOQ’s SDA, too, starts as Markdown contracts in a repository with no lock-in, validated in CI. That is almost exactly the mechanism I arrived at.
But the target is different. Where the existing SDA asks “how do we keep software systems coherent,” mine asks “how do we run the company itself” — it is the application to management (Management-as-Code).
So, to be precise for an English-speaking reader: the existing “Spec-Driven Architecture” is for software. What I am describing is the same idea, pointed at the organization. The world is moving this way in software; I want to carry it into management.
Why this design
The old idea of “systematizing” meant driving ambiguity to zero — a rigid schema that rejects anything malformed the moment it’s written. Powerful. But the human texture — relationships, history, judgment — never fit inside that schema, and so it was pushed out, into free-text fields and private spreadsheets.
Spec-Driven Architecture does not throw rigor away. It puts rigor back where it belongs: the structural spine is tightened by checks; the context that must stay free is kept in plain text.
And one more thing matters: it keeps running even if the AI goes away. When the foundation is plain text, the procedures are documents, and the checks are scripts, then a person — or a different AI — can pick it up. Fast with AI, but not dependent on it.
Closing
This is still a newborn idea. I am not claiming it is the one right answer.
But having run my own company this way, the feedback is real. And the direction matches where the wider world is heading. So I wanted to name it, and put it on the table for discussion.
Am I doing spec-driven development? Yes — I am. In software, and in the company. And whatever I find further down this road, I’ll keep telling you honestly.
Comments and criticism are welcome. I’d be glad to think this through together.
References
- 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 - Spec-Driven Development: A Practical Introduction — Nikkei BP (2026-03)
https://amzn.to/4u3TF7G