少人数のウェブ制作チームで長く仕事をしていると、同じ言葉を使っているのに期待していることが噛み合わない場面が繰り返し起きる。私の場合、いちばん多かったのが「ディレクター」だった。
この記事は、役職名で語るのをやめて責任範囲を6つに分け、案件ごとに「誰がこの範囲に責任を持つか」を決めることにした、という話だ。チームに配った表と対応図の2枚を、一般論と突き合わせながら書き直した。
「ディレクターに聞いて」で毎回ズレる
営業から「この件、ディレクターに確認しておいて」と言われる。私は「成果物の品質を見る人」のつもりでディレクターという言葉を使っていたが、相手は「スケジュールと段取りを仕切る人」の意味で使っていた。営業が進行の件でディレクターに声をかけるのは、相手の定義では自然な行動で、私はそれを品質の話だと思って受け取る。どちらも間違っていない。業界の中に、正当な定義が2つあるのが原因だった。
- 映画や広告の世界では、ディレクターは作品の質に責任を持つ人。お金と進行はプロデューサーが持つ
- 日本のウェブ制作では、「ウェブディレクター」が進行管理・要件定義・ワイヤーフレーム・品質管理をまとめて持つ職種として扱われることが多い。求人票や職種紹介を見る限りの話で、文献で裏づけたわけではない
つまり「ディレクターに聞いて」は、進行の話にも品質の話にも使える。宛先が変わる言葉を共通語にしていたので、毎回ズレる。どちらの定義が正しいかを争っても解決しない。このチームでどう呼ぶかを決める問題だ。
もうひとつ、工程が飛ぶ問題もあった。営業が作ったイメージ図がそのまま「確定した仕様」として流れてきて、デザイナーが決まっていない要素を抱えたままデザインを起こし、実装の段階で確認と調整が多発する。これは役割の問題というより、「何が決まっていれば次に進んでよいか」が決まっていない問題だった。
6つの責任範囲
| # | 責任範囲 | 責任者 | 成果物 |
|---|---|---|---|
| 1 | 納期・予算・スコープ | PM | スケジュール／スコープ |
| 2 | 掲載するコンテンツ・機能 | プランナー（要件定義者） | コンテンツ一覧（確定／未定の印つき） |
| 3 | 構造化・ラベリング・ナビゲーション | IA（インフォメーションアーキテクト） | サイトマップ／ワイヤーフレーム |
| 4 | 視覚表現・トーン | クリエイティブディレクター／デザイナー | カンプ／プロトタイプ |
| 5 | 技術方式・実装・保守性 | テクニカルディレクター／実装者 | 技術方式／実装／運用設計 |
| 6 | 公開後の保守・更新・改善 | 運用担当 | 監視・障害対応／コンテンツ更新／計測レポート |
ポイントは3つ。
1人が複数の範囲を持ってよい。ただし、1つの範囲の責任者は1人にする。 少人数のチームでは兼任が前提になる。それでいい。困るのは「誰が持っているか分からない範囲」があることで、兼任そのものではない。専任のマネージャーを置く必要もない。ただし案件ごとに、範囲1を持つ人を1人名指しする。自分のタスクはセルフマネジメントで回っても、人と人の間の依存関係と、外に対する「いつまでに何を出すか」の期待には持ち主が要る。
範囲は1から6の順に確定する。 次の範囲に着手する条件は、前の範囲の全項目が確定しているか、未定の項目に持ち主と期日が付いていること。「未定」と書いてあること自体は問題ではない。未定なのに確定に見える状態が、後工程の手戻りを生む。
営業のイメージ図は「参考」であって「仕様」ではない。 イメージ図は画面の骨組み（範囲3の成果物）の形をしているが、その手前の「何を載せるか」（範囲2）が決まっていない状態で描かれている。具体的な絵ほど確定に見えるので、扱いを先に決めておく。営業からの依頼はまず範囲1の持ち主に入り、そこから要件・IA・デザインへ流す。
一般論との対応
この6つは、私の経験だけで切ったものではなく、いくつかの定番と突き合わせてある。
- 範囲1〜4は、Jesse James Garrett『The Elements of User Experience』の5段階（Strategy / Scope / Structure / Skeleton / Surface）にほぼ対応する。Garrett のモデルは「下の段が確定してから上の段に進む」という順序そのものが主張で、上から作ると手戻りが出る、という私たちの問題をそのまま説明していた
- 範囲3の「構造化・ラベリング・ナビゲーション」は、Rosenfeld & Morville『Information Architecture』が挙げる IA の構成要素。私は当初、IA を「何を載せるか決める人」だと思っていたが、それは範囲2（要件定義）で、IA は「どう構造化し、どう名付け、どうたどり着かせるか」の人だった。この取り違えに気づいたことで、飛ばされていた工程が「IA」だけでなく「要件定義」も含むと分かった
- 範囲1の PM は、PMBOK でいうプロジェクトマネージャーの責任範囲（納期・予算・スコープ・リスク・対外コミュニケーション）。私は「進行管理だけ」だと思っていたが、「決められたものを決める」つまりスコープの確定と変更管理も PM の仕事だった
役職名は、どの責任範囲に対応するのか
とはいえ、現場では役職名で語られる。だから役職名から責任範囲を引ける対応図を、もう1枚用意した。横軸が6つの責任範囲、縦軸が役職名。濃い帯が責任を持つ範囲、点線の帯は関わるが責任は持たない範囲だ。
この図で見えることを言葉にすると、こうなる。
- ウェブディレクター（日本の慣行）は範囲1〜5をまとめて指す語。だから、この語を使うときは「進行の件」か「品質の件」かを添える。添えれば宛先が決まる
- クリエイティブディレクターとデザイナー、テクニカルディレクターと実装者は、それぞれセットで動く。前者は範囲4、後者は範囲5。クリエイティブディレクターは範囲5に「レビュー」で関わり、テクニカルディレクターは範囲4に「実現できるか」で関わる。同じ実装物を見るが、問いが違う
- プランナーと IA もセットで、範囲2と3を担う。ここが空いているチームは多いと思う。空いていると、営業のイメージ図が代用品になる
- 営業は範囲1への入力。受注・予算・顧客窓口を持つが、進行の責任者ではない。依頼はまず PM に入り、そこから要件・IA・デザインへ流す
「クリエイティブに実装は含まれるか」という問い
整理する途中で、ひとつ迷ったことがある。最近のウェブサイトは動きありきのデザインが増えていて、静止画のカンプを起こしてから実装する、という順序が成り立たない案件がある。それなら、クリエイティブディレクターの責任に実装も含めるべきではないか。
調べた範囲では、業界の答えは「責任を広げる」ではなく「役を増やす」だった。クリエイティブテクノロジスト、クリエイティブデベロッパー、デザインエンジニアといった職種は、表現と実現の両方を一人で扱う実行役として生まれている。責任の線は動かさず、人の側で兼ねている。
なので私の整理では、クリエイティブディレクターの責任は「表現が意図どおりか」のままにして、そのレビュー対象に実装後の動きやレスポンシブの挙動を含めることにした。動きありきの案件では、カンプではなくコードのプロトタイプで判断する。表現（範囲4）と実現（範囲5）の責任は分けたまま、見る対象を実装物に広げる、という形だ。
まとめ
- 役職名は、業界や会社によって指す範囲が違う。共通語にするなら「責任範囲」のほうが揺れない
- 責任範囲は6つ。1人が複数持ってよいが、1つの範囲の責任者は1人
- 範囲は順に確定する。次に進む条件を「前の範囲の全項目が確定、または未定項目に持ち主と期日が付いている」と決めておく
- 役職名で語られたら、対応図で責任範囲に引き直す
チームに配ったのは、表と対応図の2枚だけだ。文章で説明するより、「その話は範囲いくつの話？」と聞けるようになったことのほうが効いている。
出典
- Jesse James Garrett, The Elements of User Experience: User-Centered Design for the Web and Beyond (New Riders, 2nd ed., 2010)。邦訳『ウェブ戦略としての「ユーザーエクスペリエンス」』（マイナビ）
- Louis Rosenfeld, Peter Morville, Jorge Arango, Information Architecture: For the Web and Beyond (O’Reilly, 4th ed., 2015)。邦訳『情報アーキテクチャ 第4版』（オライリー・ジャパン）
- Project Management Institute, A Guide to the Project Management Body of Knowledge (PMBOK Guide)