この記事は freee Developers Advent Calendar の17日目です。
自己紹介
freee 株式会社で、PM（Product Manager）をやっているfuji_tipです。
freeeに入ってから4年で、マーケティング/事業開発 —> データ分析 —> 事業戦略 —> PM という変遷で、社内ジョブホッパーです。フルスタック社員と自称しています。
趣味は飲酒です。
PMってなにやってるの
社内外から、PMって何やってるかわからない、どういう能力があればPMになれるのかわからないなどの声をもらうことが多いので、具体的な案件のリリースまでのプロセスを振り返りながら、PMの仕事について理解いただければと思います。
ある機能を作る！とか既存の機能改善をする！となったときの大体の流れを簡単に下記の通り説明します。
- 課題選定・ゴール設定
- それが本当に課題なのか？課題だとしたら、どのような状態になるのが理想か？
- ソリューション検討・影響調査
- 課題に対してどのようなソリューションが最適か？それはお客様にどのような影響をあたえるか？他の機能に影響はないか？
- 開発
- ソリューションは実現可能か？PMが作った仕様に抜け漏れはないか？
- リリース・振り返り
- 設定した課題・ゴールはあっていたか？お客様からのフィードバックはないか？
では、次からは具体的な改善案件を扱いながら、どういうことをやっているのか説明したいと思います。
具体的案件：取引一覧のパフォーマンス改善
課題選定・ゴール設定
会計 freeeは会計・経理ソフトであるため、月末月初に利用されるお客様が多く、かつ、SaaSであるがゆえに、多くのお客様に利用されると負荷が月末月初に集中します。
また、創業当初は個人事業主の方にお使いいただくようなサービスだったのですが、事業の進捗により、個人事業主の方から数百名規模の企業にいたるまで、様々な規模の多くのお客様からお使いいただけるサービスに進化してきました。
その為、月末月初にかかるサービスへの負荷が無視できないレベルになってきており、その中でもよく使われる”取引一覧”画面の負荷が高いということがわかりました。
こちらのデータはデモアカウントのものです。
そこで、freeeの取引検索機能は、検索項目や条件を変更するたびに即座に検索が実行される仕組みとなっているのですが、取引一覧の中でも、この検索機能の負荷が高いのではないかという仮説が浮かび上がりました。
検索ボタンを設置し、ボタンを押したときにだけ検索を実行しようというアイデアもあったのですが、freee側都合でお客様への価値を下げるのはいかがなものかと思い、一度下記のように、"負荷"の原因を分解し、実際に起こっている事象を整理してみました。
| 負荷の原因 | 事象 |
|---|---|
| 取引一覧での、一度の検索リクエストの負荷が高い（一度にたくさんデータを持ってきている） | 取引一覧に遷移したときに表示される取引は、なんの条件もなく全件表示される（厳密には全件なめる）ようになっている |
| 取引一覧での、リクエスト回数が多い（検索実行される回数が多い） | 検索条件や項目を変更するたびに検索が実行される |
こうすることで、課題の本質が明らかになったので、ソリューションを考えやすくなりました。
ここで、今回の改善のゴールは下記のようなものになります。
ゴール
- （freee都合の変更なので）お客様の体験がなるべく変わらない
- 取引一覧の負荷が下がる
次からソリューションを検討していきます。
ソリューション検討・影響調査
「一度の検索リクエストの負荷が高い」という課題に対しては、取引一覧に遷移時の初期表示の件数を減らすことが必要なので、初期の表示条件に取引日付を設定することとしました。
これは、現行の取引一覧が取引日付順で並んでいるため、条件を取引日付以外にすると、初期表示される取引が現状と変わってしまうためです。変わってしまうと「お客様の体験を変えない」というゴールが守れなくなってしまいます。
その上で、「お客様の体験が変わらない」を 取引一覧の1ページ目に表示される取引の数が変わらない と定義し、実際に1ページ目に表示される取引件数をプロダクトのデータを使って調べてみました。
取引一覧の1ページあたりの件数は20〜500件までと変更できるので、最大の500件を表示件数とした時に体験が変わらない割合を算出しました。
この時、期間は現在日付から3ヶ月前、6ヶ月前、9ヶ月前、12ヶ月前、会計期間の初めからと設定して算出しています。
※一部数字を伏せています。縦軸の最大値が100%じゃない場合があります。
お客様の体験が変わらない割合
抽出される取引の件数割合（総数に対する割合）
なるべく多くのお客様の体験が変わらず、かつ、負荷が十分に下がる点を条件とし、
- 現在日付から12ヶ月前もしくは現在の会計期間の開始日のどちらか古い日付以降とする
という条件を、取引一覧の初期表示時の条件に設定しました。
「リクエスト回数が多い」という課題に関しては、検索条件が変わらない項目変更時は、検索の実行を走らせないというソリューションにしました。（こちらはまだ未実装でリリースされていません）
また、考えたこれらのソリューションをドキュメントにまとめて共有し、社内の様々なチームに確認をしてもらい、問題がなさそうであることを確認します。
開発
開発自体はエンジニアにやってもらうのですが、なぜやるのか？を重点的に説明します。 背景を理解してもらうことによって、PM側が考えた仕様に抜け漏れはないか、他に影響はないか？など、より広範に渡ってお客様に影響がないかどうかを考えながら作ってもらえます。
作ってもらった機能を検証環境で実際に触り、挙動に問題がないかなども確認したりします。
リリース
プロダクトにリリースする前には、お客様への告知を行います。
具体的には、ホーム画面へのお知らせの掲載や、お客様へのメール送信などを行います。お知らせの掲載は管理画面から自身の手でおこない、メール送信は担当チームに伝えてやってもらいます。
いよいよリリース日、お客様に受け入れられるだろうか、バグは起きないかなど、様々な想いを頭にめぐらせ、そわそわしながら反応を待ちます。
…
リリースから数週間が経ちますが、お客様からのネガティブなフィードバックはなく（ポジティブなフィードバックもないのですが）、かつ、負荷を大幅に低減させることができました。
ゴールに、お客様の体験が変わらない＆負荷が下がることを設定していたので、成功といえます。 （体験が変わっていないからこそ、フィードバックがないととらえました。）
総括
ここで紹介したのは比較的地味なプロダクトの改善でしたが、新機能の開発なども大枠同じようなプロセスで行っていきます。
今回は、ゴールをお客様の体験を変えないことに置きましたが、基本的な機能改善や新機能開発などは体験が変わることが前提となります。そのため、新しい機能をどのようにお客様に理解してもらうか？使ってもらえるか？も重要なポイントになってきます。このあたりはUXデザイナーと一緒になって考えていったりします。 （今回の改善ではUIの変更は伴わなかったため、デザイナーとの協同はあまりありませんでした）
その他にも、事業計画を達成するためにはどのようなプロダクトがどういう時間軸で存在すべきか？などのような、より抽象的な課題を考えるPMもいたりします。
また、これはfreee 株式会社におけるPM業の一例です。 PMという職種自体発展途上な部分がありますので、業種やビジネス規模、事業フェーズに応じて役割が違うことも多々あると思います。
PMのお仕事、ご理解いただけたでしょうか？
課題発見・設定力、情報収集・分析能力、コミュニケーション能力など様々なスキルセットが求められる仕事で、意思決定を迫られる機会が非常に多いためプレッシャーもありますが、お客様に価値を届ける源泉になる職種で、非常にやりがいがあります。
明日は、freeeのセキュリティを堅守する期待の若手エンジニア、macotasuさんです〜。お楽しみに！
