Nstockでは、プロダクト開発において「ユーザーの声」を重視しています。しかし、それは単に「要望をそのまま作る」ということではありません。

複雑化する問題に対し、エンジニアとCS（カスタマーサクセス）がどのように連携し、プロダクトに落とし込んでいるのか。そして、そこにある面白さとは？

今回は、株式報酬SaaS事業に立ち上げから携わるエンジニアの佐野 智章（@ryan5500、以下、ryan）と、CSの杉浦 俊貴（@sugiura0626、以下、sugiura）が、Nstockにおける開発の現在地について語り合いました。

「正解」はユーザーの中にしかない

── Nstockではユーザーの声を大切にしていますよね

ryan：そうですね、プロダクトの立ち上げ期から、ユーザーの声を大事にして開発してきました。

例えば、SOの契約を電子的に行える「契約締結機能」は、ユーザーの声から生まれた機能です。

「すでに電子契約ツールがたくさんある中、Nstockで新たに作ったとして価値を提供できるのだろうか？」という議論がありました。ですが、ユーザーにヒアリングする中で、権利者（SOを受け取る人）ごとの名前、住所、付与するSOの個数などを差し込む手間が想像以上に膨大であることが見えてきました。

数百、数千人規模の権利者がいたり、年に何度もSOを発行するスタートアップだと、この手間はかなり大きいのです。

結果として、「契約締結機能」はリリース初期のユーザー獲得に大きく貢献しました。

sugiura：契約締結機能は今でも多くのユーザーに活用されている機能です。

SOに力を入れているスタートアップの中には、SOを発行する頻度の高いスタートアップも多いです。Nstockも年に2度、SOを発行しています。オペレーションが重いことで、SOを発行するのが億劫になってしまうともったいないですよね。

運用面から権利者フレンドリーな設計を支えていくことは、Nstockが生み出せている価値の一つだと感じています。

ryan：そして提供から2年経ち、プロダクトが成長する今、ますますユーザーの声が大事になってきていると感じます。解くべき問題が複雑になってきているからですね。

上場直前のスタートアップの中には、非常に先進的なストックオプション（以下、SO）の使い方をされているケースがあります。SOの設計や運用方法について話を聞くと、全く想像していなかったユースケースが出てきます。

より広くプロダクトを届けるために、そうしたスタートアップの意見を聞きに行くのは必須だと感じています。複雑な問題を解決できれば、結果として他のユーザーにもより良いプロダクトを届けることができるはずですから。

sugiura：ryanさんが言う通りで、「正解はユーザーの中にある」んですよね。

CSチームもドメインチームも、ある程度の事例は持っています。でも、何が正解かは、ユーザーのSO設計や運用設計によって全く違うので。

「Nstock推奨のやり方がマッチする」という会社さんもいれば、「独自の考えがあるからこうしたい」という会社さんもいる。それを聞かずに、僕らが「これが理想です」と押し付けても、なんの価値も生み出せません。聞かないとわからないんですよね。

そうしてプロダクトがより良いものになっていけば、CSが手厚くサポートしなくてもユーザー自身で使いこなし、満足していただける状態になっていくはず。

例えばLINEやメルカリって、何をしたらいいか直感的にわかりますよね。何をするにも問い合わせしないと使えなかったら、面倒で使わなくなると思うんですよ。

それはto Bのプロダクトでも同じで、CSのサポートがなくてもスムーズに利用できるのが理想だと思っています。

そんな理想を目指すためにも、やはり「ユーザーの声」は一番大事にすべき指針だと思っています。

ユーザーと「期待値」を揃えるチーム連携

── 具体的に、ユーザーの声をどのように開発にフィードバックしているのでしょうか？

sugiura：ユーザーからの指摘で気づいた、細かいUIの改善要望は、Slackでサクッと連携してすぐ直してもらうことが多いです。「ここが使いにくい」「文言がわかりにくい」といった声を投稿すると、エンジニアが「それならすぐ直せますよ」って数時間後にはリリースされていたり。このスピード感はNstockならではだなと思います。

数値を表示するフォントを「等幅フォント」に変更したのは、その一例です。

株式報酬SaaS Nstockの改善 #2📣

数値を表示するフォントを「等幅フォント」に変更しました。

Nstockは、様々な種類の数値が表示されるサービスです。数値を表示するフォントを等幅にすることで、桁の表示が統一され、多くの数値が並ぶ画面でも桁を間違えることなく把握できるようになります。 pic.twitter.com/7ubNJfPwnD

— Nstock (@Nstock_jp) August 21, 2024

ryan：ユーザーにとっての「使いやすさ」に直結する部分は、CSからのフィードバックを一番頼りにしています。ユーザーの声はなるべく早く反映し、ユーザーに喜んでもらえるようにしていきたいですね。

sugiura：一方で、機能追加のような大きな話になると、すぐに改善！とはいかないので、プロセスが変わってきます。

ryan：まさに。スタートアップから「今の機能では導入が難しい」とのご相談をいただいた時、まずは「何が足りないのか」を徹底的にヒアリングします。

その上で、個社向けのカスタマイズではなく、すべてのユーザーに展開できる機能として作れないかを考えます。

sugiura：例えば、「想定キャピタルゲインのシナリオ機能」はそうして生まれた機能の一つです。

Nstockには「想定キャピタルゲイン」を表示する機能があり、評価額を入れると、権利者は自分の持つSOの価値を見られるようになります。「想定キャピタルゲイン」は「SOの価値を権利者に正しく伝える」ために、Nstockの導入モチベーションの1つになっている機能です。

この機能に対して、「評価額を権利者側でシミュレーションできるようにしてほしい」という要望をいただいたことがありました。現在の評価額だけでなく、期待通りに成長した場合や、うまくいかなかった場合についてもシミュレーションできるようにしたいという背景です。

一方で、他のユーザーにヒアリングすると、「会社側で一定コントロールしたい。自由にシミュレーションできると期待値調整が難しくなってしまう」という声も出てきました。

ryan：こうした声を集めて作ったソリューションが「想定キャピタルゲインのシナリオ機能」です。

会社側がいくつかのシナリオを設定でき、権利者はそのシナリオを使って複数パターンのキャピタルゲインをシミュレーションすることができます。会社側での期待値コントロールを可能にしつつ、権利者側でシミュレーションができるようになりました。

もちろん、どうしてもそのユーザーが必要で、かつ他のユーザーは使わないようなケースもあります。そういった場合は、影響範囲を最小限に抑えて実装するようにしていますね。

sugiura：大きな機能については「カスタマイズ」しなくて済むよう、商談の段階から連携することも多いですね。 セールスチームから「このユーザーのSOはNstockで管理できるのか？」と相談を受けて、開発チームと「運用でカバーできそうか」「ロードマップにある機能で代替できるか」といった判断を受注前に行っています。

そうした中で、開発チームもCSもわからない問題が出てくることは日常茶飯事です。Nstockには異なるバックグラウンドを持ったドメインエキスパートが3名います。困ったときにドメインエキスパートに気軽に相談できるのは、めちゃくちゃ心強いですね。

こうして、期待値をなるべく合わせたうえで導入いただくことを大事にしています。期待値がズレた状態での導入になってしまうと、お互いにしんどい思いをすることになるので。

ryan：デザイナーが商談時点でプロトタイプを作って、「ここまでならできます」と見せることもあります。PdMとデザイナーが協業して「本当に価値提供できそうか」を見極めてくれているのは大きいですね。

あと、ユーザーのほとんどがスタートアップ企業なので、同じ目線で話せるというのもあります。Nstockの思想をご理解いただいたうえで、「一緒に良くしていきましょう」という共感がベースにあるので、建設的な議論ができるのはありがたいです。

sugiura：加えて、半期や四半期ごとのロードマップ策定ミーティングにはビジネスサイドのメンバーも参加しています。「受注率を上げるためにはこの機能が必要」「解約リスクを下げるためにここを直してほしい」といった現場の声を反映させながら、開発ロードマップを決めています。

CSが優秀な「防波堤」になりすぎていないか？

ryan：CSチームの能力が高いからこそ、ユーザーに良いサービス、価値を届けられているなといつも感謝しています。

一方で、開発チームが 「守られすぎている」ことによる弊害もあるなと。

CSが「防波堤」となってユーザーの課題を解決できてしまう分、エンジニアに「本当の困りごと」が伝わりづらくなっている側面がありそうです。

例えば、データの修正依頼などもCS側で対応していただいてることが多いのですが、本来であればプロダクト側で修正機能を実装したり、データモデルを見直したりして解決すべき課題も多いはずなんです。

短期的にはユーザーの問題を解決できてハッピーなんですが、長期的には「ユーザーが自走できるプロダクト」から離れてしまっていないか、と。

sugiura：そうかもしれません。実は最近、CSがユーザーの代わりに初期設定を行う「設定代行」にどれくらい時間を使っているか集計してみたんです。そうしたら、想像以上に時間を使っていることがわかって。

「CSでこれだけ時間がかかるなら、ユーザーがやったらもっと大変だよね」という事実に改めて気づかされました。本来はプロダクトで解決していきたい。代行業務が「当たり前」になってしまって、フィードバックするのを忘れてしまっていたな、と反省しています。

Nstockのエンジニアは「自分たちが作ったものが本当にユーザーの役に立っているか」をすごく気にしていますから、こうした事実も遠慮せずフィードバックしていかないといけないですね。

もしかしたら、普段のCSが行っている代行業務を見ていただくのはいいかもしれません。

ryan：それはいいですね！ 実際に見ることで、エンジニアとしての気づきも多そうなので、早速やってみたいです。

エンジニアがもっと「ユーザーの隣」へ行くために

── 最後に、今後の課題や展望について教えてください。

ryan：ユーザーフィードバックの管理については、まだまだ改善の余地があります。いただいた声をどう解釈して、いつ実装するのか。そのプロセスをもっと可視化して、置き去りになる意見がないようにしたいですね。

「あれ？ 前も話してた気がするけど、結局どうなったんだっけ？」となることがあります。

sugiura：そうですね。ユーザーの声を集約する場所をちゃんと作っていきたいです。

今はSlackやメール、Notionなどいろんな場所に散らばってしまっているので、それをいい感じに貯めて、開発チームにも見えるように整えたいですね。「現在、その要望は実現されているのか？」といったステータスも含めて。

あと個人的には、エンジニアとユーザーが直接触れ合う機会をもっと作りたいですね。

作成途中の機能を数社のユーザーに試してもらう「Demo Day」のようなイベントを開催して、その場で「この機能でペインが解決できますか？」と直接対話できるような場を作りたいな、と考えています。

ryan：それはいいですね！ エンジニアもやる気が出ます。

過去に、Nstockの2周年イベントの際にユーザーが来てくださったことがあって。ご挨拶したところ、「使わせていただいてます、めちゃくちゃ助かってます！」と言っていただけて。直接お話できて、すごく嬉しかった思い出があります。

また、軽い要望であれば、その場で実装してイメージをすり合わせることもできそう。

sugiura：やりましょう！

「正解」を自分たちで作っていく面白さ

── 最後に、Nstockに少しでも興味を持ってくださった方へメッセージをお願いします。

ryan：職種の壁は薄く、密に関わりながらやっていける組織です。まだ全然固まっていないので、日々改善していくプロセスそのものを楽しめる人にはすごくフィットすると思います。

sugiura：複雑で難しいことも多いですが、それすらも楽しめる人と一緒に働けたら嬉しいですね。プロダクトとの距離が近く、自分たちのフィードバックが形になっていく面白さを感じられる環境だと思います。

お知らせ

Nstockでは職種を超えて、複雑な課題にチームで向き合いたいエンジニアを募集しています。