見出し画像

レガシー産業のSaaSにおける顧客理解には、“データフロー観察”が効果的?

Shippio Director of Product の西藤です。(X: K_Nishito
今回のテーマは、「レガシー産業のSaaSにおける顧客理解」の手法について。
プロダクトづくりに欠かせない「顧客理解」。私自身キャリアを通じて、このテーマにずっと向き合ってきました。
Shippioでは、セールス・CSがプロダクトメンバーを商談に巻き込んでくれたり、情報を棚卸ししてくれたり、動画を見せてくれたり、ドメインエキスパートに話を聞けたり、顧客理解を進める環境がとても整っています。
が、それでも、レガシー産業においてこれまで先人が工夫し続け・蓄積してきた業務を解きほぐしていくことはいつまでたっても難しいよなーと感じています(贅沢ですね、すみません)。
そんな中、「データフロー」を観察することでお客さんの解像度が圧倒的に上がったな、と感じることがあったのでその話を紹介させてください。

データフロー観察とは?

「データのフロー」とは平たく言うと、各社が業務で活用しているエクセルの内容を、項目単位で、誰がなんのために・いつ・どうやって・どんな背景で管理しているかを理解することです。

利用されているエクセルイメージ

現状業務で使われているエクセルには様々な物語があり、過去いろんな蓄積を経て最適に作られたもの。ここには「顧客の業務を理解するヒント」が数多く散りばめられています。
アクション単位で理解していく”業務フロー”とも近いですが、更に「データ単位」で理解していくことで、さらなる理解に繋がっていくという意図です。

データフロー観察のメリット

データフローの観察には下記のようなメリットがあります。たくさんあるのですが4つほど紹介させてください。

① 業務解像度が圧倒的に上がる

これは上で伝えているとおりですがもう少し丁寧に言語化してみます。
管理エクセルは多くの利用者間で共有されたり、異なる時間軸で情報が集まってくるストック情報です。1項目1項目に、あらゆる業務に必要な情報が、異なる時間軸で記録されていきます。
そのロジックをたどると、例えば下記のような内容が理解できます。

  • 「XXX部署とYYY部署で、情報の管理する単位が異なっている、なぜならxxxx」

  • 「XXXという情報がYYYという情報を参照するためのキー情報である」

  • 「XXXとYYYの情報には依存関係があり、XXXが定まらない限りは管理を始められない」

  • 「XXX情報は集計してマネジメントに伝える必要がある」


② 解像度を上げるためのヒアリング時間が短くなる

お客様の業務を理解したい…とは思いつつ、toCサービスのようにヒアリング対象がたくさん存在するわけでもなく、かつお客様の貴重なお時間なので長時間拘束するのは申し訳ない、と感じるケースはないでしょうか?
そんななか、事前にデータをきちんと見る / あとでデータを見返すことで理解が進むため、0-100までお客様から時間を頂く必要がなくなります。

③「リアリティのある現場」を行動ベースで理解できる

また、ヒアリングを行うのみだとやや表面をなぞったような質問しかできず、本当の意味で業務を理解することは難しい、ということもよくあります。現場にけば現場感はわかるが、いつでもできる方法ではない。
そんな中で「実際に活用されているモノ・コミュニケーション」をベースに業務を観察できることは、「リアリティ」という意味でも非常に役に立ちます。

④ 管理者が見たいデータと、現場利用するデータとの接続がわかる

お客様のデータの中で、「マネジメントへのレポート」に使っている情報へのつながりが分かることも非常に有意義です。現場で生み出される情報〜マネジメントにレポートされる情報を一貫して見ることができれば、「ユーザの業務」から「事業部の関心」に接合することが可能になり、それらは(もちろん完全ではない前提で)決裁者へのコミュニケーションでも活用が可能になります。

データフローを見た際の気づき例

例えばデータフローの理解を通じて、

  • 当初検討していた仕様が、実際の業務フローに沿っていないケースがあることがわかった。(複数回の接触の中で情報をアップデートしていく機能を考えていたが、特定の項目が定義される順序が検討していた仕様と異なっていたため、深掘りのきっかけとなった)

  • お客様の管理番号の採番ルールが未整備な事に気づき、採番ルールを定義することでプロダクトのスムーズな利用促進に繋がった

  • 当初想定していなかったオブジェクトにIDが振られており、それらの管理自体がその部署のミッションに含まれていることが理解できた

  • 完璧な情報を揃えるのが難しかったが、現場ではかなりラフなロジックで算出するケースがほとんどだったため「理想案ではないが、現状よりも良くなる1歩目としてのMVPスコープが定義できた

などなど、一部の情報を見るだけでも上記のような発見がありました。

データフロー観察で、"ソフトウェア以上の体験"をデザインする

データフローを見ると、「自分たちのプロダクトが、顧客の業務におけるどこからどこを対象にしているのか」を俯瞰的に把握できます。(それでもまだまだ一部ですが…)
それによってデザインの対象が「ソフトウェア」ではなく、「顧客の業務」になります。
近い考え方の会社も多いと思うのですが、Shippioにおけるデザイナーの役割は「User outcome」を創出すること。その1歩目は「代替手段を知ること」だと思っているので、データフロー観察流行るといいな、と思っています。
もちろんエクセルが常に用意されているわけではないので、時には紙であり、付箋であり、ファイルであるわけなのですが、顧客が業務の根幹で取り扱っている「ストック情報」がどのようなストーリーで成り立っているかを理解することが(オブジェクトを紐解いていくことが)、深い顧客理解に繋がっていくと思っています。

おまけ

Shippioのプロダクトチームは、プロダクトマネージャー + プロダクトデザイナーで構成されています。プロダクトマネージャーは「WHY」に、プロダクトデザイナーは「WHAT」に責任を持ちますが、両方とも「プロダクトに寄る顧客の課題解決を事業成長に繋げていく」というスタンスは変わりません。

Shippio Product Teamでの役割定義概要

もっともっと顧客に深く入り込んでいきたいし、より良い解決策を模索していきたい。それにより業界をより良くしていくことにチャレンジをしていきたい。
そんな複雑でおもしろい領域のプロダクトマネージャー・プロダクトデザイナーに興味はありませんか?

下記より、お気軽にカジュアル面談へのお申し込みをお待ちしております!


いいなと思ったら応援しよう!