後方互換性がアドバンテージになった日：Drupalが長期運用で選ばれる本当の理由

この記事は Dries Buytaert の公式ブログ「dri.es」の翻訳記事です。Driesブログの記事一覧よりすべての翻訳記事をご覧いただけます。

20年前、私は後方互換性を破棄することがDrupalの中核的価値の一つだと熱心に主張していました。

長期的に実行可能な唯一の戦略は、技術を正しく作ることだけに専念することです。競争力を維持する唯一の方法は、最高の製品を持つことです。[...] もし過去の荷物を引きずり始めたら、あなたの製品はいずれ、同じ機能を提供するが荷物のない何かに取って代わられるでしょう。

私は、後方互換性を維持することが終わりの始まりになると警告していました。

これが、私たちが知っているDrupalの終わりになるのではないかと恐れています。おそらくすぐにではなく、おそらく数年もかからないかもしれませんが、最終的にDrupalは変化により迅速に対応できる技術に追い越されるでしょう。

20年経った今、私は間違っていたと認めなければなりません。

では、何が変わったのでしょうか？

2006年当時、Drupalには自動テストがほとんどありませんでした。後方互換性を約束することはできませんでした。なぜなら、いつそれを壊したのかを知る方法がなかったからです。2年後の2008年、私たちはテスト駆動開発を採用しました。

Drupalのテストコードは現在、本番コードの2倍以上になっています。出典：Drupal Core Metrics

2013年までに、私たちはある程度のテストカバレッジを構築し、その基盤の上でセマンティックバージョニングを採用し、後方互換性にコミットしました。それはDrupalでの革新の仕方を変えました。古いコードを削除対象としてマークし、メジャーリリースごと、2年ごとに整理できるようになりました。私が恐れていた荷物は、実際には蓄積されませんでした。

今日、Drupal Core Metricsダッシュボードによると、Drupalコアのテストコードは本番コードの2倍以上あります。これがどれほど大きな変化をもたらすか、私は十分に理解していませんでした。Drupalの規模で後方互換性を約束するには、広範な自動テストなしには不可能なのです。

私たちのアップグレードは今やプロジェクト史上最もスムーズです。そして何よりも、Drupalは終わりませんでした。柔軟性、セキュリティ、スケールを必要とする組織にとって、今なお最有力の選択肢であり続けています。

最近、SQLiteの開発者であるRichard Hipp氏のインタビューを目にしました。SQLiteは15万行の本番コードに対して9000万行のテストコードを持っています。驚異的な600対1の比率です。Hipp氏はこれを「航空機レベルのテスト」と呼び、3人のチームで数十億のインストールを維持できる理由だと述べています。

私たちのテストカバレッジは今後も時間とともに拡大し続けると思います。しかし、DrupalがSQLiteの比率に追いつく必要はありませんし、そうする必要もありません。重要なのは、私たちに合った習慣と規律を築いたことです。

2006年、私は後方互換性がDrupalの終わりになると考えていました。2026年、それが今後20年間私たちをここに留まらせる要素になるかもしれないと思っています。

テストを書いてくれたすべての人に感謝します。

これは私にこう考えさせます。今、私たちは何について間違っているのでしょうか？ 今日投資すべきで、徐々に私たちの働き方を変え、20年後には明らかな優位性となるものは何でしょうか？ そして、私たちの他の人が耳を傾けていない間に、すでにそれを語っているのは誰でしょうか？

By Dries Buytaert

この記事は「When backward compatibility became an advantage」（投稿日：2026-01-12）の翻訳記事です。