意図駆動設計(IDD) 終章 — おわりに 〜 意図という、出発点

📖 連載「意図駆動設計（IDD）」全20章の一部です

▼ GitHub でも公開しています
https://github.com/okawa14all/intent-driven-design

最後に、この方法論が、どこから来たのかを話したい。

私のバックグラウンドは、ソフトウェア開発だ。コードを書くことから始まり、二十代で会社の経営に携わるようになってからは、組織をつくることにも、深く関わってきた。開発と、組織開発。その両方を、二十年近く、行き来してきた。

近年、AIエージェントの導入を、現場で推し進めるなかで、ひとつ、はっきりと感じたことがある。AIエージェントの導入は、ソフトウェア開発というより、組織開発だ、ということだ。

考えてみれば、当然だった。エージェントを入れるとき、私たちが本当に向き合っているのは、技術ではない。問いはいつも、こうだった。どんな役割を与えるか。どうコミュニケーションを設計するか。何を組織の標準とし、どんなガードレールを設け、例外をどうエスカレーションするか。個々の能力を、どう伸ばすか。文脈の異なる部署と、どう連携させるか——。

これらは、私が組織開発で、ずっと考えてきたことそのものだった。相手が人間からエージェントへ、あるいは人間とエージェントの混成へと変わっても、問いの形は、驚くほど変わらなかった。本書で書いてきたことは、煎じ詰めれば、この問いたちへの、私なりの答えだ。

オーナーシップという、答え

組織開発を続けるなかで、私が最も重要だと考えるようになったものがある。オーナーシップだ。

私はこれまで、数多くの停滞したプロジェクトに、テコ入れ役として入り、立て直してきた。そして、そのほぼすべてに、共通して欠けていたものがあった。オーナーシップだ。誰も、その成果を、自分のものとして引き受けていない。優秀な人が揃い、立派な計画があっても、オーナーシップが欠けたプロジェクトは、例外なく停滞していた。

オーナーシップとは、何か。私の理解では、それは、成果に向けた「意図」だ。「これを、こうしたい」「ここへ、たどり着きたい」という、引き受けられた意志。それを持つ誰かがいるかどうかが、組織が動くか、停滞するかを分ける。

意図駆動設計——Intent-Driven Design——という名前は、ここから来ている。組織を動かすのは、技術でも、計画でも、リソースでもない。意図だ。だから、組織の設計は、意図から始めなければならない。本書が、第一の原則に「意図主権」を置いたのは、二十年かけてたどり着いた、この確信からだった。

意図は、放っておいては伝わらない

だが、ここに、本書を貫いてきたもう一つの主題が、絡んでくる。

意図が源泉だとして——その意図は、放っておいても、伝わらない。人にも、エージェントにも。

なぜなら、序章で書いた通り、人は、それぞれの信念と経験と文脈のなかに生きていて、その外側を想像することが、構造的に難しいからだ。私はこれを「分かり合えなさ」と呼んだ。意図を持っていても、それが相手に届くとは限らない。むしろ、届かないことのほうが、多い。だからこそ、停滞は起きる。だからこそ、AIエージェントは「なんかズレた」答えを返す。

意図という出発点と、分かり合えなさという障壁。本書の八つの原則も、三つのレンズも、突き詰めれば、この二つに応えるためのものだった。意図を、明示的に源泉から流し(意図主権)、三項のあいだに橋を架け(翻訳層)、ズレを早く捉え(検証)、時間をかけて溝を狭めていく(SDRC)。意図を、分かり合えなさを越えて、届かせる。そのための、体系的な工夫だった。

ファンシーなAIスロップ

この主題は、AI時代に、いっそう切実になっている。

AIエージェントは、手軽に、見栄えのよいアウトプットを作ってくれる。整った文章、それらしい計画、動くコード。だが——そこに、人の意図が介在しなければ、生まれるのは、ファンシーなだけの、空疎な生成物にすぎない。見た目は立派だが、誰の何のためでもない、AIスロップ(AIの吐き出すゴミ)だ。

意図のないところに、AIは、それらしいものをいくらでも量産する。だが、それは、成果ではない。成果とは、誰かの意図が、現実を動かしたことの謂いだ。AIがどれだけ賢くなっても、この一点——意図の源泉が人間にあること——は、変わらない。いや、AIが賢くなるほど、それらしい空疎を量産する力が増すぶん、意図の有無が、いっそう決定的になる。

意図を持つ、リーダーへ

少しだけ、視野を広げたい。

日本は、ソフトウェアが弱いと言われ、エンジニアは不足し、高齢化と労働人口の減少という、重い課題を抱えている。だからこそ、AIを使う動機は、どの国よりも大きいはずだ。うまく使えれば、これは、大きな機会になりうる。

だが、そのためには、技術を導入するだけでは足りない。改善ではなく、改革が要る。そして改革には、意図を持って、それを引き受けるリーダーが要る。停滞したプロジェクトに欠けていた、あのオーナーシップを持つ人が。技術は、誰でも買える。だが、意図は、買えない。意図を持ち、分かり合えなさを越えて、それを組織に届けようとする人——その人がいて初めて、AIは、成果に変わる。

本書の原則と方法論が、そんな人たちに、何かひとつでも、インスピレーションを与えられたなら。困難に直面したとき、いつも私を助けてくれたのが先人たちの知恵だったように、本書が、誰かにとっての、ささやかな知恵になれたなら。これにまさる喜びはない。

学び続ける

最後に、正直なことを言っておきたい。

この方法論は、完成形ではない。変化のあまりに速いこの時代、明日には古びる部分も、きっと出てくるだろう。今日「永続する」と書いたことが、覆る日が来るかもしれない。それでいい。

ただ、「いつか古びる」と漠然と言って済ませるのは、誠実ではない。どの前提が崩れたら、この方法論のどこが揺らぐのか——それを、自分で名指ししておきたい。本書は、二つの前提の上に立っている。

ひとつは、三項が永続するという主張だ。これは、論理の必然ではない。「定型化によって仕事がシステムへ降りる速さよりも、新しい非定型のフロンティアが生まれる速さのほうが、上回り続ける」という、経験的な賭けの上に立っている。いまのところ、フロンティアは縮むどころか、広がり続けている。エージェントが扱えるタスクは長く、複雑になり、その先には、さらに難しい未知が現れ続けている。だが、もしいつか、新しい仕事の生成が頭打ちになり、定型化だけが進む時代が来れば——三項は、人とシステムの二項へと、静かに畳まれていくだろう。私は、そうはならないほうに賭けている。だが、これは賭けだ。

もうひとつは、意図と責任の源泉が、人間にあるという前提だ。これは、エージェントがどれだけ賢くなろうと揺らがない——と、私は考えている。だがそれは、技術の問題ではなく、責任というものが、最終的には人格にしか帰属しえない、という、私たちの社会のかたちに依っている。もし、その根本が変わる日が来るなら——意図主権という、本書の第一の原則は、書き換えを迫られるだろう。

この二つの前提を、隠さずに置いておく。そうすることで、本書は「何があっても正しい」という空手形ではなく、「どこが崩れたら、どう間違うか」を自分で語れる、検証可能なものになる。皮肉なことに、それは本書がエージェントに求めたこと——検証できる形で世に出よ——と、同じ規律だ。方法論もまた、その例外ではない。

先人たちが、口を揃えて「学び続けることの大切さ」を説いてきた。デミングも、トヨタも、その思想の根に、終わりなき学習を置いていた。私も、そうありたい。本書を、石碑ではなく、叩き台として差し出す。異論を歓迎し、反証を歓迎し、そして私自身、学び、更新し続けていく。

溝は、消えない。意図は、放っておいては伝わらない。AIは、ますます賢く、ますます空疎を量産する。

それでも——いや、だからこそ。

意図を源泉に置き、分かり合えなさに橋を架けながら、人とシステムとエージェントが、ともに成果へ向かう。その設計を、これからも、考え続けたい。

あなたと、一緒に。

参考文献

本書は、いくつもの先人の知恵に多くを負っている。各原則が源流とした、中心的な文献を挙げる。邦訳のあるものは、広く流通している邦訳版を記した。

ソシオテクニカル・システム論 — Tri-Optimization の源流

• Eric Trist & Ken Bamforth, "Some Social and Psychological Consequences of the Longwall Method of Coal-Getting," Human Relations, 1951.

トヨタ生産方式 — 自走化原則の源流

• 大野耐一『トヨタ生産方式——脱規模の経営をめざして』ダイヤモンド社、1978年.

品質管理(デミング)・DevOps — Verification by Design と SDRC の源流

• W. Edwards Deming, Out of the Crisis, MIT Press, 1982.

• Gene Kim, Jez Humble, Patrick Debois & John Willis 著、榊原彰 監修『The DevOps ハンドブック』日経BP社、2017年.(原著 The DevOps Handbook, 2016)

チーム・トポロジー・制約条件の理論 — 認知負荷の再配分の源流

• マシュー・スケルトン、マニュエル・パイス 著、原田騎郎ほか 訳『チームトポロジー——価値あるソフトウェアをすばやく届ける適応型組織設計』日本能率協会マネジメントセンター、2021年.(原著 Team Topologies, 2019)

• エリヤフ・ゴールドラット 著、三本木亮 訳『ザ・ゴール——企業の究極の目的とは何か』ダイヤモンド社、2001年.(原著 The Goal, 1984)

ドメイン駆動設計 — 翻訳層と境界設計の源流

• エリック・エヴァンス 著、今関剛 監訳、和智右桂・牧野祐子 訳『エリック・エヴァンスのドメイン駆動設計』翔泳社、2011年.(原著 Domain-Driven Design, 2003)

任務指揮・プリンシパル・エージェント理論 — 意図主権の源流

• 任務指揮(Auftragstaktik):プロイセン・ドイツ軍に由来する指揮思想。特定の単著ではなく、軍事理論の系譜として参照した。

• プリンシパル・エージェント理論:経済学・組織論における契約理論の系譜。

そのほか、本書が依拠した主要な概念

• 認知負荷理論:John Sweller, "Cognitive Load During Problem Solving," Cognitive Science, 1988.

• デザインパターン:Erich Gamma, Richard Helm, Ralph Johnson & John Vlissides, Design Patterns: Elements of Reusable Object-Oriented Software, Addison-Wesley, 1994.(邦訳『オブジェクト指向における再利用のためのデザインパターン』ソフトバンク)

凡例 — 引用と強調について

本書では、引用記法(blockquote)を、重要な命題を強調するために用いている。そこに置かれた文は、次のいずれかである。

• 著者独自の主張・命題 — 本書が提示する原則や定義など。

• 先人の理論の、著者によるパラフレーズ — ソシオテクニカル・システム論、チーム・トポロジー、制約条件の理論、ドメイン駆動設計、任務指揮などの中核的な考えを、著者が要約したもの。原典からの逐語引用ではない。

これらに対し、鉤括弧「」で囲まれた文(デミング「品質を達成するために、検査に依存するのをやめよ」、大野耐一「標準がなければ、改善はない」など)は、原典の言葉に基づく引用である。

要するに——鉤括弧のない強調は著者の言葉、鉤括弧のある強調は原典の言葉、と読んでいただきたい。