Webディレクターの仕事内容とは？向いてる人・きつい部分を、現役17年目が全部書く

「Webディレクターって、結局何をする仕事なんですか」

何度も聞かれた。そのたびに、うまく答えられない。「進行管理です」だと嘘っぽい。「まあ、なんでもやります」だと何も言っていない。

だから、ちゃんと書く。

デザイナーとして業界に入って17年。そのうち11年は、ディレクターかPMの側でやってきた。求人票の「業務内容」に並んでいる言葉じゃなく、実際に自分の一日が何に溶けているかを書く。きつい部分も隠さない。

一言で言うと「監督」

Webディレクターは、Webサイトを作らない。

作るのはデザイナーとエンジニアとライターだ。ディレクターは、何を作るかを決めて、作れる人に渡して、最後まで責任を持つ。サッカーで言えば監督だ。自分でゴールは決めない。誰を出して、どう戦うかを決めて、負けた時に前に出る。

求人票の言葉に直すと、だいたいこの4つになる。

• 企画・要件整理：クライアントの要望と目的をヒアリングして、サイトの方向性を決める

• 進行管理：スケジュールを組んで、納期通りに進むよう管理する

• 品質チェック：出てきたものが要件やUI/UXの基準を満たしているか確認する

• チーム調整：デザイナーやエンジニアに指示を出して、現場を回す

間違ってはいない。ただ、これを読んで仕事の中身がわかる人はいないと思う。自分もわからなかった。

自分の一日で、手を動かしている時間はほぼない。打ち合わせ、電話、Slack、確認、判断。ひたすらそれだ。

これを聞いて「楽そうだな」と思う人がいる。逆だと思う。作る仕事には「できた」という終わりがある。決める仕事には、それがない。

仕事内容を5つに分けると、こうなる

1. 何を作るかを決める（要件を固める）

プロジェクトの出発点で、一番重要な工程だ。

クライアントは「サイトをきれいにしたい」と言う。でも本当に欲しいのは、来店客か、応募か、問い合わせかだ。誰に向けたサイトなのか。何を達成したいのか。そこを詰めて、明確な言葉にする。

目的が決まったら、実現に必要なページと機能を洗い出す。サイト全体の構成図（サイトマップ）と、各ページのレイアウト設計図（ワイヤーフレーム）を作る。それを要件定義書としてドキュメントに落として、クライアントと制作チームで「完成形のイメージ」を揃える。ここを飛ばした案件は、後半で必ず揺れる。

居酒屋チェーンのリニューアルでは、見た目の話をいったん置いた。「どうすれば来店につながるか」だけを設計した。結果、PVは120%に伸びた。デザインの力で伸びたんじゃない。決める順番を変えただけだ。

そして、この工程にはもう一つの目的がある。クライアントの信頼を勝ち取ることだ。

提案したり、要件を詰めるやりとりが、クライアントと最初にやるセッションになる。準備の仕方、説明の運び、プレゼンの組み立て、ミーティングのファシリテーション。もちろん出すサイトマップとワイヤーフレームのクオリティも。全部見られている。

ここで「この人、大丈夫かな」と一度でも思わせたら、その案件は後半で炎上する。断言できる。

だから自分は、一番最初の提案書を、これでもかというくらい緻密に作る。

提案書はだいたい30ページくらいが普通だった。ある案件では、100枚近く作った。枚数を自慢したいわけじゃない。そこまで入れるものがあった、という話だ。

サイトをどう作るかだけじゃなく、作ったあとにどうやって効果を出していくのかまで書いた。このサイトのクライアントのビジネス上での役割、公開してからの打ち手、追う数字、次に仕掛けること。そこまで入れると、相手の見方が変わる。「こいつ、ディレクターだけどビジネスのこともわかってるな」と思ってもらえる。それが価値になる。

逆の経験もある。

若い頃、ビジネスをまるで理解していなかった頃は、どう頑張ってもサイトを作るだけの提案になった。すると、こう思われる。

「この人、私たちのビジネスのことをわかってないんじゃないか」 「デザインとかサイトとか、そっち側の意見しか言ってこないんだけど」

一度そう思われた案件は、しんどい。そのあと何を出しても通らなくなる。

だからディレクターには、Web制作の知識と同じくらいビジネスの勉強が要る。しかもそれは、提案書だけの話じゃない。ミーティングでの受け答え、相手の発言への返し方、話の組み立て方。全部に出る。隠せない。

2. お金と期間を引く（見積り・スケジュール）

要件が固まったら、いくらで、いつまでにやるかを引く。

デザイン・実装・テスト・修正と工程を分解して、それぞれの工数を積み上げて見積りを出す。スケジュールは公開日をゴールに逆算して組むのが基本で、ガントチャートで可視化することが多い。

クライアントの希望納期と、制作チームが無理なく高品質なものを作れる期間は、たいてい一致しない。合わない時は要件を絞り込むか、機能を段階的に出す「分割リリース」を提案するか。現実的な着地点を作るのもディレクターの仕事だ。

正直に言うと、ここは経験がものを言う。

自分の失敗を書く。スケジュールを、メンバーに確認しないままクライアントに出したことがある。

自分の感覚では、余裕のあるラインだった。これなら大丈夫だろうと思って、そのまま提出した。でも、自分に見えていない作業があった。デザイナーとエンジニアの側から見れば当然ある工程が、自分の頭の中の工程表から丸ごと抜けていた。当然、そのスケジュールは無理になった。

以来、メンバーへの確認は必須にしている。例外なし。一人で引いたスケジュールは、自分に見えている範囲でしか正しくない。

ただし、出てきたラインを鵜呑みにもしない。デザイナーやエンジニアが長めのスケジュールを出してくることもある。そういう時は「あれ、これもう少し短くできない？」と相談する。ここが経験だ。どこは縮められて、どこは縮めちゃいけないのか。それはやった量でしかわからない。

工数の出し方や見積りのフォーマットは、ある程度は仕組み化できる。でも「どうやったら早く、効果的に作れるのか」「どうやったら予算を抑えられるのか」は、型からは出てこない。とにかくやって、失敗して、なぜ外したのかを理解して、人に相談して、また考える。それしかない。

自分は今でも、チームメンバーや制作パートナーに相談してから数字を出す。一人で抱えて出した見積りより、聞いて出した見積りの方が当たり前に精度は高い。

デザイナー時代の自分は、この工程を軽く見ていた。ディレクター側に回って初めてわかった。スケジュールは、引いた瞬間にほぼ勝負がついている。無理な線を引いたら、後から誰がどれだけ頑張っても回らない。

3. デザイナーとエンジニアに渡す（ディレクション）

設計図とスケジュールが決まったら、実際に手を動かす人に渡す。

ここで「いい感じにしてください」は指示じゃない。なぜそのデザインや機能が必要なのか、どんなユーザーに向けたものなのか。背景と意図まで渡して、初めて渡したことになる。デザイナーにはビジュアルの方向性とブランドイメージを、エンジニアには機能仕様と動作条件を、それぞれが理解しやすい言葉に置き換えて、仕様書として明文化する。

そして、ここで効いてくるのが1の要件定義だ。

一次要件をクライアントと握れているかどうかで、渡し方が変わる。

握れていれば、こう言える。「ここはクライアントと完全に共通認識になっている部分だから、絶対にずらさないでほしい。それ以外は、思いっきりクリエイティブを発揮してください」

守る線と、任せる領域。これを分けて渡せると、現場は一気に動きやすくなる。

そして、握れていることは盾になる。

ただ、この盾の使い方は、正直に書いておきたい。教科書に載っている話とは、けっこう違う。

クライアントに「最初に決めたことなので、そこは変えません」と言い切る場面は、実際の案件ではほとんどない。

やっているのは、ちらつかせることだ。

そして本当に効いているのは、言われたあとじゃない。そもそも、それまでの流れと違う修正案が出てこなくなることの方だ。「最初にここを握りましたよね」という前提がお互いにあると、話が大きく振れる前に止まる。盾が抑止力として働いている時間が、いちばん長い。

それでも言われてしまったら、どうするか。正面から突っぱねはしない。合意した目的をなんとなくちらつかせながら、それでもなるべく意向に添えられる形を探す。これが現実だ。

一つ書いておく。複数の制作物が同時に走っている案件で、途中から、それまでの流れとは毛色の違う案が出てきたことがある。面白い案ではあった。ただ、その案件は「かっちりしていること」自体に価値がある種類のものだった。

ここで「できません」と全部止めるのは、簡単だけど下手だ。やったのは、やる場所を分けることだった。

実験的な見せ方が効く制作物の方で、その案を拾う。崩したくない方には入れず、オーソドックスな形で通す。そう提案して着地させた。

案件全体でクオリティを担保する。これができるのは、最初に「このプロジェクトは何のためにやるのか」を握っているからだ。握っていなければ、「担当者がそう言うので」で全部通ってしまう。

盾は、要望を跳ね返すための道具じゃない。話が変な方向に流れないように置いておく重しで、いざという時は、添いながら守るための拠り所だ。

そして、これはクライアントを守ることでもある。目的からズレたものをそのまま作れば、最後に困るのは向こうだ。質を担保したアウトプットを出すところまでを「ディレクション」する。

だから、1でクライアントの信頼を取っておくことが、ここで効いてくる。信頼のない相手からの「その方向は違います」は、ただの反抗に聞こえる。

デザイナーやエンジニアのクリエイティブを守るのも、ディレクターの仕事だと思っている。自分がデザイナーからこっち側に来て、唯一得をしたのはここだ。指示のどこが現場を苦しめるかを、体で知っている。

4. 品質と納期を守る（レビューと調整）

制作が始まったら、上がってきたものをチェックする日々になる。見る観点はだいたいこの3つだ。

• 目的やコンセプトからズレていないか（ユーザー目線・ビジネス目線）

• 仕様どおりに実装されているか

• スマホなど各デバイスで表示崩れやバグがないか

問題が見つかれば、どこをどう直すかを具体的に返す。進行中に遅延や追加要望が起きるのは珍しくないので、優先順位を組み替えたり、担当の業務量を調整したり、クライアントと早めに認識を合わせたりして着地させる。

ここで、あまり語られないことを書いておく。全部を自分の目でチェックできるディレクターは、いない。

自分はデザイナー出身だ。だから目的やコンセプトからのズレは見える。デザイン面で、あと一段ブラッシュアップできるところも見える。でも構築や実装は、自分で手を動かしてきた経験が薄い。

だから、エンジニアとの信頼関係を先に作っておく。「この人が出してくるものは、ちゃんとしている」という前提で進められる関係を作る。これは仕事の進め方の話じゃなく、日頃どう関わっているかの話だ。

そのうえで、ここはこの2〜3年ではっきり変わった。

動きがおかしい。コーディングが変な気がする。そういう時、今は全部AIに聞ける。自分もClaude Codeを実務で使っている。コードを開いて、怪しそうなところを自分でチェックできる。

昔なら「私は経験がないので、そこは完全にエンジニアにお任せです」と言えた。実際、それで通っていた。でも今はAIがある。**自分のわかる範囲は、AIを使ってでもチェックする。**それをやらずに通すのは、もう怠慢だと思う。

任せることと、丸投げは違う。最終的に品質を担保するチェック機能は、自分の側に持っておく必要がある。

5. 公開したあとの数字を見る

Webサイトは、公開して終わりじゃない。

Google Analyticsなどのアクセス解析を使って、実際のユーザーの動きを数字で見る。主に見るのはこのあたりだ。

• セッション数：どのくらいの人が来ているか

• 直帰率：見てすぐに離脱した人の割合

• コンバージョン率（CVR）：問い合わせや購入など、目標を達成した割合

• 流入経路：検索・SNS・広告のどこから来ているか

そこから「どこに問題があるか」「狙い通りの成果が出ているか」を読んで、導線を変える、コンテンツを直す、A/Bテストをかける。仮説と検証を回し続ける。

……と、教科書的にはこうなる。ここも正直に書く。

「Webサイトは公開して終わりじゃない」は、ディレクターと制作会社がよく言う言葉だ。でも実際に公開後の運用まで任せてもらえるケースは、半々くらいだ。数字を見られないまま案件が終わることは、普通にある。

それでも、知っておくべきことは変わらない。

かっこいいデザインが出来上がったからといって、狙った結果がそのまま出ることは、ほとんどない。制作時に立てた目的と狙いが、公開後に効いているのか。効いていないなら、どこが効いていないのか。どこを直すべきなのか。そこまで見に行かないと、狙った効果は出ない。

そしてこれは、クライアントにも同じ認識を持ってもらう必要がある。半年、1年という制作期間の提案とミーティングを通して、「公開してからが本番です」という前提を一緒に育てていく。それも仕事のうちだ。

作る仕事から決める仕事に移ると、評価される場所が「出来のよさ」から「結果」に変わる。

この5つを貫いている線は、1本しかない

書き出してみて、あらためて思った。

1で信頼を取れないと、3で盾を持てない。3で盾を持てないと、4でデザイナーとエンジニアを守れない。4でチームを守れないと、5でクライアントに「公開してからが本番です」と言える関係にならない。

全部つながっている。そして真ん中にあるのは、技術じゃない。信頼だ。

Webディレクターの仕事内容を5つに分けたけれど、やっていることを一言にすると「信頼を作って、それを使って、いいものを通す」になる。監督の仕事というのは、たぶんそういうことだ。

正直、きついこと3つ

ここまでが仕事内容だ。ここからは、求人票に書いていない話をする。

1. 「自分が作った物」が残らない

これが一番きつい。

自分はグラフィックデザイナーから始めた。自分の手で作ったものが、目の前に残る仕事だ。ディレクターになって、それがなくなった。

ただ、正直に書くと、この感覚はデザイナー時代にも味わっている。

デザイナーとして関わった案件で、売上が200%になったことがある。スーツケースなど旅行用カバンのメーカーのプロモーションだ。社内でMVP賞をもらった。数字だけ見れば、自分のキャリアで一番派手な部類に入る。

でも、「自分がやった」という感触が薄い。

あの案件には、すごくできるアートディレクターがいた。その人がそれまで積み上げてきたクライアントとの信頼関係があって、その人のディレクションがあって、自分はその上でデザインを作った。手は動かした。でも、あの成果はあの人の仕事だったと思っている。

当時は少し複雑だった。今はわかる。いい仕事は、だいたい誰か一人のものじゃない。

作る人の成果は、誰かのディレクションの上に乗っている。作らない人の成果は、人の手を経由してしか形にならない。どっちにしても「これは自分の手柄だ」と言い切れる瞬間は、そんなに来ない。

ここに耐えられるかどうかは、向き不向きの分かれ目だと思う。

2. 板挟みは、一時的な事故じゃなくて仕事の一部

クライアントは終盤で「これも入れられませんか」と言う。制作チームは「この期間では無理です」と言う。どちらも正しい。

新人の頃は、これを「今回は運が悪かった」と思っていた。違った。この板挟みは事故じゃない。間に立って決めることが、そもそもの仕事だ。どちらかの言い分をそのまま流す人は、ディレクターの仕事をしていない。

さっき書いた一次要件の合意は、この場面で効く。握れていれば、正面から突っぱねなくても「その案なら、こっちでやりましょう」と逃げ道を作れる。握れていなければ、ただ板挟みになるだけだ。

きついのは、どっちを選んでも誰かに嫌な顔をされることだ。慣れはする。好きにはならない。

3. トラブルは、全部こっちに来る

サーバーが落ちる。原稿が来ない。担当者が変わって話が振り出しに戻る。誰のミスでも、最初に電話が鳴るのはディレクターだ。

そして、その受け皿が一人しかいない組織は、けっこう危うい。

前にいた会社の社長が、いわゆるフルスタックの人だった。営業もやる、ディレクションもやる、なんならエンジニアリングまでやる。強い。ただ、その人がいないと何も決まらないし、案件が回らない。

だから、制作部の業務を仕組み化した。それまでに自分が得てきた経験をもとに、「ディレクションのこの部分は切り分けられる」「チェックのこの部分は切り分けられる」と一つずつ剥がして、手順とドキュメントに落とした。結果、制作部の売上は130%に上がった。

きれいな改善提案として始めたわけじゃない。一人に全部が乗っている状態が、単純に危ないと思った。それだけだ。

向いている人と、向いていない人

11年やって、はっきり差が出ると思ったのはここだ。

向いていると思う人

• 人が作ったものを、素直にすごいと思える人

• 人に任せられる人（「自分でやった方が早い」で止まらない人）

• 決めることを、怖がらない人

• Webの知識だけで戦えると思っていない人（ビジネスの勉強が要る）

• 話の通じない相手にも、もう一往復だけ言葉を足せる人

しんどくなりやすい人

• 自分の手で作った達成感がないと満たされない人

• 全員に好かれていたい人

• 「指示待ちの方が楽」と思っている人（決める量が、想像の3倍ある）

センスは要らない。デザインもコードも、できなくていい。要るのは、決めて、渡して、責任を引き受ける胆力だ。

それでも11年続けている理由

きつい話ばかり書いたので、続けている理由も書く。

デザイナーの頃、自分は「これは何のためのデザインなのか」に答えられなかった。上流に行きたかったのは、その気持ち悪さから逃げたかったからだ。

ディレクターになって、そこに答えられるようになった。何のために作るかを、自分が決められる位置に来た。作った物は手元に残らない。でも「どう作るかを決めた」という判断は、次の案件に持っていける。

才能は1ミリも増えていない。増えたのは、努力の向け先を選ぶ精度だけだ。

この仕事を選ぶかどうかの前に

Webディレクターの仕事内容を調べている人は、たいてい「この仕事に移るかどうか」を考えている。

仕事内容が合っていても、選び方を間違えると転職は失敗する。自分はそれで1回、はっきり失敗した。転職4回のうち、唯一の失敗だ。肩書きは上がった。それでも失敗だった。理由は入社前の「選び方」にあった。

その失敗談と、幸せになれる転職の選び方は、こっちに全部書いた。求人サイトを開く前に読んでほしい。

未経験からこの仕事に入るルートの話は、こっちに書いてある。