VoCを一気通貫で届けていく、BtoB SaaS「Loglass」におけるUX改善の仕組み
こんにちは！経営管理SaaSのログラスでPMMとカスタマーサクセス責任者をしている浅見と申します。
一般的にBtoB SaaSは「誰の、どんなペインを解消するのか？」をベースに提供価値をつくっていくのが真髄と言われております。
よって、顧客の一次情報を得ていくことはプロダクト開発上もとても大事なポイントになっていく訳ですが、一方で一次情報となるVoC（Voice of Customer）の取得→ペインの解像度の向上→提供価値（≒機能）のデリバリーという一連の流れをつくっていくのは言葉で言うほど簡単ではありません。
ログラスでもこの流れをつくることはかなり意識しており、組織が大きくなっていく中でも仕組みの改善でうまく維持できていると思っていますので、当時の課題も踏まえながら今どの様にしてVoCをプロダクト開発（今回で言えば特にUX改善）に活かしているのか、という部分について触れていきたいと思います。
本記事は以下の様な方を意識しながら書いていきます。
・顧客の要望（VoC）を適切に届けていきたいカスタマーサクセスの方
・一次情報を得て、UX改善に繋げるサイクルを回していきたいPdM、エンジニアの方
・事業/組織が拡大していく中で、ビジネス組織と開発組織の連携の難しさを感じ始めている責任者の方
ログラス社におけるUX向上の課題
ログラスでは経営管理領域におけるペインを解消し、企業価値を高めることを提供価値とするプロダクト「Loglass」の開発・提供を行っています。
Loglassの開発における特徴としては、経営管理領域におけるドメインの複雑性、ユースケースの多様性にあります。
例えばひとえに予算策定といっても、組織規模やビジネスモデルによって、その策定プロセスや粒度については全く異なります。
ほぼすべての企業がやっている予算策定で例を1つあげます。
経営陣が各事業の売上・利益目標を決めて、それらを各部門（支店）に振り分けてKPIが決まるトップダウン方式の予算策定もあれば、各部門（支店）から足元のKPIを踏まえてどれくらい成長できるかを吸い上げて、売上/利益を策定するボトムアップ方式もあったりなどします。そうなった場合、同じ予算策定でも実際の業務の進め方はまったく異なるわけです。
（なお、余談ですがLoglassの場合はボトムアップ方式、もしくはトップダウンとのハイブリッド方式の方が価値を感じやすいプロダクトになっています）
このように、ひとつの業務プロセスでも様々なユースケースが存在するため、「xxxができる機能をつくる」というのは最適解にならないことが多く、「どんな顧客の、どんな課題に応えるのか？」を明確にしていかなければ、本当に価値のあるUXは実現できないのです。
そんな中、経営管理の領域は実務として経験する方が相対的に少ないことから、特に開発チームがこのユースケースを理解をするのが困難であることが創業期からの課題でした。
ログラスのUX改善全体像
ゆえにログラスでは、顧客の一次情報を得るCSやセールスが起点となり、開発チームに一気通貫でVoCを届け、UX改善を爆速で進めるプロセスを開発しています。
以下、めちゃくちゃ雑にMiroで流れをつくってみました。
緑は各タスク、赤は同期の会議体を表しています。順番に解説していきます。
1.要望（VoC）を蓄積する習慣をつける
ログラスのSlackには、顧客要望を蓄積していく専用チャンネルをつくっています。
CSやセールスはお客様との打ち合わせが終わる度にすぐにこのチャンネルに要望を起票し、すぐに誰でも確認できる様な状態にしていきます。
要望を起票する際のポイントは、「xxxxの機能が欲しい」で留めずに、その要望があがる背景はなにか？どんなユースケースで起きる課題なのか？というものを必ず記載することです。
逆に、具体的な機能開発をあげていくことはあまりおすすめしないです。Howにこだわりすぎると近視眼的な捉え方になってしまい、解決できるユースケースが限定的になってなってしまったり、その機能が後々の負債になってしまう可能性があるためです。
ゆえに、ビジネスサイドとしては誰の（Who）、どんな課題（What）が起きていて要望があがっているという部分を強く伝えるように意識しています。
以下は弊社CS元野さんの要望起票なのですが、内容は伏せさせていただくものの、顧客からいただいた要望をそのまま記載するのではなく、その上で目的やその他で対応しうるケース等を補足しより解像度があがるようにしてくれています。
2.要望をDBとして蓄積・開発チームが随時確認
要望をSlackに垂れ流すのみではなかなかキャッチアップできず、整理も難しくなっていきます。そこで、ログラスでは、Slackでスタンプ→Zapierで連携しNotionDBに蓄積という業務フローを爆誕させました。
（これも余談ですが、以下のツイートの評判が思いの外よかったことから今回のnoteを書くことに至りました）
ログラスではCSがお客様の要望を吸い上げ、詳細をSlackに投稿→スタンプを押すと、UX向上のためのチケットとしてNotionDBに蓄積、PdMやエンジニアが整理するというサイクルを回しています！
— 浅見祐樹｜ログラス CS Mgr🐳 (@yukiasamin) February 9, 2023
ありがたいことにプロダクトのUIUXをお褒めいただくことは多いのですが、甘んじず改善を日々回していきます。 pic.twitter.com/q6DCvpSVYl
これはかなり革命的な業務フローになりまして、Slackで要望を投稿できるライトさと、DBとしてしっかり蓄積し続ける堅実さを両立させています。
DBとして蓄積されるメリットとしては単なるファクト確認を漏れなくできるだけでなく、同様の要望をカウントすることでその要望が個別顧客からのものだけでないことが確認できたり、複数の要望に一気に応えるための価値の高い機能開発の検討にも活用することができます。
なお、DBとして蓄積をした後は、ビジネスサイドで一定の重み付けをした上で、開発側で関連するエピックとの紐づけやステータス管理を行っています。
もちろん、足元は開発として難しいものや、相対的にみた時に優先順位として後手に回ってしまうものもありますが、それでも開発チームは要望をすべて目を通してくれています。（以下は各チームでやっている要望をスクリーニングする会の様子）
3.重要なユースケースは同期で理解を深める
こうして要望は集まり開発チームにも届くのですが、中にはめちゃくちゃ複雑性が高い、もしくは顧客にとっての重要性が異常に高い要望等をいただくこともよくあります。
そうなった時に、その内容や重要性を適切に伝える場を設けております。それがログラスにおける”要望を解説する会”です。
以前の記事でもこちらについては紹介していますが、直近ではこの会議体もブラッシュアップされており、今現在は以下の様な形で実施しています。
上記にも書いている通り、この場では要望の背景や重要性について理解をすることを目的としていますので、起票したCS担当者がしっかりと語り、関係者全員が同じ目線を持ってこの要望に向き合えるようにするための時間としています。
一方で、組織が大きくなるほど会議体コストはどんどん上がっていきますので、基本的に必須参加者は関係者のみに絞り、あとは任意で参加できるような体制を取るようにしています。
4.複雑な要件はドメインモデルで開発方針をつくる
ここまでは主に開発チームから一次情報を取得する流れについて説明していきましたが、文字通り一気通貫ということで、ログラスでは開発フェーズでもビジネスチームがガッツリ連携しています。
ビジネスサイドの方にはあまり聞き馴染みのないかもしれませんが、ドメイン駆動設計（通称：DDD）と言われるアジャイル開発における手法があります。本件でDDDの手法でやっていることをめちゃくちゃ簡単に言えば、「顧客のユースケースを図式化しながら、本当に使ってもらえるための開発を検討する」ことです。
DDDにおいてはドメインエキスパートと言われる当該の業務領域に詳しい人間と共にこのユースケースモデルをつくることを推奨されているのですが、Loglassの場合はこの役割をCSが担っています。
イメージとしては下記の様な形で、PdM、エンジニア、デザイナー、ドメインエキスパート（CS）が以下のモデルをつくりながら実装イメージについてディスカッションをしたり、顧客にヒアリングをしています。
新機能や、複雑性の高い機能開発において特に相性がいいです。
つくるからには価値のあるものを、ということを全メンバーが本当に考えており、LTVの高い開発設計の仕組みと言えると思います。
※DDDを取り入れてどのように進めているかはもっと書けることがあるのですが、長くなりすぎてしまうのでこの記事ではここまでにしておきます
詳しく知りたい！という方はよろしければ、DDDを積極的に発信しているエンジニアリングマネージャー松岡さんの記事をご覧ください！
5.CSチームのPlanning&Sprint Review（会議体）への参画
（主にビジネスサイドの方向けに）
ログラスではスクラム開発と呼ばれる手法を採用しています。現状だと1週間を1つのタームとして開発プランの検討、実装（リリース）を繰り返しているのですが、ログラスではこれらに関わる会議体にもCSが参画しています。
以下、それぞれの会議体にでているメリットを簡単にまとめておきます。
Planning
概要：来週以降これ開発するよ！を話す会
参加するメリット：
・着手直前の細かな仕様詰めを行えるため、手戻りが減る
・（特に小玉開発の）優先順位について強く目線合わせができる
Sprint Review
概要：次以降のSprintで何を開発していくべきか顧客目線でFBする会
参加するメリット：
・修正等もクイックに行えるため、リリース時の品質がより高まる
・新機能をいち早く理解できるので、デリバリースピードが上がる
この会議体にCSが参加しはじめたのはここ最近なのですが、目に見えてデリバリーの品質もスピードも向上していると感じており、先日エンジニアチームとKPT（振り返り）を行った際にも、CS巻き込みに関する前向きなコメントが多く挙がっていました。
より詳しくはCSの比留間さんが書いた記事で解説しておりますので、ぜひぜひ読んでみてください！
おわりに（気持ちパート）
ここまで読んでいただき、ありがとうございました！
主にTipsベースで書いていきましたが、比較的どの会社でもトライしやすいものを選んでみたので、参考になれば幸いです。
そして色々書きましたが、最後に私が強く伝えておきたいなと思うことは、
顧客に価値を届けてこそのUX
ということです。本当にこれに尽きます。
ログラスは全社で価値にこだわっています。自信をもって言えます。
ログラスのバリューのひとつに、LTV firstというものがあります。
今私たちがやっている仕事や、開発している機能は本当にLTVの高いものなのか？と常に問いかけていく結果、今回の例にあげたようなアクションをしています。最後に突き詰めるべきは、自社としてどうあるべきかというバリューに立ち返っていくことです。
事業に関わる皆さん、自社のミッションやバリューに沿った開発・デリバリー体制をつくれるように、お互い切磋琢磨していきましょう！
We are hiring！
最後にいつもの宣伝です！！！
ログラスでは超全力で採用活動を推進しております！
ビジネス、プロダクト、コーポレートのほぼ全職種で募集をしておりますので、ぜひ興味をもっていただけたらお話しましょう！（今時点で興味をもっていなくてもお話しましょう）
また、ログラスの発信コンテンツが一覧になったまとめページができました！
網羅的に整理されているので、何かしらご関心をもっていただけるものがあるのでは！と思っております。
最後まで読んでいただき、ありがとうございました！
毎月note書くぞ2023なのですが、4月になに書くかなにも決めていません！
友人・知人の方、なんかリクエストやアドバイスあればお願いいたします！！！
この記事が気に入ったらサポートをしてみませんか？