はじめまして。SaaS領域のIDポイントプロダクトデザイングループの堀場です。

ホットペッパービューティーやじゃらんnet等のリクルートのWebサービスでは、共通のIDである「リクルートID」でログインし、サービスの利用で共通のポイントをためることができます。私が所属するグループでは「リクルートID」やポイント関連の機能改善を担当しています。

今回は2019年から2021年にわたり長期間担当した、dポイント導入という大規模案件の事例をご紹介します。この中で、大規模案件以外の日常のWebディレクション業務でも活かせる気付きがあったので、ぜひ共有できればと思いました！

案件の概要

2021/5/24にリクルートのWebサービスでは「dポイント」がたまり、使えるようになりました。

※『Oisix』はオイシックス・ラ・大地株式会社のサービスです（リクルートIDを導入頂いております）
※『人間ドックのここカラダ』は2022年1月31日（月）23:59をもちまして、サービスを終了いたしました

この案件の実現前は、これらのサービスでたまる・つかえるポイントはPontaポイントのみでした。
普段コンビニでどのポイントカードにポイントをためるか自ら選んでポイントカードを提示するように、ユーザー自身が使いたい・貯めたいポイントを選べることがサービスの利便性の向上につながると考え、Pontaポイントとdポイントの選択制に踏み切りました。

案件規模と私の役割

この案件の実施にあたり、システム改修が必要なサービスは10サービス以上、社内外含め関係者は常時100人以上いる状態。ポイントを実際に使うユーザーはもちろん、じゃらん等のメディアに参画しているクライアント、システム、ビジネス、カスタマーサポートなど様々な視点での検討が必要な案件です。
構想から案件リリースまでの2年間、私はこの案件の「企画PL」として、これらの検討を行う部門の責任者を務めていました。これほど大規模な案件を責任者として遂行していくのは、私もはじめての経験でしたが、その中での学びを2点共有します。

大規模案件での学び

①最初から完璧なものを検討するのではなく、課題を最速で検知＆最速で検討することが大事
②最速で検知するために、コミュニケーションを工夫することが大事

学び①：最初から完璧なものを検討するのではなく、課題を最速で検知＆最速で検討することが大事

リクルートでは、特定のサービスを担当して（●●さんはじゃらんnet担当、▲▲さんはAirレジ担当　等）仕事をすることが多いです。
私は、リクルートIDを扱う部署に所属してこの案件全体を先導する立場ですが、それぞれのサービスには別の担当者がおり、私自身がサービスの詳細を把握している状態ではありませんでした。

こういった構造の場合、仕様の検討をするステップは2段階になります。
基礎検討をSTEP①で行い、その仕様をもってSTEP②でサービス担当者に相談にいき、議論を重ね仕様を確定していくやり方です。時間はかかりますが、一斉に全員で検討をスタートすると議論がまとまらず前に進めないことが多いと思います。

ただ、この進め方をすると、リクルートIDの担当者としては、STEP①で決めたことをSTEP②で変えることに抵抗が出てくると思います。一度決めたことを変えたくないですよね。
でも、前述の通り私はじゃらんnet等のサービスの専門家ではありません。さらに、ユーザーがポイントを実際にためたりつかったりするのはじゃらんnet等のサービス利用の時なので、サービスを運営する方々の意見を聞いて仕様を変化させていかないと、良いサービスは作れないと思いました。なので、「一度決めたことに固執しすぎない。課題が見つかるのは当たり前。私は、検討すべき課題があとで見つかった時に、最速で検知＆最速で検討することに注力する」という進め方をすることに決めました。この進め方に決めたことで、STEP①で決めた内容にこだわらず、柔軟に要望を取り込んで、進めることができたと思います。

学び②：最速で検知するために、コミュニケーションを工夫することが大事

柔軟に要望を取り込んで進めるといえども、早くその要望に気づき、早くシューティングしないとリリース日はどんどん遅れていきます。また、これだけ大きな案件の場合、私1人で全員と会話して要望を察知することはできないので、コミュニケーションの工夫が大事だと思います。私は下記の3点を実施し、早く気づけるように意識していました。

②-1：（関わりの深さで察知力Up）関わる人の考え方や役割を深く知ること
②-2：（関わりの範囲で察知力Up）オープンコミュニケーションにし察知機会を増やすこと
②-3：（定量での察知基準で察知力Up）チケット管理ツール等で3ターン以上会話が続いているなどの一律条件で見張ること

②-1：（関わりの深さで察知力Up）関わる人の考え方や役割を深く知ること
リクルートでは多くの人が働いているので、これだけ影響範囲の大きい案件を担当すると、協業者はほぼ初対面の方です。
初対面の方と会話しながら、「この方は私の意見に違和感を感じているかな？課題と思っている部分はあるかな？」と相手の違和感を察知していくのですが、最初は察知できません。その方の普段の役割や考え方、何を大切する方なのかを私が知らないからです。さらに、他社の方や他のサービスを運営している等業務上の距離が遠い方に対しては、このあたりを把握することを遠慮してしまい、距離が縮まらず察知できない。ここを打ち破るために、私は「業務での論点から話を広げ、背景を聞きに行く方法」で相手を深く知るようにしていました。

上記の会話の例のように、業務での論点の中にも協業者の人となりをしるヒントはたくさんあるので、相手を深く知る手段としておすすめします！

②-2：（関わりの範囲で察知力Up）オープンコミュニケーションにし察知機会を増やすこと
協業者が多い案件の場合、全員と会議で話す機会を設けるのは難しいです。普段使うチャットツールの運営も工夫しました。
工夫のポイントはオープンコミュニケーションにすること。社内で使用しているチャットツールなどは、議論するテーマごとにチャネルを区切って議論をしていきますが、そのテーマの担当だけではなく、案件に関わる全員が全てのチャネルに所属します。そうすることで、自分ではない担当間で出ている議論も後からキャッチアップできますし、課題に発展しそうな違和感に早期に気づくことができました。

②-3：（定量での察知基準で察知力Up）チケット管理ツール等で3ターン以上会話が続いているなどの一律条件で見張ること
Webのチケットツールなどでやりとりをすることも多いと思いますが、通常の1チケットでのやりとりはどれくらいなのか？を考察し、担当間のやりとりが少し多いなという定量基準で課題の発生を検知することも大切です。例えば、普段1ストロークで終わるようなやりとりで、3ストロークが続いているなどの場合、裏側には双方の認識齟齬や課題への考え方の違いがある場合が多いと感じます。

結果

私の経験上最も協業者が多く複雑な案件ではありましたが、予定通りのリリース日に、10サービス以上のサービスで同時に企画のスタートができました。また、ユーザーの方々にご迷惑をおかけするような障害を発生させることもなく、リリースを終えました。今は、リクルートのWebサービスでdポイントを選び、dポイントを貯めたり使ったりしてくださるユーザーも順調に増えている状況です。

最後に

今回は、私が初めて経験した大規模案件を推進する際の工夫をお伝えしました。実際にやってみてわかったことは、これらの工夫は大きな案件のみではなく、小さな案件を担当する時や普段の業務でも活かすことができるということです。普段から周りの関係者の人となりを知ることで、業務を円滑に進めることができると感じました。また、仕様を工夫する以外のこういった目には見えにくい工夫も、案件を推進する上では大事であることが改めて自分の学びになりました。

この話がリクルートのプロダクトデザインの業務に興味を持っていただくきっかけになれば嬉しいです。最後までお読みいただきありがとうございました！