この記事は、ニフティグループ Advent Calendar 2023 21日目の記事です。
この記事を読んで分かること
- ニフティの情シス（コーポレートエンジニア）の概況
- スクラムとは何か（ざっくりと）
- 情シスでスクラムをやるにあたってどんな工夫をしているか
ニフティで情シス、スクラムマスターをやっている小浦です。人生で初めてクリスマスケーキを予約したので、今年はクリスマスがとっても楽しみです。豪快に1/4に切って大きいフォークでワシワシと食べる予定です。
さてさて、今日はスクラムの話をします。スクラムといっても開発チームではなく、運用メインの情シスでスクラムをどう工夫してやっているかについて話したいと思います。
ニフティの情シスとは？
名前に情シスの冠を持った組織はありますが、ニフティはエンジニア集団なので情シス的役割を果たしている人がその組織外にもいたりします。
私のチームはその冠をもった組織の中にあり、GWSやSlackなどのSaaSやオンプレのアプリケーションetcの管理運用を行っています。この記事では各SaaS、アプリを「プロダクト」と呼ぶとして、プロダクトを数えてみると24個ありました。
私のチームは情シスですが、スクラム体制を採用しています
情シスでスクラムを採用しているところはあまりないと思いますが、私のチームは約3年前からスクラム体制で活動しています。
スクラムとはチームが一丸となってプロダクトを迅速に良くしていくためのフレームワークです。スクラムでは、チームメンバーがスクラムマスター（スクラムチームをうまく機能させる人）、プロダクトオーナー（プロダクトの未来を決め、願いを表現する人）、開発メンバー（プロダクトオーナーの願いを実現する人）に分かれ、スプリントと呼ばれる短い期間の中で決められたイベントを通してコミュニケーションをとりながら、そのスプリントにやるべきことだけに集中して開発とリリースを行い、それを繰り返していきます。
情シス的には次のようなメリットがあります。
- 目的意識を強く持ち続けることができる
- 突然の変更、変化に適応できる
- 業務共有が進み、属人化、スキルの偏りが解消される
- コミュニケーションの機会があらかじめ設定されているので、シャイな人が集まりやすい情シスチームでも交流が持てる などなど
複数のプロダクトを抱えていて、運用が多く、ウォーターフォール式でプロジェクトが進みがちな情シスにはあまり用いられていませんが、上記のようなメリットを享受するべく日々工夫してスクラムしています。
情シスでスクラムやっているよ、の触りについては以前のLT（下記）や、技術書典で頒布した「ニフティのスクラム」で紹介しているのでよろしければご覧ください。
※当時プロダクトは14個でしたが、2023年の4月に別の情シスチームを吸収したことにより24個に増えました。開発メンバーも3名→9名に増え、スクラムチームとしてはかなり賑やかな体制になりました。
【本題】情シスでスクラムをやるにあたってどんな工夫をしているか
以前のLTや本記事の冒頭でも「情シスはスクラムに向いていない」と散々書いてきましたが、工夫したポイントについてすべて書きます。
プロダクト横断的に優先順位がわかるようにした
24個のプロダクトを1つの大きなプロダクトと見なし、スプリント内のタスク（※スクラムではスプリントバックログアイテムといいます）を一元管理することでチーム全体で優先すべきタスクが分かるようになりました。
＜そうした理由＞
スクラム前はプロダクトごとにタスクを管理しており、さらにプロダクトと人が属人的に結びついていたので「いまチームで最も重要なこと、急ぎで対応すべきことが何か分からない」「隣の人が忙しそうだけど手が出せない」状態で非効率的だったからです。
＜実際にやったこと＞
すべてのタスクをスプリントバックログと呼ばれる「このスプリントにやることリスト」に集め、重要なこと/急ぎで対応することに重みづけを行い、スプリントバックログアイテムを並べ替えて確認できるようにしました。
▼スプリントバックログのイメージです。プロダクト関係なく、Must（対応必須）、Should（対応すべき）、Could（できれば対応）で並んでいます。列は状態です。
プロダクト全体に通じるチームのビジョンを作成し、全員で同じ方向へ向かえるようにした
チームビルディングを兼ねてビジョンを作成し、全員のありたい姿が一致するようにしました。
＜そうした理由＞
私のチームは出来た当初はいわば寄せ集めで、それぞれが目指す方向や考えていることがばらばらの状態でした。その状態を続ければ考えの違いでいつかは衝突するし、推進力も生まれないと思ったからです。
＜実際にやったこと＞
一つの方向に向かって進めるように、全員でありたい姿を持ち寄って言葉にまとめたチームビジョンを作成しました。
▼ビジョンのブレストの様子
スクラムのルールで決められたイベント＋αを通してコミュニケーションの機会を増やした
コミュニケーションをとることによりお互いを知り、悩みやタスクをシェアできるようになりました。
＜そうした理由＞
チーム発足時、ちょうどコロナ禍が始まったところでニフティもフルリモートワークになりました。フルリモートワークで属人的に仕事をしていると、チームの誰とも会話せず一日を終える…なんてこともありました。これでは属人化の解消もできず、チームで動いている意義もありません。
＜実際にやったこと＞
スクラムにはデイリースクラム（朝会）、プランニング、レビュー、レトロスペクティブといったコミュニケーションをとる機会を設けるルールがあります。これらの他に、雑談タイムや作業配信（運用などをおもむろに社内向けにライブする）なども行い会話できる機会を作っています。
特に属人化しているプロダクトについて共有会を行い、他の人でもタスクがこなせるようにした
＜そうした理由＞
属・人・化…情シスあるあるだと思います。その人がいなくなると誰も分からない、そんな状況を打破したかったからです。
＜実際にやったこと＞
特に属人化が激しいプロダクトについて週次で共有会を開催し、業務共有を行ったうえでそのプロダクトの細分化されたタスク（スクラムではスプリントバックログアイテムと言います）に対し「✕✕さん以外でもできる」というタグ付けを行いました。そのタグがついたスプリントバックログアイテムを✕✕さん以外がどれだけ消化したかについてスプリントの終わりに振り返りを行いました。
3年間情シスでスクラムをやって見えてきたこと
ここまで読んだ情シスの方は、きっと「大変そう」と思われたことでしょう。そう、スクラムはコストがかかる取り組みなのです。しかし3年間継続してみた結果、投資対効果でいうと効果の方が大きく上回ったと断言できます。もし、3年前にスクラムを始めていなかったらずっと寄せ集めチームのままで活動していたことでしょう。特に情シスは長く続いている組織が多く、ヒトも固定されていて新しい取り組みがしづらいケースが多いのではないかと思います。その現状を打破したい時に、スクラムのような型にはめるようなやり方は案外気楽ではないかと私は考えます。もちろんすべてを完璧にしてから始める必要はありません。まずは「スクラムっていう良さげなやり方があるんだって…」と、デイリースクラムから始めてみるのがおススメです。
まとめ＋宣伝
今回はニフティの情シスと、私のチームで取り組んでいるスクラムについて工夫点に焦点を当ててご紹介しました。
体制が変わる前の文章になりますが、当時の開発メンバーがスクラムについてどう思っているかなどのコメントが載った本がありますのでぜひご覧ください。ニフティのスクラムマスターが寄稿しあって作った本なので、スクラムそのものに関心がある方もぜひダウンロードを！（無料です）
▼クリックするとダウンロード画面に飛びます
また、ニフティの情シスメンバーも大募集中ですのでご興味がありましたら採用サイトをご覧ください。
明日の記事は…
明日の記事を書いてくれるShibataRyuseiさんは、実は1年目のエンジニアが全員体験するジョブローテーションという制度で3カ月間情シスにきてくれました。その後マイニフティチームに配属となり、すっかりチームの顔になったShibataさんの記事が楽しみです！
