本当に必要とされる機能を目指して～職種を超えた仕様検討の現場～【SaaSビジネス経験談 #8】
シナジーマーケティングのプロダクト「Synergy!❐」に関わる様々な職種のメンバーが、自身の経験を元に、ビジネスに役立つ情報をお送りします。 今回の筆者は、Synergy!フォーム機能のプロダクトマネージャーです。
1．今採用している開発方法の紹介
開発方法を説明する前に、より話がわかりやすくなるよう開発チームの登場人物について紹介します。
私たちの開発チームは、目的／ゴールの達成によって解散するプロジェクト体制とは異なり、フォームに関する機能開発、保守開発を同じメンバーで継続して取り組んでいくような体制です。
各チームにはPdM、PMM（プロダクトマーケティングマネージャー）、デザイナー、エンジニア、品質保証（QA）と、異なる職種のメンバーが集まっており、フォームチームは9名でチームを組んでいます。
Synergy!の開発プロセスは共通のフレームが定義されており、基本はそのフレームに則っていますが、細部はチームの特性にあわせて少しずつ異なります。フォームチームの特徴はSynergy!の他の機能と比較して、早期からPMMも含めたチーム全員で仕様検討する体制が整ったところです。
PMMは機能の企画や、認知／販売施策を検討し実行しているメンバーです。「チーム全員で」という点もそうですが、最大の特徴は「よりお客様に近い立ち位置で業務を遂行するPMMが、エンジニアと一緒に仕様検討している」という点です。
「職種を超えた」は少々大げさかもしれませんが、チーム全員で機能をつくる取り組みとして、どのように仕様検討を進めているのかをご紹介できればと思います。
2．なぜPMMも仕様検討に参加するのか
これまではPMMは開発チームとは独立して動くことが多かったのですが、チーム体制に移行したことで、チームの一員として活動しやすくなりました。
私はエンジニア出身なのですが、エンジニア中心のチームは仕様が具体的になるにつれて利用者目線が薄れてしまうと考えています。もちろん利用者のことを意識して検討するのですが、どうしても保守や開発コストが頭をよぎります。結果、利用者に優しくない機能になってしまうことも経験しました。PMMが仕様検討に参加する狙いは、チームが利用者目線を失わないことです。
▼PMMメンバーの経験談
3．全員野球で行う仕様検討の流れ
フォームチームの仕様検討は、大まかに以下のステップで進めています。
①PBIの作成、共有
②デザインの検討
③仕様検討、デザインの調整
④ユーザビリティテスト、仕様の調整
⑤仕様決定
順番に説明していきます。
①PBIの作成、共有
要件をもとにPdMがPBI（プロダクトバックログアイテム）を作成します。
要件整理もこのタイミングで実施していますが、その話はここでは割愛します。このプロセスでの重要な点は、PBIに要件整理でまとめた結果と、要件を満たすために必要な仕様についてチームの全員で読み合わせをする部分だと考えています。
※PBIという言葉が出てきましたが、スクラム開発ではありません。スクラム開発とウォーターフォール開発をミックスしたような弊社独自の進化を遂げた開発です😅
PBIをチーム全員に説明する際には、開発する機能の目的や背景を伝えるのは当然として、最近ではユースケースやターゲットも説明することを心掛けています。お客様に本当に利用してもらう機能を作るためには、誰の／どんな課題を／どのように解決するのか、を職種問わずにチームで共通認識を持つことが重要だと感じているからです。
それにより、各職種で検討しないといけない仕様について初期段階から解像度を上げることができます。そこから開発スコープを決めていくのですが、仕様検討時にユースケースを理解することで、機能の過不足を防ぎ、最終のアウトプットが市場の求めるものからブレにくくなると考えています。
②デザインの検討
PBIをチームに共有したら、PBIをもとにデザイナーが機能全体のデザインを検討します。（PBIの作成と平行して検討してもらうこともあります）
たたき案をチームに共有しながら、エンジニアも巻き込んで大枠を作っていきます。
作成したデザインは適宜チーム全員に共有され、調整を重ねてブラッシュアップしていきます。調整段階ではチーム朝会で「今こんなこと考えているんだけど、どうです？」といった会話をしながら進めていたりもします。
③仕様検討、デザインの調整
検討したデザインをベースに、チーム全員でその実現方法について議論を重ねて仕様を詳細化していきます。ここが仕様検討で最も時間を使う箇所になります。
例えば、
・新しい機能をどの画面に実装するのか
・設定内容をどのタイミングでチェックするのか、設定エラーをどのように伝えるのか
といった点を細かく決めていきます。
このあたりから具体的な検討に入るため、今の仕組み上実現が難しいものや、実現するための制約事項が出てきます。そんな時にはユースケースを振り返って、実際の利用者の設定の流れをトレースしながら、その制約が許容できるものなのか、許容できない場合に他の方法でケアできるのか、といった議論を重ねて、仕様を決めていきます。
ある程度仕様が固まったところで、機能全体を通して操作の流れを確認します。このとき、検討漏れはないか、使いやすさはどうか、想定しているユースケースを満たせているのか、といった観点で確認しています。
ここにPMMが参加することで、本当に利用者にとって意味のある仕様になっているのか、掘り下げて議論ができるようになったと感じています。
④ユーザビリティテスト、仕様の調整
次に、ユーザビリティテストを行います。スムーズに機能を操作できるのか、どこで行き詰まるのか、をモックや先行して実装した機能を実際に触ってもらうことで行動を分析し、デザインや仕様の調整を行います。
また、仕様検討の過程で複数の実現パターンが考えられるとき、どのパターンを採用するか判断に迷うことがあります。こんなケースもユーザビリティテストを通じて、その反応やフィードバックを分析して仕様を調整します。
⑤仕様決定
ユーザビリティテストの結果は、チーム全員で確認します。分析した結果を共有し、得られた課題を解消するためにデザインや仕様を調整していき、最終的な仕様を決定して実装に入っていきます。
以上が仕様検討の流れです。
4．良かったこと、課題に思うこと
2022年9月からチーム体制に移行し、変更を加えながら今の開発方法に至りました。チームになじんでいるか、という意味ではまだまだ改善の余地はありますし、この方法が最善とは言いません。むしろ試行錯誤している段階です。
その前提ではありますが、良かったこととしては、
・PMMが仕様検討に参加することで、チーム全員が利用者目線を意識できること
・チーム全員で議論することで、全員が当事者意識を持てること
を挙げたいと思います。
仕様検討するメンバーに、PMMのようにお客様と近い立ち位置にいるメンバーが加わることで、より利用者目線の意見を取り入れることができ、チームに良い刺激をもたらしてくれていると実感しています。
そして、チーム全員で議論することは認識齟齬を減らせるだけでなく、みんなが当事者意識を持てる点もメリットだと言えます。
デメリットは時間がかかることです。全員の時間を使いますし、当然コストもかかります。小規模なチームだから試すことができているとも言えます。
また、弊社はリモートワーク中心の開発ですので、全員が何をしているのか把握できるこの方法がなじみやすいのかもしれません。
他にも、いろんな立場の意見が出ることになるので、議論が発散しやすく、開発スコープが広がりやすい点も注意が必要です。最後はPdMが判断することになるのですが、意見をまとめるのは大変だと思います。そんなときも、チーム全員で議論した結果であれば、納得感を持ちやすいのではないかと信じています。
いかがでしたでしょうか。
本当に必要とされる機能を目指した取り組みとして、仕様検討の現場を取り上げてみました。みなさまの参考になれば幸いです。
▼メッセージングチームのプロダクトマネージャーの経験談
【SaaSビジネス経験談】では、今後、下記の記事を公開予定です！気になる記事がございましたら、ぜひ「シナマケのプロダクト」をフォローして、公開通知をお受け取りください。
▼Synergy!製品情報
#SaaS #PdM #プロダクトマネージャー #PMM
#プロダクト #プロダクトマネジメント
#仕様検討
#SaaSプロダクト
#Synergy ! #シナジーマーケティング
#私の仕事