スクラムマスターのPO支援。リサーチの道程と「+」と「Δ」

Cover Image for スクラムマスターのPO支援。リサーチの道程と「+」と「Δ」
mo
monotalk

スクラムマスターのPO支援として、プロダクトのリサーチをすることがあり、実践の中には成果が出たもの（+）と、改善の余地がありモヤモヤするもの（Δ）があります。 この記事では、それらの取り組みについての現在時点の状態をまとめておきます。

筆者の属性と前提

本記事の背景として、筆者のバックグラウンドには以下の属性があります。

  • 1. データ活用・統計への関心: 個人での技術ブログ運営をきっかけに Google Analytics や Google Search Console のデータ分析に興味を持つ。
  • 2. 統計知識・機械学習の基礎: データ解釈のための統計検定2級を取得し、古典的な機械学習やデータ分析の手法を学習。
  • 3. B2B SaaSのMOps担当: Google Tag Manager の管理や、マーケティングツール・Webアクセス解析ツールの導入・運用経験。
  • 4. スクラムマスターの経験: 　B2B SaaSのプロダクト開発チームでスクラムマスターを2年くらいやっている

適切なデータを収集し、集めたデータを分析・活用することに関心を持っています。

スクラムマスターが実施するリサーチについて

ScrumMasterWay のレベルと、スクラムマスターが実施するリサーチのスコープをGeminiにマッピングしてもらいました。プロダクトのリサーチは、PO支援の範疇としてLevel 2の役割に該当すると捉えています。

ScrumMasterWay のレベル 本来の焦点・役割 リサーチの対象・問い
Level 1: My Team（私のチーム） スクラムの型を身につけ、チームが自己組織化し、継続的に改善できるようにファシリテートする。 「自分」と「チーム」のリサーチ・自分はファシリテーターとしてどう振る舞えているか。・チーム内のコミュニケーションや心理的安全性、ボトルネックはどこにあるか。
Level 2: Relationships（関係性） チームと外部（PO、他チーム、ステークホルダー、マネジメント）との関係性を構築・改善する。 「プロダクト」と「ステークホルダー」のリサーチ・POは顧客の声をどうプロダクトに落としているか。・チーム間の依存関係や情報のサイロ化はどう起きているか。
Level 3: Entire System（システム全体） 組織全体の文化、価値観、ビジネスのアジリティを高め、会社全体が複雑系として適応できるようにする。 「組織文化」「市場・社会」のリサーチ・組織の評価制度や構造がアジリティを阻害していないか。・会社全体がユーザーや市場の変化をどう捉え、適応しているか。

プロダクトのリサーチの「+」と「Δ」

プロダクトのリサーチといっても、様々なスコープがありそうですが、個人的な経験から支援をしているのは、プロダクトから収集できるデータの分析を通じたインサイトの取得が多いです。現在うまくいっている取り組み（+）と、改善の余地がありモヤモヤするもの（Δ）があり、それぞれ以下になります。

  • 「+」ユーザーアンケートの分析・リサーチ
  • 「+」ユーザー行動ログの分析・リサーチ
  • 「Δ」SLO（レスポンスタイム）策定のためのリサーチ

「+」ユーザーアンケートの分析・リサーチ

このあたりはAIが活用でうまくいっていると考えている部分になります。2025年あたりに、Notion AI がDBの分析もできるようになって対応してからです。Notion AIを使って、Google Formなどに記録したアンケート結果の解析をしています。 Notion AIはモデルで自動を選択すると、次の分析の方向性をいくつかだしてくれます。その中から良さそうなものを選択し、ある程度洞察を得た後で分析の方向性を決めてプロンプトの出力をしてもらう。その後にそのプロンプトを、Opus系のモデルで実行してレポートを出力してもらうという手順を踏んでいます。

効果とメリット

主な効果やメリットは以下になります。

  • 自由記述などの非構造化テキストをAIによって迅速に要約・レポートにすることで、人間が洞察を得るまでの時間を短縮できた。
  • 整理されたインサイトを素早く可視化できるため、関係者間の共通認識の形成や議論がはやくなる。

留意点・考慮事項

AIは確率的な動きをするので全体の傾向を掴む用途には適していますが、スコアなどの計算については表計算ソフトやPythonでスクリプト化して値の正確さを別途確認するとよいです。 ただ、最近はモデルがPythonスクリプトをアドホックに書いて、計算していたりするので以前よりも信頼性が高まっている気がしています。

「+」ユーザー行動ログの分析・リサーチ

支援しているプロダクトでは、Datadogを利用しており、1週間分のアクセスログは時間をかけずに取得できます。会社によって保存期間は異なると思いますが、その集計や集計結果から洞察を得るまでがAIによって加速されました。

1週間分のアクセスログをCSVエクスポートし、分析したい観点でAIに集計・レポートを依頼し、出力されたHTMLアーティファクトをデイリースクラムやリファインメントで確認し、施策のブラッシュアップに活用しています。

効果とメリット

  • ユーザーの主観的な体感だけでなく、実態としての画面表示時間やリクエスト処理のパフォーマンスを客観的な事実データとして把握可能になる。
  • プロダクトコードもインプットにすることで、アクセス傾向からUI改善の観点についても洞察が得られ、議論のタネになる。

留意点・考慮事項

Datadogのログエクスポートには10万行の制限があり、分析対象の集合によっては、十分な時系列範囲のデータを確保できない場合もあります。
あらかじめ、データの取得範囲を絞った上でエクスポートするようにしています。
また、データ量でそれなりにコンテキストウィンドウを消費するので、大量データを処理する際は、あらかじめ分析の観点で集計しておく工夫が必要になります。 プロダクトの規模的に大きなユーザジャーニーの分析などには利用できておらず、ユーザーとの1つのタッチポイントに焦点を当てた時の分析という用途での利用になると考えています。

「Δ」SLO（レスポンスタイム）策定のためのリサーチ について

サービスレベル目標（SLO：Service Level Objective）とは、提供するサービスに対してチームや組織が達成すべき信頼性やパフォーマンスの具体的な数値目標です。

  • 具体例
    • 可用性（アップタイム）: 30日間で99.9%以上の時間、サービスが正常に稼働していること
    • レイテンシー（応答速度）: 「過去7日間の全リクエストのうち、99%は100ミリ秒以内に完了すること」
    • エラーレート: 「30日間の全リクエストのうち、HTTPステータス5xxエラーの割合が0.1%未満であること」

SLOは導入されているか

現在、支援しているプロダクトチームにはSLOが設定されていません。 なお、社外へ公開する外部SLOと社内向けの内部SLOの双方が存在しない状態です。

なぜSLOが必要だと考えたのか

きっかけは、ヘルプデスクに届いた顧客からの「〇〇画面の表示が遅い」という問い合わせでした。 対象顧客のログを調査したところ、特定の処理で〇秒以上かかっているケースが実際に確認され、急遽パフォーマンスチューニングを実施することになりました。

結果として、問い合わせを受けてから動く「後手（リアクティブ）の対応」になってしまい、事前に手を打つプロアクティブな行動が取れていませんでした。

なぜ事前に気づいて行動できなかったのか

実は、開発チームも画面の遅延自体には事前に気づいていました。 スロークエリ監視の仕組みがあり、〇秒以上かかるクエリを検知できていたためです。

しかし、以下の理由から具体的な改善アクションへ繋げられずにいました。

  • 検知数が多すぎる: 日常的に多数のスロークエリが検知され、優先順位を判断しづらかったこと。
  • エスカレーション基準の不在: 「どれほど遅くなったらPdMへ相談して機能開発より改善を優先すべきか」という客観的な基準がなかったこと。

問題の存在を認識しながらも開発チーム内に閉じてしまい、問い合わせという形で表面化して初めて動く事態に陥っていました。 こうした状態を解消し、チーム外と共通の基準で対話するために、客観的なエスカレーション基準としてのSLOが必要だと強く痛感しました。

SLOを作成するにあたってのモヤモヤ

1. トップダウンでの目標値設定はビジネスサイドに伝わりにくい

過去の経緯を踏まえ、トップダウンによる指標策定は見送りました。 エラーバジェットなどの概念は、機能開発を優先したいビジネスサイドには伝わりにくいと感じています。 そのため、具体的な事象をベースに帰納法的にSLOを策定していくアプローチが適切だと考えました。 現在は、機能拡張や改修が行われる機能のパフォーマンスレポートをPOに共有し、認識のすり合わせを進めています。

2. 全体の基本統計量の会話では現場の感覚と乖離する

POに画面レイテンシーの基本統計量（p50, p90, p99）を共有しても、具体的な顧客の利用イメージには結びつきませんでした。 対話を通じて、顧客別や重要顧客ごとのレイテンシーを示すことで、具体的に困っているユーザー像をイメージしてもらいました。

  • 例: 「p90が〇秒」と伝えても、「具体的にどのユーザーが遅いのか」「問い合わせはあるのか」と問われて響かない。

3. ヘルプデスクの問い合わせバイアス（問い合わせ駆動）

支援しているプロダクトにはカスタマーセンターがあり、問い合わせや要望を起点として機能開発が進む傾向も見られます。 レスポンスの統計情報を共有した際も、「問い合わせがない」という理由で優先度を下げられるケースがありました。 ヘルプデスクの声は重要である一方、サイレントマジョリティを見落とす恐れもあり、定量データとのバランスに難しさを実感しました。

まとめ：今後の取り組みとしてやっていくこと.

ここまで、スクラムマスターのPO支援として取り組んできたリサーチの現在地を「+」と「Δ」の観点で整理してきました。 最後に今後の取り組みとしてやっていくことをまとめます。

  • 「+」ユーザーアンケート分析・行動ログ分析 今後も実施していくという形が良いかと考えています。データ分析時にプロダクトコードをインプットにする。
    ユーザーの定性データと、定量データを組み合わせるなどの、データ同士を組み合わせるとより深いインサイトが得られると考えています。 また、分析がかなり場当たり的なのでプロンプトをまとめる、Skill化するなどは検討していきたいです。

  • 「Δ」SLO（レスポンスタイム）策定のためのリサーチ プロダクトチームとしては、まだSLO策定以前の段階にあると感じています。 まずは事象ベースで判断材料を共有し、チームで判断する機会を増やすことが重要です。 SLOの数値を決める前に、その観点を共通の判断材料として使える状態を目指します。

以上です。

関連記事

コメント