エンジニアのストレスを徹底カット。ラッコ株式会社に学ぶ、ユーザーと開発者がWin-Winなプロダクト開発

無料で使えるWebツール「ラッコツールズ」や、初心者向けキーワード分析ツール「ラッコキーワード」で知られるラッコ株式会社。代表取締役である坂谷泰翔さんは個人開発・運営からサービスを開始し、現在はサイト売買やドメイン管理ツール、レンタルサーバーなどに幅を広げています。

坂谷さんは「良いユーザー体験とは、ユーザーがより早く、より簡単に目的達成できること」だと語ります。そしてその実現のために、エンジニアがノイズなく成果に集中できる環境を整えているそう。

直感的に使えるシンプルさとラッコのかわいらしさが合わさって不思議な魅力を放つプロダクトの開発について、お話を聞きました。

• keyboard_arrow_down 好きだから選んだ「ラッコ」が社風にマッチ。自販機のようなユーザー体験を目指す
• keyboard_arrow_down より良いプロダクトをつくる近道は、エンジニアのノイズを取り除くこと
• keyboard_arrow_down 保守タスクは、現場を知り尽くすエンジニアからのボトムアップがうまくいく
• keyboard_arrow_down 「良い開発者体験」実現のカギは、全員が相手に気を遣えるかどうか

——そもそもですが、なぜ「ラッコ」を企業モチーフにされたのでしょうか？

もともとラッコが好きだったんです。特に漫画「ぼのぼの」のラッコが好きで。最初に始めたドメイン販売事業の中で、サービスロゴとしてラッコのイラストを使い始めたところ、お客様から「ラッコさん」と呼ばれるようになりまして、それが浸透して今に至ります。

経緯こそ偶然でしたが、ラッコという動物は結構うちの会社に合っているところがあるなと思います。ラッコは霊長類を除けば唯一道具を使える動物なので非常に賢いですから、会社として「うまく道具（ツール）を使いこなして生きていく（より良いサービスを提供する）」というようなメッセージも込められています。

さらに、会社のビジョンとして掲げている「Go Swimmingly＝スイスイと、とんとん拍子に進む」という言葉があります。こちらもラッコのイメージに沿う形で考えたものです。結果的に、ラッコは社風にとてもしっくりくるモチーフでしたね。

——そういった意味もあったんですね。サービスのユーザーは、どういった方が多いですか？

比較的ビギナーのユーザーが多いです。そのため当社で提供しているサービスにおいても、なるべくスムーズに使ってもらえるよう、不必要な専門用語を避けたりテキストを短く抑えたりといった工夫をしています。

私個人の理想としては「自動販売機でジュースを買うようなユーザー体験」をつくりたいんです。

——「自動販売機でジュースを買うような体験」といいますと…？

端的にいえば、「いつでも」「誰でも」「簡単に」「人とのやり取りなく」サービスを受けられることです。私自身、10代の頃はできるだけ人に会いたくなくて、昼間は部屋に引きこもって、夜中にこっそり外に出て自動販売機でジュースを買って帰ってくる生活をしていました。当時の私には、こうした「人とのやり取りなく使えるサービス」が非常にありがたかったんです。

——その体験は、どのようにプロダクトに現れているんでしょうか。

「人とのやり取りなく」という点では、「問合せをさせたら負け」だと思っています。

ユーザーにとって、問合せをすることはかなりストレスがかかる行為なはずなので、できるだけ問合せの必要がないものをつくりたい。そのために、たった1件の問合せでも軽視せずに、UIや表示文言、マニュアルなどあらゆる面で改善の余地がないか検討を尽くし、改善自体も優先度高く差し込んでいます。1件の問合せの裏には、不便さやわかりにくさを感じたものの問合せをしなかったユーザーが大勢いるかもしれませんから。

その結果、例えば約14万IDの利用があるラッコキーワード（キーワード分析ツール）のお問合せは、1日に1件あるかないかくらいです。機能をどんどん増やしていく中でも問合せ件数は増えていないので、いいサイクルを回せているように思います。

こういった積み重ねによってユーザーは快適にサービスを使えて、問合せ数が減ればサービス運営チームの負荷も減り、結果として利用継続率も上がれば、双方にとってよい状況になりますよね。

——「人とのやり取りなく」へのこだわりが、ユーザー、組織、事業にもプラスになっているんですね。

そうですね。ただ、問合せが少ない＝ユーザーは満足していると一概には言い切れないとも感じています。

これはセルフサーブ型サービスの弱点でもあるかもしれません。簡単に使い始められるからこそユーザーとの関係性も深くなく、フィードバックが上がってきにくい面もあるのではないかと思っていて。

不満を感じたユーザーがそのまま離脱しているという可能性も十分あり得ます。いただいた問合せをもとに改善するだけでは、ユーザー満足という面では不十分なんじゃないかと思っています。

——問合せだけで拾えない部分については、どのように機能やUIの改善点を洗い出していますか？

およそ半年に1回ぐらいのペースで、ユーザーに使用体験に関するアンケートを行ったり、ユーザーと1対1でヒアリングをしたりしています。

特にラッコキーワードでは、それまでサービスを触ったことのない方々に触っていただくことで、どんな第一印象を受けたか、どういう機能かすぐに把握できたか、などをモニタリングしています。

さらに社内では、社員みんなでラッコキーワードを使って改善案を出すグループディスカッションを行いました。開発に携わっていても、Webメディアの運営者でなければなかなか使用機会がないツールではあるので、使い方を熟知している部門の社員とのディスカッションを通して、開発チームだけでは見つからなかったさまざまな改善案が出てきましたね。

こういった取り組みは潜在的な使いづらさに気づけるので、使いやすさの追求に一役買っているのかなと思っています。

——徹底的な改善で、ユーザーの「困った」を防いでいるようにみえます。ラッコ社はどんなユーザー体験を追求しているのでしょうか。

我々が目指しているのは「ユーザーの目的達成までのスピードをより加速させること」です。シンプルでわかりやすくてサクサク動作するサービスであれば、よりユーザーがスムーズに素早く目的を達成できます。ユーザーだけでなく、誰にとっても待ち時間は少ない方がいいですからね。

——そのユーザー体験の実現のために最も大切にしていることは何でしょうか。

新規開発や改善のスピードを落とさず、かつバグを出さない・バグが出てもすぐ直せるようにしておくことですね。またそれを実現するために、エンジニアの開発以外のノイズを取り除き、成果を出すことに集中できる環境づくりにも力を入れています。

サービス品質を高いレベルに保ちながら、新規開発や改善を速いサイクルで回し続ける。これらを両立するために非常に重要な要素となるのが「ハイスキルなエンジニアにいかに気持ちよくパフォーマンスを発揮して成果を出してもらえるか」という点です。そのために、開発環境、労働環境の両面からエンジニアにとっての障壁を取り除く工夫をしています。

——具体的にはどんな取り組みをしているんでしょう。

色々あるのですが、その中でも安定して良いユーザー体験を提供することに直結しているのは「属人的な業務を極力作らない」という点だと思っています。

ドキュメントもコードも属人化が進行して「ずっと触ってきた人でないといじれない」となると、新規開発にも改善にも時間がかかり、不具合もなかなか解消できずユーザーにとって大きな不利益が発生してしまいます。それを防ぐために、約半年に1回のペースで定期的にプロジェクトメンバーを入れ替えるようにしています。

ずっと同じメンバーで業務を行っていると、段々ドキュメントもコードも「自分たちがわかればいいや」という意識になってしまい、属人化が進行してしまいます。これでは新しいメンバーが入ってもすぐに活躍してもらえない。入れ替えに備えてドキュメントはプロジェクトごとにフォーマットを作り、コードは全体の価値観として「可読性」を重視し、記述ルールを定め、誰が見てもすぐキャッチアップできるようにしています。

——成果に集中できるようにするために、他にどんな取り組みをしていますか？

ちょっと独特な取り組みとして、開発において厳密な締め切りを設けていないことが挙げられます。機能のリリース時期などおおよその目安は立てますが、 技術的に考慮しなければならない問題が発生するなど、さまざまな突発的な事柄が起こりうるので、目安として設定した期日が絶対ではないという形をとっています。

特にラッコキーワードの場合は、外部のデータを取得して処理するというサービスの性質上、さまざまな外的要求が絡むため、なかなか簡単に見積もりきれない部分があります。そのため、「この期日が絶対」という形で管理してしまうと、エンジニアにとってかなりストレスがかかってしまいます。

締め切りを最優先にして開発すると、余裕がなくなって、せっかく今まで属人化しないように整えていたコードがぐちゃぐちゃになってしまったり、テストがおろそかになって不具合につながったりする恐れもあります。プロダクトの品質を最優先にするために、機能のリリースに関しては、おおよその目安を立てつつある程度の余裕を持たせて管理するようにしています。

——ここまで聞いてきたのは、坂谷さんからエンジニアに向けての施策にみえますが、逆にエンジニアを主体とする取り組みもありますか？

リファクタリングやバージョンアップなどの保守系のタスクは、エンジニア主体で提案してもらっていますね。そのうえで、バグ対応など緊急のタスクがなければ随時対応する、という形をとっています。

新規開発や改善も含めたタスク全体の優先度は私が決めているんですが、保守系のタスクは基本的にエンジニアから「これをやりたいです」と要望のあったものを受け入れるというスタンスです。

私は全サービスのコードをくまなく見て知っているわけではないので、なかなかそういった保守上の問題は拾い切れないと思っていて。開発環境が悪化し生産性が落ちたり、サービス自体の品質が保てなくなったりすることを未然に防ぐためにも、現場のエンジニアの懸念をきちんと拾って対処していくのがもっとも適切だと思っています。

経営者としては正直、保守系のタスクは表面的には収益に直結しないぶん、どうしてもつらく感じる面はあります。ただ中長期的に開発プロジェクトを健全に保ち、良いサービスをつくれる基盤を整えておくためには、こうした保守系のタスクをこまめに進めることも非常に重要だと思っています。

この基盤ができていることで、問合せなどからのサービス改善や新規開発もより速く進められますから、我々が目指す「ユーザーの目的達成までのスピードをより加速させること」に強く結びついているような気がしますね。

——締め切りがないなど、「縛り」がほとんどないように思いますが、そういった環境で問題なく開発を進めるのは難しそうな気もします。

確かにこういった環境でも問題なく開発を進めるためには、さまざまな条件が必要になってくると思います。その中でも私が重要視しているのは、経験年数や技術力を問わず、相手に対して気を遣える資質をメンバー全員が持っているかどうかという点です。

例えば相手に気を遣えない人が1人いるとすると、その人からは全然レスが返ってこないとか、ハドルをつないで話そうとしてもタイミングを合わせてくれないとか、コミュニケーションがうまくとれない状態になってしまいます。その人自身の仕事は進むかもしれませんが、チーム全体の成果としてはマイナスですよね。

ありがたいことに、今の開発組織では相手に気を遣ってコミュニケーションを適切にとれるメンバーが多く、かなり助けられています。そういうメンバーが集まっているから、この形を維持できているのかなと思いますし、採用のときにも重視していますね。

——「エンジニアがノイズなく開発に集中できる環境」は、最近注目が集まっている「開発者体験が良い環境」とも言えそうですね。

「開発者体験を良くしよう」と常に強く意識しているわけではなくて、より良いプロダクト開発のために何が必要かと考えたときに「エンジニアがストレスなく成果に集中できる環境」は欠かせないなと。あくまで「良いプロダクトを作ってユーザーに満足していただく」ことが目的ですね。

実を言うと開発体制が整ってきたのはここ3年ちょっとくらいの話で、それまでは色々と失敗を繰り返していたんです。その体験を経て、結局自分たちで率先して開発チームをつくっていく形に落ち着きました。

やはりエンジニアに高い成果を出してもらうために環境を整備し、その成果によってユーザーが満足し、事業が成長するというサイクルでないと、気持ちよく事業もできないと思うんです。その流れをつくるのが、経営者としての責任かなと思っています。

取材：光松 瞳
文：夏野 かおる