WordPressがなくなる日〜エンジニアリング原則の適用範囲を引き直す

15年以上、自分のブログをWordPressで運用してきた。エディタの世代交代に合わせて使い方を変え、プラグインを整理し、テーマを差し替えながら、長くつきあってきた道具である。

途中、Mediumやnoteへの移行を検討したこともあったし、ヘッドレスCMSで自前のフロントを作る構想を持ったこともある。けれど、どれも決定打がないまま、結局はWordPressを使い続けてきた。それだけよくできた道具だったということでもある。

それが、AIに任せて自前のサイトへ移すという作業が、思いのほか工数も時間もかからずに終わってしまった。エンジニアでない人がアプリを作れる時代である。これ自体は、いまや驚くような話ではない。

注目すべきは、別のところにある。何がなくなったのか、という問いだ。

そもそもCMSは、何を解決していたのだろうか。書き手が技術者でないことを補い、書き手と作り手の分業を可能にし、テンプレートで工数を減らし、デザインと内容を分離し、DBで記事を管理する。どれも、書き手と作り手が分かれていた時代、人間が手で書くコストが高かった時代の、制約への解だった。

AIは、その前提を崩した。書き手が直接マークアップを生成できる。HTMLを書くコストは、ほぼゼロだ。一覧ページも検索も、必要なら都度生成すればいい。CMSが解決していた課題の多くは、別のかたちで解消されつつある。

DRY原則は、いまも変わらず大切なのだと思う。重複は保守性を下げる。AIが生成したコードであっても、ロジックがDRYでなければ、変更したときに破綻が起きる。これはプログラミングの原則として残り続けるのだろう。

しかし、HTMLはマークアップにすぎない。プログラミング言語ではなく、ロジックを含まない。同じようなマークアップが繰り返されていても、本質的な保守上の問題は起きにくい。AIが都度書き直せるなら、なおさらだろう。

CMSがやっていた「テンプレート化による再利用」は、ロジックの共通化というより、マークアップの共通化だったのではないか。それは人間が手で書くコストへの対応であって、エンジニアリング的な必然というわけではなかったのかもしれない。

そう考えると、CMSは特定の制約下での最適解だったのだろう。WordPressが長きにわたって書き手たちの道具であり続けたのも、その制約に対する優れた解だったからこそだ。前提が変われば、その役割も変わっていくはずだ。

私たちはこれまで、ロジックを持たないものにまで、エンジニアリングの原則を引き伸ばして適用してきた。人間のコストが高すぎたから、適用しないと現実が回らなかったのだ。けれど、その前提が変われば、合理性の中身も変わる。これまでの適用には、誤適用だった部分があったのかもしれない。

ロジックには、これまで通りDRYを守る。けれど、マークアップやコンテンツにまでこだわる必要は、もうないのかもしれない。AIに任せて、都度書き直せばよいことも増えていくはずだ。

AIの時代に、何にエンジニアリング原則を適用し、何には適用しないのか。

その線引きを、引き直す時期に来ているのではないか。