新サービス立ち上げ×アジャイル法務＝プロダクトカウンセルへの第一歩
はじめまして、hibiと申します！
「法務系 Advent Calendar 2018」の12月5日分の記事として、新サービスの立ち上げ時における法務の関わり方について書いていきます！ ［2020年11月29日追加］約11597 文字で、長い記事となっています。
【2018/12/08更新】
本記事のスコープ
本記事を書こうと思ったきっかけ
本編
・新サービス立ち上げのプロセスとは？
・新サービス立ち上げにおける「今までの」法務の関わり方
・ステップ1 「新サービス立ち上げキックオフ時」のアジャイル法務
・ステップ2 「新サービスデザインフェイズ」のアジャイル法務
・ステップ3 「新サービス実装フェイズ」のアジャイル法務
・ステップ4 「新サービスの開始直後」のアジャイル法務
まとめ
終わりに
参考にしたサイトや書籍
おまけ 法務パーソンのポータブルスキル プロジェクトマネジメント力
おまけ2
本記事のスコープ
新サービス・新プロダクトのライフサイクルは、①生まれるまで、②生まれてから死ぬことを決めるまで、③死ぬことを決めてから死ぬまでの三つに分かれるが、今回は、①に焦点を絞り、法務のより良い関わり方を考えたい。
本記事を書こうと思ったきっかけ
ITシステムの開発において、アジャイルな開発というものがあり、最近の新サービスの立ち上げにおいて、ITシステムの開発が大きな部分を占めているせいか、アジャイルな新サービス立ち上げと言っても良いくらい、スピード感に溢れた立ち上げになっている。新サービスを開始することの決議が終わってから、実際にサービスを開始するまでの期間が短くなっている。
そのような中で、法務部門は、既存のやり方ではそのスピードについていけないため、アジャイルな法務に脱皮する必要があると考えた。法務パーソンとして、日常的に気をつけていること、気をつけたほうが良さそうなことを記載していく。
ニュースを見ている限りでは、いろいろな企業で新規事業を立ち上げようとしており、様々な会社の法務が苦労しているのではないかと考える。
本来であれば、プロダクトマネジメント手法が確立していて、かつ、法務の新規サービス立ち上げ支援手法が確立している企業の方法論を知りたいのだが、なかなか知る機会もないので、まずは私自身の考えをお伝えしつつ、理解を深めたいと考えた。
新サービス立ち上げのプロセスとは？
メルペイのプロダクトマネジャーの川嶋さんの記事によると、「Leanなアジャイル開発」において、「デザイン」と「実装」の２つのフェイズがあると書かれている。
アジャイル型のITシステム開発と言った場合、実装フェイズ（新サービスの具体的内容が固まった後のITシステム開発フェイズ）に注目がいき、設計→開発→テスト→リリース→設計→・・・とぐるぐるとイタレーションを回すことを意味することが多いと思うが、「Leanなアジャイル開発」と言った場合、デザインフェイズにおいても、アイデア→プロトタイプ→検証→ラーニング→アイデア→・・・とぐるぐるとイタレーションというやつを回すのが特徴のようだ。
新サービス立ち上げにおける「今までの」法務の関わり方
旧来の法務の新サービス立ち上げにおける規約の作り方（正確には、過去の私の規約の作り方、だが）は、法務として新サービスのデザインフェイズに入り込むものの、デザインフェイズが終わり、新サービスの具体的な内容、例えば、サービスの目的、機能、料金、その他の詳細が決まったら、ようやく規約作成に着手していた。
つまり、以前は、ウォーターフォール式の規約作成を行っていた。
ここからは、私が考える新サービス立ち上げにおける「これからの」法務（「アジャイル法務」と呼びたい。単に、流行り言葉だから使いたいという気持ちがあるのも正直なところなので、あまり突っ込まないでほしい）の動き方の私見を書いていきたい。
ステップ1 「新サービス立ち上げキックオフ時」のアジャイル法務の動き方
まず、アジャイル法務としては、「新サービス立ち上げキックオフ時」に、「一人の決裁者を選ぶべき」と進言したい。
最終的に機関決定をしなければいけない場合も、当該機関における決め方をあらかじめ決めておくべきだ。
そして、明文化して、組織図に記載しておく。
もちろん、プロダクトマネジャーに全ての決裁権限がある場合もあるだろうが、真の決裁権限者を確定し、承認を得ておくことが重要。プロジェクトが進行した後に、仕切りなおすのは、経験上、難易度が高いと思うからだ。
決裁者を特定しておかないと、以下の症状が出てくる。
・症状1 決裁者が不明確で、サービスの具体的内容がいつまでも決まらない。サービスが決まらないと、リスクを正確に予想できない。
・症状2 決裁者が不明確なため、色々な人がいろいろなことを言うため、決めるべき論点が増え、収拾がつかなくなる。
・症状3 たくさんの決めるべき論点がある中で、優先順位付けができない。
結果、サービス開始がずるずると遅れる。
現状では、習熟したプロダクトマネジャーが市場にも豊富におらず、当然、社内にもいないため、これらのことに柔軟に対応できない。プロジェクトマネジャーと異なり、プロダクトマネジャーは、終了しないこと、つまり、サービスが開始され、顧客にサービスを支持され続けることが目的だと考えると、プロダクトマネジャーが色々なサービスの立ち上げに関わることが少ないので、それは当然だ。
一方で、法務パーソンは、リスク感度が高い人が多いように思うが、サービスに内在するリスクを感知できるスキルがあることは当然だとして、プロジェクト進行を妨げそうな障壁を感知できるスキルも比較的高い。だからこそ、法務は、プロダクトマネジャーの役割だと思われていることでも、積極的に発言をしなければならない。
ステップ2 「新サービスデザインフェイズ」でのアジャイル法務の動き方
次に、「新サービスデザイン（設計）フェイズ」だ。このフェイズで重要な役割を果たすのは、法務パーソンの大好物である規約や契約書だ。
契約には二つの機能がある。performance planningとrisk planningである。perfomance planningは「履行円滑化の工夫」であって、契約債務の履行を円滑に行うようにすることを目的としている。risk planningは「リスク対処の工夫」という意味だ。
※樋口 範雄 『アメリカ契約法[第2版]【アメリカ法ベーシックス1】』p.10
自分なりの理解だと、performanceプランニングは平時、riskプランニングは有事の際に、滞りなく円滑に取引が進むようにするための工夫だと捉えている。
契約のプロである法務は、performanceプランニングやriskプランニングのプロである。これらを使いこなせる法務は、実は、サービスデザイン（設計）段階においても、価値を発揮することができる。
それはなぜか？
新サービス立ち上げに慣れていないプロダクトマネジャーは、様々な社内のステークホルダーに意見を聞きながら進めていくが、あまりに意見を聴きすぎるがあまり、決めるべき論点を膨大に増やしてしまい、何を先に決めて、何を後で決めればいいのか？、という点でつまづくことが多い。
新サービスを構成する要素はたくさんあるが、プロダクトマネジャーは、どの要素が枝葉なのか？、どの要素が幹なのか？、を見極めなければならない。
幹を見極めるための一つのツールが、契約書や規約だ。契約には重要なことだけが記載されているからだ。
過去の進め方では、新サービスの内容が完全に固まった後、つまり、「新サービスのデザインフェイズ」が完了した後、その具体的な内容に合わせて、規約を作成していた。
アジャイル法務は、「新サービスのデザインフェイズ」の極々初期のタイミングで、規約案をプロジェクトメンバーに共有し、メンバーみんなで具体的な規約案を見ながら、新サービスのデザインの支援を行う。
具体的には以下のような手順で行う。
1. すでに入手している抽象的なサービス概要をもとに、契約当事者を想定し、誰とどんな類型の契約が必要なのかを見立てる。
2. 見立てた後、既存の自社のサービスの契約書・規約や市販の書籍の契約書ひな形で、最も近いひな形を選択し、最低限の修正、例えば、契約当事者の修正などをして、プロダクトマネジャーやプロジェクトメンバーに規約案を送付してしまう。
3. 送付した規約案を一緒に見ながら、新サービスのデザインに関わる要素について、プロダクトマネジャーにヒアリングをしていく。ヒアリングの視点は後述する。
4. 法務だけが規約を作るのではなく、関与するメンバーも規約にコメントを書き込んでいく。文字通り、みんなで一緒に規約を修正していく。
5. 結果、「新サービスのデザインフェイズ」完了時には、新サービスの具体的な取引に合致した規約が姿を見せ始める。
上記3.のヒアリングは、performanceプランニングとriskプランニングという二つの視点で行う。
まずはperformanceプランニングについてのヒアリングだ。
これを行うことで、何をまずは決めなければいけないのかを、具体的にプロダクトマネジャーにイメージしてもらいやすくなる。以下の4点をヒアリングしている。
1. お客様に提供する価値や機能は何か？
→この問いの答えが、サービス提供者側の義務（shall）になる。
そもそもどんな目的なのか？、もともと誰に対するどんな課題を解決しようとしていたのか？という「そもそも」と「もともと」の問いは、強力なツールである。合わせ技で使いたい。
2. お客様から報酬をどのように、いくらもらうのか？
→お客様の義務（shall）
3. お客様がサービスを利用する上で、最低限何をしなければならないのか？
→お客様の義務（shall）
4. お客様は、サービスを利用する上で、何をしてはいけないのか？
→お客様の禁止事項（shall not）
A4の紙に縦と横の線を引き、マトリックスを作って考える。横軸は当事者で、サービス提供者とお客様を置く。縦軸は、shallとshall notという項目を置き、各セルを埋めていくような作業だ。
ITシステム部門のメンバーを交えて話すとより効果的だ。ITシステム部門こそ、「デザインフェイズ」の次の「実装フェイズ」における主役になることが多く、新サービスにはITシステム開発がほとんどつきまとうため、サービスデザインにおいて本質的に重要な部分を見抜く力が養われていることが多いと感じるからだ。
また、個人情報や機密情報のCIAを管理する情報セキュリティ部門のメンバーも巻き込むべき。
次は、riskプランニングについてのヒアリングだ。
具体的には、リスクやトラブルの洗い出しを行う。M&Aや他社との連携の時と同じように、プロダクトマネジャーは、いかにお客様に価値あるサービスを提供するのかというポジティブなことを中心に考えており、お客様にどんなネガティブなことが発生するのか？、お客様はどんな不満を持ちそうなのか？、お客様はどんなクレームを言いそうなのか？という問いを検討しない傾向がある。
プロダクトマネジャー1人に、想定されるリスクやトラブルを考えてもらうというよりも、30分程度時間を作り、一緒に対面でブレストをすることをお勧めする。ここでリスクの洗い出しができれば、契約で手当する箇所を特定できるメリットもあるが、問い合わせを受けるコールセンターのFAQにも反映させることができたり、お客様への説明資料に反映できたりするので、お客様に害を与えないような手当が可能となる（実は、このブレストが、次のフェイズである「実装フェイズ」における手当に繋がってくる）。
顧客からサービス提供者へのクレーム、サービス提供者から顧客への要望、第三者からサービス提供者へのクレームなどがある。大事なのは、2者の当事者間の全ての組み合わせを検討し、かつ、両方向について検討をすることだ。
リスクが想定できないのであれば、それ自体がリスクである。その場合は、具体的に取引を想像できていないので、もう少し情報を集める必要がある。ただ、精緻に情報を集めることが目的ではないので、時間をかけすぎない。
performanceとriskについてヒアリングして、規約を修正して、プロダクトマネジャーに読んでもらい、またヒアリングする。そんなプロセスを3回転、繰り返し、ワードファイルの本文にお互いのコメントを残していく（ワードのコメント機能を使うと、ファイルが壊れやすいので、使っていない）。メール本文ではなく、ワードファイルに記載をしておくことで、どんな趣旨で各条項を作成したのかという見やすい履歴が後世に残る（コメント機能は読みにくい）。
ステップ3 「新サービスの詳細が決まった後（新サービス実装フェイズ）」のアジャイル法務の動き方
新サービスのデザインが完了した後、つまり、サービスの内容が固まった後は、様々な角度から、リスクに対するコントロールを実装していくことになる。
法務の主戦場は、契約による手当になるが、アジャイル法務はそれに留まらない。つまり、リスクをマネジメントする手段には、「契約」は当然あるが、契約以外の手法もある。新サービス立ち上げにおける契約以外のリスクマネジメントの手段を検討する上で、レッシグさんの四つの規制枠組を応用できる。アーキテクチャ（Architecture）、規範・慣習（Norms）、市場（Market）、法（Law）という四つだ。
*水野祐『法のデザイン—創造性とイノベーションは法によって加速する』p.15, 16
新サービスがウェブサービスの場合、サービスに関わるお客様（個人や法人）とサービス提供者とで構成される群を、一つのエコシステムだと考えると、レッシグの規制枠組の考えと接続ができると考えた。そのエコシステムの設計は、「実装フェイズ」において、法務が支援できる重要なプロセスだと思う。
・アーキテクチャ：お客様の目に晒されるITシステム、それを支える裏側のITシステム（請求、売上管理、経理システムへの接続など）
・規範・慣習：サービス説明を行うウェブページ、パンフレット、提案書、プレスリリースなど
・市場：価格やキャンセルポリシー
・法：契約（規約や契約書）
今までの法務は、契約の作成に重きを置いてきたが、契約書・規約の作成だけがポイントではないのだ。レッシグさんの規制枠組の四つの要素を用いてエコシステムを設計することが、法務としての価値だ。
規範・慣習は、サービス開始タイミングでは、エコシステム内には浸透をしていない。新しいサービスであればあるほど、エコシステム内の住人であるお客様やサービス提供者側の従業員は、サービス利用時に戸惑うはずなので、様々な手段でエコシステム内で通用する規範・慣習を浸透させていく必要がある。
市場については、エコシステムへ参加するための価格、エコシステムから離脱するための条件を設計し、実装する必要がある。
法は、エコシステム内で機能する法である契約が該当する。実装フェイズにおいては、プロダクトマネジャーを交えつつ、リスク感度が高いメンバーも巻き込み、やや長めの時間を取り、対面で規約の読み合わせを行うと、規約の完成度が急激に高まる。
上記の4つのうち、法以外の設計は、法務が担うことはほとんどない。ただ、法務が「新サービスのデザインフェイズ」という初期から検討に加わることで、「実装フェイズ」で考えるべき4つの要素を視野に入れながら新サービスのデザインを行うことができ、各部門がそのデザインに基づいて実装することで、結果、お客様にとってサービスを安全・安心なものにできる。
もちろん、安全性を優先しすぎてしまうと、価値がストレートにお客様に届かなくなってしまうし、価値提供が優先されすぎてしまうと、お客様が新サービスを安全に利用できなくなる。
なので、バランス感覚を持ったアジャイル法務が、四つの要素を効果的に定められるように、サポートをする必要がある。
ステップ4 新サービスの開始直後
新サービスが開始すると、次のプロジェクトにすぐに目がいってしまいがちだが、以下のことはやりたい。
・プレスリリースを読む。
・新サービスを利用する。少なくとも、新サービスのサイトやアプリを見てみる。
・新サービスの感想を、プロダクトマネジャーやプロジェクトチームに共有する。せっかくのサービスの誕生日だ。お互いに一言声をかけたい。
以上、新サービスに関するプロジェクト発足から、新サービス開始までのプロセスに沿って、アジャイルな法務の動き方のコツを書いてみた。
まとめ
アジャイル法務の動き方のコツを以下に簡単にまとめる。
1. 新サービスデザインフェイズのごくごく初期のタイミング、具体的には、新サービスの相談が法務に来た直後に、サービス内容から契約類型を判別して、極めて粒度が粗い規約案を提示してしまう。
2. 新サービスの内容が具体化してから規約作成に着手するのではなく、新サービスを具体化するツールとして、規約案を利用する。規約の細かい修正を繰り返し、修正の度にフィードバックを得て、連続的に規約を作り上げていく。結果的に、新サービスデザインフェイズ完了時には、規約の8割ができている状態を目指す。
3. 新サービスデザインフェイズで、押さえるポイントは、①そもそもの目的は何か？、どのようなお客様のどのような課題に対してどのような価値提供をするのか？、②どのようなお金のもらい方をするのか？、③お客様にしてもらう必要があることは何か？、④お客様がやってはいけないことは何か？、⑤どのようなリスク・トラブルが起きそうか？、の5つ。
4. 新サービスの実装フェイズでは、リスクマネジメントだけではなく、オポチュニティマネジメントの観点を加味して、①法：規約、契約書だけではなく、②規範：サービス説明を行うウェブページ、パンフレット、提案書など 、③市場：価格、キャンセルポリシーなど、④アーキテクチャ：お客様向けのITシステム、社内のITシステムの視点で、それらの設計支援を行う。
終わりに
アジャイルなITシステム開発の手法を横目に、アジャイルな法務に取り込めそうな手法や工夫していることを記載してみた。
プロダクトマネジャーは、プロダクトのCEOと呼ばれる。一方で、法務はプロダクトのゼネラルカウンセル（GC）だと言える。プロタクトマネジャーのパートナーとなり、プロダクトのガーディアンにならなければならない。開始直後の新サービス・新プロダクトは、生まれたての赤ちゃんだ。長生きして、社会に貢献できるよう、まずはしっかり守ってあげよう。
実際に、GAFAと呼ばれる会社のうち、グーグル、フェイスブック、アマゾンでは、「プロダクトカウンセル」という職種名の求人が出ている。
プロダクトカウンセルとして高い価値を発揮するためには、プロダクトマネジャーが行う「新サービスのLeanなアジャイル開発」と伴走するように、アジャイルな法務である必要がある。
新サービスの立ち上げ支援は、意識をして取り組めば、プロダクトカウンセルになる第一歩として、とても良い訓練になる。
また、アジャイルな法務の動き方を意識することで、プロダクトマネジャーに対してはもちろん、お客様に対しても高い価値を提供できるとともに、安心してサービスを利用してもらえるようになる。それらが様々な会社で行われれば、もっと自由で生きやすい社会になると思っている。
参考にしたサイトや書籍
・Product Counsel: How to be THAT kind of lawyer
プロダクトカウンセルの心構えを記載したeBayのプロダクトカウンセルのAdrianne Goさんの記事。度々この記事を読み返し、プロダクトカウンセルの卵として、もっと伸ばせる部分はないか、足りていない部分はどこかを問うている。
1) Ask Great Questions
2) Be the Customer
3) Know Your Stuff
4) Don’t Be the Dream Crusher
・法務のキャリアパス
performanceプランニングとriskプランニングのプロであるとすれば、新たな無資格法務の「別職種ルート」のキャリアパスとして、法務からプロダクトマネジャーというキャリアパスもあるのではないか。
また、スペシャリストルートとしての「プロダクトカウンセル」コースも生まれうるのではないか。
・プロダクトマネジメントトライアングルと法務や契約の機能の関係性
以下のプロダクトマネジメントトライアングルの記事を見ると、プロダクトマネジメントに必要な要素として、法務や契約などの機能の記載が、特にない。法務パーソンとしては、残念。
・法人のお客様との契約を作成する際の参考書
名著。特に「各取引類型の法的建て付け」や「契約が存在しない場合のデフォルトルールがどのようなものなのか」を理解することできる。読むたびに、頭がクリアになり、構造化されていく。
・個人のお客様との契約を作成する際の参考書
こちらも名著。新サービスを考える上での法的観点が網羅されている。上記の方法で、規約案にだけ目を向けてしまうと、「本来書くべきことが書かれていない」ことに気づきにくいため、「規約案から離れて」リスクやトラブルを「最初に」想起していくことが重要でありコツなのだが、それでも漏れてしまうことがある。漏れを防ぐためのチェックリストとしても使えるのが、この本だ。
・[12月6日追記]国際競争力強化に向けた日本企業の法務機能の在り方研究会報告書
おまけ 法務パーソンのポータブルスキル プロジェクトマネジメント力
法務パーソンが持つであろうポータブルスキル（テクニカルスキルではなく）に着目し、プロジェクトマネジメントスキルの活用についても記載をしたが、ここで補足しておく。
実は、法務パーソンは、新サービス立ち上げ経験数が、プロダクトマネジャーよりも多い場合があるのではないかと思っている。結果、プロジェクトにおいて、何が障壁になりそうなのかを、経験が少ないプロダクトマネジャーよりも、法務の方が、より早いタイミングで、より的確に予想できるように思う。
プロダクトマネジャーは複数のサービスを立ち上げるというよりは、一つのサービスに付きっきりになることが多い。
プロダクトマネジャーは優秀であればあるほど、関わるプロダクトの数は少なくなるはずだ。サービスの立ち上げの数でいうと、法務の方が携われる数が多い。結果、習熟度も法務の方が上になるケースが多い。
そう考えると、新サービス立ち上げを数多く経験している法務パーソンであれば、次に何が起こるかを予想する能力に比較的長けていると言えるのではないか。
もちろん、その予測能力の高さは、法務という職種以外の様々な要因も影響しているはずだが、何件の新サービス立ち上げに関わったのかというのは、シンプルだが重要な指標である。プロダクトマネジャーの新サービス立ち上げ経験数が0なのか1以上なのかで、プロジェクトが円滑に進むかどうかが大きく違うと思う。0と1の間には高い壁がある。
複数の新サービス立ち上げ経験を持つ法務パーソンは、少なくともプロジェクトマネジメント力の要素の一部分である「プロジェクト進行の障害の予測能力」や「障害乗り越えのための対応方針立案力」については、自信を持って良いと思う。
お次（12月6日）は seko_lawさんです！よろしくお願いします！
以上
おまけ2（と称した備忘）
・[12月6日追記]Googleで「"アジャイル法務"」、「"アジャイルな法務"」で検索したところ、結果は0件だった。Twitterで「アジャイル法務」検索しても0件だ。BLJなどの雑誌で、「アジャイル法務」特集をしてくれたら、とても嬉しいし、とても読みたい。
・[12月6日追記]新サービス立ち上げに数多く触れると、立ち上げるごとに、桜坂洋の名作小説『All You Need Is Kill』や某名作アニメ『魔法少女●●●●●●●』の登場人物の気持ちが味わえて、おすすめ。ただ、残念ながら、私は、荒ぶるワルプルギスの夜には毎回打ちのめされている。
・[12月8日追記]アジャイル法務の良い側面だけを記載する結果になったが、悪い側面はなんだろうか？考えたい。新サービス開始直後に、プロダクトマネジャーなどの関係者を交えて、法務主導でAARをするべきだと思った。そして、そのAARをアジャイル法務の基本行動にするべきだと思う。そうすることで、属人性を減らし、組織としての底力をつけられるはず。
・[12月8日追記]契約書や規約は、新サービス立ち上げに関わる多くの部門の意見や意思が、結果的に反映される書面だと、改めて認識した。そして、ソースコードと違い、契約書・規約は人間が認識できる言語で書かれているので、ソースコードと比較したら、議論のプラットフォームとして有効なんだろうと思う。また、新サービス立ち上げにおいて、様々な文書が作られることになるが、その中でも、契約書・規約は、一番最後にアウトプットされる文書だということも、議論のプラットフォームとして有効な理由の一つだと考える。加えて、新サービスの企画書は、様々な観点で作られ、ファイル数も膨大になり、すべてのファイルを見ないと全体像がつかめないが、契約書・規約は、多くても数点しかなく、共通の文書として、各メンバーが想起しやすい文書になっているので、議論のプラットフォームとしての有効性を後押しする。
・[12月8日追記]デザインフェイズにおいて、ワードファイルをコアにして、新サービスの設計を進めていくと、プロジェクト推進のためにも効果的だというのがメッセージの一つだが、実は、ワードファイルをメールでやりとりしながら進めることを前提にして、本編の記載をしている。社内サーバー上の共有フォルダを使って、進められれば、もっと効率的に進められるかもしれない。分析しきれていないが、デメリットもありそうなので、要検討だ。連続的に修正し、コメントを入れていくよりは、スナップショットの規約案を往復させていく方が、現状では、効率的だと見立てている。
また、ワードは、グーグルドキュメントと異なり、複数の人が同時に編集できないという認識であるが、複数の人が同時に編集ができたら、もっと効率的に進められると思う。もちろん、マイクロソフト以外のアプリを使えば良いという意見もあるが、良くも悪くも、最も操作に慣れているのはワードだと思うし、それ以外の要素もあり、切り替えるのが難しいケースが多いのではないか。
各所で議論が起こっているように、法務の契約書作成環境（「プログラマのプログラム開発環境」との対比）をもう一歩突っ込んで考える必要がある。ただ、私が先入観にとらわれているだけかもしれないが、IT部門への投資額と法務部門への投資額とは、大きくかけ離れているので、法務部門側の開発環境整備はなかなか整わないようにも思う。加えて、プログラム開発は、プログラマ内で完結するが、契約書作成は各部門のメンバーを巻き込む必要があり、法務部門側で新たな開発環境を整備しても、それを法務以外のメンバーに使ってもらうための心理的障壁は少なくとも乗り越えなければいけない。
[12月8日追記]各企業が形成しているエコシステムを制御する要素として、レッシグさんの4つの要素を応用できると書いたが、企業が提供するサービスに限って言えば、実は、法（つまり、この場合「契約」）の役割・効果が薄れているように思う（もともと薄かったのかもしれない、特に平時の場合）。当然、紛争時や大規模トラブル（広範囲のお客様に不利益が出るトラブルなど）時には、契約の重要性が高まるので、法務の立場からすると、契約を考え抜く必要がある。
平時に重要なのは、むしろ、他の3要素だと考える。そして、お客様視点で考えても、その3要素をもとに、日々サービスを使うことになるはずだ。法務の仕事も、他の職種の仕事と同様に、お客様に直接価値を届けることを使命とするならば、3要素に着目しないと、価値を発揮できていないことになり、法務パーソンとして生き残れないのではと、この記事を書いた後に、個人的に思った。
以上
この記事が気に入ったらサポートをしてみませんか？