参画割合20%スクラムチームのPOは顧客に価値を届けられたのか

この記事は2024.3Insurtechラボアドベントカレンダーの11日目の記事です。

こいです。InsurTechラボでは4Qより新たな試みとして、育成重視の20%参画割合で実施するスクラム活動を4チームで行うことになりました。

私が3Qからスクラムマスターとして参画しているものづくりのチーム(以下、ふぁんこみチーム)もこの4チームの1チームに含まれ、何か顧客にとって価値あるプロダクトを20%の参画割合でできるのかをチャレンジすることになりました。

この記事は私がふぁんこみチームで、POとして参加してみたトライアルの結果とふりかえりをしていきます。

今までと同じチームメンバー、少ない参画割合、新たなロール

4Qのふぁんこみチームは3Qと同じチームメンバーで構成されています。3Qでは、新技術を活用した以下のようなChatGPTを活用したSlack向けのボットを開発してきましたので、我がチームながらものづくりに対して好奇心高く進めてこれたという自負がありますので、今回もきっと大丈夫でしょう。

大きな違いの1点目は、メンバー全員がふぁんこみチームの活動を20%で行うこと。すなわち1ヶ月30時間、1週間7.5時間=1営業日で3ヶ月進めていくことになります。

もう1点目は、チームメンバーの役割変更です。私は今までスクラムマスターとしてチーム参画していましたが、今回はプロダクトオーナー(以下、PO)としての参画になります。この変更は私のラボにおけるスクラムマスター経験で「さまざまな形でプロダクトオーナーを支援する」スクラムガイド2020スクラムマスター”の項より引用)が実践できていなかったことを振り返り、自分がPOになればどのような支援を受けられればありがたいのかを実感できるだろいうという仮説から自ら望んでの変更でした。なお、私がやっていたスクラムマスターはふぁんこみチームの開発者だった方がやることになりました。

この2点の変更は大きく、果たして自分がPOとして顧客に届けたいプロダクトを見出しチームメンバーに伝えて、開発することができるのか不安はありました。
それでも、4Qのふぁんこみチームとして「チームで選定した”今までチームが取り組んでいない技術”を学習して、ものづくりを行えている」という新たなミッションを掲げて活動開始しました。

チーム内プロダクト検討LT大会

ふぁんこみチームとしてどんなプロダクトを作りたいのか。正直なところ、POこと私は何をすればいいのかノーアイデアでしたので、PO経験が豊富なラボ室長に相談し、チーム内でプロダクト検討のLT大会をすることになりました。色々なアイデアをチームメンバーで持ち寄り、「mob dora」というモブワークで使えるタイマーアプリを作ることに決定しました。

チームで考えたタイマーアプリのエレベータピッチは以下の通りです。開発者としてタイマーのユーザとして、このようなプロダクトであれば価値あるものになるかもしれないという開発テーマが決まりました。

仮説キャンバスの作成

プロダクトを作る順番としては逆かもしれませんが、チーム内LTで開発したいテーマが決まりましたので、POとして想定する顧客に対し価値として届けられるものになるか仮説キャンバスを書いてみました。

実のところ、私は今まで仮説キャンバスを1人で描き切ったことがなく、そもそも各項目を埋められるかも不安でした。が、それでもラボ室長に個人的にサポートしてもらったり、ラボ内のPO同士が集まる仮説キャンバス作成ワークショップに参加したりすることで整合性は引き続き整えていく必要があるものの何とかキャンバスを書くことができました。

今回のタイマーアプリの仮説キャンバスを作る上で、POである私が特にフォーカスしたのは潜在課題に挙げている「タイマーが楽しくない」(下図オレンジ部分)です。これを提案価値に置いた「楽しい気持ち」に持っていき「モブプロをすぐにフロー状態にさせる」ものにできるのか。

私はこれをモブタイマー起動中に流れるBGMや過剰とも取れる画面により、モブプロをドラマチックな体験に繋げられるのではないかと仮説立ててみました。
これが本当にそうなのか、プロダクトのMVP(Minimum Viable Product)を決めて検証できる状態に持っていこうとなりました。

タイマーアプリの仮説キャンバス(画像をクリックすると大きく表示)

MVPを決めるためのUSM(User Story Mapping)

前項での仮説キャンバスを開発メンバーと共有して、いざタイマーアプリのMVPを決めるためのUSM作成です。タイマーアプリを使うユーザ=開発者の体験を書き出し(下図青付箋)、体験ごとにどういったPBIと受け入れ条件になるかを書いていきました。また、プロダクト開発に必要な作業や調査なども書き出し、最終的に20%の参加割合の中で検証可能な最小限のMVPにしたものが下図になります。ここで併せてプロダクトゴールも立てました。(下図左上の黄色枠

モブタイマーのUSMから導いたMVP(画像をクリックすると大きく表示)

プロダクトゴール
・モブタイマーとして最低限検証できるものを作り、ふぁんこみチームの成功体験を得る。

このMVPに絞り込むまでは、複数のスプリントを要しました。作成当初はもう少しMVPとして作れる機能があるだろうと予測していましたが、チームミッションにも掲げていた「今までチームが取り組んでいない技術」としてElectronを採用したこともあり、思った以上にチャレンジングになって、このままだと検証できるプロダクトの開発が未完になるということで見直しを繰り返して上図の状態になりました。

開発するタイマーアプリの検証できる機能は以下になります。
1. タイマーアプリ起動
2. タイマーカウントダウン開始(タイマー時間は5分固定)
3. 開始ボタン押下と同時に、ドラの音で開始を告げる
4. タイマーカウントダウン中に静かなピアノの音楽が流れる
5. カウントダウン終了3秒前に赤基調の警告画面を表示
6. カウントダウン終了時に、ドラの音で終了を告げる

ちなみにふぁんこみチームのスプリントはラボで定番になりつつある2週間1スプリントではなく、1営業日(7.5時間)1スプリントで進めていきました。小さく進めて小さく改善を繰り返していくためです。できることなら毎週1日をふぁんこみのスプリントに充てるくらいに集中してやりかたったのですが、チームメンバーとの時間調整の結果、2日に分けて1スプリントとして実施することになりました。

期間を見極める

タイマーアプリのユーザとして検証してみた

前項に挙げたスケジュールでスプリント7(SP7)に置いていたMVPリリースのタイミングで動くアプリができましたので、次のスプリント8(SP8)でタイマーアプリのユーザとして、評価をしてみました。

評価の際は評価指標として、下図の最上段に挙げている項目ごとにふぁんこみチームメンバーが忖度なくイチユーザとしてどう感じたかを書き合いました。

タイマーアプリとして、ボタン配置は適切で操作自体は簡単であるや、タイマー開始、終了に気付けるといったポジティブな意見が出た一方で、POとしては一番の売りと思っていたモブワーク中に流れるBGMが比較的落ち着いたピアノ曲を流していても「うるさい」という意見が目立ち、仮説キャンバスで目指していた「モブワークが楽しくフローな状態にすぐなれる」といった価値は届けられていなさそうだということが見えてきました。

タイマーアプリのユーザとしての忖度ないフィードバック結果(画像をクリックすると大きく表示)

POとしては正直、無茶苦茶悔しいですし残念な気持ちになりました。自分が「これはいけるのでは?」と思っていることが否定されたからとはいえ、20%の参画割合でここまで悔しさを感じられるくらいにはPOやっていたのかなと思えました。

結果としてはPOの仮説立てたものとは異なるものになりましたが、とはいえ、これでようやく仮説を立てて、動くものに対して検証するという一巡ができたとも思えました。非常に小さなサイクルではありますが、いわゆる「仮説検証型アジャイル開発」の1周目を自分は経験できたのではないかなと考えています。

仮説検証型アジャイル開発の概念図(【Weekly Red Journey】Vol.2 正しいものを正しくつくる、仮説検証型アジャイル開発のススメ)より引用

今回作ったプロダクトは、ふぁんこみチームという限られた中では仮説とは異なる結果が得られたという学びになりました。これがモブワーク中に流れる音楽は開発者をフローな状態には導けないということに即決するとは考えておらず、それならばどういった音楽であれば仮説に近づけるのかを2周目で考えたいなと思ってきています。仮説検証のやり方も深化させて、ワークの割合も20%から広げていけばどのようなことができるのだろうと思うと、今回のこのテーマだけでなく「仮説検証型アジャイル開発」へ興味も俄然湧いてきました。

20%という限られた時間で、精一杯、やれることをやれたのではないかなと考えていますし、この経験がいつか近い将来、自分の中での「愛おしい失敗」の一つとして数えられたらいいなと考えています。

私がラボの活動を2年やってきて、気に入っている「ノーム・カースの最優先条項」の原文を引用して当記事を締めたく思います。

Regardless of what we discover, we understand and truly believe that everyone did the best job they could, given what they knew at the time, their skills and abilities, the resources available, and the situation at hand.

The Prime Directiveより引用

おまけ

自分がPOというスクラムマスターに支援してもらってありがたいなと思ったことは、チームメンバーの時間調整取りまとめやMiroで管理していたカンバンや各種スクラムイベントの枠整備といったもので、これらができているとスクラムが円滑になるのだなと実感できました。

自分がスクラムマスターの帽子を被る際、こういった部分も押さえつつ、チームメンバーに問い掛けつつ、スクラム活動を回していきたいなと改めて思いました。

おまけまで読んでいただきありがとうございます。