認知を変えるプレゼン設計
PHPerKaigi 2026で「存在論的プログラミング：時間と存在を記述する」という40分のレギュラートークをしました。存在論的プログラミングという、聞いたことのないパラダイムを33枚のスライドで伝えるために、スライドの設計そのものにかなりの時間を費やしました。この記事では、その設計プロセスで得た知見を共有します。会場でいただいたフィードバックをもとに、プレゼン後に深掘りした考えも加えています。
そもそも難しいことをしようとしている
このプレゼンは相当に難しいことをしようとしていることはわかってました。
40分で新しいプログラミングパラダイムを伝える。パラダイムを実装したフレームワークの使い方の説明を伝えるのではなく、説明を通じて「新しい認知」を届けないといけない。
ものの見方そのものを変えようという話です。これが相手が数人で、顔を見ながら理解を確認して質疑を交えながら進めるのならいいのですが、40分一方的に壇上から伝えないといけない。
伝わらない部分があるのは受け入れることにしました。内容を歪めて「全員が分かる」事を目指すのも良くないと思っていました。分からないところがいくつもあっても、いくつかのフレーズや考え方が心に残ればそれでいいのではないかという割り切りをしました。
そんなにスムーズにいくものじゃない。手続き型だけの時代にオブジェクト指向を聞いた人たちも、最初は「なんだこれ」と思ったはずです。私自身もそうでした。
視点を丸ごと変える
このプレゼンが求めているのは、視点の転換そのものです。
冒頭で天動説を出しました。空を見上げれば太陽が動いてます。観察したままに考えれば、天体が動いているのは当たり前です。それが覆った——地球の方が回っていた。しかし直感には反します。
トリアージでそれを試みました。普通に見れば、医者が患者を処理しています。プログラムはデータベースからデータを取ってきて、変換して、保存してます。それが自然な観察です。
しかしここでの提案は、そうではなくて、患者自身が変容しているという見方です。患者が体温と心拍という内在（自分の性質）を持って到着し、トリアージプロトコルという超越（判定方法）と出会い、自らEmergencyCase（救急）やObservationCase（経過観察）になっていく。同じように、エンティティがデータベースの力と出会って、外部データを自分に取り込んで変容する。なりたい自分、なるべき自分になっていく。在ることは成ること。
これは視点を丸ごと変えることです。自然に見るとそうは見えない。特定の視点を持ち込んで物事を違った視点で見る。世界地図を逆さにして南を上にしてみてください。同じ地球なのに、まったく違う世界に見えます。データは同じ、視点が違うだけです。
答えではなく、問い
ここが大事なことですが、焦点を当てるべきは答え、ソリューションではありません。問いそのものです。聴衆がトークを聴いて、これを「採用」したら何が美味しいの？という態度になったとしたらそれはプレゼン失敗です。このパラダイムは積み重なるべきものです。今までのものを投げ捨てる必要はないし「採用」かどうかの話じゃない。
利点の列挙にしてしまうとわかりやすいかもしれませんが、しかし40分後に聴衆の認知は変わらないと思いました。Visionを語ってるのに、実装の良し悪しをジャッジするような態度にもなってほしくなかった。
発見型への転換
聴衆に何かをpushするのではなく、聴衆からpullするためにはどのように構成すればいいのかと考えました。
スライドで要点をリストアップすると押しつけになります。語りなら受け取り方に余白が残ります。スライドを読ますのではなく、スライドを見て耳で語りを聞けば聴衆のまとめる力を引き出すのではないかと考えました。
原則：スライドには書かない。語りで伝える。
この原則を全体に貫くことにしました。
$userって何？
新しいものの見方に向かわせるために、従来の見方に「亀裂」を入れる必要がありました。このスライドです。
$user = new User('Alice');
$user->delete();
// ここの$userって何を表してるの？
echo $user->getName(); // 幽霊に名前聞いてる？
聴衆に問います。deleteの後、$userは何を表していますか？ getNameは何を返すべきですか？ Aliceですか？ nullですか？——どちらも納得いかない。答えがない。
さっきまでおかしいと思わなかったのに急におかしく見える。それが認知が変わったということです。スライドが答えを言ったのではありません。聴衆が自分で気づいた。これが発見型の核心です。聴衆がpullしたということです。
波の設計
33枚のスライドを波として設計しました。
冒頭4枚は穏やかに。パラダイムの定義、プログラミング史、世界認知の拡張——聴衆の認知を準備します。テンポよく進めます。
第1層「亀裂」（2枚）で認知を揺さぶります。Alice/delete/getNameで「あれ？」と思わせ、AmazonのUserクラスの23メソッドで「OOPは手続きの束だった」と追い打ちをかけます。問題はクラスがGodなことでなく、手続きの束だったことですが、説明はGodクラスで留めます。「手続きの束じゃん！」をpullして欲しいのです。
第2層「WHETHER?」（2枚）で新しい問いを立てます。HOW→WHAT→WHETHER。ここは簡潔に。
第3層「見え始めるもの」（12枚）が最も密度が高いところです。意味変数、$being、$been、内在と超越——概念を積み上げます。ただし各スライドはコードと1行だけなので詰まりません。
ピークはスライド25「複雑な世界も同じ構造」。EC注文フローの分岐図です。7段階の変容と分岐が1枚に収まっています。どこを切り取っても同じ構造——内在が超越と出会って新しい内在になる。とても単純。
聴衆に考えてもらう。「これ普段のアーキテクチャでどう表現しますか？」それ、こんな風にグチャグチャなコードになってしまいますよね、とか実例を見せない。それぞれの聴衆が、かつて目にしたスパゲッティコードを思い出してくれるのがいいです。
アーキテクチャがドキュメンテーションになりますが、これもドキュメンテーションの自動化を目指して得られたものではありません。
ピークの直後にスライド26。
$becoming = new Becoming($injector);
$final = $becoming(new OrderInput($items, $customer, $payment));
複雑な構成がこの1行で動きます。落差が効くと思いました。制御をするものはいなく、最初の入力が作った谷（Beingクラス群）に流れていきます。
ピーク後は新しいことを言いません。 聴衆はもう理解しています。波が自然に引いていく。対比表、哲学者の収束表、テッド・ネルソンの引用、そして $being の一語で閉じます。
最後の$beingの背景が黒いのはタイトルの黒背景に対するサンドイッチ構造です。「Be, Don’t do」にラストの$beingが答えます。$beingはパラダイムのコアコンセプトと同時に、このプレゼンや自身にも重ねて、全ての存在に適用できるコンセプトなんだと暗に語ります。
アイスブレイクでの「宇宙創生？」の伏線回収を考えていましたが止めました。ネルソン少年の洞察が美しすぎた。最後に「新しい視点で、新しいソフトウエアの宇宙を創造しましょう」…とかないですね。
「答えではなく、問い」のプレゼンテーションを問いで終えることにしました。どういう存在になりたいか、ある意味究極の問いです。BE = Being is Everything. 存在が全てであるなら、その問いは自分自身にも、ソフトウエアでも全てに適用されるはずです。
"The world is a system of ever-changing relationships and structures." — テッド・ネルソン
哲学者は「証人」
プレゼンには8人の哲学者が登場します。スピノザ、アリストテレス、ヘラクレイトス、荘子、老子、フッサール、ハイデガー、そして仏教の論師たち。
これは権威づけではありません。パターンが先に生まれ、哲学的な類似性は後から見えてきました。プログラマが発見した構造を、別の時代・別の言語で同じ場所に辿り着いた人々として紹介しています。
各スライドに散りばめたエピグラフが、終盤の収束表で一覧になります。「別々に出てきた人たちが全部同じことを言っていた」——この収束自体が発見型の構造です。
自分が好きなのは言霊です。言葉そのものが力を持ち、存在をより深く規定するならば(Q&Aにも出てきたように)そこの労力が必要になってもそれは、その労力に見合うのではないでしょうか。
スライドと語りの分業
最終的に確立した分業のルールです。
- スライドに載せるもの: コード、問い、引用、図を最小限に。
- 口頭で語るもの: 個人的な経験、比喩、問いかけ、概念の橋渡し。
例えば「万物流転」のスライドには「卵→幼虫→さなぎ→蝶」とヘラクレイトスの引用だけがあります。「川が流れている」と「流れているのが川だ」の対比——Doing vs Beingの本質——は口頭で語ります。テキストで読ませると説明になりますが、語りなら体験になります。
荘子の魚の話も同じです。スライドには「あなたは私ではない。どうして私が魚の気持ちを知らないと分かるのか？」の一文だけ。エピソードの全体——橋の上で「魚は楽しそうだ」「お前は魚じゃないのに」「お前こそ私じゃない」——は口頭で語ります。聴衆の目にこの一文がある状態で、声でエピソードを重ねます。
説明されると受け身になります。自分で発見すると、好奇心が動き出します。
Empty your cup
プレゼンの冒頭で「一旦頭を空っぽにして、可能性だけに目を向けて聞いてください」と前置きしました。ブルース・リーの言葉に “Empty your cup so that it may be filled” というものがあります。コップを空にしなければ新しいものは入らない。Unlearningです。
ただし、Unlearningは今まで学んだことを捨てろという意味ではありません。既存の知識や経験はそのまま残ります。問題が解けたときに、その解き方が自分のアイデンティティになってしまうこと——思考が凝り固まって、他の視点が見えなくなることが問題なんです。
これは批判を封じるためのものでもありません。新しいアイデアはとても脆弱なものです。まだ批評に耐えるベースにすら載っていないという自覚もあります。しかし、できないことに注目すると議論が止まる。「今までこれでできていたのに？」——その問いは正当ですが、そこに留まると前に進めません。カーネマンの損失回避バイアスです。新しい可能性と既存の手法を手放す痛みは非対称で、痛みの方が大きく見えてしまう。
「なんとかのパラダイムに近いよね」と既存の概念でラベリングしてしまうことも起きます。自分の知っている枠に収めると安心するんですが、そうすると既存の延長でしか考えられなくなります。知っていることが理解をブロックする。新しい可能性に対しての窓が閉じてしまう。
新しいものはいつも居心地が悪いものです。疫学がない時代のワクチン、地球は丸いという主張、CLIからGUIへの移行——全部、既存の枠の中にいると奇妙に見えます。慣れた手札をたくさん持っている人ほど、思考の枠から出ることが難しかったりすると思います。
新しい考えを聞くときは自分のカップを空にしてアイデアが入ってくるスペースを空けること、大事です。以前、それだけのテーマでトーク 新世界の理解をしました。ブルース・リーも「水に成れ」と言ってます。
"Empty your mind ... Be water, my friend" — ブルース・リー (1971)
Q&Aで感じたこと
Q&Aの時間でもそれを感じました。概念の話をしているのに、どうしてもエッジケースや具体的な実装の話に引き寄せられます。パラダイムの話をしているのに、ユースケースの話になってしまう。もっともな問いばかりなんですが、人はどうしても、具体的な実装としてしか新しい概念を考えにくいのだと思います。
しかし、その自然に目にする視点を超え、構造や抽象を見通す視点が持てるかということがビジョン創生には必要です。
この抽象度のプレゼンテーションをすることに勇気がいりましたが、Q&Aで手を上げてくれた人も勇気が必要だったんじゃないかと思います。プレゼンは10分も早く終わってしまったんですが、これがよかったです。Q&Aが3倍の15分になり、本来あるべき対話が十分できました。Q&Aで手を挙げてくれた大勢の皆さん、ありがとうございました。
わかるところだけで前に進む
懇親会で「全部がわかったわけじゃないですけど」とおっしゃる方が何人かいました。でも、それでいいんだと思います。全部わかる必要はありません。
外国語を聞いているときと同じです。聞き取れなかった単語にずっと拘ってワカラナイ、ワカラナイとしてしまうと先に進めません。聞き取れた単語だけで自分の認知を組み立てる——その能力を使わないと、外国語は聞き取れるようにならない。新しいパラダイムも同じで、わかるところだけで自分の考え方を組み立てていけばいい。DoingとBeingでは思考の組み立て方そのものが違うので、最初から全部わかろうとする方が無理があります。それに、40分のトークで全員の認知が隙なく更新されたら、そもそもそれは新しいパラダイムなんでしょうか？恐らく違いますよね。ちなみにOOPの普及には二十余年の月日がかかりました。
設計プロセスについて
この33枚のスライドは、Claude Codeとの対話セッションで完成しました。24本のペーパーを精読した上で初期版を作り、セルフレビューで強み・弱みを特定し、1枚ずつ議論しながらボツ案や方針転換を重ねました。
発見型プレゼンの設計は、説明型より時間がかかります。何を見せるかより何を見せないかの判断が多く、ボツにした案の方が採用した案より遥かに多い。しかし40分後に聴衆の認知が幾許かでも変わっているなら、その時間には価値があるのではないでしょうか。
スライドで説明しなかったこと
40分に収めるために、いくつかの用語は説明を省きました。
第一級市民（First-class citizen） 言語が「正式に扱える概念」のこと。PHPでは5.3で無名関数が導入されて、初めて関数が第一級市民になりました——変数に入れたり、引数に渡せるようになった。Be Frameworkでは「存在の条件」や「時間的な変容」を第一級市民にしています。
アフォーダンス（Affordance） そのとき利用可能な操作のこと。ドアノブは「回す」を、ボタンは「押す」をアフォードする。HTMLのリンクやフォームは操作可能なときだけ画面に現れる。OOPのクラスは全メソッドが常に利用可能で、アフォーダンスがありません。
Union型（ユニオン型） Success|Failure のように複数の型を | で繋げて「このどれかである」と宣言するPHP 8.0の機能。$being はこれで「なりうるもの全て」を宣言しています。
イミュータブル（Immutable） 一度作ったら変更できないオブジェクト。PHPでは readonly で実現します。Beの各クラスはイミュータブルです。変更ではなく変容——だから不変でいい。
VO（Value Object） 値そのものを表すオブジェクト。Email や Money など。意味変数はVOに似ていますが、VOは個別に使うもの、意味変数は名前に紐づいて世界全体に自動適用されるものです。
中央の制御者がいない 従来のアーキテクチャでは、あの注文フローをOrderServiceのような巨大なクラスが制御を手順で行います。全体を知る神が必要になる。Be Frameworkでは各クラスが自分の前後だけを知っていて、全体を知る者はいません。入力が谷を流れるように次の存在へ変容していく。このような構造をコレオグラフィ（choreography）と呼びます。踊りの振付のことで、指揮者がいるオーケストラに対して、各ダンサーが自分の振付だけで踊り全体が調和します。
OOPが目指したもの オブジェクトの自律。メッセージを受け取って自ら振る舞う——操作されるのではなく。しかし実際には$user->delete()のようにオブジェクトは外から操作される手続きの束になりました。Beではオブジェクトは外部から操作されず、内在と超越の出会いによって自ら変容します。
FPが目指したもの 不変性と変換のパイプライン。データを壊さず、関数の連鎖で変換していく。Beの各クラスはイミュータブルで、Input→Being→Finalという変換の連鎖で構成されています。ただしパイプは外からデータを加工する（Doing）のに対し、Beはオブジェクト自身が変容する（Being）——主語が違います。
DDDが目指したもの ドメインの知識をコードに投影すること。ユビキタス言語、境界づけられたコンテキスト。Beではクラス名と意味変数がそのままドメインの語彙になり、アーキテクチャ図がそのままドメインのドキュメンテーションになります。
MVCが目指したもの Webフレームワークの責務分離ではなく、本来のMVC（Trygve Reenskaug, 1979）が目指したのはユーザーのメンタルモデルとコンピュータの内部モデルの橋渡しです。Modelは世界の表現、Viewはその投影、Controllerはユーザーの意図の翻訳。BeではPatientArrivalInput→TriageAssessment→EmergencyCaseというクラス名の連なりが、そのまま人間のメンタルモデルになっています。橋渡しが要らない——コードが直接メンタルモデルです。
宣言的プログラミング（Declarative Programming） 「どうやるか（HOW）」ではなく「何が欲しいか（WHAT）」を記述するスタイル。SQLやHTMLが代表例です。Be Frameworkの#[Be]や$beingは宣言的ですが、さらにその先——「何であるか」「存在できるか（WHETHER）」を宣言しています。
Tell, Don’t Ask オブジェクトの状態を聞いて（Ask）から判断するのではなく、命じろ（Tell）。OOPの重要原則です。Be, Don’t Doはその先——命じることすらしない。何をするかではなく何であるかを定義する。
契約プログラミング（Design by Contract） メソッドの事前条件・事後条件・不変条件を明示する手法。意味変数と似て見えますが、契約プログラミングは入り口で不正を監視する、型安全な状態遷移は遷移を型で制約する——どちらもDoingの精緻化です。意味変数はそもそも不正な値が存在できない世界を作る。監視も遷移も要りません。次元の違うことをしている。もう一つ大きな違いは、契約はメソッドごとに分散しますが、意味変数は一つのディレクトリにアプリケーションの言葉として集約されます。検証セットというよりデータモデル、そのアプリケーションが使う言葉のコーパス（corpus：ある目的で集められた言語資料の集成）になります。
ハイパーテキスト（Hypertext） テッド・ネルソンが1963年に造った言葉です。テキストが直線的に流れるのではなく、リンクで相互に繋がり合う構造。ネルソンは5歳の時にボートから手を水に入れ、手の動きと水流が互いに影響し合う関係に心を奪われました。その体験から “The world is a system of ever-changing relationships and structures”（世界は絶えず変化する関係と構造のシステムである）という洞察に至り、それがハイパーテキストの着想になった。哲学者ではなくコンピューティングの先駆者が、子供の体験から存在と関係の本質に辿り着いています。ちなみにPHP: Hypertext PreprocessorのHです。
これはパラダイムか？
「洗練された設計パターンの寄せ集めではないのか？」という問いがあると思います。私も初期からその問いを持ち続けてきました。
OOPのコードを見てください。
$user->validate();
$user->save();
この$user に処理を命じているのは誰ですか？
——オブジェクトの自律を目指したはずのOOPが、コントローラーレベルでは神の視点からの操作になっています。「取ってこい、検証しろ、保存しろ」。全部三人称の命令です。Tell, Don’t Askですら、命じている主語は神様視点のシステムです。
Beが変えているのは、この視点の置き場所です。システムの視点からドメインの自我の視点へ。患者は処理されるのではなく、自ら変容する。$emailは検証されるのではなく、存在していること自体が正しさの証明。命じる者がいない。
意味変数も、$beingも、コレオグラフィーも、イミュータブルも——個別の機能ではなく、「ドメインの自我を中心に世界を見る」という一つの視点から全てが導出されます。
パターンは既存の問いに対するより良い答えです。パラダイムは問いそのものを変える。HOWでもWHATでもなくWHETHER——そもそも存在できるか。この問いの転換が、個別の機能の違いではなく、視点の根本的な転換から来ているのだとしたら、それはパラダイムと呼んでいいのではないでしょうか。
スライド: 存在論的プログラミング：時間と存在を記述する