■2017年7月20日 DIRECTORs’ SCRAMBLE vol.2
あんまりディレクター関連のイベントが少ないのですが、
ピクシブさんでディレクター特集をするという事なので、
参加してきました。
ピクシブさんのオフィスには漫画がいっぱい。
悩み：「とにかく業務が多い！効率的に仕事したい…。」【ディレクター業務を200倍楽にする最強ツール活用法】ピクシブ株式会社 高橋孝太郎さん
■自己紹介
2年越しのプロジェクトが失敗
■ディレクター業務
ディレクター業務＝期日内に求められたものを作り世に出す
・トレンドの把握、ユーザー理解
・施策の立案
・要件定義、策定
・上司、クライアントとの調整
・チームビルディング・コミュニケーション能力
・スケジュール管理
・リリース準備（告知・品質保証）
・効果測定、数値計測
■悩みもいろいろ
■ディレクター業務を効率化したい
・トレンドの把握、ユーザー理解
・施策の立案
・要件定義、策定
・上司、クライアントとの調整
・チームビルディング・コミュニケーション能力
・スケジュール管理
・リリース準備（告知・品質保証）
・効果測定、数値計測
下３つ
■ツール導入に向けた問題
・どんなツールを使えばいいかわからない
・チームにあったツールが見つからない
・既に使っている他のツール・サービスとの連携
・コストパフォーマンスをどう定義するか
・利用方法の教育コスト
・チーム外の人間との共有
・使われ続けないと、廃れる
■GoogleSpredsheet最強説
■チームで利用しているツール
・コミュニケーションツール：slack
・業務管理ツール：github / trello
・残り：Google製品
■GoogleSpreadSheetを活用しよう
・どんなツールを使えばいいかわからない
・チームにあったツールが見つからない
>まずはミニマムで始められる
・既に使っている他のツール・サービスとの連携
> 高い連携性能
・コストパフォーマンスをどう定義するか
> 基本無料
・利用方法の教育コスト
> Webの人間ならスプレッドシートはだいたい使える
・チーム外の人間との共有
> Webの人間ならスプレッドシートはだいたい使える
・使われ続けないと、廃れる
> これは努力次第・・
■ミニマム：スケジュール管理
■データの連携が可能
・各種ツールから、データのインポートを簡単に行える。
各種APIが、様々なツールで提供されており、導入も楽。
・例：trello（タスク管理ツール）へのアウトポート
・例：githubからのisuueのインポート
■実際の活用例：リリース
■関数での自動化
・IF / SUM / COUNT / UNIQUE など、関数を利用することで
自動で内容を整理していくことが可能
・IMPORTRANGE関数を使えば、別のスプレッドシートの内容も持ってくることができる
=> 他チームに、タスクごとのスプレッドシートを記入してもらっておいて、
IMPORTRANGE関数でデータをもってくれば、
他チームと同期したスケジュール管理も可能に。
■豊富なアドオン
GoogleSpreadSheetを、さらに便利にする為のアドオンを入れることができる
・おすすめのアドオン
・Google Analytics
・GoogleAnalyiticsのデータを自動で出力してくれる
・ProjectSheet planning
・GoogleSpreadSheetをタスク管理に使いやすいようにカスタマイズしてくれる
・Email Range
・SpreadSheetの内容を自動でメールで送ってくれる
■数値の自動取得・グラフ化
・GoogleSpreadSheetに、GoogleAnalyticsやGoogleBigqueryから
データを取得させて、自動で更新させる。
・自動化したSpreadSheetのデータをGoogleDatastudioを用いてグラフ化することで、
KPIを可視化したビューを簡単に作れる
■まとめ
・GoogleSpreadSheet便利
・具体的な利用シーンや形が見えてから、ツールを導入するのが良い
■質問
エンジニアの人はGoogleスプレッドシート見たがらないのでは？
→連携性が強いので、ギットハブなどのツールを使えば使ってくれるのでは、
ディレクター側が管理するような仕組みを作る。
悩み：「エンジニアとコミュニケーションを改善させたい・・・」【エンジニア上がりのPMが思う、エンジニア・デザイナーのココロの動かし方】ヤフー株式会社 善積 正伍 さん
■自己紹介
burariを開発（Yahoo! Sonomaの非公式後継アプリ）
■About Meetup
問題を解決するための企業コミュニティ
■エンジニア・デザイナーのココロはいつ、どう動くのか
プロダクトの成功イメージを利用者目線で想像できるとき
■ひとつひとつの施策に落とし込んでも、成功イメージが想像できるコミュニケーションが大事
→成功イメージが少しでも現実になったら伝える
■DAUや継続率といった指標の達成ではなく、
プロダクトの実現したいことが現実になっている
■ココロを動かすきっかけにMVPを活用する。
MVPでも成功イメージは想像できる。
■逆にココロがうごかないときは・・・
利用者目線の成功イメージが想像できないパターン
特に手段が目的化してしまう際に起こりやすい。
手段を伝えるのはデザイナー・エンジニアの仕事
■エンジニア・デザイナーのココロを動かす付き合い方
・手段はまず任せて成功イメージを語る
・なぜそれがいいのか語ってもらう
・価値基準を個人に依存させない
■まとめ
・ プロダクトの成功イメージを利用者目線で想像させる
・成功イメージが少しでも現実になったら伝える
・ココロ動かすために、MVPへコストをかける価値はある
・手段はまず任せる。なぜそれがいいのか語ってもらう
・価値基準を個人に依存させない。顧客に依存させる
■質問
・クライアントワークなどだとクライアントからの要望で手段が決まってしまうことがあるのでは。→クライアントの先にいるユーザーをエンジニアに想像させることができるか。
・MVPはどのようなものを作ってるのか。
→burariの場合はものがない状態でもMVPとした。
悩み：「チーム体制の変化に対応しきれない！」【一年でチームメンバーが激増、スピードを落とさず戦闘力を保つために挑戦したこと株式会社マッチングエージェント 新居 朋子さん
■マッチングエージェント
→サイバーエージェントの子会社
→キーコンセプト：趣味でつながるマッチングアプリ「タップル」
→会員数は２００万人突破
■機能開発の基本的なチーム構成
・アナリスト、プランナー
・ディレクター
・デザイナー、エンジニア
・テスター
■スタートダッシュ期
・約15名
・ややアジャイル、２週間のイテレーション、出来次第リリース
・とにかくスピード最優先
■拡大期
・約30名
できることは増えたが
・今、何をすべき？
・直前でバグが
・次のリリースは？
・この仕様ってどうなってる？
※ディレクターとは
チームをまとめ
成果物の品質と期日に
責任をもつ人。
■パフォーマンスは絶対落としたくない
やったこと
（1）画面仕様書のフォーマット化
（2）テストケースの早期レビュー
（3）ディレクターによる厳密なスケジュール管理・スコープの調整
ある日思ったこと・・・・
→倒れたらどうしよう・・・
ディレクターがシングルポイント！？問題
→開発推進体制を一新してディレクションのロールをスケールアウトさせよう
■推進責任者のロール
ディレクターによって一元集約していた開発推進を、
各開発ラインで機能させるようにした。
<推進責任者のミッション>
担当施策の品質と期日に責任をもつ
<主なアクション>
見積もり、スケジューリング、進捗確認、 全体への共有
<誰がやってる?>
主に技術者で、ディレクションスキルを 備えているメンバー
■Goodとproblem
Good
・期日と品質に対する一人一人の意識が高まった
・開発ラインごとに主体的に推進していくようになった
・うまくワークできればこのまま開発ラインが増やせる
Problem
・開発しながらチームのディレクションは負担になる
・全体把握のためのステップが多くなる
■まとめ
期日と品質を守るというディレクターのミッションを忘れない
・昨日までのルールに固執しない
・パフォーマンスの変化に対し常にアンテナを張っておく
■質問
・同じくらいのプロジェクト管理しているのだが、
リソース配分はどうしているのか。ツールは何を使っているのか。
→リソース把握チームがいる。
スプレッドシートを使っているのだが、使いにくい。
リソースもガントチャートとして可視化している。
・推進責任者はどうやっている。なぜエンジニア
→推進責任者に見積もりをしてもらっている
（エンジニアのほうが制度が高い）
・推進責任者がいるが、増えるだけコミュニケーションコストが増えるのでは？
→細かい単位で毎日チェックするのがいい。スラックを使っている。
■パネルディスカッション
▼エンジニア職なのでディレクターがエンジニアに対して期待していることや、困っていることを知りたい
期待していること→ディレクターの思っている通りに作って欲しい、
エンジニアが作っていく中で、ユーザーのことなどを考えてよいものを作って欲しい。
・なんでも率直に話して欲しい。
・ディレクターの期待を裏切ることを期待している。
ウルトラCを期待する。チャレンジして欲しい。
もしかして出る120点を目指して欲しい。
▼三年後に求められるスキルとは何か
・いま求められていることをできることが大事では。
・3年後もディレクターの使命は変わらないが、
新しい技術などがでてくるかもしれない。
・どうゆうユーザーにものを届けるのが大事なので、
それをアウトプットできる技術。
▼ディレクターが行う仕事と開発陣が行う仕事の線引きを他社はどうやっているのか。
・ピクシブさんではそこまで開発とディレクターの区分けはない。
・開発に関わるメンバーによりかわってくるのでは。
・チームによって変わる。いかにその人の強みに気付けるか。
▼社内にディレクターが少ないので、みなさんがどのような仕事の
進め方をされているのか知りたいです。
・エンジニアができるディレクターとディレクションができるエンジニアが
いたら、どうするべきか。
ディレクターがすくないのは強みでもあるし弱みでもある。
・ディレクターがアウトプットまで進めることは変わらない。
・チームに寄らざるを得ない。
最終的にユーザーにちゃんとしたものを届けることが大事。
▼コードをかけないディレクターがエンジニアと
うまくコミュニケーションをとる方法を知りたい
・英語を話せない人が英語を話す人にコミュニケーションとるには、
お互い歩み寄るしかない。
・歩み寄りが大事。コードが書けずとも概念を理解するなどの努力は必要
・コードをかける必要があるのか、ディレクターとしてどうあるべきかを考えるべきでは。日本でもいろいろなプロダクトが出ているので、もちは餅屋に任せるのがいいのでは。コード書くよりもいろいろんなアプリを触ったほうがいい。
▼今後ディレクターとして成長していく上で得るべき経験や知識について。
・ひたすら場数を踏み、振り返る。
・現場で経験してみるのが最良。
仕事を任せられるようにひとつひとつの仕事を大事にしていく。
▼自分がなんでも屋で「これがスキルだ！」と
わかりやすいものが作れてないこと。
・ディレクターの仕事だと自分の作ったものがユーザーに届いているのであればいい。
・スキルを表現しにくい役職。この人にプロジェクトを任せれば大丈夫というイメージを持ってもらう。
・困っていることがあればそれを伸ばすべき。
▼業務効率を上げるため色々なツールを導入、検討しているが、
なかなか良いものが見つからない。
・Googleスプレッドシートとか、みんな使うものはそんなに変わらない。
・いまの進め方についてどこが課題なのか解決する必要がある.
ツールに感度の高いメンバーに聞く.
・小さいプロジェクトで試してみる。
▼エンジニアですが、ディレクターやデザイナーとの咀嚼を
うまく調整できない事がたまにある。
・エンジニア一人では解決できないのでお互いが壁打ちしてみる。
▼常に新しいトレンドをキャッチしたいが、なかなか時間が取れない
・まずは日本のアカウントだけではなくアメリカや中国のアプリを見る。
習慣化する
▼業務について、実際にやってみてのトライアンドエラーでしかなく、
知識やノウハウの共有が難しい。
・トライアンドエラーはしょうがないのでは。
知識やノウハウの共有はテンプレートに落としてみたりしてビジョンを共有する。
■ビアバッシュ的な懇親会
懇親会とかぼっちだったけど、
ありがとうございました。
コメント