はじめに
こんにちは、フロントエンドエンジニアの樫福 @cashfooooou です。 タイミーでは toB 向け管理画面を作成しています。
半年ほど前、タイミーでは顧客からのサービスへの要望を集め、管理するシステム（以下、要望回収システム）を作りました。 顧客の課題から新しい機能について考え、顧客により価値のあるものを届けるための施策です。
システムの実装には Notion という SaaS を活用しました。 最小限の実装で良い機能・良い運用が作れたと思っています。
この記事では、要望回収システムの実装に取り組んだ経緯から、実際の運用の例まで紹介します。 同じように顧客の要望回収を行いたい方はもちろん、SaaS を使ったミニマルな機能開発の参考になれば幸いです。
Notion
Notion は、タスク管理や Wiki の作成に適した Web アプリケーションです。 ユーザの手によってカスタマイズしやすく UI も使いやすいので非常に便利です。
弊社ではエンジニアだけでなく、社全体のドキュメント管理の大部分で Notion を用いています。 Notion 好きの社員も多く、 最近は Notion の活用術について CTO の kameike がインタビューを受けたりしました。
従来の回収システム
従来の回収システムは Google フォーム と Google スプレッドシートを組み合わせたものを利用していました。
課題
従来の回収システムは顧客から寄せられた要望を閲覧できますが、次のような複雑な操作が難しいです。
- 似た要望同士を紐付けて管理する
- 対応の優先順位を決める
- プロジェクトやタスクと要望を紐付ける
結果として、要望が集まれば集まるほど確認作業の手間が増えるというジレンマに陥り、運用が十分に回らなくなってしまいました。
解決したい課題
従来のシステムの課題をもとに、次の方針を立てました。
- 要望に対して操作をしやすく
- 似た要望の紐付け
- 進捗の管理、優先度をつけられる
- 要望からタスクに繋げやすく
- なるべく実装が少なく
我々のチームは普段 Notion を用いてタスク管理しているので、それとうまく連携が取れると運用が楽になって嬉しいです。 加えて、要望回収システムは弊社のサービスのコアドメインとの直接的な関係が薄いのでなるべく手間をかけずに実装したいと考えていました。
Notion API を用いた課題解決
この議論をしていたのは2021年7月ごろでしたが、その2ヶ月ほど前に Notion API がパブリックベータとして公開されました。
パブリックベータとはいえ、レコードの閲覧や作成ができるのでいろんなことができます。
寄せられた要望を Notion 上でを管理できると、Notion を用いた既存のタスク管理との連携も容易になりました。 また、似た要望をまとめるような操作も Notion のリレーションなどを使って実現できます。
そして何より、これらのロジックもUIも、そのほとんどを Notion の機能を用いて実現できるので実装の手間がとても小さくて済みます。
今回実装した要望回収システムは、 Notion API を用いて次のような構成になりました。
顧客は弊社のサービス画面の「プロダクトへの要望フォーム」から要望を投稿します。 投稿された要望は API サーバから Notion API を経由して Notion のデータベースに蓄積されます。 要望が投稿されると Slack に通知が届くので、エンジニアは Notion の Web ページから顧客の要望を確認することができます。
このシステムを導入する上で実装すべきことは
- 顧客の投稿フォームの実装
- Notion API を用いた Notion の DataBase への投稿機能
- Slack への投稿
のみです。 Notion の機能のおかげで下のような恩恵が受けられました。
Notion API の登場によって、抱えてた問題の全てが解決しました。
制約
こちらのページでNotion API には 平均3リクエスト/秒のレートリミットについて触れられています。
将来的に料金プランに応じてレートリミットが変わる予定もあるようです。 Notion API を利用する際にはこのあたりに注意することをおすすめします。
弊社のサービスに寄せられる要望は多くても一日10件程度のなので、レートリミットの問題は無いと判断しました。
データベースの構成
システムを実装するにあたって、顧客から寄せられる要望の分析をしました。
寄せられた要望を見ると、「〇〇の条件下で△△してほしい」や「✗✗機能を追加してほしい」のような具体的な解決案が送られてくることが多いです。 これらの具体的な解決策に直接対応していっても、プロダクトが抱えている課題を本質的に解決するのは難しいことが多いです。 そこで、似た要望をまとめて抽象化し、プロダクトの課題として扱うのがよさそうだと考えました。
以上のことを踏まえて、要望の管理のために次のようなテーブルを作成することにしました。*1 図中の矢印は Notion のテーブルのリレーションを表しています。
「要望」は顧客から寄せられたメッセージそのものです。 「課題」は要望の根底にあると考えられるプロダクトの課題です。
要望と課題はそれぞれ進捗度合いを表すステータスを持っていて、進行度合いを確認できます。 タグは類似の要望や課題を整理するのに役立ります。 また、要望・課題・backlog はそれぞれリレーションを持っていて、情報の管理に役に立ちます。
回収システムの Notion の構築
こちらのページ に、上の図のテーブルを再現してみました。 寄せられた要望、そこから深ぼった課題、実際にエンジニアが着手するタスクの例を埋めています。 （簡単のために、 twitter のような架空の SNS に対して寄せられた要望という設定です。）
「要望」テーブルの一番右の列は、要望と紐付いている「課題」テーブルのアイテムが表示されています。 同様に、「課題」テーブルには紐付いている「backlog」テーブルのアイテムが表示されています。
更に、Notion でテーブルの各レコードが Notion Page になっているのも大きな利点です。 要望・課題について議論をしたときに直接 議事録を書き込むことができるので、後で確認するときに情報が漏れる心配がないです。 議事録の作成には Database templates が便利です。 ページ内の課題のレコードを開くと議事録のサンプルも確認できるようになっています。
実際に Notion を触っていただくとよくわかると思いますが、データの更新、ソートやフィルタ、他のテーブルとのリレーションなど、実際に実装するとかなりの工数のかかりそうな機能が手軽に使えるのは本当に嬉しいです。
運用
エンジニアや PM が定期的に要望テーブルを確認してタグを割り当てたり課題・タスクの作成・紐付けを行っています。 課題の作成・紐付けも Notion のデータベースのフィルタやソート機能を使って、過去に作成した同様の課題と比較しながら作業ができるので無駄が少ないです。 テーブルのレコードがそれぞれが Notion Page となっていることの恩恵を強く感じます。 Database templates を用いた議事録やテーブルの管理がかなり楽で助かります。
まとめ
プロダクトの要望回収システムを Notion API を用いて実装しました。 Notion の使い勝手がよいので実装の手間がかなり小さく、よい選択ができたと思っています。
今回のような社内向けの機能の開発において Notion API は、最小限の実装のコストで十分な機能が実現できる Notion のポテンシャルを見せつけられました。 加えて、すでに社内の情報管理のために Notion を導入しているのであれば、連携することでさらなるうまみが得られるチャンスです。 コアドメインではない機能の開発や新機能の仮説検証など、あまり工数をかけずにミニマルな実装をしたいときには Notion をはじめとした SaaS を活用してみてはいかがでしょうか。
Notion 最高！一番好きな SaaS です！
*1:実際に運用しているテーブルからいくつかのプロパティを落としています。
