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

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

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

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

ディレクター業務を200倍楽にする最強ツール活用法
ピクシブ株式会社　高橋孝太郎

pixivのグロースハック担当を経て、現在はpixivのPC版、スマホートフォン版のプロダクトマネージャーをやっている高橋といいます。今日はよろしくお願いします。

さて、基本的なディレクターの仕事とは、決められた期日内でモノを無事に出すことだと思います。そこにあるディレクター業務の問題点は「やることが色々ありすぎること」ですよね。今回の勉強会に際して、参加者の皆さんからディレクション業務のお悩みについて聞きました。軽く集計したんですが、種類がさまざまで本当に多岐に渡るんです。例えば、エンジニアやデザイナーとのコミュニケーションに関する悩みとか、複数のプロジェクトをうまく回していきたいとか。エンジニアとデザイナーがモノを作る以外はほぼディレクターが関わっているのかなと思います。

その多岐に渡る業務をなんとか効率化したいという悩みはみなさんお持ちだと思うので、今回は僕がpixiv開発チームで使っている効率化ツールのお話をします。

たどり着いたのは「Google SpreadSheetが最強説」!?

事前にこの勉強会の参加者のみなさんから集めたお悩みの中にも散見されましたが、チームで使うツールの導入についてはいろいろな悩みがあると思います。僕たちのチームもツール導入については試行錯誤したのですが、最終的にたどり着いたのはなんだかんだGoogle SpreadSheetが最強説です。なぜかというと、ツール導入に向けた問題とその解決って、この通りGoogle SpreadSheetでほぼ解決すると思うからです。

1）どんなツールを使えばいいかわからない、チームにあったツールが見つからない
=>まずはミニマムで始められる

2）既に使っている他のツール・サービスとの連携
=> 高い連携性能

3）コストパフォーマンスをどう定義するか
=> 基本無料

4）利用方法の教育コスト
　=> Webの人間ならスプレッドシートはだいたい使える

5）チーム外の人間との共有
=> Webの人間ならスプレッドシートはだいたい使える

6）使われ続けないと、廃れる
=> これは努力次第……。

▲ 実際に使っているpixiv閲覧体験チームのガントチャート。

データの連携が可能

また、Google SpreadSheetに各種ツールからデータのインポートを簡単に行えるってことはかなり強いです。各種APIが様々なツールで提供されており、導入も楽。例えばうちのチームでの例なんですが、こんな感じの連携をしています。
１）Trello（タスク管理ツール）へのアウトポート
２）GitHubからのissueのインポート

▲ ある機能のリリース前社内レビューで使ったレビューシートです。ここで得られたレビューをTrelloに入れてレビュー対応の管理をします。

あとは、他チームに、タスクごとのスプレッドシートを記入してもらっておいてIMPORTRANGE関数でデータをもってくれば、他チームと同期したスケジュール管理も可能になります。他チームと連携が必要になるチームにとっては、お互いの進捗を共有できるのでかなり有効だと思います。

さらに、Google SpreadSheetさらに便利にする為のアドオンを入れることができます。さまざまなアドオンがありますがその中でもオススメはこれ。

■おすすめのアドオン
・Google Analytics
Google Analyiticsのデータを自動で出力してくれる

・ProjectSheet planning
Google SpreadSheetをタスク管理に使いやすいようにカスタマイズしてくれる

・Email Range
Google SpreadSheetの内容を自動でメールで送ってくれる

以上、Googleの回し者のようになってしまいましたが（笑）。ツール導入は、実際の利用シーンが見えてきてから導入するのが無駄なくスムーズかと思っていて、ミニマムに始められるという意味でGoogle SpreadSheetをおすすめします。

エンジニア上がりのPMが思うエンジニア・デザイナーのココロの動かし方
ヤフー株式会社　善積正伍

ヤフー株式会社の善積（よしづみ）です。CMO-Boardキャプテンという肩書きで、会社全体のモバイル戦略を推進する仕事をしています。僕は元エンジニアで、現在でもプライベートでは友達と行きたいところを共有できる「burari」というアプリの開発をしています。

エンジニア・デザイナーのココロはいつ・どう動くのか

早速タイトルにある「エンジニア・デザイナーのココロの動かし方」について話していくのですが……。エンジニアやデザイナーが「プロダクトの成功イメージを利用者目線でイメージできること」が大事だと思っています。各プロダクトのミッションをひとつひとつの施策に落とし込み、その施策がプロダクトの成功イメージにどう近づけられるのかを、エンジニアやデザイナーが自分たちで実現したいと思えるようにすることがプロダクトマネージャーの仕事です。

例えば、今僕が携わっているお出かけアプリ「burari」の話でいうと、アプリの中で見つけて遊びに行ったところで楽しい時間を過ごせることが利用者目線での成功イメージ。 Meetupで言えば、自分たちが感じている課題や問題がそれに行ったことで改善されるってことが利用者目線での成功イメージです。そういった、エンジニア・デザイナーの稼働によって何が成し遂げられるか？ということをきちんと伝えることが大事だと考えています。さらに、褒め称える……というとちょっと変ですが、少しでも成功イメージに近づいていたら、それを伝えることも大事です。 DAUや継続率といった数値ベースの指標の達成ももちろん大切なのですが、ココロを動かすときには数値よりも「インドア派カップルの行動範囲が広がって楽しんでくれてる」といったような、成功イメージに近づいていることを伝えていくほうが有効だと思います。

ココロを動かすきっかけにMVPを使う

MVPとは、Minimum Viable Productの略で、「検証に必要な最低限の機能を持った製品」という意味です。アプリを作り切らなくても、紙芝居レベルで「こういうことを味わってもらいたい」っていうのを話すことでモチベーションを共有し、エンジニア・デザイナーの「ココロを動かす」んです。逆にココロが動かないときっていつだと思いますか？
それは、利用者目線の成功イメージが想像できないときだと思います。特に、手段が目的化してしまうとき。ディレクターは、そのプロダクトを使った先の成功イメージを伝えるのがとにかく大事で、どういうUIにしたいだとか、どういう実装にしようだとか、そういった「手段」を考えるのはまずエンジニア・デザイナーに任せるべきこと。下手したら彼らの役目を奪ってしまうことにもつながりかねません。まず任せたうえで、彼らのアウトプットに対して「なぜこれがいいと思ったのか」を語ってもらうことが大事です。仮に「これ、イケてない……」とディレクターが思ったとしても、それは自分個人の価値基準。それがサービスを使う顧客と合致するとは限らないので、まず作り手の意図を語ってもらいましょう。

1年でチームメンバーが激増！スピードを落とさず戦闘力を保つために挑戦したこと
株式会社マッチングエージェント　新居朋子

サイバーエージェントの子会社、株式会社マッチングエージェントで趣味で繋がる恋活アプリ「タップル誕生」の執行役員・開発ディレクターをしています、新居です。「タップル誕生」は会員数が2月に200万人を突破し、もうすぐで250万人突破という急成長を遂げていて、それに伴い開発メンバーも1年で2倍になりました。

この2年間、チームが急激に拡大していったのですがそこでの成長過程に沿って起こった問題・そのために行ったことを紹介したいと思います。

■スタートダッシュ期
15人の開発チームで、2週間スパンのアジャイル開発をしていました。出来次第リリースをしていたのでとにかくスピードはありました。しかし、仕様把握が属人化していたり、仕様策定のドキュメントが整備されていませんでした。何はともあれ、早めの開発の甲斐あってサービスは伸び、チームはどんどん大きくなっていきました。

■チーム拡大期
メンバーも30人ほどに増え、開発ラインが増えました。しかし次の施策をしたいときに何をすればいいのか？誰をアサインすればいいのか？が可視化されていませんでした。さらに、新しいメンバーがジョインしたときに既存のルールを把握してもらうドキュメントがなかったりと、スタートダッシュ期の少人数時代にできたことが、だんだんできなくなってきました。

ディレクターの仕事とは「チームをまとめ成果物の品質と期日に責任を持つ」
絶対にパフォーマンスを落としたくない！と思い行ったことは3つです。

1）画面仕様書のフォーマット化
=> 書き方が属人化していた＆抜け漏れが多かったので仕様書を触るメンバーにアンケートをとりつつ「誰が書いても抜け漏れを極力無くした仕様書」のフォーマットを作った。

２）テストケースの早期レビュー
=> 完成度の高いテストケースをだすことで、あらかじめ計画したテスト期間に回収できないという事態を防ぎ、スケジュールが間延びしないようにしました。

３）ディレクターによる厳密なスケジュール管理・スコープの調整
=>全開発ラインのスケジュールをデイリーで可視化。

「ある日、私が会社にこれなくなったら・・・」

チームが拡大していく中で、ふと自分が「突然病気になったりしたら…」と考えました。ディレクターの私自身がシングルポイント化していると思ったのです。そこで、開発推進体制を一新して、ディレクションの役割を他に分配することに踏み切りました。今までディレクターが一元管理していたことを「推進責任者」委託することにしたのです。
推進責任者のミッションは担当施策の品質と期日に責任を持つこと。
主なアクションは見積もり、スケジューリング、進捗確認、全体への共有。
そして誰に任せたかというと、ディレクションスキルを備えている技術者です。