ビジネスチームと一緒に作るプロダクト開発

本記事は Calendar for estie Advent Calendar 2021 | Advent Calendar 2021 - Qiita 22日目の記事です。

estieでPdMをしておりますゆーぶんです。前回はVOCについて記事を書かせていただきました！

▼まだの方はこちら

VOC（Voice of Customer）でプロダクトマネジメントを強くする - estie inside blog

今回はestieにおける開発チームとビジネスチームの連携をしている仕組みのテンプレートを紹介していきたいと思います。下記のような方の参考になれば幸いです。

顧客の声に沿ったロードマップ策定の難易度の高さに悩まれている経営陣/PdMの方
機能リリースした機能がなかなか利用されないと悩んでいるPdM/エンジニアの方
なかなか顧客の声が開発チームに伝わらないなと感じるCSの方

前回のVOCでの記事でも触れたとおり、estieでは顧客を中心として開発チームはロードマップを策定し、ビジネスチームはカスタマーサクセス方針を固めています。

上記を最速で推進するに当たり、開発ロードマップとカスタマーサクセス方針が一致することが重要となってきます。

両者が蜜に同期することで、リリースした機能が即座に顧客にデリバリーされフィードバックサイクルが早まり、開発ロードマップに基づいたカスタマーサクセスを実施することでチャーンリスクの軽減が達成できます。

当たり前じゃんと思いますが当たり前が故に難易度は高く、意識するだけではなかなか改善されないのが現状です。

そこでestieで実践した3つの仕組みを紹介致します。

そもそもなぜ開発チームとビジネスチームの連携が難しいのか

開発チームとビジネスチームのコミュニケーションは実は難しいです。。。

理由を個人的に考えてみたのですが主に以下かと分析しました。

ビジネス → 開発

開発工数等がわからないため必要以上に多く開発工数を見積り、遠慮がちに聞いてしまい本当に聞きたかったことが聞けない
UIのちょっとした使い勝手の顧客要望であり、頼んだところでインパクトあるのかと聞かれるとそうでもないと判断してしまい、そもそも開発にフィードバックしない
口頭でサクッと伝えたいくらいの軽さの相談だが、エンジニアがそもそもリモートが多く気軽に相談できない

開発 → ビジネス

開発メンバーはビジネスチームリスペクトが高い傾向にあり、気軽に話せる相手と認識しづらい
ビジネスチームへのリスペクトが強いゆえに、発言のインパクトを必要以上に大きく捉えてしまう
メイン業務の実装に脳のリソースの大部分が割かれており、なかなかビジネス系の情報をとるコストが高い

コミュニケーション難易度の高さの原因は、主にお互いを尊重するあまり発生するという、ある意味美しく非常にもったいない理由ばかりかなと思います。

こういうときこそドキュメントという情が湧きにくいツールの出番です。

お互いに聞きたい情報、伝えたい情報が満足度高くやり取りされるように、下記項目で紹介するテンプレートを用意しました。

開発 <> ビジネス連携のドキュメントのテンプレート公開

早速テンプレートを紹介します！（弊社では下記のテンプレートをconfluenceで運用しております）

各セルの内容は例になります

リリース週	チケット	紐づく仮説	想定される顧客体験	検証方法	アピールポイント
12/13	表示しているグラフの画像吐き出し機能（※該当するJIRAチケット）	綺麗な画像が吐き出されることによって、社内資料に活用される	資料作成時のデータ処理が自動化され、資料作成のクオリティが上がる	画像吐き出し回数	今までスクショで貼ってくださっていたお客さんがよりestie proを業務のコアに使えるようにと頑張りました！

リリース週

該当機能がリリースされる週を記載。

ビジネスチームが知りたいのはいつ何がリリースされるのかというポイント。

これにより顧客定例でのコミュニケーション方針が決まったり、機能のオンボーディング準備が決まるので結構重要だと思います。

一方で現状のestieの開発体制だと日にちまでなかなか約束できないため、週で丸めることで差分なく情報共有しております。（来年は日にちを記載できるようにする！）

チケット

開発の状況がみれたり、細かな仕様の記載。

でも実際にビジネスチームはそこまで細かいことまでは、あれば嬉しいくらいなのでそこまで重要ではないです。

紐づく仮説

なぜこの開発に取り組んだかの仮説の記載。

これがあると開発チームが知りたい"Why"の部分について、顧客に最も近いCSメンバーからのレビューがもらえたり、実際に顧客にヒアリングできたりします。

estieではセットでfigmaのデザインを共有し、実際にUIのイメージを解像度高い状態で仮説を相互レビューすることでより顧客価値の高い方向に修正していっております。

想定される顧客体験

デザイナー中心に開発チームで考えた想定される顧客の行動を記載。

ビジネスチームに対し、なぜこの機能なのか/このUIなのかを共有することで、UIの微修正や顧客オンボーディングイメージを高めることが目的手です。

検証方法

機能仮説をどう検証するかを記載。

開発チームがどう検証したいかを伝え、オンボーディング時の操作方法についてすり合わせを行い、仮説の検証をスムーズにし改善スピードを上げることが目的となります。

アピールポイント

開発チームからの思いを記載。

実装がどれくらい大変なのかの肌感をビジネスチームに伝わると、コミュニケーションがしやすくなるという私の仮説。

開発チームとしても頑張りを伝えることで、連携のソフト面での強化を狙っているので、実務上関係なさそうに見えて実は必須なんじゃないかと思います。

運用については、PdMが上記シートに週次で記載し、週1回15分アカウントマネージャー（CS）とテンプレートに従い共有し、意見をもらっております。

上記のテンプレートを活用した運用のリターンについて次章で触れていきます。

開発とビジネスの連携を強固にすることで得たリターン

開発とビジネスの連携は強ければいいというのは直感的に感じると思いますが、実務としてどういうリターンがあったのかを説明していきたいと思います。

①機能仮説の質が上がり、開発ロードマップと機能要件が精緻になる

本運用により、必然的にロードマップや機能についてレビューされる回数が増えるため、内容がどんどん濃密になっていきます。

今までのやり方だと仕様はPdMが考え、エンジニアによる仕様的な要件を詰めるにとどまっていましたが、”紐づく仮説”をもとに議論することでビジネス観点や顧客観点からのレビューがされ、思考を施行する回数が増えるためにUIがかなり洗練されます。

最近では併せてfigmaをみせることでビジネスメンバーでも機能をイメージしやすくし、対等な立場で議論できる工夫もしております。

②機能リリースから顧客に使われるまでのスピードが上がる

本運用により、リリース時点と機能の利用ログが伸びる時点の差分が小さくなりました。

背景としては、基本的に月1回の頻度で開催される顧客定例において実施していた機能アップデート共有フローを、リリース後すぐに機能アップデート資料を整備してメール配信するフローに移行できたことになります。

今までも機能リリース後に資料展開をしたほうがいいとは社内で何度か議題に上がったこともあり、実際に何度かトライしていたのですがなかなか運用できなかったというのが結果でした。

理由としては主に下記の理由です。

顧客へ展開しようにも、開発スケジュールがわからずリリースされてからの資料作成になるために、結局顧客定例時期と変わらなくなる
機能リリースしたのはわかっても開発背景が見にくく、またどう使ってほしいかもわからないために、ビジネスチームメンバーも資料作成コストが高い

上記の課題において、テンプレートにある”リリース週”を共有することで事前に資料作成準備ができ、”想定される顧客体験”によって資料作成コストが下がり、”チケット”で資料作成に必要な細かな仕様を把握できるため、運用確立できたのではないかと思います。

本運用により、顧客への機能デリバリーが早まり、フィードバックも早まるために改善速度も上がりました！

③プレスリリースにつながる機能の察知が早まり、マーケティング施策につながる

PdMとしてビジネスインパクトは測定した上で実装に入りますが、マーケティング施策までは手が回っていない状況でした。

この運用を回すことで、マーケティング施策的にプレスリリースを打つことで新規リード獲得ができるかどうかの判断が可能となり、実際にプレスリリースやキャンペーンといったマーケティング施策を打つことができました。

▼estie proのリリース例

prtimes.jp

▼estie proのキャンペーン例（キャンペーン自体は終了しております）

【メディア掲載】
今月はプロパティマネジメント会社特集です！

プロパティマネジメント会社様の利用も増えていることから、estie proをアセットタイプ別注目サービスとして紹介いただきました。

ただいま期間限定キャンペーン中なので、ぜひご検討ください✨https://t.co/mgqs2S5ftN pic.twitter.com/S1gn72I4rW
— 株式会社estie(エスティ) (@estie_corp) 2021年11月2日