d-haru’s blog

株式会社はてなのdeveloperです

開発チーム内で試しにバディ制を導入したときの効果とふりかえり

今月引越し予定なのに手続きが終わっていなくてバタバタしている中の執筆中の id:d-haru でございます。ごきげんよう

今日は最近のお仕事の話しです。

今回スクラム開発をしているチーム内にバディ制を導入して3~4ヶ月ぐらいが経過してそれなりの結果を得られたので良い機会なので振り返っておこうと思います。

バディ制とは

バディ制は文字通りバディを組んで仕事をすることです。

今回は開発チーム内での導入なので、最小でエンジニア2名のチーム(バディ)でタスクにあたるような形をとっていました。

私のチームでは当時7名のメンバーがいたので3チームで2名, 2名, 3名で実施しました。

なぜバディ制を導入した?

開発チームの当時の様子としては、メンバーの入れ替わりなどもあったためか直近2~3スプリントでは2~3タスクが終わりきらないなど、スプリントゴールが達成できず、ベロシティが安定しないという状況でした。

ここの原因として考えられるものとしては、

  • 事前に実装方針をすり合わせられていないことがある
    • 全てではないが、そういうケースが有る
    • メンバーが実装方針について悩む時間が長い
    • 一部の Pull Request では手戻りが多い
  • レビュー待ち時間が長い
    • コンテキストを理解するのに時間がかかる
    • そもそもの実装方針の筋が悪い&この時点で規模が大きいとコミュニケーションコストも掛かる
    • レビューそのものに着手するのがそもそも遅い

上記の課題や、そもそもフロー効率を上げていきたいよねーといった会話がふりかえりでもでていました。

こうした背景から、バディ制を導入を本格的に検討しはじめました。

バディ制導入の流れ

当初は主に下記を「狙い」としてバディ制を試してみることにしました。

  • 実装方針をスムーズに相談されること
  • レビューの負担が減って待ち時間が減ること

また、はてなの他の開発チームではバディ制を実践しているチームもいくつかあったので、これらのチームの様子などもヒアリングさせてもらったりドキュメントを覗きにいったりして参考にしていました。

初回実施の様子

結果的にはスプリント初日の午後の時間をほぼ全て使って、説明&モブプロを実施しました。

まずは、エンジニアに上記のような導入する目的や狙いを説明したうえで、実際に次のスプリントから実践しようという会話をしました。

また、最初はそもそも実装方針の相談〜ペアプロまでの流れの目線を揃えたいと思い、半日ずっと1つのタスクをエンジニア全員でモブプロをして流れを確認しました。

これによって、メンバー全員が最初に実装方針を相談することの効果を肌で体感しつつ、進め方をインプットすることができてスムーズな立ち上げに寄与したと思います。

ふりかえりの様子

その後、スプリント(2週間)ごとにふりかえりも実施していました。

初回はいくつか改善案もでたので修正しつつ、(ちょっとしたことでも)相談がしやすい、話しかけやすくなったなど、コミュニケーションがしやすくなっている様子が観測できていました。

また、スプリントタスク自体も難なく捌けており、追加で積むことができそうという声も上がるようになりました。

実践した結果とふりかえり

バディ制導入前と比べて、バディ制導入後の3ヶ月での平均ベロシティは約140%という結果になりました。

導入後に実施したふりかえりで会話をまとめると下記のようなことが考えられました。

開発に関する意思決定の速度の改善

元々手戻りの低減を狙っていたところでしたが、実際にふりかえりをしていみるとそれ以上に「相談相手が決まっている」ことによるコミュニケーションの改善関連の話題が多かったです。

たしかに、従来は7名チームでそれぞれバラバラに作業をしている状態だったので、相談するのにお互い躊躇ってしまったり、悪い意味で定例会(デイリースクラムなど)を待ってしまうこともありました。

バディになったことで、開発に関する意思決定の速度が向上し、実際にデリバリーする速度アップにも大きく貢献していると考えられます。

また、事前に相談してから進めることに関しては、メンバーからも「どう考えてもやった方が良い」と声が上がるほどだったので、新しいチームの「型」になったことを確信しました。

並列度を減らしてチームに合ったタスクの最適化

スプリントの並列度が多くなりすぎないように調整をしました。

バディ制になるタイミングと同じぐらいのときに、実施するスプリントタスクの種類(ユーザーストーリー)があまり複数並列にならないようにスプリントプランニングで調整するようにしました。

バディになったところでタスクの並列度が以前高いままだと、結局分担作業になりバディの良さが最大限活かせない可能性があったためです。

このあたりは、プロダクトオーナーとチームのTL(テックリード)の協力してもらいました。

まとめ

結果としては、私の所属するチームでは見事にハマり成果にもつながりました。

ただ、今回はチームの課題にうまくマッチして結果としてベロシティの安定化&改善にもつながったんだと思っております。

バディ制を導入すればどんな組織でも効果がでるという訳ではないことには気をつけておきたいところです。

まだまだ伸びしろもあると思っているので引き続きチームのパフォーマンスを最大限活かせるような形をこれからも探っていきたいと思います。

今日はこんなところで!!