Webディレクターは未経験からでも参入できる職種の１つです。各求人サイトを見てもそのように書かれています。しかしながら、「職種未経験＝ITについても未経験」ということになるため、入社後は苦労することが多いです。聞こえの良い求人経由で入社した後は
・伝書鳩系のWebディレクター
・技術者から嫌われる系のWebディレクター
・単純にレベルの引くWebディレクター
に帰着しがちです。【月収５０万も可能】【未経験からでも活躍している方多数】みたいな言葉に騙されたと感じて、不幸せな状態で働き続けることになります。
一方で優秀なWebディレクターもいます。QCD（品質、コスト、納期）のレベルが高く、どんな案件をどれだけ降ってもQCDを落とすことなく仕事をこなせる方がいます。
・ざっくりした話で振っても、満足いく形に仕上げてくれる
・○○さんの安心感がすごい…!!
・○○さんってめちゃくちゃ技術者ファーストでやってくれますよね
といったWebディレクターは優秀です。先程のWebディレクターと同じ職種で働く人でありつつも、その差は１人で５，６人分の成績を出す営業マンと自分の給料も稼げない営業マンくらいの差があります。
今回はWebディレクターとして一皮むけたい方やさらなる成長を求める方に向けてWebディレクターとしての質を高めていく方法をお伝えしていきます。
数の先にしか質がないことを再認識する
どの仕事にも言えることですが、Webディレクターの仕事も数の先にしか質はありません。質の高いWebディレクターであっても最初はペーペーからスタートしています。私の周りには現在はPdMやWebプロデューサーが沢山いますが、最初はWebディレクター（初心者）からスタートしています。当時のことを話せば
・ただの伝書鳩だった
・技術者達にはめちゃくちゃ迷惑をかけた
・言われるがままにやっていたイメージ
といった感じで私の原体験としても同じであるため、どんな人でも最初はそんなものです。
そういった数ある案件をこなした先にしか質の高いWebディレクターはいません。しかしながら、何も考えずに数をこなしている人と考えて数をこなしている人には差が生まれます。
・デザイン系の案件であれば、自分なりにどういったデザインが良いのかを考えてみる
・API系の案件であれば、APIの仕組みと出来ること出来ないことを覚えていく
・新規テーブルを作る案件であれば、テーブルの仕組みや技術者が考えたテーブル設計の理由を聞いてみる
・サーバのスペックアップ系の案件であれば、サーバの仕組みやスペックアップによる費用や効果を知る
など、どんな案件にも学びがあります。その学びを１つ１つ自分のナレッジにしていくことで、同じような案件が来た時は直ぐに対応できますし、似たような案件にも対応できます。
数が充分になってきたら８：２の法則で仕事をする
どんな案件にもある程度の対応が出来るレベルに数をこなしてきたWebディレクターは８：２の法則で仕事をしていくとより質が高まります。
８：今まで通り数をこなす
２：学習タイムやコミュニケーションタイム、セミナーなど知識の定着を目的とした時間
という意味になり、数に忙殺され続ける１０割よりも２割は知識の定着に時間をかけた方がいいです。Webディレクターという仕事の特性上、学び続ける姿勢が重要です。新しいテクノロジーや考え、トレンドなど新しいモノを学ぶ機会と案件をこなす中で得た学びをまとめたり、確かなスキルに還元する時間です。
タスクの細分化とリスト化をする
Webディレクターの基本はQCDです。
品質：バグなく、仕様通りの要件を担保する
コスト：最適な仕様で実装し、不要な工数を生み出さない
納期：各工程をスムーズに待ち時間なく動かしながら、リリースに遅れることなく実装する
この３つがが重要になってきます。そしてこの３つを高いレベルで実現するにあたって、重要になるのがタスクの細分化とリスト化です。
案件の種類によりますが
・要件定義書を作る
・（人によっては）要件定義書の確認会を設ける
・ヌケモレがあれば、依頼者に確認を取る機会を設ける
・デザイナーにデザイン制作を依頼する
・技術者に工数試算の依頼をする
・テスターに仕様を伝えてテスト設計をしてもらう
などなど、案件をリリースするまでに行うタスクがいくつもあります。まずはこれらの作業を洗い出すところからです。洗い出しが完了したら、それらをリスト化して完了の有無が分かるようにします。また、リスト化したタスクとそれぞれの工数を組み合わせてスケジュールを引きます。まだリリース日が決まっていなければ、少しバッファを見てリリース日が決められますし、既にリリース日が決まっていればそれが現実的なのか非現実的なのかが分かるので、依頼者に対してリリース日の調整がかけられます。それでもリリース日が動かなければ、まずは自分のタスクの期限を短くして間に合わせるような動きをとってきます。このようにやることリストが明確になっていれば、リリースまでの流れを掴むことができます。QCDの内、Dの納期を高められます。QやCは数をこなす中で掴む部分が大きいので、まずは自分でどうにかなるDの部分を高めるのが現実的です。
技術者の仲間を増やす
未経験Webディレクターに限らず多くの方が陥りやすい考えの１つに技術力の不足があります。数ある案件をこなす中で身につく技術もありますが、自分ひとりの頭だと理解しきれなかったり、知識として定着しづらいものがあります。この状態が続くとQCDの内、Qの品質とCのコストが欠落してしまいます。本当はもっと簡単で効果的なやり方があるのに、そうではない選択肢をとってしまったり、技術により実現可能なこととそうでないことがわかっておらず、無意味なコストを支払う結果になったりします。そのため、Webディレクターであっても技術的な知識を持っておくことがより質の高いWebディレクターに近づくことになります。
しかしながら、技術はそう簡単には身につきません。特にシステム系の技術は幅が広い上に深いです。ググって分かるような人であれば何も問題ないですが、ググっても理解できない人は誰かから教えてもらうしかありません。その解決はしやすく、Webディレクターは技術者達と仕事をしています。なので、その技術者達に知見を分けてもらうのが１番です。ただ、技術者に嫌われているWebディレクターであったり、技術者の気質的にもトレードオフ無しに知見を分け与えることを嫌う人もいます。既に嫌われてしまっていると面倒ですが、仲良くなるのが手っ取り早くそうなっていけば色々と教えてもらえます。そうやって少しずつ技術力を高めるのが効率的と言えます。
自分の手で動かせる領域を増やしていく
技術の中でもWebディレクター目線で持っておくと良いスキルがいくつかあります。
・SQL
・サーバへのファイルアップ
・GAS（Google Apps Script）
・Adobe Illustrator（ペイントを使いこなすでもアリ）
・Googleオプティマイズ
あたりがオススメです。Webディレクターをしていると「こんなデータだせない？」「今すぐこれアップしてほしいんだけど」「デザインみないと分からないんだよね」「A/Bテスト溶かしてみたら良いんじゃない」みたいなことを言われがちです。だからこそ、先程あげたようなことができるようになると自分で出来ることの幅が広がり価値が高まります。
要件定義書のテンプレートを作る
Webディレクターの主な仕事の１つに要件定義書の作成があります。この出来次第で技術者たちとのコミュニケーション工数が決まると言っても過言ではなく、成長段階にあるWebディレクターはしばしば技術者たちから
・ここはどうするんですか？
・これ無理じゃないですか？
・AとBに適用するとのことですがCには適用しないんですか？
といった質問を受けます。最初からできの良い要件定義書があればこうはなりません。
また、技術者も完璧ではないため、仕様漏れや考慮漏れに気づかなければそのままリリースまでいってしまいます。結果的に仕様漏れによる再修正をしたり、信頼を失ったりと良いことはありません。これも要件定義書がしっかりと作られていれば起きる自体ではありません。
だからこそ、要件定義書はしっかり作るに越したことはありません。そのためには要件定義書をテンプレート化するのが手っ取り早いです。ここでは細かい要件定義書のテンプレートについては割愛しますが、載せるべき項目は
・案件の目的と概要
・デバイスと適用サイトのサマリー表（今回はSPのAサイトが対象と分かるようにする）
・影響範囲（自分の分かる範囲で洗い出す）
・対応ページの一覧とURL表
・デザインとセットで書かれている仕様（主語と述語を忘れずに丁寧に書く）
・気をつけるべき観点
は載せておいても損はありません。最初から完璧な要件定義書を作ることは不可能です。しかしながら、何度も作る要件定義書をブラッシュアップさせていくことは可能です。要件定義書を作業とせずに目標感を持って取り組むことでいずれは良い要件定義書が作れるようになってきます。
依頼者に質問することとそうでないことを分ける
Webディレクターは依頼者と技術者の間と取り持つポジションです。それ故に双方から質問を受けたり要望を受けたりします。これに対して何も考えていないと伝書鳩になってしまいます。そうなると価値はほぼ０です。「いなくてもいいじゃん。むしろ邪魔じゃね？」的な見られ方をされてしまいます。
依頼者と技術者からそれぞれの要望や質問を受けて、それをもう片方に対して質問する際は「聞くべきことと自分で判断すること」で切り分ける必要があります。技術者からの質問に対して、全てを依頼者に対して同じように質問するのは依頼者にとってもウザったく感じます。「ここの色は何色にしますか？」「ここの動きはこれでいいですか？」など「ぶっちゃけそっちで決めてもいいよ」という質問はWebディレクター側で決めてしまっても問題ないと考えます。このあたりは依頼者の細かさや性格によるため、一概には言えませんが私が今までやってきた感覚からすれば、自分である程度決めて共有だけしておくのが良いと思います。
一例として、依頼者に質問しなくてもいいことは
・ACやCVに大きく影響しない話
・技術的な課題解決に関する話
・納期や費用に影響しない話
などはいちいち質問しなくてもいいケースが多いです。逆に「納期が遅れる」「工数がもっとかかる」といった話は気にします。そのリスクがある際は早く相談したほうが良いです。
手戻りのポイントを押さえる
Webディレクターとしての経験が浅い内は、「依頼者さん、この件ですが○日リリースが難しいかもしれません」➜「なんで？」➜「技術的な要件が…」➜「いやいや、それじゃ納得できないよ。詳しく」➜「あ、はい。わかりました。確認してきます」のように依頼者とのコミュニケーションにおいて齟齬が発生するケースが多々あります。
こういった手戻り的なことが何度も発生すると信頼度が低下し、仕事がしづらくなります。本来、確認不要なことも確認されたり、必要以上にチェックが厳しくなったりと「なんで自分だけこんなに確認されるんだよ…」といった感じでリリース日に対するコミットの難易度が上がっていきます。
そうならないようになるべく手戻りは減らしておきのが吉です。手戻りに関してもいくつかのポイントがあります。
・リリース日が遅れるような話
・費用、工数が上がるような話
この２点が主になります。然るべき理由でリリース日が遅れたり費用が上がるのは仕方ありません。しかしながら、不明確な理由でそれを言われて「OK」という依頼者はそうそういません。だからこそ、なぜそういった結論になったのかの理由をしっかり話せるようにしておく必要があります。技術者も意味なくリリース日を遅らせたいわけではないため、なぜそうなったのかの理由を自分の言葉で言えるように理解します。また、依頼者は技術的な部分に弱いため、依頼者でも理解できるような言葉に直して伝えます。
本来はこうはならないように、要件定義書をしっかり作っておいたり、依頼者からの要件をしっかりと吸い上げる必要があるのですが、どうしてもこういうことは起きてしまいます。そんな時に納得してもらえる形で伝える必要があります。また、技術者から細かい話を聞いていると「こうすればリリース日遅らせずに済むんじゃね？」と自分で思いつくことも多々あります。そうなれば、依頼者への交渉も避けられますしQCDを保つこともできます。
WordPressでも良いから自社媒体を持つ
Webディレクターは特定領域の知識を持っていればいいわけではなく、幅広い知識を押さえておく必要があります。その知識を得るために無数の案件をこなすことが１つではありますが、さらに意欲的な方は自分で媒体を持つことを勧めています。
WordPressは自分でプログラムを書かずとも１つのサイトを構築できてしまいます。そのため、プログラミングスキル的な意味では他のプロダクトを探したほうが良いかもしれません。WordPressを使ったサイト構築で身につくことは
・ドメインやサーバに関する基本的な知識
・記事コンテンツで伸ばすためのノウハウ
・GAやAdSense、Search Consoleの見方や使い方
・サイト上のどこに何を置くことで効果が出るのかの体感値
・SEOに関する原体験を基にした知識
・サイトそのもののざっくりした知識
などです。私もWordPressでこのように記事を投稿していますが、実際にやってみて良かったと思っています。フワッとしていた知識を固めることに成功しましたし、自社媒体の中にWordPressの機能を組み込んで使う際にはWordPressの使い方で困ることはありませんでした。
また、もう１つのメリットは副業申請をした上でサイト運営をしている場合にあなた個人への見られ方が変わることです。少なくともマイナスに見られるようなことはありません。仕事のやりやすさや信頼度に多少なりと影響する可能性があります。
まとめ
Webディレクターは一皮むけると一気に仕事がしやすくなります。また、年収を上げるチャンスが見えてきたり、キャリアを明確化するきっかけにもなります。この界隈はやる気のある方が多いため、競争の激しい職種の１つですが、仲間でありライバルであるWebディレクターで働く人に負けないように頑張っていきましょう！
コメント