属人CMS”からの脱却──Drupal全社導入と半年で6タイトルを同時展開した舞台裏
こんにちは。大手ゲーム会社でエンジニアとして働いています。
今回は、属人CMSの限界を打破し、Drupalを全社導入したプロセスと、
わずか半年で6タイトルを同時展開した現場の実情を紹介します。
- なぜDrupalだったのか？
- どんな課題があったのか？
- 実際にどう乗り越えたのか？
OSS活用やCMS統合、多言語対応、翻訳ツール連携、情報設計、内製化──
これらに関心がある方のヒントになれば幸いです。
なぜDrupalを選んだのか？
当時、社内には複数のCMSが乱立しており、運用や保守に課題がありました。
特に課題だったのは、多言語対応と属人化による運用リスクです。
※以前はWordPressに多言語対応プラグインを重ねていましたが、構成が煩雑化し、結果的にコストがかえって嵩む状態になっていました。
会社の方針としても、「多言語対応ができるCMS」「運用・保守しやすいこと」「コストと性能のバランスが良いこと」「ベンダーロックが起きにくいこと」が条件として挙げられました。
Drupalを選定した理由：
- OSSでライセンス費用が不要。柔軟なカスタマイズが可能
- Phraseなどの翻訳ツールとの連携がしやすい
- モジュールベースで拡張・共通化がしやすい
- コアアップデートや脆弱性対応の情報が早く信頼性が高い
- コア機能が充実しており、プラグインなしでも多くの機能が実現可能
- 中〜大規模サイト向けに設計されている
WordPressを選ばなかった理由
- 複数年運用＋多言語対応という要件では、WordPressのスケーラビリティに不安があった
- 実際に社内でも、複数タイトルでWordPress運用に失敗した例があった
- プラグイン依存による管理負荷と、セキュリティ的な懸念が残っていた
初期導入と学習フェーズ
Drupalはオブジェクト指向かつDB構造をフル活用するCMSであり、
設定・構成の多くがDBやYAMLファイル、テンプレートエンジン（Twig）に分散しています。
- ドキュメントは英語が中心で、やや技術者寄り
- HTML構造すらもDBで管理される仕組みに最初は戸惑った
- Drupal固有の概念（ノード、エンティティ、ビューモードなど）を理解するのに時間がかかった
一度構造が腹落ちすれば、非常に規則的で拡張しやすい仕組みです。
※初期導入プロジェクトは単言語対応でした。
多言語展開フェーズ
初期導入から約半年後、本来の目的である多言語対応に着手。
Drupalのコア機能だけでも多言語対応は可能ですが、運用面では以下の課題が判明：
- 多言語の記事を同時にタイマー公開する機能がない
- 多言語の記事を一括で「公開」状態にする機能がない
📌 例：10言語展開でのステータス遷移
「編集済み → 公開」の遷移を10回繰り返す必要があり、運用負荷が非常に高い状況でした。
これはミスの温床にもなります。
カスタムモジュールでの解決と提言
課題には独自のカスタムモジュールを作成して対応。
ただし、個人的には：
「このレベルの機能はコアに取り込んでほしい」
コアで保守される機能であれば、将来的な運用負担が減るためです。
Drupalは柔軟ですが、“痒いところに手が届く”には自力が要るのが現実です。
社内で広がるシェア
安定運用が進むと、他チームでも「Drupalでよくない？」という声が。
既存の翻訳連携にも課題があり、独自モジュールの開発により評価がさらに上昇しました。
社内で実質的な標準CMSになる日は突然に！
上司が退職した直後、他CMSのサポート終了が発覚し、次期CMS選定が開始。このタイミングでDrupalのテーマをフォーマット化し、内製で導入できる体制を提案したところ、フラッグシップタイトル含め一気にDrupal移行が加速しました。
スケジュール鬼！
決まるまで遅いが、決まると爆速——あるあるですね。
実装担当は私ひとりで6タイトル並行立ち上げになり、業務をこなすだけで手一杯でした。
入れるからには説明は丁寧に
Drupalのテーマ開発はクセがあり、デザイナーさんへの負荷が大きいため、
なるべく丁寧にドキュメントとレクチャーを実施しました。
以下のような内容を共有していました：
| 議題 | 担当 | 詳細 |
|---|---|---|
| Drupalの開発方法 | 主担当者 |
drupal/web/themes/custom/****** に基本的なリソースがあり、ディレクトリ構造やCSS・JSの役割、テンプレートやキャッシュの仕組み、パラメータ例、マニュアルリンク等を含めて共有 |
| サーバー構成 | 主担当者 | 利用可能ディレクトリ制限、本番反映までのフロー、Notionへのリンク等を含めて共有 |
| 今後の進行について | 主担当者・デザイナー | テスト環境・要件調整・デザインカンプの流れ・MTGスケジュール・不明点対応フローなど |
| 開発手法の説明 | 主担当者 | git運用方針、デプロイフローなど |
| デザイナーの権限確認 | 主担当者 | VPN環境とDrupalサーバーアクセスの許可取得、構成条件を共有 |
導入後の成果と信頼感
6タイトル同時導入は小さなトラブルも多発しましたが、
障害はほぼ30分以内に復旧、遅くても2時間以内には収束させました。
この結果、社内でのDrupalの信頼性が向上。
例えば、GW前の軽いアップデート連絡に対し、2時間以内に9チームが返信、2日後には全チームが対応完了という事例もありました。
まとめ
Drupal導入の成功要因は以下の通りです：
- 導入初期に構造を深く理解し、ナレッジを蓄積しておいたこと
- OSSの柔軟性を活かして、必要な拡張を自力で行ったこと
- デザイナーや他部署に対して、丁寧な連携と説明を重ねたこと
- 信頼と安定性を積み重ねて、導入拡大を“自然発生的”に実現したこと
- 複雑な機構ゆえ、ベンダーさんと二人三脚できる体制を整えたこと
💡 これは「もしも」の保険として、全てのプロジェクトに共通する備えでもあります。
社内・社外問わず、しっかり引き継げる体制を整えることは何より重要です。
最後までお読みいただきありがとうございました。
Zennでは、今後もCMS・PM・社内整備・OSS運用に関する知見をシェアしていきます。
フォローやスキ・フィードバック、お待ちしております！
Discussion