プロダクト開発初期フェーズにおける「リスク対策機能」をどこまで実装すべきか
投稿日: 2022-01-10
結論
私は以下の結論に至りました。
リスクマネジメントの実施
リスクマネジメントをするための評価指標を組織内で定義
背景
社内プロダクト開発をしている際，以下のような意見がよく出ました。
「実装してて思ったけど，○○機能ってこんなリスクあるから対応しないとまずくない？」
「ここって，こんなことが起こりうるから，そのまま放置するとまずいよね」
機能などの企画提案時は，その機能が持つ「ポジティブ」な部分にフォーカスしているため，あとからその機能の「ネガティブ」な部分によく気づくことがあります。
例えばあなたがSNSアプリを作っているとします。SNSですから，「ユーザ間でコミュニケーションが取れる」とします。
その時，以下のようなリスクが考えられるのではないでしょうか。
ユーザによる誹謗中傷
アプリの目的に反した利用方法(勧誘・オフラインでのつながりを求める等)
「これはまずい」と感じ，以下のような対策を考えます。
NGワードの検出
ユーザによる通報・違反報告機能
人間による監視
公開制限(特定のユーザのみやり取りが閲覧できるようにする)
「これらの機能実装・運用ルールを実施すれば万事解決！」…とは，すっきりいかないと思います。
なぜなら，「リスクに対応することにもリスクがある」からです。
「リスク対応リスク(ややこしい)」には以下があげられます。
機能の自由度が制限される→機能の魅力低下
対応コストによる実装スピードの鈍化→競争力低下
想定工数が増え，エンジニアが疲弊
これらもまた，厄介なリスクです。「実装するのはやめておこう」なんてことにもなりかねません。
機能によっては「そもそも，そんなリスク何％起こるんだよ」「確かにリスクではあるけど，そんな影響大きくなくない？」といった考えになります。
事業部から降りてきたタスクをひたすらこなすタイプの組織の場合「やるしかないので頑張ります」と実装し，結果機能として「魅力が弱い」＆「競合に遅れとる」なんて誰も幸せになれない結末になりかねません。
そこで，「実装したい機能」とそれに伴う「リスク」との向き合い方について考えた対策をこの記事で共有します。
より良い案やご指摘がある方は，Twitter等でご指摘いただけますと大変うれしいです。。
対策
以下のフローで考える必要があるかと思います。
基本的にはISMSのリスクアセスメントをベースに考えます。
フロー
リスク特定
どんなリスクがあるか洗い出す
「リスクが後からわかった場合」を想定しているので，すでに特定したものとする
リスク分析
そのリスクがトリガーとなって，どんなことが起きるのか分析する
影響範囲(自社・ユーザ・社会？)
自社への影響(利益・信頼性・その他被る不利益)
ユーザへの具体的な影響(心理的傷害・サービス満足度低下等・)
(ここ我流)リスク対応案分析
リスクを低減，回避する方法を検討
対応方法
対応後の残リスク量(完全にリスクはなくせない場合，どれぐらいリスクが残るのか)
対応コスト
(ここ重要)リスク評価
リスクに対し，どれぐらい対応する価値があるかを評価
リスクの重さ，対応コストを天秤にかける
天秤にかけたうえで，
対応するのか
対応する場合，どのような対応案にするか
リスク対応
リスク評価の結果を元に，リスク対応を実施する
ここまでかっちりやる必要ある？
結論，「開発初期フェーズ」においてはここまで徹底する必要はないと思います。あくまで目的は「意思決定するための指標を作る」ことです。「この結果だから大丈夫」と全体合意ができるルールづくりです。
事業部やPdM単独で意思決定できていて，かつメンバ内で納得がいっている場合など，組織内で合意がとれていればOKだと考えます。
「それって本当に要る？」といった，組織内で納得がいかない場合には，上記のような取り組みができればよいと思うと同時に，「開発初期フェーズ」から，安定した収益が望める「拡大フェーズ」で組織が大きくなって意思決定元が分散してきたときに，こういった共通した指標が必要だと私は考えます。
まとめ
「プロダクトの成功」にはスピード感が命ですが，「伴うリスク」をすべて無視することはできません。大企業の新規事業室などなら既存のブランドネームも汚せないと思います(そもそも大企業なら本記事以上に徹底した指標があると思いますが…)。重要なのは「攻め」と「守り」のバランスをとること，そして，「釣り合う点がどこなのか」を指標化することだと考えます。
こんな感じで、プロダクト開発時に思ったことのログをこれからも残していきたいと思います。