セーフィーにおけるスクラム導入ふりかえり

この記事はSafie Engineers’ Blog! Advent Calendar 2日目の記事です。

セーフィー株式会社テックリードの鈴木敦志です。セーフィーでは開発者の積極採用を進めており、エンジニア組織の人数が2年間で約35名から約75名にまで成長しました。

開発者の人数増加に伴うチーム内のコラボレーションの問題に対応するため、アジャイル開発手法の一つであるスクラム開発をサーバー/インフラチーム内で導入し2年間ほど運用し、一定の成果を得られましたので経緯や実際の施策、結果などについて共有させていただきます。

スクラム導入前の課題
- チーム内のコラボレーションが希薄
- 業務知識の属人化
スクラム導入
スクラム導入により解決された課題
- チーム内コラボレーションの推進および知識移転の推進
解決されていない課題
- 機能横断型チーム
- プロダクトオーナー
今後の方針
さいごに

スクラム導入前の課題

スクラム導入前の開発組織はおおよそ職能別のチームで構成されていました。開発案件はプロジェクト単位に分割され、各プロジェクトごとに職能別チームから開発者を0~2名程度ずつ割り当てプロジェクトチームとしていました。各チームメンバーはそれぞれ1~数個のプロジェクトに並列で参加することになります。

チーム内のコラボレーションが希薄

各開発者は職能別チームの中ではそれぞれ参加しているプロジェクトが異なり、プロジェクトチームの中では他メンバーと職能が異なるため必然的に単独で取り組むことになるため、チームメンバーとの協調作業が難しい状況でした。例えば設計の相談やコードレビューの際も、相談を受ける側はプロジェクトの細かい要件や経緯を把握しているわけではないためどうしても形式的なものにならざるをえません。

業務知識の属人化

特定個人が特定のプロダクトやコードを触り続けることになるため、他のメンバーに知識が共有されづらくなります。改修案件や質問対応、障害対応が集中しやすくなり、また転属や退職などでの混乱が発生しやすくなります。

スクラム導入

こういった状況を改善するため、サーバー/インフラ開発者内でスクラムの導入を行いました。スクラムの導入には機能横断型チームの編成や開発案件の意思決定者としてのプロダクトオーナー制度の導入など組織構造の変更が必要になります。

今回は全社的な導入でなくあくまでサーバー/インフラ開発者の間でのボトムアップ的な導入であるため、こうした組織変更を伴う施策を行うことはできませんでした。スクラムガイドでも否定的に言及されているスクラムの一部的な導入にとどまってしまい、いくつかのメリットを受けることができませんが、それらを抜きにしてもチーム内でのコラボレーション促進の効果を得られると思い導入を進めました。

チームの分割

導入時点でサーバー/インフラチーム合計で11人のメンバーがおり、チームを2チームに分割しました (現在は4チーム)。それぞれのチーム内の開発者一名が兼務でプロダクトオーナーとしてプロダクトバックログの管理およびステークホルダーとの協議を行います。 (このプロダクトオーナーは実際にプロジェクト/プロダクトに十分な権限を持つわけでなく、バックログの管理と各プロジェクトの会議体に出席し要件を整理する役割です)

プロダクトバックログ

プロダクトバックログおよびスプリントバックログはWrikeにより管理されています。 Wrikeはさほどスクラムに向いている感じではありませんが、前者共通のプロジェクト管理で使われていたためツールを合わせました。

スクラムイベントの実施

スプリントを2週間 (チームによっては1週間) とし下記スプリントイベントを実施しています。

スプリントプランニング (1回/スプリント) スプリントで行う開発の計画を行います
デイリースクラム (毎日) 一日の作業の調整を行います
スプリントレトロスペクティブ (1回/スプリント) KPT法で開発進捗やチームの状況について振り返りを行います
バックログリファインメント (1回/スプリント) プロダクトバックログアイテムの詳細化を行います

スクラム導入により解決された課題

チーム内コラボレーションの推進および知識移転の推進

開発者をプロジェクトに割り当てる習慣をやめ、スプリントプランニングおよびバックログリファインメントの場で開発項目を全員で議論し詳細化することで、チームの全員が各開発項目の実装を実装を進めることができるようになりました。各人が別々のプロジェクトに割り当てられていた頃とくらべ、特定の技術や業務知識がある人とペアプロをしたり、各人の休暇や割り込み作業などにあわせてタスクを融通しあうなど、チーム内での協力と知識の移転を促進することができました。

チーム内でプランニングポーカーによるストーリーポイントの見積もりを行っており、見積り結果の値はまだ活用できていないものの、全員で見積りを行う行為自体が開発項目への理解を深めるのに役に立っていたように思います。

解決されていない課題

今回導入したスクラムは既存チーム内で完結するもののみで組織的なスクラム導入には至っていないため、スクラムにより解決が期待される課題の一部は残ったままです。

機能横断型チーム

スクラムチームは機能横断型であり、必要な機能をすべて備えていることを求められます。一方で現在の組織は職能別のチーム構成となっておりひとつの機能を実装するにはサーバーチーム、フロントエンドチーム、デバイスチームなど複数チーム間での情報共有や優先度や調整が必要になり、都度ロスが発生します。

プロダクトオーナー

スクラムにおいてプロダクトオーナーはチームが開発するプロダクトに権限と責任をもつロールです。現在の組織体制では開発案件の権限はプロジェクトマネージャーが持っており、スクラムのプロダクトオーナーに当てはめることはできません。今回のスクラム導入の範囲ではチームの開発者のうち1名を便宜上プロダクトオーナーとし、各プロジェクトのミーティングへの出席やステークホルダーとの折衝およびプロダクトバックログの管理を行っています。プロダクトに関する意思決定者がチームの近くにおらず判断に時間がかかりますし、開発業務と平行して複数プロジェクトのミーティングに出席するため非常に負荷が高くなります。

今後の方針

開発チームにスクラムを導入し、チーム内コラボレーションの促進および業務知識の属人化防止に一定の成果を得ることができました。しかしボトムアップ的に始まったためスクラムのフレームワークすべてを導入できているわけではなく、チーム内でのスクラムイベントの実施などの一部のみにとどまっています。スクラムのメリットを享受して組織課題を解決していくためには組織全体として対応していく必要があり、今後はスクラムの推進のための施策を進めていきます。