プロダクトマネジャーによる法務機能の活用方法　個人情報保護法やプライバシーを例に【Product Manager Advent Calendar 2019】

hibiと申します！　この記事は Product Manager Advent Calendar 2019 の19日目です。普段、企業に属して法務機能を担っています。特に、新規サービス立ち上げに関わることが多く、今でもプロダクトマネジャーの方々ともタッグを組んで仕事をしています。

「Product Manager」と「新サービス立上げ」と「法務」の三つが交差する点について、記事を書きます。この記事が、数多くのプロダクトマネジャーに伝わり、今まで以上に、社会に価値あるプロダクトやサービスが次々に生まれる世界を夢想しています。

　：：：：：：：：：：：：：：：：：：：：：：：：：：：：：

プロダクトマネジャー視点で、新サービス立ち上げ時に、法務機能とどのように連携し、どのように付き合っていくのが、事業やお客様にとって効果的なのかの私見を記事にしていく。

また、法務として様々な新規サービス立ち上げに関わり、様々なプロダクトマネジャーを見てきた経験から、スムーズに新サービスを立ち上げ、価値あるサービスをお客様に提供できるプロセスがだんだんと見えてきた。まだ研究途中ではあるが、私から見た効果的なプロセスを記載していきたい。

なお、社内に法務機能が存在していることを前提に記載をしていくが、社内に法務機能が存在していない場合は、社内の管理部門の人や社外の弁護士を想定しながら、読んでいただきたい。

はじめに

プロダクトマネジャーは、お客様に価値あるプロダクトやサービスを提供する役割を担っていると共に、プロダクトやサービスというエコシステム内のルールメイカーだ。

ラグビーのプレイヤーがルールを知らずして、ラグビーの試合を戦えないように、プロダクトマネジャーは、法律を知っておく必要がある。

とはいえ、無数の法律があり、それを知るのは大変だ。また、分厚い六法を読むのは酷だし、そんな必要はない。基本原理を知っておくのが大事だ。

名著がある。それは『事業担当者のための逆引きビジネス法務ハンドブック』である。この本は、リアルワールドとリーガルワールドをつなぐ架け橋となる書籍だ。武器となる本だ。第2章では「収益改善戦略」、第3章では「コスト削減戦略」に関する法務知識が、綺麗にまとまっている。その点からすると、後ほど言及する「運用」フェイズに特にマッチする本だ。

一方で、新規サービス立ち上げ（①コンセプトメイク、②設計、③実装）については、なかなか名著がない。もちろん、『事業担当者のための逆引きビジネス法務ハンドブック』にも「新規事業開発」のパートがあるので、それを補足する形で、新規サービス立ち上げに絞って、勘所を記載していく。

また、法務機能との付き合い方も記載していく。法務パーソンとコミュニケーションするための言語を手に入れよう。異世界の人と話すためには、共通の言語を持つ必要がある。

前提

個人情報の取り扱いについてに焦点を絞る。個人情報の取り扱いについてを例示的に使って法務との付き合い方を考えたい。

記事「プロダクトマネージャーに必要なテクニカルスキルを定義してみた話。」によると、プロダクトマネージャーに必要なテクニカルスキルは、以下の6つのスキル領域になる。

▼1.Project Management
▼2.Dev.
▼3.Design
▼4.Growth
▼5.Business
▼6.Domain Knowledge

上記の記事では、以下のように、「5.Business」を定義付けている。

ビジネス（Business）は、一般的なビジネススキルを含め、プレゼンテーションやファシリテーションなど、プロダクトをビジネスの視点からリードするためのスキル領域です。

「5.Business」はさらに細かなスキル要素から構成されていて、「法務」や「経営知識」が含まれる。

本記事では、特に、個人情報関連の「法務」をテーマに記載する。付随して、「5.Business」のうちの「経営知識」にも言及したい。

つまり、プロダクトマネジャーの機能として、法令の理解をした上で設計、実装を行う機能、さらに、事業戦略ストーリーの立案を行う機能、事業戦略ストーリーが不明な場合は具体化していく機能が含まれているという前提で、以下の記事を記載している。

また、主にBtoCの新規サービス立ち上げを想起しながら、以下の記事を書いた。

プロダクトのライフサイクル

本記事では、プロダクトのライフサイクルを以下の通り定義づけ、この枠組みで記載していく。今回、主に取り上げるのは、フェイズ1とフェイズ2だ。さらに、フェイズ3の実装にも簡単に触れる。運用フェイズと撤退フェイズは、本記事では、取り上げない。

▼フェイズ1 コンセプトメイク：事業戦略、ビジネスモデルなどの決定
▼フェイズ2 設計：　ITシステムの開発はまだはじめていないフェイズ。ITシステムの要件定義は、このフェイズで行う。
▼フェイズ3 実装：ITシステムの開発、ウェブサイトの画面の制作、プレスリリースの作成、利用規約・契約書・プライバシーポリシーの作成など
▼フェイズ4 運用：サービス開始後、撤退までの全ての業務
▼フェイズ5 撤退：撤退をすることを決めてから、実際にサービスを終了するまでの全ての業務

コンセプトメイク前に知っておきたいこと

■法務の役割とは何か？

法務の機能の大きな一つに、リスクマネジメントがある。分解すると、①リスクの発生確率算出機能、②リスク発現時のインパクトの大きさ予測機能、③リスク発現頻度、および、インパクトのコントロール機能の三つだ。

リスクマネジメントは、リスク低減とは全く異なる。もちろん、法務は、違法なプロダクトやサービスは断固として反対するが、①リスク発生確率をゼロにすることや②インパクトの大きさをゼロにすることは不可能であることを認識している。リスクをゼロにすれば、お客様への価値も著しく低くなる。一定のリスクを取りつつ、お客様への価値を高めることが大事だ。

さらに、個人的な見解だが、法務のもう一つの大きな機能として、エントロピー低減機能がある。つまり、プロダクトマネジャーは様々な打ち手を考えるが、法務は何が違法で、何が適法なのかを素早く見分けられ、結果、打ち手の数を効率的・効果的に減らしてくれる。

■個人情報やプライバシーについて知っておくべきことは何か？

個人情報保護法は最低限のことしか書いてない。個人情報保護法だけを遵守すればいいというものではない。個人情報保護法を遵守すれば、何ら問題はないという時代は終わった。

重要なのは、単にルールを守ればいいという訳ではなく、お客様個人を守る、お客様個人のプライバシーを侵害しないということだ。

とはいえ、プライバシーという言葉は、人によって、そして、文脈によって様々な意味で使われるから厄介だ。だからこそ、法務機能を頼りにしてほしい。

プロダクトマネジャーは、プライバシーについても、人に対する感度を高く持ち、法律を守ることは当然として、お客様を守るという意識を持ちたい。

それでは、実際に各フェイズごとに何をするべきかを検討していきたい。

フェイズ1 コンセプトメイク

はじめに言葉ありき。言葉は神と共にあり、言葉は神であった。
　　　　　　　　　　　　　　　　　　　　（ヨハネによる福音書１章1節）　

神様でも、言葉を使って世界を創造したようだ。世界を作るためには、まず言葉が必要だった。

翻って、新しいプロダクト、サービスを創造するプロダクトマネジャーに必要な言葉とは何か？

コンセプトメイク完了時に必要な三種の神器を提案したい。つまり、以下の三つに関する三種のドキュメントを用意する。

①事業戦略ストーリー
②ビジネスモデル（例えば、商流図）
③情報の流れ（例えば、情流図）

リアルワールド三大ドキュメントを用意する。上記の三つについて、言語化、可視化することが大事だ。

■事業戦略ストーリーの立案

コンセプトメイクでは、ブレない軸を合意形成することが大事だ。事業戦略は多義的だが、『ストーリーとしての競争戦略 優れた戦略の条件』を参考に、事業戦略ストーリーを作ることをお勧めする。各会社によって状況が異なると思うが、プロダクトマネジャーの大事な機能は、①コンセプトメイクフェイズで事業戦略ストーリーを具体的にすること、②事業戦略ストーリーに基づき設計、実装を進めること、③事業戦略ストーリーに基づいて運用することだと私は考える。

私は、以下の記事に強く共感する。

「スタートアップの強みはストラテジーと実装の一致」

スタートアップの強みはストラテジーと実装の一致 | 矢本 真丈 (@yamotty3)

なお、事業戦略ストーリーとピボットとの関係性については、私自身として、答えが出ていないが、ピボットと称して、以下の5Cのいずれかを変更するのは、事業上の黄色信号だと考えている。リトマス試験紙として使える。

▼戦略ストーリーの5C by 楠木 建先生
1 競争優位（Competitive Advantage）
2 コンセプト（Concept）
3 構成要素（Components）
4 クリティカル・コア（Critical Core）
5 一貫性（Consistency）

また、上記5Cに基づいて、事業戦略ストーリーを言語化、可視化できていない場合は、赤信号だ。

Peter Thielの『ゼロ・トゥ・ワン 君はゼロから何を生み出せるか』110から111頁には、以下の言葉がある。

エンジニア主導のシリコンバレーでさえ、今流行りの戦略といえば、変わり続ける環境に「適応」し「進化」する「リーン・スタートアップ」だ。起業家予備軍は、先のことは何もわからないのだと教えられる。顧客の欲求に耳を傾け、MVP（実用最小限の製品）以外は作らず、うまくいったやり方を反復すべきだと言われる。

「リーンであること」は手段であって、目的じゃない。既存のものを少しずつ変えることで目の前のニーズには完璧に応えられても、それではグローバルな拡大は決して実現できない。

スタートアップにおいてはインテリジェント・デザインこそが最適だ。

①リーン・スタートアップ、②インテリジェント・デザイン、③それ以外の対立だ。どの方式を採るかも、事業戦略検討の論点の一つである。

私は、Peter Thielの意見に近い。つまり、事業戦略の5C（WHATとWHY）は、②インテリジェント・デザインで設計し、HOWの部分を中心にPDCAをまわすのが筋が良いと考えている。

コンセプトメイクのフェイズ、特に事業戦略ストーリーの立案は、プロダクトやサービスにおいて、最も重要だと私は考える。この論点について、プロダクトマネジャーの方々と話せたらと思っている。

■商流図の作成

以下のような流れで作成する。

▼⑴ 登場人物、登場法人（以下「プレイヤー」）を一覧化する。プロダクトやサービスを提供する上で必要な法人やお客様を洗い出す。
▼⑵ 次に、どのプレイヤーからどのプレイヤーに対して、具体的に何を提供するのかを記載する。箇条書きで列挙し、さらに各項目について、2文以上で補足説明をする。
▼⑶ もし⑵で、プレイヤーAからプレイヤーBに業務やサービスなどの提供があれば、プレイヤーBからプレイヤーAに何かしらの対価が発生するのが通常だ。その対価を書き出す。図解する場合は、¥マークを使う。無対価の場合は0¥と書く。
⑷ （可能であれば）誰が誰に対してどんなクレームを言いそうかを妄想・想像する。3個以上想起しておきたい。

■情報の流れを図解（情流図の作成）

パーソナルデータを扱うのであれば、どんな利用目的なのかを箇条書きにする。
逆に、リーガルワールドの話は、次の設計フェイズで法の専門家に任せ切って、洗い出してもらう。

最初から法令を意識しない。もちろん、大事なことではあるが、まずはどんな価値をお客様に提供したいのかを考える。

コンセプトメイク完了段階で、三つのドキュメントができているはずだ。

法務機能との連携の文脈で言うと、コンセプトメイクフェイズで大事なのは、リーガルワールド（法令や契約などのレイヤー）で考えることではなく、リアルワールドで考えることが大事だ。もちろん、プロダクトマネジャーが法令や契約の知識を持っていれば、それを加味してリアルワールドにおける事業戦略ストーリー、ビジネスモデル、情報の流れを考えてもいい。どちらにしても大事なのは、リアルワールドにおける生の取引、生のビジネス、生のお客様が、どのような動きをするのかを活き活きと言語化、可視化することだ。

コンセプトメイクにおいては、リーガルワールドの話とは切り離して、リアルワールドに想いを馳せたい。

可視化されていなければ、検証もできない。失敗するかどうかを判定するリトマス試験紙があるとしたら、企画を可視化（文字化、言語化、図式化）しないことだ。

アジャイルな開発となると、ドキュメントをほとんど残さないで進めるケースもあるようだ。アジャイルな開発でも、残すべきドキュメントと残さなくても良いドキュメントがあるはずだ。

フェイズ2 設計

コンセプトが固まったら、次は、法務への相談だ。

ここからは個人情報やプライバシーの観点に絞って、言及していく。

まず最低限以下の情報を整理し、言語化、可視化しておく。

- 取得する個人情報の具体的な項目
- 個人情報の持ち主
- 利用目的　生データ・加工データ・統計データという切り口で、利用目的を抜け漏れなく洗い出していくことが大事。
- （取得した個人情報を他の企業に渡す場合）具体的な提供先名、提供するデータ、提供先での利用目的

上記のフレームワークを使って、新規サービス、新機能追加の際の個人情報の取り扱いの仕方を考える。

その上で、「友達や恋人や家族に、個人情報の使い方を正々堂々と説明できるか？」を想像する。また、お客様がどんな思いをしそうか、それはポジティブな感情なのか、ネガティブな感情なのかを想像しておく。

上記を整理した上で、コンセプトメイクで作成した三つの図を法務に提示する。

このような整理をしておけば、法務は適切なアドバイスをしてくれるだろう。

法務からのアドバイスにより、何らかの変更を求められたら、どの行為が、誰に対して危害を与えるのかを聞いてみよう。リスクの発生頻度とインパクトの大きさを確認してみよう。

また、もし、プロダクトマネジャー自身の感覚からして、法務のアドバイスに違和感を感じた場合は、どの法令の、どの条文を根拠に言っているのかを確認しよう。具体的な法令に基づいてアドバイスされているのか、そうではないのかを区別しておくことが大事だ。具体的な法令名、条文番号が分かれば、自身でも法律の言葉を直接読んでみることをお勧めする。これを地道に実行し続ければ、戦闘力が高まる。走り込みの数がモノを言う。

上記のようなプロセスを通じて、例えば、ITシステム開発において、どんな要件を組み込まなければいけないかが、根拠を持って、洗い出すことができるはずだ。法務に依頼して、根拠となる法律条文、そこから導き出される要件を可視化、言語化してもらい、擦り合わせをしておきたい。これらの事項はドキュメント化して、保存をしておこう。

フェイズ3 実装

設計が完了したら、次は実装を行っていく。プロダクトマネジャーから法務に対して、一般的には、お客様向けのプライバシーポリシー、利用規約・契約書の作成（以下の4 法（Law）に該当する部分）を求めることが多いと思う。

実は、法務が活躍できる役割には、以下にあげた1 アーキテクチャ（Architecture）、2 規範・慣習（Norms）、3 市場（Market）に該当する部分もある。必要に応じて、法務にアドバイスを求めてみよう。

▼1 アーキテクチャ（Architecture）：プライバシーに配慮したITシステム。①お客様の目に晒されるITシステム、②それを支えるサービス提供者内で使われるITシステム　※プライバシー観点以外では、業務プロセスを支えるITシステム、請求、売上管理、経理システムへの接続などシステム間の連携も含む。

▼2 規範・慣習（Norms）：個人のお客様に向けたプライバシーポリシーの説明、プライバシーに関して双方向でコミュニケーションできる仕組みなど。　※プライバシー観点以外では、説明を行うウェブページ、パンフレット、提案書、プレスリリースなど。

▼3 市場（Market）：個人情報の取得等のやり取りで金銭を発生させるかどうかなどか。　※プライバシー観点以外では、価格やキャンセルポリシーなど。

▼4 法（Law）：お客様向けのプライバシーポリシーなど　※プライバシー観点以外では、契約（規約や契約書）など。

コンセプトや設計思想が変化すると、法的な建て付けも変わる可能性がある。小さな変化であっても、都度、法務機能に共有していこう。確かに手戻りが発生するかかもしれないが、急がば回れで、結果的には、サービスリリースまでのリードタイムが短くなるはずだ。

まとめ

プロダクトマネジャーにとって重要だと私が感じるのは、①リアルワールドにおけるプロダクトやサービスの事業戦略ストーリーやビジネスモデル等を具体的に創造・想像し、言語化、可視化すること、②法律の基本原理をおさえておくことだ。

スポーツのプレイヤーと同じように、プロダクトマネジャーも法令というルールを理解しておくと、スムーズに物事を進められる。ただ、細かなルールに拘泥せず、基本原理をおさえることが大事だ。

プライバシーは難しい。プライバシーが侵害されても、血は流れず、肉は断たれないからだ。だからこそ、判断にぶれが生じる。村上春樹の「壁と卵」ではないが、個人の一人一人のプライバシーという卵を、壁から守り切らなければ、新規サービスにおける長期的利益はもはや手に入らない時代になっている。一度、卵が割れたら、元に戻せないように、プライバシーが一度侵害されたら、元に戻らないことがある。

プライバシーの概念はおそらく今後も変化し、広くなっていくと推測する。実際、世界各国で、新たな個人情報関連の法律が作られ、また、新たな判例が出てきている。

プライバシーの概念を定期的にアップデートするために、多様な価値観の人たちと、場を作り、繰り返し議論し、時には、対話をすると、新たな切り口が見え、認識が揃ってくる。事業戦略ストーリーの認識合わせと同様に、プライバシーの概念を揃える場を、定期的に設けておきたい。そのような場合も、法務に相談すれば、専門的な知識をもって、アドバイスを得られるだろう。

参考文献など（兼おすすめの書籍等）

・楠木建『ストーリーとしての競争戦略 優れた戦略の条件』
・ピーター・ティール (著), ブレイク・マスターズ (著), 瀧本 哲史 (その他), 関 美和 (翻訳)『ゼロ・トゥ・ワン 君はゼロから何を生み出せるか』
・入山章栄『世界標準の経営理論』
・塩野誠、宮下和昌『事業担当者のための逆引きビジネス法務ハンドブック』
・雨宮 美季、片岡 玄一、橋詰 卓司『【改訂新版】良いウェブサービスを支える 「利用規約」の作り方』
・IPA「ユーザのための要件定義ガイド 第2版」
https://www.ipa.go.jp/ikc/reports/20190912.html

・ローレンス・レッシグ『CODE VERSION 2.0』
・板橋悟『ビジネスモデルを見える化する ピクト図解』
・板橋悟「「ピクト図解メソッド」と「ビジネスモデルキャンバス」 を連動したビジネスモデル設計技法」　
https://umtp-japan.org/pdf/mf2015/mf2015_itahashi.pdf

明日、12月20日は、@mizuki_tanno さんです。よろしくお願いいたします！

以上