はじめに

こんにちは。カケハシでPatient Engagementという新規事業に関わるプロダクトマネジャー（以降PdM）を担当している渡部と申します。現在はこれらの事業を加速させるために、いわゆる0→1フェイズ、かつ、SoE(System of Engagement)の側面が強いプロダクト・サービスの企画開発をしております。

カケハシではスクラムでのアジャイル開発が共通して採用されていますが、前述のプロダクト特性上、お客様ごとに置かれている状況も考え方も異なる状況下であるべきを模索し続ける必要があります。いわゆるVUCAそのものなサービス開発に日々取り組んでいます。

そんな不確実性が高い状況下で仮説検証サイクルを最速にできるよう、我々のチームのスプリントのタイムボックスは1週間、スクラムチームの成果物の一つであるインクリメントを生み出していくという活動をしています。このとき、日々プロダクト・サービスの企画開発をしているとリリースをするまで検証ができないといった状況は多くあります。ただし、それはわからないからとりあえず出してみる、というわけではありません。むしろ、何かをやることは何かをやらないことと同じであって、事前にどれだけリサーチ、仮説立て、検証結果に対する意思決定の変化をシミュレートしておけるかが肝要だと考えています。

前置きが長くなってしまいましたが

上記営みの全てのきっかけとなるのが、スクラムチームの残る成果物であるプロダクトバックログであると考えています。そのため、我々のチームはバックログの作成、順序に魂を込めています。(私はそう思っています笑) そんなバックログに纏わる取り組みの一部を今日はご紹介できればと思います。

この記事はカケハシ Part 2 Advent Calendar 2023 16日目の記事です。今年のカケハシのアドベントカレンダーにはPart 1とPart 2があるので、ほかの記事も是非お目通しいただけますと幸いです。

①すべては顧客アウトカムのために

何をいきなり当たり前のことを怒られてしまいそうな冒頭になってしまいましたが、改めて声にだして読みたい言葉、顧客アウトカムです。

PdMとして要件を検討していると、ついつい、追加でこれが実現できたらもっとあのお客様のお役に立てるかもしれない、今回このユースケースに対応するなら別のこのユースケースにも対応しておかないと何となく気持ち悪い、といった具合に図らずもスコープが広がっていくことがあります。このときに、それらが本当に顧客のアウトカムに繋がる最短のバックログとなっているのか？他により大きな価値を届けられる方法はないか？と問い直すことを大切にしています。

例えば、我々のプロダクトのユーザーとなる薬剤師さんが特定の情報（以降情報Xとします）を患者さんにお伝えすると、患者さんはお薬を不安なく飲み続けることができることが分かっているとします。加えて、今回の仮説としては、薬剤師さんはいくつかの情報の中から情報Xが存在することを認識できていないために伝達率が低いのだ、ということを検証したいとします。このとき、顧客アウトカムとしては薬剤師さんが情報Xを患者さんにお伝えできること※であって、今回のスコープにおいて、直接因果関係を持つのは情報Xの認識率が向上すること、となります。（ ※最も広い視点で見るアウトカムは患者さんの服用による治療効果）この前提で要件を整理していくと以下あたりのバックログが考えられます。なお、ここでは非機能要件などは簡単化のため割愛しています。

ユーザーはユースケースA（ハッピーパス）において、情報Xであることを認識できる。
ユーザーはユースケースB（ハッピーパス以外）において、情報Xであることを認識できる。
ユーザーは情報Xの対象を追加できる。
ユーザーは情報Xの対象を削除できる。
カケハシは情報Xとそれ以外の情報におけるユーザー認識率をプロダクトメトリクス上で評価できる。

こういったことを検討していると、検討のサンクコストも相まって全て形にしたくなってしまいます。ですが、実際に我々のチームで開発スコープとして下した決断は1.のみ。 他の2.はスコープアウト、3.4.はエンジニアによる手動設定、5.はPdMによるSQLを用いたデータ抽出およびExcelでの分析でした。その理由として、情報Xの認識率が本当に向上するのかわからないという現状で顧客アウトカムを評価できる最小のバックログは1.のみであったからです。具体的には、それぞれ以下の判断を行っていきました。

2.：顧客アウトカムに繋がると判断するためには1.の対応で効果があることが証明されなければいけません
3.&4.：1.の価値を前提として、それらの利便性を向上させつつスケールさせることに顧客アウトカムが生まれます
5.：リリース後に1度取得できれば今回の仮説を検証することができます。プロダクトメトリクスとしてCSでの継続的な活用などは1.の価値が前提となります

このように、最短で最大の顧客アウトカムに少しでも近づけられるよう、以下の図の3段目のような動きを意識しながら日々イテレーションを回しています。

引用：MVP - not "bike to car"

②ROIを最大に

①に対して、とはいえ顧客アウトカムにも大小あり、それらをどうやって評価するのか？仮に顧客アウトカムが大きいとしても対応に3ヵ月かかります、では不確実な状況の中で仮説検証スピードが低下してしまいますし、そもそもInvestmentの評価自体もPdMだけではままなりません。それに対して、ReturnとInvestmentを評価するために取り組んで良かったことをいくつかご紹介できればと思います。

Return評価：NSMとKPIと行動ログの可視化

我々のプロダクトではNorth Star Metrics（以降NSMとします）とそれを構成するKPI、KPIを構成する下位の行動ログのといった構成でβ版ローンチ時からメトリクスの定義、Datadogを用いたトラッキングが可能な状態にしています。正式リリース前のプロダクトのため具体的なNSMのご紹介は割愛しますが、一般的なNSMの特徴として、ビジネスゴールとして設定されることが多いKGI（売上や導入店舗数など）は遅効性指標であることに対し、NSM（薬剤師さんが患者さんにXXのアクションをYY件起こしたなど）は先行指標という特徴を備えており、KGIの結果を観察する前に状態を捉えることができるという利点があります。 Returnを可視化するという目的であっても、β版のタイミングからこれらの取得ロジック、基盤に投資するのは前述①の考え方から一見悪手のように思えます。私自身もどこまでやるか？という葛藤はありましたが、振り返るとチームへの良い効果が二つあったと考えています。

アウトプットにおけるポジションの明確化

PdMが要件をアウトプットする（バックログにPRDをリンクさせています）際にどのメトリクスがどのように変化したら成功と言えるのかを明記する運用にしています。この運用の狙いとして、アウトプットに必ずポジション（発案者のスタンスとも言えます）が付帯されることです。これによって、レビュアーやエンジニア陣との議論の際にも何故そう思ったのかの深堀やそれであれば他のメトリクスで評価すべきではといった具体的な議論が活発になり、より練られた要件になることを実感しています。 私が好きな科学哲学者の一人であるカール・ポパーも「反証可能性の高い仮説が反証の努力を生き延びるとすれば、それは非常に優れた仮説である（なぜならば、それは科学をより真理に接近させるからだ）」という言説を残しており、この取り組みもこの言説に通ずる部分があると感じています。

意思決定の民主化

直近のプロダクト改善において、ユーザーがサービスのトップページにアクセスした際に多くのケースで表示内容のリロードが行われていることが行動ログ上観察されました。これをきっかけに顧客の定性状態をヒアリングに行き、早期の改善に繋げることができました。また、この判断はチームへのジョインから比較的日の浅いメンバーによって実施されています。他にも同じくジョインから日の浅い別のメンバーはNSM/KPIの定量分析から仮説だし、顧客へのデプスインタビューのプランニング＆実行に繋げています。このエピソードは、一般的には経験の長いメンバーの声が大きくなりがちな日々の業務において、判断を民主化し、早期に成功体験を生み出していくことのできる基盤として取り組んで良かったと思える事柄でした。

Datadogでのメトリクスイメージ

Investment評価：リファインメントは日次15分

我々のチームではより中長期を見据えたバックログリファインメントは別途設けつつ、デイリースクラムのあとに軽いリファインメントを行う時間（以降デイリーリファインメント）を毎日15分設けています。この会において、PdMは直近数スプリント先の検討内容の共有、それに対してざっくり技術的なフィジビリティや対応ボリュームなどを相談します。また、エンジニアからは技術的な改善など今考えていることを伺い、次スプリント以降の見通しを立てる材料を少しずつ作っていきます。この取り組みも良いなと思っているポイントが二つあります。

デイリースクラムさながらのスプリントプランニングに向けた検査と適応

PdMやエンジニアのみなさまはこんな経験はないでしょうか？スクラムのタイムボックスに従ってプランニング前にリファインメントを実施した結果、いくつかの仕様再検討事項が見つかり実は開発レディなバックログがない、急いでとりあえず開発が出来そうなところから対応を進める…私は過去のチームではありました。このときのPdMの心情としては、バックログの順序・分割を検討するため、こまめにエンジニアと会話しInvestmentやフィジビリティを把握したい。他方で、デイリースクラムで実施するにはスプリントゴールに対する検査の機能を阻害してしまいますし、かといって、週次・隔週で実施するなどでは企画段階でのフィジビリティ検討のサイクルが遅くなり、前述の問題が…。これに対し、今の取り組みは「スプリントゴールに向けた検査と適応がデイリースクラムにて実行される」というプラクティスが、同じ構造で「スプリントプランニングに向けた検査と適応がデイリーリファインメントにて実行されている」と言えます。その結果、デイリースクラムでのプラクティスをプランニングにも活かすことができ スプリントプランニングに向けて障害となりそうなものを素早く検知し対応することが構造的に実現できている、と感じています。

バックログサイズの適正化

加えて、この取り組みを行ってから新たに効果を実感した部分として、15分という短い時間であるために、必然的に相談事項がフォーカスされ、密度の濃い時間を過ごすことができる、という点です。例えば、前述の「①すべては顧客アウトカムのために」の節でご紹介したバックログ全てを15分の相談の中に持ち込もうとすると、ユースケースAとBでどの程度の割合なのか、追加・削除に加えて編集は不要か、またそれを可能とするユーザー権限を規定するのか、メトリクス集計といってもケイデンスはどうするのか、計算式はどのように定義できるのか？等様々な疑問が生まれます。当然、隣接する（同じエピックや近い未来に対応する）バックログ群を意識することは重要なので、共有はするものの、全てを平たく議論しようとすると核心に迫ることができず時間が不足します。そうなると、必然的に相談者には今回は1.ユースケースAに関する相談であって、論点はXXXとYYYです、といった形で論点をシャープにする力学が発生します。 15分という短い時間のため、準備に要する労力もライトになりサンクコストが最小化できるところも気に入っています。このとき、とてもこの時間で相談できない、という場合は、バックログのサイズが大きくなっていないか？というセルフチェックを自然に実行できるようになっているところが良い取り組みだと感じています。

むすびにかえて

本稿の内容を振り返ってみると、チームとしての動きの中に、私個人がカケハシのバリューの中で最も好きな「高潔」と「価値貢献」という行動規範に通ずるものがあると感じています。

日本の国民皆保険が素晴らしいシステムであるということは言を俟たないことです。他方で、少子高齢化や新薬の高額化等による医療費・社会保障費の膨張、カケハシでの仕事を通じて痛感した薬局・薬剤師、医療従事者の皆さまの献⾝と⾃⼰犠牲。まだまだ貢献できる部分は数えきれない程あると感じていますし、世界に先立つ超高齢社会といった転換点にある日本およびこの時代で仕事ができることに心からやりがいと喜びを感じています。

カケハシのミッションであるしなやかな医療体験を実現するには多くの仲間が必要です。ビジネス、エンジニアともに仲間になってくださる方を心からお待ちしています！まずは話を聞いてみるだけでも良いので、是非お気軽にお声がけください。