The IT Grumble

文字通り、Facebookでリア充たちに言えない愚痴(grumble)を書くためだけのブログ。

WEBプロデューサーという仕事

クソ長い回想(駄文)を書き終わったので、ようやく本題が書けるようになった。重畳。

とりあえず、自分の能力は棚に上げておいて語る(当ブログの大前提であり、これが崩れることはない)と、自分の職種は「WEBプロデューサー」というものに類するはずであり、この職種の果たす役割は何なのかを再度考えてみることにした。

プロデューサーの仕事を定義する前にその他の横文字の役柄の定義を確認してみる。

 

ディレクター

これは分かる。ディレクションする人だ。

文字通り「監督・管理する人」でいい。その通り、ディレクターは仕様に基づいたプロダクトが出来上がるよう、デザイナーやエンジニアなどに指示を出し、制作中は進捗やクオリティをチェックする。また、そもそも仕様書を書いたりもする。

あとはサービスインして以降の運用も彼らの仕事になる。

日々数値を管理し、問題が起きていないかを確認し、何かあればプロデューサーに報告するとともに、エンジニアと調整も行う。まさにサービス運用の主役だ。

 

デザイナー

これも分かる。デザインする人だ。

昨今は細分化されていて、クリエイティブを作る人、UIをデザインする人、会社によってはコーディングをする人もここに入る。個人的にはJSエンジニアなんかもUIにとってクリティカルなので、デザイナーと定義したい。

基本的にはディレクターの指示に基づいて、サービスのフロント部分をデザインするのが仕事になる。

ただし最近は「UXデザイナー」なんていうカッコいいカテゴリの人もおり、羨ましい。ただし基本は一緒で、「ユーザーが触れるところに責任を持つ」のがデザイナーの仕事。

 

エンジニア

これも分かるぞ。エンジニアリングをする人だ。

サービスは大抵なんらかのプログラムやDBを利用して作られているわけで、彼らは仕様書に基づいて要求された仕様を満たす動きをするサービスを作るのが仕事だ。また、開発の管理を行うPMなんかもここに入るんではないかと。

 

他にもプロモーションを行うメンバーや営業担当、コンテンツを作るライターなどもろもろ役割が決まっている人がいて、ひとつのサービスが作られることになる。

ということでプロデューサーの仕事は、前述された人たちの仕事ではない部分にあるに違いないと言うことになる。

 

 

プロデューサーの仕事

前述したいくつかの役割とまったく異なるのは、プロデューサーは、自身で「サービスの本質」を決めなければならないという点にある。

ディレクターが運用を行うにしても、デザイナーがデザインを行うにしても、宣伝担当がプロモーションを行うにしても、そのサービスがどんなサービスで、何を目的にしているかの指針がなければ妥当な作業を行うことは出来ない。

皆さんも経験しているように、ユーザーサポートを行うサービスなのにディレクターがユーザーからの問い合わせを無視していたり、先進的なテクノロジーを売りにしたサービスなのに懐古的なデザインのページだったり(それはそれでアリか?)、若者向けなのに新聞にだけ広告出稿をしたりなどといった的外れな作業が往々にして行われる。

それらは各担当者の能力不足ではなく(むしろ、能力があるから余計なことが行われたりもしてタチが悪い)、プロデューサーがそのサービスの「本質」を伝えられていないことに起因する。

 

プロデューサーはサービスの本質を決定し、それを各担当者に指針として示すのが仕事なのである。

 

もちろん、会社であればマネージメント層から求められて、あまり乗り気になれないサービスを作らされることもあるだろうし、既に失敗したことが判明している年老いたサービスのプロデューサーにさせられることもある。

そんな時でも少ない希望の中からサービスの本質を見出し、担当者に指針を示さなければならないわけで、プロデューサーに必要なのは演技力だったりするかも知れない!

 

本質とは

自分が世界役に立たない学問不動の一位の哲学畑の人間なので、「本質」という言葉をよく使うのであるが、要は

そのサービスがどんな価値を生み出すべきか

という一点に尽きるかと思う。

さらに言うと

「誰に」「どこで」「どのように」

といったところを加えると、だいたいそのサービスの概要が形作られる。

当たり前のように聞こえるが、サービスはこれらが定義されて初めてサービス足りうるものであり、誰にも価値を与えないサービス(我々で言えばサイト・コンテンツやアプリ)は全くもって存在価値がない、そびえ立つクソ以外の何物でもない。

 

企画書を作ろう

であるからして、サービスの本質とそれを補完する情報を揃えてみると、だいたいそれが企画書になる。プロデューサーにとって最初にとりかかる仕事は、企画書をつくり上げることだ。

企画書と言っても、よく想像するような

  • 市場の状況
  • 競合の状況
  • 当社の強み
  • PVやUUの成長予測
  • ...etc

のようなカビ臭い教科書に載っている項目を並べる必要はまったくない。

もちろん、会社や組織によっては上記のような項目を含むフォーマットが決まっていて、しっかりとした稟議を経なければ企画書自体が世に出ない、という会社もあろう。それはそれで、サラリーマンとしては対応はしなければならない。悲しいことに本当に悲しいことに。

 

個人的には、ここで言いたい「企画書」は「コンセプトシート」に近いようなもので、そのサービスの生み出す価値が描かれていれば十分だと考える。

 

例えば、某メッセンジャーサービスについて。

市場:スマートフォンユーザーは拡大中

競合:既に大手企業は独自のメッセンジャーを展開しており、ユーザーも多数

強み:「まとめ」で得たユーザーが多数。でも関係ないかも。

成長予測:他社のシェアをちょっと奪います

...etc

 と書かれた企画書と、

「スタンプ」を使って気軽に気分をやりとりできるメッセンジャー

グループ機能も充実して、メールが中心のコミュニケーションを革新!

電話帳と同期してフレンドを接続するから、ユーザー数爆発!

ポップなキャラと雰囲気で、若年層にバカウケ!

 って書かれた企画書、どっちが惹かれます?って話である。

もちろん前者もビジネス的には必要なので、付ければよろしい。でも「付ければよろしい」ってだけの話なので、まったく企画の本質そのものではない。

 

作らなければいけないからと言って、前者だけを作ってマネージャーにハンコをもらい、ディレクターに仕様書づくりを指示している場面を見ると、なんとも言えない、酸っぱい気持ちが胸にいっぱいに広がる。

 

プロデューサーの仕事は各担当者に本質を伝え、指針を与えることなのだから、彼らの胸に酸っぱい気持ちを広げている暇はない

彼らが自分の能力を発揮したい、と思う企画書を作ることが大切。

  

金を稼ごう

あと、付け加えておくと、サービスの本質としては

自分(あるいは会社)に金を生む

と言うのは価値でもなんでもない

 

一方で、サービスの成功は

  • サービスの生む価値が世の中に受け入れられること
  • サービスが経済的な価値を生むこと

の両輪が揃ってはじめて成功と言えるものであり、どちらかではそのサービスの存続は難しい。

 

ただし、その順は必ず

  1. サービスの与える価値
  2. 価値に紐付いた適切なビジネスモデル
  3. 利益

となるべきで、利益のためにサービスの価値を歪めたり、合わないビジネスモデルを当てはめるためにサービスの価値を歪めることがあってはならない。

例えば上記に続いて某メッセンジャーサービスが、

「もっと儲けたいから、グループ会話機能は有料にしよう」

と決めて実行したとする。

するとどうなるか、明白である。

 

ここまで極端な例ならばさすがに分かることだが、サービスの運用フェーズにおいては、大なり小なり上記のような事態は発生する。

  • 広告クライアントの意向に合わせてコンテンツの方針を変更
  • PVを稼ぎたいために、1ページの内容を無駄に分割
  • 広告に誘導したいから、メニューから主要な機能を落とす

などという分かりやすいものから、逆に

  • 収益が悪化しているから、一部の本質的な機能のひとつを撤廃

なんていう収益をフックにして本質を見失う例は枚挙に暇がない。

 

収益をフックにするのはいい。ただし上記のような事態において、サービスの本質を変えずに収益構造を改善させられるかが、プロデューサーの仕事である。

 

数値を見よう・改善しよう

サービスが出来上がって運用が始まったあと、当然収支はもちろん、サービスの様々な数値を見ることになる。

マネージャーあるいはクライアントに報告しなければならないような定期的な数値の観測はディレクターにお願いするとして、プロデューサーはまた別の観点で数値を見るべきだ。

よくありがちな「PV」や「UU」といったデータはいろんな要素の集合体、最終形でしかなく、PVという数値に至るために様々な要素、確率が組み合わさって、PVを構成している。

プロデューサーは最終形の数値だけを見てサービスを把握しようとせず、その途中にある様々な要素、確率を注視することで、そのサービスがユーザーにどう使われているか、またそれは自分の定めた価値を提供できていると言えるのかを、考えなければならない。

 

最終形としての数値が大切なのではなく、サービスの本質に照らした時に何の数値が動くのか?(あるいは動くべきなのか)ということを考えて数値を観測しなければ全く意味がない。

 

例えば、同じ「1UU・10PV」でも

  • 1人のユーザーが5回訪問して2ページずつ見た結果
  • 1人のユーザーが2回訪問して5ページずつ見た結果

なのかで、ユーザーがどう動いているのかがまったく違うことは分かる。

どちらが正しいということではなく、自分の定めたサービスの本質、理想の使われ方に沿っているかが問題。

ユーザーに、何回も繰り返し来て欲しいのか、それとも1回訪問したらたくさんページを閲覧して欲しいのか(もちろん両方良好なら言うことはないが)、それを意識して自分の観測すべき数値を決め、サービスが想定通り使われているかを把握するのも、プロデューサーの仕事である。そしてもちろん、問題があれば改善を行う。

PVが想定より低いから改善を行うのではなく、PVが低い要因となる数値の動きが、本質に沿っていないから改善を行うのだということを失念してはならない。

 

決して上に言われた通りPV/UUを報告するのが仕事ではないし、最終数値だけを見て改善を行うのが仕事でもない

 

チームに対して、ケツを持とう

あと最後にもう一つ、プロデューサーの大事な仕事は、責任を持つことである。

それは収益的な責任であったり、権限的な話であったりもするのだが、一番大事なことは「チームに対して責任を持つ」ということではないかと思う。

サービスの本質を決め、指針を示すわけであるから、当然その結果はプロデューサーが持つべきであるし、各担当者に押し付けるものではない。

 

プロデューサーは帰結すべき結果を示しつつ、各担当者が十二分に能力を発揮できるよう、各人のモチベーションを管理し、かつクオリティも高めていかなければならない。

よく聞く「今やってるこの仕事、コロコロ指示が変わって誰に聞いてもしっかりした答えが返ってこない」みたいな事態は、プロデューサーとして避けるべき事態の最たるものといえる。

 

 

 

まとめ 

ということで、私の考えるプロデューサーの仕事とは

  • サービスの本質=価値を決める
  • 価値がどう発揮されるかを表すために企画書を作る
  • 定めた本質を元に、各担当に指針を示す
  • 本質に沿った収益化を考える
  • 本質に沿った数値を観測し、改善を行う
  • 責任を持つ

ということのようだ。

 

言うまでもなくこれは自分の経験と環境に基づく私見なので、環境や仕事の内容が変われば、いくらでも変わると思われる。

この話は直接ユーザーにサービスを提供するコンシューマサービスの話を基本としているが、クライアントがいて、クライアントのユーザーに対してサービスを行う受託やSIの場合なら、また話も違ってくるかも知れない。

 

変わらないとすれば、あらゆるサービスには核となる本質・価値があり、それをブレさせずにサービスを運用していく、という点か。 

 

たまたま、こんな記事を見つけた。


ここでは、

そしてディレクターに聞くと一番大切なのが、

・最後はケツを持つだけの責任感

という言葉を聞く。

 と書いておられる。ディレクターという仕事をちゃんと見つめなおして、ちゃんと評価しようという記事で、まったくもって大賛成なのだが、おそらく仕事の性質上、プロデューサーとディレクターが分離していないか、もしくはプロデューサーは別のマネージメント的なことをしていると思われる。

会社や仕事が違えば、各担当の果たすべき役割も変わってくるのだろう、という好例。