インフラエンジニアがスクラムをやって学んだこと

インフラエンジニアがスクラムに挑む

栗田茉緒 氏：株式会社マネーフォワード、サービス基盤本部の栗田と申します。「インフラだってスクラムがしたい！」というタイトルで発表をさせていただきます。後ほどスライドを公開するので、そちらも合わせてご覧ください。

まず始めに、マネーフォワードは「MoneyForwordクラウド」や「MoneyForword ME」など、さまざまな多くのプロダクトを提供している会社です。私は2018年8月に入社したインフラエンジニアです。趣味は野球観戦です。

さっそく本題です。スクラムという開発の手法をご存知の方はどれくらいいらっしゃいますかね？

（会場挙手）

ほとんどですかね。その中でスクラムの手法を実際にお仕事でやられたことがあるという方はどれぐらいいらっしゃいますか？

(会場挙手）

半分ぐらいですかね。ありがとうございます。

スクラムとはアジャイル開発手法の1つでして、計画などを柔軟に対応して短期間で区切って進めていく手法です。チームのコミュニケーションが何よりも大切になるものです。

しかしスクラムについて調べたりすると、スクラムという言葉の後ろに「開発」という言葉が付くことが多いんですよね。

そこでちょっとこんな疑問が浮かびます。「スクラムって開発チームだけのものじゃないのか？」「開発チームじゃないとスクラムってできないんじゃないのか？」。きっとそんなことはないはず。ということで、私が所属するインフラチームでスクラムをやってみました。今回はその取り組みやその効果などについてお話させていただきます。

スクラムを導入する前、インフラチームは、ある課題を抱えていました。1つは改善系業務の進捗が良くないこと。もう1つはそれぞれチームメンバーが持つタスクが見えにくいことです。また、今後のチームのロードマップがあり、それを実現するためにもチームの結束力が求められていました。

スクラム開始当初の状況

これらの課題を解決し、最大の効果を出すために「スクラムをやっていこうぜ！」ということで、2019年1月からスクラムをチームで始めることにしました。

インフラチームの状況です。人数は時期にもよりますが6人から9人程度で、ほぼすべてのプロダクトのインフラを見ています。

やっていることとしては2つの大きな軸があり、1つはプロダクトをすべてAWSに移行すること、もう1つは運用保守の改善です。それぞれの軸の下にいくつかストーリーが存在しています。

スクラムを開始したときのスクラムのルールです。1スプリントを2週間に設定し、毎日10時半から15分間でデイリースクラムを実施することとしました。初日にプランニング、最終日には振り返りを実施します。タスクは付箋で管理します。できるところからスクラムルールを実践していきました。

ちなみにホワイトボードは物理の限界がすぐに来たので、JIRAというプロジェクト管理ツールを導入しました。

スクラムをやったことで得られた効果をご紹介させていただきます。持ちタスクが見えるようになった、結束力が向上した、大きくこの2つが挙げられます。

まず、メンバーごとやストーリーごとのタスクが見えるようになり、量や進捗がはっきりわかるようになりました。その結果、他のメンバーが遅れをカバーすることができるようになり、結果としてタスクの消化率やストーリーの進み具合が向上しました。

2つ目は、チームの結束力が向上したことです。原則1つのストーリーにつき2人以上割り当てるようにし、ひとりぼっちになってしまうことを防ぐようにしました。また、出てきた課題はチームの全員で解決するようにしていました。その結果、スクラムを始める前と比べてチーム雰囲気も良くなり結束力も向上していきました。

しかし、試行錯誤する中でいろいろな課題も発生します。大きく以下の3つです。

「割り込みが避けられない」「デイリースクラムが終わらない」「振り返りが変わらない」。

まず「割り込みが避けられない」ことです。インフラチームには日々、依頼作業が飛んできます。

「デプロイこけました。見てください」「アクセス許可がほしいのでお願いします！」とか、毎日のようにいろいろ飛んできます。そして、どうしても避けられないのが障害対応です。障害は、いつ来るかわからないものですし、障害が起きた場合はインフラチームは速攻で対応しないといけません。

さすがに「これらを一切やらない」とは無理ですし、何日も放置することはできません。しかも、現状すべての依頼に対応することができていませんでした。そこで私たちはどうしたかというと、「依頼作業をタスク化してしまう」という方針を一度取ることにしました。

割り込みをなくす、ということはすぐにはできないし難しいのですが、割り込みがどんなものだったか、と透明化することはできます。その結果、個人がそれぞれ管理していて不透明だった情報が見えるようになり、また誰がどのくらい割り込みタスクに時間を奪われていたのかがわかるようになっていきました。

デイリースクラムや「ふりかえり」の試行錯誤

次に「終わらないデイリースクラム」です。私たちのチームのデイリースクラムは、15分間でメンバーが1人ずつ昨日やったこと、今日やること、困っていることの3つを報告し、最後に全体共有事項……明日休むとか、飲み会の情報とか、そのあたりの全体共有事項を共有していくスタイルです。

しかし、気づいたら報告中にタスクの対応についてめちゃくちゃ議論をしていたり、気づいたら別の話で盛り上がっていたり、報告中に話が脱線したりしてしまう現象が多発していました。その結果、毎朝のデイリースクラムが15分ではまったく終わらないようになってしまいました。そこで私たちの解決策として、報告時間を設定することにしました。

1人あたりの報告の時間を1分半と設定しています。1分半だと最高9人、プラスその他1分半でちょうど15分になります。ストップウォッチで時間を管理し、脱線しかけたりオーバーしたら誰かが止めていく。そして続けて議論をしたい場合はデイリースクラムが終わったあとにメンバーを全員ではなく必要なメンバーに絞って実施するというルールにし、15分以内に終わらせるということを徹底してきました。

最後に「変わらないふりかえり」です。

私たちの「ふりかえり」は、スプリントが終わる隔週の金曜日に実施し、チーム自体やチームの活動を振り返っていくレトロスペクティブという形式で行っています。

課題を各自出し合ったあと、全員でその課題をカテゴライズしていき、その後に最も改善すべきだとそれぞれが感じるカテゴリに投票し、そこで選ばれた課題の解決策をみんなで決めて、次週以降に実践していくスタイルです。ちなみに前2つで挙げた課題解決策も、この振り返りから生まれたものです。

最初はメンバーが7人ぐらいでこれだけの課題が出ました。

3ヶ月後、メンバーは変わらず7人だったんですけどここまで減りました。比較するとめちゃくちゃ減ってますよね。

もちろん、ここで課題が減ること自体はとても良いことです。しかし、問題点や改善点のちょっとネガティブな要素を挙げるふりかえりだったので、課題がどんどん出なくなっていきます。なので、ふりかえりの雰囲気がどんどん暗くなり、飽きてしまうこともありました。そこで解決策として、新たなふりかえりの手法を導入することにしました。

例えば「ファンダンラーン」という、各自がやったことを付箋に書いて、それをFun、Done、Learnという3軸で振り返っていく手法を試してみたり、大きなストーリーが終わったあとにそのストーリーを完了させたメンバーで「どんなふうにやっていたのか？」という成果などをみんなで共有して全員で振り返ることを試して、状況に応じて振り返り手法を変えてマンネリ化やネガティブになることを防止していました。

ここまでいろいろ試した結果、インフラだってスクラムができました！

「スクラムの型にとらわれすぎない！」

まとめさせていただきます。スクラムをやるにあたって、私が大事だと感じたことをまとめています。まず1つは「スクラムの型にとらわれすぎない！」ことです。最初からすべてのルールを守ろうとせずに、自分たちがやれるところから実践していくことが大事だと思っています。

また、発生した問題に誰か1人ではなくチーム全員で向き合うこと、これも大事だと思っています。誰か1人が勝手に決めてそれをみんなに「やるぞ！」と言って実践するのではなく、全員でどうするかを考えて全員でやることを決める。そして全員で実践する。これもスクラムをやるにあたって大事なことだと考えています。

また、現状は私たちが実施しているスクラムは半年経ちましたが、まだ完成形ではありません。ここまで事例を聞いて、「スクラムはこんなんなのか」「これでスクラムなのか？」と思う方ももしかしたらいらっしゃるかもしれません。私たちも守り切れていないルールや改善しきれていない課題がまだまだあります。これからもスクラムをより良いものにしようと思っています。

スクラムを始めてとっても良かったと思っています。チームも私も非常に成長することができました！

以上です。ご清聴ありがとうございました。

（会場拍手）