こちらの記事は カケハシ Advent Calendar 2024 の 9日目の記事になります。
こんにちは、プラットフォームドメインでエンジニアをしている石黒です🎅🎁
ついこの前いつになったら夏が終わるのかと嘆いていた気がしますが、もうすぐ今年が終わりますね。
今回は、バックエンドエンジニア目線で、私達のチームの開発フローと運用上工夫していることをご紹介します。
チーム構成は以下の通りで、エンジニアリングマネージャーがセレモニーの取りまとめをしてくれますが、主務としてのスクラムマスターはいません。
- エンジニアリングマネージャー1名
- プロダクトマネージャー2名
- デザイナー1名
- フロントエンドエンジニア1名
- バックエンドエンジニア4名
現在のスクラム
私達のチームでは長らく2週間スプリントでスクラムを回していましたが、スプリントの疾走感を増し、状況の変化にアジャイルに適応するために、今年から1週間スプリントに変更しました。
現在は以下のようなスケジュールでスクラム開発を行っています。
- 水曜日: 前スプリントのスプリントレビュー・ふりかえり・バックログリファインメント（チーム）・スプリントプランニング（チーム・エンジニア）
- 木曜日〜火曜日: スプリントに積んだPBIの消化
- 火曜日夕方: 提供価値計画の達成状況確認・定期リリース
- 毎日やっていること: スタンドアップ・ バックログリファインメント（エンジニア）
スプリントレビューやふりかえり、バックログリファインメントはチーム全員で行っていますが、プランニングとポイントの見積もりはエンジニアだけで進めています。
スプリントごとに担当者を立て、開発を円滑に進める
エンジニア主体でプランニングや日々の進捗確認を行うにあたり、議論を円滑に行うために輪番制でファシリテーターを置いています。
ファシリテーターがスプリントの担当者としてプランニングを回したり、着手するPBI（プロダクトバックログアイテム）の決定を行っています。
問い合わせなどの1次受けも基本的にはこのスプリント担当者が担うため、全員が満遍なく運用業務を経験することができるのも強みです。
とはいえ全ての問い合わせやファシリテーションをスプリント担当者が請け負うと負荷が高くなりすぎてしまうので、状況に応じてルーレットで対応する人を決めたりするなど負荷分散の工夫もしています。
プランニングでPBIを詳細化し、時間の見積もりを行う
成熟したスクラムチームは当たり前にやっていることかもしれませんが、計画を立てやすくするためにPBIの詳細化を行っています。
スプリント始まりのプランニングの際にはプロダクトマネージャーと共にそのスプリントで実施するPBIを決定し、後半はエンジニアだけで、実際に行う作業をサブタスク化して各サブタスクにどの程度費やすか、時間まで見積もります。
その後、メンバーの1週間の稼働状況や社内イベントなどと照らし合わせて実際に使える総合の時間を算出し、見積もった時間が実働時間を超えていないか、少なすぎないか判断してこのスプリントで実施するPBIを確定させます。
時間の見積もりまで行うためプランニングまでにしっかりリファインメントをしておくのが重要で、あらかじめチーム全体で行うバックログリファインメントでPBIの詳しい内容や受け入れ条件をすり合わせしておき、エンジニアだけで日々行うバックログリファインメントでポイントを見積もりプランニングに備えています。
以下はとあるPBIを詳細化しサブタスクに落とし込んだものですが、テストやレビューなど実装以外のタスクもサブタスク化し、かつこれら全てに初期見積もり時間を設定しています。
提供価値計画を明記しプロダクトマネージャーとのコミュニケーションの齟齬をなくす
プロダクトマネージャーとはチームでのプランニングの際に1週間で実施するPBIをすり合わせており、これらはJiraで管理しています。
複数案件を並行して進めなければならないというチーム事情もあり、スプリントの提供価値計画を設定することでプロダクトマネージャーとエンジニアの間で期待値のズレが発生するのを防ぎ、さらにこれを一覧化することで着手しているタスクに漏れがないことを確認できるよう工夫しています。
プロダクトマネージャーにはスプリントの始まりに期待値を出してもらい、エンジニアがプランニングを行っていく中でプロダクトマネージャーの提示した期待値を達成するための計画を記載することで、「何をどこまで」が明確になってスプリントレビューの発表もわかりやすくなりました。
アナログな方式を取っていますが、Jiraでは管理していない細々したタスクの取りこぼしを防ぐのに便利です。
また、この提供価値計画は毎日のスタンドアップでチーム全員で確認しているため、途中で差し込みがあったり想定外の事態が発生したときに計画のズレがすぐに把握できるようになるメリットもあります。
モブ・ペアプログラミングによる開発
実際の開発には、モブ・ペアプログラミングを取り入れています。
当初はモブプログラミングだけで進めていましたが、徐々にモブプログラミングや案件の内容にも慣れてきて、全員が知見があるタスクに関してはペアに分かれてペアプログラミングすることも増えました。
全員で行うものとペアに分かれて行うものを使い分けするようになってから、さらに開発効率が上がったように感じています。
具体的な方法ですが、私達のチームはGatherによるバーチャルオフィスを活用しており、各メンバーのデスクと大きさの異なるフリースペースが用意されているため、ほとんどの時間はフリースペースに集まって開発しています。
さらにモブ・ペアプログラミング用のFigJamを用意し、ルーレットを回してメインで画面を共有して手を動かす人を決め、20分〜25分交代でどんどん回します。 FigJamは手軽にルーレットを用意できるのと、タイマーがあり少し実装の整理をしたいときにすぐ話せる場所としても使えるのでモブ・ペアプログラミングにとてもオススメです。BGMも流せるので、気分転換もできます。
実装は、Visual Studio CodeのLiveShare機能を使い修正するコードを複数人で同時作業できるようにしています。
極論を言えば4人で同じワークスペースに入り同時に実装していくことも可能ですが、できる限りメインで実装する人以外は操作せず、あくまでもサポートに徹するように心がけています。
人の指示で実装するのではなく考えながら手を動かすことでロジックの理解が深まりますし、見ている側も自分以外の人が開発している様子から学ぶことができるのはもちろん、コードレビューも不要になります。
半年間続けてみて、どう変わった？
このようにエンジニア主体で日々の開発を回すようになり半年以上が経過しました。
この運用についてメンバーにアンケートを取ってみたところ、良いところも悪いところもさまざまな意見が出ました。
モブ・ペアプログラミングのおかげで、「隣の人がなにやっているかが分からない」ということがなくなった
全員が良くなったと感じているのが、モブ・ペアプログラミングを行うことで全員で同じPBIに取り組むため、同じ知識を持った状態を維持できること、またその場でレビューを貰えるのでプルリクエストを作成してレビューを待つ時間が減らせるというメリットです。
さらに、実装以外の面でも他の人が使っているツールを知って業務が効率化できたり、ショートカットやコマンドを教えてもらったりと細かいスキルも分け合えるのが気に入っているとの声も上がりました。
モブ・ペアプログラミングをやってみて初めて気づいた点は、複数人で作業を実施することで属人性が排除できるだけでなく、この作業は〇〇さんがいつもやってくれている、この作業はいつも自分がやる、という暗黙的な作業の偏りがなくなったことです。
バックログの上から着手しなければならないというルールにより、苦手な種類の作業やあまり知見がない領域のタスクもやらなければならないという状態になります。
ペアやモブでこの手のタスクを行うことで、苦手意識がなくなったり、新しい知見を得たりとポジティブな変化が生まれました。
一方で、モブ・ペアプログラミングでの開発への課題感も挙がりました。
前述のように常にビデオ通話で繋ぎながらモブ・ペアプログラミングを行っているため、見られながらの作業が負担に感じたり、休憩も全員同じタイミングで同じだけ取るので自分のペースで開発することができないというデメリットがあります。（もちろん、都合による中抜けやお休みは普通に取っています！）
また、定型的な業務なども現在はモブ・ペアプログラミングで実施していますが、複数人での作業が非効率に感じることもあります。
こちらに関しては、今後モブ・ペアプログラミングで実施するタスクと個人で実施するタスクの基準を決め、最もやりやすい方法を模索していきたいと考えています。
テスト駆動開発になった
プランニングの際にPBIを詳細化する運用にしたことで、漏れがちなテストケースの作成やドキュメントの作成が可視化されるため、PBIが完了しているときにはテストが実施され、必要なドキュメントが揃っている状態が標準になりました。
そして、テスト駆動開発がより活発になりました。
実装時に単体テストを先に書き、テストが成功するように実装していく方式は、モブ・ペアプログラミングのように複数人で作業する場合、「どこをどのように変更すればよいか」が分かりやすくとても有用でした。
これに加えて取り組んだことは、PBIのサブタスクの先頭にテストケースの作成を置く運用です。
テストケースの作成から取り掛かることで、仕様の理解を深めたり不足していそうな要件に気づけたりと良いことづくめでした。
実際に、あるプロジェクトでPBIごとにシナリオテストをこまめに実施した結果、リリース後も致命的なバグは1件も出ませんでした。
チームで価値提供する体制を整えることができた
現在の開発フローはチーム開発に最適化されており、チーム内の知識やスキルの差を埋め、チーム全体で価値提供していく前提になっています。
反転して、個人で成果を上げていきたい志向が強い人には向かないのではないかという意見も出ました。
この点に関してはカケハシのバリューに照らし合わせるとチーム全体で価値提供することに重きを置くメンバーが多いこともあり、現在のところ問題になったことはありません。
プランニングを丁寧に行うことの大切さを知った
エンジニア目線の考えだと、とにかく早く開発に入りたい！という気持ちになってしまいがちです。
ポイント投票だけでなくサブタスクに費やす時間まで詳細に見積もる方式を採用したことで、プランニングに掛ける時間が長く掛かるようになってしまったのですが、1つのPBIに対して何をやらなければならないのか、どういう方針で進めていくか、どれくらいの時間をかけるかをプランニングの段階でエンジニアの中ですり合わせておくことで、着手するときに考慮漏れに気づいたり、進め方の認識の相違が判明するような事故がほとんどなくなりました。
今抱えている課題は、プランニングをタイムボックスに収められないことがしばしば発生してしまうことです。
原因を探ると、リファインメントが万全でなくプランニングの時間にリファインメントをしてしまうため、結果的に予定していた時間を超えてしまう事態が発生していました。
タイムボックスを超えてしまうからプランニングを簡易化するのではなく、プランニングを予定通り行うための準備を怠らないように改善していこうと思っています。
まとめ
私達のチームで取り入れている開発フローとスプリントを快適に過ごすための工夫を紹介しました。
1週間スプリントでしっかりと計画を立て、エンジニアが提供価値計画を決定し、モブ・ペアプログラミングで開発を進める方式です。
正直人を選ぶ部分もあるのですが、現在のところは心地よく開発ができており、安定した品質で価値提供することができています。
一方で、コンフォートゾーンに入ってきていてスピード感の意識が不足している、という課題も抱えており、まだまだ改善の余地があるため伸びしろに期待大です😉
今回の記事が何かの参考になれば幸いです。良いお年をお過ごしくださいませ〜✨🎄🐍
