すべてユーザーのために！ 全社員が「User Happy」を胸にサービスに関わる
――企業の成長は、魅力的なプロダクトあってのことだと思います。迅速かつ的確にプロダクト開発を続けてこられた秘訣は何でしょうか？
野口：先ほども少し触れましたが、プロダクト開発で最も重視しているのが「User Happy」という行動規範です。例えば、今年は開催を自粛しましたが、通常では年に1回ユーザーさんをご招待して大規模なオフ会を開催し、ほぼ全社員が参加しています。もちろんユーザーさんへの感謝を伝える場でもありますが、「最近のいいお店は？」「どんなものを食べた？」とユーザーさんと同じ目線でおいしいものについて語りながらサービスにフィードバックをいただく大切な機会でもあるんです。
また、定量・定性的な分析にもかなり力を入れています。例えば、インタビューを定期的に行っており、Rettyのヘビーユーザーはもちろん、他社は使っているけどRettyは使わない人など、さまざまな方に話を聞くようにしています。その様子を録画やドキュメントにまとめ、カスタマーサクセスチームに来る問い合わせの内容なども含めて、あらゆるユーザーの反応をSlackのユーザーボイスチャンネルに掲載・共有しています。
すべてに対応できるわけではないのですが、ファクトとしてユーザーの困りごとや喜びの声をオープンに共有できる環境を作り、関係者全員が見られるようになっています。ほかにもプロダクトマネージャーが仮説を立てて分析チーム5～6名がプロジェクト的に分析することもあれば、定量的な定点分析も四半期ごとに行っています。
常松：私も入社直後は、よく数字を見ているのに驚きました。かといって、数字偏重な組織ではなく、どんな施策についても「User Happy的にどうなの？」と必ずツッコミが入るくらい、エンジニアにも企画職にもユーザー視点が備わっています。
そもそも採用の時点で、カルチャーマッチは相当厳しく見ていると思います。身近なサービスで役に立つものを作るのが好きで、食べること、人とコミュニケーションすることが好きといったが多く集まっていますね。それゆえか、「あのサイトではこうしてるから、うちもしよう」とか、競合と比較する話をほとんど聞きません。あくまでユーザーのことを思って「ユーザーのためにこうする」といった言い方しかしない。「User Happy」をしっかり持てるかどうか、それがあらゆるスキルの前に重視されていると感じます。
野口：「User Happy」を最優先項目とする社員の行動指針を「Retty Way」と名付け、2～3年ごとにアップデートを行っています。数人の運営委員会を組成して代表の武田を中心に方針や課題を話し合った上で、全社合宿を行い、各項目について浸透させるための施策も考えます。評価も「Retty Way」を基準に行うので、常に自分の行動と照らし合わせて考える仕組みになっているんです。
――プロダクトに関しては、具体的にどのような意思決定プロセスを経ているのですか。ユーザーに近いサービスだけに、主観的な意見が多く出てきそうですが。
野口：まずは主観を主観のままにせず、可視化、言語化することが大切ではないでしょうか。例えば、今まさに「ロイヤルユーザーを定義しよう」という施策を行っているのですが、それぞれが持っているイメージを互いに答え合わせする感じですね。企画やアウトプットは人によって異なることも多いのですが、少なくとも「何のために」といった目線や温度感は合ってくるように思います。
常松：そうしていろいろと出てきたアイデアや意見、企画は1か所に集めて議論した上で、最終的には野口が意思決定する体制をとり、その時に「なぜ今やるのか」「こちらを優先するのか」などを説明するプロセスを組み込んでいます。
野口：さらに大きな施策を行う際には「全展開ミーティング」を行います。その際には離脱率など数字の根拠も示しつつ、デザインを見て「これは間が空きすぎてない？」みたいな“ふわっとした感覚”も共有しますね。
迅速なプロダクト開発を実現するため、開発プロセスと組織構造を改革
――Rettyでは2019年から2020年にかけて、開発プロセスや組織構造を大きく変えたと伺います。その経緯についてお聞かせいただけますか。
野口：もともと1チームだった組織が大きくなるにつれて部門ごとに分かれて仕事をするようになり、3年ほど前、100人を超えた頃くらいから、部門の目標に終始するようになり、例えばCSが困っていても開発は黙々と自分の仕事に集中……なんてことが頻繁に生じていました。
スタートアップにありがちかと思うのですが、当社も別会社で経験を積んだスタープレーヤーが何人かいて、若手も急成長して、みんなのモチベーションを高めるために、権限や責任を持たせることを積極的に行ってきました。それでマネージャーの権限が強くなって、おのおの自由にやりすぎた結果、かえって自由がなくなってしまったように感じます。
そこで、縦割り組織を廃して、部門横断で解決に向き合えるような組織と目標、プロセスに切り替えようと、開発プロセスと組織の改革に着手したわけです。その推進役となったのが2019年6月に入社したばかりの常松でした。
常松：私が入社した時点では、ネット予約チーム、SEOチーム、toB向けシステムチームと目的別に分かれ、それぞれに企画、デザイナー、エンジニアが所属していました。平時ならとても効率的な組織だと思います。しかしチームを超える案件に取り組もうとすると、途端に部門の壁のせいで動きが遅くなるといった現象が生じていたんです。
例えば、管理画面を改修しようとすると、画面デザイン、アプリ、外部との連携……と部門をまたいで複数の要素が絡み、統制がとりにくくなります。プロダクト全体に影響する部分がなかなか改善できない状態が続き、経営層もこのままでは組織の成長を阻害してしまうといった危機感を持っていました。
それで野口とVP of Engineeringの小迫と私とで話し合いを重ね、骨子としてまとまったところで、社長の武田が2019年9月に全体向けて「LeSS（Large Scale Scrum）を導入し、組織を変える」と宣言を行いました。実質そこから動き始めた感じですね。
まずは混乱を避けるため、一気に変えるのではなく、従来の組織体制を残したまま、最初は3チーム計10人を1か所に集めて「案件を皆さんに順当に振り分けていきます。もしダメだったらもとに戻します」と宣言しました。結果、2週間後には全員がいけそうだというので、そのまま1つのチームとして定着させました。それで少しずつ広げていった感じです。
野口：その後もチームの統合を続け最終的には大きく2つのチームとし、それぞれにシンプルな最終目標を1つずつ設定しました。それまではKPIを達成するために必要な施策という考え方のもと、部門ごとに四半期の目標を10項目以上挙げていました。その結果、目の前の「やらなくてはならないこと」に手いっぱいになって、全体を見渡して「何が必要か」に意識が回らなかったんですね。大きな目標に集約させたことで“本当にやるべき仕事”に集中できるのではないかと考えました。
――実際に新体制が動き出してみて、いかがでしたか？
常松：まずは異なるチームだったメンバーが一緒になって、以前のチーム間で文書化や共有化が足りておらず「そもそもさまざまな齟齬があった」ことが明らかになりました。Webとアプリとで仕様が違う部分があるなど、別々に作業していて見えていなかったことが、人を混ぜたことで見えてきたんです。それらを互いに共有しあい、影響範囲などが全体のノウハウとして蓄積されていきました。落ち着くまでに半年くらいかかりましたね。
野口：以前は互いに要請はするけど自分の仕事を優先し、相手が完了させるまで何もせずに待つ、などの行き違いや非効率がよく起きていたのですが、改革後はそれがほとんどなくなりました。「今はこれが必要だから、みんなで取り組む」といった、ごく当たり前のことながら、あるべき状態に戻せたというところでしょうか。その実感が得られるようになったのは2020年に入ってからです。
