WordPress × FullCalendar

納品後の制約を「改善」に変えた、イベントカレンダーの実装事例

Webサイトは公開して終わりではありません。運用が始まってから新たな制約が判明したり、さらなる使い勝手の向上が求められたりすることも多いものです。

今回は、当初「トップページへのカレンダー表示」と「個別記事の作成」という要件で納品した「FullCalendar」導入事例が、その後の環境変化を経て、いかにパフォーマンスを30％以上向上させるに至ったかをご紹介します。

背景：上位組織の仕組みと、デザインカンプの意図

本案件のスタートは、サイトのトップページにイベントカレンダーを配置し、各イベントの詳細を個別記事で管理するという要件でした。

そこには上位組織が運用しているイベントカレンダーの仕組みを参考にしたいという明確な意図がありました。しかし、実際に扱うデータ構造や記事のボリューム、さらにはサイトのルールが異なるため、そのままコピーすることは現実的ではありません。

そこで、ディレクターと打ち合わせを重ね、「どこまで共通化し、どこから独自設計にするか」の整合性を丁寧に調整しました。

特にこだわったのが、デザインカンプに描かれていた「カレンダー・モーダル・個別記事」による3層の導線設計です。カレンダー上のイベントをクリックした際、即座にページ遷移するのではなく、まずはモーダルで概要を表示。そこから「詳細記事へ」「関連情報へ」といった複数の導線を設けることで、ユーザーがページを移動することなく情報を取捨選択でき、必要に応じて深い階層へ進める自然な回遊を実現しました。

初期実装：スピードと柔軟性を優先したプラグイン活用と、見えてきた課題

当初の構築段階では、イベント情報の管理にカスタムフィールドプラグインを採用しました。

当初の構築段階では、イベント情報の管理にカスタムフィールドプラグインを採用しました。

なぜ独自のプログラムを組まずにプラグインを選んだのか。それは、「限られた予算内で、将来的な要件変更に最も簡素かつ迅速に対応できるから」です。

開発初期において、最初からフルスクラッチの独自システムを構築することは、コストを押し上げるだけでなく、仕様変更のたびに追加費用が発生するリスクを孕みます。あえて柔軟性の高い構成をベースに据えることで、進行中の細かな調整や追加要望に対しても、予算の範囲内でロジックを崩さず、最小限のコストで打ち返せる状態を優先しました。

しかし、運用を進める中で、標準的なAJAX方式ゆえの課題も見えてきました。今回の要件ではカレンダーの表示タイプによって複数のJSONを出力する必要があり、データが重なるほどリクエストのオーバーヘッドが無視できなくなっていたのです。

「表示までに一瞬の『間』が空く」という状態は、UX（ユーザー体験）の観点からも改善の余地があると感じていました。

経緯：納品後の制約を「REST API化」による改善へ

無事に納品を完了し、運用が進んでいたある時、大きな状況の変化がありました。

クライアント側のセキュリティ方針が更新され、それまで使用していたカスタムフィールドプラグインは利用不可となったのです。

納品後のこの制約に対応するため、データ構造をプラグインに依存せず、テーマ内で完結する独自実装へと急遽シフトすることになりました。

この際、大きな強みとなったのが、すでに数ヶ月の運用を経て「フィールドの設計自体には問題がないこと」が証明されていた点です。運用実績に裏打ちされた完成度の高い設計をそのままコードへ落とし込むことができたため、移行は非常にスムーズでした。

幸いにもこの改修時には、予算的な余裕がありました。そこで、単なるプラグインの代替に留めるのではなく、前述の「JSON出力の重さ」を抜本的に解消すべく、システムを「WP REST API + FullCalendar」の構成へと刷新する提案を行いました。

成果：数値で現れた「30％以上」の速度改善

REST APIベースへの切り替えにより、カレンダーの挙動は劇的に進化しました。

パフォーマンスの向上：インサイトデータ上で30％以上の高速化を確認。
ストレスのない操作感：月を切り替える際の読み込み待ちがほぼ解消され、体感でも明らかに「軽くなった」と分かるレベルに。

制約をきっかけとした改修ではありましたが、予算というリソースを最大限に活かし、結果として「運用の継続性」を確保しつつ、サイト全体のユーザー体験（UX）を底上げすることができました。

制作のポイント

今回のプロジェクトにおいて、制作パートナーとして意識したポイントです。

ディレクターとの整合性調整：上位組織の仕組みをリサーチした上で、ディレクターと「自サイトにとっての正解」を議論し、仕様を固めた。
「複数導線」を持つモーダルの実装：デザインカンプの意図を汲み取り、モーダル内に詳細記事や関連リンクを配置。ユーザーを迷わせない情報の厚みを構築。
納品後の変化への柔軟な対応：プラグイン利用不可などの予期せぬ制限に対し、単なる「修正」に留めず、パフォーマンス向上という付加価値を乗せて打ち返した。
リソースに応じた技術提案：予算の余裕を「将来への投資」と捉え、REST API化によるデータ取得の最適化を提案・実行。

変化に寄り添い、現実的で「モアベター」な落としどころを探る

今回の事例は、最初から完璧な計画があったわけではなく、上位組織との調整や、納品後の制約、運用の変化に合わせて、その都度「モアベター」を選択し続けた結果です。

「既存の仕組みを参考にしたいが、そのままでは難しい」「特殊なUIを指定されているが、実装できるか」といった懸念は多いかと思います。

最初からフルスペックのシステムを組まなくても、まずは要件を満たし、状況に応じて中身をアップデートしていく。そんな柔軟な進め方も、一つの正解だと考えています。アイデア段階の「これ、どう実装するのがいいかな？」というご相談から、ぜひお気軽にお声がけください。

後記：なぜ「ベスト」ではなく「モアベター」なのか

今回の事例を通じて、改めて感じたことがあります。それは、予算や納期、予期せぬ制約が複雑に絡み合うWeb制作の現場において最初から「絶対的なベスト（最善）」を定義するのは、ある種の思考停止になりかねないということです。

開発のスタート時点では、クライアントの運用体制がどこまで固まっているか、将来的にどのような要件の変化があるか、すべてを見通すことはできません。

もし、初期段階で「これが最高の実装だ」と決め打ちして独自のガチガチなシステムを組んでいたら、納品後の「プラグイン利用不可」という急な制約変更に対応できず、多大な改修コストや工期が発生していたかもしれません。

まずは要件を柔軟に満たせる構成でスタートする
運用を経て検証された設計をベースにする
変化に合わせて、その時点での最適解へアップデートする

この「その時々の状況におけるモアベター（より良い選択）」を積み重ねていくアプローチこそが、結果として「破綻しないシステム」と「納得感のある着地点」に繋がると考えています。

「完成図が見えきっていないけれど、まずは形にしたい」「運用しながら育てていきたい」といった、現実的な課題に向き合っている制作会社様。ぜひ、その時点での「モアベター」を一緒に探るパートナーとして、お力になれれば幸いです。