🎄

治験領域でスクラム開発を8ヶ月やってみて直面した3つの課題と解決策をエンジニア視点で述べてみる

2022/12/12に公開

agile

scrum

dct

idea

この記事は MICIN Advent Calendar 2022 の 12 日目の記事です。

前回は笠井さんの graphql-ruby を使った API 開発でした。

はじめに

MICIN にて MiROHA という治験業務支援アプリケーションを開発している佐藤(@YuiSato1025)です。

MiROHA では今年 4 月から開発プロセスとしてスクラムを採用し、スプリントを積み重ねて改善を進めてきました。

個人としては開発と並行して、スクラムイベントのファシリテーションや会議設計の見直しなど、いわゆるスクラムマスターのような動きをすることで MiROHA の開発プロセス改善を推進していきました。

今回はそんな MiROHA でスクラム開発を実践していくにあたり、直面した 3 つの課題とその解決策を振り返っていきたいと思います。

この記事が、スクラム開発をされているチームの方々に少しでもお役に立てば幸いです 🙌

直面した 3 つの課題とその解決策

CASE 1 「MTG が多すぎて開発時間が取れない」問題

スクラムイベントをちゃんとやろうとするとある程度の時間を MTG に割かなければなりません。
MiROHA の場合、スプリント単位は 1 週間なので、

イベント名	タイムボックス(最大)
デイリースクラム	1 時間 15 分(15 分 x 5 日)
スプリントプランニング	2 時間
スプリントレビュー	1 時間
リファインメント^[1]	2 時間
スプリントレトロスペクティブ	1 時間

となります。

スクラム開発を今までしていなかったチームがいきなり実践しようとすると MTG が途端に増え、結果、開発時間が十分に取れないという不満が生まれやすくなります。エンジニアにとっては MTG よりもコードを書いている方が何倍も楽しいですから当然のことと言えます。

実際、スプリント開始当初はそのような声がスプリントレトロスペクティブであがり、エンジニアのモチベーション低下にも繋がっていることがわかりました 😢

解決策 ✅

MTG の時間を短縮する
- タイムボックスはあくまで最大の所要時間です。当然ではありますが、チームにとって必要な議論ができれば短縮することが可能です。MiROHA では、スプリントレビューとスプリントレトロスペクティブを統合した「スプリントイベント」なるものを作ることで、必要な議論は抑えつつも MTG の時間を 2 時間から 1 時間に短縮することができました。ここは何度かスプリントを積み重ねていくことでそれぞれのスプリントイベントのタイムボックスを最適化できるようになると思います。
スプリントイベントの準備は非同期で行うようにする
- スプリントイベント前の準備を非同期で行うこともおすすめです。例えば、デイリースクラムでは事前に勤怠や相談事項を記入できるように Slack でのリマインダー通知を活用しています。結果、デイリースクラムで議論される内容の不確実性が減り、タイムボックス内での運営ができるようになりました。
開始 30 分前に通知して、スムーズなファシリテーションを促進
MTG Day を作って MTG と開発のスイッチングコストを最小化する
- エンジニアにとって MTG とコーディングのスイッチングコストは想像以上に大きな負担になります。そのため、スクラムイベントを火曜日にまとめた MTG Day を設けることにしました。結果、MTG Day 以外の日はコーディングに集中できるようになり、エンジニアの開発体験を向上することができました。

CASE 2 「スプリントゴールが達成できない」問題

スプリントプランニングにて定めたスプリントゴールをスプリント開始初期はなかなかスプリントゴールが達成できないという課題に直面しました。

よく見てみると、原因の一つに取り組むスプリントバックログアイテムが全て可視化されておらず、見えない潜在タスクがあることが分かりました。

例えば、来スプリント以降で対応する機能開発のストーリー・サブタスクを決めるタスクであったり、スプリントレビューで指摘された細かいエンハンス、スプリントゴールには関係しない改善タスクなどです。それらはスプリント内で対応しつつも可視化されていないためにボトルネックの発見に遅れる傾向がありました。

他にも取り組むタスクの優先度が不明瞭なために改善タスクは完了しているが、本線のストーリーが完了できていないなど取り組むべきタスクの優先度がずれてしまう問題も同時にあることが分かりました。

解決策 ✅

潜在的なタスクも可能な限りチケットとして作成し、チケット以外のことはやらないようにする
- 見えないタスクほど不確実性が高いものはありません。細かいタスクであってもしっかりチケット化することで他メンバーにも作業が分かり、タスクの分担や議論をすることができるようになりました。
潜在的なタスクもチケット化する^[2]
スプリントバックログアイテムの優先度を明確にして、何をやらなければならないかをチームで合意する
- スプリントゴールを決めるスプリントプランニングの会議体も非常に大事になります。MiROHA ではスプリントバックログアイテムの優先順位がチームで合意できているかをチェックボックス形式で確認をとるようにしました。結果「スプリントで必ず達成したいもの = スプリントゴールの達成」の意識がチームメンバーの中で向上し、達成率が上がるようになりました。常にやりたいことがリソースよリも多いソフトウェア開発において、選択と集中はとても大事ですね。
スプリントプランニング開始前にチームで同意をとる
スプリントレビューを必ず実施する
- スプリントレビューは他スプリントイベントに比較すると優先度が低い印象で省略しがちですが、必ず実施するようにしましょう。
- インクリメントを見せる機会があることでエンジニアにも責任が生まれてタスクの完了率が高まりスプリントゴール達成を促進します。例え何らかの理由でスプリントゴールが達成できないとしてもスプリントレビューを実施することで、インクリメント可能な単位でストーリーが作成できているか、などレトロスペクティブの際に検査をする機会をもつことができます。

CASE 3 「開発のモチベーションが上がらない」問題

最後は少し抽象的な課題について。

スクラム開発を進めていくにつれて、我々がなぜその機能を開発するのかというエピック単位の意思決定に合意することはエンジニアのモチベーションに大きく影響することが分かりました。
そこが定まっていないと、開発の必要性をエンジニアが感じにくくなり、やらされている感が強まってしまい、結果エンジニアのアウトプットを最大化することが難しくなってしまいます。

MiROHA のように治験というエンジニアにとって普段馴染みのないドメインであったり、ユーザーのフィードバックが届きにくい BtoB モデルの場合、特に顕著に発生しやすい問題といえます。

解決策 ✅

顧客をどうにかして巻き込んで開発していく
- プロダクトは顧客のためにあります。せっかく開発した機能が全く使われない機能だとしたらとても悲しいですよね。机上の空論にならないためにも顧客と接点を持ち、スクラムイベントに参加して積極的にプロダクトづくりに関わってもらう必要があります。
  
  こんなことは絶対に避けたい
- 私たちのプロダクトは顧客が製薬会社や医療機関であるため、toC 向けのサービスと比べると顧客との距離がどうしても遠くなってしまう傾向にあります。その現状を理解しつつ、顧客を巻き込んでいくことは間違いなくプロダクト開発におけるモチベーションを向上させ、結果、提供価値の最大化につながると考えられるため、積極的な顧客への働きかけを開発に閉じず進めていく必要があります。ユーザーインタビュー、やりましょう。
ドメイン勉強会を実施する
- エンジニアが開発するドメインを知ることはとても大切です。僕自身治験という領域が入社当初全くわからず、CRA・CRC という専門用語やプロダクトの構造を理解するのにとても苦労し、当初の開発モチベーションは正直低かった気がします。
- MiROHA では定期的にドメイン勉強会を実施しており、元製薬会社出身のメンバーなどからドメインのレクチャーを受けることでユーザーやプロダクトの理解が促進され、結果プロダクトに対する愛着や目的の理解が大きく向上しました。
- 馴染みのない領域の開発を取り組んでいるチームの場合、エンジニアが積極的にドメインを知ろうと働きかけること・インプットの機会を設けることがモチベーションの向上に役立ってくれることでしょう。
インセプションデッキを作成して、チームの目的・存在理由・提供価値の共通認識をもてるようにする
- アジャイルにはビジネス側・開発側という壁はありません。ある場合は無くすためにインセプションデッキを作成してみるのも一案です。
- インセプションデッキを作成することで、エンジニアは開発の Why が明確になります。
- 本来インセプションデッキはプロダクト開発前に取り組むものだと思いますが、MiROHA では当初存在しなかったため、現在進行形で取り組んでいます。チームで決めていくプロセスは時間はかかりますが、今後のプロダクト開発における土台になることから、まだ無い場合は作成することをおすすめします。
プロダクトタスクの階層構造^[3]