製造業ドメインにOneTeamでディープ・ダイブする組織設計・組織運営

2024/05/24 Product Engineer Night #4

Transcript

1. 製造業ドメインにOneTeamでディープダイブする 組織設計・組織運営編 CTO 井坂 星南 2024.05.24 Product Engineer Night #4
2. 井坂 星南 Isaka Sena 匠技研工業 取締役 CTO 1996年生まれ（28歳） 大学院在学中に社会課題の解決を決心。 中退し、現匠技研工業を創業 趣味 - お客さんと美味しいお酒を交わすこと @i_senaz 2 自らお客さんの業務に入り込みものづくりをしているところ
3. ビジョンとミッション 全ての企業に、テクノロジーの恩恵を。 インターネットやスマートフォンの普及により、私たちの日々の暮らしは格段に豊かになりました。一方、レガシーな BtoBの世界では、アナログで非効率な現場が数多く残っています。 特に、投資余力に限りのある中小企業では、テクノ ロジーの恩恵を受けているとは言い難い現実があります。 限界費用がゼロに近いデジタルは、全ての企業をエンパワー メントする可能性があると信じています。あらゆる企業がテクノロジーの恩恵を受け、より豊かな働き方ができる世の 中を、匠技研工業は描いていきます。 フェアで持続可能な、誇れるモノづくりを。 戦後の日本経済を飛躍的に成長させた、我が国が誇るべき製造業。しかし、人材不足や技術承継困難など、数々の根深い 課題も山積しています。さらに、業界構造には歪みが生じており、努力が正当に報われているとは言い難い現実がありま す。 匠技研工業は、日本の製造業を世界で飛躍する基幹産業として、モノづくりに携わる全ての人々が誇りを持って働 くことができる世界を実現します。 3
4. • 経営・営業・製造など一気通貫で工場の課題解決を実現 • 現場データ・現場UX・現場AIにより、 DXがこれまで困難だった領域に挑戦 事業概要 製造業向けVertical-SaaS 匠フォース 4
5. バリュー 5
6. バリュー 6 複雑なドメイン　かつ　エンジニアが現場から遠い そこに取り組むために必要なバリュー
7. “プロダクトエンジニア” をどう組織で成り立たせるか 7 プロダクトエンジニアとは何者か Niwa Takeru｜アセンド株式会社 CTO https://note.com/niwa_takeru/n/n0ae4acf2964d
8. ドメイン知識とは 8 業界理解 顧客理解 事業理解 プロダクト理解 ︙ いかにこれらのドメイン知識を全社で共有する仕組みを作るか
9. 3つの組織設計 9 越境して “実践” する 同期コミュニケーションを通じて “伝える” 非同期コミュニケーションを通じて “伝える”
10. 越境して “実践” する 10
11. 越境して “実践” する 全員でカスタマーサクセス 全員でプロダクト開発 11
12. 越境して “実践” する • PO, PdMは商談実施 ◦ 自分が作った製品を自分で提案してみる ◦ 提案が詰まるところがあれば、そこが課題 • プロダクトチーム全員CS ◦ 自分が作った機能で顧客課題が解決されることを、 オーナーシップを持って届けきる ◦ 人によってペルソナ領域を分ける • テックエキスパートMGをDesignerが担当 ◦ 顧客にどう製品を提案しているか、 ほぼすべてをDesignerが把握 ◦ 把握した上で、製品がどうなるべきかを考える ※テックエキスパートとは、匠フォースを顧客業務にあわせて 　カスタマイズするチーム 12
13. 越境して “実践” する • 良かったこと・できたこと ◦ 得られるインサイトの量が多い ▪ 商談やCSMTGの同席と、自分でオーナーシップを持って実践してみるでは差がある ◦ 深い顧客理解のもと、常にリアルな顧客像が頭に浮かんだ状態でプロダクト開発ができる ▪ カスタマーサクセスにつながるか怪しい機能があれば直感的に気づくので、その場で議論ができる ◦ Sales/CS/Product間のズレや軋轢を減らせる →日常的な意思決定がプロダクトチーム内で迅速により適切にできる • 課題・できないこと ◦ 深さはとれるが、幅はとれない ◦ 時間的に、エンジニアリング業務が減ってしまう • 今後の展望 ◦ エンジニアリング業務との最適なリソース配分を考える ◦ 全エンジニアである必要はおそらくない ▪ CS業務は苦手でも、技術に特化して尖っている人材もチームには必要 ▪ PdEとEngで職種を分けることを検討 13
14. 同期コミュニケーションを通じて “伝える” 14
15. 同期コミュニケーションを通じて “伝える” • 毎日の昼礼にて ◦ ドメイン雑談会15分 • 毎週の全社会にて ◦ 社長報 ◦ 顧客勉強会 ▪ CS担当者が持ち回りで、担当顧客一社のCS状況をディープに共有する ▪ 業務プロセス、課題、匠フォース導入Before/After、etc. • 不定期にて ◦ 製造業勉強会 ▪ ドメインエキスパートによる、”ものづくりとは” といった抽象度の高い勉強会 ▪ 顧客にお願いして工場見学開催 15
16. 同期コミュニケーションを通じて “伝える” • 良かったこと・できたこと ◦ リアルタイムに、幅広く、現場情報を手に入れられる ◦ ディスカッション通じてさらにディープダイブができる • 課題・できないこと ◦ 情報がストックされにくい ◦ 人によって必要なキャッチアップが異なったりするが、その調整は難しい • 今後の展望 ◦ 全員にとって有益な時間となる時間の使い方を考えていく 16
17. 非同期コミュニケーションを通じて “伝える” 17
18. 非同期コミュニケーションを通じて “伝える” • ドメインキャッチアップ資料 • 活動報告Slack • VoC • PRD • ResearchDB 18
19. ドメインキャッチアップ資料 19 • 製造業について • ものづくりについて • 全社戦略について • ターゲットについて • 業務プロセスについて • ドメインモデルについて • … メンテナンスが難しいので、 変動が少ない静的情報をストックしている ︙
20. 活動報告Slack 20 • InsideSales報告 • FieldSales報告 • CustomerSuccess報告 日々蓄積されるドメイン情報。 要点だが、重要なインサイトが多い。 PdEが自由に読めるようにし、 顧客とプロダクト理解を日々高める。 FS報告の例 CS報告の例 〜〜〜〜省略〜〜〜〜
21. VoC (Voice-of-Customer) 21 • 顧客の発言を全部署から集約 ◦ Sales/CS/Product • 顧客MTG中や直後に登録する ◦ MTG中だった場合、その場でエンジニアが反応して、 MTG中に修正をデプロイすることも • VoCという媒体を通じて、現場にいけないPdEも 現場理解が進む • 共有だけでなくストックされる
22. Product Documentation • PRD (Product-Requirements-Document) ◦ 何をなぜどう作るか、作った結果どうだったか ◦ 一覧がロードマップとなり、全社に可視化 ◦ 1PRDにつき1PdEをオーナーにアサインし、 フルサイクルに対応 • ResearchDB ◦ 検証結果、明らかになったこと一覧 プロダクトチームの意思決定と学びを蓄積。 現場にいけないフルリモートエンジニアや、 後から入ったPdEのキャッチアップに活用 22 ←PRDの目次例 ↑PRD一覧の例
23. ドメイン情報の集合 23 ソースコードのわずかな一行から、関連する殆どのドメイン情報にたどり着くことができる
24. 非同期コミュニケーションを通じて “伝える” - 結果 • 良かったこと・できたこと ◦ 大量の現場情報を吸収し、学びを得て、迅速にプロダクト に反映ができる ◦ 人・時間を横断して学びを共有できる • 難しかったこと・できないこと ◦ 大量の情報をいかに整理するかは難易度が高い ◦ 整理が上手にできないと、活かされずに眠ったままの情報 となってしまう ▪ ここを乗り切れると大きなメリットがある • 今後の展望 ◦ Product VisionからPRDまでの間のDocsを充実させ、 上流レイヤーを言語化・明確化する ◦ チームが拡大したときに、上流の共通認識が重要 24
25. まとめ • 3種類の方法で、ドメイン理解を全社で高める組織設計・組織運営をしている ◦ 越境して “実践” する ◦ 同期コミュニケーションを通じて “伝える” ◦ 非同期コミュニケーションを通じて “伝える” • 全社でバリューを体現し、 “全員でCSをし、全員でProductを作る” 共通認識が重要 • 最も学んだ組織が最も成長する。学びを最大化するためのOneTeamな仕組み 25
26. プロダクトメンバー募集中！ • プロダクトエンジニア • リードエンジニア※PdEよりもTechに寄る • デザイナー • プロダクトマネージャー • Bizサイドも全方位採用中！ 気になってなくてもOK！ 井坂と話してみたいなと思ったら、DMください！ 26
27. ご清聴ありがとうございました 2024.05.24 Product Engineer Night #4