はじめに
こちらは バイセルテクノロジーズ Advent Calendar 2023 の 2 日目の記事です。 前日の記事は早瀬さんの「開発効率を上げるためのモダンなフロントエンド構成」でした。
こんにちは！株式会社バイセルテクノロジーズのテクノロジー戦略本部開発 2 部でバックエンドのテックリードをしています藤澤です。 現在私の所属しているチームではアジャイル開発を取り入れて開発に取り組んています。その中でフロー効率を重視して価値提供のスピードを上げる取り組みをしていたのですが、思わず開発メンバーのエンゲージメントが低下していまうという問題が起きました。今回はその問題の経緯とそれをどのように改善したかについてまとめたいと思います。
元々チームが目指していた姿
元々チームではスクラムをプロジェクト管理手法として採用し、フロー効率を重視した上で、ユーザへの価値提供の頻度やスピードを重視した開発に取り組んでいました。具体的には以下の図のように複数の機能を並行して開発するのではなく、重要度の高い機能から順に直列に開発を行いリリースしていくというフローをとっていまいた。
狙いとしては価値提供のリードタイムを短くすることによって、軌道修正をしやすくなり、ユーザーへの価値の最大化ができると考えていたからです。 また、同時に複数人で同じ機能を作ることによる属人性の排除や、それによる開発メンバーのエンゲージメント向上も期待していました。
実践していたこととその成果
特に力を入れていたポイントは、バックログリファインメントを全員で行い仕様や設計の共通認識の醸成を行うということでした。また、1 つのストーリーを可能な限りタスク分解し、なるべく全員で開発していく進め方を取りました。これらの効果として、狙い通り属人性を排除でき、どの機能でも誰でも開発できるという理想に近い状態にチームは変貌を遂げました。また、高頻度で機能がリリースできることにより、スプリントレビューでのフィードバックも多く受けることができユーザーへ提供する価値も高まっていると思える状態でした。
当時の具体的な取り組みについては以下の記事でも紹介して頂きましたので、よかったら読んでみてください。
フロー効率を重視して起きた問題
一時は理想と思えるチーム状態になったかと思われたのですが、開発を進めるうちに徐々に以下のような問題が浮き彫りになってきました。
機能が完成し切らない時がある
私たちのチームでは複数人で 1 つのストーリーの機能を開発していたため、ストーリー内のサブタスクを誰が担当するかわからないままスプリント終了を迎えてしまうことがありました。また、ストーリー内のサブタスクの進捗に関しては担当者それぞれで把握していたため、ストーリー全体としての進捗が追いづらいという問題も発生し、スプリントの期限までに機能が完成しないということも起きてしまいました。
個人の成長実感がない
私たちのチームでは、仕様の詳細化や設計フェーズをチーム全員で行なっていました。スキルや経験がバラバラということもあり、メンバーによって意見を多くいう人や意見が採用されやすい人の差が出てしまっていました。それによって、いつも誰かが設計した機能をただ開発するだけで、自分の成長が感じられないという意見が若手チームメンバーから特に多く出てしまっていました。
自身の重要性が薄く感じられる
どの機能でも誰でも開発できるというのはチームとしては理想の状態です。しかし、個人としては自分じゃなくても開発ができるということは、自分のチームにおける重要性が感じられないという意見が出ていました。 また、自分がこのチームにおいて何をやったか、どのような成果を上げたか、ということについて言語化できない。もっと大きな枠で仕事を任せてほしい。という様な意見も多く出てしまいました。 結果として、実際にチームを離れたいという人も出るほど開発メンバーのエンゲージメントが低下する事態となってしまったのです。また、開発が逼迫していた時期ということもあって、振り返り改善する時間もこれまでなかなか取れていませんでした。
エンゲージメントを高めるための改善ポイント
上記の様な状態を改善するために、チームでは長い時間をとって振り返りと改善について話し合う時間を取りました。 基本方針として、フロー効率を重視し価値提供のスピードを上げるということは変えないほうがいいというチームの共通認識はありました。 なので、その中で「どうすれば開発メンバーそれぞれが責任を持って開発し成長した上で、チーム内における自身の成果を感じられる様にするか」、という難題への解決を話し合いました。 そして、定性的な意見や定量的な生産性指標を集めて相談した結果、以下の様な改善施策を実施することになりました。
① ストーリーリーダー制度
上記の各問題に対して統合的に対応する方法として、各ストーリーに対して 1 人のリーダーを置くことにしました。 リーダーの行うことは以下の 3 つです。
- 担当ストーリーの仕様や設計のたたき台を作成し、バックログリファインメントを主導する
- ストーリーの機能実装時の主担当となり開発も行う
- ストーリーを期限内に開発完了するための全責任を持ち進捗を管理する
開発の進め方のイメージは以下の様になります。
ストーリーリーダーは開発メンバーの中でローテーションし、ストーリーの優先度順に割り振られる様にし、特定のメンバーに責任が集中しない様にしました。また、バックログリファインメントや開発そのものは以前通り全員で行う状態を維持し、価値提供のスピードや属人性の排除に対して影響が出ないようにもしました。
こちらは現在も実施中の施策ですが、開発メンバーからは「以前よりも自分の成長実感が得られている」や「プロジェクト内で自分が何をやったのかについて自信を持っていえるようになった」など良い感想も聞かれるようになり、実施して良かったと感じています。一方で、ストーリーリーダーを務めるメンバー間のドメイン知識や開発経験量の差により、以前に比べて成果物の質にばらつきが出てくることもありました。
② ブラザー制度
上記のようにメンバーの満足度は高まりましたが、リファインメント後の実装方針や機能開発後の成果物の質が少し落ちたという実感も出てくることになったため、それに対しても手を打つことになりました。この問題は特に、チーム歴の浅いメンバーの仕様の詳細化の際に起きることが多くありました。そのため、それを解決するための方法としてブラザー制度という施策にトライすることにしました。 チーム歴の長いメンバーと浅いメンバーを 2 人 1 組のブラザーとし、仕様や設計の策定を補助します。相手がリーダーとなっているストーリーに対しても副担当者として責任を同じく持つというルールにすることで、ストーリーの完了に対してコミットできるようにしました。
こちらも実施した結果、スプリントレトロスペクティブにて定性的な意見として良いものを得ることができました。
③ スクラム行動規範
元々スクラムを導入して取り組むにあたって、スクラムマスター的なメンバーが 1 人いました。「ベロシティの安定」や「ユーザーへの価値提供」といった開発を進めるにあたっての考え方や行動の選択についてそのメンバーが決めることが多くありました。 ストーリーリーダー制度に移行するにあたって、そのような視点や行動のあり方について、メンバー全員が同じく共通認識を持ってリーダーを務めることができるようにチーム内での行動規範を策定しました。 これを策定するにあたっては、すでにバイセルが会社として定義しているバリューである「プロフェッショナル」「クリエイティブ」「ホスピタリティ」をブレイクダウンしつつ自分たちのチームとしてのあり方の理想を開発メンバー全員の合意の上で決めるようにしました。
結果どうなったのか
以上のように課題が発見されてから、チームとして様々な試作で改善を試みました。定性的に良い意見が出ている一方で、上記図のように現在のところチームとしてのベロシティは大きく崩れることもなかったことが非常に良かったと感じています。 ただし本当にエンゲージメントが向上しているかについては、すぐに結論が出るものだとは考えていません。これからもチームとして改善を続け、良いチーム状態を維持しつつユーザーへの価値提供を続けられることを目指して行きたいと思います。この改善のゆく末についてはまた機会があれば記事にできればと思いますので、乞うご期待ください。
まとめ
いかがでしたでしょうか。 今回はアジャイル開発に取り組むチームにおいて、フロー効率を重視しつつ、エンゲージメントを高めるために挑戦したことを紹介しました。 この記事がチームのエンゲージメント低下について悩んでいる方に、少しでも参考になれば幸いです。
最後に、バイセルではエンジニアを募集しています。少しでも気になった方はぜひご応募お待ちしています。 明日のバイセルテクノロジーズ Advent Calendar 2023 は尾沼さんの「サービス運用の負担軽減に繋がった、Playwrightの紹介」です、そちらもぜひ併せて読んでみてください！
