B2B SaaSはデプロイだけじゃ終わらない。 リリースノートを書き、マニュアルを作り、サポート対応や運用の定着まで支援して､ 顧客の利用定着率向上にチーム全員で取り組む。/ We are ProductOps.

2/13溜池山王開催 深掘りプロダクトマネジメントわいわい会 オープニングトーク

Transcript

1. B2B SaaSはデプロイだけじゃ終われない。 リリースノートを書き、マニュアルを作り、 サポート対応や運⽤の定着まで⽀援して､ 顧客の利⽤定着率向上にチーム全員で取り組む。 プロダクトマネジメントわいわい会 2026年2⽉13⽇ Yusuke Ohira
2. 1. コンテキストと注意事項 2. プロダクトのローンチから2年間 プロダクト開発チームはどのようなオペレーションをしてきたか ‐ 施策1:リリースノートを書き始める ‐ 施策2:サポートサイト（マニュアル）を整備し始める ‐ 施策3:社内問合せの窓口を作る ‐ 施策4:生成AIで問い合わせBotを作る ‐ 施策5:運用の定着支援 3. さいごに Agenda
3. コンテキストと注意事項
4. コンテキスト ログラスに2023年7月入社。 新規事業のプロダクト開発チームのQAエンジニアを担当。 • 好きなスクラムイベント：スプリントレビュー • 好きな本：闘うプログラマー • 好きなプロトコル：LDAP ログラスは4社目｡ 1社目は13年ぐらい勤務で､某ID管理パッケージ製品のプロダクトライフサ イクルの「導入・成長・成熟・衰退」の体験している｡ 株式会社ログラス QA エンジニア 大平 祐介 Yusuke Ohira
5. 担当プロダクト 2024年2⽉にローンチしたプロダクト
6. • メインのプロダクトとは別の新規事業プロダクト開発チーム • オーソドックスなスクラムチーム ◦ PO（PdM）1名、デザイナー1名、エンジニア6名､テクサポ2名と QA ◦ 1Sprint1Week ▪ ⽊曜⽇にスプリントレビュー、ふりかえり、プランニング ▪ リファインメントは適宜やる ▪ それ以外に「ロードマップみんなで確認会」とか「ビジネスと 仕様を検討する会」がある • テストはみんなでやるよ 私たちのチーム
7. • BtoB SaaS 新規プロダクト開発におけるオペーレーション周りの話 ◦ 素朴理論です（N=1） ◦ BtoC系､⼤企業のプロダクトは⾨外漢なので悪しからず 注意事項
8. プロダクトのローンチから 2年間 プロダクト開発チームは どのようなオペレーションをしてきたか
9. フェーズ0（初期）:ローンチしたときの状況 • プロダクト開発チーム､ビジネスチームともに少⼈数で密に同期コミュニケーションを取れる（阿吽の呼吸） フェーズ1（⽴ち上げ期）:ローンチから半年の状況 • ビジネス側の関係者が増える｡また､ビジネスチームが顧客対応等で同期コミュニケーションが難しくなる • 関係者の⾮対称性を解消するため、ドキュメントを整備 ‐ 施策1:リリースノートを書き始める ‐ 施策2:サポートサイト（マニュアル）を整備し始める フェーズ2（事業組織拡⼤期）:ローンチ半年から1年の状況 • 順調にビジネス拡⼤､それに伴い､ビジネス側も増員 • 仕様を知って貰うために質問への⼼理的ハードルを下げる対応を実施 ‐ 施策3:社内問合せの窓⼝を作る ‐ 施策4:⽣成AIで問い合わせBotを作る フェーズ3（利⽤定着期）:ローンチ1年から今の状況 • 顧客数の増加に伴い運⽤のパターンも多様化‧複雑化､「機能を提供するだけ」では定着しない壁に直⾯ ‐ 施策5:運⽤の定着⽀援 状況の変化に合わせて、必要な打ち⼿を実施してきた
10. 施策1 リリースノートを書き始める
11. 課題 • ビジネスサイドの関係者の増加に伴い、同期コミュニケーションだけでは仕様を伝えきれない 場⾯が増えてきた 打ち⼿ • 「実装前」にリリースノートのドラフトを書き、公開するフローを確⽴する ポイント • ⾃分たちで書くことで運⽤の具体例がイメージでき､運⽤する上で注意事項はないか考えること ができた • ステークホルダーに共有することで､運⽤レベルで齟齬がないか確認でき､作る前に運⽤レベル での問題に気づきやすくなった • ビジネスサイドはリリースノートを元に顧客に説明するためマジになる 実装前にリリースノートを書いて関係者との認識ズレをなくす
12. 施策2 サポートサイト（マニュアル）を 整備し始める
13. 課題 • リリース頻度が⾼く､新しい機能の操作⽅法を共有する必要が出てきた 打ち⼿ • プロダクト開発チームがリリースのタイミングで､サポートサイト（マニュアル）を作成する ポイント • リリース頻度が⾼いので､仕様が変わるため､なるべく作り込まない • 必要なもの､重要機能の操作から順次記事化する 顧客の⾃⾛を⽀える情報を提供する
14. 状況によって、担当を変えたりする リリースまでのだいたいの流れ
15. 施策3 社内問合せの窓⼝を作る
16. 課題 • 社内の⼈員増加に伴い、「誰に聞けばいいかわからない」、「異なる⼈から来る同じ質問への 繰り返し対応」が発⽣してきた 打ち⼿ • Slackに「気軽に質問チャンネル」を開設した • CSと定期的なMTGを設定して､状況を把握できるようにした ポイント • チャンネルをつくることで「ここで開発チームに聞けば解決する」という社内認知を得た • ビジネス側の状況を把握することで､先⼿を考えるようになった 社内関係者の仕様理解をあげる
17. 施策4 ⽣成AIで問い合わせBotを作る
18. 課題 • リリースノートなどのドキュメントなどのナレッジを貯めることができたが「探すのが⼤変」 になった 打ち⼿ • 「気軽に質問チャンネル」に⽣成AIを利⽤した問合せチャットbotを利⽤できるようにした • さらに気軽に質問できる状況を作った ポイント • 問い合わせBotのためにナレッジをリポジトリに集約する • 「ユビキタス⾔語の整備」など､必要な情報を作り込んだ 蓄積したナレッジを⽣成AIでアクセスしやすくする
19. 施策5 運⽤の定着⽀援
20. 課題 • 顧客数が拡⼤し、⾼度な運⽤設計を⽀援するリソースが不⾜ 打ち⼿ • プロダクト開発チームが技術的視点で顧客の運⽤設計まで踏み込んで⽀援する ポイント • 業務要件に対し、既存機能をどう組み合わせれば実現できるか、「使い⽅」ではなく「業務フ ロー」を案内する • 実際に顧客と対⾯することで､顧客チーム全員の顧客理解が進んだ • ⾃分たちで顧客へのサービスレベルの品質をコントロールしやすくなった 運⽤の定着を⽀援し、顧客の活⽤度を上げる
21. さいごに
22. • 必要なものを必要なだけやる ◦ 状況の変化で発⽣した課題に対して対策する ▪ ちょっと未来ぐらいの打ち⼿までを考える ◦ プロダクトの初期は変化が激しいので作り込まない ▪ メンテナンスコストを考える • まずは⾃分たちでやる ◦ プロダクトの顧客提供までを考える ◦ プロダクトのサービスレベルのコントロールを⾃分たちで出来るようにする プロダクト開発チームでプロダクトオペレーションをする上で⼤切にしてきたこと
23. ⾯倒くさい？ 作ることに集中したい？
24. でも､ プロダクトを作り上げていく上で オペレーションも⼤切な活動だよ
25. ⾃分たちで作って､ ⾃分たちで顧客に価値を提供していくことが ⼤切
26. これも､ プロダクトマネージメントであり､ プロダクトを作るということ
27. みんなでやっていこう