私たちは創業当初から「顧客志向」を徹底して重視し、2017年からは開発組織として「顧客をカスタマーサクセスに導く、圧倒的に使いやすいSaaSを創り提供する」というミッションを掲げてきました。その結果、多くのお客様にプロダクトが支持され、国内SaaS市場でARR No.1を達成できました。

ラクスは、特定の業務領域に特化して顧客志向でプロダクトを徹底的に磨きこみ、圧倒的に優れた顧客課題解決を目指す「ベスト・オブ・ブリード型製品開発戦略（以下ベスト・オブ・ブリード戦略）」でプロダクト開発を行い、お客様の声を最優先にする方針をとってきました。

「ベスト・オブ・ブリード」は元々IT製品調達の用語で、業務領域ごとに最適な製品を組み合わせてシステムを構築することを指します。ベスト・オブ・ブリード戦略はこの概念を用いて再定義したものです。

ラクスがなぜベスト・オブ・ブリード戦略を選び、どのようにお客様の声を製品へ反映しているのか。開発本部長の公手に、その背景や経緯、成功要因を聞きました。

原点は「お客様に喜ばれるものを作りたい」思い
重視したのは「お客様のリアルな姿」
マルチプロダクトを高成長させる戦略
絞り込んだターゲットから圧倒的支持を獲得
戦略成功には組織の「熱伝導性」を高めることが重要
「誰かの役に立っている」実感こそ開発の醍醐味
おわりに

原点は「お客様に喜ばれるものを作りたい」思い

ラクスがベスト・オブ・ブリード戦略をとるようになった背景を教えてください。

正直、創業当初から「これがベスト・オブ・ブリード戦略だ」と意識していたわけではないですね。「メールディーラー」を開発していたころは2000年代前半です。まだベスト・オブ・ブリードという言葉はなかったんじゃないですかね。「お客様に喜ばれるものを作りたい」という気持ちは強かったですね。

ただ、そういう気持ちが強いのとお客様に価値あるものが提供できるというのはまた別の話です。ただ、「お客様に喜ばれるものを作りたい」という想いはめちゃくちゃ重要だと思います。最初の頃はお客様の話は聞いていましたが、解像度が高くありませんでした。なので、結構想像でこういうものが役立つだろうという感じで開発していたと思います。

私が「メールディーラー」の開発に参画したときは「メールディーラー」は十数社に導入されているぐらいのかなり小さなサービスでした。その後、私の後に参画された当時の役員のHIさんがPMF（Product Market Fit）を目指し奮闘していました。ECショップのメール問い合わせという領域に焦点を合わせることで、すごい勢いで売れるようになりました。

当初はお客様に役立つものを想像で開発していたとのことですが、売れ始めてから課題は出てきませんでしたか？

まだまだ製品完成度も低かったことから、お客様からの要望が山のように来ました。自分たちが想像していなかったような要望がきたり、自分たちの開発したものがお客様のイメージやHIさんのイメージと微妙にズレがあることもありました。

そこでHIさんともっとお客様の声をリアルに直接聞いて、現場を見て顧客解像度を上げていこう、ということになったわけです。開発だけでなく、営業もCSもお客様から聞いた声をどんどんデータベースに蓄積していきました。「こんな機能があると助かる」「ここが不便だから直してほしい」と具体的な要望がどんどん出てきましたね。

お客様の声を徹底的に聞き、マーケットインでお客様の声を実現していくうちに、自然と機能が豊富になり、お客様のかゆいところに手が届くシステムになり、より多くのお客様からの支持を得られるようになりました。

お客様の声をリアルに聞いたことで、ベスト・オブ・ブリード戦略に至る成功体験が得られたんですね。

はい、この成功体験がその後のラクスのプロダクト開発の基本姿勢となり、結果としてベスト・オブ・ブリード戦略をとっていたということになるかと思っています。あ、我々ってベスト・オブ・ブリード戦略なんだって気が付いたのは2011年とか2012年ぐらいだったと思いますね（笑）。「ベスト・オブ・ブリード」という言葉は2004年ぐらいからあるみたいですけど。

お客様の声を徹底的に聞く方針について、具体的にはどんなことをしていたのでしょうか？

仕様一つとっても、開発・営業・CS・マーケティングが膝を突き合わせながら議論していました。先ほども述べましたが、営業やCSが商談やサポートで拾った要望、つまり「お客様からこういう声が出てる」「こんなところに不満を感じている」という情報を集めて、当社のWebデータベースでもある「楽楽販売」に情報集約しています。

それを開発と営業、CS、マーケティングのメンバーで「どれを優先的に解決するか」「何が一番お客様にとって価値があるのか」を話し合う「製品力会議」という場を作っていましたね。楽楽シリーズを開発する頃には「顧客志向」のカルチャーが根付いていたため、自然と「お客様の声を最優先に意思決定する」ということができるようになっていたと思います。

重視したのは「お客様のリアルな姿」

お客様にとって価値あるものを知るため、エンジニアはどんな取り組みをしていましたか？

エンジニアやUIデザイナーは、お客様先を訪問して実際の利用シーンを見たり、電話でインタビューしたりというのはやっていましたね。

業務の詳しい内容を完全に理解できなくても、直接会ってやり取りすると「こんな人が使ってるんだ」というイメージがつかめます。それが開発者にとっては大事なんです。

お客様が使うイメージをつかむことで、どんな変化があるのでしょうか。

開発者自身が少しでも「お客様のリアルな姿」を知っていると、いざ仕様を考えたり改善案を作ったりする時に発想が変わるんです。

自分が書いているコードが誰かの課題解決に繋がっていると思えると、モチベーションも上がりますし、本当に使う人の役に立ちたいという視点でよりよい実装アイデアが出せるようになります。

そういった一つ一つの小さな差分が積み重なって最終的なプロダクトの使い勝手に大きな差として現れてきます。結局、SaaSというビジネスも人と人のつながりで成り立っているので、コードや技術の先にある、お客様という人を開発者が意識することが重要です。

マルチプロダクトを高成長させる戦略

ベスト・オブ・ブリード戦略を意識し始めた経緯を教えてください。

ベスト・オブ・ブリード戦略を自然ととっていたというのが僕の感覚ですね。記憶はあやふやですが、ラクスのプロダクト戦略の強みをベスト・オブ・ブリードという言葉で認識したのは先ほど述べた通り2011年とか2012年頃だと思います。

それからしばらくたって、各サービスをよりスピード感をもって成長させるために、サービス別組織として営業、マーケ、CSなどビジネス側の部門を事業部制としてまとめましたね。そのほうが自分たちのターゲットのみを意識して素早い意思決定ができます。この頃には全社員がベスト・オブ・ブリード戦略が当社の強みと明確に認識していたと思いますね。

ラクスは各プロダクトの技術選定にも裁量がありますが、これもベスト・オブ・ブリード戦略の考え方が活かされているのでしょうか？

技術選定自体はベスト・オブ・ブリード戦略と直接の関係はなく、開発スピードや長期的な保守性などのいくつもの要素を勘案して決めています。各開発サービスのエンジニアが決定します。特にこれを使わないといけないという縛りはなく、一番のポイントは「そのときにベストと思った技術を選ぶ」ということです。ただ、社内のノウハウから、データベースはPostgreSQL、言語はJava、PHPがほぼ選択されます。

例えば、初期のプロダクトでは短期リリース実現のためにやや古めではあるけど再利用性などのメリットを生かすために既存の技術スタックを流用するということもやってました。今は組織が拡大し、リソースにも余裕があるためそのような縛りなく新しい技術スタックやアーキテクチャを選択しています。いずれにしても「お客様に必要な価値を、できるだけ早く届けるにはどうするか？」が根本。技術選定はその手段にすぎない、という考え方です。

絞り込んだターゲットから圧倒的支持を獲得

ベスト・オブ・ブリード戦略によって、複数プロダクトのPMFを達成できた要因は何だと思いますか？

それぞれのプロダクトで、しっかりとターゲットを絞ったことも大きな要因です。

広く汎用的にすべてのお客様のニーズをカバーしようとしないで、「まずはこの層に刺さる機能を徹底的に磨く」ですかね。

たとえば「メールディーラー」なら先ほどとお伝えした通り、ターゲットをECショップに定め「まずはこの層に圧倒的に支持される」ことを狙っていました。なので在庫管理システムとの連携なんかも実装しましたね。

そういった積み重ねで結果的に「これがあるとめちゃくちゃ便利」「ほかに代替があまりない」という域に達することができる。当たり前と言えば当たり前なのですがベスト・オブ・ブリード戦略の真髄だと思っています。

ベスト・オブ・ブリード戦略では、複数プロダクト間の連携についてどのように考えているのでしょうか？

複数プロダクトを開発していると、どうしてもクロスセルのために共通機能やデータ連携という話が出てきます。また効率性の観点から共通モジュールの開発、共通データ基盤という技術側の発想も出てきます。

ただ、当社はいったんはそれらの優先度を落とし、ターゲット顧客が求める機能を最優先に実現してきたというのは成功要因の一つだと思いますね。ここ最近のコンパウンドスタートアップとは真逆のやり方ですね。データ連携や共通機能を実装してしまうとそれらに引きずられてしまい、足かせとなり、ビジネスとしての速度低下や使い勝手の低下を招いてしまいます。

戦略成功には組織の「熱伝導性」を高めることが重要

一般的に組織規模が拡大すると分業が進み、開発組織にお客様の声は届きづらくなります。ラクスの開発組織としては、どのような対応が重要と考えていますか？

組織規模が大きくなると開発とお客様の距離は遠くなりますので、「相手を知ろうとする」マインドセットを持ち続けてもらうことが重要。ここで言う相手とは、お客様と、お客様と接点を持つ社内の他部署の両方です。

お客様を知るには、可能なら直接会いに行く・現場を見に行くのが一番です。リアルで訪問すると会社の雰囲気や業務の流れがより具体的にわかります。それに、何社か回ると「この業界のお客様はこういう課題を抱えているんだな」といった共通点や傾向も見えてきます。開発はCSほど深く顧客業務を理解できるわけではないですが、それでも実際に一度触れるかどうかで、見える景色がまったく違ってくるんです。

社内の他部署との連携についてはどうでしょうか。

各部署同士がお互いの役割や温度感を知ることが大事です。

開発であれば「CS・営業がどんなやり取りをしているのか」を知るだけでも、認識が変わります。たとえば、営業の日報を見たり、CSの対応履歴を確認したりするだけで、「こんなふうに使われているんだな」「ここに不満を持たれているんだな」と具体的なイメージがつかめます。

創業時に自然と行っていたことを、今は仕組化して意識的に行っていく必要がありますね。

はい、昔は開発、営業、CSの距離が近かったので、お客様の声やビジネスのリアルな状況（熱量）がダイレクトに伝わっていました。でも、組織が大きくなると「お客様の声が届くまでの経路」が長くなり、熱量が薄まってしまう。

開発側・ビジネス側相互が自分から情報を取りに行き、組織の「熱伝導性」を高める必要があります。

単にビジネス責任者が熱量を持って伝えてくれるのを待つだけではなく、開発側からも「何が求められているのかを知りたい」と積極的に動くことが大事です。そうしないと、規模が大きくなるにつれてお客様のリアルな声が遠のいてしまうんですよね。

つまり情報が自動的に伝わってくるのを待つのではなく、能動的にアクセスすることが必要になってくる、と。

そうですね。結局、どんなに規模が大きくなっても、「顧客志向で製品を作る」ためには、開発もお客様を知る努力をし続けなければならないんです。そのためには、お客様と直接話す機会をつくること、そして社内の他部署との情報共有を深めることが欠かせません。

昔は規模が小さかったから自然とやれていたことも、いまは能動的に取り組まないと情報が届かない。だからこそ、「どうやったら熱量を伝え合えるか」を組織として工夫する必要がありますね。

昔のような距離感は戻せなくても、マインドセットや仕組みを作れば、お客様とのつながりを維持できるんですね。これからもその姿勢を重視していきたいですね。

「誰かの役に立っている」実感こそ開発の醍醐味

最後に、エンジニアがラクスで顧客志向で開発することの一番の醍醐味は何でしょうか？

やっぱり「誰かの役に立っている」という実感を得られることですね。

技術を追う楽しさもありますが、最終的には「自分が作ったものが誰かの課題を解決している」とわかるのが一番の喜びだと思います。

当社は長年にわたってお客様の声をしっかり聞く取り組みを続け、それがベスト・オブ・ブリード戦略を支えてきました。結果として、業界トップレベルシェアのプロダクトも複数あります。つまり、自分たちが開発したものが「本当に世の中で使われて、誰かの役に立ち、評価されている」という手応えを得やすいんです。

あと、10年以上提供し続けているサービスも多数ありますが、古臭い技術スタックのサービスだけではありません。既存のアーキテクチャを刷新したりする機会もありますし、新規プロダクトの立ち上げもあります。常に新しいことに挑戦する機会があるかと思います。お客様の課題を意識して開発していくので、ダイレクトにお客様へ貢献できる。そういう面でも「人の役に立つものを開発したい」という想いの強いエンジニアにとってはかなりやりがいが大きいかと思います。