顧客の声や現場の要望をどのように開発に反映させているか

 

 

ご覧いただきありがとうございます。
クロスマート株式会社でプロダクトマネージャー(以下、PM)を
務めております杉原(@sugihara_xmart)です。

最近話題のスプラ3を購入しましたがエイムが下手すぎて絶望しているこの頃です。
エイム力を上げないことにはうまくなれないとYouTubeの数多の動画に触発され
イカバルーン相手に基礎トレを実施しようかと画策中です。
もう少し世間に顔向けできる実力になりましたらぜひ対戦お願いします。

営業出身のPMでコードを書いた経験がほとんどありません

社会人的な自己紹介としては、ずっと営業周りのキャリアでしたが、
紆余曲折あってプロダクトマネージャーに転向し、2年ほど経過しました。

今回テックブログではありますが、営業出身PM目線で開発に関連する発信ができないかと考え、
「顧客の声や現場の要望をどのように開発に反映させているか」というテーマで記事を書かせていただこうと思います。

想定読者

  • 上流から要求だけ降ってきて顧客の顔が見えづらい環境で業務をされている転職活動中のエンジニアの方
  • 自社サービス・SaaSどんなプロダクト開発のプロセスをしているか、その生々しい実態に興味がある方
  • クロスマートの選考プロセス中で、どんな雰囲気で日頃やりとりをしているかの手触り感を掴みたい方

免責事項

  • 就活時代のインターン以外でほとんどコードを書いたことのない人間がテックブログを書いています。
    今までの記事とテイストがかなり異なることを何卒ご容赦ください。
  • 本記事では「Flyle(フライル)」というツールをめちゃめちゃポジティブに語ってますが、PR記事ではありません
    ただ杉原個人がロイヤルユーザーで、好きなプロダクトというのみです。この手のツールをめちゃくちゃ比較検討したというわけでもないので、その点ご容赦ください。
  • また本記事の内容は6月に行われた「Flyle」のユーザー会で話した内容を利活用しています。一層PR感がすごく感じるかもしれませんが、あくまで伝えたいことは「顧客の声や現場の声をどう開発に活かしているか」なのでその点もご承知おきください。
  • 現在クロスマートはプロダクトチーム13名(業務委託含む)なのでそれくらいの規模のチームの話と思って聞いていただけると幸いです。

事業全体で約30名弱の組織

抱えていた課題と導入した「Flyle」というツール

当初はGoogleSpreadSheetにまとめていましたが、形骸化していました

1年半ほど前なのでまだチームが上記の半分(6~7名)くらいのときでしたが、
徐々に顧客の声が遠のいていくのを課題に感じていました。

GoogleSpreadsheet(以下、GSS)に要望を記入してもらっていましたが、
そもそもGSSを開いて記入する作業そのものが営業・CSメンバーからするとハードルがあったり記入する粒度感がばらばらだったり、記入している改善策も扱われる機会は月に一回あればいい方で、たまに時間が空いたときに着手するという使い方で鮮度が下がったりと、運用が形骸化していました。

PJT化して改めて企画を進めていくにも、そもそも顧客要望が可視化・整理されていない状態からなのでせっかくのGSSの情報も有効活用されない、非常に微妙な顧客の声の扱われ方でした。そのような中で「Flyle」という顧客と製品のフィードバックループを構築するツールと出会い、導入するに至りました。

現在の機能開発の流れ

「Flyle」を顧客の生声DBにし、要望を説明する会を起点に

そういった機能開発の状況から1年半経った今は、概ね上記のような流れで開発を進めています。左から右に流れていくような形ですが、スライド右上に「心のバックログ」なる「実はこう改善したい」という思いや、自身がプロダクトを利用していての気付き、日々お客様とやりとりする中で生まれてくる改善要望などがあり、これらを「Flyle」に収集します。

現在は週2回、ビジネス・プロダクト双方のメンバーが参加する「Flyle定例」があり、そこでビジネスメンバーが要望の背景を説明し、やるべきか様子見をするか、やるべきな場合PJT化する(粒度が大きいもの)か、カイゼンタスクにする(粒度に小さいもの)かを大枠割り振りを実施しています。

PJT化するべきものに関しては、経営陣と月一回開催している「ロードマップ揉む会」という会でPJT優先度のチューニングを実施し、経営戦略・プロダクト戦略の接続を実施します。

直近扱うべきPJTに関してはPJT発足と定例を設置し、仕様詰め・チケット作成をし、以降はスクラム開発(現状2週間のスプリントで実施中)の流れで推進をしていく、そんな進め方になっています。

もちろん(株主との共同事業など)経営戦略・プロダクト戦略が比重を多く占めるPJTもありますが、大半のPJTはこうした「Flyle」に蓄積された「顧客の生声DB」を存分に参考にしつつ企画が進むのが現状のプロダクト開発の特徴かな、と考えています。

具体的な1週間の流れ

Slackに直接記入し、Flyleに連携しています

具体的な1週間の流れをチラ見せすると、上記のような形でいろんな職種・役割の人がSlackの指定チャンネルに要望を書き込みます。

現状のフォーマットは

■ 対象
■ 事実
■ 解釈

という非常にシンプルなフォーマットで最低限、顧客が言ったこと・事実として発生していることと、それを聞いた投稿者の解釈を分けて記入してもらっています。

記入してもらった情報はSlack連携でできるので、現場メンバーは「Flyle」にログインすることなく、要望をツールに蓄積することが出来ます。

この連携時に温度感を高・中・低 の3つに分けて投稿してもらうようにして、要望をさばく優先度の参考にしています。

起票者の温度感と内容を見て大枠の優先度をつけます

その後、週2回の定例に向け事前の確認をします。
主に定例では温度感高を確実に扱い、温度感中以降は余った時間に可能な限り見るような形で扱っています。

事前に起票者に準備してもらうためにも「お品書き」と称して事前に扱う一覧のキャプチャを展開するようにしています。

ビジネス・プロダクトチームが同じ場で要望を説明

そして30分×週2でのFlyle定例です。
要望は、よほどのバグでなければ差し込み対応することは稀なので、

  • (現状進んでいるPJTがあれば)その進捗共有
  • 類似機能の開発状況や運用回避のTIPS
  • 開発者目線での難易度共有や工数の所感
  • 開発を進める上でのユースケースや考慮事項のヒアリングすべき項目

などを共有することで顧客への一次回答や追加ヒアリングの初速を早めるようにしています。

要望はチケットに紐付けてJIRAへ連携

会議が終了すると定期的に、ソリューションに紐付けを実施します。
すぐに対応せず、様子見にすると決めた要望も、要望の数によっては優先度を変更することもあるため原則的にはすべてのチケットをソリューションに紐づけて管理をしています。

またこのソリューションをJIRAの新規チケット作成 または 既存チケットとの紐付けをすることができるので、JIRA上でのステータスがどうなっているかも一覧で確認することができるようになっています。

リリース完了したものはSlackにて起票者に連絡

そうしてチケットが進んでいき、リリースされたあとには本番環境での動作確認後、起票されたSlack投稿に「リリースされましたよ〜」と連絡をするようにしています。

2桁を超える起票だとかなりの通知数になるのですが、それだけ期待が大きかった機能だということでやや過剰めでも伝えることを優先して通知しています。

自分が思っている以上に伝えているつもりのものも伝わっていないことがあるので、キアコン(気合と根性)が必要な作業ではありますが、意識的に実施しています。

投稿数ランキングとFlyle起点の改善チケットの消化具合を定例で報告

そして週次の定例での共有です。
顧客ドリブンなプロダクト開発を推進していく上でも、要望を起票することは非常に重要な文化です。
その労力を割いていただけることが素晴らしいことだ!というメッセージが届くよう、
投稿数のランキングと頂いた要望の中でその週時点での着手中とリリース済のチケットの一覧を全社に共有するようにしています。

運用してみての

顧客に向き合う時間としてプロダクトチームからも好評な場に

このような取り組みを経て導入半年時点での定例メンバーからの声の抜粋です。

・要望をサクッと記載できること(手間が少ない)
・↑のおかげで細かい要望を出すときも心理的なハードルが低い
・flyle MTGのおかげで、エンジニア視点での意見やシステムの構造について知る機会になる

by CSメンバー

エンジニア視点だと「どうしてこのタスクを作業しているんだっけ?」という背景を知れるという点で良い。 何か問題がありそうだと感じた際に、相談や改善案の提示、アラートを上げる為の事前情報として「とりあえずFlyleを見よう」という形で活用出来る。 こういう場が無いとエンジニアは「全てのSlackメッセージから該当の要望を探す」為の工数を割かれたり、「言われた物を言われた通りに作る」だけになってしまうので、それが起こりづらくなったのは大進歩

by エンジニアメンバー

slackを追わなくても顧客やCSの要望をまとめてみれる。
普段は目先の開発タスクでいっぱいなので、
定期的なflyle MTGが、顧客のことを考えるいい機会になっている。

by エンジニアメンバー

と概ね前向きな声をいただいています。

こうした顧客の声を開発に活かす体制が魅力的に感じ、クロスマートへの入社を決めてくださったメンバーもいて、採用にもポジティブサプライズがあったなあ〜という気持ちです。

まとめ

  • Flyle運用はPMの「キアコン(気合と根性)」が必要な部分も多い🔥
  • 要望を説明し、背景がわかることでエンジニアが納得感をもって開発に従事できる(採用にも好影響🙆)
  • 運用は会議体とセットで⏰
    Bizチームとプロダクトチームが顧客に向き合う時間になる
  • 起票者が損しないポジティブフィードバックが廻る運用を🎉

 

以上です。

まだまだこれが完成形とは思っていませんが、
これからも顧客の声や現場の要望を活かしながらプロダクト開発を推進していく姿勢は変えずに実施して行きたく、そのためのメンバーを募集しています。

このお話を読んでちょっとでも気になった方がいたら以下も覗いてみてください

xorder.notion.site

 

おまけ

発表当時の資料も展開しておきますので、よければご参考に。

speakerdeck.com