CTOから見た事業開発とプロダクト開発 / My Perspective on Business and Product Development as CTO

DevelopersIO 2024 でお話したスライドです

Transcript

1. 2024.7.19 株式会社Singular Perturbations ⻄⾕圭介 CTOから⾒た事業開発とプロダクト開発 事業課題を技術で打開するということ
2. はじめに • ちゃんとした理論や⼀般的な原則ではなく個⼈的な経験に基づく 内容です • 実際のプロダクト開発で⼤切にしている考え⽅
3. Keisuke Nishitani !,FJTVLF 1SPHSBNNJOH
   JT
   B
   DSFBUJWF
   XPSL 🎨 -PWF
   .VTJD ♫ -PWF
   $BNQJOH ⛺ #MPH
   IUUQTXXXLFJTVLFOFU 💻 &WFSZUIJOH
   XJMM
   CF
   TFSWFSMFTT ⚡ $50
   BU
   4JOHVMBS
   1FSUVSCBUJPOT
   *OD $00
   BU
   %&-5"
   *OD
4. 世界の悲しい経験を減らす。
5. 犯罪発⽣数 68%減 を達成
6. CTO?としてやっていること • プロダクト開発 • 技術戦略と事業⽬標の整合性確保 • 技術的専⾨性とビジネス視点の重要性 • エンジニアサイドとビジネスサイドの橋渡し • プロダクトをどう売るか、市場を踏まえてどういうプロダクトを 作るべきかの計画 • 営業プロセスの設計やオペレーションの管理、整備など
7. 私の考えるプロダクト開発と事業開発
8. WhatとHow • What • 「何」を作るか • 事業開発（の⼀部）でありプロダクト開発（の⼀部） • How • 機能を「どう」実現するか • どんな⾔語で、どんなアーキテクチャで、システムを実装するか • プロダクト開発 ⼤事なのは技術的な難易度の⾼さではなく、いかに課題にミートしてるか つまりWhatこそ重要
9. What • 誰の何を解決するものなのか • 顧客の売上向上につながる or コスト削減 • ただし、これはB2Bの場合 • 適切な⼈たちに届けることも⼤事 • 適切な⼈たちがどこにいるのか • 眼の前にいる⼈だけを適切な⼈たちだと誤解していないか • 常に⾃分⾃⾝に問う
10. プロダクト開発で⼤切にしている3つのこと • なるべく作らない • シンプルさの追求 • 段階的アプローチ
11. なるべく作らない • ソフトウェアは作った時点で潜在的に技術負債化する • 技術負債の最⼩化 • 「あればいいな」は実装しない • 本当に必要な機能を⾒定めてそれだけを実装する • 本当に必要な機能＝プロダクトのコンセプトを体現する機能、顧客が必要 とする機能
12. シンプルさの追求 • シンプル ≠ 単純 • 単純なだけでなく明快であること • 無駄な機能がない＝ユーザが迷わない • あれもこれもできるものではなく、そのプロダクトが解決するも のが何なのか、そのコンセプトを体現する最⼩限のセット
13. 段階的アプローチ • 最初から機能豊富なものを作らず、常にその時点の最⼩セットを 実装して出す • 最⼩のサイズはプロダクトの成⻑に伴い変わっていく • シンプルに始めることで、ユーザーの真のニーズを理解し、それ に基づいて段階的に機能を追加していく • 無駄な機能（≒技術負債）を減らせる
14. プロダクト開発は螺旋のようなもの
15. 事業課題を技術で打開した事例
16. 事業課題 • POCに必要なプロダクトが重厚⻑⼤ • 多くの⼈員を巻き込む必要があり、とても時間と労⼒がかかるものだった • 事業を加速させる上で最⼤のハードルが犯罪データ • ブラジルには犯罪実績のオープンデータが存在しない • センシティブであり警察組織外に出すことが⾮常に⾼いハードル • ここの交渉にとても時間がかかる • コンプライアンス • 原則としてブラジル版GDPRともいえるLGPDへの対応が必要 • 顧客の温度感 • ⽇々の業務が忙しく、新しいことにチャレンジすることの優先度が低い • チャレンジのハードルが⾼いのでさらに優先度が下がる • スピードが遅く、ウェットなコミュニケーションを好む
17. より加速させるには？
18. 仮説 やれることを絞り込み、犯罪データ提供の問題を解消でき れば、顧客のスピード感を⾼められるのではないか
19. 仮説 顧客の準備コストを軽減 やれることを絞り込み、犯罪データ提供の問題を解消でき れば、顧客のスピード感を⾼められるのではないか
20. 仮説 導⼊ハードルの軽減 やれることを絞り込み、犯罪データ提供の問題を解消でき れば、顧客のスピード感を⾼められるのではないか
21. やれることの絞り込み 「シンプルかつ簡単に、専⾨家でなくても Hotspotを特定できる」
22. 犯罪データをもらわずに実現するには？ • ユーザのオンプレ環境で実⾏する • 警察組織のデータセンタなどにオンプレ環境を構築する必要がある • 既存のシステムはオンプレで動作するようには作られていない • スタンドアロンのローカル環境で実⾏する • これまでサーバーサイドで実⾏していた部分をローカル環境で動作するよ うに • インストールが必要 • 開発チームが⽇本にいることもあり、オンプレは現実的ではない ためローカル環境で実⾏する⽅法を模索
23. WebAssemblyの採⽤
24. WebAssemblyの採⽤ • 採⽤理由 • ブラウザ上で⾼度な処理が可能 • 誰しもが使える環境で動作する • あくまでもWebなので頻度の⾼いリリースが可能 • 標準化された汎⽤的なプラットフォームなので機能拡張性が⾼い • 環境 • ⾔語はRust • Pyodideを⽤いたPython版も現在実装中 • GeoSpatialな処理はDuckDBを採⽤
25. 提案プロセスの変更 • まずはライトな新プロダクトを提案 • データ提供不要 • ⼀⽅で精度の⾼さについてはそれなり • 説明変数を決め打ちしたり、環境ごとのチューニングを⾏わないため • 使い始めを早く・簡単にして、精度をあげたい場合はデータを提 供してもらう形に
26. その結果どうか • プロダクトのリリースは約1ヶ⽉ • これはシンプルだったからできたこと • 2年で1組織 => 3ヶ⽉で4組織 • ただし、実施内容の重みは異なる • ⼀度⾒送りになった組織にも再提案し、話しが再開しているものもある • そもそも営業のやり⽅を変えた効果もある • オンボーディングコスト激減 • 従来は警察官を集めて数⽇かけて現地でハンズオン実施 • 現在は主要な⼈にオンラインで説明するだけ • モバイルアプリと異なりデバイスの種類による不具合がほぼない
27. 成功のポイント • 技術による事業課題の解決 • 犯罪データの提供という事業課題をWASMという技術で打開 • シンプルさと段階的アプローチ • 導⼊ハードルを下げるためにやれることを絞り込み • シンプルなものを提供した後に実際のユーザフィードバックを元に機能追 加 • 営業プロセス⾃体も導⼊ハードルを下げて懐に⼊った後に本来やりたいこ とにつなげる形に変更
28. シンプルさの例 • 複数⼈によるデータ共有には対応せず • データ永続化や認証・認可の機能が不要に • 時間や罪種ごとの検出は対応せず • ほしいと⾔われることの想定はしていた • やりたい場合は読み込ませるデータで対応 • その他細かい「あったらいいな」の実装は後回し • 使い勝⼿とのトレードオフではある • その後、フィードバックを元に⼀部を実装 • 簡易パスワード保護 • 時間や罪種の対応
29. 技術と顧客ニーズのバランス • 技術の可能性と顧客ニーズのバランスが重要 • プロダクトアウト vs マーケットイン • SPの場合、コア技術はどちらかというとプロダクトアウト • だからこそ、それを応⽤したソリューションは顧客ニーズを意識 • 最⼩限の機能で開始し、顧客ニーズを理解するプロセスを重視 • 技術がいかに顧客の課題を解決できるかを常に考える
30. まとめ • エンジニアリングスキルのビジネス価値 • エンジニアリングスキルは単なる技術⼒に留まらず、ビジネスの成功に直結する 重要な資産 • 技術⼒を活かして事業課題を解決することで、競争⼒を⾼める • 逆に技術的な裏付けなく事業が進むと実現性の観点で不幸になる • プロダクト開発の3原則 • なるだけ作らない • シンプル • 段階的アプローチ • 技術と事業⽬標の整合性 • 技術戦略と事業⽬標を⼀致させることが重要 • 最新技術を追求するだけでなく、ビジネスのニーズに応じた技術選定と実装を⾏ うことが重要 • 技術的専⾨性とビジネス視点のバランスを取り、エンジニアチームと事業部⾨を 橋渡し
31. Thank You ご感想・ご質問・ご相談は@Keisuke69まで