Skip to main contentSkip to footer
Search
LINEヤフー Tech Blog

LINEヤフー株式会社のサービスを支える、技術・開発文化を発信しています。

LINEドクター Scrum 開発：Waterfall開発からScrum開発へ

LINEヤフー Advent Calendar 2023の23日目の記事です。

はじめに

こんにちは、ヘルスケア開発部でバックエンドを担当している徐 一球(Seo Ilgu)です。

ヘルスケア開発部では主にLINEドクターというサービスを開発しています。

LINEドクターはサービスを立ち上げた当初からWaterfall開発を採用していましたが、市場の変化や顧客のニーズ、チーム内の課題に迅速に対応するため、開発プロセスをScrum開発へと切り替える決定をしました。

紆余曲折はありましたが導入の初期フェーズが完了したため、2つの記事に分けて紹介したいと思います。

きっかけ

LINEドクターはサービスは「医療を最適な距離に近づける」ため生まれたOnline診療サービスです。

COVID-19のパンデミックによる需要の増加と、ユーザーに良い体験を届けると同時に更なる「ユーザー中心の設計」と「継続的な改善」を強化する必要がありました。

Waterfall開発モデルは明確なフェーズが強みとなる一方で以下のような問題もありました。

  • ドキュメンテーションの過剰
    • 要件と計画を詳細まで全てを設計してから開発するので、その分ドキュメンテーション作成も時間とリソースを大量に消費されます。
      特に複雑な仕様になると見落としや考慮漏れが発生しやすいのはもちろん1つの手戻りが発生した場合には修正も難しいです。
    • 初期で作成された設計に次のフェーズで変更が必要になった場合、またその分のドキュメンテーションの更新が発生したりするのも多々あった。
  • ユーザーフィードバックや組織内フィードバックの遅延
    • 要件定義からリリースに至るまでのリードタイムが長いので、その時々のフィードバックをすぐに反映できないため、結果的にユーザ満足度を上げにくい。
  • モチベーションの低下
    • 開発初期に設定された目標の不明瞭や途中までの案件が不要になると、チームのモチベーションが下がりパフォーマンスやプロダクト品質にも悪影響を及ぼす、インシデント発生のリスクも高める。

上記の問題を解決しつつ開発効率を上げて、より質の高いサービスの提供をしていけるように検討をしました。

なぜScrum開発なのか

  • プロジェクト管理

    • Waterfallは規模によってはプロジェクトの期間は数ヶ月から数年に及ぶことがありますが、LINEドクターでは「ユーザー中心の設計」と「継続的な改善」を強化が求められていたため

      短いスパンでリリースサイクルを回す事によって規模を小さくして管理できるScrum開発の利点に注目しました。

  • フィードバック

    • Waterfallでは通常、機能の完成後にフィードバックが発生します。

      一方でScrum開発はSprintの終わりにReviewとRetrospectiveが行われ、組織内のフィードバックが早い段階で得られる利点と同時にリリースサイクルが短くなった分もっと早くユーザーフィードバックも得られる利点に注目しました。

上記の理由でScrum開発を採用した場合、冒頭のきっかけで説明した問題と紐付けると以下が期待されました。

  • ドキュメンテーションの過剰
    • 期間が短い分作成するドキュメンテーションの量も減る事が期待
  • フィードバックの遅延
    • Sprint Reviewを通じてもっと早い段階で改善点を見つけ出し、次のステップを検討する事ができるとより早いスピードが出せる期待
  • モチベーションの低下
    • サービスに貢献できている実感とプロダクトが進んでいる事をチームメンバーが感じやすい点も期待

過程

一通り期待される項目は確認できましたが、実際にScrumを導入した時にも期待通りの結果が出るかまではまだ未知数だったため段階を踏みながら実験的に進む事にしました。

Iteration開発を通じたアジャイル開発の体験

最初に行ったアプローチは既存の開発期間を短縮し、定めた一定期間(例：４週間)中に開発を行なって完成できた分はリリースをして、開発できなかった分は次の開発期間に収まれるように細分化して行く事を繰り返すIteration開発でした。

LINEドクターではリリースサイクルを約2ヶ月程度に定めて試した所、以下が改善された事に注目しました。

  • 要件の細分化が必要になるため、ドキュメンテーションの量も減り要件を理解する時間も短縮できた。
  • 早期に問題を発見する事が可能になり修正ももっと早い段階から着手する事ができた。

一方でサイクルが短くなっただけで現在の状況や次のステップの理解しにくさやチーム全体が協力体制になりにくい部分がありました。

そして手戻りが発生した場合に修正が難しい課題もまだありました。

これを踏まえて具体的なルールと案件を開発可能な状態に議論するフロー設けられてあるScrum開発の導入を決める事にしました。

次で紹介したいと思います。

Scrum推進チーム

現場のメンバーにはScrum経験者がいなかったため、通常のサービス開発を止めずにScrum開発に単純移行することは不可能でした。

そこで我々は、企画・開発・QAから有志のメンバーでScrum推進チームを発足して、Scrumについて理解をしたことを他のメンバーに広げることから始めて行きました。

LINEドクターの特徴として、Scrum推進チームの概要と活動内容についてはLINEドクター Scrum 開発：開発体制の改善事例の方で紹介します。

Scrum開発の説明とチームへの適用例

経験がない中で進めていくのは不安もありましたが、Scrum Frameworkの概念図をはじめとする公式が出している情報をしっかり理解することから進めて適用させて行きました。

公式の概念図を用いて、1箇所つつ概念と適用例をセットで説明して行きます。

役割

  • Product Owner
    • 製品のビジョンを持ち、Product Backlog（製品の要件をリストアップしたもの）を管理します。また、 Produc Backlogの優先順位決定やリリースの時期を判断します。

  • Scrum Master
    • Scrumの進行役です。ScrumチームがScrumの理論と実践を理解し、適用するのを助けるファシリテーターとコーチの両方の役割を持ちます。

  • Developers
    • 製品の開発を担当するメンバーたち。エンジニアだけでなく企画やデザイナーも含みます。
アーティファクト
  • Product Backlog

      • 製品の要件を優先順位が高いものからリストアップしたもので、Product Ownerが管理します。

        • 「Product Backlog Item」製品の要件を表すItem(JIRAのチケットに該当)で、1回のSprint内で完成できる大きさまで細かくする必要があります。
        • 「User Story」ユーザーの視点から製品の要件を簡潔に説明したProduct Backlog Itemの表現方法の１つ
        • 「Acceptance Criteria(受け入れ条件)」User Story だけでは表現しきれない外部的な品質特性で、Product Backlog Itemがきちんと開発できたかどうかの判断基準となる

        があります。

  • Sprint Backlog

    • Sprintで開発チームが達成する目標と、それを実現するためのタスクをリストアップしたものです。

      例えばエンジニアは開発に必要なタスクをリストアップし(例：環境構築、I/F設計、DB設計等)

      企画は仕様書作成に必要なタスクをリストアップする形です。

  • Increment

    • 潜在的にリリース可能な製品(Potentially Shippable Product Increment)または最小実行可能製品(Minimum Viable Product, MVP)とも言います。

      もっとシンプルに言えばSprint期間が終わった時の成果物です。

イベント
  • Sprint
    • 一定の期間（※通常1~4週間）で、開発チームが製品を完成させるまでの時間枠です。
  • Sprint Planning
    • Sprintの開始時に行われ、開発チームが次のSprintで何を達成するか、どのように作業を行うかを決定します。
  • Daily Scrum
    • 毎日開発チームが行う短いミーティング(15分以内)で、前日の進捗と次の作業計画について話し合います。
  • Sprint Review
    • Sprint開始時に決めたProduct Backlog Itemのうち完成したものを披露し、今後のプロダクトをより良くするためのフィードバックを参加者から引き出します。
  • Sprint Retrospective
    • Sprintの終わりに行われ、Sprintで何がうまくいったか、何が改善されるべきかを振り返りをします。
Scrum開発の流れ

説明の元になるScrum Frameworkをパート毎に分けて説明します。

  • Product Backlog Refinement

    • Product Backlogの手入れを行う活動で、Product Backlog ItemをSprintですぐに着手できるようPO、Developersで以下を行います。

      • 内容理解と詳細化

      • 相対見積もり

      • PBIの分割・統合

    • 例えば「TOPメニューにボタンを追加」のProduct Backlogがあると仮定します。
      開発者、デザイナー、テストエンジニア、企画者などが集まり、「ボタンを追加」というのは何を意味するのか、どのように実装すべきかを話し合います。
      話し合った結果を元に相対見積もりをします。(※ポイント見積もりとも言います。)
      (※注意) 相対見積もりは具体的な作業工数(絶対見積もり)ではなく、基準となる案件と比べ、作業の規模感や複雑さ、不確実性などがどれくらいかを考慮して数値(ポイント)を決める見積もり手法です。
      分かりやすく例えるならマグニチュードのイメージです。
      (例 : M2=微小地震、M5=中地震)

  • Sprint Planning

    • そのSprintで何を達成するかを決定するイベントです。
      1.Product OwnerはProduct Backlogから最も優先度が高いのを開発チームに提示します。
      2.開発チームは示されたProduct Backlogに対して計画を立てる前に開発メンバーそれぞれSprint期間中のキャパシティを算出します。

      例えば以下のようにです。

      3.算出が終わったらProduct BacklogをSprint Backlogとしてもっと具体的にどのように達成していくのかをサブタスクをリストアップします。

      4.相対見積もりで決めたポイントよりボリュームが超えるかどうかとキャパシティと一緒に比較し、できる事できない事を洗い出しProduct Ownerと調整します。

      5.Sprintを開始します。

  • Daily Scrum

    • Sprint期間中に通常は毎日同じ時間に開催されます。ミーティングの時間は15分を超えないのが理想で開発チームのメンバー全員が参加します。

      主な目的はチームの進行状況を確認し、問題や障害があればそれらを解決するための戦略を立てることに使う時間です。

  • Sprint Review

    • Sprint Backlogを一つつつReviewし、それが完了したかどうかを確認します。

      完了していない物は、次のSprint Backlogに持ち越しにするか、Product Backlogに戻すかを判断をします。

      完了したSprint Backlogに対しては具体的な機能や変更点をデモします。

      そのデモをProduct Ownerからの組織内フィードバックをチームメンバーと議論しながら必要に応じてProduct Backlogを調整します。

  • Sprint Retrospective

    • Sprintの終わりに行われます。

      終了したSprintを振り返り、何がうまくいったのか、何が改善の余地があったのかを議論し

      次のSprintでの改善策を立てます。

Scrum開発に向けた環境整備

テスト環境を拡充する

Waterfall開発では開発環境からリリースまでの一連の流れは以下の通りでした。

開発とテストが時系列で完全に別で動いていたため、開発環境は1つあれば十分でした。

Scrum開発ではProduct Backlog毎に開発とテストが行われます。

ここまではWaterfall開発と差がなく1つの開発環境で対応できますが、Product Ownerがリリース対象とするPBIを決めリリースの前にテストを実施したい場合は難しくなります(※LINEドクターではBeta Testと呼んでいます。)

Beta Testが終了されるまで今進行中のSprintを止めてしまうとWaterfall開発と違いがなくなってしまうため

新しいテスト環境を構築し、以下のように運用する必要がありました。

狙ったタイミングでリリースできるような整備

Scrum開発ではProduct Ownerがリリースの判断をします。

そしてその判断基準になるのがSprint終了後に行われるSprint Reviewというイベントです。

例えばある機能がPlanningまでは気付けなかった法的イシューが見つかった場合リリースを見送る事になったと仮定します。

こうすると同じSprintでもリリースするRequirementとしないRequirementが混在していて運用が難しくなる事が予想されました。

LINE Doctorは以下のGit Branch戦略で運用する事にしました。

Git Branch戦略

Waterfall開発ではGit Branch戦略はシンプルでした。

一般化はできませんが上記のように開発環境と本番環境とマッチする構成が良くある構成と思います。

しかしこのままでは上で話したRequirementを除外するのが難しく、コストが必要な作業です。

LINE DoctorではSprint Reviewイベントに備えつつ、リリースの対象の選定をもっとスムーズに進めるための区切りとしてTagを利用することにしました。

我々は各Sprintの終わりにはTagを作成しチームは特定のSprintで行われた作業を簡単に参照し、振り返りを行うように構成したのは効果的でした。

まとめ

以上がScrum開発のきっかけから導入までの経験を紹介しました。

今考えてみればLINE DoctorでScrum開発が実現できたのは以下の要因が多かったと思います。

  • Scrum推進チームの存在
    • 本格的に移行する前に色々検討してチームをサポートした推進チームの存在は大きいかったです。
  • 納期を強要しないProduct Owner

    • Product Ownerはメンバーの一人に過ぎず、R&RはProduct Backlogの管理である事を認識し

      どのように達成するかの決めの主体は開発メンバーの責任である事を理解していたのが結果に現れました。

  • 文句ばかり言わないSprint Review
    • 積極的に意見を交換してくれた参加者全員

導入の経験ではメリットの方を多く感じていて長期的な視点で見ても導入できて良かったと感じています。

その他、LINE Doctorならはでの壁にぶつかった課題とその解決策の事例を明日の記事でぜひご確認ください。