なのに、1年経ってもPVが1年経ってもPVがほぼゼロ。
これ、笑えないくらい普通に起きます。

俺もやった。

「これはいけるでしょ」で出した記事が、半年後に見ても誰にも読まれていない。

Analyticsを開いて、「いや、さすがにもうちょい…」ってスクロールするやつ。

現実は、きれいなゼロ。

原因はほぼ一つです。

検索意図を”わかったふり”している。

「検索意図＝キーワード」だと思っていた

若手のころ、シンプルにこう思ってた。

検索意図＝キーワード。

例えば、

「Webディレクター　年収」

このキーワードなら、

・平均年収
・年代別
・会社別

これを書けばいい、と。

間違ってはいない。でも、足りない。

実際に書くとこうなる。

「Webディレクターの平均年収は〜です。」
「20代では〜、30代では〜」

それっぽい。ちゃんとしてる。でも読まれない。

なぜか。

読者が知りたいのはそこじゃないから。

本当はこう思ってる。

「このまま続けていいのか知りたい。」
「転職したら上がるのか知りたい。」
「自分、低いのかどうか知りたい。」

でも記事は「平均は〇〇万円です。」で終わる。

そりゃ刺さらない。

検索意図の定義、ちゃんと切っておく

SEOでよく出てくる言葉。

検索意図（Search Intent）
→ユーザーがそのキーワードで検索した”本当の目的”

ここ、誤解されがちです。

「検索意図＝キーワードの意味」

ではない。

検索意図＝その人の状況と目的がセットになったもの

です。

同じ「Webディレクター 年収」でも、

・転職したい人
・今の会社で悩んでる人
・なんとなく気になった人

全然違う。

キーワードだけ見てると外す。これが”わかったふり”の正体です。

わかったふりの正体

「検索意図、考えてます。」

って言ってるとき、だいたいこれをやってる。

・関連キーワードを見る
・上位記事をざっと読む
・それっぽく構成を作る

で、満足する。

全部悪くない。ただ、それだけだと浅い。

なぜか。

読者がどれくらい切羽詰まってるかを見ていないから。

・今すぐ知りたいのか
・なんとなく知りたいのか
・かなり悩んでいるのか

ここが抜けると、全部同じ記事になる。そして誰にも刺さらない。

現場でどう見てるか

今、俺はこうやって見ています。

まずキーワードを見る。ここまでは同じ。

そのあと検索結果を開く。上位記事を読む。

ここで終わらない。

コメント欄と、SNSの反応を見ます。

「これわかりにくい」
「結局どうすればいいの？」
「この条件だと違う気がする」

こういう声を拾う。

ここに書くべきポイントがある。上位記事が拾えていない”ズレ”。そこが差になります。

あと、現場の経験を足す。

「実際はこういうパターンが多い」
「現場だとこうなる」

これを入れるだけで、記事の厚みが変わる。

結果で言うと

正直、外すときは外します。

どれだけ考えても読まれない記事はある。

でも、わかったふりで書いた記事はだいたい外す。

逆に、少し考えすぎたくらいの記事は、あとからじわっと伸びることが多い。

これ、現場での体感があります。

今日からどうする

じゃあ何をすればいいか。

シンプルです。

キーワードの”後ろ”を見る。

キーワードを見る
→その人の状況を想像する
→どこで詰まってるか考える

この順番。

あとこれ。

「自分だったら何で検索するか」をもう一段深く考える。

「年収」じゃなくて、

「このままでいいのか」
「転職したら上がるのか」
「自分だけ低いのか」

このレベルまで降りる。ここまでやると、だいぶ外さなくなります。

PVゼロの記事は、だいたい優等生

1年経ってもPVゼロの記事。

だいたいちゃんとしてます。

情報も正しい。構成もきれい。でも、刺さらない。

理由はシンプル。

人を見てないから。

検索意図を”わかったふり”していると、どうしてもこうなる。

だから、今日からこれだけ。

「この人、なんで検索したんだろう？」

これを一回考える。

それだけで、だいぶ変わります。

会議で普通に飛び交う言葉たち。

冷静に聞くと、ちょっと面白い。

公開でよくない？

僕も普通に言います。ローンチ。
むしろ、ちょっと気持ちいい。

言った瞬間、なんか仕事してる感が出る。
公開より、ローンチの方が“それっぽい”。

でもある日、ふと気づきます。

これ、誰にでも通じる言葉だっけ？

若手のころ、ローンチって言いたい

最初のころって、めちゃくちゃ言いたくなります。

ローンチ。
リスケ。
アジェンダ。
サマる。

全部使いたい。

「この案件、来週ローンチです。」
「一旦リスケでお願いします。」
「アジェンダ共有しておきますね。」

なんか強くなった気がする。

ただ、ちょっとだけズレる瞬間もある。

例えば、初めて入るクライアントとの打ち合わせ。

「ローンチって、どういう意味ですか？」って聞かれて、
一瞬だけ詰まる。

公開です。って言えば終わるのに、
なんかちょっと説明を足してしまう。

この“ワンクッション”、地味にストレスです。

いったん、日本語だけで話してみる（ちょっと苦しい）

試しに全部日本語で言ってみます。

「来週公開でお願いします。」
「公開前に最終確認入れます。」
「公開後のまとめ出しておきます。」

普通に通じる。

むしろ、わかりやすい。

じゃあ、これもいきます。

アジェンダ（agenda）
→会議の進行予定

リスケ（reschedule）
→日程変更

サマリー（summary）
→要約・まとめ

サマる（summaryの動詞化）
→まとまる

ここまではいい。

問題はこのへんです。

ファーストビュー（First View / FV）
→最初に画面に見える範囲

キービジュアル（Key Visual / KV）
→サイトの印象を決めるメイン画像

ヒーローイメージ（Hero Image）
→一番目立つ大きなビジュアル

……全部ちょっとずつ違う。

しかも、日本語にすると逆に説明が長くなる。

ここが難しいところです。

なんでローンチって言うのか

理由はシンプルです。

短いから。

「公開する」より「ローンチ」の方が短い。
「日程変更する」より「リスケ」の方が早い。

あともう一つ。

なんとなくニュアンスがまとまるから。

例えば「ローンチ」って言うと、

・公開
・リリース
・世に出す
・ちょっとした節目

このへん全部をまとめて言ってる感じがある。

だから便利。

ただ、その“便利さ”って、
前提を共有してる人同士でしか成立しない。

「ローンチ」がズレる瞬間

ここが今回の本題です。

「ローンチ」って言葉、
人によって意味がちょっと違います。

・公開した瞬間を指す人
・本番環境に反映されたタイミングを指す人
・プロモーション開始も含める人

つまり、同じ言葉で違うことを考えてる可能性がある。

これ、地味に怖い。

「来週ローンチですね」って言って、

片方は「公開完了」
もう片方は「リリース準備完了」

だったら、普通にズレます。

だから僕は、こういうときはちょっとだけ具体を足します。

「来週、公開（ローンチ）でお願いします。」
「本番反映のタイミングでローンチ扱いでいいですか？」

この一言だけで、だいぶ事故減ります。

僕はどう使ってるか

僕、ローンチ普通に使います。

使うんですけど、そのままは使わない。

最初だけ、ちょっとだけ日本語を混ぜます。

「来週公開（ローンチ）で進めますね。」

これだけ。

一回説明しておけば、そのあと楽です。

あと、相手によって変えます。

社内だったら「ローンチ」でいい。
外部だったら「公開」に寄せる。

新しく入った人には、なるべく日本語。

このへん、正直ちょっとちゃっかりやってます。

その方が話が早いし、あとで説明しなくて済むので。

それっぽさより、伝わるほうを選ぶ

アルファベットって、ちょっと便利すぎるんですよね。

言った瞬間、それっぽくなる。
仕事してる感も出る。

でも、それで伝わらなかったら意味がない。

むしろ、あとで余計な説明が増える。

だったら最初から、

「公開」
「日程変更」
「まとめ」

って言った方が早い場面も多い。

全部を日本語にする必要はないです。

ただ、日本語でもいい場面なのに英語を選んでないか、
ここは一回考えてもいい。

今日からどうする？

まずはこれだけでいいと思います。

最初だけ、日本語を添える。

「公開（ローンチ）」
「日程変更（リスケ）」
「まとめ（サマリー）」

これだけで、新しい人も迷わないし、
クライアントも置いていかれない。

あとは、

迷ったら日本語。

これでだいたい外れないです。

ローンチって言いたくなるけど、公開でいいときも多い

ローンチ、便利です。

僕も使います。

ただ、毎回じゃなくていい。

ちゃんと伝わるなら、日本語でいい。

Webディレクター、アルファベット好きがちです。

だからこそ、

「それ、日本語でよくない？」

って一回だけ思い出す。

それだけで、会話がちょっとスムーズになります。

会議って、だいたいこういう流れになります。

その場の空気はいいんですよね。
前向きだし、誰も否定しないし、ちょっとチーム感も出る。

僕もこの流れ、嫌いじゃないです。

むしろ最初は普通に乗ります。
「いいですね、それやりましょう。」って、一回は言います。

ただ、そのあとで一個だけ聞きます。

「それやるなら、どれ削ります？」

ちょっとだけ空気が止まります。
でも、この“ちょっと”がないと、あとでだいたい地獄になります。

ディレクターだけ、頭の中で引き算してる

会議の場では、基本的に足し算しか出てきません。

これもやる。
あれもやる。
ついでにこれも。

でも、そのときディレクターだけは別のことを考えています。

この修正が入ると、どこまで影響が出るか。
誰の作業が増えるか。
スケジュールはどこがズレるか。

つまり、会議では足し算の話をしているのに、
頭の中では引き算を始めている。

これ、わりと毎回です。

例えば「文言ちょっと変えたいです」って一言でも、

・ワイヤー修正
・デザイン修正
・実装修正
・確認フローやり直し

くらいまでは普通に見えます。

周りは“1個の変更”に見えているけど、
ディレクターには“連鎖”で見えている。

このズレがある状態で会議が進むので、
何も言わないと、あとでだいたい詰みます。

正直、全部やるのも嫌いじゃない

ここ、ちょっと誤解されがちなんですけど。

僕、別に「全部やる」のが嫌なわけではないです。

できるならやりたいし、
その方が完成度が上がることも多い。

ただ、それをそのまま受けると、
あとで自分が一番困るのも知ってます。

誰の作業が増えるか、だいたい想像つくんですよね。

デザイナーが戻されて、
エンジニアが手戻りして、
確認が増えて、
スケジュールがズレて。

で、その中に普通に自分も入ってる。

だったら、一回だけ立ち止まる。

それだけです。

「削りましょう」じゃなくて、「どれ優先します？」

ここで言い方の話です。

「削りましょう」って言うと、ちょっと強いです。
ブレーキ役っぽく見える。

でも、

「どれ優先します？」

って聞くと、意外と普通に通ります。

これ、やってることは同じなんですけど、印象が全然違う。

こっちは否定してない。
ただ選んでもらってるだけ。

このときに使ってる考え方が、いわゆるKPIです。

KPI（Key Performance Indicator）
→「何が達成できれば成功か」を決める指標

例えば、

・問い合わせ数を増やすのが目的
→フォーム周りは優先

・ブランド認知を上げる
→ビジュアルは優先

こういう軸があると、「どれ削るか」が自然に決まります。

逆にここが曖昧だと、全部大事に見える。
だから全部やるしかなくなる。

「どれ優先します？」って聞くと、
あとでスケジュールを無理やり調整する回数も減ります。

自分が楽になるためにやってる

ここ、ちょっと本音です。

この「どれ優先します？」ってやつ、
別にチームのためだけじゃないです。

普通に、自分が楽になるためにやってます。

後から調整するより、
その場で決めてもらった方が早い。

無理なスケジュールをあとで修正するより、
最初に整理した方がラク。

結果的に、

・手戻り減る
・調整減る
・説明減る

で、ちゃんと回る。

しかも、なんか仕事できるっぽく見えます。

わりとコスパいいです。

今日からどうする？

いきなり「削りましょう」は言いづらいと思います。

なので、まずはこれだけでいいです。

「どれ優先します？」

これを一回だけ聞く。

余裕があれば、

「全部対応も可能ですが、スケジュールかコストに影響出ます」

この一言を前に置く。

これだけで、会話が変わります。

ちゃんと断ると、むしろ現場は回る

「全部やる」って、優しさです。

でも、優しさだけだと現場は回らない。

どこかで線を引く必要があります。

そのときに、強く断る必要はないです。

ちゃんと選んでもらえばいい。

僕は今日も普通に言います。

「それやるなら、どれ優先します？」

最初はちょっとだけ空気が止まります。

でも、その“ちょっと”のおかげで、
後ろがだいぶ楽になります。

この一言、ディレクターなら一度は使ったことあると思います。

そしてだいたいこうなります。

クライアント
「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ディレクター、アルファベット好きがちです。

だからこそ、ちゃんと伝わる使い方をしていきたい。

それだけで、現場はだいぶスムーズになります。

ディレクターの仕事って、基本ずっと画面です。

Slackを見て。
ドキュメントを見て。
Figmaを見て。
GAを見て。

ずっと画面。

だからなのか、考えごとがまとまるのは机の前ではありません。

駅まで歩いているとき。
コンビニに行くとき。
自転車で帰っているとき。

こういう移動の時間に、急に整理されます。

「あ、あの導線こう直せばいいかも。」
「CTAの動詞これ弱いな。」
「この提案、順番変えた方が伝わるかも。」

机で唸っているときより、外を移動しているときの方が頭が動く。

これ、ディレクターあるあるだと思います。

僕の場合、その時間を作っているのが自転車です。

普段は、いわゆる「ちょっとだけ高め」の自転車に乗っています。

自宅から駅まで。
会社まで。
スーパーまで。

数分の移動です。

でもこの時間、意外といい。

そして最近、ちょっと思っています。

ロードバイク、欲しいな。

ディレクターの頭は、意外と移動中に動く

ディレクターって、机の前で仕事しているイメージが強いと思います。

実際そうです。
ほぼずっと座っています。

でも、考える仕事って意外と「机の外」で進みます。

歩いているとき。
移動しているとき。
ぼんやりしているとき。

画面を見ているときは、情報が多すぎるんですよね。

通知も来る。
チャットも来る。
タブも増える。

だから逆に、少しだけ頭が空く時間があると、思考が整理される。

僕の場合、それが自転車の移動時間です。

自転車に乗っていると、スマホは見ません。
当然ですが。

だから頭の中だけで考えます。

すると不思議なことに、さっきまでまとまらなかったことが整理される。

ディレクターの仕事って、半分くらいは「考える仕事」です。

導線どうするか。
構成どうするか。
提案どうするか。

だから、思考が動く時間って結構大事なんですよね。

案件で自転車メーカーをやったら、世界が変わった

ロードバイクが気になり始めたのは、実は案件がきっかけです。

少し前に、自転車メーカーの案件をやりました。

そのとき初めて知りました。

ロードバイクって、結構高い。

普通に10万とかします。
20万とかも普通にある。

最初に見たときは、正直思いました。

「PC買えるじゃん。」

ディレクターの頭ってこうなるんですよね。

20万の自転車。
↓
20万のPC。
↓
PCの方が作業速くなる。

みたいな比較を始めてしまう。

だから、そのときは「へー」で終わりました。

でも案件が終わったあと、不思議なことが起きました。

街でロードバイクが目に入るようになったんです。

通勤途中。
川沿いの道。
信号待ち。

よく見ると、結構走っています。

しかも、案件で見たモデルと同じやつに乗っている人がいる。

「あ、これサイトに載ってたやつだ。」

気づくと、ちょっと気になるようになっていました。

ディレクターの「欲しいもの」はだいたい仕事とつながる

ディレクターの欲しいものって、面白いです。

人によって全然違う。

速いPCが欲しい人もいる。
大きいモニターが欲しい人もいる。
いい椅子が欲しい人もいる。

どれも共通しているのはこれです。

仕事がちょっと楽になるもの。

ディレクターの仕事って、ずっと小さいストレスと戦っています。

画面が小さい。
キーボードが打ちにくい。
会議が多い。

そういうものを少しずつ減らしたくなる。

僕の場合、それがたぶん「移動時間」です。

移動しているときに考えがまとまる。

だったら、その時間をもう少し良くしたい。

そう思い始めると、ロードバイクがちょっと気になってくる。

もちろん、まだ買っていません。

価格を見ると、やっぱりちょっと考えます。

でも、もし買ったらどうなるんだろう。

ちょっと想像します。

もしロードバイクを買ったら

もしロードバイクを買ったら、たぶん最初にやることはこれです。

朝、少し早く起きて走る。

川沿いの道を走って。
少し遠くのカフェまで行って。
コーヒーを飲む。

その間、たぶんずっと考えています。

あの案件の導線。
あの記事の構成。
あのCTAの言い方。

ディレクターの頭って、完全にオフにはならないんですよね。

でもそれは、そんなに嫌なことでもありません。

むしろ、ちょっと面白い。

「あ、これ改善できそう。」

そういう瞬間があると、少し嬉しい。

ロードバイクは、たぶんただの移動手段じゃなくて、
思考を整理する道具になる気がしています。

今日できること

ロードバイクは、すぐには買えません。

でも今日できることはあります。

移動時間を、ちょっと大事にすることです。

例えば。

・駅まで少し遠回りする
・スマホを見ない
・考えごとを一つだけ持って歩く

それだけで、意外と頭は整理されます。

ディレクターって、ずっと画面を見ている仕事です。

だから、画面を見ない時間が結構大事。

僕にとってそれが、自転車です。

そしていつか、ロードバイクを買うかもしれません。

そのときはたぶん、またこう思います。

「これ、いい買い物だったかも。」

「……導線って、どこですか？」

わかる。
その反応、めちゃくちゃ正しいです。

Webディレクターの世界では「導線」という言葉が頻繁に出てきます。
でも、実はこれ、かなり抽象的な言葉です。

だから新人は迷子になる。
ページは見ている。
リンクも見ている。
でも、何をどうチェックすればいいのかわからない。

そして結果、こうなります。

「とりあえず全部見ました。」

うん。
それ、僕も新人のときやっていました。

今日はその話です。
新人が最初に覚えると強い「導線の見方」。

これは新人教育というより、先輩の準備の話でもあります。
4月の現場がちょっと楽になる、そんな話をします。

「全部見ました」がちょっと不安になる

4月。
なぜか質問が一気に増えます。

Slackの通知が止まらない。
同じ説明を何回もする。
「これどうすればいいですか？」ラッシュ。

あるあるです。

新人が悪いわけではありません。
むしろ真面目です。
ちゃんと確認しようとしている。

でも、質問の内容がこうなりがちです。

「このページ、問題なさそうです。」
「リンクは全部押しました。」
「特に変なところはなかったです。」

うん。
でもそれ、導線チェックではない。

ページ単体の確認になっています。

新人は、だいたい「画面」を見ています。
でも先輩は「流れ」を見ている。

この差が、質問ラッシュの原因だったりします。

新人は真面目にチェックしている。
でも先輩からすると、見てほしいポイントが違う。

だから会話がすれ違う。

「あー、わかる…」と思った人。
多分いま、現場にいますね。

新人が入ると何が起きるのか

新人が入ると、現場では3つの差が発生します。

知識の差。
用語の差。
仕事の見え方の差。

知識の差はわかりやすいです。
CMSの操作。
公開フロー。
デザイン確認。

でも、意外と大きいのが「仕事の見え方」です。

新人はページを見ます。
先輩は流れを見ます。

新人
「このページ大丈夫です。」

先輩
「そのページに来る人、どこから来る？」

新人
「……？」

こういう会話、あります。

新人は間違っていない。
ただ、見ている範囲が違う。

だから僕は新人にこう言います。

「ページは点。導線は線。」

点をチェックするのは大事です。
でもユーザーは点では動かない。

人は必ず“流れ”で動く。

検索結果 → 記事 → CTA → 申込み
広告 → LP → フォーム
SNS → 記事 → 商品ページ

この流れを見ないと、問題は見えない。

新人が迷子になるのは当然です。
誰も最初にこの話をしないから。

だから先輩の準備が効く

ここで大事な話です。

新人教育の話ではありません。
先輩の準備の話です。

新人にいきなり「導線を見て」と言っても、無理です。
見えないものは見えない。

だから先輩がやることはシンプルです。

導線を言語化しておく。

例えば、こうです。

「この記事の役割はこれ。」

・検索流入を取る
・サービスページに送る
・問い合わせにつなぐ

これを先に伝えるだけで、新人の見方が変わります。

ページの目的がわかると、チェックの視点が変わる。

「リンクあるか？」ではなく
「次に進みやすいか？」

これはかなり大きな違いです。

新人が導線を理解できないのは能力の問題ではありません。
前提が共有されていないだけ。

だから先輩の準備が効きます。

僕が新人にする具体策

僕が新人に最初にやることがあります。

「このサイト、3分で説明して。」

これです。

新人はだいたいこう言います。

「会社紹介のサイトです。」
「サービスを紹介しているサイトです。」

間違っていない。
でも、もう一歩。

そこでこう聞きます。

「ユーザーはどこから来る？」

すると少し考え始めます。

検索。
広告。
SNS。

次に聞きます。

「来た人は、最終的に何する？」

問い合わせ。
資料請求。
申し込み。

ここまで来ると、導線が見え始めます。

僕はよくホワイトボードにこう書きます。

検索
↓
記事
↓
サービスページ
↓
問い合わせ

新人はこの図を見ると理解します。

「あ、流れなんだ。」

そう。
導線は図で理解すると一気にわかる。

ここからチェックの視点を教えます。

記事からサービスページにリンクある？
そのリンク目立つ？
クリックしたあと迷わない？

新人のチェックはここで変わります。

今日からどうする？未来の自分が楽になる準備

完璧な先輩になる必要はありません。

でも、1つ準備しておくと未来の自分が楽になります。

おすすめはこれです。

導線メモを1枚作る。

内容はシンプルでいい。

流入
検索 / 広告 / SNS最初のページ
記事 / LP次の行動
サービスページゴール
問い合わせ / 資料請求

これを新人に渡すだけで、質問の質が変わります。

「このページ大丈夫です」
から

「記事からサービスページの導線弱いかもです」

に変わる。

これはかなり楽です。
Slackの通知も減ります。

新人教育って、全部を教えることじゃない。
見る視点を1つ渡すこと。

導線の見方は、その最初の一歩としてかなり強いです。

そして何より、未来の自分が楽になります。

来月の自分。
ちょっとだけ感謝すると思います。

このボタンを見るたびに、僕は少しだけそわそわします。
悪くない。
間違ってもいない。
でも、どこか弱い。

Webディレクター、日本語で迷子になりがちです。
特にCTA。
専業でUIやUXをやっているわけじゃないのに、ある日突然「ボタン文言どうします？」と振られる。

そして検索する。
「CTA 文言 コツ」。
「ボタン テキスト 正解」。
わかる。
これ、あるよね。

今日はその話です。
CTAの動詞が弱いと、なぜ落ち着かないのか。
そして、僕がどう考えているか。

あるある。動詞が迷子

案件の最終調整フェーズ。
デザインはほぼ確定。
構成もOK。
あとはボタン文言。

「資料請求はこちら」
「お問い合わせはこちら」
「詳しくはこちら」

無難。
安全。
怒られない。

でも、なんかモヤっとする。

「こちら」って、どこ。
「詳しく」って、何を。
動詞がふわっとしている。

それでも、こう言われがちです。
「とりあえず一般的なのでいいんじゃないですか？」

一般的って、何だろう。
それ、成果に効く？

僕はこういうとき、頭の中で分解を始めます。

ユーザーは今、何をしたいのか。
そのボタンを押すと、何が起きるのか。
その動作は“見る”なのか、“申し込む”なのか、“試す”なのか。

CTAは、ユーザーの次の一歩を言語化する場所です。
だから動詞が弱いと、行き先がぼやける。

あるあるですが、ボタン文言を最後に回すと、だいたいこうなります。
「まあ、これでいいか。」

そして僕だけが落ち着かない。

何がそんなに引っかかるのか

引っかかる理由はシンプルです。
CTAは行動の宣言だからです。

「詳しくはこちら」は、行動になっていない。
情報の方向だけ示している。

一方で、
「料金プランを見る」
「無料で試す」
「30秒で申し込む」

これは動詞が立っている。
押した先の未来が具体的です。

僕は導線を追う癖があります。
ボタンを見ると、必ずその先を想像します。

このボタンを押した人は、どんな気持ちになるか。
期待値は上がるか、下がるか。
押した瞬間に“やった感”はあるか。

CTAの動詞が弱いと、期待値が設計されていない感じがします。
「とりあえず次へどうぞ」と言っているだけ。

それ、もったいない。

もう一つあります。
責任がぼやける。

「詳しくはこちら」は、誰の行動なのかが曖昧です。
でも「資料をダウンロードする」だと、主体がはっきりする。

CTAは小さいけれど、ページ全体の覚悟が出る場所です。
だから、僕は落ち着かない。

学問上／文法上の整理

ここで少し整理します。
「詳しくはこちら」は文法的に間違いではありません。
慣用表現です。

でも問題は文法ではなく、機能です。

CTAの役割は何か。
それは行動を促すこと。

日本語は主語を省略しやすい言語です。
だからこそ、動詞が曖昧でも成立してしまう。

しかし、UIでは“成立する”だけでは足りない。
“迷わせない”ことが重要です。

動詞の種類も整理できます。

・認知系動詞：見る、知る、確認する
・取得系動詞：ダウンロードする、受け取る
・参加系動詞：申し込む、予約する
・体験系動詞：試す、始める

「詳しくはこちら」は、このどれにも属さない。
抽象度が高すぎる。

学問上の正誤よりも、
ユーザーの次の動作が具体かどうか。

ここがポイントです。

実務ではどう扱われているか

とはいえ、現実は理想通りにいきません。

「前からこの文言だから変えなくていいです。」
「法務的にこの表現しか無理です。」
「デザイン的に文字数が入らないです。」

あるあるです。

実務では、正解より合意が優先されることもある。
学問上の正しさより、社内の安心感が勝つこともある。

だから僕は、全部を戦わないようにしています。

いきなり「これ弱いです」とは言いません。
代わりにこう言います。

「もし成果をもう一段上げるなら、動詞を具体化してみるのもありかもしれません。」

少し柔らかく提案する。
そして、テストの話をする。

「ABで試しませんか？」

これが一番平和です。

CTAは思想の戦いではなく、検証の話に持ち込む。
すると空気が変わる。

Webディレクターは、日本語で迷子になりがちです。
でも、検証という武器がある。

今日からどうする？

ここから具体です。

まず、自分のCTAを3つに分類してみてください。

1. 何が起きるか明確か。
2. 行動が具体か。
3. ユーザー目線か。

そして、今すぐ置き換えられる例をいくつか。

「詳しくはこちら」
→ 「料金プランを見る」

「お問い合わせはこちら」
→ 「相談してみる」

「資料請求はこちら」
→ 「無料で資料を受け取る」

「会員登録」
→ 「無料で始める」

ポイントは3つです。

・動詞を具体にする。
・できればベネフィットを入れる。
・押した先とズレない。

そしてもう一つ大事なこと。

困ったら、先輩や上司に相談してください。
これ、本気です。

一人で悩み続けるより、
「この動詞、弱くないですか？」と聞くだけで視点が増えます。

もしあなたがUI専業じゃないディレクターだったら、CTAで迷うのは当たり前です。
でも、それを放置しないことが差になります。

CTAは小さい。
でも、CVRに効きます。

だから僕は今日も、ボタンを見るたびに考えています。

「本当に、それでいい？」

落ち着かない。
でも、それでいいと思っています。

僕の頭の中では、だいたいこういう声が出ています。

「これ、こうしたらもっと良くない？」

職業病です。
完全に。

普段は改善提案を仕事にしています。
検索意図を見て、導線を分解して、CVRの落ちどころを探して、小さな改善を積み重ねる。

でも困るのは、仕事が終わっても止まらないことです。
改善のスイッチが、オフにならない。

今日はそんな話です。
Webディレクターって、だいたいこんな感じ。
そして、その厄介な癖が、実はちゃんと仕事に返ってきているという話です。

コンビニで勝手にABテストを始める

まずコンビニです。

新商品の棚に立ち止まると、つい視線の流れを追ってしまいます。
どの高さに何があるか。
一番売りたい商品はどこに置かれているか。

気づいたら頭の中でこう考えています。

「これ、右端に“期間限定”のPOP置いたらCVR上がるのに。」
「この価格表記、フォントもう少し太くしたほうがいいのでは。」
「そもそも棚の左から右に視線が流れる前提で並べてるけど、ここ通る人の導線逆じゃない？」

買い物に来ただけなのに。
勝手に仮説を立てています。

そして怖いのが、心の中でABテストまでやっていることです。

A案：価格訴求。
B案：限定訴求。
C案：ランキング表示。

どれが刺さるか、勝手に想像している。

これ、あるよね。

でもこの癖、実は悪くないです。
なぜなら「観察→仮説→想像検証」の流れを、日常で回しているからです。

改善提案って、特別な時間にだけやるものじゃない。
普段から“気になる”状態をキープしていることが、提案の質を底上げしている。

今すぐできる一手としては、コンビニで一つだけやってみてください。

「一番目立つのはどれか？」を3秒で答える。

これだけです。
目立つ理由を言語化できたら、もう立派なトレーニングです。

レストランで導線が気になる

次は飲食店です。

席に案内されて、メニューを開いた瞬間。
僕は料理ではなく、構造を見ています。

最初に目に入るのは何か。
写真の大きさの差は何か。
セットメニューはどこにあるか。

「これ、最初のページで単価上げにいってるな。」
「ドリンクの導線弱いな。」
「ここ、写真1枚差し替えるだけで印象変わるのに。」

完全に余計なお世話です。
でも止まらない。

この癖が仕事に返ってくる瞬間があります。

それは「離脱理由を想像できる」ということです。

飲食店で迷うときの気持ち。
どこから頼めばいいかわからない微妙なストレス。
価格帯が読めない不安。

その感覚を体で知っていると、Webでも気づきやすい。

導線が弱いページは、だいたい“迷い”を生んでいます。
ユーザーは怒らない。
ただ離脱する。

だから僕は、飲食店で迷ったときに、1つだけやっています。

「今、なぜ迷ったか」をメモする。

本当に一言でいいです。
価格帯が見えない。
写真が小さい。
おすすめがわからない。

これ、提案のネタになります。

家族との会話で改善提案をしてしまう

ここが一番まずいところです。

家族が「このアプリ使いづらい」と言った瞬間。

「どこが？」
「どのタイミングで？」
「それって最初の設計の問題じゃない？」

やめろ、武。
今は家族の時間だ。

でも分解癖が出る。

ただ、ここで気づいたことがあります。
相手は解決策を求めていないことがある。

これは仕事にも通じます。

クライアントが「使いづらい」と言ったとき。
すぐに改善案を出すより、まず感情を受け止める。

「なるほど、そこストレスですよね。」

改善提案をする人ほど、いきなり解決に走りがちです。
でも、共感が先にないと提案は刺さらない。

プライベートでちょっと失敗することで、仕事では慎重になれる。
これ、わりと本当です。

Netflixでサムネイルを研究している

完全にオタクですが、サムネイルも見ています。

同じ作品でも、ユーザーごとに違うビジュアルが出る。
あれ、最高に面白い。

「この人にはラブ要素を見せるんだ。」
「こっちはアクション推しだな。」

つまり、期待値のチューニングをしているわけです。

これ、Webでも同じです。

検索意図によって、見せるべき要素は変わる。
全部を一度に見せなくていい。

トップで全部語らなくてもいい。

今すぐできる一手としては、自分のサービスページを1つだけ見直してみてください。

「誰に向けて書いているか」を一言で言えるか。

曖昧なら、改善余地ありです。

改善癖は、実は“楽しみ”でもある

ここまで読むと、ずっと仕事してるみたいに見えますよね。

でも、僕はこれを面白がっています。

「あ、ここ工夫してるな。」
「これうまいな。」
「ここ、もったいないな。」

世の中が全部ケーススタディに見える。

それって、わりと楽しいです。

Webディレクターって、だいたいこんな感じです。
日常が教材になる。

そして、改善提案って大きな改革じゃなくていい。

小さな一手でいい。
5分でいい。
火を消さないことが大事。

今日できることはこれです。

1. コンビニで一番目立つ商品を言語化する。
2. 飲食店で迷った理由を一言メモする。
3. 自分のページを“誰向けか”で見直す。

それだけで、観察の筋肉は鍛えられます。

“こうしたらいいのに”が止まらない人へ

もしあなたが、日常でつい改善案を考えてしまうなら。

安心してください。
それ、向いてます。

でも一つだけ忘れないでください。

全部を直さなくていい。

全部を提案しなくていい。

小さく、続ける。

Webの仕事って、派手じゃないです。
でも、じわじわ効いてくる。

改善はクセになる。
でもそのクセは、ちゃんと武器になります。

だから今日も僕は、コンビニで棚を眺めながら思っています。

「これ、こうしたらもっと良くない？」

止まりません。
でも、それでいいと思っています。

新しい施策は出ない。
テストも回らない。
「今はとりあえず回す」が合言葉になる。

気づくと、CVRの微妙な下落を「季節要因かな」で片付けている。
忙しいから仕方ない。
来月やろう。
4月になったら落ち着くはず。

たぶん、毎年同じことを言っています。

今日はそんな、年度末あるあるの話です。
でもただの共感で終わりません。
こっそり“一点見直し”の話も混ぜます。

軽く読めて、でもちゃんと使えるやつです。

改善が止まるのは、悪意じゃない

忙しいと、改善は止まります。
これは怠けでも甘えでもありません。

単純に、優先順位が押し出される。

公開が先。
納品が先。
調整が先。
火消しが先。

改善は「今すぐ死なない」カテゴリーに入れられます。
だから後ろに回る。

そして年度末は、「今すぐ死ぬ案件」が多すぎる。

ここで起きがちなのが、改善を“ゼロか百か”で考えてしまうことです。
A/Bテストを組むなら、ちゃんと設計したい。
導線を直すなら、全体を触りたい。
コピーを変えるなら、トンマナから見直したい。

それ、今の3月にやりますか？

やれないですよね。

だから止まる。

でも実は、改善ってもっと雑でいい瞬間があります。
年度末は特にそう。

完璧な改善ではなく、「落とさない改善」に切り替える。

この発想に変えるだけで、止まりにくくなります。

CVRは“全体”より“一点”を見る

忙しいときにやりがちなのが、「全体を見ようとする」ことです。

全体CVR。
全体流入。
全体売上。

でも年度末って、全体がブレやすい。
季節要因もある。
広告予算も変わる。
施策も混ざる。

だから、全体を見ていると混乱します。

ここでやるのが、“一点見直し”。

例えば、申し込みボタンの直前の一文。
FAQの最初の質問。
フォームの最初の入力項目。

どこでもいい。
一箇所だけ。

「ここ、今のままでいいか？」と見る。

忙しいと、意外とここが放置されています。
前回の改善のまま。
去年のまま。
なんなら初期設計のまま。

一箇所なら、5分で見直せます。
一箇所なら、会議もいらない。

その一手で、CVRは意外と落ちにくくなる。

全部やらなくていい。
一点だけ触る。

年度末は、これで十分戦えます。

“改善できない罪悪感”を手放す

改善が止まると、地味に罪悪感がたまります。

「ああ、今月テスト回せなかったな」
「レポートに改善ネタ書けないな」

でも、3月は例外です。
回すこと自体が価値。

ここでやるべきは、「ゼロにしない」こと。

大きな施策はできなくてもいい。
小さな見直しを残す。

例えば、ヒートマップを一回だけ見る。
直帰が高いページを一枚だけ読む。
問い合わせ理由を三件だけ読む。

全部じゃなくていい。
三件でいい。

そうすると、不思議と感覚が戻ります。
「あ、ここ引っかかってるな」と気づける。

改善って、作業というより観察です。
観察が止まると、改善が止まる。

だから年度末は、「観察だけは止めない」。

これ、地味ですが効きます。

一点見直しのコツは“言い切りを疑う”

一点見直しでよくやるのが、「言い切りを疑う」ことです。

「最短で成果が出ます」
「誰でも簡単に」
「今すぐ解決」

こういう言葉、忙しいとそのままになります。

でもユーザーは、年度末だろうがなんだろうが冷静です。
言い切りが強すぎると、逆に引きます。

だから、ほんの少しだけ調整する。

「最短で成果を目指せます」にする。
「はじめての方でも使いやすい」にする。
「まずは無料で試せます」にする。

トーンを整えるだけ。

これ、A/Bテストじゃないです。
大改革でもない。

でもCVRの落ちを防ぐ“守りの一手”になります。

忙しいときは、攻めなくていい。
崩れないことを優先する。

一点見直しは、防御です。

「来期にしましょう」と言われたとき、どうするか

ここで、ちょっとリアルな話をします。

言い切りを弱めたい。
トーンを整えたい。
CTAを少し変えたい。

でもクライアントからこう言われることがあります。

「いったんそれは今じゃなくて、来期にしましょう。」

あるあるです。

理由も分かります。
今はリニューアルで手一杯。
予算も締め。
稟議も動かない。

でも、僕らは知っています。
“来期”はだいたい忘れられる。

タスク管理表から消える。
議事録の奥に沈む。
そして半年後、「そんな話ありましたっけ？」になる。

でも、CVを上げたいという要望は、どのクライアントにもあります。
そこは共通。

だから僕は、正面から「やりましょう」とは言いません。

代わりに、こう言います。

「では、大きな改修は来期に回して、
今回は文言だけ、影響の小さい範囲で触るのはどうでしょう。」

ポイントは、“規模を縮める”こと。

デザイン変更ではなく、テキスト調整。
導線変更ではなく、順番の入れ替え。
全面改善ではなく、一文修正。

しかも、「CVを上げるため」ではなく、
「ユーザーの誤解を減らすため」と言い換える。

これ、意外と通ります。

一度、「来期」と言われた案件で、僕はCTAの一文だけをその場で提案しました。
「最短で成果が出ます」を、「最短で成果を目指せます」に。

正直、地味です。

でも翌月、CVRがわずかに改善しました。
大きな変化ではありません。

ただ、その数字が“次の提案の材料”になった。

「あのときの文言修正で微増しているので、
来期はもう一段見直してみませんか。」

こうやって、後回しを完全な消滅にしない。

年度末は、全部を通そうとしない。
でも、火は消さない。

これが、僕なりの立ち回りです。

まだ間に合う

年度末進行って、毎年ちょっと笑ってしまいます。
「ああ、またここで詰まったな」と。

でも同時に、毎年思います。
「まだ間に合うな」と。

大きな改善はできないかもしれない。
でも一点ならできる。

今この瞬間に、ページを一枚開いて。
CTAの一文を見る。
フォームの順番を見る。
FAQの最初の質問を見る。

それだけでいい。

改善って、特別なプロジェクトじゃない。
忙しい合間にできる、小さな観察と修正です。

年度末は、だいたいここで詰まる。
改善が止まりがちになる。

でも、ゼロにしなければ勝ち。

一点見直しを続けていれば、4月にちゃんと伸ばせます。

面白いのは、こういう地味な積み重ねが、あとで効いてくるところです。

大改革をした記憶より、
「あのときボタン文言変えたな」のほうが、数字に残ることもある。

忙しいと、改善は止まりがち。
だからこそ、一点だけ。

今なら、まだ間に合います。

そんな時期に、僕が毎年思うことがあります。
「今は、タイトルより締切だな」と。

もちろん、いいタイトルは大事です。
SEO的にも、ブランド的にも、モチベーション的にも。
でも3月は、完成していることのほうが価値を持つ瞬間がある。

今日はそんな、年度末のちょっとリアルな話です。
HOWTOと気づかないHOWTOを、こっそり混ぜていきます。

完璧な企画より、間に合った企画が強い

年度末になると、不思議な現象が起きます。
「もう少しブラッシュアップしたい」が、だいたい通らなくなる。

普段なら、「タイトルをもう一回練り直そう」と言える。
構成も詰められる。
競合も見直せる。

でも3月は違います。
提出日が先にある。
公開日が先にある。
契約の区切りが先にある。

この時期に強いのは、完成度よりも進行力です。

締切を守る。
公開を落とさない。
更新を止めない。

これ、派手じゃないです。
でも、年度末はここが一番評価されます。

だから僕は、タイトルを考えすぎて止まりそうになったら、まずこう考えます。
「今日、何を終わらせるか？」

タイトルは、60点でもいい。
公開してから直せばいい。

締切は、直せない。

これ、ちょっとドライに聞こえるかもしれませんが、現場ではかなり大事です。
締切を守る人は信頼される。
信頼されると、次の自由度が上がる。

結果的に、いいタイトルを考えられる余裕も戻ってきます。

年度末は“決める回数”を減らす

3月は、やることが増えます。
でも時間は増えません。

ここでハマりやすいのが、「決めること」にエネルギーを使いすぎることです。

タイトルどうしよう。
構成どうしよう。
ビジュアルどうしよう。

悩み始めると止まりません。

だから僕は、年度末だけは決める回数を減らします。

タイトルは型を使う。
構成はテンプレを使う。
過去に反応がよかったフォーマットを流用する。

ゼロから作らない。

これ、手抜きではありません。
エネルギー配分です。

年度末は、創造よりも完走が大事な局面が多い。
だったら、創造は少し抑える。

「これ、前にもやったな」という構成でもいい。
「ちょっと普通だな」というタイトルでもいい。

代わりに、公開まで走り切る。

そのほうが、現場は回ります。

先にやっておくと楽になること

ここで、ひとつだけこっそりやっておくと楽になることがあります。

3月に入る前に、やることを書き出す。
しかも、「理想」じゃなく「現実」で。

今月中に絶対落とせないもの。
調整が発生しそうなもの。
外部依存があるもの。

これを、先に見える化しておくだけで、かなり違います。

そしてもう一つ。
「削れるもの」を決めておく。

やれたらやる。
余裕があればやる。
なくても致命傷ではない。

このリストを持っておくと、締切優先モードに入りやすい。

年度末に大事なのは、全部やることではなく、落とさないことです。

全部完璧にやろうとすると、どこかで止まる。
止まると、連鎖する。

だから、先に優先順位を決めておく。
タイトルより締切を選ぶ瞬間を、あらかじめ想定しておく。

まだ間に合います。
3月が本気を出す前なら、今が仕込みどきです。

面白いのは、ここから

ここまで読むと、なんだか守りの話に聞こえるかもしれません。

でも実は、ここからが面白い。

締切を守れる現場は、余白が生まれます。
余白が生まれると、実験できる。

年度末をうまく走り切ったチームは、4月に強い。

「あの時ちゃんと回せた」という自信があるからです。

僕は毎年、3月に小さなチェックリストを持っています。

今日、終わらせたか。
止めていないか。
人のボールを放置していないか。

これを回しながら、時々ちゃんと笑います。
「今年もこの季節来たな」と。

バタバタしているけど、嫌いじゃない。
むしろ、ちょっと好き。

みんなが本気で走っている感じが、現場の熱量を上げるからです。

タイトルは、あとでいくらでも直せる

最後にひとつだけ。

タイトルは、あとでいくらでも直せます。
SEOも、リライトも、A/Bテストもできる。

でも締切は、過去に戻せません。

年度末は、判断の軸をシンプルにします。

今、出すか。
出さないか。

磨くか。
間に合わせるか。

そのときに、「締切」を選べる人は、強いです。

しかも、ちゃんと後で磨けばいい。
4月にリライトすればいい。
落ち着いてから勝負すればいい。

今は、走る時期。

タイトルより締切を優先する。
それは妥協ではなく、戦略です。

まだ間に合います。
今日の一つを終わらせれば、それだけで現場は少し軽くなる。

年度末は忙しい。
でも、ちゃんと笑いながら走れる。

そのほうが、たぶんいい仕事になります。