エンジニアがプロダクトに向き合うための 組織づくり

A1A株式会社 佐々木 延也 @__mnc90

�1

Name 佐々木 延也

Company A1A株式会社 CTO

Career カカクコム → Speee → A1Aを共同創業

URL twitter.com/__mnc90 manchose.hatenablog.jp

About プロダクト戦略、インフラ構築、コーポレートIT、開発組織づくりなどを担当

!2

B2Bの取引をワンランク上に

Mission

!3

B2Bの取引をワンランク上に

Mission

!4

A1A（社名の由来）

プレミアリーグの強豪トッテナム・ホットスパーFCの胸スポンサー

!5

プレミアリーグの強豪トッテナム・ホットスパーFCの胸スポンサー

弊社じゃありません

!6

A1Aはエィワンヌエィです

AIA トッテナムの胸スポンサーをしている香港の保険会社。エイアイエイ

A1A B2Bをワンランク上にあげるA1A。 エィワンヌエィ

!7

!8

製造業 調達・購買向け見積査定SaaS

RFQ Cloud

Product

※コスト削減のための見積明細版のSansanみたいなイメージ

!9

プロダクト概要

今日のトークの前提

!10

1 弊社はエンタープライズ向けのB2B SaaSを開発している

2 弊社の顧客は製造業の調達部門であり、レガシー産業

※今回のトーク内容は背景として上記2点の影響が大きいです

開発組織の在り方はビジネスの戦略に従う。 価値あるプロダクトを作り続けるためには、戦

略から変えていく必要がある。

今日お話すること

!11

Agenda

!12

1 B2B SaaSの理想のプロダクト開発とは

2 B2B SaaSの難しさ

3 難しさを乗り越える戦略と組織を作る

4 まとめ

!13

1. B2B SaaSの理想のプロダクト開発とは

!14

価値あるプロダクトづくりが事業成長に最速で貢献するような状態

理想のプロダクト開発

!15

ビジネスの成長戦略とプロダクトの成長戦略が一致している状態

言い換えると

!16

CTOとしての自分の役割

組織は戦略を実行するための手段。 戦略から組織の在るべき姿を決めるべきだ

とする考え方。

「組織は戦略に従う」が基本

!17

組織文化・カルチャーなどによって立案される戦略も決まってくるという考え方。

「戦略は組織に従う」も現実としてある

!18

戦略を所与の条件として開発の組織づくりをしないようにする

!19

ビジネスの戦略とプロダクトの戦略が一致しないとどうなるか？

!20

1 機能の開発を約束し契約をとる、コミット開発が頻発する その結果、機能追加の順番がアンコントローラブルになる

2 まだ解像度が高くない顧客像に対しての機能追加により技術的負債・UX的負債が積み上がる

3 契約のために機能開発が必要になり、ビジネスの成長スピードが遅くなる

A1Aはできているの？

!21

徐々に改善してきているが、これまではできていなかった。B2B SaaSに特有の難しさが

根本の原因だった。

2. B2B SaaS開発の難しさ

!22

B2B SaaS開発の難しさ

!23

1 MVPから契約までの機能のGAPが大きい

2 プロダクトの仮説検証が難しい

MVPから契約までの機能のGAPが大きい

!24

創業から半年ほどで開発したMVPで多くの引き合いを得たものの、そこから契約までが

遠く、多くの機能要望が出てきた。

MVPから契約までの機能のGAPが大きい

!25

プロダクトの機能を2つに分類する

!26

価値の創造プロダクトのコアコンセプト（提供価値）そのものを実現するための機能（例）見積明細のデータ化、見積明細の活用

価値のデリバリープロダクトの提供価値を実際に得るために業務上必要となる機能（例）権限管理、ワークフローなど

B2B SaaS(エンタープライズ向け)は利用人数の多さや利用頻度の高さに起因する機能要望やガバナンス・セキュリティのための機能要望など価値のデリバリーに対しての機能の

必要性が高い。

なぜ機能のGAPが大きいのか？

!27

MVPでは価値創造に集中して機能開発を行っているため、商談が進み契約に近くなると一気に機能のGAPが出てくる。

なぜ機能のGAPが大きいのか？

!28

この機能GAPを機能追加で埋めることを顧客と約束し契約をとるという手段は、価値あるプロダクト開発という点において大きな足枷

になる。

機能GAPへの誤った対応

!29

機能コミットはアジャイルと非常に相性が悪い。限られた時間内で作るものを自社で調整したいにも関わらず、作るものが固定化され

てしまうため。

機能コミットはアジャイルと相性が悪い

!30

理想を言うと、顧客には提供価値でコミットし、機能の仕様のハンドリングは自社で行えたら大きな問題はない。しかし、顧客がレガシー産業の企業である場合はそれは幻想。結局機能でコミットすることになってしまう。

機能コミットはアジャイルと相性が悪い

!31

機能を作れば確実に売上というリターンが見込めるため、頭では機能コミットのリスクを理解していても、要件を吟味せずに作るという力学が働きがちになる。

機能コミットの誘惑は非常に強い

!32

作るものが決まってしまうと目的に対しての手段が限定されてしまうため、プロダクトで価値を提供するという点に対して当事者意識を持ちづらくなる。

機能コミットはエンジニアの自律性を阻害する

!33

本来であれば別の機能を作った方がより事業インパクトが大きかったり、プロダクトの価値が大きいと判明しても、約束してしまったがために開発することが必須になる

つまり、未来がアンコントローラブルになる

結果

!34

プロダクトの仮説検証が難しい

!35

2Cと異なり、商談・稟議・承認などを経て初めて提供価値の検証ができる。つまり、プロダクトの仮説検証の役割を営業が担う必要があり、仮説検証のサイクルが長くなる。

仮説検証の役割を営業が担う必要がある

!36

営業の仕方次第で顧客の反応が変わってしまうため、プロダクトの提供価値と異なる売り方をしてしまうと仮説検証に失敗し、取り込むべきでない要望が出てきてしまう。

売り方を間違えるとプロダクトの仮説検証に失敗してしまう

!37

「購買業務を効率化する」プロダクトというメッセージングの場合、効率化のための機能や業務のカバー範囲を強く求められてしまう。一方で「見積明細を資産としてデータ化する」プロダクトというメッセージングの場合、あくまでデータ化とその活用方法についての要望が

強くなる。

RFQCloudの例

!38

常に○○機能がないと契約できない、という声が出続け、なにを解決すれば乗り越えられるか

わからなくなる。

結果

!39

「機能が足りないから売れない」と不満を感じるSales、と「どれだけ作れば売れるんだ」と不満を感じるDeveloperという構図になりがち。

結果

!40

3. 難しさを乗り越える戦略と組織を作る

!41

なにを解決すれば契約・稼働できるのかを分析するのが難しいこと。

理想のプロダクト開発ができない原因

!42

PMM(CEO)が営業に入り契約がとれない理由を分析する

!43

各担当者の肌感覚を頼りに契約がとれない理由を考えることをやめた。CEOがPMMも兼務し、契約がとれない理由を「価値の創造と価値のデリバリーのどちらに原因があるのか」から分析するようにし、仮説検証の役割を担っても

らうようにした。

価値のデリバリーのための機能要望は①利用範囲②利用頻度による影響が大きい。そのため、最初から全社稼働を提案せず少人数で成果を出してもらえるように勧めることを検討。

その後アップセル（全社展開）ができるような提案内容や機能拡充の戦略を描く。

ミニマムスタートからのアップセルを狙う

!44

事業を進めていると色んな「とはいえ」がある。戦略の幹をつくり、そのための組織を作った上で、はじめて「とはいえ」を考えるようにする。色んな「とはいえ」を都度考慮し、最適な解を導き出せるというのは希望的観測でしかなく、実際はオーバーヘッドの方が大きい。

戦略の幹をつくる

!45

※とはいえ…「理想とは違うのはわかる。とはいえ、目先の売上もほしい」というシーンで使いがちな言葉

とはいえ、温度感の高い「超大型案件」が不定期で入ってくる。嬉しい悲鳴だが、これに対処しながら開発を進めたいが、めちゃ難しいです…

とはいえ…

!46

4. まとめ

!47

プロダクトでの価値創造に向き合うことが会社にとって価値あるものにするためには、戦略・組織全体を一致させていく必要がある。その上で価値創造の力を最大化させていく役割をエンジニアリングマネージャーに求めていきたい。

プロダクトに向き合うためには戦略・組織全体を変えていく必要がある

!48

We are hiring! A1A

!49