はじめに
スライド・ドキュメントデータの出品/購入が可能なCtoCマーケットプレイス「DocTok」の開発でPMを担当させていただき、学んだことがあるのでまとめました。
DocTokの簡単なサービス紹介になりますが、資金調達や経営会議でのプレゼン資料、クライアントへの提案資料、定例会議のフォーマット資料など、経営者から営業・企画担当者、フリーランサーまであらゆるビジネスパーソンが実際に使用した実績ある資料を出品/購入ができます。
これまでPCに眠っていた質の高い情報や知識である“隠れ資産”と、目的を達成するプレゼン資料を最短距離で作成したい忙しいビジネスパーソンとをつなぎ、新たな価値交換の場を創出するのがDocTokです。
ぜひ、見てみてください！
この記事では、DocTokの開発にPMとして担当させていただき、要件定義~リリースまで学ぶことがありましたのでアウトプットしたいと思います。
プロジェクトの進め方
今回のプロジェクトでは、以下のようなウォーターフォールに近いような形でプロジェクトを進めました。
ただデザインや開発のフェーズでも追加した方がプロダクトにとって良いインパクトがある機能に関しては、追加しています。
要件定義
要件定義では、以下のように必要な要件を洗い出します。
・機能要件/非機能要件
・環境種別
・大区分（画面）
・中区分（ユーザー行動）
・小区分（ユーザーができること）
・優先度（高・中・小）
・役割別工数
以下が実際に要件定義の際に使用したスプレットシートの一部です。
要件定義の進め方としては、類似だったり競合になるサービスを実際に触って必要な要件を洗い出していきます。
もちろん、よくあるWebアプリケーションのCRUD機能などの基本となる機能に関しては類似だったり競合になるサービスを触らなくてもある程度の必要最低限の機能は洗い出すことができますが、事業ドメイン特有の必要機能などもあるので必ず類似、競合サービスは実際に触ってみるのが良いと思います。
2~3個触ってみるだけでもプロダクトのイメージが格段に鮮明になると思います。
また要件定義中でも優先度を決め、初期リリースではどの優先度まで開発をするのかチーム内で議論しました。
優先度を決める中でプロダクトを利用するユーザーを想定しUI/UX観点で必要な機能を洗い出すことも重要ですが、以下の観点でも要件定義を進めるべきだったなと感じます。
プロダクトをリリースした後のマーケティングを考え、要件定義する
結局、プロダクトをリリースしてそのまま広告やプロダクトの分析/検証/改善をしないままだと、一向にプロダクトの新規登録者や売上が伸びていくことはないです。
なので、どんなにプロダクトを利用するユーザーを考え、UI/UXを考えたとしてそもそもプロダクトを知ってもらわない限り意味がないです。
どのようなターゲットに対し、どのようなマーケティング施策を打つかによって要件定義の内容も変わってきます。
リリース後になりますがDocTokでは、XとSEOを中心にマーケティングを実施することになりました。
DocTokに出品していただいた各スライドをXで投稿したり、「提案資料 テンプレート」などで検索した際にDocTokのスライド詳細ページが検索結果で表示されるようにする施策を中心に検討し、その施策の1例ではありますがOGPでは出品していただいたスライドのタイトルとディスクリプション、スライドの1枚目をOGP画像として設定するようにしています。
元々は、スライドの情報に関わらず決まったテンプレートのOGPを表示させるようにしていましたが、Xなどで投稿した際にスライド独自の情報がなくXでDocTokに出品していただいているスライドを見た際に興味を引くような施策になっていませんでした。
要件定義の際に、SNSを中心にマーケティング施策を打つことをもう少し検討できていれば良かったなと思います。
現状は、各スライドの情報を取得し、OGPが生成されるようになっています。
以下のような感じで！
あとは、自身のSNSでもDocTokで出品していただいた資料を拡散しやすくするために、マイページを作成しMetaやLINE、Xなどでシェアできるようにしています。
細かいところではありますが、こういった些細なことがのちのデザインや開発で大きく影響があり、リリースした後のマーケティング施策で、「あれ...？〇〇の施策をするんだったらこういう見え方、機能が必要なんじゃないか...？」っていう話になるなと学びました。
また、リリース後にプロダクトの分析/検証/改善サイクルを回しますが、その際にどのようなツールを使って分析/検証/改善をするのかも要件定義で検討しておきたいです。
DocTokは、toC向けのプロダクトなので様々な媒体から流入があります。
Google, X, Meta, LINEなど
その中でGoogleアナリティクスやClarityなどのアクセス解析ツールでは、アクティブユーザー数や流入経路はわかるが、どのスライドがどれくらい購入されているのかわからないです。
プロダクトを伸ばす上で、売れ筋商品だったりユーザー1人あたりの購入単価を把握することは、今後の施策の示唆出しで大いに役立ちます。
DocTokではBigQueryを導入し分析をしていますが、要件定義の際は分析/検証/改善サイクルまで検討することができていなかったのでリリース後にBigQueryを導入しました。
ただ本来は、リリース前にBigQueryを導入しどのようなKPIでマーケティング施策を実行するのかまで検討できていればベストだと思いました。
リリース後にプロダクトの分析/検証/改善サイクルを検討する
最後にDocTokの決済は、Stripeを使用しました。
Stripeでは、Stripe利用料の他にも振込手数料や有効なアカウント費など様々な手数料があり、キャッシュフローを整理するのに時間がかかりました。
※詳細については、公式ドキュメントをご確認ください。
プロダクトにとって肝になるキャッシュフローは、要件定義の中でも最優先で進めるべきだと思います。
キャッシュフローを整理することで、Stripeの手数料がいくら差し引きされているのが明確になることからDocTok利用料を設定し、販売の最低金額を決めることができます。
また外部サービスを利用する際に、公式ドキュメントを見て料金体系や仕様等を確認することは重要ですが、プロダクトにとってクリティカルな仕様になるのでサポートセンターに問い合わせて想定している仕様で認識の齟齬がないかを確認することは重要だと感じました。
以下が、キャッシュフローをまとめた図になりますが、Stripeの手数料が決済が発生した時以外にも売上を振込際にも発生するため、なかなか公式ドキュメントだけで理解するのは難しかったです。
※現在のDocTokでは手数料が異なる箇所があります。
なので、サポートセンターに現在想定しているキャッシュフローで認識齟齬がないか問い合わせをし、何度も確認を繰り返しました。
もう1つ要件定義で学んだこととしては...
キャッシュフローを整理する
WF/デザイン
要件定義で、大枠の仕様が洗い出せたらWFに着手します。
正直、個人的には要件定義とWFは並行して進めるべきかなと思います。
要件定義で共有したようなスプレットシートなどで要件をまとめたとしてもWFに起こし実際の動線を考え、UX的に問題にないかを見直しすると要件定義漏れの箇所が出てきます。
頭の中で要件定義をし動線も考えますが複数ページだったり複数機能あるアプリケーションの場合は、なかなか頭の中だけで要件を整理するのは難しいと思います。
WFに書き起こすことで、動線や機能が揃っているかをチェックでき、足りなければ要件定義し直すようなサイクルを回すことができるので良いと思います。
完璧な要件定義書の作成を目指して、必要以上に要件定義に時間を割くよりも大枠の要件定義ができたらWFに着手しプロダクト全体の流れを考えてさらに仕様の検討をするのが良いと思います。
なので、今回WF/デザイン作成で学んだ1つ目のこととしては...
大枠の要件定義ができたらWFに着手する
WFで動線や機能まで含めて詳細に詰めることでデザインや開発に入った時に、デザイナーやエンジニアがスムーズに作業に入ることができるので、WFは重要です。
開発
WF/デザインの作成ができたら、開発に入っていきます。
開発まで来るとPMとしては基本的に、進捗の確認がメインの業務になりますが、開発の中でも追加要望をいただき、実装タスクが増えることがあります。
中には、大きめの機能の追加もあれば小さめの微修正などがありますが、タスク管理をする上で学びがありました。
どんなタスクでもBacklogに起票する
微修正だと、Slackなどのコミュニケーションツール上で修正依頼をしてしまい、進捗があやふやになることが多かったです。
なので、ちょっとしたテキスト修正でもまずはBacklogに起票し優先度や進捗含めて管理することが重要だなと学びました。
QA
開発が終わると、いよいよリリース前のQAです。
QAでは、シナリオテストを実施しています。
DocTokを実際使用するユーザーを想定し、テストケースを作成しPC/SPともに実機で粛々とテストを実施します。
実際に使用したテストケースの一部は以下です。
UI面でのQAも必要ですが、バックエンド的なロジック面も含めてテストケースを作成することが重要です。
特に決済処理がある場合は、プラットフォーム手数料や振込手数料など様々な手数料があり最終の決済額が正しいかもQAでチェックするようにしましょう。
意外とUI面のテストに注力し、ロジック部分のテストが抜けてしまうこともあるなと気づきました。
なので、PMがテストケースのベースを作成し詳細なロジックなどはバックエンドエンジニアの方に必要なテスト項目が網羅できているかをチェックしてもらうのも良いなと思います。
ロジックも含めてテストケースを作成する
またQAでも余白やフォントサイズがデザインと異なるようなレベルの軽微な修正もあれば、プロダクトにとってクリティカルなバグも出ました。
プロダクトにとっては、軽微な修正も含めて全て修正できるのが良いですが、エンジニアの限られたリソースの中で、優先度を決めて修正を進める必要があります。
QAで出た不具合に対しPOとも相談し、優先度を決め期限内で修正箇所を精査しましょう。
QAで出た不具合に対し優先度を決めて対応する
まとめ
今回、新規事業であるDocTokのPMを担当させていただき、仕様通りにプロダクトを開発することももちろん重要ではありますが、リリースした後を考え要件定義することの重要性を学ぶことができました。
また限られたリソースの中で、機能開発だったり不具合修正をする必要があり無闇に必要な機能だから、不具合だからといって開発するのではなく、しっかり優先度を決めてチーム内で検討することでプロダクトの品質を高められると感じました。
採用のお知らせ
株式会社Relicでは、エンジニア・デザイナーを積極的に採用中です。
またRelicでは、地方拠点がありますので、U・Iターンも大歓迎です！🙌
少しでもご興味がある方は、Relic採用サイトからエントリーください！