estieの開発チームは、ビジネスメンバーと共に価値創出する

こんにちは。t-poyoです。

不動産データの分析アプリケーションである estie pro を開発しています。

estieではエンジニアメンバーが開発業務に加えて採用活動もおこなっているため、私自身もカジュアル面談や面接等で、estieに興味を持っていただいている候補者の方々とお話させていただく機会が多いです。

そういった中で、候補者の方々に「ほぼ毎回聞かれる」ご質問があります。それは…

「開発チームはビジネスメンバーとどう連携しているの?」

本当によく聞かれます。

不動産は歴史も長く、一見「営業力がモノを言いそう」な業界ですよね。そういった業界へ向けてサービス開発をしていることもあり、プロダクト開発サイドとビジネスサイドの関係性、距離感、あるいは力関係については多くの方々が気にされるようです。

本記事ではそういった疑問を解消し、またestieの開発プロセスについて知っていただくべく、「開発チームとビジネスメンバーの関係性」についてご説明していきたいと思います。

チーム構成

まず、現在のestieのチーム構成を組織図と合わせてご紹介します。

ご覧のように、まずプロダクトや事業といったグルーピングがされ、その下に役割に応じて人が集まるという構図になっています。よくある職種による一括のグルーピング(「CTO配下の開発部門」「COO配下の営業部門」など)は行われていません。

従って、構造的にも開発チーム以外のビジネスメンバーとも非常に距離が近いです。例えば以下のような活動が自由に、かつ頻繁におこなわれています。

  • KPIで使うヘルススコアの設計について議論する
  • 一緒にお客様との定例に出て、新機能のモックアップをお見せする
  • エンジニアがSQL勉強会を開催し、事業開発(CS)メンバーが学ぶ
  • 事業開発メンバーがお客様の業務や課題について勉強会を開催し、エンジニアが学ぶ

開発プロセス

お客さまからの要望の整理

estie proは、toB SaaSであり、お客様はビルの貸主や資産運用会社などです。

事業開発メンバーは営業から始まり成約後のオンボーディング、定例会など、同期的にお客様からご意見・ご要望をいただく機会が多いです。

最短距離でお客様にとっての価値を作るサービス開発のために、ログなどの定量的な指標と合わせて、定例会などでいただける定性的な声も非常に重要になってきます。

そういったお客様の声を開発メンバー/事業開発メンバー間でスムーズに連携するために、Flyleというサービスを利用しています。Flyleは、端的に言うと「フィードバック管理・集約ツール」です。

次世代プロダクトマネジメントプラットフォーム|Flyle(フライル)

実際のFlyle画面

事業開発メンバーが主体となって、「商談でお客様からいただいたフィードバック」「事業開発メンバー自身が日常的にサービスを触っていて感じたことや気づき」などを入力してもらい、蓄積・分類整理をおこなっています。

各商談の議事録まで辿れるようリンクされているため、そのご意見がどういった業務のどういったシーンで感じられたことなのかまで追えるようになっています。

これらの記録は、実際のサービス開発の以下のようなシーンで活用しています。

  • VOC(Voice Of Customer)会での同期的な議論(後述)
  • 開発チケットの優先順位づけにおける定量的指標
  • 開発チームで課題仮説をブレインストーミングする際の参考情報 など

ちなみに先日、自分の所属するチームのPdM田中陸がFlyle様のイベントに登壇させていただき、開発チケットの優先順位づけにFlyleを活用する様子をお話させていただきました。

急成長の裏側で、プロダクトマネージャーはどんな機能開発の優先度づけをしてきたか?(イベントレポート)

VOC(Voice Of Customer)レビュー

Flyle上での非同期的な連携だけではなく、開発メンバーと事業開発メンバーが集まって同期的な議論をおこなう場もあります。それが「VOCレビュー」です。

現在は2週間に1回程度開催され、設定されたトピックに興味のあるメンバーが集まります。トピックはPOが事前に選定します。Flyleで投稿が多い領域や、注視しているお客様の課題が選ばれます。

基本的には以下のような流れで1時間のミーティングをおこないます。

No. agenda 発言例
1 POが課題仮説をざっくり提示 「物件リスト」を整理したいという要望が多いので、取り上げたいと思います。
2 関連するVOC(Flyle内のデータ)を事業開発メンバーが詳しく説明 〜株式会社の〜様が「xxx」とおっしゃっていた。oooの業務の中で、△△△と感じられているようだ。
3 開発メンバーを含む参加者からどんどん質問する そもそもなぜ整理したいのか?既にある検索機能が使えないのははぜか?
「特定の物件リストを早く見たい」ということではないか?
4 仮説を磨き、全員が確信を持てる状態にする お客様は「よく見る物件リストをすぐ閲覧できるようになることで、業務効率を上げたい」と感じているようだ。

上記に「発言例」も載せましたが、これは実際にあったVOCレビューを元にしており、この回でまとめられた課題仮説は実際に「ピン留め機能」として開発され、リリースがおこなわれました。

閲覧頻度の高い物件リストを上部に固定できる

VOCレビューで磨かれる仮説は全員の納得感と解像度が高いため開発がスムーズで、仮説としての確度も高いため、個人的にも非常にお気に入りのミーティングの一つです。

まとめ

以上、estieでの開発チームとビジネスメンバーの関係性についてご紹介してきました。まとめると「異なるのは役割(職種)だけであり、対等な目線で事業とお客様に向き合える」関係性であり、その上でさまざまなプロセスが営まれているなと感じております。

エンジニアとして働く上で、「言われたものを作るだけの開発体制は嫌だ」「ユーザーの課題にできるだけ深く向き合いたい」ということは多くの方々が志向されることかと思いますが、estieではこういった組織作りやプロセス作りで全メンバーのアウトプットを最大化できるよう、日々尽力しています。

応募お待ちしております

気になった方はぜひカジュアル面談しましょう!

hrmos.co

© 2019- estie, inc.