【ラクス開発部門トップが語る】「顧客視点」を高め、圧倒的な使いやすさを追求したい

はじめに

こんにちは、株式会社ラクス開発本部長の公手です。

普段はブログを書くことが少ないのですが、今回は当社のエンジニアやデザイナーたちが特に大切にしている顧客視点について共有したいと思い、投稿することにしました。

この投稿を通じて、社内のエンジニアやデザイナーに顧客視点の重要性を再確認してもらい、それぞれの役割の中で使い勝手の良いSaaSを開発するためにどのようなアクションを起こすべきかを考えてもらえるきっかけになればとの狙いもありますし、ラクスの開発組織が顧客視点を最優先に考える組織であることを、社外のエンジニアの皆さんにも知っていただければ幸いと考えております。

ラクスがプロダクト開発において徹底してきたミッション

ラクスの開発本部が掲げるミッションは、

「顧客をカスタマーサクセスに導く圧倒的に使いやすいSaaSを創り提供する」

です。 実は2017年と結構最近までは言語化されておりませんでしたが、2000年代初期のSaaS開発時から徹底してこのミッションを果たしてきたと思っています。

ラクスはベストオブブリード型のプロダクトを提供することを戦略としています。

当社の代表的なプロダクトである、楽楽精算や楽楽明細という名称を聞くと、楽楽シリーズという統合スイート型プロダクトをイメージされるかもしれませんが、実際にはプロダクト間連携機能などはあまりなく、例えば楽楽精算は経費精算分野で、楽楽明細は請求書発行分野で、それぞれがベストとして選ばれるプロダクトになることを目標として単独進化・開発が進められてきました。 他プロダクトの仕様や使い勝手で引っ張られることもありません。その領域の顧客の声を真摯に受け止め、プロダクトに反映していけば、その分野においては顧客のペインを確実に解決できる良いプロダクトを最短で開発できます。

まだベストオブブリードという言葉も広まっていなかったこともあり、明確にそういう戦略を意識して開発してきたわけではありません（というのが私の感覚）。各プロダクトにおいて、その分野に特化して、ビジネスチームと開発チームが一丸となって顧客ペインの解決にひたすら取り組んできた結果、顧客に高く支持されるプロダクトにまで成長し、幾つかのプロダクトはその領域で高いシェアを獲得することができました。

※複数の高いシェアを持つプロダクトがあることもラクスの大きな特徴の一つです。 のちのちベストオブブリードという言葉を知り、「あぁ、僕らがやっているのはこれなんだ」と思った記憶があります。

この成功の背景には、エンジニアやデザイナーたちが「顧客の成功を支えるためには使いやすさを徹底的に追求すべきだ」という考えを自身に深く根付かせ、それを実際に徹底して実行してきたことがあります。

欠けていた顧客視点（持っていると勘違い）

プロダクト開発（だけでなくあらゆるサービス）においては、顧客視点（顧客解像度を高く持ち顧客と同じ視点に立てること）を持つことは今や当たり前に語られていると思います。ソフトウェア開発の現場でも、エンジニアやデザイナーが単に技術的なスキルを持っているだけでは不十分で、実際にユーザーや顧客が求める価値を提供できるよう、その視点やニーズを深く理解することが当たり前に求められています。

わかったつもりになっているという罠がありますが、当社で最初のSaaSプロダクトの「メールディーラー」の開発を2003年に当社の創業メンバーから引き継いだ私もその罠にはまっていました。営業資料の読み込みや役員からのプロダクトの説明を受けただけで顧客を理解したつもりになっていました。

当時のメールディーラーはまだPMF（Product-Market Fit）にも至っておらず、私と二人三脚でメールディーラー事業を担当していた当時の事業責任者HIさんはPMFを目指して奮闘していました。そうしてようやくECショップの店長さん達に刺さり、その領域でPMFを達成しました。そこで上がってくる機能要求は私の想像していたものと違うものも多く、HIさんと意見の相違もありました。顧客の解像度のレベルが全く違うために私が開発するものがHIさんのイメージするものと微妙に違うということが結構ありました。

顧客視点の獲得に向けて

当時は小さなベンチャー企業だったこともあり、夜中遅くまで開発をしていた（笑）私に大変気を使いながら、私の顧客視点強化を目指し、いろいろな取り組みを提案（やってくれ依頼）してくれました。

• 営業同行する
• 実際に営業もしてみる
• 営業の商談議事録を読む
• システム障害時後に報告書を書いて顧客のところに謝罪に行く
• プロダクトに関するメールでの顧客対応をすべてやる

などです。

「こんなことまでやらないといけないのか」と思いつつやっていましたが、やるうちに顧客解像度が相当上がり、HIさんや新しく入った営業責任者とかなり近いレベルまで顧客理解が進みました。 メールのサポートは特にしんどかったですね。。操作の流れをテキストで説明するのは難しく、うまく説明できずに何度もメールでやり取りをする、時にはお電話で説明させていただくということありました。 説明しなくても理解してもらえるUI/UXを作ろう、と心の底から思いました（笑） 顧客訪問すると、使っているブラウザ、モニタのサイズなんかも目で見てリアルにわかります。

顧客視点獲得の効果

その後は認識のずれも相当少なくなり、仕様の決定などもスムーズになりました。

また、マインド面でも大きな変化がありました。人は困っている人を助けたくなる性質があり、知っている人だとなおさらその思いが強くなります。顧客解像度が高くなればばなるほど親身に顧客のことを考えられるようになり、早く顧客を助けたいという思いが強くなりました。新機能開発、バグの修正、トラブル時の対応速度もかなり早くなりました。顧客解像度の高いエンジニアとそうでないエンジニアでは行動が変わってきます。例えば、一つのバグが引き起こす事象によって、解像度が高ければ、単にその操作ができないということだけでなく、その操作ができないことにより、そのユーザーがどのように困るのかを想像できます。それが想像できるかできないかで、バグ修正の速度感や判断が変わってきます。これはインフラで障害が発生した場合などの対応でも同様のことが言えます。

その後しばらくはメールディーラーの開発チームでは営業同行やメールサポートを必ず経験させるようにしてきました。

組織の成長による顧客視点低下への対策

組織が大きくなるにつれ役割の分担が進み、カスタマーサクセス（CS）部門、営業部門、マーケティング部門、開発部門がそれぞれ専門組織化しました。開発部門は効率化を求めて開発に注力すべきとなってきました。営業やCSから席も遠くなるなどして顧客の声を感じられる機会も減り、エンジニアやデザイナーの顧客解像度は自然と低くなってきやすくなります。

とはいえ、エンジニアやデザイナーが300人近くなった現在でも、それぞれが高い顧客視点を保持できていると思っています。 どういう工夫があるのかというと、実は特段工夫はありません。当たり前に常日頃から顧客理解の大切さを訴え続けるのみです。 顧客視点を高く保つことの大切さは常々エンジニアマネージャーからメンバーに伝えられ、顧客ファーストで判断をしているのかメンバーへの問いかけが日々続けられています。

それ以外でも、（メールでの顧客対応はさすがにやらなくなりましたが）各プロダクト開発チームの判断で、CSのメール対応を読んだり、入社後の営業同行などを継続してくれていたりもします。 プロダクト開発の各工程にはCSや営業部門には積極的に入ってもらい、意見をどんどん吸い上げています。

ミッションの言語化と浸透

カルチャーとして顧客視点を最重要視し開発することは普通に行われていたのですが、 より浸透させて根付かせるため、また採用の際にも説明しやすいようにと2017年に冒頭で紹介したミッションとして言語化しました。

「顧客をカスタマーサクセスに導く圧倒的に使いやすいSaaSを創り提供する」

現在ではマネジメント層だけでなく、インナーブランディング担当チームがあり、ミッションの浸透や顧客視点強化を訴え続けてくれています。 半期に一度このミッションの浸透度や理解度、顧客理解の重要性などを部門内アンケートで確認しています。

圧倒的な使いやすさを求めて

開発組織にはバックエンドエンジニア、フロントエンドエンジニア、UI/UXデザイナー、プロダクトマネージャー、AIエンジニア、アーキテクトなど様々なエンジニア・デザイナーがおります。それぞれが自身の専門性を活かしながら「何がお客様にとって最高に使いやすいものなのか？」を追求して開発をしてくれています。高い顧客視点をもって我々のミッションを遂行していけば、今後も高く顧客に支持されるプロダクトを生み出していけるはずです。

社内のエンジニア・デザイナーの皆さんがこの投稿を読むことで、改めて顧客解像度を高く持つことの重要性を理解し、さらなる顧客視点の強化に努めていただけると幸いです。また、この投稿が（あまりたいしたことは書いていないですが）社外のエンジニア・デザイナーの皆さんの参考になり、よいプロダクトが世に生み出されることの一助となって人々のペインが解決されていけば幸甚でございます。

最後にですが、もし我々のミッションに共感されて興味を持たれた方がございましたら、ぜひカジュアル面談にお越しください。 私も含め当社のエンジニアマネージャーにていろいろとお話しできればと思っています。