リフカムの出口 (@dex1t) です。CXOとしてリフカムに入社して8ヶ月が立ちました。2019年やったことを、プロダクトマネジメントの観点で振り返ってみようと思います🙋‍♂️

Refcome Teamsのリリース

リフカムにとって2019年いちばん大きな変化は、Refcome Teamsを世に出したことでした。

リフカムはこれまで、Refcomeというリファラル採用活性化のためのSaaSを提供してきました。新しく立ち上げたRefcome Teamsも同様の価値を提供する製品なのですが、こちらは"スタートアップに特化"をうたっています。

なぜあえてスタートアップ特化型の製品を、既存サービスとは分けて新規立ち上げしたのか。その意思決定のなかで、式年遷宮的なサービスリニューアルという考え方を試してみました。

※ 以降、この2つを既存RefcomeとRefcome Teamsと書き分けます ✍🏻

リノベーション的サービスリニューアル

🤦‍♂️「ゼロから作り直した方がはやいんじゃないか…」
デザイナー・エンジニアをはじめサービスづくりに関わる人は誰しも抱いたことがあるであろうこの気持ち。特に意思決定者が変わったタイミングでは、実際にリニューアルという形で作り直しが行われることが多いかと思います。僕自身も例外ではなく、入社したタイミングで同じことを思いました。

事業の成長のために、サービスリニューアルは必要なことです。ただ、次のような話はよくある話。

1. あれもこれもやりたくなり収拾がつかなくなる (体験の刷新、ビジネスモデルの変更、技術的チャレンジ…）
2. 既存の仕様や技術的負債との帳尻合わせをした結果、リニューアルが中途半端に終わる
3. 既存ユーザーの混乱を招く。それを緩和するための調整をした結果、長期戦になる

1つ目はスコープの決め方で対処できる余地はありますが、2や3はなかなか対処が難しいところです。

住居🏠に例えて考えると、一般的に行われるサービスのリニューアルは、既存の建物に付加価値をつけるリノベーションといえます。しかも住人 (ユーザー) が、普段どおり暮らし続けている状態で、リノベーション工事をするので、2や3のような問題が起こるのは、ある意味当然かもしれません。

なぜ作り直したくなったのかを考える

ここでもう一度、既存Refcomeをなぜ「作り直したい！」と思ったのか考え直してみました。

1. ユーザー層の幅広さ
BtoCサービスと比較すると、BtoBサービスは、サービス上の登場人物が多い傾向にあります。既存Refcomeも例外ではなく、人事採用担当からアルバイトの高校生まで、幅広いユーザーがRefcomeに触れます。また既存Refcomeは、IT系ベンチャーに導入いただいたところからスタートし、最近では大手飲食チェーン、介護・医療系や製造業まで幅広い業界に導入が広がりました。

事業としては喜ばしい一方、サービスとしては1つで多くのユーザー層をまかなう難しさもあります。一口に"リファラル採用"といっても、ITスタートアップのエンジニア採用と、飲食チェーンでのアルバイト採用は、全く事情が異なります。かける採用予算も違うので、RefcomeのようなSaaSにかけられるコストも変わってきます。

そしてユーザー層の幅広さは、サービス開発のなかでのコミュニケーションも難しくします。

・認識のブレ (誰にどんな体験を提供すべきなのか）
・大口顧客に対するバイアス (ブレた状態での大口顧客からの要望に、無意識にバイアスがかかる)

これらは特に根深く、開発メンバーだけでなく、マーケティング・営業・CSすべてにおいて難しさを生んでいました。今回の"作り直し"は、この問題の解決を主に考えます。

2. 技術・デザイン的な負債
既存Refcomeは開発開始から丸4年経過しているサービスです。もちろん技術的な負債はあり、SaaSのスタンダードから外れてる部分もあります。またデザイナーが長く不在だったこともあり、デザイン面でも継ぎ接ぎだらけな状態です。

これらはよくある話なので、ユーザー層広い問題に比べれば、粛々と向き合っていくだけとも言えます。ただその向き合う時間も、スタートアップとしては確保しづらい。なにより、デザイナー・エンジニアの採用面では難しさがあります。新規で採用した方がすぐに活躍できる土壌とは言えません。

式年遷宮という考え方

ここで前職のSREチームが、式年遷宮という考え方でサーバーのリプレイス作業をしていたことをふと思い出しました。元ネタは伊勢神宮の式年遷宮です。

伊勢神宮などで行われる、一定期間 (式年) ごとに、社殿を別の場所で作り直し機能を移す (遷宮) 行事が式年遷宮です。伊勢神宮では新旧の社殿用の土地が確保してあって、旧殿を使いながら、新殿の建築作業が進められるらしい。これにより社殿を常に新しい状態で使い続けることができ、作り直しを通して技術継承を行うというもの。

式年遷宮的サービスリニューアル

さすがにサービスを、"式年"することは難しいですが、"遷宮"には学ぶところがありそうです。思考実験してみました。

🙆‍♂️メリット
1. 別の場所に新居をつくることで、現居のユーザーには負担がかからない
2. 体験的にも技術的にも、現状に囚われることなくリニューアルができる
3. 人材の確保がしやすい。新規立ち上げはフリーランス・副業メンバーを巻き込みやすい
4. モダンな技術を新居作りから学ぶことで、会社全体に2019年のスタンダードを取り入れられる

特に3, 4は採用や組織観点ですが、リノベーション的サービスリニューアルと比較すると、隠れたメリットです。
(3に関しては自分の周りにたまたま新規開発に長けた人が多いというのもあります)

🙅‍♂️デメリット
1. 新居が完成したら、ユーザーに移り住んでもらう必要がある
2. 現居と新居の2つを運営する必要がある

1は、BtoCサービスのようなユーザー数が大きい場合は、通常は許容できないデメリットです。ただしRefcomeのようなハイタッチなBtoB SaaSは、ユーザー規模自体は小さい。移行するメリットを作ることや、CSメンバーが介入することを前提に許容できそうだと判断しました。

コンテキストでサービスを二分する

先にお話したとおり、既存Refcomeは「ユーザー層が幅広い」という課題を抱えていました。これは言い換えると、「現Refcomeを使うコンテキストが、いちサービスでまかなえないほどに幅広い」といえます。

リファラル採用は、転職顕在層向けのリファラル採用と、転職潜在層向けのリファラル採用の大きく2つに分けられます。

前者は飲食チェーンで、「バイトを探してる大学の友達を自分の店に誘う」ようなケース。
後者はIT企業で、「前職で活躍していたエンジニアを、口説き続けて数年越しで入社してもらう」ようなケース。

同じリファラル採用といっても、時間軸もプロセスも大きく異なります。

結論としては、顕在層向けを既存Refcome、潜在層向けをRefcome Teams (新居) という棲み分けにし、両サービスを今後も継続して開発するという判断をしました✅

こうすることで、それぞれコンテキストにあった体験を届けられますし、ビジネス面でもそれぞれにあった料金体系を模索できます。

伊勢神宮の式年遷宮は、技術継承が目的ですので、Refcomeの場合はサービス分割を目的にした式年遷宮といえます。

最初の住人を誰にするか

新居であるRefcome Teamsは、転職潜在層向けのリファラル採用というコンテキストを担うと決めました。先程は"IT企業"と大雑把に例を出しましたが、ここにもグラデーションがあります。

新居をまずは誰向けに作るのか。Refcome Teamsの場合は、ITスタートアップから始めることにしました。

この狙いを書き出すと長くなりそうなので割愛しますが、箇条書きするとこんな感じでした。

・我々自身もスタートアップでありドッグフーディングしやすい
・営業時の導入意思決定が早い
・解約の判断も早いので、よりシビアに初期検証を回せる
・エンジニア採用は競争が激しく、リファラル採用の難易度が高い

ということで、まずはスタートアップ特化と銘打ってRefcome Teamsをリリースしました。ずっとスタートアップ限定というわけではなく、徐々にカバーする範囲を広げていく計画です。

また既存Refcomeは、今後はアルバイト採用をはじめ、より顕在層向けのリファラル採用に特化させていくことを計画しています。

まとめ

式年遷宮から着想を得て、サービス分割という形のリニューアルを行うに至るまでの意思決定の流れをまとめてみました。

あくまで副産物ですが、副業・フリーランスを巻き込みやすいメリットはかなり大きかったなと感じています。実際のところ、Refcome Teams開発メンバーの半数は、副業・フリーランスです。

働き方が変わった時代だからこそ、彼らをいかに巻き込めるかが、スタートアップにおけるサービス開発のチームづくりとして大事だなと感じています。

もちろん、リフカムは正社員含めて雇用形態・働き方を問わず、エンジニア・デザイナーを積極募集中です🙌

1300年前から続く伊勢神宮の式年遷宮も、技術者の確保という意味合いが強いようです。先人から学ぶ点は多い。

それでは良いお年を！🎍