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

by Keisuke69

Slide 1

Slide 1 text

2024.7.19 株式会社Singular Perturbations ⻄⾕圭介 CTOから⾒た事業開発とプロダクト開発事業課題を技術で打開するということ

Slide 2

Slide 2 text

はじめに • ちゃんとした理論や⼀般的な原則ではなく個⼈的な経験に基づく内容です • 実際のプロダクト開発で⼤切にしている考え⽅

Slide 3

Slide 3 text

Keisuke Nishitani !,FJTVLF 1SPHSBNNJOHJTBDSFBUJWFXPSL 🎨 -PWF.VTJD ♫ -PWF$BNQJOH ⛺ #MPHIUUQTXXXLFJTVLFOFU 💻 &WFSZUIJOHXJMMCFTFSWFSMFTT ⚡ $50BU4JOHVMBS1FSUVSCBUJPOT*OD $00BU%&-5"*OD

Slide 4

Slide 4 text

世界の悲しい経験を減らす。

Slide 5

Slide 5 text

犯罪発⽣数 68%減を達成

Slide 6

Slide 6 text

CTO?としてやっていること • プロダクト開発 • 技術戦略と事業⽬標の整合性確保 • 技術的専⾨性とビジネス視点の重要性 • エンジニアサイドとビジネスサイドの橋渡し • プロダクトをどう売るか、市場を踏まえてどういうプロダクトを作るべきかの計画 • 営業プロセスの設計やオペレーションの管理、整備など

Slide 7

Slide 7 text

私の考えるプロダクト開発と事業開発

Slide 8

Slide 8 text

WhatとHow • What • 「何」を作るか • 事業開発（の⼀部）でありプロダクト開発（の⼀部） • How • 機能を「どう」実現するか • どんな⾔語で、どんなアーキテクチャで、システムを実装するか • プロダクト開発⼤事なのは技術的な難易度の⾼さではなく、いかに課題にミートしてるかつまりWhatこそ重要

Slide 9

Slide 9 text

What • 誰の何を解決するものなのか • 顧客の売上向上につながる or コスト削減 • ただし、これはB2Bの場合 • 適切な⼈たちに届けることも⼤事 • 適切な⼈たちがどこにいるのか • 眼の前にいる⼈だけを適切な⼈たちだと誤解していないか • 常に⾃分⾃⾝に問う

Slide 10

Slide 10 text

プロダクト開発で⼤切にしている3つのこと • なるべく作らない • シンプルさの追求 • 段階的アプローチ

Slide 11

Slide 11 text

なるべく作らない • ソフトウェアは作った時点で潜在的に技術負債化する • 技術負債の最⼩化 • 「あればいいな」は実装しない • 本当に必要な機能を⾒定めてそれだけを実装する • 本当に必要な機能＝プロダクトのコンセプトを体現する機能、顧客が必要とする機能

Slide 12

Slide 12 text

シンプルさの追求 • シンプル ≠ 単純 • 単純なだけでなく明快であること • 無駄な機能がない＝ユーザが迷わない • あれもこれもできるものではなく、そのプロダクトが解決するものが何なのか、そのコンセプトを体現する最⼩限のセット

Slide 13

Slide 13 text

段階的アプローチ • 最初から機能豊富なものを作らず、常にその時点の最⼩セットを実装して出す • 最⼩のサイズはプロダクトの成⻑に伴い変わっていく • シンプルに始めることで、ユーザーの真のニーズを理解し、それに基づいて段階的に機能を追加していく • 無駄な機能（≒技術負債）を減らせる

Slide 14

Slide 14 text

プロダクト開発は螺旋のようなもの

Slide 15

Slide 15 text

事業課題を技術で打開した事例

Slide 16

Slide 16 text

事業課題 • POCに必要なプロダクトが重厚⻑⼤ • 多くの⼈員を巻き込む必要があり、とても時間と労⼒がかかるものだった • 事業を加速させる上で最⼤のハードルが犯罪データ • ブラジルには犯罪実績のオープンデータが存在しない • センシティブであり警察組織外に出すことが⾮常に⾼いハードル • ここの交渉にとても時間がかかる • コンプライアンス • 原則としてブラジル版GDPRともいえるLGPDへの対応が必要 • 顧客の温度感 • ⽇々の業務が忙しく、新しいことにチャレンジすることの優先度が低い • チャレンジのハードルが⾼いのでさらに優先度が下がる • スピードが遅く、ウェットなコミュニケーションを好む

Slide 17

Slide 17 text

より加速させるには？

Slide 18

Slide 18 text

仮説やれることを絞り込み、犯罪データ提供の問題を解消できれば、顧客のスピード感を⾼められるのではないか

Slide 19

Slide 19 text

仮説顧客の準備コストを軽減やれることを絞り込み、犯罪データ提供の問題を解消できれば、顧客のスピード感を⾼められるのではないか

Slide 20

Slide 20 text

仮説導⼊ハードルの軽減やれることを絞り込み、犯罪データ提供の問題を解消できれば、顧客のスピード感を⾼められるのではないか

Slide 21

Slide 21 text

やれることの絞り込み「シンプルかつ簡単に、専⾨家でなくても Hotspotを特定できる」

Slide 22

Slide 22 text

犯罪データをもらわずに実現するには？ • ユーザのオンプレ環境で実⾏する • 警察組織のデータセンタなどにオンプレ環境を構築する必要がある • 既存のシステムはオンプレで動作するようには作られていない • スタンドアロンのローカル環境で実⾏する • これまでサーバーサイドで実⾏していた部分をローカル環境で動作するように • インストールが必要 • 開発チームが⽇本にいることもあり、オンプレは現実的ではないためローカル環境で実⾏する⽅法を模索

Slide 23

Slide 23 text

WebAssemblyの採⽤

Slide 24

Slide 24 text

WebAssemblyの採⽤ • 採⽤理由 • ブラウザ上で⾼度な処理が可能 • 誰しもが使える環境で動作する • あくまでもWebなので頻度の⾼いリリースが可能 • 標準化された汎⽤的なプラットフォームなので機能拡張性が⾼い • 環境 • ⾔語はRust • Pyodideを⽤いたPython版も現在実装中 • GeoSpatialな処理はDuckDBを採⽤

Slide 25

Slide 25 text

提案プロセスの変更 • まずはライトな新プロダクトを提案 • データ提供不要 • ⼀⽅で精度の⾼さについてはそれなり • 説明変数を決め打ちしたり、環境ごとのチューニングを⾏わないため • 使い始めを早く・簡単にして、精度をあげたい場合はデータを提供してもらう形に

Slide 26

Slide 26 text

その結果どうか • プロダクトのリリースは約1ヶ⽉ • これはシンプルだったからできたこと • 2年で1組織 => 3ヶ⽉で4組織 • ただし、実施内容の重みは異なる • ⼀度⾒送りになった組織にも再提案し、話しが再開しているものもある • そもそも営業のやり⽅を変えた効果もある • オンボーディングコスト激減 • 従来は警察官を集めて数⽇かけて現地でハンズオン実施 • 現在は主要な⼈にオンラインで説明するだけ • モバイルアプリと異なりデバイスの種類による不具合がほぼない

Slide 27

Slide 27 text

成功のポイント • 技術による事業課題の解決 • 犯罪データの提供という事業課題をWASMという技術で打開 • シンプルさと段階的アプローチ • 導⼊ハードルを下げるためにやれることを絞り込み • シンプルなものを提供した後に実際のユーザフィードバックを元に機能追加 • 営業プロセス⾃体も導⼊ハードルを下げて懐に⼊った後に本来やりたいことにつなげる形に変更

Slide 28

Slide 28 text

シンプルさの例 • 複数⼈によるデータ共有には対応せず • データ永続化や認証・認可の機能が不要に • 時間や罪種ごとの検出は対応せず • ほしいと⾔われることの想定はしていた • やりたい場合は読み込ませるデータで対応 • その他細かい「あったらいいな」の実装は後回し • 使い勝⼿とのトレードオフではある • その後、フィードバックを元に⼀部を実装 • 簡易パスワード保護 • 時間や罪種の対応

Slide 29

Slide 29 text

技術と顧客ニーズのバランス • 技術の可能性と顧客ニーズのバランスが重要 • プロダクトアウト vs マーケットイン • SPの場合、コア技術はどちらかというとプロダクトアウト • だからこそ、それを応⽤したソリューションは顧客ニーズを意識 • 最⼩限の機能で開始し、顧客ニーズを理解するプロセスを重視 • 技術がいかに顧客の課題を解決できるかを常に考える

Slide 30

Slide 30 text

まとめ • エンジニアリングスキルのビジネス価値 • エンジニアリングスキルは単なる技術⼒に留まらず、ビジネスの成功に直結する重要な資産 • 技術⼒を活かして事業課題を解決することで、競争⼒を⾼める • 逆に技術的な裏付けなく事業が進むと実現性の観点で不幸になる • プロダクト開発の3原則 • なるだけ作らない • シンプル • 段階的アプローチ • 技術と事業⽬標の整合性 • 技術戦略と事業⽬標を⼀致させることが重要 • 最新技術を追求するだけでなく、ビジネスのニーズに応じた技術選定と実装を⾏うことが重要 • 技術的専⾨性とビジネス視点のバランスを取り、エンジニアチームと事業部⾨を橋渡し

Slide 31

Slide 31 text

Thank You ご感想・ご質問・ご相談は@Keisuke69まで