営業組織の中にエンジニア組織を立ち上げるコツを、私自身の経験からお伝えする資料です。

1. 営業組織の中に
エンジニア組織を立ち上げる方法
小越崇広
株式会社AJA 取締役
@ogoshi
@LINE Sales × Product Manager Meetup
2018.09.08

2. 自己紹介 小越崇広( @ogoshi)
・2005年にサイバーエージェントに新卒入社
・株式会社AJAのプロダクト担当役員。シャドウバースグランドマスター
・非エンジニア、本業はマネージャーです。
コード一切読めません。ER図、シーケンス図、コンポーネント図は理解できます
・立ち上げ、マネジメント経験
エンジニアチーム:イマ6チーム目
それ以外の職種:無数にやっています。
2

3. My recent
Works
3

4. House Keeping!
・今日の資料は公開済みです。
・懇親会にもいますので、その時に今日の発表
をネタにいろいろお話できると嬉しいです。
4
@ogoshi でURLツイートします。

5. House Keeping!
私事ですが、おととい誕生日でした！
5

6. House Keeping!
私事ですが、おととい誕生日でした！
初対面の方からでも誕生日プレゼントは
受け取るポリシーですので、遠慮せず！
6
【参考】
近隣の百科店
©Google,ZENRIN
You are here!

7. 今日のテーマ
営業とPMのパワーバランス別でのPMがやるべき事

8. 今日のテーマ
営業とPMのパワーバランス別でのPMがやるべき事
営業＞PM
営業＝PM
営業＜PM

9. 今日のテーマ
営業とPMのパワーバランス別でのPMがやるべき事
営業＞PM:これが一番大変
営業＝PM:こういう組織はあまり無い
営業＜PM:本業に集中できる

10. 今日のテーマ
営業とPMのパワーバランス別でのPMがやるべき事
営業＞PM:これが一番大変←ここ中心に話します
営業＝PM:こういう組織はあまり無い
営業＜PM:本業に集中できる

11. 今日のテーマ
営業とPMのパワーバランス別でのPMがやるべき事
営業＞PM:これが一番大変←ここ中心に話します
【今日話す事】
あなたがある時突然、営業組織の中に技術組織を
立ち上げる事になったら、どうすると良いかの話。

12. チーム立ち上げは以下の4つの経験からお話します。
・営業組織の中にエンジニア組織を立ち上げる（2回）
・営業組織の中のエンジニア組織の立て直し（1回）
・テック主導のエンジニア組織作り（1回）
営業とPMのパワーバランス別でのPMがやるべき事
今日のテーマ

13. アジェンダ
前提条件の整理
営業＞PMの組織に技術組織を創る
初期のゴールセッティング
ゴール達成の為にするべきこと
初期ゴール達成後
営業＜PMバランス
落とし穴とその対処

14. アジェンダ
前提条件の整理
営業＞PMの組織に技術組織を創る
初期のゴールセッティング
ゴール達成の為にするべきこと
初期ゴール達成後
営業＜PMバランス
落とし穴とその対処

15. 前提条件の整理
プロダクトマネージャー
プロダクトの成功に責任を持つ人

16. 前提条件の整理
プロダクトマネージャーとしてやってる事
ピープルマネジメント
-採用・コンディショニング・目標/査定
プロダクトマネジメント
-事業計画の策定と実行・プロダクト計画の策定と実行
ステークホルダーマネジメント
-上長への報連相・営業との計画すり合わせ
やってない事
プロジェクトマネジメント（得意な人に任せてる）
-納期の管理、チケットの管理
エンジニアリングマネジメント(テックリードが担当)
-技術選定、アーキテクチャ設計、開発プロセス管理

17. 前提条件の整理
私の経験は、
エンジニア0名からゼロから創ったのは1回で、
後は既に数名いるところから20-30人の
ところまでスケールさせてます。
また、全て広告系のプロダクト経験です。
なので、それをベースに話します。

18. それでは本題に入ります。

19. アジェンダ
前提条件の整理
営業＞PMの組織に技術組織を創る
初期のゴールセッティング
ゴール達成の為にするべきこと
初期ゴール達成後
営業＜PMバランス
落とし穴とその対処

20. 初期のゴールセッティング

21. 初期のゴールセッティング
通常の開発が回る状態を作る

22. 初期のゴールセッティング
通常の開発が回る状態を作る
・目指すべきゴールがあり
・やることに優先順位がつけられ
・方法が議論できる

23. 初期のゴールセッティング
通常の開発が回る状態を作る
・目指すべきゴールがあり
・やることに優先順位がつけられ
・方法が議論できる
大体できない状態になっている

24. 初期のゴールセッティング
通常の開発が回る状態を作る
・目指すべきゴールがあり
・やることに優先順位がつけられ
・方法が議論できる
大体できない状態になっている
何故？

25. 通常の開発が何故できないか？
営業組織の中のクリエイター組織
には最初は3つのRが無い(断言)
Re-plan
Review
Respect

26. Re-plan

27. Re-plan:プランの再策定
仕様や事情が変わったらリプランする。
もちろん、遅延を正当化する訳ではなく、
品質と納期のバランスをちゃんととろう、
という話。
通常の開発が何故できないか？

28. Re-plan無いあるある
通常の開発が何故できないか？
営業「これやりたい」
エンジニア「おかのした」
営業「どれくらいでできる？」
エンジニア「2ヶ月すかね」

29. Re-plan無いあるある
通常の開発が何故できないか？
営業「あ、これ追加」
営業「えっと、これ変更」
営業「えーなんか違う」
・・・2ヶ月後・・・
営業「なんで出来てないの！！
遅延遅延！！！」

30. Re-plan無いあるある
なぜか良く聞くセリフ
「できない理由じゃなくて、
できる方法を考えろ！」
＊普通、未知の挑戦について使うセリフであって、
できない直接の原因になってる人が言うことじゃない。
通常の開発が何故できないか？

31. Review

32. Review:開発へのフィードバック
つくり手は、作ったものに愛情があるもの。
リリースの結果の反応はやっぱり知りたい。
また、営業のオーダーベースではなく、
「効果」や「売上」をベースに何を作るか
決めたいというのは正当な欲求。
通常の開発が何故できないか？

33. Review無いあるある
通常の開発が何故できないか？
営業「これやりたい。最短でやりたい！
これはすごいことになるよ！革命！」
エンジニア「おかのした」
・・・リリース・・・
営業「今度はこれやりたい！」
エンジニア「お、おかのした・・・
(ねえ、革命は？革命は起こったの？)」

34. Review無いあるある
なぜか良く起こる現象
「急いでつくりたい！！と
急かされた機能の受注が
一向に入らない。」
通常の開発が何故できないか？

35. Respect

36. Respect
これらは要するに、
エンジニアへの不理解
ものつくりへの不理解
から来る。
通常の開発が何故できないか？

37. 初期のゴールセッティング
通常の開発が回る状態を作る
3つのRを実現する
・Re-plan
・Review
・Respect
・目指すべきゴールがあり
・やることに優先順位がつけられ
・方法が議論できる

38. ゴールを達成するためにする事

39. ゴールを達成するためにする事
・信頼を得る
・ちょっとずつ開発文化を創る

40. ゴールを達成するためにする事
・信頼を得る
・ちょっとずつ開発文化を創る
ゼッタイこっちが先！

41. 信頼を得るのが先なのはなぜか？

42. 信頼を得るのが先なのはなぜか？
みんなから、
お前誰？って思われてるから。

43. 信頼を得るのが先なのはなぜか？
みんなから、
お前誰？って思われてるから。
権限がない人が実績も無しに変えられるほど組織は甘く無い。

44. 信頼を得る
・初動の成果
・着任直後の1on1
・営業文化を理解する

45. 信頼を得る
・初動の成果
・着任直後の1on1
・営業文化を理解する

46. 初動の成果
一番大切なのは、
まず分かりやすい成果を出すこと。
あるべき論にこだわらなくても。

47. 初動の成果
一番大切なのは、
まず分かりやすい成果を出すこと。
あるべき論にこだわらなくても。
例)エクセルのマクロを作る、というのは本来エンジニアリング
組織の仕事でないかもしれないけど、工数削減が見込めるなら
やっちゃう。

48. 初動の成果
過去の初動例
・分かりやすくクリック率を上げる
・営業と協力して大型受注

49. 初動の成果
お前誰？から、
あ、役に立つ人かも？へ。

50. 信頼を得る
・初動の成果
・着任直後の1on1
・営業文化を理解する

51. 着任直後の1on1
・チーム内、チーム間の雰囲気と
テコ入れどころを特定する
・簡単に解決できる課題は
すぐ解決しちゃう
初動と平行で行いましょう。自チームと周辺チーム、
両方やるとよいと思います。

52. 着任直後の1on1
「質問例」
・困ってる事ありますか？
・今の組織課題ってなんだと思います？
・この仕事、どういう時にやりがいを
感じますか？
・よりプロダクトを伸ばす為に、あなた
だったら何をします？

53. 着任直後の1on1
・チーム内、チーム間の雰囲気と
テコ入れどころを特定する
どこに手を付けるべきかを特定する。
アクションを起こすのは、信頼を得られてから

54. 着任直後の1on1
・簡単に解決できる課題は
すぐ解決しちゃう
例えば、備品が欲しいとか、そういう簡単なもの
はすぐやってしまう。チーム間の問題も簡単なや
つはすぐに解決。言えば動いてくれる、という
小さな信頼があると、今度からも言ってくれる。

55. 着任直後の1on1
・簡単に解決できる課題は
すぐ解決しちゃう
特に、売上、利益の目標が自分に無い時には
こっちを積み重ねながら、他の人の売上を
アシストすると良い。

56. 問題をちゃんと解決してくれる人
と認識してもらう
着任直後の1on1

57. 信頼を得る
・初動の成果
・着任直後の1on1
・営業文化を理解する

58. 営業文化を理解する
・営業同行
・カラオケ

59. 営業同行
客先に連れてってもらう。
プロダクトの生の評判を知るチャンス。
営業との雑談にもヒントが埋もれてる。
意外と、プロダクトマネージャーが行くと
喜ばれるケースも。

60. カラオケ

61. カラオケ
歌って踊れば
みんな仲間！

62. 営業文化を理解する
重要なポイント。営業は役割が
違うだけで別にモンスターではない
お互いの仕事に寄与しあうことを
PMが率先しよう。

63. 信頼を得る
・初動の成果
→お前誰？の脱却
・着任直後の1on1
→信頼を積み上げる
・営業文化を理解する
→相互寄与！

64. ゴールを達成するためにする事
・信頼を得る
・ちょっとずつ開発文化を創る

65. ちょっとずつ開発文化を創る
いきなり、教科書どおりの
ベストプラクティスを実行しよう
と思っても無理。
ちょっとずつ慣らして、
最終的にベストを目指す

66. ちょっとずつ開発文化を創る
例えば、review
STEP1 リリース物のフィードバックを聞くようにする
STEP2 リリース後の「効果」を予め決めて、追う。
(あれ？○○さん、売上2倍って言ったのに3,000円ですよ！)
STEP3 リリース前に「効果」を予測して目標化する
STEP4 事前に創るべきか、創るとしたらどのような
機能だと効果が最大化されるか議論する

67. ちょっとずつ開発文化を創る
例えば、re-plan
STEP1 根拠の無い「今日中」「今週中」を無くす
STEP2 依頼窓口を自分に統一する
(エンジニアはエンジニアリングに集中できるように)
STEP3 変更時にはリリース日程の変更有無も議論する
STEP4 リリース計画をお互いに共有し、今あるリソー
スをどこにかけるべきかを一緒に議論する

68. ちょっとずつ開発文化を創る
Respectは、仕事を通じて培われる。
成果が上がり、それを一緒にできていたら
お互いが尊重できるようになる。

69. ゴールを達成するためにする事
・信頼を得る
・ちょっとずつ開発文化を創る
手を変え品を変え信頼を得ながら、
ちょっとずつ文化を創る。

70. アジェンダ
前提条件の整理
営業＞PMの組織に技術組織を創る
初期のゴールセッティング
ゴール達成の為にするべきこと
初期ゴール達成後
営業＜PMバランス
落とし穴とその対処

71. 初期ゴール達成後
・フラッグシップを持とう！
・スケールに備えよう
・製品ロードマップを持とう

72. フラッグシップを持とう！
これまでの話はどちらかというと
マイナスをゼロにする話。
初期ゴールを達成する上で得た情報
を元にして、プロダクトを前進させ
る大きめの開発にとりかかる。

73. フラッグシップを持とう！
これまでの話はどちらかというと
マイナスをゼロにする話。
初期ゴールを達成する上で得た情報
を元にして、プロダクトを前進させ
る大きめの開発にとりかかる。

74. フラッグシップを持とう！
大きめの開発のいいところ。
・自然とチーム全員でひとつの
目標を見ることになって
まとまりやすい。
・当たると、リターンが大きい。

75. 初期ゴール達成後
・フラッグシップを持とう！
・スケールに備えよう
・製品ロードマップを持とう

76. スケールに備えよう！
初期ゴールを達成すると、
今度はチームサイズが大きくなる。
スケールに備えよう。
(そこらへんの苦労話は下記資料に)
『広告プラットフォーム立ち上げ百鬼夜行』
https://www.slideshare.net/TakahiroOgoshi/ss-80311897

77. 初期ゴール達成後
・フラッグシップを持とう！
・スケールに備えよう
・製品ロードマップを持とう

78. 製品ロードマップを持とう
長期の計画についても、
議論できる状態になってるはず。
目指すべきプロダクト、世界を
定義して、ドキュメントに落とそう。

79. 営業＞PMバランスの時
初期のゴールセッティング
まず通常の開発ができる状態を目指そう
３Rの担保
ゴール達成の為にするべきこと
信頼を得ましょう
ちょっとずつ開発プロセスを整えましょう
初期ゴール達成後
大きい開発＝フラッグシップを持とう
スケールに備えよう

80. 営業＞PMバランスの時
話さなかった事
・メンバー編成と採用はもちろん重要。
ですが、これは深いのでまた別に・・・

81. アジェンダ
前提条件の整理
営業＞PMの組織に技術組織を創る
初期のゴールセッティング
ゴール達成の為にするべきこと
初期ゴール達成後
営業＜PMバランス
落とし穴とその対処

82. 営業＜PMバランス
良いところ
差し込みなどを適切に仕分けできる
長期プランを最初から建てられる
などなど・・・

83. 営業＜PMバランス
良いところ
差し込みなどを適切に仕分けできる
長期プランを最初から建てられる
などなど・・・
エンジニアアリングに集中しやすい良環境

84. 営業＜PMバランス
欠点。

85. 営業＜PMバランス
欠点。
PMが怖い。

86. 営業＜PMバランス
欠点。
PMが怖い。
気軽な相談ができない
簡単にいうと煙たい

87. 営業＜PMバランス
欠点。
PMが怖い。
気軽な相談ができない
簡単にいうと煙たい
営業から正しい情報が入ってこず、
プロダクトが緩慢に死ぬ可能性

88. 営業＜PMバランス
PM怖いあるある
PM「新機能どう？」
営業「最高っす！」
PM「でも売れてなくない？」
営業「それは自分達の努力不足っす！」
(・・・競合にスペック負けてるけど)

89. 営業＜PMバランス
PM怖いあるある
PM「新機能どう？」
営業「最高っす！」
PM「でも売れてなくない？」
営業「それは自分達の努力不足っす！」
(・・・競合にスペック負けてるけど)
もちろん、営業論としてあるもので最大の努力を
する、というのは良い。
だけど、PMが自社プロダクトの客観評価から
目をそらして良いというわけじゃない。

90. 営業＜PMバランス
じゃぁどうするか？

91. 営業＜PMバランス
じゃぁどうするか？
PMが笑う。

92. 営業＜PMバランス
じゃぁどうするか？
PMが笑う。
余計怖い・・・。

93. 営業＜PMバランス
耳年増を重用する。
チームの誰か、チーム外の誰かでやたら営業と
コミュニケーションが取れる人に代わりに風評
を集めてもらう。

94. 営業＜PMバランス
耳年増を重用する。
チームの誰か、チーム外の誰かでやたら営業と
コミュニケーションが取れる人に代わりに風評
を集めてもらう。
又聞きの本音は、
直接の建前よりも100倍有用。

95. まとめ

96. 初期のゴールセッティング
通常の開発が回る状態を作る
3つのRを実現する
・Re-plan
・Review
・Respect
・目指すべきゴールがあり
・やることに優先順位がつけられ
・方法が議論できる

97. 信頼を得る
・初動の成果
→お前誰？の脱却
・着任直後の1on1
→信頼を積み上げる
・営業文化を理解する
→相互寄与！

98. 初期ゴール達成後
・フラッグシップを持とう！
・スケールに備えよう
・製品ロードマップを持とう

99. 怖いPMが笑うと、
余計怖い。

100. ありがとうございました！
@ogoshi
Follow me on Twitter!
[告知]
10/12 19:30- @サイバーエージェント
アドテクエンジニア向け勉強会
「オレシカナイト」
テーマ:開発プロセス x アドテク
私もLTに登壇予定です！
『エンジニアマネージャーは、
何故増えないのか？』