はじめに

こんにちは、ヘルスケア開発部でバックエンドを担当している本田です。ヘルスケア開発部では主に LINEドクターというサービスを開発しています。

LINEドクターでは2023年4月から Scrum 開発に取り組んでおり、その導入および継続的改善を進めていく中で、さまざまな課題に直面しました。

この記事では、まず LINEドクターにおける Scrum 開発の特徴を述べ、それらに関して生じた課題を紹介しつつどのように解決したか、という改善事例を紹介します。

「LINEドクター Scrum 開発：Waterfall開発からScrum開発へ」では Scrum 開発を導入した背景や全体像を書いてるので、まだ読んでいない方はそちらから進んでいただけると理解しやすくなると思います。

LINEドクターにおける Scrum 開発

Scrum 開発と一口に言っても、プロジェクトやチームの特徴によってその進め方は様々です。ここでは LINEドクターの Scrum 開発にはどのような特徴があるかをまず説明します。

Scrum 推進チーム

LINEドクターでの Scrum 開発の導入および継続的改善は、LINEドクターのサービス開発に関わるメンバーからの有志で構成される「Scrum 推進チーム」を中心として進めてきました。ここでは、LINEドクターの特徴として、Scrum 推進チームの概要と活動内容を紹介します。

Scrum 推進チームとは

LINE ヤフーには PJM コンサル部（以降、PJMC 部）という「良いプロダクトをユーザーに届けるために、チームやプロセスをより効果的にするための社内コンサル部隊」がいます。多くのプロジェクトでの Scrum 導入などを経験しており、LINEドクターでも彼らからのサポートを受けながら Scrum 開発の導入をすることとなりました。その際、以下の目的で Scrum 推進チームが発足されました。

• 目的1：組織全体を巻き込み、現場メンバー主導でプロセス改善を行う
• 目的2：ドメイン知識や組織的制約を理解した上での、Scrum 開発のテーラリング^※ を行う（※ 業務プロセスやシステム開発プロセスなどについて、規格や全社的な標準などを元に、個別の部署やプロジェクトに合った具体的な標準を策定すること）

上記目的1のとおり、Scrum 推進チームは基本的にはメンバーレイヤーのみで構成されています。マネジメントレイヤーではないメンバーが中心となってボトムアップで組織全体を巻き込んでいったため、以下のような効果がありました。

• 主体的に組織を変えようという当事者意識が高まる
• 現場レベルの困りごとに対するアプローチがしやすい
• 推進チーム以外のメンバーも意見をしやすくなる

参考までに、LINEドクターは Plan, Dev, QA メンバー合わせておよそ40名で構成されており、その内6名が Scrum 推進チームに所属しています。内訳は以下の通りです。

• Plan 1名
• Dev 3名 (FE 1名 ＋ BE 2名)
• QA 2名

Scrum 推進チームの活動

Scurm 推進チームで行っているのは主に Scrum 開発の導入と継続的改善です。Scrum 開発の導入に関しては、こちらの記事（LINEドクター Scrum 開発：Waterfall開発からScrum開発へ）で説明されているので、ここでは継続的改善に関して説明します。

Scrum 開発における重要な取り組みの1つが継続的改善です。継続的改善の効果を高めるために、Scrum 推進チームでは Sprint Retrospective の中で十分に検討できなかったものをより深く検討したり、Next Action として決めたものをより具体的に進めるといったことを行っています。Scrum 推進チームには各ロールのメンバーがいるので、ある程度の改善施策を検討した後に各ロールにそれらを共有・実践し、その改善施策がうまくいかなければさらにそれを振り返り、ということを繰り返し行い、チームの生産性をより向上させています。

LINEドクターのチーム体制

次に、Scrum 導入時の LINEドクターチーム体制の変遷とその Scrum チーム体制の特徴を紹介します。（現在のチーム体制については後述します。）

チーム体制の変遷

LINEドクターでは、元々以下図のような Waterfall 型のチーム体制で開発を進めていました。

• 各 Role ごとで構成されたチーム
• デザインはデザイン専門チーム、フロントエンド開発（の大部分）は海外事業体のチームが担当

Scrum 開発を導入するに当たり、上図から大きく体制を変えないよう導入当初は以下図のような体制にしました。

• 各ロールを2分割した Scrum チーム
• デザインおよびフロントエンドチームは Scrum チームに組み込まれていない（Daily Scrum や Product Backlog Refinement のような Scrum イベントには不参加）
• PJMC 部メンバーが各チームに Scrum Master として参画

LINEドクターのチーム体制（当初）の特徴

上で示した Scrum 導入当初のチーム体制には以下のような特徴がありました。

• デザインチームとフロントエンドチームという外部依存組織の存在
• 2チームとも同じコンポーネントを担当

LINEドクターのチケット管理

最後に LINEドクターでの Jira を用いたチケット管理について紹介します。Scrum 開発では Jira というツールがデファクトスタンダードであり、LINEドクターでも使用しています。ここではどのように Jira でチケットを管理しているかを簡単に紹介します。

チケットの階層

LINEドクターでは、Jira チケットを Epic → Product Backlog Item^※ → Sub-task という階層で管理しています。（※ 以降 PBI と呼ぶ）

この Epic の規模が大きい場合、Epic に紐づく機能の開発を1つのチームだけでやりきるのは難しくなり、2つのチームで協力して開発を行うこととなります。LINEドクターでは2つのチームが同じコンポーネントを担当しているため、同じ Epic に紐づく機能を2つのチームをまたいで開発しようとすると、依存関係が生まれることがありました。

ラベルでのチケット管理

LINEドクターでは、Scrum Team1、Scrum Team2 といったチームラベルを使用しており、このラベルによって Product Backlog にてチーム単位でのフィルタリングを行うことができます。LINEドクターでは、特定の PBI をどちらのチームが担当するかは基本的に Product Backlog Refinement の前段階で決めているため、Product Backlog 上での管理が容易です。たとえば、Scrum Team1 は Product Backlog Refinement でどの PBI の見積もりまでできているのか、Scrum Team2 は Sprint Planning でどの PBI を次回 Sprint で取り組むのか、といったことがわかりやすくなります。

両チームが担当の PBI には2つのラベルが付与することになります。Product Backlog 上で管理する上ではこのような共通の PBI でも問題なく管理できていましたが、Sprint に組み込む際には Product Backlog から Sprint Backlog という枠組みに移す必要があり、両チームが共通で担当する PBI を管理することが難しくなるといったこともありました。

LINEドクターにおける Scrum 開発の課題

上記で説明した LINEドクターにおける Scrum 開発の特徴を踏まえて、ここからは以下の3つの具体的な課題とそれらの解決策を紹介します。

1. Scrum チームと外部依存組織との連携
2. 依存関係がある PBI の管理
3. Scrum チーム共通 Undone work の管理

1. Scrum チームと外部依存組織との連携

先述したとおり、LINEドクターでは Scrum チームとは別に外部依存組織がおり、それらチームと協力しながら開発を進めていましたが、多くの理由で生産性の低下を招いていました。

外部依存組織と Scrum 開発を進めるうえでの課題

外部依存組織と連携する際、以下のような課題がありました。

• コミュニケーションコストが高い
  • Scrum イベントに参加していないため、外部依存組織はそれまでの議論や経緯を知っておらず、背景や詳細を再度説明しなければいけない
• 優先度通りに PBI を進められない
  • 外部依存組織の業務は Scrum チームからの依頼がないと進まないため、効率を考えると外部依存組織に関わる PBI を先に取り組む必要がある
• 外部依存組織の専門分野の知見を Product Backlog Refinement 時点で得られない
  • LINEドクターの場合、フロントエンドの開発が外部組織に依存していたため、Sprint 開始前にフロントエンドまわりの十分な検討ができていない

上記に加え、LINEドクターでのフロントエンド開発は海外事業体のチームが担当していたことによる言語起因のコミュニケーションコストも高く、外部依存組織との連携に多くの工数をとられていました。

外部依存組織への依存度を下げるチーム体制への変更

上記で述べた課題を解消するためには、外部依存組織との連携を減らすことが必要です。可能な限り Scrum チーム内で業務を完結できるよう、LINEドクターではチーム体制を以下のように変更しました。

• LINEドクターに工数100％のフロントエンドエンジニアが各チーム1名
• 工数50％のフロントエンドエンジニア1名が Sprint の負荷によってどちらかのチームをサポート（Traveler と呼ぶ）
• 一部のフロントエンド業務は引き続き海外事業体メンバー担当
• デザインチームに関しては変更なし

その結果、以下のような効果が生まれ、事業の優先度に沿った順番で開発をより効率的に進められるようになりました。

• 密なコミュニケーションによって共通認識のもと連携
• Product Backlog の優先度にしたがって PBI に取り組むことができる
• フロントエンドエンジニアも Scrum イベントに参加するため、見積もりの精度向上や懸念点の早期検討が可能

理想は完全に外部依存組織をなくして Scrum チーム内ですべてが完結できることですが、可能な限り外部依存をなくすことでより生産性をあげることができました。

2. 依存関係がある PBI の管理

LINEドクターでは2つの Scrum チームが存在し、どちらのチームも同じコンポーネントを担当しています。コンポーネントごとでチームが分かれていないため、管理者である PO が開発チームのリソース配分を気にすることなく、ビジネスのニーズに合わせた Product Backlog の優先順位を決められるといった利点がある一方で、2チームが同一コンポーネントを修正するうえでの課題もありました。

PBI の依存関係による別チーム作業のブロック

Scrum 開発では、Sprint Planning の時点で各チームに割り振る PBI を決めます。すべての PBI が独立に開発できるものであれば問題はありませんが、PBI 間には依存関係があるものも残ります。とくに同じ Epic に紐づく機能を開発する場合、PBI 間には依存関係が発生することが多いです。PBI 間に存在する依存関係を意識していなかったことで、依存関係がある PBI を異なるチームに振り分けてしまい、片方のチームの進捗がもう片方のチームの作業をブロックしてしまうということがありました。

依存関係をもつ PBI の確認および割り振り

上記課題は Sprint Planning までに、十分に PBI 間の依存関係を考慮していないことが原因で発生しました。そこで、LINEドクターでは以下のようなルールを設定しました。

• Refinement 時点で依存関係があるとわかっている PBI は Jira の機能を使って関連付ける
• Sprint Planning の冒頭で、PBI の依存関係を再確認する

上記ルールにしたがい、開発メンバーが中心となって Sprint に含まれる PBI の依存関係を確認し、依存関係のある PBI は以下表の優先順位でいずれかの対応を行うようにしました。

これらの対応方法をルール化しつつ以下の点を徹底することで、作業ブロックによる生産性の低下を防ぐことができました。

1. ブロック要素は事前に処理
2. 事前に処理できなかった場合でも依存関係がチームをまたがない
3. 依存関係がチームをまたいだ場合でも別チームの作業をブロックしない

3. Scrum チーム共通 Undone work の管理

Scrum 開発では、Sprint 内でやりきる Done work と、Sprint とは別のスケジュールでリリースまでにやりきる Undone work という2種類の作業が存在しています。

Done work は Scrum チームごとに毎回の Sprint 内で完結することができますが、Undone work はリリースのためのタスクとなるため基本的には両チームとも対応する必要があります。この Undone work の管理に関しても課題がありました。

Undone work の管理

LINEドクターでは、2つの Scrum チームが存在するため、そのままチームごとに Sprint Backlog を分けて運用していました。

このとき、Undone work に関連して以下2点の課題が存在していました。

• Undone work の PBI を片方のチームの Sprint に割り振らなければならない
  • 別チームの Sprint にある Undone work に対する意識が薄れる
  • Daily Scrum での確認漏れやそれに伴う作業忘れなどが発生
• Undone work を Sprint のスケジュールで管理してしまう
  
  • Undone work がリリースに紐づくスケジュールで管理されないため、いつまでに完了すべきかという認識が難しい

Version Sprint への Undone work の切り出し

上記課題に対し、LINEドクターでは Version Sprint という3つ目の Sprint Backlog を運用することで対応しました。