はじめに
20以上のマイクロサービスを抱える大規模なプラットフォームをVMからKubernetesベースのプラットフォームに移行するプロジェクトを実施しました。そこで Scrumの要素を取り入れてみたので、経験や実施した内容を共有します。
業務情報に当たる箇所もあるため、実際のものとは変えています。
また、途中で書き疲れて整理・説明の足りない箇所があるかと思いますがご容赦ください。
プロジェクトの概要
移行プロジェクトについて
- VMからKubernetesへのプラットフォーム移行プロジェクト
- 利用中のVM製品がEOL（End of Life、製品サポート終了）を迎えるため、それまでに移行する
- EOLに間に合わないとサービス停止のリスクがあり、期限には確実に間に合わせる必要がある
- 移行対象のマイクロサービスは20強
メンバー構成
- PM
- 基本的にプロジェクト進行には関わらないが、進捗の管理や上層部への報告を行なっている
- Scrum でいう PO の役割に近い
- 社員メンバー
- 私＋1名
- 兼務と維持作業あり
- 業務委託メンバー
- 4名
Scrum導入の経緯
導入前の状況
- JIRAでのチケット管理はしているが、Scrumは未導入
- 進捗管理はガントチャートベース
- 遅延は移行完了予定日と実績との差分で把握
浮上した課題
最初の数サービスを試金石として進めたところ、いくつか課題が見えてきました。
- 想定より遅れているが、実態が不明確
- 「何日遅れている」という数字は出ているが、その影響度が不明確
- 挽回可能なのかどうかの判断が難しい
- 残サービスの移行完了への不安
- 現在のペースで本当に間に合うのか？ 具体的な見通しが立たない
- 予定されている人員で対応が間に合いそうか状況が見えない
- 遅延の累積懸念
- 小さな遅れが積み重なり、プロジェクト全体に大きな影響を与える可能性
- 遅延を正確に認識して、問題があれば検出して対策したい
Scrum導入の決断
課題の解決のため、プロジェクトを Scrum で運用することにしました。
Scrum を選んだ理由は以下の通り。
- Scrumは「問題を可視化するフレームワーク」とも言われており、課題の見える化・解決をしたい、という欲求にマッチしている
- JIRAは既に利用しており、導入ハードルが低い
- 部署内でのScrum開発の実績が少なく、ノウハウ蓄積になる
自身のScrum経験について
- Scrum Master と 開発メンバー の経験あり
- 一応、Certified SAFe Scrum Master という大規模アジャイルフレームワークの資格は持っています
- ここ数年は Scrum からは離れていた
Scrum についておさらい
Scrum について簡単におさらいします。
基本的な部分は知っている前提とし、詳細や深い部分についてはここでは触れません。
構成するイベント
| イベント名 | 概要 | 主な活動 |
|---|---|---|
| Sprint Planning | Sprintの計画を立てる | ・このSprintのゴールを決定 ・このSprintで実現することを特定 ・作業完了のための方法を決定（課題解決含む） |
| Daily Scrum | Sprintゴール達成のための日次ミーティング | ・課題の共有と解決 ・達成困難な場合の相談と対策立案 |
| Sprint Review | 成果物のレビュー | ・Sprintで達成した成果物をレビュー |
| Sprint Retrospective | Sprintの振り返り | ・うまくいったこと、いかなかったことの話し合い ・改善方法の検討 |
| Backlog Refinement | バックログの整理 | ・優先度の変更 ・バックログの追加・削除 （注：スクラムガイドでは正式なイベントとして定義されていないが、定期的に行うことが推奨されている） |
成果物の定義
| 成果物 | 概要 |
|---|---|
| プロダクトバックログ | プロダクトに必要なものを定義した一覧 |
| スプリントバックログ | プロダクトバックログのうち、Sprintで達成するものの一覧 |
| インクリメント | 成果物。プロダクトバックログ、スプリントバックログ、のうち達成したもの |
基本原則（３大柱）
Scrumには3大柱と呼ばれる基本原則があります。
| 原則 | 概要 |
|---|---|
| 透明性 | ・現在の状況や問題点を明らかにする （透明性の確保） |
| 検査 | ・定期的に進捗状況を検査し、進め方に問題がないか確認する ・タイムボックス（短い固定位の期間）に区切って作業を進める |
| 適応 | ・やり方に問題があれば柔軟に変更し、適応していく ・成果やリスクを必要性を基準に並び替え、成果を最大化する |
特にこの辺りが、今回解決したかった課題とマッチ！
5つの価値基準
Scrumチームは以下に価値を認め行動することが求められます。
| 原則 | 概要 |
|---|---|
| 確約（Commitment） | Scrumチームは、ゴールを達成し、お互いにサポートすることを確約する。 |
| 集中（Focus） | Scrumチーム は、ゴールに向けて可能な限り進捗できるように、スプリントの作業に集中する。 |
| 公開（Openness） | Scrumチームとステークホルダーは、作業や課題を公開する。 |
| 尊敬（Respect） | Scrumチームのメンバーは、お互いに能⼒のある独⽴した個⼈として尊敬し、⼀緒に働く⼈たちからも同じように尊敬される。 |
| 勇気（Courage） | Scrumチームのメンバーは、正しいことをする勇気や困難な問題に取り組む勇気を持つ。 |
価値の共有は Scrumで重要な部分ではあるものの、定期的な周知や研修などマインドセットが必要になってくる部分なので、時間制限や優先度の都合から、執筆時点ではあまり取り組んでいません。
移行プロジェクトへのScrum導入ステップ
ここでは、移行プロジェクトにScrumを導入したステップを紹介します。
Scrum を導入する上での課題
それぞれが兼務や保守作業を持っており、完全なScrumの導入は難しい状況でした。
また、打ち合わせも既存のものが多いため、Scrumイベントを全て導入するのは憚られました。（MTGばかりで作業が進まなくなる）
そこで、スモールスタートとして導入できそうな部分から取り入れていくこととしました。
ステップ1: プロダクトバックログの作成
- 移行に必要な作業の洗い出し
- 全ストーリーのチケット化とストーリーポイント設定
- ストーリーポイントは作業の複雑さや不確実性を表す相対的な指標
- 当初見積もり工数から按分した値を StoryPoint とした
- 将来的にはチームの経験値に基づいて設定することを目指す
ステップ2: スプリントバックログの作成
- 2週間を1スプリントとして設定
- 各スプリントに目標（想定）ベロシティを設定
- 想定営業日や、夏季休暇/予定休、移行作業に入れる割合を考慮
- ある程度余裕を持った値にする
- Sprint 毎にチケットを配置、担当者を設定
- 必要に応じて並び替え(優先度変更)や担当者変えは実施するが、この時点の想定でチケットを並べる
ステップ3: 実施イベントの選定
現在、実施している他のMTGとの兼ね合いも考慮し、実施するイベントを選定しました。
Kubernetesなど初めて触れるメンバーもいたため、勉強会や相談を行うための「移行プロジェクト相談会」をScrumイベントとは別に 月・水・金 で実施していました。
| イベント | 実施有無 | 備考 |
|---|---|---|
| 移行プロジェクト相談会 | ◯ | 勉強会や方針の相談、モブプロ等を実施 |
| Daily Scrum | × | 全体の朝会があるため、そちらで兼ねる |
| Sprint Review | × | 移行プロジェクト相談会の中で実施 |
| Backlog Refinement | ◯ | 社員2名で実施。バックログの整理や計画の変更、課題の確認を実施 |
| Sprint Planning | △ | 社員2名+PM で実施。計画した内容は「移行プロジェクト相談会」でも共有 |
| Sprint Retrospective | △ | Backlog Refinement の中で実施。内容は「移行プロジェクト相談会」で共有し、必要に応じてヒアリングも実施 |
ステップ4: 計画の見直し
この時点で、全作業完了がEOLギリギリになりそうなことが判明したため、計画の見直しを実施しました。
- 緊急性の低い作業を分割し、優先度を下げた
- VM環境の除却など、最悪間に合わなくてもユーザー影響がない部分の優先度を落とした
- 全作業の完了は期限ギリギリだが、優先度の高い作業だけであれば 1ヶ月程度の余裕を持って完了できそう、という目処がついた
ステップ5: 運用開始
計画した内容で運用を開始し、執筆時点で期間の半分が経過しています。
当初は目標とする Velocity が出ていませんでしたが、ふりかえりと課題解決を繰り返すことで、徐々に改善していきました。
ふりかえり
プロジェクトとしてはなんとか軌道に乗り、若干前倒して移行完了できそうな目処が立ちました。
私はこの段階でプロジェクトを離れることになったのと、ちょうど半分程度の期間が経過したということで、一度全体を通してのふりかえりをチーム内で実施しました。
以下にその内容をまとめます。
良かった点
進捗状況の可視化
チケットとストーリーから残っているタスクの残量がわかるようになりました。
早期問題検出と対策
また、2週間毎にふりかえりと計画を実施することで、目標通りに進捗しているかを"検査"し、遅れや問題への対策を早い段階で打つことができました。
計画変更の柔軟性向上
想定外のタスクが増えた際や、期待する進捗が出なかった時も、スプリントバックログを調整することで、比較的計画の変更がしやすかったです。
開発スピードの向上
定期的にふりかえりを行なったことで、課題解決に動く頻度が増え、開発速度の改善が見られました。ダイエット時の体重記録のように、可視化するだけでも効果は得られると感じました。
改善が必要な点
メンバーや外部への進捗可視化
進捗情報を計測できるデータは揃っていたものの、「進捗がリアルタイムで見えやすい状態」に出来ていませんでした。
そのため、報告用の進捗資料は別で作成しており、二度手間になっていました。
今後は、その辺りを「ダッシュボード化して見える化する」など改善を目指したいです。
開発メンバーの巻き込み不足
全員で実施するイベントを絞っていたこともあり、上意下達になりがちな部分がありました。
今後は Sprint Retrospective をメンバー全員で実施するなど、よりメンバーを巻き込む形にシフトしていく予定です。
まとめ
Scrumの導入により、プロジェクトの透明性が向上し、チームの協働が促進されました。完璧なScrumではありませんが、プロジェクトの特性に合わせて一部でもエッセンスを適応することで、大きな効果を得ることができました。
課題はまだありますが、チームとして大きな前進になったと思います。
今回の経験を通じて、Scrumは単なる手法ではなく、継続的に改善を重ねていくフレームワークであることを改めて実感しました。皆さんのプロジェクトでも、ぜひScrumの要素を取り入れ、チームに合った形で活用してみてください。
参考文献
-
スクラムガイド
-
SCRUM BOOT CAMP THE BOOK
-
スクラム現場ガイド