非エンジニア・非デザイナーがプロダクトマネージャーになってみた。

非エンジニア・非デザイナーが
プロダクトマネージャーになってみた。
pmjp.slack.comオフ会#9
2017/06/07
Research & Development Unit
Akihiro Ohashi

1© 2017 from scratch Co.Ltd.
自己紹介
画像
株式会社フロムスクラッチ
プロダクトマネージャー
大橋明弘（おおはしあきひろ）
2014年3月東京大学卒業
2014年4月株式会社フロムスクラッチに新卒で入社
コンサルティング部署でマーケティングコンサル
2014年10月 b→dashが生まれ、
マーケティングコンサル＋システム導入＋カスタマーサクセスに範囲拡大
30社～40社ほどを担当
2016年11月開発部署へ異動
2017年1月プロダクトマネージャーへ

自己紹介
画像
株式会社フロムスクラッチ
プロダクトマネージャー
大橋明弘（おおはしあきひろ）
2014年3月東京大学卒業
2014年4月株式会社フロムスクラッチに新卒で入社
コンサルティング部署でマーケティングコンサル
2014年10月 b→dashが生まれ、
マーケティングコンサル＋システム導入＋カスタマーサクセスに範囲拡大
30社～40社ほどを担当
2016年11月開発部署へ異動
2017年1月プロダクトマネージャーへ
社会人4年目、
プロダクトマネージャー歴
5ヶ月のペーペーです…。

会社紹介
■ 会社名
■ 設立
■ 資本金
■ 代表取締役
■ 本社所在地
■ 従業員数
■ 事業内容
：株式会社フロムスクラッチ
：2010年4月6日
：1,872,313,375円
：安部泰洋
：〒160-0023
東京都新宿区西新宿7-20-1
住友不動産西新宿ビル17階
：約150名（業務委託/アルバイト/派遣含む）
：マーケティングプラットフォーム b→dash
：自社内で製品開発・営業・導入・サポートを推進

最近のトピック
Forbes “有望スタートアップ”に2年連続で選出
Topic③
Topic①
元LINE
CEO・森川氏
元PwC
CEO・椎名氏
Topic④
Topic②
2017年、累計約45億円の資金調達を実施アドバイザリーに元・LINE森川氏、椎名氏
「CTO of the year 2016」登壇

プロダクト紹介
マーケティングプラットフォーム

b→dashとは…

b→dashとは…
マーケティングプロセス全体の
データを統合し、一気通貫で活用する
SaaS型のマーケティングプラットフォーム！

b→dashとは…
マーケティング×データという課題に対して、
1つのプラットフォームで解決できる

メジャーバージョンアップ中です！
データ取得から活用、先の展開を見越して
新しい価値を生み出すために、
アーキテクチャから全て作り直そう！
⇓
メジャーバージョンアップ！(新規開発！)

メジャーバージョンアップにあたり…
メジャーバージョンアップにあたって、
既存バージョンや市場の製品で
解決出来ていない課題や、
ユーザーの悩みに詳しい人間を
開発部署に入れたい…
まだクライアントのあんな
悩みやこんな課題を解決
できていない…

メジャーバージョンアップにあたり…
（コンサル部署は大変だけど、
開発に投入しよう）
大橋で!
（開発経験ないけど、
40社くらいのコンサル経験があるか
らいいものつくれるはず）
やります！

本日のテーマ
プロダクトマネージャーになってみた。

大橋のスペック
システム開発経験
デザイナー経験
スクラム開発経験
ナシ。
分析用にマニアックなSQLは叩ける。
ナシ。
Mockを作ることもできず、武器はパワポとエクセルのみ。
もちろん、ナシ。
バックログ？スプリント？横文字が多すぎ…。

大橋のスペック
システム開発経験
デザイナー経験
スクラム開発経験
ナシ。
分析用にマニアックなSQLは叩ける。
ナシ。
Mockを作ることもできず、武器はパワポとエクセルのみ。
もちろん、ナシ。
バックログ？スプリント？横文字が多すぎ…。
…とりあえずやってみよう！

スクラム開発体制
Product Owner
Product Manager Product Manager
Scrum Master Scrum Master
Dev Team
Dev
Team
Dev
Team
Dev Team
Scrum Master

スクラム開発体制
Product Owner
Product Manager Product Manager
Scrum Master Scrum Master
Dev Team
Dev
Team
Dev
Team
Dev Team
Scrum Master
プロダクトマネージャー2名、
スクラムマスター3名、
スクラムチーム4チームの体制

担当領域

担当領域
分析機能と、それに必要な
データマネジメントを担当

まずはやってみよう！
プロダクト戦略/
プロダクトコンセプト策定
機能構成/
Mock作成
バックログ作成
• 戦略/コンセプトのベースがあった
• 現行バージョンの課題や展望も把握していた
• コンセプトを元に機能構成資料（パワポ）を作成
• UIデザイナーに依頼して、Mockを作成（ほぼまるっと依
頼）
• ユーザーストーリーを作成し、バックログに積む
• スプリントにどれだけ入るか分からないので無邪気に積んで
みる

まずはやってみよう！
プロダクト戦略/
プロダクトコンセプト策定
機能構成/
Mock作成
バックログ作成
• 戦略/コンセプトのベースがあった
• 現行バージョンの課題や展望も把握していた
• コンセプトを元に機能構成資料（パワポ）を作成
• UIデザイナーに依頼して、Mockを作成（ほぼまるっと依
頼）
• ユーザーストーリーを作成し、バックログに積む
• スプリントにどれだけ入るか分からないので無邪気に積んで
みる
まずはセオリーに乗っかって、
準備を進めてみる

スプリント1開始！

スプリント1終了
スプリント1で消化できた
ストーリーポイント

スプリント1の結果

スプリント1の結果
見事なまでに平行な
バーンダウンチャート…。

何が起きたのか？？

開発ロードマップが
伝わっていない
仕様が曖昧
スクラムチームとの
コミュニケーションが薄い
スクラムチームのメンバーが、
最終的に何ができて、どの部分をどの順番で、
どんな優先順位で開発すれば良いのか分からず、
戸惑ってしまった
仕様が曖昧でスクラムチームのメンバーの設計が進まず、
効率が著しく下がってしまった
そもそも信頼関係が築けておらず、課題にぶつかったり、
迷ったりした時に気軽に相談できなかった

仕様が曖昧
スクラムチームのメンバーが、
最終的に何ができて、どの部分をどの順番で、
どんな優先順位で開発すれば良いのか分からず、
戸惑ってしまった
仕様が曖昧でスクラムチームのメンバーの設計が進まず、
効率が著しく下がってしまった
そもそも信頼関係が築けておらず、課題にぶつかったり、
迷ったりした時に気軽に相談できなかった
結局、エンジニアが
どんな情報をもとに、
どのように考えて開発するのか
理解できていなかった

（アカン…）

焦りからの迷走
Q. DevTeamが話している内容がぜんぜんわかりません、、、
非同期処理とか、Athenaとか、Prestoとか。。。
僕もオブジェクト指向とか勉強した方がよいですよね？？？
A．まて。オブジェクト指向はいらん（笑）
君が向くべき方向は、ステークホルダーだよ。
認定スクラムマスターホルダーの先輩に相談

焦りからの迷走
Q. DevTeamが話している内容がぜんぜんわかりません、、、
非同期処理とか、Athenaとか、Prestoとか。。。
僕もオブジェクト指向とか勉強した方がよいですよね？？？
A．まて。オブジェクト指向はいらん（笑）
君が向くべき方向は、ステークホルダーだよ。
認定スクラムマスターホルダーの先輩に相談
焦るあまり、迷走…

しかし、試行錯誤の結果

試行錯誤の結果たどり着いたところ

試行錯誤の結果たどり着いたところ
大まかなシステム構成とデータ構造、
データフローをキャッチアップすること、
というポイントにたどり着く

大まかなシステム構成をキャッチアップすることで…
仕様が曖昧
システム構成図をもとに、どのカタマリからどの順番で
開発していくのが一番効率的か、議論できるようになった
ざっくりとしたシステム理解であっても、
エンジニアが開発するにあたり、詰めておくべき箇所
が見える様になった
システムに関する素朴な質問をこまめにしにいくことで
徐々にコミュニケーションが増えた
Before After

大まかなシステム構成をキャッチアップすることで…
仕様が曖昧
システム構成図をもとに、どのカタマリからどの順番で
開発していくのが一番効率的か、議論できるようになった
ざっくりとしたシステム理解であっても、
エンジニアが開発するにあたり、詰めておくべき箇所
が見える様になった
システムに関する素朴な質問をこまめにしにいくことで
徐々にコミュニケーションが増えた
Before After
（未だに細かい所は分からないが、）
ユーザー・ビジネスサイドの要望を
エンジニアが必要な形で
伝えることができるように

スプリント別消化ストーリーポイント
0
90
140
151
72
86.5
97
0
20
40
60
80
100
120
140
160
スプリント1 スプリント2 スプリント3 スプリント4 スプリント5 スプリント6 スプリント7
※チーム人数変更

スプリント別消化ストーリーポイント
0
90
140
151
72
86.5
97
0
20
40
60
80
100
120
140
160
スプリント1 スプリント2 スプリント3 スプリント4 スプリント5 スプリント6 スプリント7
進む開発。
スプリントを重ねるごとに
ベロシティが安定！

開発が進む中、こんなケースに
よく出くわすように

よくあるケースその1
エンジニア
この部分の実装方針で悩んでいます。
Aだと処理が早くてコストが高いけど、ユーザーにとって不便かも。
Bだと処理が遅くて安いけど、ユーザーにとって分かりやすいかも。
大橋
その部分はAで良いです！
なぜなら、その部分は限られた場面しか使わないし、
使うときはコンサルのフォローが入る部分だからです！

エンジニア
この部分の実装方針で悩んでいます。
Aだと処理が早くてコストが高いけど、ユーザーにとって不便かも。
Bだと処理が遅くて安いけど、ユーザーにとって分かりやすいかも。
大橋
その部分はAで良いです！
なぜなら、その部分は限られた場面しか使わないし、
使うときはコンサルのフォローが入る部分だからです！
プロダクト単体ではなく、
プロダクトを含めた「サービス」として
考えられるので意思決定がスムーズに！

営業・コンサル
こういう機能が無いと、
クライアントの要望に応えられないんだけど、
いつ実装できるの？
大橋
いやいやいや。ちょっとまって。本当にその機能が必要なの？
話を聞いていると、それって課題を取り違えていない？
あとこの部分は今ある機能の使い方を変えるという手段の方が
早いしリスク無いよ。

営業・コンサル
こういう機能が無いと、
クライアントの要望に応えられないんだけど、
いつ実装できるの？
大橋
いやいやいや。ちょっとまって。本当にその機能が必要なの？
話を聞いていると、それって課題を取り違えていない？
あとこの部分は今ある機能の使い方を変えるという手段の方が
早いしリスク無いよ。
ユーザーと他部署の課題・願望を
把握できているので
ステークスホルダーとの調整ができる！

まとめると

非エンジニア・非デザイナープロダクトマネージャーのできること
User
BusinessTechnology
“ユーザーの課題を解決する”
“事業として継続可能”“技術的に実現可能”
• ビジネスモデル・コスト構造の理解
• 開発部署以外の課題の理解
• 市場のニーズと競合の強み・弱みの把握
• クライアントのビジネス・業務理解
ユーザーの課題・願望把握
自社の課題・願望把握
ドキュメン
テーション
問題解決
意思決定
/ファシリ
テーション
交渉
/説得 • ビジネススキルを活かしたプロジェクトの推進
• ステークスホルダーのコントロール
プロジェクトの推進

User
BusinessTechnology
ドキュメン
テーション
問題解決
意思決定
/ファシリ
テーション
交渉
エンジニアと異なるスキルや経験が
あるからこそ、「チーム」として動くことで、
ゴールに最短距離にたどり着ける

User
BusinessTechnology
ドキュメン
テーション
問題解決
意思決定
/ファシリ
テーション
交渉
大まかなシステム構成とデータ構造、
データフローをキャッチアップして、
まずは「チーム」の一員となること

User
BusinessTechnology
ドキュメン
テーション
問題解決
意思決定
/ファシリ
テーション
交渉
今後、セールスやマーケター、
そしてコンサルタントという、
プロダクトマネージャーになったとき、
そっとアドバイスを…！

最後に
プロダクトマネージャー歴、若干5ヶ月…。
未だに試行錯誤中なので、
ご助言、ご指摘頂ければ嬉しいです…！

© 2017 from scratch Co.Ltd.
～免責事項～
第三者による、文書の無断転用、引用を禁止いたします。
本資料に記載している情報は、信頼できる情報ソースから取得しておりますが、その内容の正確性、信頼性、完全性、網羅性を保証するものではありません。
本資料に記載している情報による意思決定は、貴社の判断及び責任において行うようお願い申し上げます。

非エンジニア・非デザイナーがプロダクトマネージャーになってみた。

More Related Content

What's hot

Viewers also liked

Similar to 非エンジニア・非デザイナーがプロダクトマネージャーになってみた。

非エンジニア・非デザイナーがプロダクトマネージャーになってみた。