自己紹介
こんにちは。半年ほど前に株式会社 Rehab for JAPAN に入社したホセです。これまで複数の事業会社で Web サービスの開発に携わり、スクラム開発にも数多く取り組んできました。現在は介護事業所の請求業務を効率化する「Rehab Cloud レセプト」というサービスを開発しているチームで、チーム活動の支援やプロジェクト管理を担当しています。毎日新たなチャレンジに取り組みながら、チームの成長を支える役割を目指しています。
最近、私たちのチームではウォーターフォール型開発からスクラム開発への移行を進めています。まだ移行して間もないタイミングですが、このブログでは、移行に至った背景、導入の手順、直面した課題、そして初期の成果についてお話したいと思います。
2. なぜスクラム開発を導入したのか
1. ウォーターフォール開発の成果と課題
これまでレセプトチームでは、ウォーターフォール型を軸にした開発手法を採用してきました。このことは、主に以下のような理由から、特にプロジェクト立ち上げ期において高い成果をもたらしたと考えています。
-
堅実な開発体制
私たちが開発している「Rehab Cloud レセプト」というプロダクトは、介護事業所の業務運用に直結した Web サービスです。不具合が許されない高い信頼性が求められるため、ウォーターフォール型開発による計画的な進行が適していました。要件を厳密に定義し、設計、実装、テストを着実に進めることで、高品質なシステム構築を実現し、結果として、サービス全体の安定性を保ち、インシデントの発生を極めて低い水準に抑えることに成功しています。 -
進捗管理のしやすさ
開発工程が要件定義、設計、実装、テストと明確に分割されており、最初に全てのタスクを洗い出すので、弊サービスのようなある程度規模の大きいプロジェクトにおいても、タスク残量を常に監視することで、進捗の確認が容易であったと考えています。 -
効率的なタスク分割と管理
PM がプロジェクト全体を管理し、タスクを細かく分割してメンバーに割り振ることで、各メンバーが自分の作業に専念できました。新人や経験の浅いメンバーには明確な指示が役立ち、経験豊富なメンバーは専門分野でそのスキルを最大限に発揮できる環境が準備されていたと思います。
しかし、プロジェクトが成長し、機能追加や変化への対応が求められるフェーズに入ると、以下のような課題が浮かび上がり、スクラム開発の必要性を感じることになりました。
-
チームの自律性が不足
PM がすべてのタスクを管理する仕組みでは、メンバー、およびチームが主体的に判断し、行動する機会が限られており、変化への柔軟性や対応力がチームとして十分に発揮されにくい状況でした。結果的に、個々の力ではパフォーマンスを発揮できていたものの、チーム全体としての成長や一体感に課題があったと考えています。 -
ユーザー価値への意識の低下
開発の進行においては、要件を確実に満たすことが優先され、プロダクトの向こうにあるユーザーの姿、ユーザーにとっての価値を想像する機会が減少していたように思います。結果としてユーザー中心の視点を高める余地があるのではとの意見が見受けられました。 -
役割分業による柔軟性の低下
PM の役割が広範囲に及び、負担が大きく、調整に多くの時間が費やされていました。また、役割が固定化されることで、チーム内で柔軟に協力し合う機会が減少し、チーム全体の効率性や連携力が低下する要因になっていました。
2. スクラム開発で期待したこと
これらの課題を解決するために次のような効果を期待し、スクラム開発を導入しました。
-
チームの自律性向上
チーム全体でタスクを計画・管理する仕組みを整え、メンバーが主体的に行動できる環境を構築する。これにより、現場で迅速に意思決定し、柔軟に対応できるチーム文化を育てることを目指しました。 -
ユーザー価値を意識した開発
プロダクトバックログを通じて「誰のために何を解決するのか」を明確化し、スプリントレビューで顧客やステークホルダーからのフィードバックを反映することで、顧客価値を最大化するプロセスを開発サイクルに取り入れることを目指しました。 -
柔軟で効率的な体制づくり
タスクの共有を通じて役割や調整の負担を分散し、メンバーが柔軟に技術領域を横断できるような体制づくりや、意識づけを行うことで、より変化に強い柔軟なチームを実現することを目指しました。
3. スクラム開発導入の手順
導入に関しては、スクラム開発経験の多くないメンバーが大半であったことを考慮し以下の手順で進めました。
-
現状課題の共有と目線合わせ
プロジェクトマネージャー間で現行の開発プロセスの課題を整理し、「なぜスクラムを導入するのか」「どのような改善を目指すのか」「どのような成果を期待するのか」といったことについて、入念に認識を擦り合わせました。このプロセスを通じて、課題に対する共通意識や導入後の期待値について認識をそろえることができたと考えています。 -
小さく始める
小規模なプロジェクトを対象に、試験的にスクラムを導入しました。この取り組みで、スプリント運営やプロダクトバックログの活用方法を実践し、課題の検討を行いました。スモールスタートによって本格導入時の不確実性を少しでも排除したいと考えていました。 -
スクラム勉強会の実施
メンバー全員に対してスクラムの基本概念や目的、従来との違いを共有する勉強会を実施しました。メンバー全体での理解を深め、共通認識を持つことで、スムーズな導入を目指しました。 -
意見収集と調整
勉強会後にアンケートを実施し、メンバーの疑問や懸念を吸い上げ、必要に応じてフィードバックを実施しました。メンバーが感じている導入へのハードルを理解し、スクラム開発運用に解消策も織り込みたいと考えました。 -
移行期間の設定
移行期間を設け、余裕を持ってスクラムイベント（リファインメント、スプリントプランニング、デイリースクラム）を実施しました。これにより、新しいプロセスに慣れながら課題の炙り出しを行いたいと考えました。 -
本格導入開始
各ステークホルダーの役割を定義し、本格的なスクラム開発を開始しました。
4. スクラム開発導入の振り返り
運用を開始してまだ 2 ヶ月余りと短期間であり、本格的に振り返るには時期尚早ですが、現時点でも導入手続きにおいてはいくつかの課題が散見できました。
課題
-
スクラム開発についての勉強会が不足していた
メンバーには動きや思考に大きな変化を求めることになるため、「何が変わるのか」だけではなく「なぜそれをするのか」を深く理解してもらうことが重要です。そうした納得感を醸成するための時間をより多く確保するべきだったと感じています。 -
QA チームの活動をスプリントに組み込む検討が不十分だった
初期段階では他の検討に時間を要したので一旦優先度を下げていましたが、プロダクトの品質に対する認識の一致は重要なテーマでした。しっかりと議論するべきだったと感じています。その後 QA チームと共により良い連携の仕方について議論しました。 -
プロダクトマネージャーとの役割調整が不完全で、スムーズな連携が課題となった。
弊サービスではプロダクトマネージャーが要件定義、UX の役割も担っていますが、何がどう変わるのか、スクラム開発でどのように協働したいのか、についてしっかりと議論する必要があると感じました。
同時に、初期段階において良い兆しも生まれつつあると感じています。
初期成果
- チーム内での議論が増え、タスク完了までの具体的な進め方を協議する機会が増加しました。
- 領域横断的な活動が活発化し、メンバー間で柔軟に連携する機会が増加しました。
- 不確実性の高いタスクについても、進め方を含めて議論しながら進めていく文化が生まれつつあります。
5. 今後の展望
私たちのプロジェクトに最適なスクラムの形を実現するためには、継続的な改善が不可欠です。これまでの取り組みを踏まえ、以下の点に注力していきたいと考えています。
スクラム理解の深化と学びの強化
スクラム開発の本質や目的を全メンバーがより深く理解できるよう、勉強会を定期的に実施したいと考えています。
プロダクトとチームの進化に合わせた柔軟なスクラム運用
私たちのプロジェクトでは、ウォーターフォール型開発にも有効な手法が存在すると考えており、それらを適切に取り入れつつ、現状の運用課題を随時見直していきます。これにより、チームの状況に応じた改善を重ね、スクラムを単なるフレームワークに留めず、プロジェクトの成功、チームの成長を支えるための最適な手段として活用していきたいと考えています。
文化としてのスクラム定着
スクラムをチーム全体の文化として定着させることを目指します。不確実性に立ち向かい、協力して課題を解決する姿勢や議論を重んじる文化を強化することで、より強いチームを作り上げていきたいと考えています。
スクラム開発の道は一日にしてならず。私たちはこれからも試行錯誤を重ねながら、プロダクトの成功とチームの成長を両立するスクラムの形を追求していきます。
Discussion