【独自インタビュー】リクルートが自社開発に踏み切った「規約同意管理システム」設計のツボ

プライバシー保護体制の見直しを発表したリクルート。その取組みの中で特に注目したいのが、どのユーザーが・いつ・どのバージョンの規約とプライバシーポリシーに同意したのかを管理する「規約同意管理システム」の存在です。このプロジェクトを担当された森様・渡部様・馬場様に、取材に応じていただきました。

350超のサービス規約＆プライバシーポリシーの表示・同意記録をシステムで一元管理するプロジェクト

—本日の取材にお時間を割いてくださいまして、誠にありがとうございます。

リスクマネジメント担当役員　森様：
こちらこそ、先日弊社のプライバシー保護に向けた取り組みをメディアで詳細に取り上げて下さり、うれしく思いました（関連記事：「なぜリクルートは組織再編日にプライバシーポリシーを改定するのか」）。私たちも、リクナビDMPフォローの件以降、一段と襟を正していかなければという思いでおりますし、今日も可能な限りオープンにお話をしたいと思っています。

—リクルートの新しいプライバシーへの取り組みについては、大手メディアも様々な視点で注目しているところです。この「サインのリ・デザイン」は、契約の電子化やリーガルテックに興味を持つ読者が多い媒体ですので、特に、プライバシーセンターで言及されている「規約の表示システムの一元化・自動化」について、詳しくお伺いできればと思います。

プライバシーセンター・規約同意管理プロジェクト責任者　渡部様：
私がプロジェクトの責任者をつとめました。中途で当社に入社し、以降ずっと私のバックグラウンドは事業サイドだったのですが、今回、作った仕組みが現場の実運用でもきちんと回るようにしたいという視点から、このプロジェクトに携わっています。法務面の詳細については、法務担当の馬場からも補足をしてもらいます。

法務・プライバシー担当　馬場様：
私は新卒入社以来ずっと法務を担当しておりまして、今回のプロジェクトではプライバシーポリシーをメインで担当しております。本日はよろしくお願いします。

—さっそくですが、今回、規約・プライバシーポリシーの表示と同意管理をシステム化することとなった経緯と、当初のゴールイメージがどんなものだったか、教えていただけますか。

渡部：
リクルートには350を超えるサービスがあります。今回のシステムができる前は、そのそれぞれのサービス担当者が法務と相談し、Wordで文書を作成してチェックを受け、事業部がHTML化しFTPで本番環境にアップロードするといった運用でした。これですと、人依存の管理になり、どれが最新バージョンかがわからないといった危険な状況に陥りがちです。

各事業部がバラバラで管理している規約やプライバシーポリシーを中央でもしっかり管理して、いつ・どこで・どのような同意をとったのかがもれなく管理できるように、が漠然とした最初のゴールイメージでした。これだけのサービスとなると、人が管理をするのは限界がありますので、システム化が最初から要件でした。

森：
リクルートという会社は、スクラップアンドビルドで作るのはうまいのだけれども、運用を継続することがあまり得意ではありませんでした。その結果問題が起こるとパッチを当てる、モグラ叩き的な対処になってしまいがちでした。しかし、2019年8月サービスを廃止した『リクナビDMPフォロー』をめぐる問題が起き、これによってお客様にご心配や迷惑をおかけしてしまった反省から、個別最適ではなく業務の全体最適、標準化をすすめています。

リクルートはボトムアップの文化が強く、現場の意向を重視します。そのため、各サービス毎に一番進めやすい開発方法をそれぞれ採用します。なので、ここまでの精緻なシステム化は、これまでのリクルートであれば現場に受け入れられなかったかもしれません。しかし、『リクナビDMPフォロー』での反省をきっかけに現場にも基盤を整備・標準化をすることの重要性が浸透し、ビジネスの「脳幹」にあたるところに投資をしていくことが、結果的にはビジネスを強くしていくとの思いを経営と現場の共有認識として持て、このシステム化プロジェクトが始まりました。

渡部：
このプロジェクトでは、サービスの数だけ存在するプライバシーポリシーやサービス規約について、それらのマスターを管理するための「CMS」と呼ばれる規約管理の仕組みと、誰がいつどの文書に対して同意をしたのかを管理する同意管理の仕組み、この2つを基盤としてシステム化しました。

ユーザーに同意していただくために、各サービスの画面に規約・プラポリを表示するときは、必ずCMSに格納されたマスタを参照することになります。これにより、更新漏れを防ぐことができます。

2019年の『リクナビDMPフォロー』の件では、プライバシーポリシーの更新漏れによる同意取得の不備があったことを報告リリースにも記載していました（下図 事象3）。今回のシステムは、そのような問題の再発防止策の一つでもあります。

GitHubのようなユーザビリティを意識した管理システムを自社開発

—CMSをマスターとして、そこに格納された規約・プライバシーポリシーを常に参照するように変更したことで、更新漏れが発生し得なくなったわけですね。では、そのマスターの改定はどのような手続きで行うのでしょうか。

渡部：
CMSの管理画面から、今使っている規約・プラポリをダウンロードして、修正してアップロード、それを責任者が承認することで、初めて外に公開される仕組みになっています。

誰がいつ更新作業をしたのかは、バイネームで記録されます。もちろん、権限のない者が勝手に変更できないような仕組みに加え、

• 法務担当者
• サービスの最高責任者

双方の承認を得ないと、インターネット上に公開されないようになっています。

—CMSの仕組みは、エンジニアがソースコードを共有管理するGitHubのようなものを想像しますが、同じようなものですか。修正した文書の差分なども分かりやすく表示されるのでしょうか。

渡部：
たとえば、既存のプライバシーポリシーと比較して、どこが削除・新設・追加されたかといったことが色分けして表示されるようになっています。承認ワークフローも、システムの中に組み込まれています。GitHubほどのリアルタイムなコミュニケーションは不要なので、そういった機能は省いています。

—自社開発ということですが、このような利用規約・プライバシーポリシー管理システムというのは、世界を見渡しても無さそうです。

渡部：
要件定義をディスカッションしている過程で、ConfluenceやGitHubなどのユーザビリティは参考にしていたと思いますけれど、規約・プラポリに特化したシステムは、市販のものや公開されているものでは見当たらなかったと思います。

ユーザーが実際に同意した規約画面を「再現」可能

—次に、ユーザー毎の同意取得を管理する仕組みについて、教えていただけますか。

渡部：
今回の仕組みでは、規約文書をマスター管理するCMSと連動した「規約セット」管理のDBを用意し、このDBに、

• 誰が（ユーザーID）
• いつ
• どの「規約セット」を
• どの画面で

同意したのかを記録します。

—「規約セット」について、もう少し詳しく教えてください。

渡部：
はい。ユーザーに同意いただく利用規約やプライバシーポリシーは、多くの場合複数の法律文書の「セット」からなります。どのサービスでも、少なくとも規約とプラポリで最低2つはありますし、サービスによってはもう少し細かい規約に追加で同意いただく必要もでてきます。

こちらの図をご覧ください。

たとえば、あるサービスの入会画面では、ユーザーに「規約ID①〜④」の4つの規約に同意していただくことになります。この4つの規約それぞれに、バージョンごとの内部的なIDを持たせます。

さらに、ユーザーが同意したそのセットに対して「規約セットID」を振っています。加えて、その規約セットが、どのような画面で表示されていたのかも記録しておくために、「画面ID」も用意しています。

—なるほど。このデータ構造ならば、ユーザーとの間で同意した・していないという認識の相違による紛争が発生してしまっても、お客様が当時確認した規約が「画面」イメージごと再現でき、事実を確認できるわけですね。

渡部：
そのとおりです。さらに、同じ画面IDであっても、

• Xルートから遷移して画面に到達したユーザーには、規約セットID　Aを
• Yルートから遷移して画面に到達したユーザーには、規約セットID　Bを

表示わけするなど、同じ画面の中でユーザーのサイト遷移に応じて規約セットを動的に変化させたいという現場ニーズもあり、これにも対応できるようになります。

ブラウザとアプリでの同意取得導線設計の違い

—近年のウェブサービスは、さまざまなデバイス、ブラウザとアプリの違いを意識した設計が求められていると思います。そうした点での苦労はありましたか。

渡部：
アプリに規約を組み込んでしまうと、変更にあたってアプリのアップデートが必要になってしまいます。何度もアプリの更新をユーザーに要求することが、サービス毀損につながりかねません。そこで、アプリからのアクセスであってもブラウザに遷移して同意をしていただくよう、導線を整理しました。

また、細かいところでは、会員登録を1回するとその後再同意がほとんど発生しないサービスや、クライアントさんとユーザーが直接やりとりを行うサービスなどもあり、プライバシーポリシーを変えたとしても、変更をお知らせし、変更内容について同意を取得する導線が作りづらいものもあります。こうしたサービスについては、個別のケアが必要です。

—同意を取得する粒度とタイミングについてはいかがでしょうか。特にアプリ経由でパーソナルデータを取得する際に、位置情報の取得時など、データを利用するその時に同意を得ることが望ましいという考え方もあります。その一方、この粒度を細かくしすぎると、ユーザーとしては何か行動をするたびに同意を求められ、サービス体験が劣化してしまう恐れもあります。こうした問題について、何か議論はありましたでしょうか。

馬場：
取得・利用させていただくデータの「機微度」と「ユーザーから見たときの当該利用の必要性」の二軸でリスクマップ的にプロットし、私のようなプライバシー部門が同意取得の方法を評価しています。その結果、プライバシーポリシーのみで同意を取得するものと、プラポリから切り出してポップアップや導線上で個別に説明した上で同意を取得する場合とを分けています。

よりよい選択肢を提供するために、ユーザーにとってのわかりやすさにこだわる

—同意の対象であるプライバシーポリシーそのものも、箇条書きにこだわった、かなりドラスティックな変更ですよね。

森：
この変更については、法務として葛藤や悩みもあったようです。

馬場：
最近の欧米のプライバシーポリシーは、長文化する傾向にあると思います。法務の方ならおわかりいただけると思うのですが、法的な正確性や完全性を担保しようとすると、「とにかく思いつく限り、なんでも詳細に書いておく」というスタイルのほうが安心です。

でも、長くなればなるほど、一般ユーザーには読めないプラポリになってしまうと思っていまして。そこのバランスを外の声を聞きながら、何度も作っては直して調整しました。

現状、この箇条書きスタイルへの変更については、ご批判の声は無いように思っています。むしろ、端的で読み易いという声を見聞きしています。

—このようなプライバシー保護への取り組みを強化するにあたり、担当役員の立場から、どのようなことを大事にされたのでしょうか。

森：
今回のプロジェクトメンバーには、「ユーザーにとってわかりやすいものにしてほしい」と強く要望しました。

適法であることは大前提、その上で、ユーザーに「よりよい選択肢」をサービスを通じて提供するのがわれわれの使命です。これに必要なデータの取扱い方法をしっかりと説明し、お預かりしたデータがどのように使われているのかについて、真摯にお伝えしたいと思っています。

法律にきちんと対応しています、という説明で終わるのではなく、ユーザーのみなさまに私たちのデータの取扱い方法をしっかりご理解いただいた上でサービスをご利用いただきたい。今後もみなさまからのご意見を反映しながら、ユーザーのみなさまにとってわかりやすいサービス作りを、プライバシーセンター・規約同意管理システム・プライバシーポリシーの表現一つひとつを通じ、実現していけたらと思います。

（聞き手　橋詰）