＜この記事の著者＞
ばんか（bamka） - Tech Team Journal
Web制作会社の会社員（Webディレクター）として働きつつ、個人でブログ／メディアライターとしても活動するパラレルワーカー。
ChatGPT等AIを公私で駆使し、ITツール・ガジェットを用いて人々の生活をより豊かにするための活用術を提供するブログも運営。
制作会社のWebディレクターとして12年間働いてきて、その中でさまざまな失敗を経験しました。
好んで失敗したわけではありませんが、そこから学びを得たことで、自分にとっての「Webディレクターとはこうあるべき」という姿を形作れたように思います。
今回は、Webディレクター時代に経験した失敗例と、そこから得た学びと対策についてお話しします。
【目次】
言われたことをやるだけのつまらない仕事
仕事の基本的な流れは、クライアントから「こういうことをしたい」という依頼をもらい、それに応えた対価として報酬を得ます。
その結果、「依頼する側」「請け負う側」という構図を意識してしまい、以下のようなマインドに陥ってしまいがちです。
・言われたことをやるだけの、つまらない仕事。
・このままでいいのか？と疑問に思っても解消できず、もやもやを抱えたままになる。
・クライアントの無茶な要求にも答えなければならない。
特にWebディレクターという職種は、クライアントと社内を繋げる橋渡し的な存在。右から左に話を通すだけの仕事にもなりがちで、自分の存在意義を感じられない時期もありました。
行った対策
クライアントからの依頼には、まずはとにかくヒアリングに注力するよう心がけました。
課題や方法ではなく、目的を明確にするところから始める。目的を定めてから、あらためてそれを達成するための手段を考え、提案する。
得てして依頼内容は手段や方法にフォーカスが当たりがちですが、最初に一歩引いた視点を持つようにしていました。
その結果、失注した仕事もありました。
クライアントからは「Webサイトを作りたい」という希望で相談を受けたのですが、検討を進めていくうちに、サイト制作が最善でないと感じはじめました。
同じ予算を使うなら、ランディングページを1枚作り、余った予算を広告に回したほうが得策である。そう判断し、提案しました。
その結果、クライアントで内製する運びとなり、仕事としては失注となりました。ですがクライアントからは感謝される結果となり、関係も以前にも増して良好となりました。
目的から考えられるようになると、クライアントに対して自信を持って「こうあるべきです」と提案できるようになります。
言われた依頼をただ遂行するのではなく、「一緒に良いものを作りましょう」という姿勢で臨めるようになりました。
終わらないデザイン修正
何度デザインを提出しても修正依頼が返ってきて、いつまで経っても終わらない。そんな失敗はWebディレクターなら一度は経験すると思います。
特に起こりがちなのが、Webサイトのリニューアル時の初稿デザイン。バチッとハマれば早いのですが、ハマらないと泥沼化。
あの手この手でデザイン案を変えてみますが、「なんか違う」という違和感を解消できないまま、時間だけがイタズラに過ぎていきました。
行った対策
私はこの「デザインを作る」というフェーズがとても苦手です。いまでも苦手意識はありますが、失敗する数は減ったように思います。
心がけているのは「関係者が各々で持っている感覚を、可能な限り言語化・視覚化して、同意を形成する」というもの。
たとえば私はよく、デザインヒアリングシート・デザインコンセプトシート・ムードーボードなどを作って、デザイン制作前に希望を聞いていました。
その他にも、参考サイトを並べてみたり、競合他社の参考にしたいところ・したくないところをまとめたりと、あの手この手を尽くすようにしていました。
参考にするのはWebサイトに限りませんでした。本屋に行って、雑誌をいくつも買って、「この雑誌は遠くて、こっちの雑誌は雰囲気が近い」などの意見交換もしました。
クライアント側に明確なデザインの希望がない場合でも、「こういう方向で進めようと思います」という提案を視覚化・言語化してから、デザインを作るようにしています。
大切なのは、クライアントとの共通認識と合意形成。
言い方は悪いかもしれませんが、クライアントの修正依頼に対して「あらかじめこうするって決めましたよね」と根拠を持って言い返せる状態を作るのが大切です。
ケンカをしたいわけではありませんが、互いに納得をしながら進めるために必要な手順です。
案件が進めば、新しいアイデアが浮かんだり、感情的な変化が生まれます。そういう「一時的に発生した点」に対して、それが当初の計画の線上にあるのか、あるいはないのかを、明確に判断できる材料が必要なのです。
それでもなお「修正したい」というのであれば、それは「修正」ではなく「変更」となるため、スケジュールを延ばす交渉ができます。
制作・実装に必要な工数を見誤る
いまでこそ「これぐらいのボリュームなら、デザインにこれぐらいの工数がかかって、HTMLのコーディングはこれぐらいだな」というのが、なんとなくの肌感でわかるようになりました。
しかし、各制作工程に必要な工数の見積もりを見誤り、スケジュールの設計に失敗したことは、過去に何度もありました。
特に多かったのは、フロントエンジニアでの実装部分について。
必要なページ数や構成が過去の案件と似ていたからと、過去の事例を参考に工数を算出すると、よく失敗しました。
クライアントの環境、使用するフレームワーク、JavaScriptの内容、実装するCMSの仕様—。過去の事例と異なれば、どれひとつとっても同じ作業工数にはなり得ない。
そしてなにより、実装するエンジニアの得手・不得手やスピード感によっても、必要な時間は左右されます。
こういったものを考慮に入れず、杓子定規にスケジュールを引いてしまった結果、クライアントの承認を得たあとに「こんなスケジュールじゃ実装はできない」と突っ返されたこともありました。
行った対策
大切なのは事前の相談。結局はコミュニケーションが重要なのです。
Webディレクターが要件や仕様の方向性を考えはしますが、クライアントに提案する前には必ずエンジニアに相談するようにしました。
仮にその時点で、プロジェクトにアサインするエンジニアが決まっていなかったとしても、仲の良いエンジニアに声をかけて、意見を仰ぐようにしています。
Webの制作で重要なのは、チームとしての一体感。
Webディレクターがクライアントと決めた仕様を、デザイナーとエンジニアに一方的に依頼するのでは、「チームで創る」とはいえません。
プロジェクトの与件から始まって、クライアントの目的やゴールを共有し、「どうしたらクライアントの目的を叶えられるか」から一緒に考えてこそ、各人が主体的に動ける理想的なチームとなります。
「Webディレクターが計画」「実装はそっちで」と切り分けるのではなく、計画の段階からワンチームになるよう働きかければ、工数計算やスケジュール作成で失敗することもなかったでしょう。
あとからコロコロ変わる仕様や要件
制作が佳境にさしかかっても「ここの仕様を変更したい」「社内からこういう要望が出てきたので対応できないか？」といった変更の希望は出てきます。珍しくはありません。
あるいは「これも対応してください」「あの件ってどうなってますか？」と、当初予定していなかった、あるいはこちら側で対応する予定ではなかったタスクが飛び込んでくることもあります。
そんなとき、「発注と受注」という関係性から抜け出せず、言われた依頼はやらねばならないと思っていた時期がありました。
しかし、しわ寄せを受けるのは社内の制作陣です。リリースのスケジュールが変わらない中、無理なお願いを強いてしまった経験は、過去に何度もありました。
行った対策
プロジェクトを始める前に、キチンと要件定義を固めるのはもちろん重要です。制作するページの数やボリュームだけじゃなく、実装方法に至るまで、具体的であればあるだけ良いです。
それに加えて、見積もりの段階でスコープ（役割）の切り分けをハッキリさせるのも、同じぐらい大切です。
私の会社では「スコープオブワーク」といって、見積もりの中に何が含まれていて、何が含まれていないのかを明文化するための資料がありました。
見逃されがちなタスクの一例として、以下のようなものがあります。
・素材は提供されるのか、それとも購入するのか。
・メインビジュアルは静止画でいいのか。
・コピーライティングはするのか。
・ページ内の原稿は、既存サイトの内容を流用して良いのか。それとも新たに制作しなければならないのか。
・各ページのmetaは誰が考えるのか。
細かい話ですが、こういった役割分担をあらかじめ詳細に行っておくと、後のトラブルを未然に回避できます。
「それは当初の見積もりには含んでいないので、対応に追加料金がかかります。」
「当初の要件に含まれておらず、スケジュールにも加味されていないので、スケジュールを後ろにずらすか、公開を二段階にわけるなどの対応が必要です」
こうした交渉をするためには、根拠となる約束事が重要です。
作成したスケジュール通りに進まない
これはWebディレクターをはじめて数年経った頃、よく悩んでいた問題です。
プロジェクトが始まる前に計画したスケジュール。あんなに時間をかけてしっかり練ったのに、いざ始まってみると、期日通りにタスクが完了していかず、スケジュールが逼迫していく。
プロジェクトに関連するメンバーにはそれぞれ無理のないスケジュールでタスクを割り振っているのに、なぜ期日通り終わらせてくれないのだと、ヤキモキする日々でした。
行った対策
当時の私は、そもそもの “Webディレクターとしての考え方” が間違っていました。
前提として、プロジェクトはスケジュール通りには進みません。
スケジュールを目指して進行管理はしますが、さまざまな要因により、変更は余儀なくされます。
人のやる仕事ですから、体調不良やモチベーションの低下で、思っていたようなパフォーマンスが出せない日もあります。
他のプロジェクトとの兼ね合いで、忙しい時期が続いてしまい、着手が遅れてしまうこともあるでしょう。
Webディレクターに求められるスキルは「完璧なスケジュールを作る能力」ではなく、「スケジュールを柔軟にコントロールする力」です。
スケジュールに変更があれば、影響のあるタスクに対して、期日を延ばしたり、優先順位を入れ替えて、調整をする。
プロジェクトメンバーが、期日に終わらなさそうで困っていたら、他のメンバーに強力を仰いだり、サポートを付けるなどの対策を考える。
あるいはクライアントに、確認期間の短縮を依頼したり、場合によってはリリースの延期を交渉したりする。
こういった細かな対応をして、スケジュールを何度も何度も引き直すのは、Webディレクターとして当たり前なんだと理解しました。
そのため、リスクとなりそうなものに対して早めに察知できるよう、工夫をしていました。
毎日始業後の10分で朝会を実施したり、デスクに行って雑談交じりに声掛けをしたりして、メンバー各々が自分の状況を気軽に打ち明け、相談できる
空気づくりを目指しました。
さいごに
最後になりますが、上述したような対応を杓子定規に行うのが、Webディレクターの仕事ではありません。
クライアントとケンカをしたいわけじゃありません。責任のなすりつけ合いに勝つための予防線でもありません。
「そんな話は聞いてないので対応できないです」と冷たく跳ね返すのではなく、相手の立場や希望を鑑みつつ、現実的にみんながハッピーでいられる建設的なアイデアを作る。
それがWebディレクターの仕事です。
これらのことを加味して、最後に、私がWebディレクターとして得た一番の教訓はこれです。
「結局最後は人と人。お互いや優しさを持ち寄って “相手のために何がしてあげられるか” を思いやれる関係性を構築するのが、Webディレクターの一番の仕事である」
クライアントだとか、パートナー企業だとか、そういう役割や立場は関係ない。「あの人のためなら、少し寝る間を削ってでも、頑張ってあげよう」と、そういう思いやりをみんなが少しずつ持ち寄れる。
それが最高のプロジェクトの形です。そんな理想の形を作れるかどうかは、プロジェクトの中心を担うWebディレクターの力量にかかっています。
(文：ばんか（bamka）)
paizaでは、Webサービス開発企業などで求められるコーディング力や、テストケースを想定する力などが問われるプログラミングスキルチェック問題も提供しています。
スキルチェックに挑戦した人は、その結果によってS・A・B・C・D・Eの6段階のランクを取得できます。必要なスキルランクを取得すれば、書類選考なしで企業の求人に応募することも可能です。「自分のプログラミングスキルを客観的に知りたい」「スキルを使って転職したい」という方は、ぜひチャレンジしてみてください。
詳しくはこちら
