この記事はSafie Engineers' Blog! Advent Calendar 19日目の記事です。
序文
セーフィーのクラウド録画サービスのサーバーサイド開発を担う、サーバー第一グループというチームでグループリーダーをしている三村です。自分はセーフィー入社前まではプレイヤーとしてサーバーサイドの開発を行うことが多かったですが、入社後はたまたま機会がありマネジメントの仕事も任されるようになり、その一環としてチームの開発手法を改善しようと活動してきました。アドベントカレンダーの季節なので、その一部をブログで共有できればと思います。
チームの紹介
メンバーの構成
セーフィーの開発組織は人数が多く、サーバーサイドエンジニアだけでも人数が30人以上がいます。そのため、サーバーサイドエンジニアのチームも複数に分かれています。映像配信に関する開発チーム、AI機能に関する開発チーム、社内や代理店向けの管理ツールの開発チームなどがある中、私のチームはユーザー向けの新規機能を開発するチームとなっています。
チームのメンバー数は異動などから変動しつつもの、だいたい6〜8人くらいで開発をしています。メンバーは比較的若手が多く、新卒数年目の人から30代前半くらいの人で構成されていて、社歴は長くても3年くらいまでです。
開発内容
開発する内容としては、社内で走っている複数の開発プロジェクトに対応する形で開発をしています。プロジェクトの例としては、
- カメラを用いた侵入者検知プロダクトの「Safie Security Alert（セーフィー セキュリティ アラート）」の開発
- 既設のIPカメラをセーフィークラウドで視聴可能にする「Safie Trail Station（セーフィー トレール ステーション）」の開発
- 高速道路業界向けの「キロポスト表示」機能の開発
- クラウド録画サービスをベトナムなど海外で利用できるようにする開発
など、種類は多岐に渡っていてそれらを並行で開発をしています。
弊社はカメラやサイレン、ライトなどのモノを扱う開発をしているため、新機能追加時にはソフトウェアエンジニアやPdMだけでなく、デバイスエンジニアから機器の調達や配送、カスタマーサポートの立て付けなど、一般的なWebサービスの開発と比べてより多くの人が関わります。そのため新機能の開発の際にはそれら関係者を一堂に集めたプロジェクトが作られて、私たちサーバーサイドエンジニアもそれらに参加をし、開発内容をチームに持ち帰ってタスク化しています。
そのためチームの開発の仕方も、一つのプロダクトをじっくり腰を据えて開発しているというよりは、複数の文脈の開発を並行して行っているような体制になっています。加えチームとしてはサーバーサイドエンジニアのみを抱え機能開発に必要な他のエンジニアがいないことから、一般的なスクラム開発がしにくい体制となっています。
当初の開発手法
どこかしっくりこないスクラム開発
私がこのチームにジョインした頃は、チームはスクラム形式で開発を行っていました。プランニングで決めた内容を2週間のスプリント期間でこなし、スプリント終わりの振り返りでベロシティ等を確認する形式でした。
ただし上述の通り一つのプロダクトのみを開発するような体制ではなく明確なスプリントゴールが決めにくいことや、スプリント期間中に臨機応変に差し込みで消化しなければならないタスクも多く、プランニングでの計画通りにはスプリントが進まないことが多かったです。結果的に、スクラム開発のセレモニーは一通りこなしてはいるものの、「スプリント期間で動く機能を実装して少しずつプロダクトを良くしていく」というスクラム開発の本質的な部分をあまり実践できていなかったです。
肥大化する振り返り
スプリント期間の終わりに振り返りを実施していました。そこで行う内容も段々と肥大化していき、時間がかかるようになっていきました。
例えば、フレームワークとして一般的なKPTを使っていたところに、Fun/Done/Learnというものも面白そうだという話になり、その二つを組み合わせた形で振り返りで行っていました。また振り返りの際に指標として取るメトリクスも、一般的なベロシティに加えてメンバーの自己申告の「幸福度」などさまざまなものをとるようになり、数が増えていきました。
メンバー間のタスクの理解度の差
複数のプロジェクトの開発を一つのチームで開発している関係で、メンバー間でタスクへの理解の差が生まれていました。スプリントに積むタスクの内容説明は2週間に一回のリファインメントの時間のみであり、時間が足りていなかったです。
改善の取り組み
根本的には、チームで一つのプロダクト開発というよりは複数のプロジェクト形式での開発をしていることによる負が多かったですが、そこの改善には別途職能横断型チーム化に移行しようという動きなどもあったため、一旦は現状を受け入れる形で改善に取り組みました。
スクラムを辞める
まず最初に、スクラム形式で開発をすることを辞めました。臨機応変に複数のPJの要請でタスクを差し込みで詰む必要のあるチームの現状と、スプリント期間中の開発内容を固定して機能を作り上げていくスクラム形式が合わないという現状を受け入れたための判断でした。
その代わりにチームで取り入れた方式が、カンバンでした。カンバン開発は、スクラムのような厳格な期間設定なしに、継続的なフローを重視するアジャイル手法です。視覚的なボードを活用して作業状況を共有し、チームがタスク消化のリードタイムを縮めるようプロセスを改善することを目指しています。
個人的には、ゾンビスクラムサバイバルガイドという本を読んでチームのスクラム開発の現状への問題意識を改めて持つようになりました。この本ではセレモニーはこなすものの、本質的にスクラム的な思想の実践はできていない状態で、どのようにスクラム的な開発に近づけるかのケースワークの紹介がされていますが、私のチームにおいては根本的な原因のチーム開発の体制の改善は一旦置いておいて、最終的にスクラムをやめる判断となりました。
タスク内容を議論する時間を多く確保
カンバンに移行してからも、スクラム時代に行っていたセレモニーを全て辞めたわけではありません。例えばスクラム時代に行っていたリファインメント*1の時間は、これまでスプリント期間中一回しか行っていなかったものを、2日に一回程度まで時間を確保するように増やしました（話題にするタスクがなければ流会にしているので、最大限これらの時間を使っているわけではないです）。
上述のようにチームでは様々なプロジェクトでの開発を行なっているため、スクラム時代にはチームメンバーは自分のあまり深く理解できてない文脈のタスクを取って時間がかかってしまうという課題がありました。そのためカンバンに移行した後は、タスクについてなぜそれをやる必要があるのか、それがユーザーにどのような価値を提供するものなのか、また実装上どのような不確実性があるのかなどをチームメンバーで議論する時間をより長く設けました。
また日々のリファインメントに加えて、大きな機能開発の始めの際などは別途時間を取りチームメンバー全員が集まり設計について議論をする時間（特に大きな機能の場合は合計で数時間程度まで）を設けるようにしました。これまでは担当者一人が設計をしてそれを元にタスク化してチームで消化するような形であった中、メンバー全員が設計段階から少なくとも話は聞いているような状況にすることで、理解度の差を埋めようとしました。
振り返りは継続も簡素化
リファインメントだけでなく、振り返りの時間もチームの開発手法改善のための話し合いだけでなく、単純にコミュニケーションの機会としても意義を感じていたため引き続き2週間に一度実施しています。ただしその際に採る指標は、消化したタスクのリードタイムやタスク数ベースでのチームのスループットなど、チームの生産性の関するものに限定するようにしました。また方式はシンプルにKPTに戻しました。
デイリーミーティングの司会の輪番化
元々スクラムを行っていた時は、デイリーミーティングの司会はスクラムマスターを兼任するエンジニアメンバーによって行われていました。スクラムを辞めたことを契機に、この司会の役割をメンバー間で輪番としました。目的としては、デイリーミーティングの場を自分の出番が来たら喋るだけの場でなく、各メンバーが主体的に情報共有する場としての意識を持てるようにすることでした。
成果と課題
一番大きな問題であった、チームの現状とチーム開発のプラクティスのズレの意識は解消することができました。複数文脈の開発の中で突発的に発生する差し込みタスクを、スクラム開発時代は例外として扱わなければならなかったものを、カンバン開発では想定内のこととして振り返りなどでも扱うことができるようになりました。
また振り返りを生産性に関するものに限りシンプルにしたこともあり、チームでタスクのリードタイムを削減することに関して集中して話し合うことができるようになりました。そのため振り返りで出てくるTryも現実的に実施しやすいものが増え、継続的に意義のあるアクションを取る流れは作られ始めています。例えば、カンバンのボードとしてタスクの歩留まり箇所を可視化したことにより、スループット向上のためにはチームのレビューの速度に問題があるという仮説が出て、各メンバーのレビューの反応速度やレビュアーのアサイン方法などについて改善を試みるなどのアクションなどがありました。
チームでこなすタスクの内容の理解度をメンバー間で平準化しようとする取り組みは、多少の進歩はありつつもまだ改善の余地があるような状態です。以前よりはタスクについて情報を共有し議論する時間が増え、既存メンバー間でのヘルプも行われやすい状況になったものの、特に新規ジョインしたメンバーに取ってはコンテクストが複雑でタスク内容が分かり難いような状態が依然と続いています。こちらについては来年以降チームで引き続き改善したいと感じています。。。
*1:スクラムの文脈での「リファインメント」とは違い、カンバンに移行してからは、単純にタスクについて話し合って理解を深める場程度の意味でこの語を使っています
