はじめに
こんにちは、Assuredでエンジニアをしている伊藤、内山と、QAエンジニアの日下です。
Assuredでは、職能に関係なく「ビジネスや事業を一緒に作っていく」という考えを大切にしています。エンジニアも事業成長にコミットするため、少人数のチームでスピード感を重視し、各メンバーが大きな裁量を持って開発を進めてきました。
事業の成長とともエンジニアメンバーが増え、それに伴うチーム分割などのエンジニアリング組織の変更を行ってきました。
私たちのチームは大半が入社間もないメンバーで構成されており、これまでの「少人数のチームでスピード感を重視した開発」では許容してきた課題が顕在化してきました。そして、これまでと同じやり方を続けてしまった場合、それらの課題がより大きくなってしまうことが予想されました。
本記事では、私たちの課題への向き合い方とそれらを解決するための開発フローの改善についてご紹介します。
私たちが直面していた3つの大きな課題
チームが発足した当初、私たちは主に3つの大きな課題を抱えていました。
課題1：ハイコンテキストな開発スタイル
これまでのAssuredの開発は、1人のエンジニアが特定のテーマ(施策やマイルストーン)に責任を持ち開発を進めてきました。そのためPBI（プロダクトバックログアイテム）の抽象度が高い状態でも、各エンジニアが適切に仕様を検討しながら実装することができていました。スピード感がある一方でハイコンテキストな状態でありました。
特に、PBIの受け入れ基準が明確に記載されていない場合が多くありました。それによって、新規メンバーがPBIを確認した時に開発内容が分かりづらい、QAエンジニアが何を確認すればよいか分かりづらいことが課題でした。
課題2：ドメイン知識の属人化
1つ目の課題で挙げた、「1人のエンジニアが特定のテーマに責任を持つ開発スタイル」であったため、そのテーマのドメイン知識や実装が特定のエンジニアに属人化してしまう状態でした。ドメインの共有に関する仕組みがしっかり作られていたわけではないため、属人性を解消していくことが課題でした。
課題3：チームのケイパビリティが不明確
新しいチームだったため、自分たちがスプリント内でどれくらいの開発を終わらせることができるのか、ケイパビリティが見えませんでした。これにより、精度の高い開発計画を立てることが困難でした。
私たちが改善で大切にしたこと
課題は多かったのですが、私たちは一度にすべてを解決しようとはしませんでした。プロセスを急に大きく変えると、チームに混乱を招き、形骸化してしまう恐れがあるからです。
そこで、私たちは以下の3つのことを大切にしながら、既存のプロセスの課題を一つずつ改善していくことにしました。
- ビッグバンな変更はしない: 既存のやり方を尊重し、課題が顕在化したものから着実に改善する。
- チームで目的意識を共有する: トップダウンではなく、チームで課題を発見し、なぜ改善するのかを全員で考える。
- 納得感を持って進める: 常にチームで対話し、全員が納得した上で新しいプロセスを導入する。
取り組んだ改善策
ここからは、私たちが具体的に取り組んだ改善策をご紹介します。
1. ふりかえりの定着
まず最初に取り組んだのが、ふりかえりの定着です。どんな小さな課題も見逃さず、チームで改善サイクルを回し続ける土台が必要だと考えました。
- 手法: KPT（Keep / Problem / Try）
- 工夫した点:
定着させることを目的に多くのメンバーが経験のあるKPTを採用しました。このふりかえりを通して、ふりかえりのサイクルを作ることができたとともに、「受け入れ基準が不明確」「次に何に着手すればいいか分かりづらい」といった具体的な課題がチームの共通認識となり、次の改善アクションへと繋がっていきました。
2. 「受け入れ基準」の設定
ふりかえりで挙がった課題を受け、PBIごとに「受け入れ基準」を明記することをルールにしました。
- 目的: 機能の完成イメージをチーム全員で揃えること。
- やり方:
- PBIのリファインメント（後述）の場で、受け入れ基準をチームで合意形成します。
- 「〇〇という操作ができる」「〇〇というデータが表示される」のように、具体的な振る舞いを記述します。
- 効果:
- 実装者はゴールが明確になり、迷いなく開発を進められるようになりました。
- 実装者以外でも、受け入れ基準を見れば受け入れが可能になりました。
- 相対見積もり（後述）の際、ポイントを判断する明確な基準になりました。
3. 「Readyの定義」の明確化
受け入れ基準を定めましたが、それ以外にも「実装方針が決まっていない」「デザインがない」といった理由で、スプリントの途中で手戻りが発生することがありました。
そこで、スプリントで着手できるPBIの条件として「Readyの定義」をチームで合意しました。
【私たちのチームのReadyの定義】
- 受け入れ基準が明確になっていること
- デザインがFIXしていること
- 実装方針のイメージが湧いていること
- 1スプリントに収まる適切なサイズになっていること
- 相対見積もりが完了していること
Readyになっていないチケットは、原則としてスプリントでは着手しないルールを徹底しました。これにより、「やったけど終わらなかった」というチケットが減り、開発の確実性が向上しました。
4. カンバンの改善
次に取り組んだのは、カンバンの改善です。以前はプロダクトバックログのPBIが優先順位なく並んでおり、エンジニアとしては「次に何をやるのか見えづらい」、PdM（プロダクトマネージャー）としては「リファインメントの対象を非同期で伝えづらい」状態でした。
そこで、カンバンのステータスを”Backlog”, “Need To Refine”, “Ready”に細分化しました。
PdMが優先順位の高いPBIを“Need To Refine”に移動させることで、チームは「次にリファインメントすべきこと」を非同期で把握できるようになりました。これにより、事前準備がしやすくなり、リファインメントの質も向上しました。
5. リファインメントの整備
リファインメントは、PBIの受け入れ基準をチーム全員で認識を合わせることを一番の目的にしました。PdMがPBIの目的や背景を共有した上で、すべてのPBIに対してチーム全員で下記のことを確認しています。
- 受け入れ基準に抜け漏れがないこと
- 受け入れ基準に認識齟齬がないこと
- 「Readyの定義」を満たしていること
リファインメントに時間を要してしまうのは確かですが、チームでドメイン知識の属人化を防ぐために必要な時間だと捉えています。また、受け入れ基準について認識を揃えている効果としてコードレビューやQAの際のコミュニケーションがスムーズになっていることを実感しています。
6. 相対見積もりの導入
チームのケイパビリティが見えないという課題に対し、ストーリーポイントを用いた相対見積もりの導入とベロシティの可視化を始めました。ストーリーポイントを設定し始めた当初は、ベロシティが安定しないため、短期的に以下の観点でふりかえりを行なっています。このふりかえりを通してチームのケイパビリティの見える化とスプリント計画の精度向上につなげたいと考えいます。
- スプリント毎にベロシティが変動する要素は何であったか
- PBI毎に相対見積もりの時に考慮漏れの観点がなかったか
また、ストーリーポイントは、基本的にリファインメントの中で設定しています。PBIをReadyにする直前にメンバー全員で一斉にポイントを提示します（指でポイントの数字を作ります）。ストーリーポイントが大きく割れた場合は、受け入れ基準の認識やそのズレについて議論することにより、PBIの解像度がさらに高まるという副次的な効果もありました。
改善を続けて、もっと事業に貢献できるチームへ
大半が入社間もないメンバーで構成された私たちのチームは、一つひとつの課題と向き合い、対話を重ねることで、開発フローの改善を重ねてきました。重要なのは、完璧なプロセスを一度に目指すのではなく、チームで課題を発見し、納得感を持って一歩ずつ変化していくことだと考えています。
冒頭で記載した通り、Assuredでは職能関係なく、ビジネスや事業を一緒に作っていくという考えを大切しています。それはエンジニアも同じです。エンジニアとしてPBIに対してのHowやWhenに対して責任を持つのはもちろんですが、いわゆるフィーチャーファクトリーにならないように継続的に改善を続け、より事業に貢献できるエンジニア組織を目指していきたいと考えています。
この記事が、同じようにチームの属人性や開発フローに課題を感じている方々の参考になれば幸いです。
最後に、私たちと一緒にプロダクトづくりを共にして下さる仲間を募集しています！ 今回のブログを読んで、少しでも興味を持ってくださった方は、ぜひ採用情報をご覧ください。
