自己紹介

プロダクトマネージャーの深瀬です。
前職はオフショア開発会社で営業、開発ディレクター、Project Managerをしていました。
2021年2月にSENRIにJoinしました。もうすぐ1年経つところで、ようやく全体像が見えてきたのでSENRIのプロダクトマネジメントについてご紹介したいと思います。

プロダクト

SENRIは現在アフリカ6カ国とインドネシアで展開している新興国向けのSales Force Automationです。
外回りする営業メンバーがアプリで顧客の訪問を記録したり、受注や配送の管理ができます。
オフィスにいる営業マネージャーはWebで訪問状況を確認したり、顧客管理や在庫管理などができます。

SENRIの導入によって、

1. 営業報告や受注書などの紙でのコミュニケーションが少なくなる
2. 営業マネージャーから各スタッフへの情報伝達が早くなる
3. データが現場からリアルタイムで送られてくるので受注〜配送のオペレーション自体が早くなる & 倉庫の残業がなくなる
4. 営業部全体の動きが素早くデータ化、可視化されることで営業マネージャーの意思決定の手助けになる

などなど、既存のオペレーションが効率化されたり、そこで働く人の働き方自体を変えてしまったりと、会社によって異なりますがさまざまな効能効果があります。

開発メンバー & 開発サイクル

Android, サーバーサイドチームに分かれており、バックエンドフロントエンド関わらず担当しています。
アプリは1.5ヶ月に1度のリリースサイクル、サーバーサイドは1週間のsprintで開発しています。
現在は、Androidは3人、サーバーサイドは5-6人で開発しております（業務委託や副業の方も含む）。

課題の設定

毎月始めにAndroid, Webともに直近1-2ヶ月の課題を決定します。
事前にケニア、ナイジェリア、インドネシアのSENRIの現場の営業担当者とある程度合意を取った後に、エンジニアメンバーとMTGを行ない、リリーススケジュールを決定しています。

SENRIの開発課題の性質は大きく分けると2つあります。

戦略的案件

SENRIではクォーター毎に開発していきたい大きめの機能をビジネスサイドで決定します。AIのようなビジネス側から発案された機能もあれば、新たな顧客層を開拓するための新機能などがあります。クォーター毎に1,2件あり、要件決めから実装まで2-3ヶ月かけて行ます。
直近だと、訪問や売上サイクルに合わせて、どういう顧客に訪問すべきかをレコメンドする機能をリリースしました。

Product feedback

SENRIでは現場の営業担当者が顧客からのフィードバックや要望はSlack上で社員全員が見れるようにしています。週に1回ケニア・ナイジェリアの営業担当者とMTGを行い、詳細のヒアリングやどの要望に答えていくかを議論します。
その際は複数の顧客に共通する課題か、運用方法の変更で解決できないか、などを検討します

フィードバックなどの内容は、顧客からの「〇〇が欲しい」という具体的なものから、「〇〇ができるようにしたい」という抽象的なものまであります。
「〇〇が欲しい」「〇〇ができるようにしたい」という表現に引っ張られて、その機能を作るにはどうするか・・ということをつい考えてしまうのですが、なぜそれが必要なのか、本質的な問題は何か、その機能で本当に問題は解決されるのか、を考えるようにしています。
と言ってもまだまだできていないことが多く、エンジニアに課題を共有する際に厳しいツッコミをもらい、もう一度顧客の本当の課題は何なのかと考え直すこともしばしばあります。これらは顧客の要望やリソース、内容を鑑みて、すぐに実装することもあれば、数ヶ月後に実装することもあります。

フィードバックから課題はどこにあるのかなど、顧客の声をダイレクトに聞くことができ、それをプロダクトに反映させていける、というのもBtoBのソフトウェア開発の醍醐味でもあります。

リリース後のモニタリング

実はこれはまだあまりできておらず、大きめの機能に対してはリリース数ヶ月後に何社が利用しているか、顧客獲得にどれくらい効果ががあったのかなどを確認することはありますが、他の多くの機能はモニタリングができていませんでした。リリースサイクルの短さ、機能追加していく速さ、リリースしてから使ってもらうまでの時間が会社ごとに違う、そもそも会社によってSENRIの使い方が違うなどモニタリングするにも、全部のデータをどかってみても意味あるものにならないので、どう切り分けて見ていくか、何を見るべきか、というのも難しいところでした。
今年からなるべくリリースする前に仮説を立てどうモニタリングしていくと良いかを事前に設定し、可能な限りリリースした全機能の利用状況を営業チームと確認、月に一度エンジニアメンバーにも結果共有をすることにしました。それによって自分達の仕事の成果を可視化するとともに、今後優先すべき機能・捨てる機能なども明らかにしていきたいと思います。特にCTOは機能を捨てたがるのですが、それを判断するのが難しいので困っています。

SENRIのプロダクトマネジメントの面白いところ

一人一人の担当する幅が広いところ
前述の通り、開発チームはAndroid, サーバーサイドでしか別れておらず、PdMは1人で両方のプロダクトを見ています。先週まで在庫管理の新しい機能を作っていたと思ったら、次の週はAIの需要予測作り、その次はPush通知を作ったり・・・
エンジニアも担当機能は決まっていないので、納期や難易度をもとに毎回誰が実装するのかを相談して決めています。
機能ごとに理解を深めたり頭を切り替えるのは大変ですが、エンジニアにとってはSENRIのプロダクト全体を見ながら様々な機能に携わることができて面白いのではと思います。

影響範囲の大きさ
SRNRIの中では些細なことでも、ユーザーの営業現場の負を改善して効率的な業務ができることで、新興国の経済発展に貢献できるかもしれない。
営業マネージャーが営業メンバーの業務を正確に把握して適切に評価・指導できることで、新興国の人材育成につながるかもしれない。
つい日々の業務に忙殺されて忘れてしまうのですが、自分達の作るプロダクトで負を解決した先の未来を時々考えるとワクワクしますね。
個人的には、青年海外協力隊としてセネガルに赴任していた時に、意欲があっても環境が整わないために成果を出すことができないという人たちにたくさん出会いました。そんな人たちでもシステムを使うことで平等に努力する機会を得て、成果が認められるといいなと思っています。

最後に

ただいまサーバーサイドエンジニアを募集しています。
ユーザーにどういう行動をとってもらいたいのか、そのためには何を作ると良いのかを一緒に考て実装したいという人には面白いのではないかと思います。
展開している国の数や使ってくれているユーザー数、プロダクトに対して組織はまだ小さいので、プロダクト全体に影響を与えることができます。
少しでも興味を持った方は是非詳しいお話をさせていただきますので、お気軽にご連絡ください。