guide
AI・思考の技法による純粋要求定義法 入門
知働化要求定義 ガイドブック
このページの位置づけ ── 本調査とは独立しています
このページで扱う〈純粋要求定義法〉は、本サイトの調査とは独立した、それ自体で完結した一つの方法論です。 『思考の技法 2.0』から純粋に演繹して抽出された手法であり、 「概念」「仮説」の各ページで整理している仮説（H1〜H5）を前提とするものでも、 その検証を目的とするものでもありません。
つまり、ここに書かれていることの正しさは、調査の仮説が正しいかどうかとは無関係に成り立ちます。 逆に、この方法論を採用しなければ調査が成り立たない、ということもありません。 あくまでも参考資料として、独立に読める形で置いてあります。
本格版のダウンロード
このページは入門版です。理論的な根拠、既存の要求工学のどこがどう成り立たなくなるのかという論証、 および各原理の導出過程は、本編にあたる次の資料に収められています。
このガイドは、本編が六十数ページかけて論証している事柄を、 はじめて要求定義を学ぶ方に向けて、要点と手順だけに絞って示したものです。 扱うのは道具と手順です。なぜそれが正しいのかについては、本編をお読みください。
三通りの読み方
第1章から順に読めば「なぜやり方を変えるのか」から入れます。 すぐ手を動かしたい方は、第4章（五つの局面）と第5章（技法）から読み始めてください。 第7章の演習だけを先にやってみるのも、有効な入り方です。
このページの内容
1. なぜ、要求定義のやり方を変えるのか
1.1 「作るのは高い」という前提が消えた
要求定義のやり方は、長いあいだ、ひとつの経済的な事実に支えられてきました。 〈作ることは高い〉という事実です。だから上流で誤らないように、要求は精密に文書化され、 レビューされ、承認され、凍結されてきました。 「上流の誤りは下流で百倍のコストになる」という経験則が、その手続きすべての根拠でした。
ところが生成AIによって、実装のコストはゼロに近づいています。 作り直すことが安いのであれば、凍結する経済的な理由はありません。 むしろ、承認手続きの重さのほうが、それが防いでいた手戻りより高くつくということになります。
1.2 崩れた八つの前提
本編の第1章は、既存の要求工学が置いてきた前提を八つ取り出し、そのすべてを棄却しています。 ここでは結論だけを掲げます。
| これまでの前提 | これから | |
|---|---|---|
| A | 要求は存在し、収集できる | 要求は実行によって生成される。聞き出す対象ではない |
| B | 完全な仕様書が作れる | 完全性は証明できない。必要なのは誤りを早く見つける仕組み |
| C | 上流の誤りは下流で高くつく | 実装の誤りは安くなった。目的の誤りは相対的に高くなった |
| D | 合意が正しさを担保する | 合意の外に社会性の検分がある |
| E | 要求は What を書き How は書かない | Who も書かない。人か機械かは最後まで決めない |
| F | 非機能要求は機能要求のおまけ | 構造こそが主である |
| G | アクターは人間である | 人・組織・機械・AIを同じ形式で書く |
| H | 統合された唯一の仕様がある | そんなものは存在しない。どこから見るかを選ぶ |
八つに共通しているのは、いずれも「作るのが高い」という一点から派生しているということです。 本編はこれを〈人働説〉── ITシステムの価値を、作るのに費やした人の労働量で測る思想 ── の残滓と呼んでいます。 これに対して〈知働説〉は、システムの価値を、それが組み込んでいる〈知〉で測ります。
1.3 それでも要求定義は消えない
誤解しないでいただきたいこと
要求定義が不要になるという話ではありません。むしろ逆です。 実装が自動化されていくと、ソフトウェアづくりのなかで人間が担う領域は、要求定義のあたりに集中していきます。
『思考の技法 2.0』の終章は、こう述べています。 「問題領域の分析・抽象化こそが、AI時代の人間に残される本質的な仕事である」。
つまり、要求定義は縮小するのではなく、人間の仕事のほとんど全部になるということです。
2. まず覚える三つの言葉
このガイドで使う概念は、多くありません。三つだけ、正確に覚えてください。 なお、この三つは「概念」のページでより詳しく扱っています。 あちらを先に読んでいる方は、ここは確認のつもりで読み飛ばしていただいて構いません。
2.1 目的（purpose）
目的とは、系（システム）が何のために存在し、
誰の何を実現しようとしているのかの規定です
似た言葉と混同しないよう、三層で区別しておきます。
| 層 | 問い | 時間の概念 | 例 |
|---|---|---|---|
| 目的 | どちらへ向かうのか | なし | 持続可能なエネルギーへのシフトを世界中で加速させる |
| 目標 | いつまでに、どこまで | あり | 2028年度末までに再エネ比率60%を達成する |
| 要求 | この人工物は何を満たすか | 実装時に確定 | 発電量と需要の予測誤差を5%以内に保つ |
目的には、二つの重要な性質があります。
第一に、〈目的は捨象の基準を与える〉ということです。 抽象化とは不用な情報を捨てることですが、何が「不用」かは、それ自体では決まりません。 何のためかが決まってはじめて決まります。
実務上の含意
要求定義が行き詰まったとき、原因は情報不足ではなく目的の未定であることが多くあります。 「もっとヒアリングしよう」ではなく「そもそも何のためのシステムか」に戻ることで、進むことがあります。
第二に、〈目的は系の外部にある〉ということです。 在庫管理システムの目的は、そのシステムをいくら詳しく調べても出てきません。 目的は、それを使う人、その業務、その業務が置かれた組織や社会の側にあります。
これはそのまま、AIとの分担の根拠になります。 AIに与えられるのは系の内部の情報であり、外部にある目的は誰かが持ち込むしかありません。 無論、これは能力の問題ではなく、情報がどこにあるかという構造の問題ですから、 AIが賢くなっても変わらないということになります。
2.2 抽象化と抽象山
抽象化とは、問題を発見・解決するために不用な情報を捨て去ることです。 逆が具体化で、特定の領域に向けて抽象度を下げ、領域特有の情報を付け加えることをいいます。 山にたとえると、抽象化は登り、具体化は下りにあたります。
| 観点 | 低い山（抽象度が小さい） | 高い山（抽象度が大きい） |
|---|---|---|
| 記述の性質 | 特定の実装に強く結びついている | 領域を越えて成り立つ |
| 下り道の数 | 少ない | 多い |
| 自由度 | 作れるものが限られる | 多様な具体化ができる |
| 登る労力 | 小さい | 大きい。捨てる判断を重ねる必要がある |
要求定義とは、この山を登り、頂上に〈意図〉を置く作業です。頂上が高いほど、実装の選択肢は広くなります。
ここで大事なのが、登りと下りの非対称性です。 ある実装が与えられれば、それがどの仕様を満たすかは一つに定まります（登りは一意）。 逆に、ある仕様を満たす実装は一つに定まりません（下りは多義）。 この一対多の関係が、頂上は一点で裾野は広いという山の形そのものです。
だから、下るときには必ず選択が生じます。どの道を選ぶかを決めるのは、目的です。 ただし、登りすぎもよくありません。 「システムは利用者に価値を提供する」は抽象度が極めて高いものの、そこから何も作ることができません。 どこまで登るかを決めるのも、やはり目的だということになります。
2.3 意味の場（Sinnfeld）
意味の場とは、対象が特定の仕方で現れる領域のことです
そして「存在する」とは、ある意味の場のなかに現れることです
あなたの手は、物理学という場では素粒子の集まり、生物学の場では器官、 挨拶という場では握手をするものです。 どれかが本当でどれかが見かけ、ということではありません。どれも等しく実在しています。
もっとも間違えやすい点
これを〈視点〉だと思ってしまうことです。 意味の場は、人が対象をどう見るかという主観の側の事柄ではありません。 対象の側にある実在の領域であり、人がいなくてもそこにあります。
視点なら「増やす」ものですが、意味の場は「気づく」ものです。創意工夫ではなく、探索の問題ということになります。
ソフトウェア工学でいう〈ドメイン〉とも違います。 ドメインは範囲で区切られ、意味の場は現れ方で区切られます。 ドメインは分析者が引くものですが、意味の場は選び取るものです。
ここから重い帰結が出てきます。すべての場を包む唯一の場 ──「世界」── は存在しません。 したがって、すべての関与者の見方を統合した唯一の要求仕様も存在しないということになります。 つまり、要求定義に「完全な仕様」という終点はないのです（前章の前提 H）。
理解チェック 「意味の場」の説明として、正しいのはどれでしょうか。
3. 八つの原理（早見表）
本編の第3章が立てる八つの原理を、一枚にまとめておきます。根拠は本編に譲ります。 迷ったときは、ここに戻ってきてください。
| # | 原理 | ひとことで |
|---|---|---|
| 一 | 目的は要求ではない | 目的が立たないうちに要求を書き始めない |
| 二 | 要求は生成される | 実行してみて初めて要求が生まれる。だから要求定義には実行が要る |
| 三 | 意味は共有できない | 交換できるのは表現だけ。解釈の差は必ず残る |
| 四 | 実行主体は遅延束縛する | 人か機械かを最後まで決めない |
| 五 | 記述は可謬である | 誤りのなさではなく、誤りの検出速度で測る |
| 六 | 抽象度が価値を決める | 嘘にならない範囲で、いちばん高い記述がよい |
| 七 | 計算可能／不可能の境界を引く | 意味・目的・倫理は人間、探索・最適化はAI |
| 八 | 要求は意味の場ごとに現れる | 統合を目指さず、どの場から見るかを選ぶ |
4. 五つの局面 ── 全体の手順
4.1 全体像
知働化要求定義は、五つの局面からなります。 工程ではなく局面です。 順序と担当が決まっているのではなく、「いま自分はどの問いに答えているのか」を示す区別だと考えてください。 同じ日に複数の局面にいても構いません。
| 記号 | 局面 | 中心となる問い |
|---|---|---|
| I | 定立（Setting） | 我々はどちらへ向かうのか |
| II | 切出（Framing） | 何を対象とし、どの場から記述するか |
| III | 定式化（Formulation） | この人工物が満たすべき性質は何か |
| IV | 喚起（Evocation） | 実行によって、我々の認識はどう変わったか |
| V | 計算（Calculation） | この構造は破綻しないか |
この五つは、二つのループと一つの門で結ばれています。
二つのループと一つの門
- 〈意味ループ〉 III → IV → III。書いて、動かして、認識が変わり、書き直す。この回転の速さが要求定義の生産性そのものです。
- 〈構造ループ〉 II → III → V → II。書いて、構造を計算し、切り方を見直す。
- 〈目的の門〉 I → II。目的が定まらないうちは、この門を通ってはなりません。
4.2 各局面ですること
| 局面 | すること | 出口条件 |
|---|---|---|
| I 定立 | 目的を立てる（5.1・5.2節） | 関与者の各人が、目的を自分の言葉で言い直せる。文書レビューでは確認できないので、実際に言い直させる |
| II 切出 | 問題領域を六フレーム（制御・模擬・算法・編集・変換・メタ）に割り付ける。並行して主要な対象を複数の意味の場から記述させる（5.3節）。外に置いた前提は思考停止台帳へ | 主要な対象について、三つ以上の場から記述が得られている |
| III 定式化 | 意図を書く（5.4節の超マシン記述） | 実行主体を名指ししていない。実装候補が三つ以上挙がる（5.5節） |
| IV 喚起 | 動くものを作って触ってもらい、何が変わったかを記録する。本番実装でなくてよい。捨てる前提の〈実行可能仮説〉で十分 | 双方について認識の変化が記録されている。変化がなかった場合も、その事実を記録する |
| V 計算 | プロセス・成果物・構造の三点を、開発を担う側とは別の第三者が計測する | 次の投資判断点までに解消すべき事項が明示されている |
4.3 「完了」はない
知働化要求定義に完了はありません。実行が続くかぎり、要求は生成され続けるからです。 あるのは〈投資判断点〉──「現時点の意図に基づいて、次の規模の投資を行ってよいか」という判断 ── です。
つまり、要求定義の終わりを問うのではなく、次の判断点はいつか、 そこで何が計測されていればよいかを問うということになります。
理解チェック 五つの局面が「工程」ではなく「局面」と呼ばれているのは、なぜでしょうか。
5. すぐ使える五つの技法
5.1 未来からの質問（局面 I）
現在の延長ではなく、明るい未来から逆算して目的を掘り起こす技法です。
- 時点を決めます。三年後が扱いやすいところです。全員で同じ時点を共有します。
- 各人に、その時点で「一番うれしいこと」を述べてもらいます。システムの語彙（画面、データ、機能）が出たら、その手前に戻します。
- 次に「そうなったのは、あなたがどんなことをしたからか」を述べてもらいます。ここで初めて手段が語られます。
- 全員分を並べ、重なる部分と重ならない部分を可視化します。
やってはいけないこと
進行役が「つまり業務効率化ということですね」と要約することです。 要約は誘導であり、同時に相手の言葉を奪う操作でもあります。
5.2 目的表現の三要件テスト（局面 I）
| 要件 | 判定の問い | 不合格の例 |
|---|---|---|
| 唯一無二 | 他の組織名に置き換えても成り立たないか | 「顧客満足度を高める」 |
| 社会性 | それが達成された社会は、誰にとっても恥ずかしくないか | 「競合のシェアを奪う」 |
| 共有 | 関与者が自分の言葉で言い直せるか | 文書にはあるが誰も引用しない表現 |
第一要件の簡単な検査法は、目的表現から自組織の名前を消し、他社の名前を入れてみることです。 それでも成り立つのであれば、唯一無二ではないということになります。
5.3 意味の場による多重記述（局面 II）
同じ対象を、複数の意味の場から記述させる技法です。
- 対象を一語で定めます。「棚卸し」「与信」「配車」など、業務のなかで名前をもつ営みを選びます。「品質」「効率」のような抽象語は対象になりません。
- 現れうる場を列挙します。業務・会計・法務・労務・現場・顧客・社会・技術を初期リストとします。
- 各場について「この場において、この対象は何として現れるか」を一文で書かせます。
- 一つの場からしか出てこない記述に印をつけます。そこに要求の芽があります。
| 場 | 「棚卸し」はそこで何として現れるか | そこから出る要求の例 |
|---|---|---|
| 業務 | 月末の作業手順 | 手順の標準化、進捗の可視化 |
| 会計 | 資産評価の根拠 | 評価時点の一意性、差異の説明可能性 |
| 法務 | 内部統制上の証跡 | 改竄不能性、保存期間、監査対応 |
| 労務 | 残業を生む要因 | 所要時間の短縮、作業の平準化 |
| 現場 | 冷えた倉庫での肉体労働 | 作業姿勢、滞在時間、端末の操作性 |
「棚卸しの所要時間を短縮せよ」は、労務の場からしか出てきません。 業務の場をいくら詳しく分析しても現れないということになります。
注意点は二つ
- 場と部署を混同しないこと。「あなたの部署の立場で」ではなく「会計という場から見ると」と問います。
- 「視点」という語を使わないこと。視点と言った瞬間、記述は主観の申告になってしまいます。
5.4 超マシン記述（局面 III）
人・組織・機械・AIを同じ形式で書くための様式です。五つの欄で書きます。
| 欄 | 悪い例 | 良い例 |
|---|---|---|
| 名称 | 与信審査担当者 | 与信可否判定 |
| 入力 | 申込画面から入力された申込書PDF | 申込主体の識別情報、および過去の取引履歴 |
| 意図 | 信用情報機関に照会し、スコアが600未満なら却下 | 貸倒れ期待損失が与信枠の2%を超えない範囲でのみ可とする |
| 出力 | 審査結果画面への表示 | 申込主体ごとの与信可否と与信枠 |
| 意味 | （記載なし） | 反社会的勢力該当性の最終判断、例外承認の妥当性判断 |
良い例の「意図」欄は、実装を一つに縛っていません。 スコアリングでも、機械学習でも、人間の審査でも満たしうる書き方になっています。 その一方で悪い例は、読んだ瞬間に実装が一つに決まってしまっています。
第五欄の〈意味〉について
この第五欄が、様式の特徴です。明示できない判断が残るのであれば、空欄にせず書いてください。 記載がある超マシンは計算不可能な領域を含みますので、人間の関与が必要な候補として扱われることになります。
5.5 実装候補を三つ挙げる（局面 III）
抽象度を測る、いちばん簡単な方法です。 書いた意図について、それを満たす実装を、性質の異なるものを三つ挙げてみてください。
一つしか挙がらないのであれば、その記述は実装を先に決めてから逆算して書かれています。 抽象度を上げる操作は、三段階です。
- 実装語彙（画面、帳票、テーブル、API、職名、製品名）を消します。消すと意味が通らなくなる箇所が、抽象化されていない箇所です。
- 「なぜそれが必要か」を三回問います。三回目の答えが目的に届いていればよいということになります。
- もう一度、実装候補を挙げ直します。
ただし
候補を増やすために記述を曖昧にしてはいけません。 曖昧な記述は、実装の自由度が高いのではなく、何も指定していないだけです。
6. AIとの付き合い方
6.1 任せてよいこと、任せてはいけないこと
| AIに任せてよい | AIに任せてはいけない |
|---|---|
| 既存文書からの語彙抽出、用語の揺れ検出 | 目的の定立 |
| 意図記述に対する反例の探索 | 社会性の判定 |
| 実装候補の列挙 | 思考停止境界の決定 |
| 意図記述どうしの矛盾検出 | 意味の場の同定と選択 |
| 実行可能仮説の生成と実装 | 実体等価性の最終判定 |
| 構造計算のシナリオ生成 | 認識が変化したかの判定 |
| 過去事例との比較・類例提示 | 投資判断 |
境界の根拠は、二つあります。 目的は系の外部にあり、AIに与えられるのは系の内部の情報だけであること（2.1節）。 そして、下り（具体化）は正しさを確かめられますが、登り（抽象化）は何を捨てるかの判断を含み、 それは目的に依存するということ（2.2節）。 どちらも能力ではなく構造の話ですので、AIが賢くなっても線は動きません。
この仕分けそのものをAIにやらせてはいけません
AIは自分の計算可能領域を過大に見積もります。 境界の設定は、外側にいる者にしかできません。
6.2 「操作」と「コミュニケーション」を見分ける
コミュニケーションとは、表現の交換によって
お互いの〈意味〉を修正・進化させていく活動です
この定義に照らすと、AIとのやりとりには二種類あることになります。
- 指示を出して出力を受け取るだけ。人の側の意味は修正されていない。これは〈操作〉です。
- やりとりを通じて自分の問題の捉え方が変わった。これが〈コミュニケーション〉です。
AIを使ったあとで「自分の考えが変わったか」を確かめてみるとよいでしょう。簡単で、有効な見分け方です。
無論、操作が悪いわけではありません。ただ、要求定義の生産的な活動としては数えられないということです。 同じことは、人間相手のヒアリングにも当てはまります。 聞いて、メモして、双方の認識が何も変わらなかったセッションは、失敗として記録してください。
6.3 AIは価値を黙って持ち込む
覚えておいていただきたい注意
どんなアルゴリズムにも、価値を受け入れる機能が組み込まれています。 AIの危険性は、人間の価値体系を暗黙裡に推奨していながら、 推奨していることを明らかにしないところにあります。
AIに実装候補を挙げさせると、その候補群にはすでに何らかの重みづけが入っています。 そして、挙がらなかった候補は、どの成果物にも現れません。 「見えない」のではなく「存在しないように見える」ということです。
これは利用者が賢明であれば避けられる種類の問題ではありませんので、対処は手順の側に置きます。
- AIの出力を却下した箇所と、その理由を記録します。採用の記録より情報量が多くなります。
- 別の経路（別のAI、あるいは人間だけ）で列挙し直し、差分を取ります。不在は差分としてしか観測できません。
- その要求定義が前提にしている価値判断を書き出し、思考停止台帳に移します。
理解チェック AIに「任せてはいけない」ものに含まれるのは、どれでしょうか。
7. 演習
各演習は一人でもできますが、三人以上で持ち寄って比べると、よく効きます。
演習1 目的と目標を分ける
身近なシステム（大学の履修登録、コンビニのレジ、図書館の貸出）を一つ選び、 目的（時間の概念を含まない一文）と、目標（時間と達成基準をもつもの）を三つ書き出し、 目的表現に三要件テスト（5.2節）を通してください。
つまずき
目的欄に「利用者の利便性を向上させる」と書いてしまうことです。 他のどのシステムでも成り立ちますので、唯一無二ではありません。 そのシステムでなければならない理由まで降りてください。
演習2 意味の場から書き出す
「履修登録」を対象語として、5.3節の手順で多重記述を行ってください。 学生・教員・教務・経理・システム管理・保護者の各場から、 それぞれ一文で「履修登録とは何として現れるか」を書きます。 そのうえで、一つの場からしか出てこない記述に印をつけ、そこから要求を一つ導いてください。
つまずき
場のかわりに「立場」を書いてしまい、 「学生は登録しやすくしてほしいと思っている」のような希望の記述になることです。 問うべきは希望ではなく、その場において履修登録が何として現れるかです。
演習3 超マシン記述に書き直す
次の要求を、5.4節の五欄形式に書き直してください。
「教務課の職員が、履修登録期間終了後に、上限単位数を超えて登録している学生の一覧を画面で確認し、 該当学生にメールで警告を送る」
つまずき
名称欄に「教務課職員」と書いてしまうことです。それは役柄の名であって、機能の名ではありません。 「上限超過の検出と通知」のように、動作でなく機能で書いてください。
演習4 実装候補を三つ挙げる
演習3で書いた意図について、それを満たす実装を、性質の異なるものを三つ挙げてください。 一つしか挙がらない場合は、5.5節の三段階で抽象度を上げてから挙げ直します。
つまずき
「Web画面」「スマホアプリ」「メール」の三つを挙げてしまうことです。 これは同じ方針の表示形式が三通りあるだけで、性質が異なる候補ではありません。 「登録時に弾く」「事後に検出する」「そもそも上限を設けない設計にする」のように、 解き方の違う候補を探してください。
演習5 思考停止台帳を書く
演習3・4の作業で、当然のこととして受け入れた前提を三つ書き出し、次の欄を埋めてください。
| 欄 | 内容 |
|---|---|
| 前提 | 何を正しいものとして受け入れたか |
| 根拠 | なぜ受け入れてよいと判断したか（権威・規格・実績・計測） |
| 反証条件 | この前提が誤りだと判明するのは、何が観測されたときか |
| 波及範囲 | 誤りだった場合、どの記述が影響を受けるか |
| 再検討時期 | いつ見直すか |
つまずき
根拠欄に「一般的にそうだから」と書いてしまうことです。それは根拠ではありません。 誰の、どの検討を、なぜ信用してよいのかまで書いてください。
8. チェックリスト
提出前、レビュー前に一通り確認してください。
| 局面 | 確認する事項 |
|---|---|
| I 定立 | 目的表現は一文で、時間の概念を含まないか／ 他組織の名前に置き換えても成り立つ表現になっていないか／ それが達成された社会は誰にとっても恥ずかしくないか／ 関与者を無作為に指名して原稿なしで説明できるか／ 目的が系の外部から立てられているか |
| II 切出 | 六フレームすべてについて該当の有無を検討したか／ 主要な対象語について三つ以上の意味の場から記述が得られているか／ 一つの場からしか出てこなかった記述に印がついているか／ 「意味の場」を「視点」「立場」「部署」と読み替えていないか／ 対象外とした前提が思考停止台帳に列挙されているか |
| III 定式化 | 意図記述に組織名・職名・製品名・画面名・帳票名が含まれていないか／ 性質の異なる実装候補が三つ以上挙げられるか／ 「なぜ」を三回問うと目的に届くか／ 〈意味〉欄が安易に「なし」になっていないか |
| IV 喚起 | 動かせるものを用意したか（説明資料だけになっていないか）／ 捨てることを宣言したか／ 関与者側・分析者側の双方について認識の変化を記録したか／ 変化「なし」を事実として記録したか |
| V 計算 | 計測する人はこの要求定義の成否によって利害を受けない立場か／ AIの出力を人間が却下した箇所が記録されているか／ 破綻シナリオは負荷・災害・悪意の三系統を含んでいるか／ 次の投資判断点と、そこまでに解消すべき事項が明示されているか |
付録 用語ミニ辞典
- 目的（purpose）
- 系が何のために存在するのかの規定。時間の概念を含まず、方向を示す。
- 目標（target）
- 時間と達成基準をもつ到達点。達成されれば消える。
- 意図（intention）
- 抽象山の頂上に置かれる記述。要求定義の成果物であり、仕様にあたる。
- 抽象化
- 問題を発見・解決するために不用な情報を捨て去ること。
- 抽象山
- 抽象化と具体化を、登りと下りにたとえたモデル。高い山ほど下り道が多い。
- 意味の場
- 対象が特定の仕方で現れる領域。視点ではなく、対象の側にある実在の領域。
- ドメイン
- 範囲によって区切られた領域。意味の場（現れ方で区切る）とは別の概念。
- 超マシン
- 人・組織・機械・AIを、実行可能な人工物として抽象化したもの。
- 実行可能仮説
- 意図の誤りを示すために作る、捨てる前提の動くもの。
- 思考停止台帳
- 受け入れた前提と、その反証条件・波及範囲を記録する台帳。
- 構造計算
- プロセス・成果物・構造の三点を、第三者が計測すること。
- 人働説／知働説
- 価値を労働量で測る思想／価値を組み込まれた〈知〉で測る思想。
もっと知りたい方へ
- 大槻繁『思考の技法 2.0 改訂新版 ── 知を構造化し、未来を設計する』Ichi Corporation, 2026
- 大槻繁『思考の技法 2.0 押さえておくとよい事項』2026年8月7日