こんにちは、GxPの石村です。
この記事はグロースエクスパートナーズ Advent Calendar 2020の2日目です。

今回は、2020年6月の下旬から3か月ほどで起こった私のチームの変化についてお伝えしたいと思います。

結論からお伝えすると、2つ以上のプロダクトを9名ほどのメンバーで開発していたチームを、1プロダクト1チームに組みなおしたところ、以下のような効果がありました。

プロダクトへの理解が深まり、品質も向上してきた
プランニングの精度が上がり、納期前のドタバタが大きく減少
チームメンバーの主体性が増し、自己組織化され始めた

少し長くなりますが、そんな変化の背景、何をしたのか、どんな変化があったのかについてお伝えします。

1チーム複数プロダクト時代の問題点

私がこのチームに参画したのは2017年ごろだったと思います。
長くお付き合いのある医療系の顧客から、新規プロダクトの開発を依頼されていました。
当時は技術検証を兼ねたプロトタイプを作成しながら、プロダクトのファーストリリースを目指しており、開発メンバーは3名くらいだったような気がします。

そこからプロダクトの成長や追加、規模の拡大、メンバーの入れ替わり、保守フェーズにあるプロダクトの引き継ぎなどがあり、プロダクトは4つ（開発継続しているもの2つ＋保守2つ）、メンバーは9名になっていました。

スクラムを導入しようとした時代もあったのですが、以下の要因でウォーターフォール（ですらない混沌？）状態になっていました。

プロダクト同士でリズムが揃わず、納期も案件規模もバラバラ
開発するプロダクトが複数あるため、あるプロダクトの課題を担当している間に別のプロダクトには知らない機能が増えていて追いきれない
他案件と兼務のメンバーが多く1スプリントで消化できる工数が安定しない
メンバーが入れ替わりすぎて経験値が溜まらない
メンバー同士のスキル差が大きい（能力・経験とも）
ステークホルダーが多く、各種調整の難易度が高い

そんな状態ですので、開発した機能が増えるたびに属人化している箇所が増え、他の人が開発した機能・プロダクトそのものに対する理解度もなかなか上がりませんでした。その結果、メンバー自身も自分の作業以外への関心が薄れてしまっていたように思います。チームには疲弊や諦めの空気が漂い、リリースは喜ぶものではなく疲れ果てるものでした。

変化のきっかけ

なにかひとつ大きな転機があったというよりは、パズルのピースのようにいろいろなものが重なったことで、決行できました。

現場コーチをやっている中村洋さんへの相談の積み重ね
社内の「エッセンシャルスクラム」読書会でのディスカッション
認定スクラムマスターの取得によるスクラムへの理解度の向上
SCRUM FEST Osaka 2020@onlineの懇親会での相談
私自身の役割が変化したこと
（プロジェクト責任者のサポート兼設計者→プロジェクト責任者）
メンバーから兼務者を徐々に減らし、専任者がほとんどになってきたこと
顧客側の期末を迎え、今期の計画を立てるタイミングが来たこと

何をどう変えたか

1プロダクト1チームに組みなおし

メインプロダクト2つに対して、専任チームに組みなおしました。
1プロダクト3～4名となり、夕会はチーム単位、全体共有会は2週間に1回実施するようになりました。

顧客との会話も少しずつチームメンバー自身にやってもらう範囲を増やしていっています。

リリースを定期的に行うように提案

学会などのイベントや期末など、イベントに合わせてリリーススケジュールを組んでいました。
これをプロダクトごとに定期的・一定ボリュームでのリリースに変更できるよう提案し、了承いただくことができました。

片方のプロダクトは1か月、もう片方のプロダクトは2か月ほどの定期リリースとなりました。

バックログの概念を導入

「プロダクトバックログ」「スプリントバックログ」の概念を導入し、顧客側で並べ替えを行っていただくようにしました。
「バックログ」「プロダクトオーナー」といった言葉は使っていませんが、やっていることは同じです。

たくさんの要望をいただいていたので、これらをすべてJiraでチケット化しました。
このJiraチケットを、だいたいいつ頃どの課題に対応したいか、どの時期のリリースにどれを入れたいか、どれが特に優先か、という基準で並べ替えていただくようにしました。

これをもとに直近の希望に対して、チケット単位で仕様調整やスコープの調整を行えるようになりました。
これまでは対面での月次定例会議で仕様調整することが多かったのですが、Jiraで行える範囲が増え、会議を待たずに調整できるようになりました。

得られた効果

プロダクトへの理解が深まり、品質も向上してきた

担当するプロダクトが固定化されたこと、お互い何をやっているのか理解できる範囲の人数になったことで、プロダクトへの理解が深まりました。

また、これまでは議事録の共有や私からの説明だけだったのが、顧客の生の声を聞けるようになりました。その結果、顧客が何を求めているのかということへの理解や関心も深まったように思います。

全体を把握できるようになってきたことで、認識齟齬や影響範囲の見落としなどが減っていきました。

プランニングの精度が上がり、納期前のドタバタが大きく減少

プロダクトへの理解と、定期的なリリースによる「1か月でだいたいこのぐらいできる」という経験の蓄積により、予測の精度が上がりました。
人数が減ったことで、お互いのスキルセットも把握できるようになり、誰が何をするかも開発メンバー同士でスムーズに決められるようになりました。

そのおかげで作業遅延や、タスク漏れの発覚で納期前にドタバタすることが大きく減少しました。

チームメンバーの主体性が増し、自己組織化され始めた

そういったことの相乗効果で、チームの雰囲気に少しずつ余裕ができてきました。

「ここの機能はこうしたほうがもっといいんじゃないか。」
「この作りだとこういうパターンで問題が出るんじゃないか。じゃあこうするといいかな。」
「少し手があいたのであの作業自動化しますね。」
「調査しやすいようにここのログ出力追加しましょう。」
といった発言が聞こえてくるようになりました。

これから

6月の下旬にチームを分けます！と宣言してから今日までの間に、想像以上の効果が得られました。
これからは以下のようなことをやろうとしています。

スクラムを本格的に導入

開発チームがスクラムを導入したいと思えばできる状態まで、土台は整ってきました。
今起こっている良い変化は、スクラムを理解し、導入していけば促進されるのではないかと思います。

少しずつスクラムの要素を取り入れ、理解を促進しながら、開発チームがやってみたいと思ってもらえたタイミングで実施するつもりです。
そのときには、「認定スクラムデベロッパー」の取得も是非してもらいたいと思っています。

自己組織化の促進

いまはKPTを使ってふりかえりをしているのですが、明確な問題がないとTryにつながりにくいので、自己組織化の促進がしにくいと感じています。
マンネリ化もしているので、今度から Fun/Done/Learn を使ってみることにしました。
（参考記事①、参考記事②）

以下のような効果を期待しています。

「いいね！」と成果を祝福し合う空気が生まれる
「Probrem」に書いていたようなことを「Learn」に表現しなおすことで、問題を認識することが良いことになる
「Fun」「Learn」を増やしたいという気持ちが生まれる
困ってるわけじゃないけど、もっとこうなったらいいのにな、という想いが表現できる