サントリーウエルネスサービス事業部の相川です。
自社アプリComadoへのレコメンド機能の導入を目的とした、パーソナライズプロジェクトの推進を担当しました。
プロジェクトの立ち上げ〜推進していく上で、個人的に気をつけたことや肝になったと思うことについて記したいと思います。
1. はじめに
今回の記事の位置付け
タイトルにもありますが、入社3年目ではじめてPLというプロジェクト推進を担当する立場になり、諸々試行錯誤しながら頑張ってみたというお話になります。
そのため、推進ガチ勢の皆様からすると当然すぎることや的外れなことも散見されるかと思います。ご容赦ください。 逆に似たような状況の方にとっては何か参考となる情報があれば幸いです。
宣伝
私はサントリーホールディングスのデジタルテクノロジーコースに新卒で入社し、今年で3年目になります。 基本的なデジタル研修を経た後にサービス事業部に配属され、Comadoの集客施策担当や簡単なデータ分析等の業務経験を積んできました。
ザ・エンジニア以外にもこういうサービスに関わる仕事があるんだ〜という仕事紹介にもなるかなと思うので、本記事でご興味を持ってくださった方は是非ご検討ください。
Comadoにあるお仕事については他記事でも触れられているので、気になる方はそちらも見てみてください。
2. プロジェクト基本情報
①背景〜目的
Comadoには健康行動を促進するための健康習慣・フィットネス・健康記事といった、ユーザーの心身の健康をサポートする多種多様なコンテンツがあります。しかし検索機能やレコメンド機能が乏しいことにより、自分に合ったコンテンツに出会いづらいという課題がありました。これを解消するため、レコメンド機能の導入を目指したプロジェクトが始まりました。
②初期方針
当時のComadoのレコメンドと目指す姿について
当時Comadoのレコメンドは手動の運用で行われており、週に一度更新する7個のコンテンツを全員に提示する形でした。
※TOPおすすめ枠に横カルーセルで表示 (下図赤枠)。
もちろんこちらの運用でも、編集部の皆さんがユーザーに見られそうなコンテンツを毎週考えて選定してくださっており、改善が重ねられていました。
しかし手動では、日次やリアルタイムなどの更新頻度の増加や、ユーザーセグメントごとの振り分けといった複雑な提案には限界があります。そのため、今後踏み込んだレコメンドができるようになるためには機能化する必要がありました。 また、健康につながることは一人一人違うはずであるため、全員に画一的なコンテンツ提案をするのではなく、各ユーザーに適した提案を行うパーソナライズドレコメンドを理想形としました。
QCDの優先順位は圧倒的にD
時間を気にせずにやるのであれば、「どういうレコメンドをユーザーに提供したいか？そのために何が必要か？」から考え、それらを綺麗に揃えて進めることになるのかもしれません。しかし、このプロジェクトは既にリリースされているアプリの改善が目的であり、ユーザーに価値を届けて初めて意味を成します。そのため、QCDのうちDを最優先し、多少粗くても少しでも効果が見込めそうなことからやっていく方針をとりました。
ロジックをメインに扱う
レコメンドを構成する要素としては
- ロジック
- 更新頻度
- ユーザーへの見せ方
がありますが、どの要素に関しても「手動選定・週次・TOPおすすめ枠」という1パターン以外試されたことがなかったため、本プロジェクトでは最も改善幅があるであろうロジックをメインに扱いました。
Comadoではパーソナライズドレコメンドを目的としたデータ取得設計は行われていなかったので、かなり限られたデータをもとにしたロジックしか構築できないことがわかっていました。しかし、その中でも既に手動選定よりも評価指標が改善するロジックがあるのであれば一旦それで機能化できればベストです。一方改善しない場合でも、現在地を知ることで課題の特定と改善方針の拠り所にできるため、まずはいくつかABテストを行うことにしました。
立ち上げ当初仮説として上がっていたのは
- ユーザーのお悩みと合致するコンテンツを一定のルールで提示する
- ユーザーの行動ログをもとに、機械学習モデルを用いてパーソナライズドレコメンドを行う
の2つです。 これらのABテスト(vs既存の手動選定ロジック)実施を一旦の目標とし、プロジェクトを立ち上げました。
③関係者と自分の業務
プロジェクトメンバーは約10名で、モデル構築・UIUX・KARTE配信チームから構成されていました。その他必要に応じてComadoコンテンツチーム等と会話します。
私はPLとしてプロジェクトの立ち上げ〜推進を担当しました。プロジェクトを進めるために必要なこと全てが担当業務です。
④今回のプロジェクト推進の特徴的な点
プロジェクト立ち上げ全般に当てはまりそうなこともありますが、今回特徴的だと感じた点は以下です。
スピード重視
前述の通り、最速でユーザーに価値を届けることに重きを置いていました。ABテストを行うためにも多くの事前準備が必要な中、
- 絶対やらなくてはいけないこと
- やれたらいいけどやらなくてもいいこと
- やらなくていいこと
の見極めをした上で、絶対やらなくてはいけないことに集中して最善を尽くすことが必要でした。
何をやればいいか探索的に考え続ける必要がある
社内ではレコメンドプロジェクトの前例がほとんどなかったため、ABテスト実施やレコメンド機能を届けるまでに何が必要か、どういう順番で進めるべきかから考える必要がありました。これはプロジェクトを通してずっとです。
複数の専門領域があり、整合性を取らないと詰む
データ取得・機械学習モデル構築・配信・UIUX検討等、複数の専門領域が関わっています。そのため落球や齟齬が生じやすい境界が多数存在しており、全体で進行の整合性を取ることが特に重要でした。
3. プロジェクト立ち上げ〜推進する上で意識した点
上記のプロジェクト性質をいい感じにおさえつつ成功に導くために、以下のことを意識して行いました。
①必要な知識のインプット
【立ち上げ・推進の考え方】経験者にめちゃくちゃ相談する
さらっと冒頭でプロジェクト初期方針を書いていますが、立ち上げ時は当然言語化ができていない状態でした。なんとなくの背景目的は感覚的に理解していたので、一旦自分の視界で言語化できるところまでした上で、社内の立ち上げに強そうな方々に壁打ちに行きました。フラットな視点で質問と深堀をしてもらうことを何回か繰り返すことで、必要な観点の補完と解像度を徐々に上げていくことができたと思います。
またはじめてのプロジェクト推進であり、そもそも何を求められる役割なのかもわかっていない状態からのスタートだったため、推進力が強そうな方達に質問しに行きました。 他記事にも登場していますが、直近社内で大きなプロジェクトとしてあったSWC (サントリーウエルネスクラブ) 立ち上げに関わった方々にもお世話になり、立ち上げ時に見えている論点洗い出しと整理の仕方はもちろん、プロジェクトを通して課題や論点を可視化し潰し続ける流れと重要性がよくわかりました。
どちらにも言えることですが、なるべく思考特性や経験したプロジェクト特性が違いそうな人たちを何人か選ぶことを意識しました。色々な角度でのアドバイスをいただくことで、自分に合ったスタンスや全員に共通する核となる考え方が見分けやすくなると思います。みなさんお忙しいところ丁寧に対応してくださりありがとうございました。
【最低限の専門的知識(機械学習領域)】一旦本読む
私自身の背景として、元々機械学習領域に明るかったわけではないため、知識のインプットも多く必要でした。元々データサイエンス系に興味があったのもあり、社内の方に薦められた以下の本の必要な部分を読んだりしていました。
もちろんインプットだけですぐ業務ができるようになるわけではありませんが、専門領域の方と直接会話するために必要な大枠の考え方や定性的な理解は進んだかなと思います。
②プロジェクトの中で自分の言葉で説明できないところを作らない
プロジェクトを進めていく中で、コーディング等まで理解することは難しいものの、少なくとも定性的な理解は最下流まで行うことを意識しました。
目的といつまでに何をする必要があるという最低限の認識合わせをした上で、私自身の解像度が低いところが無くなるまで、
- ここはどう実装する予定なのか
- 複数の選択肢がある場合はなぜその選択肢を選ぶに至っているのか
- こういったパターンはどう対処するのか
等を納得いくまで確認させていただきました。
これにより、考慮漏れや目的と整合性の取れない部分が発生することを未然に防げたのではないかと思います。
③少人数のキーパーソンと同期する
ABテスト実施を目指す上では、主に「モデル構築チーム」、「KARTE配信チーム」と完全に同期しておく必要がありました。各チーム代表1名ずつと密なコミュニケーションをとり、私を含めた3人の認識が常に揃っているようにしました。
探索的なプロセスにおいては、このように最少人数で同期を取るのがいいのではと思っています。理由としては以下が挙げられます。
スピードが上がる
特にスピードを重視するプロジェクトである場合は、認識を揃えるべき人数は絞った方が効率的です。もちろん結果的にメンバー全員の方向性が揃っていることは重要ですが、常に全員と同期を取ろうとするのは負荷が高い上、人数が増えれば増えるほど認識のずれが発生しやすくなり、スピードが鈍化します。
安心感が持てる
「めちゃくちゃカオスな状況だけど、少なくともこの2人と認識があっているから大丈夫」というシンプルな自信が持てたので、メンタル的にも余裕ができました。少人数でコミュニケーションを重ねていると、一定期間経った後からまだ会話してないものについてもあまり認識がずれなくなってくる感覚があり、安心感に到達しやすい気がします。
プロジェクトメンバー全員の方向性を揃えやすくなる
一見矛盾するようですが、最少人数で小回りが効くコミュニケーションをとっておくと、細かな考慮もれや一人では気づかない専門的な視点を補完しやすく、多角的に見ても納得感のある方針にブラッシュアップされやすいと思います。
そういったものを全体へ共有した方が結果的にメンバーの高い納得感やモチベーションにもつながるのではないでしょうか。
④ツールに切り出せる情報は外に出して思考のリソースを空ける
できるだけ「探索的に考え続ける」ことに思考のリソースを割くべく、すでに認知できている課題やタスクについては全てツールに可視化し意識しなくていいようにしました。
本プロジェクトではJiraを使用しましたが、
- タスク一覧
- 課題一覧
はもちろん、
- 領域を跨いでいるタスク・課題の依存関係
を最初の段階で全て紐付けておいたのが良かったと思います。例えば以下の画像のように、小さいタスク含め全てチケットを切り、依存関係を可視化しておきました。
※以下画像：各チケットの実施期間を帯で表示し、依存関係を曲線で表している
これにより既知のことには注意を払わなくて良くなり、まだ見えていない部分に集中できるようになったと思います。
また、後続のタスクへの影響が全て可視化されているので、何か新しい課題が見つかりスケジュール調整が必要になった際にも、混乱することなく各チームと認識が合わせられました。
他にはJiraとSlackを連携しておくことで、
- 今週動く予定のタスクと担当者のお知らせ
- 3日前に会議持ち込み準備のリマインド
を行い、考えなければならないことを減らしました。
これらによって私個人の思考のリソースが空いたのはもちろん、全体としての会議体は週次1時間という最小限に抑えられ、個々人が仕事に集中できる状況を作れたのではないかと思います。
4. 成果
これらを実践したことにより、今できるロジックでABテスト(vs 既存手動選定)を行うという一旦の目標は、立ち上げから半年経たずに無事達成できました。
結果、
- ユーザーの行動ログをもとに、機械学習モデルを用いてパーソナライズドレコメンドを行う
こちらのロジックが手動選定に対し、クリックユーザー率が120%超で改善されるという結果になりました。 冒頭で述べたように限られた行動ログしかない状態でしたが、意外にも今できる機械学習モデルでも手動選定に勝つということがわかり、スピード重視でテストを実施してよかったなと思います。
この結果を受け、秋から実際にモデルをベースとしたレコメンドを運用に乗せる予定です。 手動選定には勝利したもののあくまで初期モデルであり、
- より良い体験を提供するモデル構築のためのデータ取得
- ユーザー体験向上のための除外条件の改善
- 運用していく上での各種調整
- 更新頻度・見せ方といったロジック以外の要素の検討
などまだまだやるべきことはありますが、ひとまず「ユーザーに最速で価値を届ける」第一歩が踏み出せて安堵しています。
限られたデータの中で最善のモデルを提案＆構築してくださったモデル構築チームのみなさん、配信基盤が整っていない中最短でテストできるように動いてくださったKARTE配信チームのみなさんはもちろん、チーム全員で同じ方向を向いて進められた結果だと思います。ありがとうございました！
5. 個人的な今後の目標
プロジェクト規模が大きくなった場合について
特に
②プロジェクトの中で自分の言葉で説明できないところを作らない
で言えることですが、今回よりさらにプロジェクト規模が大きいものを担当したときに、リアルタイムで全て把握するのは難しい場面が出てくると思います。
そのような場面でも円滑にプロジェクトが推進できるような自分にフィットする方法を見つけたいです。社内の大型プロジェクトだったSWCでは、共通ルールのもと、意思決定プロセスを全て言語化したドキュメントを作成する方式をとっていたようです。まずはその方法に適応してみたいと思います。
信頼関係の構築について
勘の良い方はお気づきかと思いますが、推進上意識したことに挙げたことは積極的にコミュニケーションを取る必要があるものが多く、周りの人との信頼関係が前提になっています。
幸いにも本プロジェクトはメンバーや周囲の人にめちゃくちゃ恵まれており、心理的安全性が担保されているのはもちろん、私が専門的にわからないことを無邪気に聞いても懇切丁寧にわかりやすく教えてくださる方ばかりでした。
では殺伐とした環境に身を置くことになったら再現性がないじゃないか！ということになりますので、今後はどんな環境からでも能動的に信頼関係を構築できるような人になることを1つの目標としたいなと思いました。
本プロジェクトでお世話になったメンバーからいただいた
「上流の仕事になっても具体まで理解しようとする姿勢が大事。意外とそれによって信頼関係は構築されていくもの。」
との言葉を胸に、自分なりに方法を模索していきたいと思います。
6. 終わりに
元々私はプロジェクト推進ポジションをやるつもりもやれるつもりも全くなかったのですが、3年目でこのような機会を与えてくださった環境と、無事一定形になるところまで推進できるように支えてくださった関係者全員に感謝しつつ終えたいと思います。
本記事では推進にフォーカスした内容でお届けしましたが、そのうち技術面などもう少し具体に寄った内容をどなたかが書いてくれるんじゃないかな？と思っていますので乞うご期待です。
ここまで読んでくださった方がいれば、ありがとうございました〜