なぜ項目の名前と説明文が運用を左右するのか

CMSの設計者は、項目の意味を完全に理解しています。「この項目はサイトのどこに表示されるか」「どんな値を入れるべきか」「文字数の上限は何文字か」「他の項目とどう関係するか」、すべて頭の中に入っています。

ところが、運用者は違います。設計者の頭の中にある情報は、運用者には見えません。運用者が見ているのは、画面に並んだ項目名と説明文だけです。ここに必要な情報が書かれていなければ、運用者は判断できず、毎回問い合わせをすることになります。

CMSの運用フェーズで発生する問い合わせの多くは、項目の名前と説明文を丁寧に作り込めば防げるものです。設計者の頭の中にある暗黙知を、項目名と説明文に書き出す作業。これが第5回のテーマです。

項目名のつけ方

項目名を決めるとき、押さえておきたいポイントがいくつかあります。

運用者が一目で意味を把握できる名前にする

開発者が考えがちなのは、システム識別子をそのまま運用画面に出してしまうことです。「TITLE_MAIN」「DATE_PUBLISH」のような英大文字のスネークケースが画面に並んでいると、運用者は意味を理解する前に拒否反応を起こします。

運用者が見る項目名は、自然な日本語にします。「タイトル」「公開日」「メイン画像」のような、説明されなくても何を入れる場所か想像できる名前が望ましいです。

システム上の識別子（実装ファイル名やデータベースのキーで使う名前）と、運用者が見る項目名は分けて持たせます。第2回でテンプレートについて同じ話をしましたが、項目レベルでも同じ原則が効きます。

似た項目は接尾辞で区別する

実務では、同じ種類の項目が複数必要になることが頻繁にあります。たとえば「サービス名」という情報は、サイト内の表示場所によって長さや形式を変えたい場合があります。詳細ページでは正式名称、一覧ページでは省略形、ナビゲーションでは超短縮形、というように。

このとき、項目名を次のように分けると、運用者が混乱しません。

  • サービス名
  • サービス名 - 短縮表示用
  • サービス名 - 法人名
  • サービス名 - 通称
  • サービス名（ふりがな）

主たる項目名（「サービス名」）の後ろに、用途を示す接尾辞をつけます。「サービス名2」「サービス名B」のような無機質な番号やアルファベットではなく、何の用途で使う項目かが名前から分かる形にします。

似た項目が増えてきたとき、項目名を見直すのは設計の重要な作業です。「タイトル」「タイトル2」「タイトル3」のような状態になっていたら、それぞれの用途を明確にした名前に整理し直します。

説明文を充実させる

項目名の次に重要なのが、各項目に付ける説明文です。CMSによっては、項目の下に説明文を表示する機能があります。ここを使い倒すかどうかで、運用品質が大きく変わります。

説明文に書くべき内容は、おおむね次の4要素です。

  1. 使い方の説明：その項目に何を入れるべきか
  2. 具体例：実際の入力例
  3. 使用箇所：その項目の値がサイト上のどこに表示されるか
  4. 注意点：守ってほしいルール、ありがちなミス

これらをすべて書く必要はありませんが、運用者が判断するために必要な情報は揃えておきます。

説明文のサンプル

具体的にどんな説明文を書くか、いくつかサンプルをお見せします。

サンプル1：基本的な項目の説明

サービス名 - 短縮表示用
一覧やナビゲーション用の短縮形のサービス名をご設定ください。
例）「○○分析プラットフォーム」が正式名称の場合、「○○分析」のように短縮します。
使用箇所）サービス一覧、ホームの主要サービスセクション、グローバルナビ、
関連サービスの推奨欄など、限られたスペースで表示する場面で利用されます。
*正式名称をすべて表示できる場合は、「サービス名」項目の値が使われます。

これは「使い方」「具体例」「使用箇所」を揃えた基本形です。「使用箇所」のラベルをつけて、サイト上のどこにこの値が表示されるかを明示しているのがポイントです。

サンプル2：選択肢が複雑な項目の説明

関連リンク（種類指定）

■サービス情報へのリンク
サービス概要=service-overview
料金プラン=service-pricing
機能一覧=service-features
よくある質問=service-faq
資料ダウンロード=service-document

■導入事例へのリンク
事例一覧=case-list
業種別事例=case-industry
規模別事例=case-size

選択肢のパターンが多い項目では、どの値を入れたら何が起きるかを一覧にしておきます。運用者が項目を見ながら、必要な値を辞書のように引ける状態にすると、問い合わせが激減します。

サンプル3：複数の項目で使い分けが必要な場合

補足情報（見出し）
副題やキャッチコピーなど、メインタイトルに添える短い文言を入力します。

補足情報（テキスト）
副題やキャッチコピーの本文を入力します。

自由HTML（上部）
ページ冒頭の導入文・前書き・告知文などに使用します。

自由HTML（下部）
ページ末尾の締めの挨拶・関連情報の案内などに使用します。

似た名前の項目が並ぶときは、それぞれにどんな場面で使う項目かを書き分けます。「自由項目だから何でも入れていい」と運用者に判断させるのではなく、想定している用途を明示します。

サンプル4：チェックボックス項目の説明

準備中
チェックされている場合、関連サービス・関連事例の推奨欄に表示されません。

チェックボックスは「ON/OFFの意味」が運用者に伝わりにくい項目の代表です。チェックを入れたら何が起きるかを、明確に書きます。

説明文に書く情報の優先順位

説明文に書ける文字数や行数には、CMSによって制約があります。すべてを書ききれない場合、優先順位は次のようになります。

  1. 最優先：使用箇所（サイトのどこに表示されるか）
  2. 次に重要：具体例（実際の入力サンプル）
  3. その次：注意点（ありがちなミス、特殊なルール）
  4. 余裕があれば：使い方の詳細

「使用箇所」が最優先なのは、運用者が「自分がこの項目を変更したら、サイトのどこに影響が出るか」を把握する必要があるからです。これが分からないと、運用者は怖くて項目を編集できません。

入力の型と文字数制限

各項目には、入力の型を設定します。代表的なものは次の通りです。

  • 1行テキスト
  • 複数行テキスト
  • リッチテキストエディタ
  • 数値
  • 日付・日時
  • 選択肢（ラジオ・チェック・プルダウン）
  • 画像
  • ファイル
  • リンク

型を適切に選ぶと、運用者の入力ミスを減らせます。日付を1行テキストで入力させると、形式がバラつきます（2026/1/15、2026年1月15日、1/15、など）。日付型を使えば、CMS側でカレンダー入力になり、形式が統一されます。

文字数制限も、設計時に決めておきます。項目名の横に「（50）」のような形で最大文字数を表示しておくと、運用者は入力しながら長さを意識できます。

文字数制限は、表示画面のレイアウトから逆算して決めます。一覧ページでタイトルが2行に収まるべきなら、その文字数が上限になります。説明文には「全角40文字を超えると、一覧ページで末尾が省略されます」のような注意書きを入れておくと、運用者が表示崩れを防げます。

必須・任意・初期値の判断

各項目について、必須にするか任意にするかを決めます。判断軸は、その項目が空だったときにサイトの表示が破綻するかどうかです。タイトル・公開日・メイン画像のような、どのページにも必要な項目は必須にします。補足情報・任意の関連リンクのような、なくても表示が成立する項目は任意です。

「なるべく必須にしたい」と思ったときは、注意が必要です。必須項目が多すぎると、運用者は「とりあえず仮の値を入れておく」状態になり、データ品質が逆に下がります。本当に必要な項目だけを必須にして、それ以外は任意にしておくほうが、結果として品質が保たれます。

初期値（デフォルト値）を設定できる項目には、適切な初期値を入れておきます。公開日に「今日の日付」、ステータスに「下書き」、カテゴリに「未分類」のような初期値があれば、運用者の入力負担が減ります。

選択肢はマスタ化する

プルダウン・ラジオボタン・チェックボックスの選択肢を、各ページで直接書かせる設計はおすすめしません。

選択肢のマスタ（カテゴリマスタ、タグマスタなど）を作り、そこから選ばせる仕組みにすると、次のメリットがあります。

  • 表記ゆれが防げる（「お知らせ」と「おしらせ」が混在しない）
  • 選択肢の追加・変更が一括でできる
  • 選択肢が増えるたびに既存ページを修正する必要がない
  • 後で「選択肢ごとの集計」のような処理がしやすい

選択肢が3〜5個で固定的なものは直接定義してもよいですが、運用中に増減する可能性がある選択肢はマスタ化しておくと、後の運用が楽になります。

この回のテスト観点

項目の命名と説明文が適切かは、次の観点で確認できます。

  • 設計者以外の人に項目名だけ見せて、何を入れる項目か説明してもらう：項目名から意味が伝わるかを確認する。「これは何を入れる項目ですか」と聞かれたら、項目名の見直しが必要なサインです
  • 運用者役の人に説明文だけを読んで入力してもらう：実際にコンテンツを入れてもらって、「分からなくて手が止まった」「設計者に聞きたくなった」項目を洗い出す。それらが、説明文の改善が必要な項目です
  • 似た項目が複数あるときの混乱を確認する：「タイトル」「タイトル2」のような似た項目を、運用者が正しく使い分けられるか確認する。混乱があれば、項目名や説明文の改善が必要です
  • 説明文に「使用箇所」が書かれているか棚卸しする：すべての項目について、「この項目の値はサイトのどこに表示されるか」が説明文で分かるか確認する。書かれていない項目があれば、追加します

検証の方法論については第7回で詳しく扱います。

まとめ

項目の命名と説明文は、CMS設計の中でも特に「設計者の暗黙知を運用者に渡す」作業です。設計者の頭の中にある情報を、項目名と説明文に書き出すことで、運用フェーズの問い合わせを大きく減らせます。

項目名は運用者目線でつけ、似た項目は接尾辞で区別する。説明文には使い方・具体例・使用箇所・注意点を書く。入力の型と文字数制限を適切に設定し、必須・任意・初期値を判断し、選択肢はマスタ化する。これらを丁寧に進めれば、運用者が説明文だけで自己解決できる仕組みが出来上がります。

次回（第6回）は、CMSで自動管理する領域と、あえて直書きにする領域をどう線引きするかを扱います。

著者

STSD株式会社代表 鴻田孝雄。製薬企業のWebサイトを中心に、BtoB向けCMSの開発・設計に20年以上関わっている。長期運用を前提とした設計と、運用負担を最小化する仕組み作りに関心がある。