「問題無ければ次へ」に眠る暗黙知
手順書に「問題無ければ次へ」と書いてあったり、ログ収集手順は書いてあるがログをどう見るかまでは書いてなかったりしませんか？
— タマゴケ (@s5ml) 2026年2月11日
その「問題無ければ」や「ログの見方」がナレッジです。問題有無判断方法やログ確認手法まで書いてあれば、たとえ実体が手順書でもそれは形式知化されたナレッジです https://t.co/JsKEerIwA9
Xで見かけたこの投稿をきっかけに、ずっと考えていたことが一本の線につながった。運用手順書に「問題無ければ次へ」と書かれている場面を何度も見てきた。一見すると親切な手順書なのだけど、この一行が隠蔽しているものは途方もなく大きい。「問題無ければ」の判断基準はどこにも書かれていない。ベテランのエンジニアは ps コマンドを打ち、ログの特定の行を目視し、レスポンスタイムの微妙な変化を体感的に察知して「問題無し」と判断する。その判断プロセスこそが暗黙知であり、手順書のどこにも記述されていない。
「じゃあ暗黙知を書き出せばいいじゃないか」という話になるのだけど、書き出せないから暗黙知なのだ。レシピ本に書かれた「塩少々」を読んで料理が上手くなるわけではない。知識には意図・目的・文脈が必要であり、「なぜ ps を打ったのか」「ログのどこを見ているのか」「何と比較して正常と判断したのか」という Why の連鎖がなければ、手順書はただの呪文になる。
野中郁次郎と竹内弘高が定式化した SECIモデルは、この暗黙知の問題に正面から取り組んだフレームワークだ。共同化（Socialization）で経験を共有し、表出化（Externalization）で言語化し、連結化（Combination）で体系化し、内面化（Internalization）で再び身体知に落とし込む。ペアワークで隣に座って「なぜ今 ps 打った？」と問い、ポストモーテムで「ログのどこを見て判断した？」と掘り下げる。この地道なサイクルこそが、「問題無ければ次へ」の行間を埋める唯一の方法だった。
何を載せるか＝何を載せないかを問う方法論。コンテキストエンジニアリングも本質は同じだ。LLMに何を渡し、何を渡さないか。CLAUDE.mdやSKILL.mdは「編集指針」の明文化であり、AIエージェントが参照する暗黙知のリバースドキュメンテーションにほかならない。
リバースドキュメンテーション、つまり先に動き、後から書く。この概念が SECIモデルのサイクルそのものと合流しつつあることが気づかれて始めている。そしてその合流は偶然ではない。
スクラムとSECIモデルは同じ親ブランチから生まれた
スクラムと SECIモデルは「似ている」のではなく同じ親から生まれている。
初めてサザーランド博士に出会ったとき、こう言われました。「私たちは日本人のタケウチ、ノナカから学んだ。日本人なら ちょうどいいスクラム が、きっとできる」そして私たちが野中先生との初対面を実現してから 10 年。 ちょうどいいスクラム で皆さんの組織に変革を。
1986年、野中郁次郎と竹内弘高はハーバードビジネスレビューに「The New New Product Development Game」を発表した。日本企業のイノベーティブな製品開発プロセスを分析し、ラグビーのスクラムに喩えたこの論文が、後にジェフ・サザーランドらによってソフトウェア開発のフレームワークとして再構築される。1995年、同じ野中・竹内のコンビが『知識創造企業』を出版し、SECIモデルを定式化した。アジャイル開発の代名詞であるスクラムと、ナレッジマネジメントの金字塔であるSECIモデルは、野中郁次郎・竹内弘高という同じ親リポジトリからフォークされた二つのブランチなのだ。
AIによる支援が「第四の責任」になる、共同化から始めよ
スクラムマスター、開発者、プロダクトオーナー。スクラムの三つの責任はいずれも人間が担うことを前提に設計されている。だが、AIエージェントがチームメンバーとして機能し始めた今、この三つだけでは回らなくなりつつある。AIが何を担い、人間がAIに対して何を責任として負うか。AIエージェントによる支援とAIエージェントが自律的に働くための仕組みが第四の責任として再定義される必要があるのではないか。
スクラムマスターの仕事の中で、構造的にしんどいのが「促し」だ。ワーキングアグリーメントを守れているか、KPTで出たTryが実行されているか、「できているか」と問い続ける役割。これは知的労働というより監視と促しの反復であり、人間がやるには感情的な摩耗が大きい。しかしAIにとっては、むしろ最も得意な領域だ。ワーキングアグリーメントの明文化とチェック、KPTAのTODO化と進捗トラッキング、定期的なリマインドと振り返りの促し。これらは人間が感情を消耗しながらやるべきことではなく、AIが淡々と、しかし確実に回し続けるべきセレモニーだ。
RTS ゲームで複数のユニットを操作するように、複数のコーディングエージェントを操作して成果物を生み出す。
RTSゲームにおいて、ユニットの種類が増えればゲームのルールそのものがアップデートされる。AIエージェントという新しいユニットの参加は、スクラムというゲームのルール拡張を要求する。ではその拡張を、どこから始めるべきか。仕様書を書いてからAIに渡すアプローチは一見合理的だが、SECIモデルの順序を無視している。スクラムの本質はエンピリシズム、経験と仮説検証の蓄積だ。SECIは共同化（Socialization）から始まる。まず一緒にやることが先なのだ。仕様書から始めるのはウォーターフォールの再発明にすぎない。
やってみて直したWhyを記録せよ
AIエージェントに仕事をさせるとき、僕たちはつい CLAUDE.md や SKILL.md に完璧な指示書を書くことから始めようとする。だが、それは料理を教えるのにレシピ本を渡すところから始めるようなもので、うまくいかない。最初にやるべきはペアプログラミングだ。人間とAIが同じタスクに向き合い、人間が判断する癖をAIに見せる。初期段階ではモブプログラミングに人間の先生役がいるべきで、「ここはこう書く」「この場合はこちらを優先する」という暗黙の判断パターンを、一緒に手を動かしながら教え込んでいく。
この構図は産業用ロボットのティーチングと本質的に同じだ。テスラは Optimus の訓練のために50人以上のオペレーターを雇い、モーションキャプチャスーツとVRヘッドセットを装着させて1日7時間以上の動作データを収集している。人間がスーツを着て動くと、Optimus が同じ動作を実物の部品で再現する。文字通り「一緒にやって見せる」テレオペレーション方式だ。
ボストンダイナミクスの Atlas はさらに踏み込んでいて、オペレーターがVRゴーグルでロボットの視界に没入し、自分の全身動作を Atlas に1対1でマッピングする。人間がロボットの「目」で世界を見ながら、自分の「体」でロボットを動かす。身体の共有を通じた暗黙知の移転そのものだ。いずれも明文化された仕様からスタートするのではなく、身体的な共同化から始まる。まず「一緒にやる」ことが先にあり、そこから蓄積されたデータがニューラルネットワークの訓練データになっていく。AIエージェントへのスキル伝達も本質的には同じなのだ。
そして結果的に CLAUDE.md や SKILL.md が生まれる。「僕がどう判断するか」「何を重視するか」「どんな文体で書くか」。これらは最初から書き下ろされたものではなく、ペアワークの蓄積からリバースドキュメンテーションされたものだ。まず共同化があり、その経験が表出化として形式知に変換される。CLAUDE.md は仕様書ではない。共同化の結晶だ。
UNIX コマンドが実装してきた 4W1H（誰が、いつ、どこで、何を、どのように）の不確実性解消メカニズムを、AI エージェントには Why（なぜ）を加えた形で実装する必要がある。
Why 付きコマンドパターンもまた、共同化の中から抽出された暗黙知を構造化するための器だ。一緒に手を動かす中で「なぜ ps を打ったのか」が問われ、その回答が蓄積されて初めて形式知になる。
ボケがいるからツッコミが喋れるアフォーダンスが生まれる
要件定義を、ソフトウェアを作って欲しいと言ってる人から要件を正しく聞き取ってまとめる作業だと勘違いしてる人、割といる。
— きしだൠ(K1S) (@kis) 2026年3月3日
ソフトウェアを作って欲しいと言ってる人は要件を知らない。というか誰も要件を知らない。特にソフトウェアの素人の場合、何が可能で必要かわかっていないし。
経験上、一回動くものを見せると、ようやく本当のことを話し出す
— 松田信介@今日も元気だ、ご飯が美味い (@xhackjp1) 2026年3月4日
詳細なモックでもダメ、遷移図とか見ない
とりあえずの業務を想定してそんなに外さない仕様を満たす動くプロトタイプを作って触ってもらう
そこから本当の要件定義が始まると思ってます https://t.co/F7G66GBRNy
「誰も要件を知らない」「一回動くものを見せると、ようやく本当のことを話し出す」。この二つのポストは、仕様書から始めることの無意味さを現場の肌感覚で言い当てている。そしてこれは、マキタスポーツが『一億総ツッコミ時代』で指摘した構造とまったく同じだ。
ツッコミは二次的な行為である。ボケという一次的創造がなければ、ツッコミは発話する対象を持たない。「要件を聞き取ってまとめる」というのは、ボケ不在の状態でツッコミだけしようとする行為にほかならない。動くプロトタイプというボケを差し出して初めて、ステークホルダーは「ここはこうじゃない」「本当はこうしたかった」とツッコミを入れられるようになる。要件定義の本質はヒアリングではなくツッコミの誘発なのだ。
これはギブソンのアフォーダンス理論そのものでもある。ドアノブの形状が「回す」という行為を誘発するように、動くプロトタイプが「ここは違う」という言語化を誘発する。冒頭で触れた手順書の「問題無ければ次へ」も同じ構造だ。動いているシステムという「ボケ」があるからこそ、ベテランエンジニアは ps コマンドを打つという「ツッコミ」ができる。アフォーダンスなき要件定義は、ボケなきツッコミと同じで、空振りにしかならない。
一夜城にサンクコストを抱かない
ここで重要なのは、プロトタイプは製品の雛形ではないということだ。ボケるためのロケ地——お笑いで言えばコントの舞台セットであり、秀吉の墨俣一夜城のようなものだ。一夜城は堅牢な城郭ではない。敵の目に「城がある」という事実を突きつけ、戦局の前提を変えるための装置だった。動く仕様書としてのプロトタイプも同じで、ツッコミを誘発するという役割を果たした時点で使命を終える。
だから大事なのは、いかに早くロケ地を建て、いかにサンクコストを感じずに捨てられるかだ。丁寧に作り込んだプロトタイプほど「せっかく作ったのだから」という執着が生まれ、ツッコミを受け入れられなくなる。AIエージェントが一晩でプロトタイプを量産できる時代は、このロケ地の建設コストを限りなくゼロに近づける。捨てることに躊躇しない動く仕様書を高速で回し続けること。
それがボケの質を上げ、結果としてツッコミの精度も上がる。ツッコミを入れられるのは、目の前にレビュー対象という「ボケ」があるからだ。そしてツッコミの蓄積が SKILL.md として形式知化され、AIエージェントに委譲された瞬間にツッコミだけをするお人間さんノードの役割は終わるが、のっかりボケをすることが人間の新しい役割となる。これって、こうなったら面白くない！？
マキタスポーツは一億総ツッコミ社会に対して「ボケろ」と説いた。全員がツッコミしかしない社会では何も生まれない。だが、ツッコミを形式知化してAIに手渡せるなら、話は変わる。人間はツッコミから解放されて、様々なボケに専念しその実現はAIに任せられる。SECIモデルの言葉で言えば、表出化と連結化をAIに委譲し、人間は共同化と内面化に集中する。身体で感じ、手を動かし、まず「やってみる」ことで新しいものを掴む。
AIはSECIサイクルを接続する媒介でありメモリーである
ここにスクラムとSECIモデルの再合流の核心がある。AIエージェントは「場（ba）」そのものではない。場はあくまで人間と人間、あるいは人間とAIが共同で作業する関係性の空間だ。AIエージェントの本質的な役割は、場で生まれた暗黙知を保持し、SECIサイクルの各段階を接続する「媒介」であり「メモリー」なのだ。
野中郁次郎が提唱した「場（ba）」は、共有された文脈・意図・価値観の空間であり、スクラムのイベントはその具体的な実装だ。しかし従来のスクラムでは、場で生まれた知見はスプリントをまたぐと揮発してしまう。議事録やWikiに書き残しても、文脈が失われれば死んだ文字列になる。AIエージェントがメモリーとして機能するとき、この問題の構造が変わる。
| スクラムの実践 | SECIプロセス | AIが媒介・記憶するもの |
|---|---|---|
| ペアプロ / モブプロ | 共同化（Socialization） | 人間の判断パターン・癖の観察と保持 |
| Daily Scrum | 表出化（Externalization） | 暗黙の障害や懸念を言語化する場の記録 |
| Sprint Planning | 連結化（Combination） | 過去スプリントの判断履歴と知識の自動統合 |
| Sprint Review | 内面化（Internalization） | 成果物に埋め込まれた意図と文脈の再提示 |
| Sprint Retrospective | 表出化（Externalization） | 蓄積されたログからの判断パターンの言語化 |
ペアプロやモブプロで人間がAIに癖を教え込む。これがSECIの起点となる共同化だ。Daily Scrumでは「昨日何をしたか、何が障害か」を言語化する。暗黙の問題意識を形式知に変える表出化の場であり、AIはその記録をメモリーとして蓄積する。レトロスペクティブでAIが蓄積したログを分析し、「あのとき何を基準に判断したか」を言語化する支援をする。プランニングでは過去の判断履歴をセマンティックメモリから引き出して統合する。AIは各段階の「あいだ」を接続する媒介として、SECIのスパイラルを途切れさせずに回し続ける。
ユングが提唱した「集団的無意識」という概念がある。個人の経験を超えて、人類全体の深層で共有される普遍的な無意識だ。チーム開発にもこれに近い層がある。誰も明文化していないのにチーム全員がなんとなく共有している判断基準、「うちではこうする」という暗黙の了解、コードレビューで「なんか違う」と感じるときの「なんか」の正体。これがチームの集団的無意識だ。従来はこの層に到達する手段がなかった。個人の暗黙知を表出化するだけでも困難なのに、チーム全体の無意識を言語化するのはほぼ不可能だった。
だが、AIがメモリーとして全員のペアワークの蓄積を保持し、パターンを横断的に観察できるようになると、話が変わる。「Aさんもこう判断した」「Bさんも同じ場面でこのアプローチを選んだ」と、個々の暗黙知の共通項が浮かび上がり、チームの集団的無意識が結果的に明文化されていく。これはドメイン駆動設計（DDD）における「ユビキタス言語」の生成プロセスとほとんど同じだ。DDDではビジネスドメインの概念をチーム全体で共有する統一言語として定義するが、それもまた最初からトップダウンで決まるものではなく、開発者とドメインエキスパートの対話の蓄積から浮かび上がってくるものだった。AIがメモリーとして媒介することで、このユビキタス言語の生成が加速される。
これは「記号接地」を計画的に行うためのプロセスにほかならない。記号接地問題とは、言葉や概念という記号が実世界の経験や意味とどう結びつくかという問題であり、AIにとっての最大の課題の一つでもある。CLAUDE.md に「だ・である調で書く」と記述しても、その記号が具体的な文章のリズムや判断の癖と接地していなければ、AIはただルールに従うだけで文脈を理解しない。ペアプロという共同化を経て、実際の判断場面の蓄積がメモリーに積まれ、そこからリバースドキュメンテーションされた形式知が生まれる。記号接地なき形式知は、文脈なき手順書と同じだ。つまり「問題無ければ次へ」に逆戻りする。
同じ親ブランチの再合流が示すもの
1986年の「The New New Product Development Game」に立ち返ってみると、野中と竹内が描いたビジョンは驚くほど現代的だ。自己組織化するチーム、オーバーラップする開発フェーズ、知識の創発的な生成。スクラムはこのビジョンのプロセス面を、SECIモデルは知識創造面を、それぞれ発展させてきた。
そして今、AIエージェントという触媒を得て、二つのブランチは再合流しつつある。AIによる支援を第四の責任として組み込み、AIのためのスクラムイベントを設計する。その出発点は明文化ではなく共同化であり、ペアプロやモブプロという儀式を通じて暗黙知がAIというメモリーに蓄積され、リバースドキュメンテーションとして形式知に変換される。チームの集団的無意識がユビキタス言語として浮かび上がり、記号が経験に接地していく。これはスクラムの「拡張」であると同時に、1986年に描かれた知識創造のダイナミズムへの「原点回帰」でもある。
野中と竹内が40年前にコミットした origin/main から、スクラムブランチと SECIブランチはそれぞれの方向に開発を続けてきた。そして今、AIエージェントという新しいコミットが両方のブランチの差分を解消し、git merge の条件を整えつつある。ツッコミをAIに委譲し、人間がボケに回帰する。スクラムとSECIモデルがAIエージェントによる暗黙知のリバースドキュメンテーションで再合流するとき、僕たちは「問題無ければ次へ」の行間を読みながら、まだ誰も見たことのないプロトタイプを動かし始めているだろう。
