エンジニアチームのWeeklyの働き方

こんにちは。ミクステンドエンジニアのロッチです。
今回は、TimeRexエンジニアチーム（以下、「チーム」と称する）で実践している 週次スプリントの回し方、Story Point と Planning Poker の運用、そして サポート対応の仕組み について紹介します。

この記事の目的は次になります。

• チームの開発プロセスや雰囲気を知ってもらう

なぜ「Story Point」と「Planning Poker」を使うのか

私たちのチームでは、タスクの見積もりに Story Point を使い、見積もり手法として Planning Poker を採用しています。

狙いはシンプルで、

• 作業時間の“正確な予測”よりもタスク同士の相対的な大きさを揃えること
• チーム内で認識のズレを早期に可視化すること

に価値を置いています。

Planning Pokerの進め方

進め方は、いわゆる一般的な Planning Poker に近い形です。

1. 事前に、未見積もりのタスクをバックログから列挙しておく
2. その中からチケットを1つずつ取り上げ、簡単に内容を確認
3. 各メンバーが心の中で Story Point を決める
4. 同時にカードを出す
5. Story Pointに大きな偏りがない場合 → 平均値で決定
6. Story Pointに大きな偏りがある場合 → 数分議論

ここで大事にしているのは、
見積もりはあくまで概算レベルという点です。
プロダクトマネージャーがロードマップの優先順位付けを行うために必要な、判断材料としての見積もりを提供します

Planning Pokerで扱うタスクの考え方

本来、スプリントに含めるタスクは「スプリント終了後にリリースするもの」を前提にプランニングするのが一般的だと思います。
ただし、私たちのチームでは、すでにリリース予定がある程度決まっている運用になっているため、その前提にはしていません。

その代わりに、

• すでにリリースが決まっているタスク
• 優先度が高く、近いうちに着手が必要なタスク

を中心に Planning Poker を実施しています。

また、その機能や領域に詳しいエンジニアが限られている場合は、その担当エンジニアだけで見積もりを行うケースもあります。

無理に全員で見積もることよりも、「実装イメージを現実的に持てる人の見積もり」を優先する、という判断です。

タスクの粒度に関する運用

あまりに大きなタスクは、そのままスプリントに載せない運用としています。具体的には、以下の運用です。

• Jira 上で Epic として作成する
  • その下に、実行可能な粒度の子タスクを列挙する

こうすることで、

• 見積もりがしやすくなる
• 進捗が追いやすくなる
• レビューやアサインの単位が現実的になる

といった効果を狙っています。

週次スプリントのスケジュール

私たちのチームは、スプリントを1週間で回しています。
月曜日に今週のスプリントのアサインまでを決定し、残りの曜日で割り当てられたタスクを消化していきます。

月曜 11:00〜11:30：Planning Poker

• バックログにある未見積もりタスクを中心に Story Point を付与
• 新しく出てきたタスクや、粒度が怪しいタスクを整理

月曜 12:00〜12:30：スプリント確認MTG

• Story Point を見ながら、今週のスプリントに入れるチケットを決定

各エンジニアの稼働状況や役割を考慮してアサインします

ここで意識しているルールは次の通りです。

Story Point が未確定のチケットは、原則スプリントに入れない
ただし、緊急性の高い割り込みタスクは例外とします

各エンジニアには、あらかじめ一定のバッファを確保しておく
コードレビュー、MTG、サポート対応などを吸収するための余白です
たとえばフル稼働のメンバーでも、「週あたり最大◯ptまで」といった目安を設けています
「毎週ギリギリまで詰め込まない」ことを、意図的に運用に組み込んでいます。

月曜 14:00〜14:30：エンジニアMTG

• スプリントタスクのアサインの共有
• 共有事項・相談事項があればそこで解消

このMTGは、
各メンバーに今週アサインするタスクを共有し、問題なければそのままスプリントを開始するための場、という位置づけです。

月曜 14:30〜：スプリント開始

サポート対応の運用

開発と並行して、サポートチームからの調査依頼にも対応しています。

サポート対応とは

1. サポートチャンネルに、サポートチームから調査依頼が届く
2. エンジニアが内容を確認し、調査・回答する

という流れです

曜日ごとの担当制

平日は曜日ごとに担当を決めておき、その人が一次対応を行います。

1. 担当者がメッセージにリアクションして対応開始を明示
2. 内容を見て、適任のエンジニアがいればスレッドで依頼
   自分が適任だと思えば、そのまま引き取って対応してもOK
3. もし他のタスクが優先で難しければ、別のエンジニアに依頼
4. 担当者が不在の場合は、対応できるエンジニアがリアクションして引き取る
5. 調査完了後、サポートチームに結果を共有

この運用によって、

• 「誰が拾うか分からない問い合わせ」が減る
• 開発スプリントの計画に、サポート対応の負荷を織り込みやすくなる

といった効果が出ています。

この運用で得られていること

この形にしてから、チームとしては次のような変化がありました。

• 見積もりのブレが小さくなった
• タスクの粒度が揃いやすくなった
• スプリントの詰め込みすぎが減った
• 開発とサポート対応の両立がしやすくなった

完璧なプロセスではありませんが、チームの状況に合わせて調整し続けられる土台は作れていると感じています。

おわりに

プロセスは「守るもの」ではなく、「育てていくもの」だと思っています。
チームのフェーズ、人数、プロダクトの状況によって、最適解は変わり続けます。

この記事が何かしらのヒントになれば嬉しいです。