ワンランク上の健康管理を！「FiNC Plus（プラス）」をスクラムで開発しました
FiNCでAndroidエンジニア 兼 スクラムマスターをしている吉田です。
日課は毎朝の散歩とラジオ体操です。
弊社では、2020年7月21日（火）に、糖質管理やアドバイスレポート機能など、ワンランク上の健康管理ができる新しいサブスクリプションサービス「FiNC Plus」をリリースしました。
弊社ではユーザーに価値あるサービスを継続的に提供するためにアジャイル開発を取り入れているのですが、その実現方法は開発チームに委ねられています。そんな中、このFiNC Plusを開発している「dev2」というチーム(以後分かりやすく「Plusチーム」と呼びます)では、スクラムガイドに則ったスクラムでFiNC Plusを開発し、今でも改善を続けています。
しかし、社内でスクラムの知見はまだそこまで溜まっておらず、スクラムの適応も日々試行錯誤しながら改善しています。スクラムガイドにも「軽量 • 理解が容易 • 習得は困難」とあるように、理論は簡単でも実践がなかなか難しいスクラム。
そこで本記事では、我々Plusチームがどのようにスクラムを適応してきたかを以下のステップで紹介します。
- なぜスクラムを取り入れたのか
- 現状のスクラム体制
- これまでに遭遇したスクラムの壁
・専属PO不在のスクラムチーム
・プランニングの時間でリファインメントをしてしまう
・一方通行のバックログリファインメント
・スクラムマスターがPM的なポジションや、POと開発チームとの橋渡しになってしまう
・チームメンバー同士の信頼関係の構築 - 今後の展望
・スクラムについてスクラムチームのみんなが理解している状態にして、チームの自己組織的な成熟を支援する
・仮説検証を繰り返しながら、どんどん良いプロダクトにする
・スクラムをほかチームにもスケールし、社内でのスクラムの知見を増やす
なお、本記事はスクラムについての基礎知識があることを前提としています。
また、弊社の他のチームがどのようにアジャイル開発しているかについては、同じくAndroidエンジニアでキャンプの達人 佐多の↓記事をご覧ください。
なぜスクラムを取り入れたのか
実は我々Plusチームがスクラムを経験するのは今回が初めてではなく、前身となるチームでもスクラムを取り入れていました。そのため、Plusチームがスクラムを採用するのは自然の成り行きでした。
しかし改めて振り返ると、スクラムはプロダクト開発における責務を3つの役割(PO、開発チーム、スクラムマスター)に分散し、かつチームを自己組織化させることで、チーム外から指示されることなく、チーム内でも特定の管理者に依存せず、チームメンバーが互いに協力し合いながら一丸となってプロダクトの改善をし続ける仕組みになっています。FiNC Plusというサービスを長期に渡り継続的に改善しユーザーに価値を提供し続けるためには、チームメンバーひとり一人の相乗効果が大切になってくるので、そういった点でPlusチームにはスクラムが合っていると感じています。
他にも、スクラムはルールが定義されているため社内の他チームにも展開しやすく、また広く普及しているフレームワークなので本や勉強会が豊富で知見を得やすいのもメリットだと感じています。
現状のスクラム体制
ここでは、Plusチームが現状どのようにスクラムを運用しているか簡単に紹介します。
チーム構成
以下のように、合計14名のスクラムチームとなっています。
- PO 1名
- スクラムマスター 1名
- 開発チーム 12名
(Android 1名/iOS1名/サーバー4名/QA5名/デザイナー1名)
スクラム経験者であれば、この開発チームの人数を見るとゾッとするでしょう。スクラムガイドでも、開発チームが9人を超えると調整が大変になり有益さも減ると書いてあります。しかし、メンバーの入れ替わりなどによる現在のメンバーのスキルセットを考慮し、このような構成となっています。（メンバーが多い苦悩は後ほど共有します）
スプリント
2週間スプリントを採用しています。前身チームでも同じ周期だったので慣れているのと、モバイルクライアントとサーバーがあり、1週間だとどちらかが遅れるとスプリントから溢れやすくバッファ的な意味でも2週間としています。一方、2週間だと「差し込み」が多くなりがちで、1週間スプリントの場合は「次スプリント(1週間後)でやろう」のように差し込みを減らしやすかったり、仮説検証やチームの振り返りのサイクルが早くなるメリットもあり、1週間スプリントとすることも検討しています。
各種スクラムイベント
スクラムガイドに則り、スプリントプランニング、デイリースクラム(朝会)、スプリントレビュー、レトロスペクティブ の各種イベントに沿ってスクラムを回しています。また、プランニングに入る準備としてのプロダクトバックログリファインメントは隔週で曜日固定としています。
FiNC Plus全体定例
その他、FiNC Plusというサービス全体で部署の垣根を超えて早期のコラボレーションを生み出せるように、分析・CS・マーケなど関係する各部署のメンバーが集って週次で進捗報告をする定例を設けています。KGI・KPIの進捗やカスタマーボイス・問い合わせの共有などもこの場で行われています。
これまでに当たってきたスクラムの壁
ここでは、これまでPlusチームがスクラム開発する過程で当たった壁と、それがどう改善されてきたかを紹介します。
専属PO不在のスクラムチーム
現在はPlusチームの専属POがついていますが、少し前まではPlusチームに専属POはおらず、いっときはPO的な立場の人が3人同時にいました。というのも、FiNCアプリには様々な機能がありそれだけ多くの企画が同時に並行して動いている一方、開発ラインが限られているためです。実際、FiNC Plusの開発中も、クライアント側は「食事アドバイス」というPlusとは別サービスの開発もしていました。
バックログが無法地帯
複数POがいても、誰か特定の人がバックログの管理にオーナーシップを取れていれば良かったのですが、当時はそうした状況でもなくバックログの管理責任の所在が不明瞭でした。結果、Plusチームのプロダクトバックログには「FiNC Plus」「食事記録」「食事アドバイス」などそれぞれのPO管理のチケットが立ち並び、それに加えて今となっては不要なチケットやエンジニア用語で書かれて中身のよく分からないチケット、同じ内容のチケットなどが乱立しており、はっきり言ってカオスな状態でした。
「POさん、バックログはあなたのものです！」
そしてつい最近、開発ラインが増えたことでようやくPlusチームに専属POが1人つくことになりました。そこでまずはPOに「バックログはあなたのものです、あなたが責任を持って管理してください」と伝え、バックログのオーナーシップを専属POにとってもらうことでバックログが整備されるようになりました。 これまでエンジニア用語で書かれていて内容の分からなかったチケットが、実はPlusの品質維持のためにとても重大なものであるとPOが気づけたり、大きな発見がいくつもありました。こうして、改めてプロダクトバックログにあるアイテムを全てPOが目を通し優先度をつけることで、企画だけでなくバグ修正や技術負債対応も含めたPlusチームのロードマップを引き直すことができました。
このように専属POがいることでようやくスクラムの体制が整ってきましたが、一方で、PO/スクラムマスター/開発チームが一つのスクラムチームとしてお互いに協力し合う文化創りはまだまだ改善の余地があると思っています。
プランニングの時間でリファインメントをしてしまう
リファインメントのやり方はスクラムガイドにない
スプリントプランニングは、そのスプリントで「何を」「どのように」開発チームが完了させるかを決める場所です。そしてその判断をするために事前に優先度の高いバックログアイテムの詳細(受け入れ条件や開発規模など)をPOと開発チームで詰める作業があり、これをプロダクトバックログリファインメント(PBR)と呼びます。しかし、PBRの必要性はスクラムガイドにあるものの、その実現方法については一切触れられておらず、自分たちで考える必要があります。
不定期開催のリファインメントで開発リズムが崩れる
これまではPBRの開催タイミングが決まっていませんでした。すると、専属POの不在などもあり、各POがそれぞれ思いおもいのタイミングで開発チームにリファインメントを依頼し、スプリント中の開発リズムが崩れるし開発時間が想定外に減ってしまう現象がありました。
リファインメントが開催されずにプランニングが始まる
あるいは逆にPOがどのタイミングで開発チームに依頼したらよいか分からないままリファインメントが開催されず、優先度が高いという情報のみでプランニングが始まり、プランニングの最中でリファインメントを行ってしまうことも多々ありました。リファインメントはユーザーストーリーの詳細を詰める大事な場なので、「プランニング時間内にちょっとだけ」はできません。
リファインメントの日を固定する
このように、突発的なリファインメント依頼とリファインメント漏れを防ぐために、隔週で固定日にPBRをするようにしました。一方、開発リズムという観点では、リファインメントをする日が事前に分かっているとしても、スプリント中に数時間PBRに向き合わないといけないというのは、やはり開発チームにとってはやりづらさがあります。今後は、このPBRをいかに改善していくかが一つのテーマになりそうです。
一方通行のバックログリファインメント
先ほどはPBRのタイミングについて説明しましたが、PBRの質にも改善したい点がありました。PBRはPOと開発チームとがストーリーチケットについて双方向で議論することで、そのストーリーに対する認識齟齬を無くし開発準備が整った状態とする場です。具体的には以下のようなことを話し合います。
- どんなユーザー体験(ユーザーストーリー)を実現したいの？
- その背後には仮説・背景・課題があるの？
- それを満たすにはどんな方法があるの？
- 受け入れ基準は？
- 開発規模は？
つまり、プロダクトの価値を高めるための方法をPOと開発チームとで話し合い理解し合うとても大事な場所で、そこでは参加者ひとり一人の 主体的な参加が大切です。
しかしこの議論が双方向にあまりされず、スプリントが始まってからどんな実現方法にするかや受け入れ条件について話し出すことが多く、コミュニケーションコストがかかっていました。PBRという会議体はあっても意義のあるリファインメントがあまりできていない状態でした。
そしてこれは、スクラムマスターである私の責任だと感じています。というのも、そもそもこれまでPBRが何のためにあり、何を話す場で、参加者にどんなことが求められているかを共有できていなかったからです。
なんのための会議体で、何が求められるのかを説明する
そこでチームの振り返りの場を使い、PBRについての説明と、POと開発チームとで双方向の議論が望ましいことをチームに伝えました。説明の際には、アジャイル開発におけるプロダクトバックログのリファインメント方法の提案 より、「リファインメントさえやれば良いのか？」というスライドを引用させていただきました。
また、話し合う項目を明確化するため、プロジェクト管理ツールAsanaのチケットの項目に、既存の開発規模などに加え、「背景(課題)」「実現方法」「受け入れ基準」の項目を追加して、PBRの時間でこれらを埋めるようにしました。
これにより一定PBRの質は向上したものの、まだまだ改善できる点はあると感じています。例えばPBRが行われる水曜日はFiNCアプリのリリースがあり、QAは本番リリースする前の最終的なチェックがあるためリファインメントに集中しにくいです。受け入れ基準は特にQAの方々が強い領域でもあるため、開催日を変える必要があるかもしれません。また、まだまだ心理的安全性が低いのか、あるいは私のファシリテーション不足か、全体的に発言が少なめな印象です。PBRの場でいかに詳細を詰められるかでスプリントでの生産性と提供できる価値の高さも変わってくると思うので、この辺りは継続して改善していきたいです。
スクラムマスターがPM的なポジションや、POと開発チームとの橋渡しになってしまう
スクラムチームにはチーム全体を管理する人がおらず、POはプロダクトの価値を高めるために「何を」「どの順番で」取り組むかの責任を持ち、そのスプリントで「何を」「どうやって」完了させるかは開発チームが責任を持って管理する、そしてスクラムマスターはサーヴァントリーダーとして、ティーチング/コーチング/ファシリテーションなどを用いてPO・開発チーム・組織がスクラムで価値を届けられるように支援することに責任を持つ。スクラムではこのようにプロダクト開発に必要な管理をチームに分散させ互いに協力し合うことで、特定の管理者に依存しないチームを目指します。しかし、こうしたスクラムの思想をスクラムチームにもチーム外にもきちんと説明しないと、スクラムマスターがチーム全体の管理者として認識されやすいです。なぜなら、そうした説明なしにはスクラムの中で各メンバーがどう動けば良いか分からず、その上で「スクラムマスター」という仰々しい名前があるので、なんとなくスクラムマスターに相談してしまいやすいためです。実際、Plusチームでもスクラムマスターである私がこうした説明を怠っていたため、スクラムマスターがPOと開発チームのコミュニケーションのハブになってしまったり、開発チームの進捗管理もスクラムマスターが管理するように捉えられ、チームメンバー同士のコミュニケーションを阻害してしまうことがありました。
そこで、チームメンバーひとり一人とのヒアリングを開催し、その過程で上記のようなコンセプトを伝えてチームメンバーの主体性を促すようにしています。しかし、スクラムについてのもう少し体系的な話や、「開発チームに肩書きは無くて専門分野に関係なく協力し合う」などのコンセプトはまだチームメンバーにきちんと伝えることができていないため、ここは目先で一番優先的に行いたいことです。
チームメンバー同士の信頼関係の構築
Plusチームでは、職能メンバー同士のコミュニケーションは活発ですが、職能間のコミュニケーションがあまり積極的に行われておらず、そこに見えない壁があり続けていました。特にエンジニアとQAとの関係でその傾向が顕著で、同じチームにいながらもチーム内受託のような、相互扶助の関係ではなくウォーターフォールのように分断された仕事の受け渡し状態でした。スクラムイベントの中でも両者が議論し合うことは担当チケットに関することがほとんどで、「一緒のチームとして助け合い、チームの改善のために議論し合う」ような関係性では正直ありませんでした。
この点にメスを入れるべく、開発チームのひとり一人とヒアリングをしたところ、意外な事実を発見しました。私としては、「QAの方々がチームとしての働き方を望んでいない」と勝手に思い込んでいたのですが、QAの方々もこのエンジニアとの距離感を懸念していることが分かりました。さらに、「意見を言いたくても相手のことを良く分かっていないので相手がどう思うか分からず意見しにくい」と感じている方が多くいることが分かり、この信頼関係の構築の欠如に加えて、彼らのほとんどが派遣契約で契約的な立場からも無責任に発言しにくいという状況も重なり、心理的安全性が低い状態だったことが分かりました。思い返せば、QAメンバーのうち何名かはコロナ禍以後にPlusチームに参画してくれ、最初からリモートのまま特にチームビルディングのようなものが無い状態でこれまでずっときていました。
今の状態は、チームの5つの機能不全の中でも「信頼の欠如」「衝突への恐怖」の段階だと考えており、これらを乗り越えなくては
チームの5つの機能不全 (表示順に基礎をなしており、一つ一つ順に乗り越えていく必要がある)
- 信頼の欠如
- 衝突への恐怖
- 責任感の不足
- 説明責任の回避
- 結果への無関心
現状が分かったことで、今後はこのチームの5つの機能不全をいかに乗り越えていくかも大きな焦点となっています。
今後の展望
スクラムについてスクラムチームのみんなが理解している状態にして、チームの自己組織的な成熟を支援する
Plusチームはこれまでスクラムでいくつもの壁に当たり、いくつかは改善することができましたが、本当のスクラムはまだまだこれからだと考えています。というのも、これまでも触れた通り、「スクラムが何か」ということやスクラムにおいてチームメンバーひとり一人に求められることを、まだきちんとチームメンバーに伝えることができていません。また、チームメンバー同士の信頼関係構築と心理的安全性の向上についてもまだまだ改善できるところがあります。スクラムプロセスになんとなく従っているチームから、スクラムを理解した上で自分たちで協力し合いながら改善していく自己組織的なチームへと変化する上で、最初の第一歩をようやく踏み出すことができたな、という感じです。チーム形成の段階的な推移を示したタックマンモデルではまだ形成期の段階だと思います。このモデルによれば次は混乱期が訪れ、まだまだチームの旅の先は長いですが、スクラムマスターとしてチームの成長を支えていきたいです。
タックマンモデル
- 形成期 (互いに無関心、個人プレー)
- 混乱期 (意見の衝突)
- 統一期 (安定した結果現状維持の罠にはまる)
- 機能期 (チーム一体となって新たなことに挑戦)
仮説検証を繰り返しながら、どんどん良いプロダクトにする
スクラムを採用しているのは、ユーザーに最短で価値を届け、その価値を増やし続けるためです。つまり、どんなにスクラムのプロセスを効率よく回し、素早くサービスをリリースできても、ユーザーにとって価値が無ければ意味がありません。そのため、ユーザーの声やデータをPlusチームのひとり一人が意識し、価値を高めるための仮説検証をPlusチーム全体で考えられるようにしたいと思っています。ユーザーインタビューに開発チームが参加したりするのも良さそうです。また、スクラムに固執しているわけではなく、結果よいサービスを楽しく作ることができれば良いので、チームメンバーの声を聞きながら、場合によっては勇気を持ってスクラムから離れることも考えられると思います。
スクラムをほかチームにもスケールし、社内でのスクラムの知見を増やす
もしPlusチームのスクラムが上手く回るようになったら、このノウハウを社内の他チームにも展開し、スクラムチーム同士で知見のシェアをできるようにしたいです。互いの経験的プロセスを共有することで、より良いチーム作りに繋げていきたいです。ゆくゆくはスクラムチームを超えて組織全体にもスクラムの知見を共有し、会社全体がよりアジャイルに、そしてより自己組織的に動くようになればいいなと密かに思っています。
以上。
