リスクテイクを後押しする法務～Ubieのリスク系レビュープロセス～
イントロ
こんにちは！Ubieで法務を担当しているkamechanと申します。
この度、noteを書く機会をいただいたので、Ubieで実施しているリスク関連のレビュープロセスの紹介をしたいと思います。
概要
この記事では、当社で実践しているリスク関連のレビュープロセスである「リスクナビゲータ（主にリスマネバディ）」の紹介を行います。このマネジメントシステムの特徴は、事業フェーズによって関わり方を変えることで、より柔軟かつスピーディーに事業開発に伴走できる点です。
従来の法務部門が行うようなリスク事項を極限まで減らすというリスクヘッジ機能とは異なり、弊社のようにリスクテイクをしながら事業を拡大させていくスタートアップにフィットしたシステムとなっています。
こんな人に読んでほしい
事業会社で法務をやっている方には参考になれば幸いです。ただし、どちらかというと本記事は事業を実際に動かしている方に読んでほしいなと思います。Ubieではコーポレート部門の名称をUbie Acceleratorとしており、あくまで事業の成長を後押しする部門であることを明確にしています。この施策はそのスタンスが具体的に表れているマネジメントシステムだと考えるためです。
事業部門の方にUbieのコーポレート部門だったらより事業開発がうまくいきそう！楽しそう！と興味を持ってもらい、Ubieで事業を作っていくことに興味をもってもらえると望外の喜びです。
前提～大企業とスタートアップの法務の役割～
まず、前提として法務部門の役割について簡単にシェアさせてください。一般に法務部門の役割は、企業の成長において重要なレバーをもつと思います。しかし、一口に法務部門といっても、法務がどのように機能するかは、企業の文化や経営方針によって大きく異なります。特に、企業におけるリスクに対する考え方は、企業の成長戦略やカルチャーに直結するため、法務部門のアプローチも変わってきます。私が転職して最もカルチャーショックを受けたのはこの部分でした。
大企業における法務の役割
私が以前在籍していた企業（大企業）では、法務部門は主に「ブレーキ役」として機能していました。事業部門がアクセルです。法務部門はリスクを抑えるためのブレーキをかける役割を担っており、経営層が運転をしながら、会社という車を駆動させるというようなイメージだったかと思います。また、QCDでいうとQuality重視。一つの判断ミスが会社全体を揺るがしかねないですしアリ一匹通さない緻密な法的評価の積み上げが会社全体を支えます。このアプローチは、一定の規模があり、急成長ではないものの安定した成長を目指す企業には有効なものだったかなと思います。（とはいえ、私にはそれが最終あわなかったでした。この辺は入社エントリでもちょっと触れたので興味のある方は読んでみてください）
スタートアップにおける法務の役割
一方、現在の私が所属するUbieでは、法務部門は「リスクテイクを後押しする」役割を果たしています。ここでは、経営層が法務やリスク部門に期待することが大きく異なります。経営からはリスクを適正に評価し、事業を毀損しない範囲でリスクを極小化し、最終的にはリスクを取ることを後押しすることが求められています。QCDでいうとDelivery(スピード）が優先。リスクを極小化する点でもちろんリスクヘッジ施策は実施するのですが、あくまで主は事業です。また、スタートアップでは法務リスク以外にも財務リスク・事業リスクなど多様なリスクがあります。すべてリスクヘッジしろというのはそもそもスタートアップをするなというのと同義です。その中でスタートアップでは勝ち筋やROIを見極め、事業のために必要なものについてはスピーディーに大胆にリスクテイクをしていくことがより求められると思います。
法務部門に求められるのはその後押しです。例えば、このくらいのリスクだと最大の影響としてはxxxで、発生確率はxxxといったケースが考えられます。さらにリスクヘッジ策をとればxxxまでリスクを低減できます。見込まれるリターンがxxxなのであればリターンが勝るのでGOでもいいんじゃないでしょうか。みたいな提言が求められます。
このように、企業のフェーズや文化によって法務部門の役割は変わってくると思います。そのため経営や会社が法務部門やリスク部門に何を求めているか、経営層とのアラインが取れているかどうかが、法務部門の活躍に大きく影響するかと思います。
その中で当社の運営ではよりリスクテイクを後押しし、事業を加速してくれる法務部門が求められています。
なぜレビュープロセスを刷新したか～事業に伴走するうえでの課題～
さて、リスクについての考え方の共有ができたところで、レビュープロセスを刷新するに至った背景・課題について共有させてください。
元々当社ではリスクレビューというマネジメントシステムを実施しておりました。以下の記事がわかりやすいです。
かいつまんで言うと、窓口が一元化されていることや、質問フォームがあることで何を伝えたらいいかが明確になるという利点がありました。
ただ、簡単な質問に返すだけならこれでもよかったのですが、実際に運用してみると以下のような課題が出てきました。
全ての相談がフラットに入るため、事業的な重要度の軽重や優先度が分からない。そのため、単に質問に答えるだけでいいのか、その周辺領域も調べて手厚く対応したりより事業を動かすような働きかけをすべきか分からない。
新規事業を立ち上げる際に複数の論点、難解な論点を含むもので、Slackのスレッドが200以上になることがある。もはや何の話をしているのかよく分からない状態。
別の人が新しい相談を投げると新しい案件として処理されてしまい、別の相談案件との関係が分からなくなる。
また、一番覚えているのが0-1の新規事業立ち上げへの対応の難しさです。新規事業立ち上げとなると新しい論点が噴出します。新規事業ですから論点自体も過去の知見に無いものであり、それに法務部門は答えないといけません。これへの対応として、依頼を受けて調査し、検討し、3～5営業日くらいで返答するのが過去の自分のプラクティスでした。
しかし、彼らはそれでは許してくれません。彼らはデイリーでPDCAを回します。何か新しい種が出てきたらすぐにMVPを作ってユーザーに当てて、うまくいきそうだったら改良し、ダメだったらまた一から作り直す。そんなことを毎日繰り返しています。その中で相談から3～5営業日で返答するということをしていたらどうなるでしょう？デイリーで回していたPDCAが1週間ストップすることになります。1Qを14週とすれば14回しかPDCAが回せないことになります。これでは全然tryが稼げません。
そもそも彼らが求める答えは精緻な法務回答ではありません。プロダクトの方向は顧客への価値提供がより大きくなるよう日々変わります。その中で前提となる事実も変わっていきますし、検討してたアイデアが次の日には放棄されるということもしばしば起こります。そのなかで求められるのは、結局「なんか行けそうか、ダメそうか」のふわっとした粒度のものをスピーディーに返してほしいということでした。従来のレビュープロセスでは、全ての質問をフラットに一つの窓口で対応していたため、背景にある事業のフェーズや立ち位置が考慮できず、事業から求められているちょうどよい粒度の回答やスピードに対応できませんでした。
実際に、Ubieでは、事業開発におけるフェーズが明瞭化されており、それぞれのフェーズにてアプローチや担当者を変えています。フェーズ毎に求められること必要なスキルや検証すべきことが異なるためです。
これに沿った形でより事業に伴走できるようなプロセスにした方がより事業を加速させるのにフィットすると考えました。
どうしたのか？～レビュープロセスの刷新～
上記の課題に対応するため、Ubieでは、事業のフェーズに応じて関わり方を変えて、法務部門・リスク部門ではリスクナビゲータ（主にリスマネバディ）という形でより事業を加速できるような形を取り入れることとしました。
リスクナビ
これは主に通常・個別の相談案件に対応するものです。従来のリスクレビューを踏襲しているのですが、「レビュー」というと受け身な感じがどうしても出てしまうので一緒に得たいものを得ていこうということでこのような形にしています。
リスマネバディ
当社が特徴的なのはこちらの制度です。会社・事業上、より重要な大玉案件には、個別の相談に対応するのではなく、担当者を立ててより伴走できるようにしております。
特に、上記のフェーズに対応するため、Ubieでは、事業のフェーズに応じてリスク部門の関わり方を変えるようにすることとしました。
具体的には、以下のようなプロセスを経て、法務部門が事業をサポートしています。
0-5フェーズ（PSF～PMF前）：
この段階では、サービスの方向性が定まらないため、精緻な検討は求められません。ノックアウトファクターのみを見て、事業の方向性が大枠で問題ないかを判断します。ここでは迅速なフィードバックが重要です。
また、スケールしても引き続きついて回るリスクはありえます。そういったものは事前にお伝えし、そもそもスケールする蓋然性はあるのかと一緒に検討してもらうこともあります。
リスクヘッジの対策は最低限とし、どこまでとるかはPO(product owner)に委ねます。このフェーズは数名で検証を回すことが多くリソースに限界があります。法務の対応より事業を伸ばすためにやることはたくさんあります。リスク対策に使うリソースは最低限であるべきです。
例えばデータの安全管理も、このフェーズであればきちんとしたDBを作らずとも手作業での管理でよしとするといったものが考えられます。また、いわゆるレピュテーション観点でもこの段階ではユーザー数が少ないため大きく考慮することはしません。
ただし、検知しているリスクについては可視化し、いつかスケールしたタイミングで対応できるようPBI（product backlog item。追って対応するタスク)に積んで明瞭化しておきます。
5-10フェーズ（PMF～GTM・スケール前）：
この段階では、今後のスケールを見据えて、積んでいたバックログの処理を進めたり、プロセスの整流化やドキュメント類の型化・ひな形化・規約化もこのタイミングで行っていきます。
例えば、契約雛形の作成、契約を規約様式に変更したり、販売管理プロセスを整備したりなどの対策が考えられます。また、ユーザー数や顧客数が増えてきているのであれば、レピュテーション観点のリスクアセスメントにも重みづけをしていきます。
10-100フェーズ（GTM・スケール以後）：
この段階では、法務の関与が通常対応に移行し、リスクの検知は事業部門が行い、法務はそのサポートを行います。また、このフェーズではユーザーやクライアント企業もついてきておりますのでリスクテイクよりはよりリスクヘッジ策に対応できるようにします。
具体的には、個別の論点についての相談対応などが想定されます。このタイミングにまでくると事業がある程度出来上がっております。なので相談の内容も、いちからスキームを検討するというよりは、既にある土台に対しての枝葉の論点のブラッシュアップが多くなります。
また、事業のリスク担当者をアサインしてインプットやトレーニングを行います。これにより頻出の論点やQ&AなどはFAQを作るなどして事業内で完結して対応できるようにしていきます。
このように、フェーズごとにやるべきことを明確にし、事業が得たいものを必要なタイミングで提供できるようにしています。また、フェーズ毎に見るべき観点やかかわるリスク部門の担当者も変わってきます。適宜バディの担当を受け継ぎながら全体としてマネジメントを行っています。
また、検討のやり取りについては各レビュー担当者で参照できるよう、フロー情報はslackの特定のchannelを立てその中でやり取りを行うことでその中にまとめていき、ストック情報はnotion内に議事録含めて記事としてまとめています。これにより情報の散逸も防いでいます。
このプロセスいいところ
このプロセスのいいところは主に以下の3点にあります。
事業のフェーズ毎にその時に得たいものを提供できる：
ここまでに記載している通り、フェーズによって事業がリスク部門から得たいものや情報は異なると考えております。
特にアーリーフェーズの事業にとっては情報を与えすぎることがかえって事業の萎縮効果を起こす可能性もあると思います。あれもリスク、これもリスクみたいなことを言われたら担当者もやる気が失せますよね？また、リソースは有限です。情報を与えすぎないことで、サービスとして本質的に重要なことに時間を割いていただくのもよいかと思います。
事業が成長してきたら徐々により細かい点についての整備も行います。事業への移譲できるところは移譲してより冗長性をもった対応をできるようにします。逆にこのフェーズでは既に顧客やユーザーも一定ついておりますので、リスクテイクよりはリスクヘッジに重きを置いていきます。
適切なタイミングで適切な分量での関与をすることで、トータルとしては充分な形でのリスクマネジメント・リスクテイクを推進できると考えます。
案件を点ではなく線、面でとらえられる：
従来の課題であった全ての相談をフラットに受けてしまうので軽重が分からないという課題に対してより線や面で捉えられるようになりました。それにより施策全体をより俯瞰して整理できるようになったかと思います。
今後やることをPBI（バックログ）に積んでおくということを通じてリスク対策を経時的に線で捉えることができます。また、このサービスって何だっけ？といちいち説明してもらうコストを省けたり、過去の検討が明瞭になっているのも線で動かせるメリットです。
また、面という意味では、OKRを参照することで現時点での案件の会社としての位置づけが分かるので、相談されているサービスが会社や事業全体からみて重要な施策なのかが分かります。これにより、対応にかかるリソース配分も調整できます。OKRとアラインしているため、選択と集中をすることができ少ないリソースでも適切なレビュー依頼対応やリスクマネジメントができていると思います。
ナレッジの集約：
情報をバディの案件毎にフロー情報はslackの専用のchannelに、ストック情報はnotionの専用ページに集約されます。過去の検討事項が明瞭になっているため、他のサービスの検討事項を参照することができます。また、ナレッジの共有もスムーズに行えるようにしております。
また、案件ごとにslackのchannelを分け、相談や論点ごとにスレッドを分けるということを徹底しておりますので一つの案件でスレッドが200以上になって分からなくなると行ったこともありません。体感ではスレが40以上になるとどこかでコミュニケーションエラーや論点のブレが発生しているように思います。このようなときは意識的にスレッドを分けています。
課題と今後の展望
しかし、このプロセスにもいくつかの課題も存在します。
まず、担当者の偏りが出やすく、アーリーフェーズはどうしても法務が多くの案件を抱えることがあります。また、10-100フェーズへの対応はチェックリスト化しづらく、サービスごとに論点が異なるため、型化が難しいという現状もあります。
今後は、冗長化や10-100フェーズへのより細かい対応がチャレンジのポイントかなと考えております。
最後に
ここまで読んでいただきありがとうございます。
法務部門の役割は、企業の文化やフェーズによって大きく異なると思います。既に成熟した企業であれば既存の事業を安定的に回すというのがメインとなってくるかなと思うので、ここに記載したような0-5の対応などは特に必要ないかもしれません。この辺は会社によって異なってくると思います。
ただ、当社のようなスタートアップでは、0-5や5-10のフェーズも多いですしリスクテイクを後押しする法務のあり方は事業の成長にとって非常に重要だと考えております。そのために経営層とのアラインを取り、フェーズに応じた関わり方を実践することで、法務部門やリスク部門は事業の成長を支える重要なパートナー、場合によっては事業の推進者となることができると考えております。
このような取り組みが現役の法務部門の方々の参考になれば幸いと思っておりますが、冒頭にも書いた通り、どちらかというと、事業部門の方にUbieのコーポレート部門と一緒に事業開発をしていくことに興味を持ってもらい、一緒にUbieを作っていくことに興味をもってもらえたらうれしいです。
おしまい
we are hiring!