Webディレクターはどんな仕事をしているのか

今回は、Webディレクターの仕事内容についてご紹介します。

Webデザイナーやエンジニアはある意味「デザインを生み出す」「コードを書く」といったわかりやすいイメージがありますが（本当はもっと細かく分かれていたりします）、Webディレクターというとその業務が多岐にわたることもありイメージが一番つきにくい仕事かもしれません。

一般的に、Webディレクターの仕事は「進捗管理」。プロジェクトが滞りなく進むためにタスクやスケジュールの管理を行い、ゴールに導く仕事と言われます。しかし実際は、Webディレクターは企業規模やプロジェクト規模、その人のパーソナリティによって内容が異なったり、業務が細分化されたり、逆に関わる領域が拡がっていったりします。

Lepusで取り組んでいるWebディレクターの仕事や、私のこれまでの経験を交えて、Webディレクターはどんな仕事をしているのかご紹介します。

プロジェクトにおけるWebディレクターの立ち位置

プロジェクトは「サービスを立ち上げる」「クライアントからの依頼」など、一連の業務が発生した時に立ち上がります。

クライアント or PO（プロダクトオーナー）とは

プロジェクトの最終意思決定をする人です。サービスの立ち上げを行なった場合は、上長であったり経営者がPOとして立ちます。クライアントに業務システムを収める場合、クライアント側が最終意思決定をします。プロダクトオーナーはあくまで意思決定を行います。Webディレクターが兼務することもありますが、なるべく客観的にプロジェクトを見れる立場の人が望ましいとされています。

Webディレクターの立ち位置

Webディレクターは、依頼主（企画者）と開発メンバーであるデザイナー、フロントエンド、プログラマー（バックエンド）の間に立ち、プロジェクトがスムーズに進められるようにします。

Webディレクターの業務は進捗管理だけではない

Webディレクターの立ち位置を紹介をしましたが、間に入って進捗管理をしていくということはわかったと思います。ただ、進捗管理はプロジェクトが始まってからの仕事で、実はそれまでに重要な役割が多くあります。

実はプロジェクトが始まるまでが重要なお仕事

ヒアリング（企画会議）〜要件定義

Webディレクターは、まずクライアントへのヒアリング（社内プロジェクトの場合は企画会議）を行い、作り上げるプロダクトの要件をまとめていきます。

個人的に、Webディレクターの仕事の8割はこのフェーズにあると考えているくらい重要です。その理由として、経験上ヒアリング〜要件定義が甘いプロジェクトは炎上したり完遂しなかったりするからです。

クライアントへ収めるシステムの場合は、見積の前、見積の後も繰り返しヒアリングを行い、内容を要件に落とし込んでいきます。クライアントとのヒアリングでは、窓口担当者、現場、意思決定者とクライアント側でプロジェクトに関わる人数も増えるため、その意思決定がブレていたり（求めている事が変わる）、間違っていたり（現場にヒアリングすると欲しいものは違ったなど）することも少なくありません。ですので要件に落とし込み、クライアント側の関係者になるべく目を通してもらい、クライアントの必要とするものを形作っていけるよう粘り強い仕事が求められます。

社内プロジェクトの企画会議は、アイデアラッシュであったり、マーケティング戦略であったりとWeb業界のキラキラ・ワクワクしたイメージに近いものです。とても楽しいのですが、それをサービスとして要件に落とし込むと、矛盾や無理があったり、優先度の問題があったり、そもそも思ったよりイケてなかったりといろんな問題が表面化してきます。企画と要件定義を繰り返し、そうした粗を削ぎ落としていくことで、プロジェクトの質を高めていくことがWebディレクターに求められます。

「要件定義が重すぎないか」「サービス立ち上げでスピード感が重要」「考えるより手を動かせ」という考え方もあるかもしれませんが、スピード優先で成功しているプロジェクトというのは、こうしたプロダクトが必要なんだと、揺るぎない信念＝明確なゴールを持ったPOがいる場合のみだと思います。

仕様設計〜機能設計

仕様設計では、要件を各機能に落とし込みます。これは技術的なフォローが必要になるため、リードエンジニアと協力して進めていきます。

仕様は機能ごとにタスク化していきます。タスクの管理はJiraで行います。

機能設計は、各機能のフローを起こしていきます。プロジェクトによってフローの粒度は異なりますが、複雑な機能は必ずフローを起こします。フロー化することで、見えていなかった機能が洗い出せるほか、バグが起きるポイントを未然に洗い出す事ができます。またその後画面仕様に落とす際にも、フローに沿って必要な画面を作成する事ができるため、無駄がありません。

フロー化する際はmiroを活用しています。miroは、簡単に言えば無限に広がるホワイトボードです。フロー図以外にも、企画段階のアイデアラッシュに使ったり、ヒアリングした情報などを一元的にまとめていたりなどLepusではヘビーユースします。

ちなみにJiraでは、リードエンジニアが各機能をさらに技術的に必要な細かなタスクに落とし込んでいきますが（DB設計・API・画面実装など）、Webディレクターは関与しません。あくまでも機能ごとの大まかな進行を管理していきます。

画面設計

機能設計まで進めたことで、必要な画面が見えてきます。ここでWebディレクターは画面設計に入ります。Lepusでは、画面設計にFigmaを使っています。

ツールにFigmaを使っている理由は以下の通りです。

ブラウザでも利用できるためどこでも作業が可能
各パーツをコンポーネント化することで保守性が高い
Core UIをはじめ無料で使えるベースコンポーネントが豊富
そのままデザイナーがデザインに入れる

ちなみにLepusのWebディレクターが使っているツールは以下です。

ここまでの作業を経て、ようやくプロジェクトの進行が始められます。とはいえ、大枠の要件定義が固まった時点で、開発可能な機能から仕様を用意し順番にエンジニアチームに落としていくため、実際にはもっとスムーズに進めています。

開発は続くよどこまでも

こうしてしっかりとした仕様を用意することで、致命的なバグが起きにくく、咄嗟の仕様変更にも柔軟に対応できるプロダクトを開発する事ができます。そして、プロダクトに完成はありません。初期の開発スピードから落ち、安定していくことはあっても、OSレベルのアップデートから運営のフィードバックを経ての機能変更・追加は必ず必要になっていきます。
人もプロダクトも、成長を止めた瞬間落ちていくだけです。