【座談会】Magic Moment社に聞く！少ないコミュニケーションコストで回すプロダクトフィードバックループのヒント-前編

こんにちは。技術広報の椿です！ ICT開発センターではいろんなプロダクトを扱っています。その中でもエンジニア、デザイナー、セールス、ビジネスと各職種メンバーがスクラムチームを組み、プロダクト開発をしている「review-it! （レヴュイット）」チーム（以降、reviチーム）がSaaSプロダクトの急成長を目指して、Magic Moment社にその実態と秘訣を根掘り葉掘り聞いてみました！

今回の記事は、Magic Moment社（以降、MM社）との座談会した時の内容です。短い時間でしたが、実りのある話をたくさんさせていただいたので、1回の記事に収まりませんでした！（笑） そのため、全2回に分けてお送りします👏それではご覧ください！

座談会の目的と経緯

reviチームでは、これまで蓄積してきた受託開発のノウハウに加えて、SaaSプロダクト開発をもっとアジャイルに回していくため、スクラム開発を実践しています！ そんな中、以前から交流があったMM社も同様にスクラム開発でプロダクトを手掛けていることから、ぜひその秘訣と成功のカギを学べないかとご相談したところ、快く座談会を開いてくださいました！

※MM社さん、ありがとうございました！

参加者

Guest

TOPPANデジタル株式会社（review-it!チーム）

• 今井 洋志（PdM：プロダクトマネージャー）
• 金山 尚徳（PO：プロダクトオーナー）
• 平野 雄大（PMM：プロダクトマーケティングマネージャー）
• 中森 あすか（デザイナー）
• 青山 桃（テックリード）
• 原井 隆浩（エンジニアリングマネージャー）

※TOPPANメンバーは人数20名程度で参加しておりました

アジェンダ

-----前編-----

悩み①：コミュニケーション

1-1．意思決定・合意形成のためのコミュニケーションコストが高い問題
1-2．セールスとエンジニア間で起こる「思ってたんとちゃう」
1-3．議事録"だけ"共有は注意？MM社のプロ意識

-----後編-----

悩み②：顧客の解像度と課題理解

2-1．プロダクトチーム全員が顧客課題を深く理解するためにしていること
2-2．顧客価値を考え続けることは『自分がいることの付加価値』を考えること
2-3．「自分たちは受託にはならない」その言葉の真意

悩み③：意思決定

3-1．意思決定と、チーム全体の納得を得るためには
3-2．意思決定の根底にある『ラディカル・プロダクト・シンキング』
3-3．開発におけるデザインの重要性理解を得るためには

悩み①：コミュニケーション

1-1．意思決定・合意形成のためのコミュニケーションコストが高い問題

（T：今井）認識齟齬を生まずに全員が同じ方向を向くことを目指すあまり、会議の回数が多く、時間が長いということに悩んでいます。視点の異なる関係者を持つスクラムチームでは、どのように解消していけるでしょうか。

（M：渡邊氏）弊社のコミュニケーションはこんな感じです。

• 会議極小派！会議時間はデフォルト30分。
• 会議の種類には、3つ（①共有、②発散・収束、③決議）。基本的に共有事項は、極力会議では取り上げない。
• アジェンダは前日の夜19:00までに共有し、次の日の朝に会議へ参加するメンバーは目を通す習慣づけ。

一方で、スプリントイベントはしっかり時間をかけて行います。slackなどで行われた議論や決定事項を確認しないと、流れていってしまうかも？といったような心配事は、毎日15分のデイリースクラムでピックします。

スプリントレビューの粒度と構成は次の通りです。

• 2週間でスプリントを回してる
• スクラムチームは5名くらいで構成
• それぞれのチームに、スクラムマスター、PdMが所属

上記の前提で、以下の流れで進めると約1時間弱でスプリントレビューが進行します。

1．事前に今回のスプリントで実装確認をする機能をアジェンダにまとめておく
2．今回のスプリントゴールは達成されたのか、という確認を行う
3．機能を上から順にデモしていく

1-2．セールスとエンジニア間で起こる「思ってたんとちゃう」

（T：平野）コミュニケーションの行き来をおさえた場合に、セールス→PdMと伝えられ、スプリントレビュー→リリースとなった実装機能に対し、CSやセールスから「思ってたんとちゃう」という声があがることを恐れてコミュニケーションコストが発生してしまいます。そんな経験、MM社ではありますか？

（M：渡邊氏）弊社では、実は少し前までは同様なことが散見されていました。それがなくなった要因としては、改修の企画、仕様の段階でビジネスチーム（CSやセールス）が打ち合わせに参加することで回避できるようになったのだと思います。開発段階でも確認には入ってもらいますし、大きなリリースの時は全社に向けたデモデーという場を設け、全社レビューのようなことを行っています。

デモデー

• 大きなリリースの時は、全社レビュー（デモデー）を実施する
• デモデーでは質問や意見はだれでも挙げられる環境を整備している
• 大切なのは、声を上げやすい雰囲気をつくること

1-3．議事録"だけ"共有は注意？MM社のプロ意識

（T：平野）セールスから開発へ市場の声を伝える時には、どのくらいの粒度で開発へ共有するようにしていますか？顧客からの声をそのまま議事録共有する形で伝えるのかなど…。どこまでセールス側が踏み込むべきでしょう。

（M：伊藤氏）弊社では、絶対に議事録"だけ"共有は実施しません。ビジネスチーム（CSやセールス）は、お客さまからのフィードバックを開発サイドへそのままの言葉で伝えることはしません。

お客さまがプロダクトを使用した時に実現したい状態と、その実現したい状態に対する課題を構造化して連携します。開発側から構造化のためのフォーマットを作成してもらっています。議事録共有だけで済ませてしまうと、背景にあるプロダクトが描いているビジョン、ロードマップと混在してしまい、チーム全体の迷いの元となるからです。

ビジネスチームからは、ユースケースを網羅して全ての観点からフィードバックをするにはどうしても限界があるので、そこは開発サイドとのバランスのとり方が重要になってくると思います。

このような悩みは、プロダクト開発あるあるでしょうか。どうやら、reviチームの抱える悩みはMM社のプロダクト開発でも覚えがあるようで会場はとても盛り上がっていました。後半も更に深く相談に乗っていただきました。

この続きは後編で。

▼Magic Moment社 公式サイトはこちら
https://www.magicmoment.jp/