2022年1月11日のSTATION Aiでの講演で利用した資料です。

1. PMFを目指すプロダクト開発組織が
組織拡大するときにやるべきこと
学生起業からM&A、そしてプロダクト開発組織作り

2. 自己紹介
● 名前: 西岡 賢一郎
○ Twitter: @ken_nishi
○ note: 西岡賢一郎@研究者から経営者へ (https://note.com/kenichiro)
○ YouTube: 【経営xデータサイエンスx開発】西岡 賢一郎のチャンネル
(https://www.youtube.com/channel/UCpiskjqLv1AJg64jFCQIyBg)
○ 機械学習の社会実装勉強会も開催 (月1回)
■ connpass: https://machine-learning-workshop.connpass.com/
■ YouTube: https://www.youtube.com/channel/UCrjRZ4D2tpqV5UI2XSUKQ6g
● 経歴
○ 東京大学で位置予測アルゴリズムを研究し博士 (学術) を取得
○ 東京大学の博士課程在学中にデータサイエンスをもとにしたサービスを提供する株式会社トライデ
ィアを設立
○ トライディアをビービットにM&Aし、CTOとして3年半務め、2021年10月末に退職
○ 自社および他社のプロダクト開発チーム・データサイエンスチームの立ち上げ経験
○ 現在は、CDPでグローバル展開してるスタートアップとスモールビジネスをするスタートアップに関
わる

3. 今回のお話
● 学生起業したスタートアップをM&Aし、プロダクト開発チームに取締役CTO
として途中から参画した経緯
● 一度縮小してしてしまった開発組織を立ち上げ直し、自走可能なグローバル
チームへ成長させたときに重要だったこと

4. 発表の構成
1. 起業からM&Aまで
2. 開発組織立ち上げから安定化まで
3. PMFを目指すプロダクト開発組織が組織拡大するときにやるべきこと

5. 1. 起業からM&Aまで

6. 起業
● 博士在学中に研究者仲間と株式会社トライディアを起業
○ 電子教科書共同編集プラットフォームでシートアクセラレータプログラムに採択
○ 在学中でまとまった資金がなかったため共同創業者にお金を借りた
○ 登記の資料作りは友人に手伝ってもらう
● 創業してすぐに共同創業者がそれぞれの本業で忙しくなり、ほぼ一人で経営
する状況
● 手探り状態だが、少しずつ組織は成長
ハーバードの構内でブレスト 立ち上げ当初は研究室などで作業 自宅兼オフィスでの作業

7. 事業性の乏しいプロダクト
作りたい世界が先行し、事業と
しては成り立っていなかった

8. コンサルティング事業開始
● 創業2年目に、得意のデータ分析を活用したコンサルティング開始
● 人×時間の労働集約のビジネスが主軸 →余剰資金でプロダクト開発 (BIなど)
● 最終目標はプロダクトを作ること！

9. 転機: 創業した会社のM&A
● 創業を手伝った別のスタートアップと会食
● 1 ~ 2ヶ月程度でM&Aに合意
● M&Aに合意した理由
○ 労働集約型のビジネスからの脱却
○ 他の人との分業
○ 資本のあるプロダクト開発
○ データ解析技術が活用できる未来
○ 技術系経営者はリスタートしやすい

10. 2. 開発組織立ち上げから安定化まで

11. M&A後の3年半
● 各年のハイライト
○ 2018年 開発組織立ち上げ
○ 2019年 大規模な環境改善、チームのグローバル化
○ 2020年 開発組織の安定化
○ 2021年 後任の責任者採用、そして退職
● タックマンモデル
○ 2018年 形成期
○ 2019年 混乱期
○ 2020年 統一期・機能期

12. 2018年 形成期
● 開発組織の再生
○ プロダクト開発に途中から参入
○ 入社後の想定外の事態
● 初年度の大きな目標
○ 脱属人化
○ 技術的負債の解消

13. 2019年 混乱期
● 数年後のプロダクト拡大を見据えた意思決定
○ インフラの大規模刷新
○ フレームワークの入れ替え
○ グローバル人材を採用
● チーム拡大による苦しみ
○ マネジメント
○ 個の力 ⇔ チームの力、ソフトスキルの重要性
○ オンボーディング
● 目標設定のためOKRを導入 → 失敗

14. 2020年 統一期・機能期
● 責任譲渡の推進
● OKRの再導入
○ トップダウン + ボトムアップ
● アウトプットからアウトカムへ
○ 開発主導で突き上げ
● 開発フローの再度見直し
● 後任採用を本格化

15. 2021年 退任
● 開発チームは成熟し手離れ済み
● 安定開発継続のための後任採用決定
● 影響を最小限に約半年かけ退職
● 退職を選んだ理由
○ メンバーの成長による組織の安定化と責任譲渡完了
○ 現状の立場でこの先5年以上残り続けるよりも新しい挑戦
○ データに真摯に向き合うData-drivenの経営の追求
○ 日本を離れグローバルで挑戦するための準備

16. 3. PMFを目指すプロダクト開発組織が
組織拡大するときにやるべきこと

17. PMFを目指すプロダクト開発組織が組織拡大するときにやるべきこ
と
1. OutputからOutcomeへの転換
2. ロードマップの脱却
3. 役割を分割
4. 採用前に役割を定義
5. ピープルマネジメントの導入
6. 管理上の負債の解消
7. マイクロマネジメントをやめる
8. エンジニアを積極的に巻き込む
9. 文書化
10. 機能開発と技術的負債解消のバランス
11. 依存関係の排除
12. 目標設定
13. 人への投資

18. OutputからOutcomeへの転換
● 組織を拡大するとき、「どのくらいの期間」で「どんな機能をリリース」したかに着目しがちになる
● プロダクト開発では、「たくさん機能をリリースすること」は目的ではない
● リリースした機能によって、顧客の課題を解決することが重要
● つまり、機能リリース数に着目する”Output”ではなく、機能によって何が得られたかの”Outcome”を目
指す
● 測定可能なOutcomeが開発開始前に定義されていないのであれば、Outcomeをどのように測定するかをま
ず決める
● 一度のリリースでOutcomeが得られることはほとんどないので、Outcomeの測定結果をもとに改善のサ
イクルを回し、Outcomeの獲得を目指す
改
善
リリース (※ここで終わらない！！) Outcomeを測定 Outcomeを得るために改善

19. ロードマップの脱却
● ロードマップには、数カ月後にどんな機能が開発されているかが書かれており、中長期の計画を立てるの
に役立つ
● ロードマップを、顧客や投資家へ共有することで、プロダクトの期待値を高めることができる
● しかし、PMFを目指す段階のプロダクト開発において、ロードマップはほとんど意味をなさない
● むしろ、ロードマップが制約となりプロダクトへ悪影響を与えることがある
● ロードマップが必要になった場合は、以下のことを考える
○ ロードマップがなぜ必要となっているのか
○ ロードマップを引いた時点のだいたいの計画は、計画呼べるような調査はできていない
○ ロードマップが確定事項じゃないと伝えたとしても、勝手に約束事になる
○ 顧客の課題は機能を開発したからといって解決するわけではない
ロードマップを作る時点では、機能作成計画のための十分な調査はできていない
そもそも、顧客課題解決は1度や2どのリリースではできないので、改善サイクルを回す
必要がある

20. 役割を分割
● スタートアップ立ち上げ初期段階では、人材が不足するため、一人が複数の
役割をこなす (例: プロダクトオーナーと開発, スクラムマスターと開発)
● その結果、個人の中で利益相反を起こし、正しい意思決定ができなくなる
● 利益相反となる役割を1人で担っている場合は、採用により早期解決をする
必要がある
複数の役割をこなす 利益相反が起きている
実際は

21. 採用前に役割を定義
● 経歴がすごい人や経験豊富なエンジニアなど、チームに入ってくれたら何かしら活躍してくれそうな人を、
役割を定義せずに雇うことがある
● スタートアップでは、決められた役割以外でも色々こなしてくれる人材が必要であり、そもそも優秀な人
であれば役割を定義しなくても勝手にやってくれると思っている人もいる
● 実際は、役割定義がない状態で雇うと、採用された人は社内で何をやればいいか分からなくなり、その人
が能力を十分に発揮できずに活躍しないどころか、最悪の場合退社してしまう
● その人に何をやってほしいか、どんな裁量を与えるかを必ず明確にして採用する必要がある (もちろん、役
割がその人の可能性の限界を決めてはいけないように配慮)
● とくに、責任者クラスの採用は、組織への摩擦が大きいので注意
役割が不明確 最悪の場合、退職へつながる

22. ピープルマネジメントの導入
● 組織の人数が増えるにつれ、仕事に対して様々なモチベーションを持つ人が入ってくる
● モチベーションを高く保ち、高いパフォーマンスを出してもらうためにも、個人と向き合い、個人
をサポートするピープルマネジメントが必要となる
● ピープルマネジメントをおろそかにすると、管理上の負債がたまり、組織全体のエンゲージメント
の低下やモチベーションの低下の原因になりうる
● ちなみに、メンターは心的なサポートにはなるが、個人の成功に責務を持つ存在ではないので区別
が必要
ピープルマネジメントあり ピープルマネジメントなし

23. 管理上の負債の解消
● メンバーが増えてくるにつれ、管理体制が必要になってくる
● 管理上の負債は技術的な負債と同様に、その場限りの解決策に頼ると負債が
どんどんたまり、あとから大きな痛手となる
● 1 on 1にマネージャーが時間を追われている、プロダクトの品質が低下して
いる、社員のモチベーションが下がっているなど、管理上の負債は様々な形
で出てくる
1on1
評価
目標管理
管理上の負債がたまりすぎないうちに対処が必要

24. マイクロマネジメントをやめる
● 組織を拡大していくときには、責任譲渡をすすめないといけない
● このとき、必要以上に干渉して、任せたことにあれこれ口を出すようなマイクロマネジメントをす
ると、責任を譲渡された人のモチベーションが下がったり、その人が成長しなかったりする
● 何を達成してほしいか合意をとり、どのように達成するかは本人に任せ、要望があったときだけヘ
ルプする
● とくに、経営メンバーなど上位の職位の人が、責任譲渡した責任者を飛ばして、指示を飛ばしたり
することは絶対にやってはならない (少人数のときの癖が抜けきらない人がたまにいる)
監視を続けている場合、責任譲渡できていない

25. エンジニアを積極的に巻き込む
● エンジニアは「コードを書くだけの人」ではない「ソリューションのスペシャリスト」
● 優先度を決めるのはプロダクトマネージャーの仕事だが、優先度を決めるとき積極的にエン
ジニアを巻き込むことで、プロダクトマネージャーだけでは考えつかなかったプロダクトの
可能性を発見できることが多々ある
● 課題発見のための顧客とのミーティングには必ずエンジニアを一人連れて行く
● ただし、すべてのエンジニアが顧客との対話を求めているわけではないので、希望者は募る
エンジニア≠コードだけ書く人 エンジニア=ソリューションのスペシャリスト

26. 文書化
● プロダクトの初期段階で人数が少ないときは、プロセスやルールなどの文書がなくても、暗黙の了解で動
ける
● しかし、プロダクトが複雑化し、関わる人が増えてくると、暗黙の了解は通じなくなり、情報伝達コスト
が増大する
● ソフトウェアのドキュメントも同様
○ プロトタイプがいつの間にかプロダクションになった場合 (アンチパターン)、ドキュメントが皆無であることが多い
○ 無駄なドキュメントは作らないようにし、できる限り自動生成
○ ちなみにアジャイルソフトウェア開発宣言にある「包括的なドキュメントよりも動くソフトウェア」でドキュメントをいらないと
勘違いしている人が多い (実際は優先度だけの話でドキュメントは必要)
● 文書化は他人のためのものだけではなく、数カ月後の自分のためのものでもある
● 文書化する余裕がないのだれば、それは文書化していないから余裕がなくなっているのかもしれない
人から人へ教えると認識の齟齬が生じる 早い段階でとにかく文書化する

27. 機能開発と技術的負債解消のバランス
● プロダクトマネージャーに技術知識が足りない場合、優先度決定をするときに技術的負債の解消が後回し
にされがち
● 技術的負債はあとになればなるほど解消が難しくなる
● 限られたリソースでは、技術的負債の解消ばかりやっていても、プロダクトが成長せず競合に負けるので、
機能開発と技術的負債解消のバランスが大事
● ちょっとの作業だから手動にしているもの、リリースに追われて後回しして放置しているものなどが技術
的負債として残りがち
● まずは以下のようなものをやってみるとよい
○ 繰り返し行う手動作業は、自動化してCI/CDに積極的に組み込む (テスト、デプロイ)
○ 後回しにしているものは、次のイテレーションで解決
○ 新しいタスクを始めるときに、周辺をリファクタをしてから開発に入る
なんでも自分でやる手動の世界から機械にやらせる自動の世界へ

28. 依存関係の排除
● 特定の機能を知っている、またはレビューできるのが一部の人やチームになるとそこがボトルネックと
なる
● 初期段階では品質を保つという意味でも、このボトルネックは見逃されがちだが、組織拡大につれ、多
くのタスクがここで詰まるようになる
● 属人性やチーム依存を完全に取り除くことは難しいが、できる限り個人またはチームへの依存を排除し
て負担を減らす必要がある
○ その個人などが突然何らかの理由でやめたりする可能性などを考えると、依存関係が残っている事自体が、大きな
リスク本当にその人やチームしかできないのか？他の人材でもできることではないのか考える
○ 他に人材がいないのであれば、教育に積極的に投資する
● 依存関係自体が見えていないこともあるので、依存関係の可視化も進める必要がある (コードレビューの
フロー整備やDMでの依頼禁止など)
依存関係により特定の人の負担が大きくなる

29. 目標設定
● 人が増えれば増えるほど、プロダクトがどこを目指しているかが伝わらなくなる
● 自分らが何を目指しているかが分からなくなると、容易に社員のモチベーションは下がる
● OKRなどを導入し、会社の目指す方向性に合わせた、チームまたは個人の目標設定を支援す
る
● プロダクトの目指す方向と、個人の成長の方向を合わせて、社員の自律性を高める
● ただし、目標を評価と直接結びつけると、管理されている印象が強くなり、目標が重みとな
ってしまうことも (OKRの場合、評価とは結び付けない)
プロダクトの向かう先に合わせて、自分で目標を設定する

30. 人への投資
● 採用だけで組織を成長させることは難しい
● 社員が新しい知識を手に入れられるように、会社側から積極的に支援し、個人の成長が組織へつながる
ようにする
○ 資格の取得の支援 (認定スクラムマスター, AWS関連の資格など)
○ セミナー参加の支援
● コミュニケーションの活性化のためのイベントの開催を積極的に支援 (Win Session, お茶会など)
● 人への投資は、中長期的に見ればかなりコストが良いので積極的に投資
● もちろん、闇雲に投資すればいいというわけではないので、投資の目的と目的が達成されたかどうかを
判断する測定方法は考えておく (資格を取ったら、他のメンバーのために勉強会を開催するなど)
資格取得者による勉強会は、資格取得者自身にも役に立つ

31. 今日話せなかったこと
● M&Aの良かった点と悪かった点
● CTOや開発責任者がいないチームはどうすべきか
● 創業者以外の経営メンバーを採用するときに意識するべきこと
● 海外エンジニアの採用やオフショアの活用
● 人材の見極め方
● アジャイル開発・スクラムのやり方
● AI・データ解析の技術をプロダクトに組み込むためにやること
● など

32. Thank you for your attention.