SHOEISHA iD

※旧SEメンバーシップ会員の方は、同じ登録情報(メールアドレス&パスワード)でログインいただけます

CodeZine編集部では、現場で活躍するデベロッパーをスターにするためのカンファレンス「Developers Summit」や、エンジニアの生きざまをブーストするためのイベント「Developers Boost」など、さまざまなカンファレンスを企画・運営しています。

Developers Summit 2022 レポート(AD)

プロダクトマネージャーが大切にしたい「開発者視点のROI」とは?【デブサミ2022】

【17-B-8】開発者視点のBtoBプロダクトマネジメント実践論 ~エンジニアが高い顧客解像度を持つ事で高まる機能開発のROI~

  • X ポスト
  • このエントリーをはてなブックマークに追加

ROIの高いプロダクト開発を実現するには?

 続いて荒井氏は、ROIの低い開発と高い開発の違いをより鮮明に伝えるべく、自身が過去に経験した失敗談と成功談を紹介した。

 まずは失敗談から見ていこう。Flyleには、顧客のフィードバックと顧客情報をひもづける機能がある。その機能に対し、Flyleの利用者から「Salesforceの顧客情報をFlyleに自動で連携させたい」という要望が多く寄せられていた。

 そこで、「条件に合致するSalesforce上の取引先/商談情報を“リアルタイムで”Flyleに同期できるようにしよう」と荒井氏は考えた。しかし、いざふたを開けてみると、Flyleの利用者が求めていたのは、あくまでも自動で連携することであり、そこにリアルタイム性は求められていなかった。その結果、想定よりも多くの技術調査や設計の工数をかけてしまった。

 そこには顧客と開発者の認識のズレがあった。「何を実現すべきなのかを深掘りせずに、『リアルタイムでデータを取り込む必要があるだろう』と、思い込みで進めてしまった。開発者は自分で作れてしまうからこそ、オーバースペックな機能開発に陥りがちだ」(荒井氏)

 一方、成功談はどのように生まれたのか。FlyleのSlack連携機能を開発したときのことだ。「Slackに投稿された顧客のフィードバックをFlyleに飛ばしたい」という要望があった。当該の顧客の業務フローをしっかりと理解できていたことから、「取りあえず任意のSlack投稿をFlyleに飛ばせるだけで良さそうだ」と判断した。結果、顧客が求める最小要件でリリースした後、実際に使ってもらった上でフィードバックをもらい、継続的に改善するという理想の形につながった。

 「人は満足したときよりも、不満がある時のほうが、具体的な要望を語ることができる。多少、作り込みが甘かったとしても、実際に使ってもらってから得られるフィードバックを活用して、徐々に顧客が満足する要件に近づけるアプローチのほうが、トータルのコストを下げられると考えている」(荒井氏)

 そんなフライルでは、顧客の解像度を上げるための取り組みとして、「顧客フィードバックデータベース」を運用しながら、日々の機能開発に活かしている。ここには、顧客と接点をもつビジネス部門によって「どの顧客セグメントの」「どの顧客が」「どんな業務中に」「何に困っていて」「どんな要望を話していたか」といったデータが蓄積されている。

 プロダクトマネージャーである荒井氏が、これらの蓄積された「顧客の声」を参照することで、表面的な顧客の要望だけでなく、要望の背景にある顧客の課題まで知ることができる。結果として、顧客のニーズを満たすソリューションを素早く、精度高く企画立案することができるのだ。

 この顧客フィードバックデータベースのポイントは、“フィードバックの発言者が特定されている点”だ。発言者が不明なフィードバックは、発言の背景を理解できないため基本的には扱わない。また「文面だけでは正確な情報をつかみきれず、顧客に直接ヒアリングして、より深掘りしたいケースが出てくる。その際に、発言者が特定されていることで、ユーザーインタビューのリクルーティングがとても容易になる」と荒井氏は明かす。

 そして、この仕組みを回すには、フィードバックを蓄積する仕組みの他にビジネスチームの協力を得て、顧客からフィードバックを収集するというプロセスが欠かせない。そのためには、売上の創出と顧客の成功には、エンジニア・プロダクトマネージャー・デザイナーが担う「製品力」と、セールス・カスタマーサクセス・マーケティングが担う「コミュニケーション力」の掛け算が重要であると組織全体で理解しておく必要があるという。

 荒井氏は、ビジネス部門からフィードバックを集めるための取り組みとして、次の4つのステップを示した。

  • Step1:ビジネス部門からフィードバックを上げる場(ツール)を用意する
  • Step2:内容の良しあしに関係なく、フィードバックを伝えてくれたことに感謝する&リアクションする
  • Step3:書き方や内容が良いフィードバックをお手本として取り上げ、注目を集める
  • Step4:リリースした機能の参考になったことをフィードバックする

 「ツールやフレームワークを導入したからといって、いきなりフィードバックの文化ができあがるわけではない。地道な意識づけと改善、そして時にはトップの意思決定が必要だ。一度仕組みが出来上がってしまえば、全社で顧客のニーズに向き合い、継続的に『顧客に喜ばれる機能』を提供できるはず」(荒井氏)

この記事は参考になりましたか?

  • X ポスト
  • このエントリーをはてなブックマークに追加
Developers Summit 2022 レポート連載記事一覧

もっと読む

この記事の著者

野本 纏花(ノモト マドカ)

 フリーライター。IT系企業のマーケティング担当を経て2010年8月からMarkeZine(翔泳社)にてライター業を開始。2011年1月からWriting&Marketing Company 518Lab(コトバラボ)として独立。共著に『ひとつ上のFacebookマネジメント術~情報収集・人脈づくり...

※プロフィールは、執筆時点、または直近の記事の寄稿時点での内容です

【AD】本記事の内容は記事掲載開始時点のものです 企画・制作 株式会社翔泳社

この記事は参考になりましたか?

この記事をシェア

  • X ポスト
  • このエントリーをはてなブックマークに追加
CodeZine(コードジン)
https://codezine.jp/article/detail/15702 2022/04/15 12:00

おすすめ

アクセスランキング

アクセスランキング

イベント

CodeZine編集部では、現場で活躍するデベロッパーをスターにするためのカンファレンス「Developers Summit」や、エンジニアの生きざまをブーストするためのイベント「Developers Boost」など、さまざまなカンファレンスを企画・運営しています。

新規会員登録無料のご案内

  • ・全ての過去記事が閲覧できます
  • ・会員限定メルマガを受信できます

メールバックナンバー

アクセスランキング

アクセスランキング