zoi's blog
ユースケースを絞る
February 22, 2020
担当者の状況
最も大きな要素
担当者の状況を洗い出すと、おおよそ次の要素による所が大きい。
- 権限の大きさと職責
- 導入検討箇所の状況（システム構成/開発リソース/攻撃状況）
関連する要素の全体像
詳細は下図の通り。 売るためには現状のままだと予算/権限/製品などどんな部分に課題があり、その課題を解決するにはどうしうるのかを整備した。
トレードオフの全容
| toC | 社内 | |
|---|---|---|
| ニーズ | 使い勝手を悪くせずに不正行為を検知 | 多様な労働環境に合わせて機密情報を守る |
| 顧客の懸念 | ・使い勝手 ・ROI（費用と実害、+αの付加価値） | ・予算内に費用が収まるかどうか ・細かく検証できるか ・業務にそうか（細かくポリシー設定できるか、2FA周知の手間） |
| Locked側の懸念 | ・リテラシーがきつい（事業責任者はセキュリティ担当じゃない≒データの見せ方） ・予算が新規（≒ +αの影響） | ・情シスの担当者に権限あるのか ・つなぎ込めるのか（AD,認証鯖,JS使えるか） ・予算の既枠から取れるのか |
| 営業の課題 | ・トライアルが必須（時間軸が長い） ・代理店経由に注力必要（代理店の要望に沿う、リテラシーないとセットが必須） | ・リモートとか情シスとか割と囲いやすい（メディア, コミュニティ） |
| 製品への影響 | ・代理店の要望（Lockedでセキュア→手数料減、何かしら差別化への寄与） ・診断モードの強化（リテラシーの無い人でもリスクを適切に判断できる、フェーズをすすめるための共通認識を顧客社内で形成できる） | ・社内利用を前提としたイベントの内容とその出し方 ・レガシーな構成にも接続できる仕組みの検討 |
| 制約 | ・ITのリソースがない(開発・判断) | |
| 前提 | ・必要性はリテラシーに依存 |
検証したい項目
| 代理店が売る | 社内システムに売る | toCサービスに売る | |
|---|---|---|---|
| 検証内容 | ・どこが代理店になりうるのか
・代理店する背景と抱える課題 ・具体的な座組 |
・担当に権限があるのか
・予算がどの配分でどの程度あるか ・老朽化したシステムには組み込めるのか |
・代理販売は可能か
・リテラシーバラバラなので、トライアルが前提 ・分析系の検討 |
SMB向けのマーケットプレイス事業を売却後、エンプラ向けのSaaSをやってます。元エンジニア：Ruby / Go / Nuxt / ReactNative