やっほーこんにちは！『スタディサプリ』でクライアント向け（例：大学等、教育機関向け）システムのPdM（プロダクトマネージャー）をしています、岡戸映実です。実はPdM系の業務×マーケティング系の業務を兼務しており、「二刀流です」と言えるその日までそれぞれ修行中の身でございます。ちなみに前職ではSIerの営業をしていました。
今日は、

• SIerなどの立場でシステムを作っているけれど、もっと主体的にプロダクトをつくりたい

• toBのシステムを担当しているけれどtoCに近い実感をもちたい

• toBシステムの改善を担当しているけれど、単発的な機能開発を考えるだけだともやもやする

そんな感じの方に向けて、

• プロダクトデザイン室にはクライアントソリューショングループ（toB向けプロダクトを担当するグループ。以下クラソリGと略します）があるよ

• クラソリGにおいても、カスタマ調査を通してカスタマに向き合うといいことあったよ～toCに近い実感を得られた！

という話を共有したいです。なお、この記事は　リクルート  プロダクトデザイン室  アドベントカレンダー 2022の11日目になります。

クライアントソリューションGの業務と、岡戸が経験してきたこと

私が所属している『スタディサプリ』のクラソリGにはいくつかのプロダクトが存在しており、それぞれ数人のチームで担当しています。
業務の目的はざっくりと以下の３つに分類され、

①中長期的な構想
②機能開発や保守的改善の必要性検討
③具体的な打ち手の実現度・費用対効果等の検証→開発チームと一緒に打ち手の実行

私自身はこのようなことを主体的に取り組んできました。↓

• ①および②のためのKPI設計とモニタリング方法の構築

• ①および②のための、カスタマーニーズ調査の設計と実施（実際のインタビューも含む）

• ②の中でも「継続的に利用されるシステム」のための機能検討～リリース

それでは、カスタマーニーズ調査にフォーカスして実施概要とメリット・気づきを振り返っていきたいと思います！
（KPI設計とモニタリング方法の構築についても、最後のキメはPdMの意思だよねって気づいた話をいつか書きたいです。またいつか...）

実施概要：担当プロダクト、どうしたいかってどう決めてる？調査開始の経緯と設計・実施

改善点の優先度のつけ方として、売り上げへのインパクトを考えるのがシンプルですよね。ところが、売り上げをゴールに設定することが難しいケースもあると思います。
私の場合は後者だったので「プロダクトがどういう状態であってほしいか」をまず決めました。

具体的には大学などの教育機関（クライアント）が高校生（カスタマー）に向けてメッセージを送りたい時に使うシステムを担当しているのですが、クライアントの継続利用には「高校生が読みたくなるメッセージを送れる状態」が必要だと捉えました。そこで、システムの直接的なユーザーであるクライアントではなく、エンドユーザーであるカスタマーのニーズ調査を始めることになります。

最初の調査設計では、既にメッセージが届いている高校生を対象に以下２点をアンケートする予定でした。

• メッセージを読んだ理由

• メッセージを読まなかった理由

この調査は、定期的にプロダクトの健康状態をチェックしたい場合や、現仕様上の課題を把握したい場合に有効です。一方で、今回のケースではこんな課題感が残ります。

1. 「高校生が読みたくなるメッセージを送れるシステム」って結局何？の回答が散漫になる

2. 上記1.の打ち手が自身の担当するシステムの範疇外になってしまい、結局自分の取り組みに活かせない可能性がある

3. 現行の仕様へのコメントに終始し、高校生の価値観にあう潜在的なニーズ（インサイト）を引き出せない可能性がある

↓
う～～～んと唸ることに。。周囲のアドバイスに助けてもらいながら、思い切って仮説ベースの調査にアップデートすることにしてみました！

アップデート①：「高校生が読みたくなるメッセージ」＝「○○感がある」など、仮説を決める。目指す状態が散漫になってしまうことを回避。

◆工夫ポイント
プロジェクトメンバーや同じようなカスタマーに向き合っているグループなどと一緒に協議できると、カスタマーの解像度が上がっていきました。
且つ、色んな職種のメンバーから「今はこう思っているんだけど、このあたりは調査できていない」といった調査観点や論点を先にインプットしてもらえるので調査の具体性も増してよかったです！

アップデート②：担当システムの仕様変更でどんな「○○感がある」メッセージ配信ができるか。調査前に複数の改善案をイメージし、A/Bテスト的な質問を加える。担当システムが関わる範囲での具体的な質問設計が可能に！

◆工夫ポイント
例えば、高校生の属性に応じて”興味が持てない可能性のあるメッセージ”を定義するのか、”興味を持って読む可能性が高いメッセージ”を定義するのか。仕様の改善方法まで想定してみると、「○○感がある」状態を目指すための打ち手と粒度が複数あることを認識できました。
そこで、いくつかのパターンでメッセージ一覧をつくり、高校生が「一覧の中で読みたいと思うメッセージの数」をテストしました。テスト結果を以って、打ち手の方針が自ずと決まる流れをつくることができました。

アップデート③：データの正しさ×高校生のニーズをひろえているか、の信ぴょう性は調査形式を組みあわせて確認。

◆工夫ポイント
アンケート・チャット・インタビューの３つの方式を組み合わせて仮説検証を繰り返していきました。「○○感がある」メッセージ＝高校生にとって読みたいものか、をチャットで検証した後で打ち手およびニーズについてアンケート＋インタビューの実施です。仮説の確度をチャットでクイックに検証できたからこそ、よりシャープな設問設計でアンケートとインタビューに臨めたのだと思っています。
※高校生にニーズを問うというよりは、インサイトに近い本音コメントをまとめることでニーズとして解釈しました

ちなみにの話。アンケートでの回答とインタビューでの回答に高校生の「建て前と本音」が潜んでいたことも個人的にはとても面白かったです！！
志望校に求めるものとして「学びたいことを学べる・学力的にも自分にあっている・先生の研究分野に興味がある...etc」などたくさんの条件を記載していた子が、実際には「東京のXX駅から〇分以内のところがいい！憧れるキャンパスライフを楽しみたいから！」と言い切ってくれた時…回答環境を念頭において回答を読み取ること、カスタマーの心境の変化をとらえることの大切さを学んだのでした。

まとめ：クライアント向けシステム担当なのに、カスタマーニーズ調査を本気でやった結果

カスタマーニーズ調査をしたメリットと個人的な気づきをまとめます。

メリット

1. 理想形を言語化できるようになり、必然的に“今おこなっておきたいこと” “今明らかにしておきたいこと”が整理される

2. カスタマーニーズを取り入れる＝クライアントにとってもより価値や効果のある（双方にベターな）構造を検討しやすくなる

3. カスタマーニーズを関係部署に共有することで「カスタマーのことも話せる人」として認識してもらえると、その後も相談や情報交換がしやすくなるのでハッピー

気づき

1. SIerのバックグラウンドは、調査後の工程を意識したアウトプット設計や質問粒度の観点で活きた

2. 取得情報の網羅性×回答量と質×スピードの観点で、マーケティング系業務の経験も調査に活きた

3. 調査方法もトライ&エラーが大事。チャット調査ひとつをとっても、時間内に聞き終えられなかったり（質問と全く異なる回答が戻ってきたり）。とくに新しい調査方法を試す場合は、調査方法自体の検証を行えると安心！

以上から、toBプロダクトを担当するクラソリGにいながらも”カスタマーに近いところでプロダクトを作っているんだ！”という実感を持つことができたなと思っています。
もちろんクラソリGの中でクライアントに真摯に向き合っているメンバーもいますし、プロダクトデザイン室の中でカスタマー用のプロダクトを担当している部署もありますので、他の記事やイベントも覗いてみていただければ嬉しいです。

★スタサプのクラソリGの記事が12/15に公開予定らしいです。色々なバックグラウンドを持つメンバーが登場しますので雰囲気感じてみてください

それではまた、どこかでお会いしましょう！
メリクリ！

★noteへのスキ、twitterへのイイね、各種イベントへのご参加大歓迎です（実はプロダクトデザイン室の中途採用PJTのnote事務局メンバーもやっています、ほんとにまたどこかでお会いしましょう）