スクラムを導入した運用チームに感じる成長のお話

この記事はラクス Advent Calendar 2021 の8日目の記事です。

はじめに

スクラム開発と言われると主に開発チームに適応される開発手法としてイメージされることが多いのではないでしょうか。

私は開発チームの中でも主に運用・保守・カスタマーサポートの部門に所属しておりますが、スクラムで業務を行っております。

運用・保守をメインとして実施するチームでスクラムで業務を実施することでどのようなメリットがあるのか、ということを私自身が感じたこととチームのメンバーからヒアリングした結果をまとめさせていただきます。

なお、スクラムについてはCodeZine様の以下の記事がとても分かりやすかったのでご参照ください

チームの詳細

メンバー構成

ベテランエンジニア：１名
中堅エンジニア：１名
新人エンジニア：１名

スプリントの進め方

１スプリント１週間という周期で実施しており、毎回スプリントの最終日にふりかえりを実施しています。

また、私たちのチームは運用業務を主に実施するチームではありますが、通常のシステム開発業務も一部は担当していますので、スプリント計画では運用業務と開発業務の目標を立てています。

スクラムを導入して良かったこと

良かったことを挙げると大きく3つのカテゴリがあると認識しています。

• 計画策定
• 体制強化
• モチベーション改善

それぞれのカテゴリ別にご紹介いたします。

計画策定

通常開発業務と運用業務のメリハリがつけやすくなった

私たちのチームは運用業務を主に実施するチームではありますが、通常の開発業務も実施しています。しかし、チームの特性上、トラブル対応やカスタマーサポートといった追加タスクが突発的に発生します。そのため、それらの追加タスクに柔軟に対応するため、スプリント計画で取り決めたタスクを実施するためのキャパシティと追加タスクに対応するためのキャパシティを別で見積もるようにしています。

このように計画しておくことで、突発的な対応が必要になったとしてもスプリント計画で取り決めたスプリントのゴールを大きく見直すことなくスプリントを継続できます。
また、追加タスクを焦って対応しなくて良いため作業ミス防止にも繋がっているかと思います。

「優先度」が把握しやすくなった

スプリント計画を立てる際はプロダクトバックログから優先度の高いタスクから取り込んでいくため、実はこの作業を先にやってほしかった、というような認識齟齬が発生しにくいです。

また、優先度がわかっていればスプリント計画後に突発の追加作業が増えて、計画していたすべてのタスクを完了させることが難しくなった場合でも、どのタスクは必ずそのスプリントで終わらせないといけないかの認識も合わせやすいため、比較的スムーズに計画の組み換えができていると思います。

実施すべきタスクの優先度が不明確だと、上に積まれたタスクをひたすら潰していくしかないため「根性で何とか終わらせる」という状態でしたので比較的タスクの進め方が改善されたと思います。

メンバーの状況に応じて効率的にタスクをアサインできるようになった

メンバーのキャパシティは休暇の取得やその他の日中作業などにより変動するため、常に一定の稼働が確保できるわけではありません。突発的に特定メンバーのキャパシティが少なくなったとしても、その人がもともと実施していたタクスが属人化していないタスクであれば他のメンバーが巻き取ることで挽回することができます。
メンバーのキャパシティ変動をキャッチアップして即座に対応できるようにチームの状態を見える化できるようにしていることが要因かと思います。

また、スプリント単位でのゴール状況が把握できるようになったので、仮にスプリントバックログのタスクが未消化で終わってしまったとしても次のスプリントで優先的に対応すべきタスクが何なのかという事が明確になり、優先度の高いタスクを効率的に終わらせるための布陣を検討するなど、状況に応じてチームで柔軟に対応しようとする習慣ができました。

体制強化

属人化しているタスクが見つけやすくなった

スプリント計画時に「このタスクは誰が実施しましょうか」という話題になった際に「あ、このタスクはいつも〇〇さんが実施してるな」ということに気づけるようになりました。

突発的なトラブルに柔軟に対応できるようにするためには属人化している状態から脱却しなければならないという課題意識があったため、何が属人化しているのかに気づけただけでも十分価値があったと思います。

属人化していたタスクが少しずつ解消されることでチーム全体で対応できる体制が整い、トラブル時などにも比較的慌てることなく対応できる余裕が生まれました。

チャレンジングなタスクが担当できるようになった

自分の担当領域を広げるため新しいタスクを引き継ごうとする際の課題は以下のようなものかと思います。

• 引き継ぎタスクの全容がわからないとボリューム感がつかめない
• 引き継ぎできるだけの余裕がない
• そのタスクを巻き取れる自信が無い

上記のような課題の大半はスクラムを導入してチーム全体でメンバー同士をフォローする体制ができたことで解決できたかと思います。
チーム全体でフォローし合うという意識が当たり前のものとして定着したことで、自分自身もチャレンジングな課題にトライしてみようという勇気が生まれました。

作業の引き継ぎがスムーズになった

上記の引き継ぎに絡んでなのですが、自分自身が新しい課題にトライしようとする場合、それまで自分が担当していた領域が手薄になってしまうという問題もあるかと思います。
この問題を解決するためには大きく２つのことができると思っています。

• 作業を効率化してこれまでよりも少ないコストで実施できるようにする
• 新しいメンバーに作業を引き継ぐ

スクラムを導入したことでできるようになったのは、主に２点目かと思います。チーム全体でフォローする体制ができたことで新しいメンバーにタスクを引き継ぐ際の課題に共通認識が生まれ、どこでどういうフォローをすればよいか、引き継ぎ時にどういうアラートを上げてもらえばフォローしやすいかが分かるようになりました。

新しいメンバーにタスクがを引き継ぐ場合に重要なのは引き継ぎの準備と引き継ぎ状況の把握かと思います。
引き継ぎタスクが問題なく引き継げているかを確認するには周りを見渡す余裕がなければ実施できません。

自分自身に余裕が生まれたからこそ他の人に作業を引き継げる状況になりました。

モチベーション改善

自分が余裕のある時間に周りを見渡す習慣ができた

自分に割当たっているタスクとほかのメンバーに割当たっているタスクが認識できるようになったため、自分の担当していたタスクが完了した際にほかのメンバーに割当たっているタスクの進捗状況を気にする余裕がでたように感じます。

そのタスクが自分でも巻き取り可能なタスクの場合はそのほかに割当たっているタスクとの優先度を考慮して巻き取りすべきかをチームで相談するという習慣ができたと思います。

ふりかえりを実施することで問題を放置しなくなった

運用業務のうち定期的に実施しなければならないような定型作業は継続して実施できている状態になっていれば課題意識が薄れてしまいがちになるかと思いますが、非効率な作業フローを改善する、といったふりかえりも重要です。また、突発的に発生したトラブルも、対応が完了すると問題が解消されたという意識になってしまいますが、本質的に何が問題だったのか、ということのふりかえりができると同様のトラブルを未然に防ぐことができるようになります。

こうしたふりかえりを決まったタイミングで強制的に実施できるのはスクラムの大きなメリットかと思います。

次の目標達成に向けて必要な戦略を走りながら考えるのではなく立ち止まって練り直すことがふりかえりの効果を高めるための重要なポイントかと思います。

おわりに

思いつくだけのメリットをひたすら書き出してみました。
中には自分自身のスキルアップにより改善されたものも混ざっていて、スクラムを導入したから、という直接的な要因でないものも含まれているかと思います。

ですが、それらもスクラムを導入して改善されたチームだからこそ成長が加速したのではないかと思います。

チームを改善して業務を効率化して自分自身も成長できるいいサイクルを回せるようになるようにこれからも挑戦していきます！