「CMSで構築します。」
この一言、ディレクターなら一度は使ったことあると思います。
そしてだいたいこうなります。
クライアント
「CMSって何ですか？」
ディレクター
「コンテンツを更新できる仕組みで…」
ここまではいい。
問題はそのあとです。
「WordPressってことですか？」
これ、めちゃくちゃ高確率で聞かれます。
そして内心こう思う。
「まあ、そうです。」
Webディレクター、アルファベット好きがちです。
でもそのアルファベット、だいたい中身はWordPress。
CMSって言葉、便利なんですよね。
ふわっとしていて。
なんとなくそれっぽい。
でも便利すぎて、誤解も生まれる。
今日はその話です。
CMSまわりの略語、どう使ってるか。
そしてどうズレるか。
目次
CMSって言ってるけど、中身はほぼWP
まずここからです。
CMS = Content Management System。
コンテンツを管理する仕組み。
間違っていません。
正しいです。
でも実務だとこうなります。
CMS = WordPress。
ほぼこれです。
もちろん他にもあります。
Movable Type。
Headless CMS。
独自CMS。
でも現場で「CMSで」と言ったとき、
8割くらいはWordPressです。
ここで何が起きるか。
言っている人と聞いている人で、想像がズレる。
ディレクター
「CMSでいきます」＝WordPress前提
クライアント
「CMSでいきます」＝なんか便利なやつ
このズレ、地味に危険です。
例えば。
「更新しやすいんですよね？」
→管理画面の理解度による
「デザイン自由ですよね？」
→テーマ依存
「機能追加簡単ですよね？」
→プラグイン次第
全部、WordPress前提の話です。
でもCMSという言葉だけだと、その前提が共有されていない。
だから僕は最近、こう言うようにしています。
「WordPressで構築します。」
先に言う。
そのあとでCMSと説明する。
これだけで、会話のズレが減ります。
WPって言った瞬間、さらに距離が開く
次に出てくるのがこれです。
WP。
WordPressの略。
これ、ディレクター同士だと普通に通じます。
「WPでいいよね。」
「WPのテーマどうする？」
「WPの管理画面で対応できます。」
でもこれ、対外だと一気にわかりづらくなります。
クライアント視点だとこうです。
WP？
何それ？
さっきCMSって言ってなかった？
ここで混乱が起きる。
さらにややこしいのが、
社内でも通じないことがあることです。
デザイナー
「WPって何ですか？」
エンジニア
「WordPressのことですよ」
デザイナー
「ああ、それなら最初からそう言ってほしい」
あるあるです。
略語って便利なんですが、
理解している前提があるときだけ便利です。
だから僕はルールを決めています。
初出は略さない。
「WordPress（WP）」と書く。
2回目以降でWPを使う。
これだけで、だいぶ平和になります。
REST、ACF、API…急にアルファベットが増える
CMSまわり、途中から急にアルファベットが増えます。
「WPで構築して、ACF入れて、APIで連携します。」
ディレクター同士だと普通に通じます。
でもこれ、外から見るとほぼ呪文です。
よく出てくる略語を少しだけ整理します。
REST（Representational State Transfer）
→データのやり取りのルールみたいなもの
API（Application Programming Interface）
→システム同士をつなぐ窓口
ACF（Advanced Custom Fields）
→WordPressで項目を追加できるプラグイン
ここでよく起きる誤解があります。
「APIがあれば何でも連携できるんですよね？」
「ACF入れれば自由に管理画面作れますよね？」
半分正しくて、半分違います。
APIはあくまで“つなぐための入り口”です。
つながるかどうかは、相手次第です。
ACFも同じです。
項目は増やせる。
でも設計しないと使いづらくなる。
アルファベットの略語って、便利なんですが、
なんとなく万能に見えてしまうんですよね。
だから僕は、このあたりの話をするときはこう言います。
「できることは増えます。ただ、その分設計が必要になります。」
この一言を入れるだけで、期待値が落ち着きます。
略語が増えるほど、期待値もズレやすくなる
ここが一番やっかいなところです。
略語が増えると、説明は短くなる。
でも、その分だけ前提が省略される。
ディレクター
「APIで連携できます」
クライアント
「じゃあ何でもつながるんですね」
ディレクター
「いや、そういうわけでは…」
この会話、よくあります。
略語は、知っている人同士なら最短距離です。
でも知らない人にとっては、前提が抜け落ちた状態になる。
しかもアルファベットって、それっぽく見えるんですよね。
難しそう。
すごそう。
できそう。
だからこそ、誤解されたまま進みやすい。
ディレクターとして一番避けたいのはここです。
「できると思っていたのにできない」
このギャップが、あとで一番効いてきます。
じゃあどう使う？僕なりのやり方
ここで僕がやっていることはシンプルです。
略語をやめるわけではありません。
むしろ使います。
ただし、一言だけ具体を足す。
これだけです。
例えば。
「APIで連携できます」
→「APIで連携できます。ただし、相手側の仕様に依存します」
「ACFで対応できます」
→「ACFで項目は増やせます。ただ、設計しないと運用が複雑になります」
「CMSで更新できます」
→「WordPressで更新できます。ここまでは触れます」
この“一言”があるだけで、ズレがかなり減ります。
ポイントは、全部説明しないことです。
全部説明すると長くなる。
理解されない。
結局聞かれる。
だから一言でいい。
「万能ではない」という前提だけ置いておく。
これ、かなり効きます。
今日からどうする？
アルファベット、つい使ってしまいます。
CMS。
WP。
API。
ACF。
短くて便利。
それっぽい。
でも、その裏にある前提が抜けると、後でズレる。
だから今日からこれだけやればOKです。
略語は最初だけ展開する。
WordPress（WP）
Application Programming Interface（API）
これを一回だけやる。
それともう一つ。
「できること」と「制約」をセットで一言添える。
これだけです。
ディレクターの仕事って、説明の仕事でもあります。
アルファベットを使うこと自体は悪くない。
むしろ必要。
でも、そのアルファベットの裏にある前提まで渡せると、
会話が一気に楽になります。
Webディレクター、アルファベット好きがちです。
だからこそ、ちゃんと伝わる使い方をしていきたい。
それだけで、現場はだいぶスムーズになります。
