顧客の課題解決を超えて、価値を届けるカイゼンチームの挑戦

はじめに

※この記事は、any Product Team Advent Calendar 2024の16日目の記事になります。

こんにちは！anyでナレッジプラットフォームQastのPdMを担当している樽川です。
普段、新機能開発やカイゼンチームのPdMとして、プロダクト作りや改善を行なっています。

今回は日々、お客様からいただく改善のご要望に対しての向き合い方やプロセスを紹介していきますので、ホリゾンタルSaaSの改善や新機能開発を担当しているエンジニアやPdM、デザイナーの方に読んでいただけると幸いです。

プロダクトチームの体制

現状は以下の体制でプロダクトチームを形成しています。
※2024年12月11日時点

図を見ていただければわかりますが、ジョブ型的にチームがフラットになっているのが特徴です。

詳しくはEMのYueさんが紹介しているので、気になる方はぜひチェックしてみてください！

カイゼンチームについて

カイゼンチームの役割

シン・カイゼンチームと呼ばれ、日々お客様からいただく改善要望やバグの改修などをクイックに対応するチームです。

チーム名は当時、共同で立ち上げた波多野さん(@hatamasa1988)がシン・エヴァンゲリオンにはまっていたことから、名付けられたとかそうでないとか。
※ボツ案：PJTシリウス

短期と中期の目標

短期：Qastはまだまだ成長が著しいプロダクトであることから、既存機能のブラッシュアップ余地も多々あり、新規でのご契約やご継続の判断に響いてしまうこともしばしばあります。

中長期：テーマを決めてNSM¹ 向上のためのUX/UI、仕様などの改善を行なうことを目標にしています。
改善を進めるにあたり、作り手の視点を尊重しつつ、局所最適にとどまらない全体最適の観点から課題解決に取り組めるよう、基盤を整えていく予定です。

カイゼンの難しさ

短期で対応する改善案件は緊急度・重要度ともに高いケースがほとんどです。

しかし、プロダクト開発(特にホリゾンタルSaaS)においては一つの改善が全てのお客様の環境に反映されるため、多角的な視点でご要望を分析し仕様に落とし込む必要があります。
タイムラインが短い中で、今取り組む機能開発はアウトプットではなくアウトカムであるか、汎用的な機能に昇華できるか、他のお客様へのハレーションはないかなど情報を整理し案件を進める必要があります。

カイゼンプロセス(PdM/案件観点)

基本的にカイゼン案件の場合は次のようなプロセスで進めていきます。
今回はPdMが主に関与する部分をご紹介していきます。(もちろん実業務では実装中の議論や受け入れテスト、リリース計画なども行います)

1. ご要望に対するユーザー要求の仮説作り
2. ユーザーの要求に対するペインとゲインの仮説作り
3. 仮説に対する検証(ユーザーヒアリング)
4. 検証結果から改めてユーザー要求定義
5. プロダクトの思想、ドメイン領域との適合チェック
6. PRDや簡易ドキュメントの作成
7. カイゼンチームでの案件共有と実現可能性のディスカッション
8. システム要件定義
9. 以降、開発チームにて機能の仕様決め〜実装
10. 成果物の受け入れテスト、レビュー
11. リリース計画
12. リリース

1.ご要望に対するユーザー要求の仮説作り〜3.仮説に対する検証(ユーザーヒアリング)まで

お客様や社内からの要望は"要望"であるため、こうしたい！こうしてほしい！といったHowをいただく機会が多い印象です。具体のHowだけを解決しに行こうとすると、他のお客様へのハレーションやリリースしても使われない機能となり運用保守のコストだけ増加するリスクがあります。また、運用でカバーできるケースや他の機能で代替できるケースもあるので、要望の真因である"なぜ"を解剖していく必要があります。

解剖するプロセスではセールスやCSに協力を仰ぎ、お客様へ直接ヒアリングする機会をいただくことが多いので、お打ち合わせ時には必ず仮説を作ってから打ち合わせに臨んでいます。

仮説を持たない状態ではお客様とコンテキストが揃わず、いわゆるユーザー要求の引き出しと定義が困難になります。また、お客様の貴重な時間も無駄にしてしまう可能性もあります。そういった事態を事前に防ぐためにセールスが過去に商談した記録や企業情報のリサーチ、要望に対するユーザー要求の仮説を立ててからヒアリング当日を迎えます。

また、お客様の業務フローを可視化したい場合や課題が複雑は場合やモデルリングを一度するケースもあります。

Qastのタッチポイント整理

それぞれのユーザーレベルで行動フローの可視化

そして、実際のヒアリングではペライチのヒアリングシートにまとめ、ディスカッションベースでお話をお伺いしていきます。

※この時点で既存機能での代替提案や運用回避策も準備していきます。

※余談ですが要求/要件の話で個人的にお気に入りのポストがあるので貼っておきます。笑
引用：https://x.com/hrjn/status/1470957720711077888

4.検証結果から改めてユーザー要求定義

実際にヒアリングを終えると、お客様が困っていることや本当に実現したかったことの解像度が爆上がりしています。先に頂いているHowのご要望に捉われず、改めて問いを立て、ユーザー要求として定義を行っていきます。

Case：実際にあったケースで、投稿を降順に並べたい、とご要望を頂いたことがありました。
最初は投稿日時を基準にソートを行いたいものだと仮定していました。
(お客様もお話をお伺いした社内メンバーも含め)
しかしディスカッションを重ねていくうちにQastのユースケースを会議の議事録にフォーカスし、
投稿タイトルに「日付+定例名」のように記入し運用していることがわかりました。
実際に実現したかったことはタイトルを基準とした降順ソートだということが判明し、
ユーザー要求として再定義したケースがあります。

〜中間のプロセス割愛〜

7.カイゼンチームでの案件共有と実現可能性のディスカッション

ドキュメントの作成まで完了したら一度、チーム定例やSlackで共有を行います。
UI/UXデザインでの解決策やビジュアライズの会話、技術的な実現可能性の議論を行います。

PdMとしては原則、課題の問いを立てることに意識を置いています。
具体のソリューションも検討しますがそれだけを伝えてしまうと、社内受託のような関係性になってしまいますし、課題解決のプロフェッショナルであるデザイナーとエンジニアと対話を重ねることでチームとしてよりよいプロダクト開発ができると信じています。

※そもそもの前提に立ち返ったり建設的な議論が前向きにできるのもanyのプロダクトチームの魅力だったりもします。

↓これはデザイナーのYukiさんがある機能のデザイン改善に込めた熱い思い。
コミュニケーションもデザインも細部にこだわるデザイナーがいることで楽しくワクワクしたプロダクト開発ができています。(心も熱くなる!!)

PdMが感じるカイゼンチームの素晴らしさと尊さ

冒頭でもご紹介したYueさんの記事の通り、弊社のカイゼンチームはフレンズさんと呼ばれる業務委託の方を中心に構成されています。

フレンズさんでありながら、真摯にプロダクトに向き合いカイゼンに取り組んでいただいています。
一人一人がプロフェッショナルであり、立てた問いのそもそもから議論いただくこともあります。

また、月次のKPT振り返り会ではそれぞれの課題や打ち手を毎回多く出してくださったり、なんなら打ち手の叩きまで作ってくれたりします。

そういったプロフェッショナルなフレンズさんに支えられany、そしてQastというプロダクトは成り立っていることに改めて感謝とリスペクトをこの場を借りてお送りします。

DesignDocのトライアル提案もフレンズさんから!!!

おわりに

今回はPdM視点でカイゼンのプロセスについて紹介しましたが、チームにフォーカスした話やチーム活動についても別の機会に執筆したいと思います！

PdMチームとしての対談noteもany公式から公開予定なのでそちらもぜひチェックしていただけると嬉しいです。

最後に、弊社に興味を持っていただいた方、ぜひカジュアルにお話ししませんか？Twitter(新:X)のDMにご連絡頂いても構いません。

ご飯でもポケポケでもなんでもお待ちしています。
1mmでも興味がある方は私が惜しみなく質問に答える会も開催しております。

1. 一般的なNSMとは：https://productzine.jp/article/detail/67 ↩