Drupal CMS ラボ 編集部
この記事は Drupal コミュニティの主要ニュースサイト「The Drop Times」の翻訳記事です。
いまだにDrupal 7を運用している多くの組織にとって、課題はもはやアップグレードするかどうかではなく、長年にわたってコンテンツ、ワークフロー、業務運用を支えてきたシステムを混乱させることなく、どうモダナイズするかという点に移っています。
アップグレードプロジェクトは、プラットフォームの移行とリデザイン、新機能、アーキテクチャの変更を同時に組み合わせることが多く、複雑さが増し、重要な機能が期待どおりに動作するかどうかを検証するのが難しくなっています。
CodeLiftの創業者兼リード開発者であるNiels de Feyter氏は、Drupalのアップグレードを成功させる鍵は、基盤となるプラットフォームをモダナイズしながらも、システムの観測可能な挙動を保つことにあると主張しています。Drupalの開発と移行における15年以上の経験をもとに、同氏は自身が「Steady State Update（定常状態アップデート）」と呼ぶ原則を中心に仕事を組み立ててきました。
このアイデアは、同氏が複数のソフトウェアプロジェクトで観察したあるパターンから生まれました。システムの実装とユーザーから見える挙動を同時に変えると、検証が難しくなり、リグレッション（機能後退）のリスクが高まる、というものです。
この書面インタビューで、Niels氏は、2026年になってもなお組織がDrupal 7にとどまる理由、老朽化したシステムに伴う運用上・セキュリティ上のリスク、そして大規模なアップグレードの過程で業務に不可欠な機能を保つことの難しさについて語ります。
同氏はまた、検証、テスト、移行の複雑さ、AI支援開発、そしてDrupalのモダナイゼーションプロジェクトを成功と定義づけるものは何かについての見解も共有しています。同氏は、The DropTimesのサブエディターであるKazima Abbasにその知見を語りました。
TDT [1]：あなたの仕事は現在、Drupal 7からモダンなDrupalへのアップグレードを中心としています。従来のアップグレードやリビルドのプロジェクトで繰り返し見られたどのような失敗パターンが、CodeLiftを立ち上げるきっかけになったのですか？
Niels de Feyter：ソフトウェア開発チームは、システムの内側と外側を同時に変えるべきではありません。それをすると、システムが正しく動作することを証明するのが難しくなり、プロセスを管理する手間が増え、リグレッションや待ち時間という形で無駄が生まれます。
この洞察がCodeLiftの「Steady State Update」原則につながり、2024年に会社を設立することになりました。システムの外側は同じに保ちながら、内側を改善・モダナイズする。そして、観測可能な状態が同じであることを証明することで、システムが動作することを証明するのです。
このアプローチであれば、あらゆるレガシーシステムを、壊すことなくモダナイズできると私は確信しています。
TDT [2]：Drupal 7のサイトは2026年になってもまだアップグレードが続いています。あなたが直接見ているプロジェクトから見て、なぜこれほど遅くまで組織がDrupal 7にとどまるのでしょうか。待てば待つほど、どんなリスクが高まるのでしょうか。そして、基盤となるPHPやサーバー環境の古さは、どの時点で定常状態アップグレードの実施を難しくするのでしょうか？
Niels de Feyter：一般的に、サイトオーナーは長年うまく機能してきたDrupal 7システムに満足しています。技術的・運用的なリスクは水面下で蓄積していくのですが、それらは隠れています。システムがレガシーであればあるほど、モダナイズするのに多くの労力がかかります。
最大のリスクは、サイトがハッキングされ、顧客データや接続された内部システムが侵害される「ブラックスワン」的な事象だと思います。
–Niels de Feyter（CodeLift創業者兼リード開発者）
これはここ数か月の間に、国際的にさまざまな大規模ウェブサイトで発生しました。おそらく、世界中のどの開発者でも利用できるのと同じAIツールを使って行われたのでしょう。
TDT [3]：Drupal 7のアップグレードは、コンテンツ、機能、アーキテクチャを含む技術的な移行としてよく説明されます。実際のプロジェクトでは、その説明はどの点で誤解を招くものになるのでしょうか？
Niels de Feyter：Drupal 7のアップグレードは、単なる技術的な移行ではありません。システムが何をするのか、そしてどのように使われているのかを把握することが、プロジェクトの不可欠な一部であることが分かっています。そしてこれは、サイトオーナーのチームと緊密に協力することでしか実現できません。この非技術的な作業は重要です。隠れたロジックを特定し、実際のワークフローをテストし、重要な挙動を検証し、何を残すべきかを承認していくのです。
Steady-State-Updateでは、クライアントの時間的な投資を最小限に抑えますが、それでもDrupal 7のアップグレードにおいてはかなりの負担になります。
TDT [4]：多くのDrupal 7サイトは、長年にわたってカスタムモジュール、編集ワークフロー、権限、コンテンツタイプ、文書化されていない業務ルールを蓄積してきました。何を保持し、何を再構築し、何を廃止し、何を問い直すべきかをどのように判断していますか？
Niels de Feyter：原則として、私たちはすべてを保持します。クライアントがプロジェクトの早い段階で、ウェブサイトの特定の部分を削除するように指示しない限りは。
TDT [5]：「検証ファースト（verification-first）」と言うとき、具体的に何が検証されているのでしょうか。キャプチャから比較、受け入れまでのアップグレードの一ステップを説明してください。
Niels de Feyter：システムの観測可能な状態です。私たちの検証システムは、ログイン済みユーザーとしてウェブページを訪問します。そして、新システムとレガシーシステムの両方でスクリーンショットを作成します。それらのスクリーンショットは一致しなければなりません。もし一致しなければ、そこにバグがあると分かります。
これを複数のユーザーとサイトマップ全体にスケールアップすると、1回の検証実行で1000ページ以上を比較することになります。また、設定済みの製品をショッピングカートに入れる製品コンフィギュレーターのような、複数ステップのワークフローにも対応しています。
私たちには手動テストを行う品質保証チームもいます。彼らは送信メール、サインアップ、reCAPTCHA、その他の自動化されていないプロセスの検証を担当します。
私たちの品質保証チームが、最終的な検証の判定を下します。
TDT [6]：あなたの定常状態アップグレードのアプローチは、サイトがアップグレードの前後で同じように動作することを証明することに依存しています。Drupal 7サイトのどの部分が確実にキャプチャでき、どの部分が自動的に検証するのが難しいままなのでしょうか？
Niels de Feyter：難しいケースは、システムの隠れた業務ロジックです。特に、モダンなDrupalに移植されていないカスタムコードやモジュール（Rulesなど）の中にあるものです。あるウェブショップでは、ロールや国別の条件に基づいて割引を適用する価格計算があるかもしれません。さまざまな価格計算をすべてどうトリガーするかを知ることが極めて重要です。
最も簡単なのは、ウェブページ上に直接表示されるもの、あるいはHTTP GETリクエストに対するRESTレスポンスに含まれるものすべてです。たとえば、ログイン済みユーザーとしてフロントページを表示する場合などです。この検証は完全に自動化されており、これらのページの発見も同様に自動化されています。
外部システムを伴うワークフローには手動テストが必要です。たとえば、reCAPTCHAセキュリティ付きのサインアップや、訪問者のメールクライアントで受信されなければならないHTMLメールなどです。
TDT [7]：壊れたエンティティ、一貫性のないフィールド値、放棄されたコンテンツタイプ、あるいは移行スクリプトを実行したときにだけ現れるデータベースの前提といった、レガシーデータの問題にどう対処していますか？
Niels de Feyter：ほぼすべてのプロジェクトで、私たちはDrupalのアーキテクチャをモダンな標準へと統合します。これには次のものが含まれます。
- エンティティ、フィールド、翻訳のデータモデル
- 認証・認可システム
- キャッシュとページ速度の最適化
データ移行の実現は反復的なETLプロセスであり、移行を実行し、結果を検証し、うまくいくまで修正と繰り返しを行います。
この進め方により、レガシーシステムから新システムへ、最適なフォーマットと構造でデータを読み込むことができます。
TDT [8]：Drupal 7のアップグレードにおける強力な「完了の定義（definition of done）」とはどのようなものでしょうか。誰がそれを定義し、その定義がプロジェクトの途中で変わらないようにするにはどうすればよいのでしょうか？
Niels de Feyter：プロジェクトは、モダナイズされたシステムが本番環境で1か月間問題なく稼働したときに完了です。その時点で、すべての機能が触れられているはずであり、これが成功を証明します。
強力な「完了の定義」には、システムの可視的な挙動と、それが使用している実装レイヤーの仕様も含まれるでしょう。
各プロジェクトは、まさにこの仕様を発見することを目的とした発見（discovery）フェーズから始まります。
実際に起きたことは、クライアントによる手動テストの中で、隠れた業務ロジックや外部システムとの統合が発見されたということです。私たちの目標は、発見をできるだけ前倒しし、自動化することです。
TDT [9]：クライアントは通常、どこでDrupal 7のアップグレードを過小評価するのでしょうか。エージェンシーはスコープ、スケジュール、納品リスクを見積もる際に、通常どこで過小評価するのでしょうか？
Niels de Feyter：通常、過小評価されるのは、1回のテスト実行で必要とされるテスト量と、最終承認までに必要な反復の総回数です。これはすぐに積み上がります。エンドツーエンドのテストに10時間かかるのに、5時間と見積もられていたとしましょう。そして、5回の反復ではなく、実際には25回必要だったとします。その差は10倍（5×5に対して10×25）になります。私は個人的に、これに対する良い解決策は、自動化とプロジェクト間での統合ツールの再利用だけだと考えています。
2つ目の過小評価はデータ移行です。Drupalの移行モジュールは複雑なシステムで、多くのプラグインや依存関係が組み合わさると壊れやすくなります。私たちはDrupalの移行モジュールを強化し、回避するために、追加のスクリプト化されたデータ移行コードを書いています。
TDT [10]：CodeLiftは、リビルド主導のアプローチと比べて開発者のワークフローをどう変えるのでしょうか。何が速くなり、何がより厳格になり、何が依然として人間の判断を必要とするのでしょうか？
Niels de Feyter：CodeLiftの定常状態アップデートは、システムの優先順位付けや再考のためのミーティングといった創造的なチームワークを超えて、大きな効果をもたらします。そうしたことは依然として可能ですが、別のプロジェクトとしてスコープを切り、Drupal 7のアップグレードの中には含めません。これにより、外部ステークホルダーからの入力や承認を待つ時間が減り、開発者のワークフローのブロックが解消されることに気づいています。
ソフトウェアアーキテクチャには、依然として人間の判断が必要です。
TDT [11]：AIツールは開発ワークフローでますます使われるようになっています。Drupal 7のアップグレード作業において、AIは今日どこで現実的に役立ち、どこでリスクや誤った自信をもたらすのでしょうか？
Niels de Feyter：特に2025年にClaude Codeが登場して以来、コードを書くこととDrupalのようなフレームワーク開発がはるかに簡単になりました。私たちは常にそれを使っています。厄介なのは、コードを書くことが今や簡単になったように見えるため、バグやメンテナンス不能な機能を導入することもまた簡単になっている点です。だからこそ、検証とレビューがより重要になります。
面白いことに、私は2010年にDrupalが登場したときにも同じことを観察しました。それによって、私を含むはるかに多くの人々が複雑なウェブサイトを構築できるようになりました。以前のツール（素のPHPやJavaなど）は難しすぎたのです。しかし、その能力とともに、新しい職業が生まれました。AIによるエージェンティックコーディングでも同じことが起こると私は予想しています。ソフトウェアは今もこれからも、エンジニアリングの問題であり続けます。
TDT [12]：いまDrupal 7のアップグレードを計画しているチームは、Drupal 10とDrupal 11のどちらを選ぶべきでしょうか。長期的なメンテナンス性、コントリビュートモジュールの準備状況、プロジェクトリスクにとって、最も重要な要素は何でしょうか？
Niels de Feyter：2026年には、すべてのDrupalサイトがDrupal 11にアップグレードすべきです。Drupal 10は2026年12月9日にサポート終了（end of life）を迎えます。
By Kazima Abbas, Sub-Editor
この記事は「Niels de Feyter: Why Drupal 7 Upgrades Need More Than a Migration Plan」（投稿日：2026-05-30）の翻訳記事です。
カテゴリ
カテゴリ
関連リンク
