3つ目のプロダクトに関わってる「今」
皆さん初めまして。RePharmacyの虎谷です。
調剤薬局向け＆患者向けに「つながる薬局」というサービスを提供していて、僕はこのチームでPMをやってます。
このサービスは2021年3月15日にリリースして1年半ちょい（ここまで一瞬だったな〜）。調剤薬局界隈で提供されているサービスでは国内で1番患者様にご利用頂いている今日この頃です。（当社調べ）
このプロダクトに関わってから、仕事のスタイルや進め方がガラッと変わったこともあり、僕の「今」を載せておこうと思い、noteを書いています。
初めてのnote投稿なので、雑なところもあるかと思いますが、その点は優しい目でお付き合い頂けると嬉しいです。
これまでと変わったこと
1. スクラムを最初から採用しなかった
今RePharmacyではエンジニアが8名いますが、過去いろんなところで様々な開発をされてきた方々ばかりなので、スクラム開発を採択せず、PMとエンジニアで各機能を最短でリリースできる開発サイクルを回し続けています。
これが今はこのチームにはピッタリはまり、このサイズのチームでは中々な機能開発を行えてるのでは？と感じています。
※ただ、少し運用自体が少し属人的なところが一定量あるため、これからチームが拡大したり、分割したりするフェーズでは一定仕組みがが必要だなとは思っています。
ちなみに、これまでのプロダクトでは、経験が豊富な方とそうでない方が混在していたため、スクラムを採用し、プランニング、レビュー、レトロスペクティブなど、スクラムイベントをしっかり行い、チームのベロシティを安定させることに重点をおいてきました。
※実際関わっていたプロダクトがフェーズ的には一定成熟していることから安定稼働が目的だったことも大きな要因だったかなと思います。
2. ICEスコアを取り入れた
プロダクトロードマップを作成し、エピックが立ち上がった後、各エピックに紐づけるPBLに対して、属人的かつ主観を極力排除した運用（＝優先順位付け）をしたいなと思っていた中、何かのサイトでICE Scoreを目にし、「これだ！」となってから半年ほど運用していますが、今の所順調に回っているかなと思ってます。
もちろん、割り込みで対応マストPBLは生まれますが、この手法を取り入れることで、簡単な開発からやっていこう！という安直な進め方はまずなくなり、かつこのPBLを倒す確らしさを定量的に把握できていることから、開発優先順位決めの際の時間が大幅に短縮できたことは大きいかなと感じています。
また、定義したスコアに対して、新PBLが生まれた際にスコアリングするサイクルも一通り出来上がったので、今の所は来季以降も継続する予定です。
3. ブラウザテストを取り入れた
これまでは安定稼働が目的かつ機能もそこまで多くはなかったので、リリース前のリグレッションテストはPM側で十分吸収できました。
が、今回のプロダクトは搭載している機能は同じくらいであるものの、ユースケース多岐に渡ったり、かつ医療情報を取り扱うことからより十分なテストをしてから安全にリリースしたい。というチーム全体の目線もあったことから、AIテスト自動化サービスを活用することに至りました。
現在はDatadogのブラウザテストでDOM, Transactionなどの一連テストをユースケースに応じて作成し、dev環境に機能がデプロイされたタイミングで自動的に走る仕組みを構築しています。
これによって、これまでPMリグレッションテストや外部QA企業に外出ししていたものが1/3程度になり、総合的にコスト削減にもつながりました。
また、リリース後に発生した不具合（元々かなり少なかったのですが）もほぼほぼ0になりつつあり、導入した意味をストレートに感じています。
これからはMagicPodという別のサービスへの乗り換えを絶賛検討中です。
※ちょうどUIの大幅アップデートがあり、ブラウザテストの全組替えが発生することからサービス乗り換えにはちょうどいいタイミングだな〜と
4. figma使い倒して目線合わせを徹底した
チームのサイズ的にデザイナーを採用できる規模ではないため、実質PMである僕がfigmaでデザインを起こし、フロントエンジニアとデザインシステム（目下構築中）と照らし合わせながら統一感を意識しつつデザイン仕様を決め、それをCSやSalesと共有した上で、最終的な画面を作っています。
これまでのプロジェクトでfigmaは少し触ってきたくらいだったので、最初大丈夫か？ってのはありましたが、UIは最終的に利用者が目にするところなので、「ま〜これくらいでいいか」っていう妥協が許されないところが逆にポジに働き、今はfigmaを心の底から楽しめています。
5. プロダクト担当なるものを各セクションに置いた
まずはCSにCSで持っている課題とその優先度を決めるプロダクト担当を設置し、隔週でPMとエンジニアの一部とmtgしながらどのタイミングで実施していくかを話し合っています。
※この手法はある企業のCS統括の方とmeetyさせて頂いた時にアドバイス頂いた内容でした
その際にはもちろんプロダクトロードマップと照らし合わせながら、優先度を決めるため、プロダクト全体として大きくずれることにはならないような運用にしています。
6. 利用者へ向き合う時間をこれまで以上に増やした
「当たり前のこと過ぎない？」ってのは重々承知の上で、これまでのプロダクトは利用ユーザーと接点が少し遠く、一次情報を取りに行くことが難しいプロダクトでした。
今回は調剤薬局、それを利用する患者様ということで、一次情報をこれまで以上に取りやすい状況のため、わからないことがあればすぐにでも薬剤師の方と会話をし、業務の解像度を上げ、仕様を考え、FBをもらう、という良いサイクルが回せているのかなと思います。
最後に
長文にお付き合い頂き、ありがとうございました。
これまで関わってきたプロダクト2つと進め方が大きく異なってたことからnoteを書くに至りましたが、改めて違ってたな〜と。
まだまだ属人的なところも多いので、うまく仕組み化していきつつ、サービス・チームが大きくなったとしてもやっていけるチームにしていけたらなと思っています。
この記事が気に入ったらサポートをしてみませんか？