スクラム導入を巡る冒険　～インフラチームの場合～

【IIJ 2022 TECHアドベントカレンダー 12/2（金）の記事です】

こんにちは。クラウドサービス1部基盤サービスデザイン課の田中です。

 

現在私達のチームは、いわゆるインフラチームとして、IaaSの設計、構築および運用の業務を担当しております。

私達のチームでは数カ月前、プロジェクト管理のフレームワークとしてスクラムを採用いたしました。

本稿では、スクラム採用の背景と試行錯誤の過程についてお伝えさせていただきます。

「インフラ周りや運用の業務を担当するチームに所属しているけど、アプリケーション開発チームのようにスクラムを導入してみたい。果たしてどんなものだろう」とお考えになってる方の一助となれば幸いです。

スクラムのコンセプトや用語に関する説明は本稿には含まれておりませんので、必要に応じて各種ネットや書籍の資料をご参照いただければと思います。

要約

• オンプレミス環境を扱うインフラチームでも、あるいは障害対応などの割り込みタスクが避けられない運用チームでも、スクラムは検討に値する。
  • インクリメントは「価値を提供」できれば良く、「お客様へ直接的に価値を提供」することに限定されているわけではない。
  • 割り込みタスクなどの外乱からスクラムを守り、生産性を安定化させることは工夫次第で可能。
• スクラムは軽量フレームワークであり、その管理はチケット管理システムなどのツールを流用することで簡単に始められる。
• プロダクトバックログアイテムの完了について特定のメンバーに全責任を負わせるのは良くない。
  • 特定のメンバーが休むとそのプロダクトバックログアイテムが進められなくなるようでは、透明性が確保されているとは言えない。
•  スクラムの導入直後は、その管理プロセスの単純さを維持することに注意を払う。
  • 単純なものは続け易く、従って定着し易い。
• 割り込みタスクが頻発するチームにおいては、「割り込み当番」のロールを設け、1人以上そのロールにアサインする。
  • 割り込み当番のメンバーは割り込みタスクの処理に専念し、原則スプリントバックログのタスクは担当しない。
  • 割り込み当番は各タスクをチケットに書き出した上で、スプリント終了時にローテーションを行うことで、割り込みタスクをメンバー間で公平に分担させる。
• 複数のプロジェクトを抱えるチームでスクラムを導入する際は、プロダクトバックログアイテムの優先度を「プロジェクト単位」「アイテム単位」の2段階で決めていく。
  • チームで取り組むプロジェクトをスプリントごとに切り替えることで、別々のロードマップを持つプロジェクト群を並行して計画的に進めることが可能。

背景

スクラム導入前、私達のチームは（あるいは少なくとも私個人は）、定例会の度にマネージャー層から聞かれる次の質問へどのように回答するべきか、内心困っておりました。

 

「それで、○○はいつ頃終わりそうですか？」

 

担当しているタスクがいつ頃終わるのか、直ぐに答えられなければならない質問です。

私はガントチャートに記載があった日付を答えようとして、ふと別の仕事のことが脳裏に浮かびます。

（そういえばサービスリリースに関する作業依頼があって、私が担当することになっていたな。あと、先日のシステム障害のポストモーテム報告書も今週中に書かないといけないし、午前中にエスカレーションが上がってきた問い合わせについても直ぐ返答しないといけなくて……あれ？本当に間に合うっけ？）

一瞬のためらいの後、私は、ガントチャートに記載されている通りの日付を回答します。

間に合わせるための時間をどこから捻出するか決まっていない、いやそれどころか、そもそも本当に捻出できるのかも分かっていないにも関わらずに、です。

 

上記のような状況を変えたいと思ったことが、スクラム導入の切っ掛けになります。

スクラムのメリットは様々ありますが、1番の目的は「○○はいつ頃終わりそうですか？」という質問に対して、根拠のある予測を回答できるようになることでした。

 

前述の通り、私達のチームは、開発と運用のどちらの工程も担当している職能横断型のチームです。

運用については、障害対応などの非定型の運用業務も含まれております。

そのため、直近で運用系のタスクがどの程度発生するかを読み切ることは困難と言わざるを得ません。

そのような状況下で、柔軟性に難のあるガントチャートを使い続けるのはデメリットが大きいと考えられました。

そうして、代わりとなるプロジェクト管理のフレームワークとして、スクラムの導入を検討することになったのです。

第一の落とし穴：スクラムはアジャイルの別名ではない

スクラムを導入するに先立ち、ネットや書籍で情報収集しましたが、まずこの段階で戸惑いを感じました。

果たして、インフラチームがスプリントごとにお客様に対して直接提供できる価値とは、一体なんなのだろう、と。

 

スクラムの導入事例の中では、ユーザーストーリーマッピングにより整理されたユーザーの要求から、プロダクトバックログアイテムが作成され、優先順位に基づいて並び替えられ、スプリントごとに完成され、お客様に価値として提供されていく様子が語られます。

このようなストーリーはどれもアプリケーション開発チームの事例です。

インフラチームはシステムの安定稼働により価値提供に貢献しますが、お客様が直接触る機能を実装するわけではありません。

当時の私はここでつまずきました。

そもそもスクラムの導入事例がアプリケーション開発チームのものばかりで、インフラチームが導入したという事例が少なかったのです。

もちろんゼロではなく、ネットで「インフラ スクラム」で検索すれば、各社の素晴らしい事例を参照することができます。

しかし残念なことに、柔軟性の高いクラウドインフラの利用が前提であったり部分的なプラクティスの採用に留まっていたり、その他様々な要因により、中々私達のチームが参考にできそうな取り組み事例が見つかりません。

オンプレミス環境を扱う私達インフラチームにとって、スクラムはそぐわないのだろうか？と迷いが生じました。

 

幸い、所属部署でスクラムの研修を受講させていただく機会があり、その研修により、上記の迷いは単なる思い込みによるものであることが分かりました。

その思い込みは、一言で言えば「アジャイルとスクラムの混同」です。

アジャイルはソフトウェア開発のための方法論であり、スクラムは問題解決ためのフレームワークです。

アジャイル開発におけるプロジェクト管理手法の1つとしてスクラムを採用する、という関係性です。

「お客様に対して」継続的に価値を提供することを要求するのはアジャイルの方であり、スクラムは、「継続的に価値を提供する」としか定義されていないのです。

 

こう書くと当たり前のことですが、当時の私のような初学者の中には「アジャイルだと設計ドキュメントの作成はお客様への直接の価値提供にはならないんでしょ？じゃあオンプレミス環境のインフラ開発でスクラムは無理ってこと？」とよく調べずに早合点してしまう人がいるのではないか、と感じます。

実際にはそのようなことはありません。

インフラ開発においてもそれぞれの工程において成果物は作成されますし、その成果物がプロダクトゴールの達成に有用であり完成の定義を満たしているのであれば、それはインクリメントになります。

スクラムガイドにおいても下記のように述べられております。

スクラムを採用できるのはソフトウェア開発プロジェクトだけではありません。

スクラムが誕生したソフトウェアプロダクト開発の領域を超えて、本質的に複雑な作業を必要とするさまざまなドメインでスクラムが採用されている。

（引用：Ken Schwaber, Jeff Sutherland, (2020), The Scrum Guide, https://scrumguides.org/docs/scrumguide/v2020/2020-Scrum-Guide-US.pdf, （角征典, 荒本実, 和田圭介（訳）（2020), スクラムガイド, https://scrumguides.org/docs/scrumguide/v2020/2020-Scrum-Guide-Japanese.pdf））

よって、オンプレミス環境のインフラ開発においても、スクラムは問題なく導入可能なのです。

第二の落とし穴：タスクの可視化≠透明性の確保

軽量フレームワークということもあり、スクラムの導入決定後、開始までの準備を整えるまではスムーズにできました。

私達のチームは元々、問題管理のためにRedmineというチケット管理システムを使っていたため、これを流用することにしました。

チームメンバーはそれぞれ抱えているプロジェクトがありましたので、その各業務を改めてプロダクトバックログアイテムとして整理し、チケットとして起票していきます。

各スプリントイベントをカレンダーに登録し、いよいよ1回目のスプリントを回してみます。

そしてそのスプリントのスプリントレトロスペクティブにおいて、真っ先に出た感想がこちらです。

 

「これ今までと何が変わったの？」

 

改めて振り返ってみると、1回目のスプリントで実施した、自分の抱えている業務を各々で進めて進捗を毎日共有する、ということは今まで普通にやっていたことのように感じられます。

この時点でスクラムによる恩恵は感じられませんでした。

スプリントプランニングもスプリントレビューも、型通りやってみたところで、ただ目の前の業務をこなしているようで計画的に行動できているようには思えません。

 

何が問題だったのか？

チームで話し合うことで見えてきたのは「透明性に欠けている」という点でした。

単に業務をプロダクトバックログアイテムに変換し作業を可視化するだけでは不十分なのです。

特定のメンバーが休んだらそのプロダクトバックログアイテムが進まなくなる、ということでは透明性があるとは言えません。

プロダクトバックログアイテムの進捗を属人化させず、チームメンバー全員で協力して取り組むことで、初めて透明性が確保され、チームとしての生産性に基づく計画立案が可能になるのです。

この点に気づいてからは、プロダクトバックログアイテムを個人に割り当てることはやめ、スプリントバックログのタスクの単位でアサインするように変更しました。

それにより、自然とメンバー間の協同が促進され、チームとしての生産性がどの程度か見えてくるようになりました。

第三の落とし穴：スプリントバックログはどこに？

同じく1スプリント目のスプリントレトロスペクティブで、こんな課題が持ち上がりました。

 

「タスクのチケットとプロダクトバックログアイテムのチケット、進捗はどちらに書けば良いの？」

 

当初、チケット管理システム上ではプロダクトバックログアイテムとスプリントバックログのタスクは別のタイプのチケット（トラッカー）として作成していました。

そのため、タスクとプロダクトバックログアイテムとの関係性は下記のように、タスクの親チケットの属性に、紐づくプロダクトバックログアイテムのチケットを指定するというやり方で管理しておりました。

導入前はこの構造が自然だと思ったのですが、いざスプリントを終えてみると、日々の作業に関する情報をどちらのチケットに書けば良いか混乱してしまうという問題があることが分かりました。

また、タスクごとにチケットを作成しなければならないため、チケットが多量になり、その作成にかかる手間も馬鹿にならないことに気づきました。

 

チーム内での相談の結果、タスクのチケットは不要ということで廃止し、各タスクはプロダクトバックログアイテムのチケットの説明欄に、リストとして記載することにしました。

この問題は単なるツールの都合で、チケット管理システムを採用していなければ起こらなかったものかもしれません。

ただ、いずれにしても、スクラムの管理をシンプルに保つという意識があれば、こうした設計にしなかったとも考えます。

スクラムはシンプルだからこそ活きるという側面もありますので、その方向性から逸れていないかは注意する必要があるかと思います。

第四の落とし穴：空白の時間と見えないタスク

ある日のデイリースクラムのこと、タスクの進捗状況について確認したところ、あるメンバーから「昨日は問い合わせ対応に忙殺されていたため、特に進捗は無い」という共有がありました。

よくある割り込みタスクです。

今までの仕事の進め方であれば、各メンバーが時間をやりくりして仕事を間に合わせるという進め方でしたが、前述の通りそれではスクラムの透明性が確保されているとは言えません。

 

この問題に対しては最初、割り込みタスクを減らしていくというアプローチを考えましたが、直ぐに筋が悪いことが分かりました。

私達のチームはDevOpsの領域も担当しており、障害や問い合わせへの対応をゼロにする方向性は現実的では無かったためです。

 

この問題への対策は直ぐには思いつきませんでしたが、「スクラムチームの生産性の最大化を目指す」のではなく「スクラムチームの生産性の安定化を目指す」という風に意識を変えたところ、解決策が見えてきました。

チームメンバー全員をそのスプリントに参加させるのではなく、割り込み当番というロールを作り1人をアサインすることで、他のメンバーが割り込みタスクをやらなくて済むようにしたのです。

割り込み当番となるメンバーは原則、スプリントバックログのタスクを担当しないようにします。

そうすれば、他のメンバーで構成されるスクラムチームの生産性は安定化します。

そして生産性が安定化すれば、プロダクトゴール完了がいつ頃になるかの予測精度が向上するのです。

チームを取り巻く状況によっては、割り込み当番が1人では足りないことも想定されます。

その場合は、スプリント終了のタイミングで、次のスプリントでは割り込み当番の人数を増やすということも検討します。

そうすれば当然、スクラムチームの生産性は一時的に低下しますが、「当該スプリントは減った人数の分だけ生産性が低下する可能性が高い」ということが事前に分かりますので、予測精度への悪影響を抑えられます。

 

現在、私達のチームの割り込み当番は、障害や問い合わせへの対応のみならず、週報や部会報告の資料作成など、スプリントバックログのタスク以外の全業務を任されています。

割り込み当番が担当するタスクもまた、プロダクトバックログアイテムとは別のチケットとして管理することで透明性を確保します。

これにより、他のメンバーがスプリントゴールの達成に向けて専念できるようにチームを支えています。

また公平を期すため、スプリントプランニングのタイミングで割り込み当番のローテーションを行い、チケット化された割り込み当番のタスクを引き継ぎます。

ローテーションにより、全てのチームメンバーが公平に割り込み当番を経験するようにしています。

第五の落とし穴：結局「あの件」はいつ終わるの？

第四までの落とし穴を超え、何回かスプリントをこなし、なんとなくスクラムが身についてきたような気がしてきた時のことです。

とある定例会で、マネージャー層からこう聞かれました。

 

「それで、○○はいつ頃終わりそうですか？」

 

私はその質問に対して、自信満々で、予測される日付を答えようとします。

今度こそ大丈夫なはずです。まさにそのためスクラムを導入したのですから。

そして、ふと別の仕事のことが脳裏に浮かびます。

（待てよ、あれとあれのプロダクトバックログアイテムが次のスプリントに含まれれば○○完了の予定だけど、優先度的には△△に紐づくプロダクトバックログアイテムも含めないといけなかったな……あれ、ストーリーポイントのサイズ的に無理かも？）

一瞬のためらいの後、私は、△△のことを考慮していない日付を回答します。

結局、自信を持って回答することができませんでした。

 

なぜこうなったのでしょうか。

改めてチームで検討した結果、プロダクトゴールとスプリントゴールの扱いに問題があることが分かりました。

私達のチームは、そもそもプロダクトゴールもスプリントゴールも設定していませんでした。

私達は別々のロードマップを持つ複数のプロジェクトを抱えており、統一的なゴールを設定することができなかったのです。

これでは、いくらプロダクトオーナーが優先度に基づきプロダクトバックログアイテムを並べ替えたところで、「あの件」がいつ終わりそうかは分かりません。紐づかないプロダクトバックログアイテムを完了させても「あの件」の進捗はゼロだからです。

 

この問題は、それまでの落とし穴の中で一番深いものでした。

そもそもスクラムにおいてゴールの設定が難しい状況への対応策なんて存在するのでしょうか？

チームで議論を重ねた結果、時間はかかりましたが「プロダクトバックログを分割する」という手段で一応の解決を見ました。

プロジェクトごとにプロダクトゴールを設定し、プロダクトバックログを分け、その中でプロダクトバックログアイテムの優先度付けを行うのです。

その時点で一番優先度の高いプロジェクトがどれであるかは、ステークホルダーとプロダクトオーナーとの間で決定します。

そしてスプリントプランニングでは、そのプロジェクトに紐づく優先度の高いプロダクトバックログアイテムのみをスプリントに含めるようにし、スプリントゴールを明確にします。

次のスプリントプランニングまでに、再度プロジェクト間の優先度付けを確認し、必要に応じて次のスプリントでは別のプロジェクトを進めるようにします。

このようにプロダクトバックログアイテムの優先度を2段階で決定し、スプリントごとに進めるプロジェクトを切り替え可能にすることで、並行して計画的に進めることができます。

「いつ終わりますか」という質問に対して「残りのストーリーポイントは何々で、1スプリントで平均して何々ポイント消化できます。そのため何々スプリントで完了が見込まれますので、このままこのプロジェクトを進めていく前提であれば、いついつ頃に終わる想定です」と自信を持って回答できるのです。

 

ただし、このやり方がスクラムガイドに沿っているかというと若干怪しいです。

スクラムガイドでは下記のような記載があり、「プロダクトバックログを切り替える」という手法を否定しているような印象を受けます。

プロダクトゴールは、スクラムチームの長期的な目標である。次の目標に移る前に、スクラムチームはひとつの目標を達成（または放棄）しなければならない。

（引用：Ken Schwaber, Jeff Sutherland, (2020), The Scrum Guide, https://scrumguides.org/docs/scrumguide/v2020/2020-Scrum-Guide-US.pdf, （角征典, 荒本実, 和田圭介（訳）（2020), スクラムガイド, https://scrumguides.org/docs/scrumguide/v2020/2020-Scrum-Guide-Japanese.pdf））

この解決策の採用に時間がかかったのも、スクラムガイドの記述的に問題ないかの検討が必要だったからです。

一応、現状ではこのやり方で問題無くスクラムの恩恵を受けられていますが、チームの長期的な目標にぶれが生じないかについては留意しなければならないと考えております。

落とし穴を超えて：インフラチームの近況

試行錯誤を経て、スクラムの各構成要素はチケット管理システム上で下記のように整理されました。

プロダクトバックログ

 

前述の通り、私達のチームではプロダクトバックログが複数存在します。

全てのプロダクトバックログアイテムのチケットは「サブプロジェクト」という属性を持っており、この値によりアイテムのグルーピングを可能にしています。

またプロダクトバックログアイテムは「優先度値」という属性も持っており、これによりアイテムの優先度による順序付けを可能にしています。

優先度付けについては、本来なら各プロダクトバックログアイテムをドラッグアンドドロップで並び替えられるのが理想なのですが、このやり方でも十分機能します。

スプリントバックログ

プロダクトバックログアイテムをスプリントへ含める際には、Redmine上ではチケットの「バージョン」という属性に、該当するスプリントをセットします。

これにより、スプリントに含まれるプロダクトバックログアイテムをリストすることが可能になります。

プロダクトバックログアイテム

プロダクトバックログアイテムの完成の条件や必要なタスクのリストは、チケットの説明欄に記載しています。

また見積もったアイテムのサイズは、ストーリーポイントという属性に値としてセットします。

ステータスには状況に応じて下記の値をセットします。

• 「新規」：アイテムが作成された直後の状態、下書き状態を含む
• 「準備完了」：アイテムの完成の条件が定義されており、スプリントに含められる状態
• 「進行中」：現在進行中のスプリントに含められている状態
• 「終了」：プロダクトバックログアイテムが完了した状態
• 「中止」：何らかの理由でプロダクトバックログアイテムとして扱うことを止めた状態

まとめと今後の展望

本稿では、私達インフラチームが、試行錯誤の末にどのようにしてスクラムを導入したか、その過程についてお伝えいたしました。

現在の状態も完ぺきではありません。

特にスクラムにおけるメトリクスの可視化については大きな課題だと考えております。

現在、RedmineのAPI経由で取得した情報を加工することで、下記のように生産性（ベロシティ）の可視化やバーンダウンチャートの生成まではできています。

そのため今後は、例えばプロダクトバックログアイテムのサイクルタイムを計測し可視化することで、チームの生産性の安定化に関する深い分析ができるようになれば、と考えています。

以上になります。ご覧いただきありがとうございました。