zoi's blog
どんなポジションを取るのか
January 14, 2020
目次
大壇上の仮説
代替手段の普及が進まない理由は、ビジネス上の要求に添えないシロモノしか存在しないから。
ビジネス上の要求とは？
- 予算
- 時間（工数増やさない）
- 人材（専門人材や専任の不要）
- 売上やKPI（使い勝手悪くして何か悪化してないか）
プロダクトの機能
上記を踏まえ、うちのプロダクトは「ビジネス要求に応える機能」「セキュリティを支える機能」の２軸がある。
ポジションを支える仕様
ビジネス要求に応える機能は次の表に分類できる。どんな側面からどのビジネス要求に応えるのかが分かる。
| 種類 | 予算 | 時間 | 人材 | KPI |
|---|---|---|---|---|
| 開発 | ・フェーズ管理 | ・SDK | ・SDK | ・2FAの種類
・メール（テンプレ＆署名） |
| 運用 | ・フェーズ管理 | ✕ | ・通知
・Webhook |
・スコアリングの塩梅 |
| PS | ✕ | ✕ | ・監視代行
・組み込み代行 |
・塩梅や設定の代行 |
具体的な機能の活用例
- 予算を使わずに無理なくPOCを進められる
- タグやSDKで実装工数を削減
- 専任無しでもWebhookや通知を用いて、予防・対応のワークフローを整備できる
- 2FAのトリガー条件を柔軟にし使い勝手担保
セキュリティを支える機能
ビジネス要求ではない、セキュリティに関する機能要件は次の表のどこかに分類できる。
| 種類 | 見えようになる | できるようになる |
|---|---|---|
| 予防 | ・DBでリスクの可視化
・HIBPの可視化 |
・MFAを用いた2FA
・アクセスの遮断 |
| 対応 | ・HIBPの可視化 | ・アクセスの遮断
・パスワード再設定の自動化 ・特定条件の通知 ・アクセスの遮断 |
プロダクトの持つ不確実性
- 実際に攻撃を、いつどのくらいどの程度の頻度で受けるのか
- エンドユーザーのデータがどれくらい取得できるのか
- 正しい塩梅が設定できるかはコンサル次第
製品の性質上、価値を発揮するかどうかが一部変数になっている。
説明責任のある反論事項
プロダクトのポジションが上記で明確になったが、次のリスクを事業として抱えている。
-
金融以外の顧客が、課題を把握できない可能性が高い
- リスクを把握していない
- リスクを正しく評価できていない
SMB向けのマーケットプレイス事業を売却後、エンプラ向けのSaaSをやってます。元エンジニア：Ruby / Go / Nuxt / ReactNative