DrupalCamp Tokyo 2026で感銘を受けたセッション。
Drupalが単なるWebサイト構築ソフトウェアでないことを実践的に証明した発表。Google Analyticsとの統合や表示されないフィールドの定義、それを活用して編集に携わる人達に検討情報を提供し続けてきた歴史を惜しみなく発表したとんでもなくすごいプレゼンテーションであった。
その中で、マシン名の翻訳の問題が指摘されていたので、後刻「あれは編集者には関係ないのではないか」と聞いたところ、その通りだが、（私のように）機能を提供する側の生産性向上にはとても大事なことだと答えが帰ってきたことにまた感動させられてしまった。
私がDrupalを触り始めたのはD7からなので、その前の事は分からないが、一番最初に惹かれたのはViewsだったのを思い出す。もともとRDBを前提にしたシステム開発の経験が多かったので、コンテンツとその見せ方が分離されていることに感動した。RDBであればプログラムを書かなければWebページを作れないのに対して、ノーコードでかなりな柔軟性が実現されていることに惚れた。ただ、理解が進むに連れ、node（コンテンツタイプ）がRDBのテーブルに対応しているのではなく、fieldがRDB(mysql)のテーブルになっているのに驚いた。コンテンツ・マネジメントの観点で言えば、リビジョン管理は重要だし、別node(あるいはterm)への参照(entity reference)も重要になる。D6以前もそういった問題は十分認識されていたようだが、D7の段階でもかなり対処療法的な対応がなされていた。DrupalはD8で、思い切って後方互換性を犠牲にして大きな変更を行った。その結果、Viewsはcoreに取り込まれ、概念的にもcontent entityとconfiguration entityが明確に認識されるようになり、少なくとも概念的には強力なCMSに進化した。
しかしながら、D7からD8に移行する段階で、多くのユーザーが脱落した。登壇者（インプレス）が脱落しなかったのは、本質的なDrupalのCMS的な潜在力を理解していて、D8への移行コストを負担してもなおメリットを享受できると判断したからだろう。
D8以降、D9、D10、D11とアップデートの容易性は確実に向上している。同時に、後方互換性を捨てられるプロセスも確立した。これは、とてもすごいことだ。私が担当したパネルセッションでWordPressに関する言及で「後方互換性重視ゆえの技術的負債がある」と書かれているのと違う道をDrupal（あるいはDries）は選んだ。ユーザーに本質的な構造理解を強要することになるので「WordPressと比較すると後方互換性を軽視していることで持続性確保のための負荷が大きい」と言える。Drupalを採用するには覚悟が必要ということだ。ユーザーに覚悟を迫るということは、Drupalプロジェクトは覚悟して継続あるいは新規に使って頂けるユーザーを満足させなければいけないということだ。
このセッション発表に参加して、感銘を受けたのと同時に、Drupalプロジェクトは、登壇者のようなすばらしいAmbitious Site Builderの期待に応えられなければいけないという現実に震撼する。