「1年半」のはずが「3年半超」に！？ Web担当者Forumのサイトリニューアルが長期化したワケ

 Web担当者にとって、サイトリニューアルは特に難しい仕事の1つだろう。サイト体験を改善したい、運用環境に問題がある、でも日常業務も忙しい……。そんなジレンマを抱えながら多くの企業でリニューアルプロジェクトが計画されていることだろう。

2006年創刊の本誌・Web担当者Forumでも、このほどサイトリニューアルを実施した。日刊でニュースを提供する体制は維持しつつ、10年以上使ってきたサイト構築用CMS（コンテンツ管理システム）を刷新した。その作業に要した期間はなんと約3年半以上（！） もちろんサイト規模によって作業量は変わってくるが、とはいえ「1年～2年程度で完了」というあたりが、多くの人にとっての肌感覚ではないだろうか。

サイトリニューアル自体は成功したが、なぜこれほどの時間がかかったのか。Web担当者Forum編集統括・初代編集長で、オープンソースCMS「Drupal」のエンジニアでもある安田が内幕を語った。今となっては笑って話せるが、どうにも大変な事情があったようで……？

「Drupal」サイトリニューアル実施に至った、3つの理由

Web担当者Forumは、2006年7月24日に創刊したが、日々の更新によって、収蔵する記事数は約4万2000件を超える。創刊20周年を迎えたWeb担当者Forumだが、実はその誕生当初から、Webサイトを表示するためのCMSに、「Drupal」が採用されている。Drupalは長期にわたって開発が継続しており、国外・国内問わず導入例は多い。比較的身近なところでは、デジタル庁が2023年11月のサイトリニューアルに際してDrupalを採用した。

同一サイトを20年近く稼働させているとなれば、大小の問題は蓄積してくる。それに目をつぶらざるを得ない場合もあるだろう。それでもなぜ、サイトリニューアルを決断したのか。安田によれば、その理由は3つに集約される。

1. Drupal 7の公式サポートが終了するため、新バージョンへどうしても移行せざるを得なかった
2. サイトデザインを改善したかった
3. 社内ではWeb担含めて複数のDrupalがバラバラに運用されており、維持の手間も過大だったため、効率化したかった

理由1Drupal 7の公式サポートが終了するため、新バージョンへどうしても移行せざるを得なかった

リニューアル前のWeb担当者Forumでは、Drupalのバージョン7にあたる「Drupal 7」で運用していた。同バージョンは2011年1月にリリースされたが、その12年後にあたる2023年10月30日をもってEOL（End Of Life）、つまり公式サポートを終了することが予告されていた。以後、セキュリティアップデートは提供されなくなるため、これはさすがに商業目的Webサイトの運用にはそぐわない。アップデートが適用される新バージョンへの移行せねば──。3つの理由の中でも、これが決定的な要因だったと安田は振り返る。

理由2サイトデザインを改善したかった

Web担当者Forumのサイトデザインは2010年ごろに固まり、以後は微調整だけ行われていた。それから10年以上経過し、商業メディアとしてのデザインクオリティが高いとは言えなかった。また、サイトの構造などを見直すことで、直帰率や閲覧ページ数などの改善もねらいたかった。

理由3社内ではWeb担含めて複数のDrupalがバラバラに運用されており、維持の手間も過大だったため、効率化したかった

安田が関与する事業部では、Web担当者Forumを含めて合計7つのDrupalサイトが運用されており、このうち4つが、EOL対象のDrupal 7で構築されていた。これらを新バージョンへ移行するのが急務だが、別の課題もあった。運用体制がまったくバラバラで、非効率だった点だ。

4つのサイトの保守運用管理が本当にバラバラで、社外に頼んでいたり、社内でやっていたり。サイトの作りもまったく違っていたんです（安田）

Drupal 7で構築されている点は4サイトで共通している。ならばこの際、4サイトに共通の仕組みを構築して、まとめて管理できるようにしたいというのも、大きなモチベーションとなった。

独自開発のし過ぎも、大きな問題に

ただ、安田は実際のところ、もう1つ“裏のゴール”を設定していたという。いわゆる“属人化の解消”だ。

これまで私が、（Drupalで構築されている）Web担当者Forumとネットショップ担当者フォーラムのシステム管理をずっとやってきたのですが、あまりにも作りこみすぎてしまい、管理できる人が私以外にいなくなってしまっていた。これをどうにか解消しなければいけなかったのです。それこそ、私が明日、交通事故で死んでも大丈夫なように（安田）

説明によれば、これはマニュアルの整備などで対処できるレベルを遥かに超えているという。具体的には、サイト内での機能を実現するカスタムモジュールが50個にもおよんでいた。

Drupalは、「モジュール」という単位で機能を追加できる拡張性の高さを特徴とする。Drupalエコシステム内で作られたモジュールも多くあるが、通常はいくつかのカスタムモジュールを作って必要な機能を実装する。

Web担では、たとえば次のような多岐にわたる機能を、安田独自開発のカスタムモジュールによって実現していた。

• サイトに掲載した記事をYahoo!ニュースに配信する
• サイトに掲載した記事をスマートニュースなどの外部サービスに配信する
• 記事が掲載された際にSNSへ投稿する
• 読者プレゼントの締切を期日直前になって再告知する
• GoogleアナリティクスやSNSのデータを取得して記事と紐付けて分析する
• プレスリリース配信サービスからの企業リリースをサイトに掲載する
• 記事本文で大きな画像を使っていたら、自動的に縮小版を生成する
• トラフィックに応じて内部キャッシュを適切にwarmupする

この状況をさらに複雑化させたのが、Drupal 7からDrupal 8以降の改版時に断行されたフレームワーク変更だ。これにより、Drupal 7までで動作していたカスタムモジュールが、Drupal 8以降では動作しなくなる。つまり、約50のカスタムモジュールをゼロから作り直す必要がある。これはなかなかの難題だ。

デザイン難航。コストのために、納期で妥協

最終的に、リニューアルサイトが公開されたのは2025年11月18日である。その目標に向かって、プロジェクトの準備が具体的に始まったのは、2022年4月のことだった。過去にWeb担でも記事執筆など協力してもらっていた社外の専門家に相談し、プロジェクト体制やRFP（Request for Proposal、提案依頼書）を作る作業を進めていった。

RFPには、前述のリニューアル目的の3要素をしっかりと定義。その上で、具体的に対象とするWebブラウザーはどの条件か、現在運用しているサーバー環境の説明など、リニューアルサイト制作会社から提案してもらいたい内容を記載していった。RFPのたたき台となるテンプレートの提供を受けたこともあり、とりまとめにかかった期間は1か月～2か月で済んだ。

このRFP作成と並行して、開発実務の依頼先などのメドをつけていき、予算感も判明したことから、同年8月、社内でリニューアルプロジェクト開始の正式承認を得た。そして翌9月からはデザインの作成が開始された。

——そこからが長い道のりの始まりだった。次の開発ステップである、完成デザインのDrupal実装を依頼する会社との正式契約が2024年1月。つまり、デザインに1年3カ月かかった。安田も「これはさすがに長すぎた」と振り返るが、やむにやまれぬ事情があった。

要因はズバリ、コストである。

サイトリニューアルは、デザインだけ新しくすればいいという話ではない。リニューアル前サイトのシステムやデータを、新サイトへ移植することを前提に、デザインを完成させなければならない。そして、リニューアル前サイトは前述のとおり、安田によって徹底的に作り込まれ、結果として複雑化してしまっていた。しかも、4サイトあって内部構造もバラバラだ。

あれだけ作りこんだサイトです。Drupalに詳しい制作会社に話を聞いたら「5000万円ではとてもやれない。1億円もらえたらやってあげてもいい」と(笑)（安田）

この金額感では、確保済み予算では支払いきれない。では、少ない予算で目的を達成するためにはどうしたらいいか？ 安田はここで、プロジェクト管理の三角形（トライアングル）の理論を持ち出して考えた。一般的に、業務をだれかに頼む場合には「報酬額」「クオリティや量」「どれだけ早く仕事を完了させるのか」のバランスが（暗黙に）存在する。条件のどれかでハードルを上げるならば、他の条件のハードルを下げて全体のバランスをとるというものだ。たとえば、「報酬額を下げる」「締切も厳しくする」と「クオリティが下がる」、わかりやすい。「とにかく早く成果物を納入してもらい、しかもクオリティ面で妥協できない」なら「報酬額を上げる」しかない。

安田が諦めたのは時間だった。報酬額は変えられないが、クオリティや量も決まっている。であれば、「時間の制約を緩くする」しかない。デザイン会社に対して、「納期の目安はありますが、絶対厳守の締切ではありません。余裕のあるタイミングで作業を進めてください。他の案件があれば、そちらを優先してもらって問題ありません」という形での発注となった。それどころか、「ほかの案件があれば、そちらを多少優先してもよい。ペナルティはない」という条件までつけての発注となった。

この結果、当初は3か月～4か月を見込んでいたデザイン期間が、1年3カ月にまで伸びてしまった。繰り返すが、準備開始からリニューアルサイト公開まで3年半以上である。なおWeb担当者Forumの編集部では「リニューアルで新サイトが生まれるより前に、産休した部員の子供が生まれた！」という笑い話があったそうな。

4サイト共通管理の仕組み構築でも時間がかかった

話はこれで終わらない。リニューアル対象4サイトを実際に構築する際の作業工数が当初予想より大幅に増えてしまった。勘違いのないように説明すると、この部分の開発実務を担当するのは、Drupalのエンジニアでもある安田自身。外部委託ではない。

既存のシステムのアップグレードに加えて、“4サイト共通で保守運用するための仕組み”作りが当初からの目標でした。そこで、ある程度の作り込みが発生するのはわかっていましたが、実際にやってみると、想定のレベルを超えてしまったんです（安田）

そもそも論として、CMSは原則として「1つのサイトを管理する」ように設計されているのが一般的だ。今回のリニューアルでも、リニューアル対象4サイトはそれぞれ独立して稼働する。

安田の目指す“共通の保守運用”の最終形は次のようなものだった。

• システムは共通化させ、内部の基本挙動はどのサイトも原則同じにする
• ある設定項目を修正する場合には、他サイトにもほぼ自動で反映できるようにする
• 一方でサイトごとに設定を変えたい部分があれば、全体の設定に影響を与えずにサイトごとに変更できる

話だけ聞けば十分理解できる。しかし現実に、システムとしてこれを実現しようとすると細かい点で問題が続出した。サイトごとに設定を変える機能はDrupalでも存在するが、変更したい箇所によってはその機能ではうまくいかなかったり、サイト別の設定が複雑になって後で把握できなくなりそうだったりしたのだという。

仮に「イベントレポート」を一覧表示したいとする。各サイトでそうしたコンテンツはあるのだが、過去に異なるサイトとして作られていたため、内部的な「この条件に合致するものがイベントレポート」という条件がバラバラすぎるのだ。単純に「条件抽出のカテゴリIDをサイトごとに変えればいい」わけではなく、「このサイトでは条件Aと条件B」「このサイトでは条件Cと条件Dと条件E」といった、まったく違う軸での処理が必要だった。

こうした違いを吸収し、「全体の仕組みは1つ」「サイトごとに違う部分は設定で対処」できるようにする工数が、想定をはるかに上回ったのだという。

今回のリニューアルでは予算の都合もあり、安田自身がこの作り込みを行った。追加で膨大な作業が発生するだけでも大変だったが、フレームワークが根本的に変わったDrupal新バージョンに安田自身が慣れていないことも仇となった。

ここで諦めて4サイトをバラバラにしてしまうと、結局、運用コストが膨らんでしまう。なんとかやりきるしかない。いまここで作り込んでシンプルにしておけば、向こう数年、場合によっては10年くらい、保守運用がスムーズになります。その後の保守を外部に委託するにしても、わかりやすくなる（ので絶対実装するしかなかった）。まぁ、それにしてもかかりすぎましたけど……（安田）

安田による作り込み作業は、最終的に2025年1月から11月まで、リニューアルサイト公開直前のほぼ1年にわたって、続けられた。

大幅遅延もプロジェクト成功。しかし、諦めたものもあった

こうして約2年のプロジェクト遅延を経て、2025年11月、4つのリニューアルサイトが一斉に公開された。公開開始からすでに約10カ月が経過したが、当初の目論見通り、保守運用にかかる工数・コストは削減された。安田に集中していた保守運用実務を、完全に外部委託する目処も立った。

安田は「リニューアル後、外部の編集者さんに『なにも変えてないんじゃないですか？』と言われたことは、本当に嬉しかった」と明かす。内部的にはまったく違うフレームワークで完全に違うコードなのだが、CMSを触る編集者にはその違いを感じさせないように、互換性を保った。編集者が日々アクセスするCMSの各画面も、若干のデザイン変更などは行ったが、違和感がなく操作できるように徹底配慮したこともあり、不満の声は出ていない。各ページのURLは変わらず維持され、リンク切れなどに関する読者からの問い合わせは一件もなかった。

またサイトリニューアルに際しては、SEOへの影響も気になるところだが、検索順位の低下などは発生しなかったという。事前の準備を周到に行ったのはもちろんのこと、いくつかあった問題点を公開直後に修正できたのも大きい。記事やイベントなどWeb担に関わりのあるSEO専門家らから、リニューアルサイト公開後に「ここに、こう問題がありますね」と具体的な指摘を多く寄せてもらえたそうで、これはまさに“役得”といったところか。

時間はかかったものの、ある種で理想のリニューアルが達成できたようにも思える。ただ計画段階で諦めた要素は少なくない。

一般論としてのサイトリニューアルは、サイト訪問者の体験向上、つまりUXの改善が大目的によく掲げられる。ユーザーは何を求めてサイトを利用しているのか？ 複数回訪問してきたユーザーには何か別の対応すべきか？ さまざまな観点から分析を行い、それを満たすべく調整をかけるというのが1つのアプローチだ。だが、その作業の実現には予算も時間もかかる。安田は計画当初の段階で一切諦めた。プロジェクトでも「一般的なUX改善は含むが、実際のユーザー調査に基づく改善はスコープ外とする」ことを明確にしていた。

同様に、あきらめたことがある。開発コンペの開催だ。

当初は、参加事業者を選定したうえで、アイデアの権利もきちんと処理して、その上でコンペ参加者にコンペフィーをしっかりと払う形でのコンペを開催しようと思っていたんです。

世の中のコンペでは、「コンペに参加したのに（選ばれないと）一銭にもならず、工数だけかかる。しかも、結果がパクられているのではないか」といったことがあるじゃないですか。そうではなく、発注側はこうした形で進めるべきだという「本来のあるべき姿のコンペ」を、やりたかったのです。

業界を支える役割の媒体として、そうした形でコンペを実施して、それを記事にして公開したかった（安田）

ただ今回は、コストや時間の都合でコンペを実施できなかった。将来的に、デザインやシステム開発が必要になった際には、ぜひチャレンジしたいという。

待つ身はツラい。2年遅延して、なおかつ進捗報告が足らず

……と、ここまではおおむね、安田側の視点での話である。もちろん、サイトリニューアルは1人でやるものではない。Web担当者Forumの編集部員は「リニューアルの行く末を待つ側」「リニューアル後に作業効率が落ちないか、気が気でない側」としては、かなりの労苦があったようだ。

筆者も本稿執筆にあたって編集部員に少々話を聞いたが、基本的には笑い飛ばしつつも、その“作業の進め方”には不満を漏らした。当初のリニューアル完了予定時期は2023年11月。それが完全に2年遅延し、2025年の11月となったのだ。これはさすがに致し方あるまい。

この規模の遅延に関しては、安田も反省しきり。「開発であまりにも忙しすぎて、報告していたつもりができていなかった」と平謝りだった。

編集部員からすると、まず安田からリニューアル後のデザイン案は比較的早い段階で示された。しかし、その実装が行われたのは1年半後。しかも、当初案と大きく乖離している状況だった。あまりに長期化しすぎ、ある編集部員は「しつこく聞き続ければよかったが、疲れてきて『もういいです』というような状況だった」と振り返る。

加えて、編集部内で異動や産休にともなう人員の出入りがたまたま多かったことも、状況を悪化させた。平時よりも人員が少ないにもかかわらず、しかも散々待たされたのに突然「実装のチェックを〇〇日までにやってほしい」などの依頼が舞い込む。当時はなかなかに殺伐とした雰囲気だったようだ。

やはり、想定外の事態が起こったら、関係者間できっちりコミュニケーションをとる。これが鉄則だ。

サイトリニューアルで本当に大事なことは？

サイトリニューアルは、実施されるサイトによって背景も課題も微妙に異なる。よって、Web担当者Forumの事例がそっくりそのまま他社サイトでも参考になるとは限らない。

ただそれでも、メディアの立場を離れ、いちエンジニアとして安田がサイトリニューアルについてアドバイスするならば、それは事業ドメインに対する理解こそが最重要ではないか、と述べた。

サイトリニューアルは、どんなアプリケーションを使うか、どうやってコンテンツを移行するか、スケジュールはどうするかという技術論が優先されがちだ。しかし、その企業がどういう収支で成立しているのか、CMSに普段触っている人は実際にどんなタスクをしているのか、ならば何を優先すべきなのか。そうした理解に立ったサイトリニューアルでなければ、最終的に機能しないのではないか。それが安田の疑問だ。

これは逆に言うと、サイト制作会社に頼んだだけで上手くいく話ではない。発注側がきちんと課題を把握して訴えていかないと、サイト制作会社側はそこまでは察知してくれないでしょう（安田）

これはもっともな指摘だろう。サイト制作会社は確かにプロ集団だ。だが、サイトリニューアルを依頼する企業の事情を100％完全に理解しているわけでもない。ならば、餅は餅屋で任せるべきところは任せる。だが事業の根幹にかかわる部分はブレないように口を出し続ける。

安田はもう1つ、「アクセス解析をCMS管理画面にも導入してはどうか」というアイデアも披露した。オーディエンスの行動把握を目的としたアクセス解析はもはや当たり前だが、これとは別枠で、CMS管理画面にも適用する。こうすれば、「頻繁に利用されている機能」「1年に1回しか使われない機能」「苦労して実装したのに誰も使っていない機能」などが明確に判別でき、機能開発の取捨選択をする上での参考になる。工場生産の現場では、作業員の一挙手一投足を観察して、その効率を改善する取り組みがあるが、これのデジタル版・Web版と言ったところだ。実際、今回の4サイトリニューアルでは、管理画面の利用動向解析をはじめている。

「1年半の予定が、3年半以上かかった」——Web担当者Forumを含む4サイトの一斉リニューアルが、いかに難航したかを物語る数字だ。

ただ実際に話を深掘りすると「あるある」と共感できるエピソードが次々と出てきた。特に、リニューアル担当者とそれ以外の関係者のコミュニケーション不足は、多くの人が笑いつつも、一方で冷や汗を隠しているはずだ。

Webを取り巻く環境はどんどん変化している。AIの台頭による検索エンジンの立ち位置変化、プライバシー保護やアクセシビリティへの対応、パスキーをはじめとするセキュリティ向上施策の導入など、サイトリニューアルに対する要求のハードルは、間違いなく高まっていくだろう。

安田は今回のサイトリニューアルで、新機能追加の準備が整ったとしている。具体的には、トップページのパーソナライズ化を進め、読者により適した記事をレコメンドする機能の実装を目指す。また姉妹サイトで一部導入が進んでいる「インプレスID」への対応にも意欲を見せていた。

さらには4サイト共通基盤を設けたことで、新たなサイトの立ち上げもより容易になったという。サイトリニューアルは大変だ。しかし、成功すればそれだけの実りもある。今回の暴露話（？）を筆頭に、Web担当者Forumでは関連する記事・レポートを多数掲載している。リニューアルすべきかどうか、その判断材料としてぜひご活用いただきたい。