Airtableでプロダクトの要望管理を仕組化した話
※この記事は、【2022 春 LayerX Advent Calendar(概念) 】39日目の記事です。前回はマーケティング（MK）チームのitoさんの記事でした。次回は、Fintech事業部のtakochuuさんの記事です！お楽しみに〜！
はじめまして。LayerXのSaaS事業部でPMをやっておりますnumashi（@numashi_Biz）と申します。
このnoteでは、PMをはじめて2か月間で取り組んだ内容のうち、プロダクトの要望管理を仕組化したことについてまとめました。
3行で自己紹介
PM始めて2.5か月、それ以前のキャリアはハードウェアエンジニア3年 BizDev2年です
ソフトウェアエンジニアではないのでコード書けません
ゼスプリキウイブラザーズが好きです。社内では本名よりもキウイって呼ばれることの方が多いかもしれません
そのほかの詳しい自己紹介はこちらです。主にLayerX入社してから3か月の話を書いています。
なぜこのnote書こうと思ったか
LayerXでは、プロダクト開発に関する投稿がいくつかありましたが、
①そういえば要望管理に関する話ってなかったなと思った
②LayerXでPMはじめて2か月で、要望管理の仕組み化をやった結果いろんな良いことがあった
という観点から、開発意思決定のために足元で何やっているかなというのをまとめてみようと考えました。
先に：宣伝とかお願いとか
これ以降のお話、実務上要望管理をやっている内容等を記載します。が、今の状態が成功だとは思っていません。道半ばです。
他社の方にも学びたいので、meetyで雑談しませんか？
また、LayerX、全職種積極採用中です！
LayerX SaaS事業部のサービスと担当プロダクト
私は、バクラク申請のPMをしています。
バクラク申請は、バクラク請求書という請求書処理の効率化サービスを開発するうえで、稟議についても併せて対応する必要があるよね、ということで2021年4月にリリースされたワークフローサービスです。
あえて表現すると、バクラク申請はバクラク請求書という最初のプロダクトから、お客様の要望を把握する中で、派生する形で生まれたプロダクトです。稟議と仕訳の部分が密に・なめらかに連携されることが強みであるがゆえに、要望管理や開発意思決定も、バクラク請求書をコアとしながら、今までは一緒にやっていた（＝明確にバクラク申請のPMを配置していなかった）という事情があります。なお、PMを配置しないという怠慢ではなく、意思を以て一緒のプロダクトとして扱っていました。これは、密に・なめらかにプロダクト間を連携するという設計思想上、真にユーザーに求められる機能を最速で開発することを志向していたからです。
一方で、バクラク申請も利用顧客数が増加するに従い、要望数の増加やワークフローサービスとしての機能追加、品質向上等が求められることが増え、プロダクト間連携を前提としつつも、１つのプロダクトとして要望管理や開発意思決定をするタイミングにきていました。
と、いうことで、私がPMやり始めたとき、バクラク申請のプロダクト開発の体制でいうと、以下のような状態でした。
・バクラク請求書を基軸とした開発ロードマップは存在したが、要望管理の体制が十分とは言えない形だった
・要望は漏れ聞こえてくるが、十分にストックされてはおらず、感覚的に要望の多いと思われるものについて対応している面があった
・つまり、"仕組み化するには最高のやりがいのある環境だった"
バクラク申請のPMの役割とは
今取り組んでいるバクラク申請のPMは、主にPjM、PdM、PMMの３つの役割が混在している状態です。まだまだ成長途中のサービスのため、大きめの企業におけるPdMよりも、浅めにでもカバー範囲を広く持つ役割が求められています。
もちろん、PMの役割は組織のリソースや事業の状態により様々だと思いますが、PdMはPjMやPMM的な役割を全くやらない！というのは稀で、多少はやることがあるんじゃないかと思います。
PjMやPMMでの動きは今後書いていくとして、今回はPdMの動きである、開発意思決定のために要望管理をどう整えたかについて書いていこうと思います。
LayerXの開発に関する考え方
LayerXはテクノロジーを大事にしている会社です。実際、行動指針の1つにBet Technologyがあります。コードを書くことだけではなく、組織の各メンバーがテクノロジーに意識を向け、テクノロジードリブンで未来を切り拓いていこうという行動指針が浸透しています。
具体的には、エンジニアかどうかにかかわらず、各所で各メンバーが業務を"仕組化"したりしています。例えば、デザイナーのmoriさんはzoomの背景画像の作成をノーコードツール等を用いて自動化しています。
Bet Technologyが浸透した組織においては、プロダクト開発においても、様々な参考資料があります。
例えば、"爆速でユーザーの価値となるための開発"を実現するためのmosa_siruさんは、本当に参考になります。
他にも、SaaS事業部PdMエンジニアの花村(@naomasabit)さんの"開発ロードマップ作り"もPM初心者の自分にとって、非常に参考になるブログでした。
要望収集〜リリースまでの流れ
要望管理までの上段の考え方は、他の方がブログに記してくださっているので、以降は私自身が構築した要望収集からリリースまでの流れを記載します。
以下のような流れで、SlackとAirtableの２つを組み合わせて運用しています。
気をつけたポイントとしては、以下の３点です
お客様からの要望は宝。これが集まらない限り、お客様に届くプロダクト改善が始まらないか、効率が悪くなるので、まずは収集しやすいよう、投稿しやすいSlackで要望を募る
要望にいろんなメタデータを付与し、要望の内容だけでなく、分析しやすくする
要望からタスクに変換し、それを開発スケジュールに落とし込む一連の流れは極力自動化する
Slack投稿からAirtableへの連携
Salesの要望リクエストチャンネルに投稿し、特定のスタンプを押すと、Airtableへ連携され、そのURLがスレッドに投稿されます
キウイが２つつながっていますが、要望収集キウイはZapierによる自動返信です。
Zapierの設定から、「様」と表現した前の文章を要望企業名として切り取り、お客様の要望社数を集計できるようにしています。
なお、タスク分類や優先度は、PMが独自に決めるのではなく、要望棚卸会を毎週実施し、要望としての優先度を設定しています。
具体的には、SalesチームとCSチームから、PX(Product Experience）という役割のメンバーを２名アサインし、プロダクトフィードバックサイクルを回せるようにしています。
要望リストから新機能リスト、backlogリストへの連携
PMが判断し、連携しています。
AirtableはRDBのノーコードツールのようなものなので、
①新しい新機能や新しい要望の場合は、起票フラグをつけると、自動で各リストへ連携されます。
②既存の要望と同様の場合は、要望を引用することでマージすることができます。
backlogや新機能からスプリントボードへの移行
こちらも、チェックを押すとスプリント（＝直近２週間でのタスク）に移行することができます。
スプリントタスクとして積んだものが、リリースされた場合
リリース済みのチェックボックスを押すと、slackチャンネルに自動で連携されます。
企業名一覧と、起票者にメンションがされ、要望が叶ったんだなとわかるようになります。
仕組み化してみてよかったこと
プロダクトフィードバックサイクルを回すためのDashboardが作れたことです。
例えば、チーム毎の要望数です。今まで、要望を聞いて、かわりに起票する運用だったため、チームごとに分類して管理ができていませんでした。
3月の頭にSalesチームの要望数が少ないことに気づき、SalesチームのPX担当と会話しながら、要望数を上げるにはどういったことをしたほうがよいか、改善行動を続けています。
他にも、要望企業数でソートをかけることで、「何が求められる機能なのか」を容易に判断できるようになりました。
各要望に対して、いろんな付加情報をつけることにより、様々な分析が可能になる土台を整えることができました。
さいごに
開発は、目に見える機能をつくるだけが全てではありません。リファクタや、今お客様が意識していなくても、作ると喜んでもらえるサービス等、色々な観点が存在しているため、今日記載した内容だけで意思決定ができるわけではなく、その複雑性がPMとしても面白いと感じています。
再度になりますが、ぜひMeetyで話しましょう！私はキャリアとしてもPMやりはじめて2か月ちょっとなので、ひよっこです。
色々な人と話しながら、学んでいきたいと思っています。
採用も積極的にしていますので、ご興味のある方、ご応募お待ちしています！
この記事が気に入ったらサポートをしてみませんか？