薬局体験アシスタント「Musubi」のデータ活用チームで、スクラムマスターを務めているカケハシの松田です。私たちのチームは、昨年12月から 薬局業務“見える化”クラウド「Musubi Insight」の開発に着手し、3カ月という短い期間でβ版をリリースしました。その経緯を振り返りつつ、今回のプロジェクトで徹底したスクラムとOKRによるチーム運営についてご紹介できればと思います。

・・・

薬局業務“見える化”クラウド「Musubi Insight」とは？

今回私たちがリリースしたMusubi Insightは、調剤薬局向けのBIツールです。

日々多くの薬局経営者や薬剤師とコミュニケーションをとる中で、調剤薬局経営におけるデータ活用の課題が見えてきました。経営や業務状況の定量化・可視化が他業界ほど一般化されておらず、主観によるマネジメントによる意思決定の質のばらつきや適切な説明の難しさ、そのために発生する多大なコストが課題となるケースも時にあるようでした。

また、現場薬剤師の観点でも「自分はどれだけ薬歴（＝薬局に義務付けられた調剤や服薬指導の記録）を書いたか？」など、自身の業務を定量的に把握できていないケースもしばしば。そのため日々の業務活動の振り返りができなかったり、経営者に業務負荷や頑張りを適切に伝えられていない状況がありました。

こうした状況を改善すべく企画されたのが、薬局業務“見える化”クラウド「Musubi Insight」。薬局向けの業務システムであるMusubiのログデータや薬局収益のデータを可視化し、薬局経営者や現場薬剤師の意思決定や業務改善を支援するサービスです。

プロジェクトの流れ

カケハシのサービス開発ではスクラム開発を導入し、2週間スプリントでプロジェクトを回すとともに、中長期の目標管理は全社的にOKRを用いて運用しています。半年に一度、全社を挙げてOKRを策定し、必要な場合は四半期のタイミングで中間見直し。策定時にはまず最上位のObjectiveが定められ、そこに付随するKeyResult・第2階層以下のObjectiveを各チームで起案し、すり合わせるという流れです。

今回の開発プロジェクトも、このOKRの策定からスタートしました。

「今四半期中には、実際にユーザーにプロダクトを触ってもらって、フィードバックを得たいよね」
「そのためには、プロダクトがリリースされ、利用方法などある程度まとまってないといけないよね」

こうした話を、プロダクトオーナーだけでなくエンジニアも含めたチーム全員で妥協なく徹底的に話し合いました。

その結果、策定したのが「薬局経営の意思決定を支援するβ版の利用準備が全顧客向けに整っている」というObjective。3カ月というタイトな期間で何もないゼロのところからカタチにしてリリースするという、自分たちにとってもストレッチな目標を設定しました。正直、決めた当初は達成できるかどうか不安しかありませんでしたが、同時にチーム全員がワクワクできる（コンフォートゾーンにない）目標で意識統一を図ることができたことはとてもポジティブでした。

ちなみに、導入から日が浅いこともあり、OKRの仕組みがそれほどチームに浸透していないという課題もありました。チームメンバーの一人から「OKRについてより理解を深めるためにチームの輪読会をしよう」と声があがり、毎週当番制で『Measure What Matters（メジャー・ホワット・マターズ） 伝説のベンチャー投資家がGoogleに教えた成功手法 OKR』（ジョン・ドーア著/日本経済新聞出版）を読むことに。プロジェクトの進行とともに、より練度を高めるように努めました。

ストレッチ目標のための技術調査・策定

3カ月というタイトなスケジュール、かつチームにエンジニアは私を含めて3人だけ。この状況でプロダクトを完成させるには、OKRでいうところのストレッチなObjectiveを達成するための技術選定が極めて重要でした。

光明が見えたのは、OKRのチェックイン時のチームディスカッション。「どうすれば最短で顧客に価値を提供できるか」を議論するなかで、プロダクトオーナーがBootstrapのテンプレートについて話したことをきっかけに、BIツールのテンプレートを調査してみようという流れに。そうしてたどり着いたのが、AngularのBIのテンプレートです。

幸い、Angularはカケハシのメインプロダクトである薬局体験アシスタント Musubiでも利用しており、私たちのチームのエンジニアも全員が経験ある技術でした。フロントエンドは、こちらを軸にプロトタイピングして進めることに。

さらに精度を高めるべく、CTOや他チームのエンジニア、AWSのソリューションアーキテクトの方にもレビューを求めたところ、フロントエンドはそのままに、バックエンドをサーバーレスな構成で進めたほうがいいのではというアドバイスが。他のチームにサーバーレスでの実装やamplifyを利用したデプロイの経験があったため、その知見をふんだんに活用する形でバックエンドの方針も定まりました。

基本に忠実なスケジュール見積もり

決定事項をもとにβ版リリースに向けたタスクを洗い出し、できる限りユーザーストーリーにブレイクダウンしたうえで優先順位をつけ、エンジニアでvotingを行うようにしました。

さらに、不確定要素ではあるものの、ほぼ確実に発生する数値検証やバグ修正などのタスクに関しても、ざっくりとポイントを定めて可能な限りの見える化を徹底しました。

幸い、これまでに計測していたチームのベロシティが1スプリント25ポイントと安定していたため、実績ベースで現実的なリリースラインを出し、スケジュールを見積もりました。

2週間ごとのデモを「マスト」に

カケハシのスクラムは2週間スプリントで回しており、スプリントの最終日には全社的に成果物をデモするスプリントレビューが設けられています。

私たちのチームでは、リリースまでの全6回すべてのスプリントレビューに何かしら目に見える成果をデモすることを決めていました。デザインが不十分でありつつ、テストデータでも構わないので、とにかくカタチにする。そして、フィードバックをもらおうという意図です。カタチにすることにこだわるチームの姿勢が、プロジェクトを通じてとても印象的でした。

スクラムの原理原則に基づく計画の見直し

残3週間ほどのタイミングで、「このままでは終わらない」とチームメンバーがアラートを上げてくれました。リリーススケジュールを先延ばしにすることもできましたが、プロジェクト冒頭のOKR策定で議論しきったとおり、私たちにとって最優先なのは「ユーザーのフィードバックループを回すこと」

そこで、スクラムの原理原則にのっとり、スコープを削るという意思決定をとりました。見積もり段階でストーリーを細かく切っていたことが奏功し、スコープを柔軟に可変できたため、リリースラインを緩める作業も比較的やりやすかったと思います。とはいえ、「リリースノート告知すら削る」という、なかなかハードな意思決定となりました。最終的に、当初想定した機能の1/3程度が削られる結果に。

そしてリリースへ

残り1スプリントを残し、あとはバグ潰しです。どれだけ気になっても新機能は入れないという断固たる決意で臨みました。数値検証とバグの洗い出しの状況をみてはプロダクトオーナーがデイリーで優先順位を並び替え、エンジニア陣ができうる限りのスピードで次のカードに着手……という流れを繰り返し、無事にデザイン修正、バグ潰しが完了。

最後に、プロジェクト途中にジョインしたデザイナーによるサービスのロゴデザイン。プロダクトの理念や想いをのせたロゴを画竜点睛の如く組み込み、無事リリースとなりました。

プロジェクトの振り返りと、成功のポイント

 1. OKRの理解を深め、運用を本気でやった
今回のプロジェクトを見返すと、OKRを徹底的に運用したことが効果を発揮したように感じています。チームにOKRを浸透させるべく輪読会を実施して理解を深め、策定の際にはチームで議論を重ねることにより全員のコミットメントを高め、目標に対する意識統一を図ることができました。

日々の運用も、毎週のスプリントプランニング、スタンドアップ、レビューに関してもすべてOKRを軸としたコミュニケーションを徹底しました。レビューの際に必ずムーンショットを考える時間をとるようにしていたのですが、BIツールのライブラリーの技術選定により大幅に工数をスキップできたことが、まさにその最大の成果だったと感じています。

 2. ベロシティからのスケジュール見積もりというスクラムの王道に、忠実に従った
今回のプロジェクトを迎える以前から、チームのベロシティが安定していたことが奏功しました。

安定させるための施策として、以下のスクラムの作法に倣った運用を意識していました。

* voting5以下のカードしかプランニングに積まない。大きければ分割する
* プラニング時点でスプリントレビューでのデモを意識し、成果物を明確にしておく
* スタンドアップなどでカードベースの丁寧な報告を徹底する

仕様が決まった段階でタスクをブレイクダウンし、votingすることで、リリースまでにかかるポイントを算出。毎スプリントのベロシティが安定していると、これだけで全体スケジュールを見積もることができます。votingできないタスクに関しては、一旦「スパイク」というラベルを付けておき、早い段階で不明点を解消に着手する。そうしてvotingできるところまでの落とし込みを徹底したことが、スケジュールの安定につながりました。

さらに、その全体見積もりをベースにして、「今のままだとプロジェクトはどれくらい遅れるのか」をバックログで可視化し、プロダクトオーナーによる機能の取捨選択を高頻度に行ったことが、無事にリリースできた要因だと感じています。

3. カケハシの掲げるバリューにこだわった
カケハシにはメンバーが体現すべき価値観を表した6つのバリューがあるのですが、今回のプロジェクトでは特に「カタチにする」「情報対称性」「変幻自在」という3つにこだわったアクションができたかなと思っています。

カタチにする 
一つは前述した通り、2週間に1度の全社スプリントレビューに、必ず目に見える成果物を持っていくようにしたこと。全員がこの前提でプランニングできたことが、最小限でのリリースを実現できた要因だと感じています。

例えば、まずはじめにXDでモックを作ったこと。これをベースにすることで、チーム内のコミュニケーションコストを著しく抑えることができました。その他にも、開発環境を率先してつくることで、プロダクトオーナーがイメージするUXと齟齬がないかを早い段階で確認できたり、ステージング環境を用意してバグ検知を早めたりと、常に先手をとって軌道修正していくことができたように思います。とにかく、まず目に見える成果物をだすこと……カケハシバリューの「カタチにする」を実践することの重要性を、身をもって感じることができました。

情報対称性
こちらも前述したとおり、デイリーで行うスタンドアップで各人の業務進捗や目の前の困難な状況を高頻度にシェアするようにしたことにより、仕様の不明点の解消や、バグ発生時の問題解決がスムーズに進みました。エンジニア側に仕様の不明点はほぼなく、バグが発見されたらその日中に解決という状況を作ることができていたように思います。

ラバーダックプログラミングのように、Slackの分報チャンネルを使って各人が自分の考えていることをリアルタイムに垂れ流していたのも良かった点。おかげで、高密度な情報連携ができていました。

カケハシバリューに、あらゆる情報をオープンにすることをよしとする「情報対称性」というものがあるのですが、まさにその賜物であったと感じています。

変幻自在
最後に、カケハシバリューでは「変幻自在」という言葉で表されている、固定化した立場に縛られない動きを実現できたことも良かったポイントです。チーム事情でそうせざるを得なかった面もありますが、エンジニアから仕様に対してアイデアを出したり、プロダクトオーナーがAdobe XDでデザインモックをつくったり、スクラムマスターが開発に携わり、メンバー各人がセルフマネジメントをしたり、といった所与のロールを超えた動きが自然にできていたことも強く印象に残っています。

能力以上のパフォーマンスを発揮できた達成感

仕様策定から開発までの3カ月という短い期間でのリリースでしたが、実はエンジニアの残業時間はほぼゼロ。理想的なプロジェクト進行、チーム組成ができたと感じています。

チームメンバーから「自分の力以上にパフォーマンスを発揮できた」という声も上がりました。チームとして 1+1＞2 のシナジーを得られ、これがまさにスクラム×OKRの効果なのかなと感じます。

その後、Musubi Insightはβ版から順調に進化し、無事に正式版をリリースすることができました。今後もチーム運営の練度を高め、プロダクトの改善と、それを通じたユーザーの課題解決に貢献していきたいと思います。

・・・