複雑なCMS入力を、仕様書とテストで移行可能な機能へ整える

ご要望は、既存CMSの運用を継続しながら、新しい検索・分類機能とコンテンツ入力を追加することでした。マルチサイトでは、どのサイトがデータを持ち、どの画面へ表示し、共通設定をどこまで共有するかを決めなければなりません。

入力条件が多い機能を画面の見た目だけで作ると、運用者は何を入力すべきか判断できず、検索結果も想定どおりになりません。既存プラグインを組み合わせる案も、要件への適合と将来の保守を確認せず採用できません。検索条件、カテゴリ、入力項目、移行対象、例外時の表示を、資料とテストで同じ定義へ揃えることが課題でした。

最初に、利用者が選ぶ検索条件と、管理画面で登録する項目を対応させました。画面単位で仕様を書くのではなく、入力値がどのカテゴリへ属し、どの検索結果に現れるかを整理しています。すべてを自由入力へする案は採用せず、選択肢で揃える項目と、文章として入力する項目を分けました。

既存プラグインを利用する場合と独自に実装する場合を比較し、機能の有無だけでなく、マルチサイトでの利用範囲、移行方法、更新時の保守を判断材料にしました。仕様書と設計書に加え、運用者向けマニュアルとテスト結果を残し、制作側と運用側が同じ条件を確認できる状態にしています。

この方式は、入力項目と検索条件の対応が明確な場合に有効です。業務ルール自体が未確定なら、先に代表データで検索結果を検証する必要があります。

検索画面は条件を並べるだけでなく、利用者が選択肢の違いを理解し、現在の条件と結果を確認できる構成にしました。カテゴリ階層が深くても、最初からすべてを見せず、判断に必要なまとまりへ分けています。

管理画面では、公開画面の言葉と入力項目の言葉がずれないようにしました。同じ意味の項目を画面ごとに別名で呼ぶと、運用者の入力ミスにつながります。必須、任意、条件によって表示される項目も視覚的に区別しました。

仕様書の項目名、管理画面、検索画面を対応させ、デザイン確認が見た目だけで終わらず、データの流れを確認できる状態を目指しました。

WordPressマルチサイトの既存構造を確認し、データの登録先、検索対象、サイト間で共有する設定を整理しました。カスタムフィールドは、画面ごとに増やすのではなく、検索条件と表示用途へ対応させています。

検索では、複数条件の組み合わせ、結果なし、未入力データ、カテゴリ変更後の表示をテストしました。移行時には、旧データを新しい入力項目へどう対応させるかを定義し、代表データで一覧・詳細・検索の一致を確認しています。

プラグイン採用は、短期的な実装量だけで判断せず、マルチサイト対応、更新継続性、独自条件の扱いを確認しました。複雑なCMS機能は、コードと同じ重要度で、仕様書、移行手順、テスト結果、運用マニュアルを揃える必要があります。