サービスづくり

(前編)すぐに使えるディレクターの技術とは?LINE社、ヤフー社等のディレクターが大集結!

ピクシブ株式会社 ピクシブ株式会社
2017.3.30
シェア
ツイート
ブックマーク

サービスの要件定義に進行管理、プロモーションからUI改善まで……。 WEBディレクターとしてプロジェクトをうまく回すために必要な仕事は多岐に渡ります。

しかし、そんな中で 「ディレクションのスキルアップってどうしたらいい?」 「社内にベンチマークとなる人が見つけられない…」 「そもそも自社のディレクション手法が正しいのか不安・・」

なんて悩みを抱えるWebディレクターも少なくありません。そこで、「実際に明日からの業務に役立つ情報をシェアできる交流の場が欲しい!」そんな声から生まれたピクシブ主催のイベント「DIRECTORs' SCRAMBLE vol.1」が、2017年3月9日、代々木のピクシブオフィスで開催されました。

ピクシブ株式会社、LINE株式会社、ヤフー株式会社、クックパッド株式会社、株式会社サイバーエージェント(※ 発表順)のディレクターが集結。同イベントで彼らが語った内容についてお届けします。

ピクシブ社初!大規模チームのチームビルディング

最初の登壇者はピクシブ株式会社の重松裕三。クリエイター向けショップ作成サービス「BOOTH」と、イラスト1枚からグッズを作れるサービス「pixivFACTORY」に関わっており、自身が現場で実践したことを語りました。

通常、ピクシブでは1チームあたり5〜6人で構成しています。 僕のチームは最初10名程度だったのですが、プロダクトの成長とともに、メンバーの 数が増え、2年半の間に26名にまで増加しました。今回は、26名という比較的大きな体制の中、どのようにマネジメントし、チームビルディングをしていったのかをご紹介します。

KPIを設定した上で、どれだけDOできたのかを評価する

スクラム開発においては、通常3~9人規模が適切だと言われています。そこで、僕のプロダクトチームでは役割ごとに更に小さいチームに分け、「Web」「アプリ」「運営」「CS(カスタマーサポート)」の4チームで運用しています。

その中でチーム開発を円滑に進めるために、各チームで主に3つのツールを活用しています。 まず1つ目は、「カンバン」です。カンバンは担当者がどのような作業をしているのかをひと目で把握することができるツールです。誰が何に対して時間を費やしているのかだけが分かればいいので、粒度は大きくしています。

次に、タスクの進捗管理についてです。これには「Trello」を活用し、タスク毎のポイントの見積もり、またそのベロシティの計測を行っています。 そして3つ目のツール「バーンダウンチャート」を使ってグラフを作成し、タスクの進捗状況を可視化したものをSlackに投稿にする仕組みを作っています。 そのスプリントは1週間で回し、週ごとにKPTで振り返ります。

チームの運用方法ですが、僕のチームでは、決まった形ではなくチームごとに合ったやり方をカスタマイズしています。

例えば、リリースが近いアプリ開発チームでは、リリースという目標に向けて必要なタスクを洗い出し、その日やるべきことを朝会で確認し、やったことを夕会で確認しています。

また、CSチームでは、KPIを設定しユーザー体験を改善する施策を行っています。BOOTHはクリエイターがショップを作成するサービスなので、発送する人と受け取る人の間でトラブルが起きることもあります。こうした問題を「◯%以下まで減らす」という感じでKPIを設定し、施策を実施していきます。

こうした短いサイクルでPDCAを回していく中で、DOがすぐにKPIへ影響するとは限らないという問題にぶつかります。KPIという「結果」に影響が及んだかどうかは、コントロールしにくいものです。しかし一方で、どれだけやったかという「行動」については、コントロールしやすかったりします。

僕のチームでは、KPIを頭に置きつつも、「今週はどれだけDOできたか?」という進捗を重点的に追っています。KPIに対して論理的に正しいDOであれば、実施と共に結果はついてくるであろうという考えに基づいて、施策や作業を進めています。

チーム内でのコミュニケーションを密にすべく、エンジニア側へ歩み寄る

僕のチームのCSは、自分でコードを修正して、デプロイまで行うことができるので、ちょっとした文言の改善やCSSの修正は、CS自身で行います。KPIに関連するデータも、CS自身がSQLを使って抽出しています。ユーザーに一番近い場所にいるCSが、エンジニアに強く依存することなくやれることが多いというのは、僕らの強みです。

そういうチームを作っていけるよう、定期的なプログラミング研修を行っており、エンジニアがCSに技術的なことを教える機会を作っています。また、エンジニアに囲まれるような場所に席を作って、CSがエンジニアと気軽にコミュニケーションできる環境を作っています。意識的に、コミュニケーションが生まれるように工夫しているんです。

またエンジニアが普段活用しているGithubのIssueを、CSも活用する文化があります。Issueにやりたいこと、それがどういう目的なのかということを書くと、エンジニア側からも「もっとこうした方がいいかも」、「こういう調査をすると良さそう」という反応がダイレクトに返ってきます。CSとエンジニアのコミュニケーションは、活発な方だと思っています。

1on1の習慣化し、無限に悩むことをなくしていく

ピクシブでは、メンタリングを意識して、定期的にマネージャーと社員で1on1での面談をやっています。その面談での話は、マネージャーと社長にも共有します。

ただ、ディレクターである僕自身にもチームメンバーと1on1で話をする必要があると考えていまして、その時間を週に数度は設けています。 目的は、一人で抱え込みがちな悩みを減らすことです。仕事をしていると、際限なく悩んでしまうことも多く、無駄な時間をなくすために一緒に話をして解決方法を探ります。そのため、面談では主にプロダクトの話をするようにしています。

チームメンバーは常にたくさんのタスクを抱えていて、一人では決められない悩みごとで頭を抱えています。チーム全体を見渡してるディレクターが、チームメンバーへ積極的に関わってサポートしていく姿勢と環境作りが重要だと、僕は思っています。

プラットフォーム企画と想像力

LINE株式会社の伊井壮太郎さん。LINEが提供しているサービス「LINE Beacon」の開発を通じて得られた、企画に関する知見を語っていただきました。

LINE Beaconは、例えばお店などでビーコンを発信すると、お店のクーポン券やお店の情報をメッセージとして受け取れるサービスです。プラットフォームには、ユーザーや会社など、関係する人がいて、そのために汎用的でなくてはいけません。その中で、具体的なユースケースや事業展開などを想像し、企画に落とす必要があります。

プラットフォーム開発については、イマジネーションが重要だと考えています。

「事業展開」について想像する

当初のLINE Beaconのビジネス要件では、ボタン型のビーコンを想定していました。ビーコンにも色々な種類があります。ボタン型では汎用性は得られないので、他のタイプに対応していく必要性を想像できます。

実際に対応したことによって、リリース後の窓口が一気に広がりました。

「オープン化」について想像する

技術的な話をします。LINE Beaconで使っているBluetoothのパケットには、端末の識別子やパスワードといった情報を詰め込んでいまして、検討を進めていく中で、7バイト分の領域が余ったため、どんな用途に使うのか、社内で色んな議論がされました。

こうした中で私は、そもそもLINE Beaconは、過去の他サービス同様、APIを外部の開発者に対してオープン化していくだろう、ということを想像しました。そこで、外部の開発者にとっての柔軟性を上げるため、7バイトの領域の使い道は自由に定義できるようにしました。

狙い通り、LINE BeaconのAPIはMessaging APIの公開に合わせて2016年の半ばにオープン化されました。

「不正利用」について想像する

LINEはクラッキング方法を研究されがちなサービスです。Bluetoothを使っている場合、リプレイアタックなどのセキュリティ脆弱性を突いた攻撃をされないよう、対策が必要です。対策について、LINE Beaconだけでなく、LINEそのもののユーザビリティが下がるということだけは、絶対に避けなくてはいけません。

対策した結果を想像し、LINEのユーザビリティを下げないように進めてきました。

「グローバル展開」について想像する

LINEはグローバルサービスでして、国外での利用者も多く、タイ・台湾・インドネシアでよく使われています。

昨年末には、タイや台湾でもLINE Beaconが公開されています。

LINE Beaconも企画段階で、いずれは国外にも公開されるだろうという想像ができました。あらかじめ、国外の法律や規制等をかなり念入りに調査したことで、法律や規制をクリアしたサービスになっています。

ただ、一点だけ想像できなかった失敗談があります。

LINE Beaconの通知設定できる文字数は20文字という制約を作っていまして、タイ語では文字数が全然足りないという問題が発生しました。文字数で得られる情報量では、日本語のほうが1.5倍から2倍ぐらいあるんです。そこまで事前に想像できなかったのは、私の大きな反省点です。

ディレクターは常に想像し先回りしておくことが重要

LINEでは、3ヶ月以上先の計画を立てない、という空気感でプロダクトの開発を進めています。その時々で、最適なことをやっていくという考えの下、プロダクトを作っています。

とはいえ、今回のLINE Beaconでは、先回りして準備を進めておいたことがリリースに繋がっています。プラットフォーム開発では、あらゆることを常に想像しておくこと、イマジネーションが重要だと考えています。

染み出し型サービス ディレクション

ヤフー株式会社の横田結さん。「myThings」というIoTプラットフォーム開発の企画について、ディレクターが持つべきマインドについて語っていただきました。

IoTプラットフォーム事業では、関わるステークホルダーが多く、今までインターネットに触れたことないという人も巻き込まなくてはいけません。私はこのサービスを、インターネット外の割合が大きいという意味で「染み出し型サービス」だと考えています。今回、ステークホルダーが多い中で、いかにしてサービスを提供してきたかという話をします。

マインドセットとして必要なのは2つあると考えています。「立体的に描く」と「ブラックボックスを置く」です。

立体的に描く

私は企画を、常に立体的に描き考えるようにしています。

例えば「時間、視野、視点、視座、軌跡、余白、水面下」の7つに考えを巡らせます。この観点は時により変わるもので、企画ごとに「この観点は適切か?足りなかったり多すぎたりしないか?」を考えます。

具体例として、担当したmyThings主催の2回の大きなイベントの経験があげられます。両方とも定量的には成功したのですが、1回目のイベントでは「視野」「視点」への意識が不足していました。その結果、伝えたい全体の世界観やメッセージよりも、それぞれのパーツ、要素にお客さまの興味とメディアの注目が集まりました。

2回目のイベントでは、足りなかった2つの観点を足して意識した結果、狙った通りにメッセージを伝えることができました。

ブラックボックスを置く

しかし「立体的に描く」というのは、観点が多く、考える事が非常に多くなりがちです。そのままやると、スピードが落ちるという問題があります。

そこで、考えることを減らしながら適切に導くため、「立体的に描く」中で「ブラックボックスを置く」イメージもします。例えば、可逆性がある所、細かい開発手法などはブラックボックス化して、エンジニアなど他のプロフェッショナルに相談します。サービスのユーザーに近いところに絞って考えることで、企画のスピードを上げています。

ディレクターは一歩先を考えることが重要

今回お話ししたのは、私が考えた発展途上のメソッドです。こういうものを自分で考えた上で使っていくことが重要であるということを伝えたいと思い、私が個人的に考えたメソッドを紹介させていただきました。

既存のカスタマージャーニーマップとか、すでにあるツールを使って企画を作っていくことは良いことです。考えることのコストを下げることができるし、スピードをあげることもできます。ただ、繰り返しサービスを改善していく中で、体系化されていない何かを自分で体系化させていくことも、企画をしていて大切なマインドだと思っています。

いまある手法は今後廃れるかもしれません。しかし、既存のメソッドを取り入れるだけでなく、一歩先を考え体系化し活用するというマインドは、ディレクターとして活動していく上で、一生大事なことになると考えています。

→ 次回: (後編)すぐに使えるディレクターの技術とは?クックパッド社、サイバーエージェント社等のディレクターが大集結!・・・

シェア
ツイート
ブックマーク