ニフティ株式会社でマネージャーをしている北浦です。
今回は私がマネジメントしている基幹システムグループ 課金システムチームのマネジメントについて紹介します。とはいえ自身のマネジメント歴が浅い（2022年4月〜）ので、今回は僕たちのチームがどのようにスクラムを導入していったのかを書いてみたいと思います。
(0) スクラム導入前
2017年まで課金システムチームの前身のチームではウォータフォール開発を採用し、ほぼ全ての開発業務を外注していました。社員の業務は要件整理や社内外調整、プロジェクトマネジメントなどがメインであり、自ら開発を行うシーンはとても少なかったと思います。社内向けツールや運用作業の自動化などで開発を行うメンバーもいましたが、コードを一切書かないメンバーもいました。
また、属人化もかなり進行しておりシステムごとに人（社員＆協力会社メンバー）が張り付いており、同じチーム内でも隣のシステムについては全く分からず手が出せない状況でした。
このような環境の中でチームメンバーが大きく変わっていきましたが、いざシステムを引き継いでみると多くの問題が発生しました。”ドキュメント化されていない業務仕様”、”ドキュメントがなくリポジトリ管理されていない謎のプログラムがプロダクション環境で動いている”、”ビジネス部門の担当者が不在”、”社員が仕様を把握しておらず協力会社メンバーしかわからない(そのメンバーは既にプロジェクトから離れている)”など、とても苦労しました。
このままではまずいということで、主に属人化の解消とエンジニアの技術力向上を目指しスクラムを導入することにしました。
(1) 1チームスクラム: 1プロダクトを開発
2018年からスクラムを導入しました。既存プロダクトの全面刷新をスクラムで完全内製開発しました。ポイントは以下です。
- スクラムマスター研修に参加してスクラム開発を学ぶことで導入時のハードルを下げた
- 比較的規模の小さい既存プロダクトを対象として全面刷新する方針とした
- ビジネス部門に相談してPO(プロダクトオーナー)を立ててもらった
- 職制上のチームを跨いでスクラムチームを構成、若手メンバーに多く参加してもらった
ウォータフォール開発に慣れていたメンバーにとって、最初はスクラムガイドや書籍で勉強してもなかなかスクラム開発のイメージを掴むのは難しいので、一部メンバーがスクラムマスター研修に参加して学んできたことはスクラム導入がスムーズに進められた要因の一つだと感じています。
以降、各フェーズごとにKPT法でふりかえってみたいと思います。
良かったこと
- ビジネス部門とシステム部門が協力して”プロダクトを育てる”という意識が芽生えはじめた
- 小さく始めることで無理なく少しずつスクラムに慣れていくことができた
- 完全内製によるチーム開発の土台づくりができた
- 開発スキルを向上できた
改善したいこと
- 暫定で組んだスクラムチームだったので”チームの成長”をメンバーが意識しづらかった
- スクラムチームメンバーは職制上チームのタスクも継続して担当していたため、スクラムに注力できないメンバーが発生してしまった
- 初期リリース実施前に職制上チームのタスクが忙しいメンバーはスクラムチームから外れることになってしまった
- メンバーが職制上チームを跨ぐのでマネジメントが難しい
トライ（実験）
- チームを跨ぐ状況を改善して職制上チームとスクラムチームを一致させる
(2) 1チームスクラム: 複数スクラムを同時に実施
2019年からは職制上チームとスクラムチームのメンバーが一致するようチームを再編しました。また、別プロダクトでもスクラム開発したいものがでてきたので、新規にスクラムを立ち上げて複数のスクラムを同時に実施してみました。以下がそのふりかえりです。
良かったこと
- 新規にスクラムを開始したプロダクトはプロトタイプを小さくリリースしてPOから早期にフィードバックをもらうことで必要な機能を素早く提供できた
改善したいこと
- 同時期に複数のスクラムを1チームで実施することによるオーバーヘッドが想像以上に大きく、開発時間の確保が難しかった(スイッチングコスト、各種スクラムイベントなど)
- スクラム対象プロダクト以外にもチームが担当しているプロダクトがあるが、それに割り当てる時間がなくなってしまった
トライ（実験）
- 全てのプロダクトを1つのスクラムで管理してみる
(3) 1チームスクラム: 複数プロダクトを対象とした1つのスクラムを実施
1つのスクラムチームが複数のスクラムを同時に実施するのはかなり厳しいことがわかりましたので、2020年からは1つの職制上チームが担当する全てのシステム・サービス・プロダクトを1つのスクラムで管理してみることにしました。ただし、全ての関係者のスケジュールをあわせることが難しかったため、各プロダクトのPOと簡易スクラムイベントを個別設定することで対処しました。以下がそのふりかえりです。
良かったこと
- スクラムイベントのオーバーヘッドが削減できた
- 職制上チームが担当する全てのプロダクトに関するタスクが可視化され属人化解消に役立った
- 簡易スクラムイベントの導入によって各種イベント実施が効率化できた
改善したいこと
- プロダクトを跨ぐ優先順位付けが困難
- 社内システムへの要望やシステムリプレース対応のような技術的負債の改善につながる活動は、相対的に優先順位が常に低くなってしまう
- レガシーシステムに関するプロダクトバックログアイテムは認知負荷が高く多くのドメイン知識が必要となるため共有が進まない
トライ（実験）
- チームが担当するプロダクトのPOを集めて、各プロダクトのスケジュール共有会を定期的に実施してみる
(4) サブチーム同士が協力してスクラムを実施(検討中)
各プロダクトのPOを集めて実施するスケジュール共有会の実施により、事前にスケジュールのバッティングが確認できるようになり、早い段階で関係者と調整するなど対策が立てられるようになりました。
また、2021年には大規模スクラム(LeSS：Large-Scale Scrum)を採用し新規接続サービスの内製開発も行いました(こちらは別途ブログ化される予定です)。
2022年現在では、”複数プロダクトを扱う1チームスクラム”と”LeSS”の2つのスクラムを同時に実施しています。一般的にスクラムは”1つのチームは1つのスクラムに専念する”という大原則があるのですが、現実はなかなか難しい状況ですので現在の形となりました。2つのスクラムで可能であればスクラムイベントを共通化するなど、できる限り複数スクラムを実施することによるオーバーヘッドの最小化を目指しています。
現在は途中でもう1つサブチームが合流して2つのサブチームで課金システムチームとなったのですが、サブチーム間の協力がまだまだ弱いのでより良いチーム体制を模索しています。
チームにどのようにスクラムを導入していったのかを紹介させていただきました。”スクラムは理解するのは簡単だけど実践するのは難しい”と言われています。上記の内容がどこかのチームの参考になれば幸いです。
