タイミーのsyam(@arus4869)です。アドベントカレンダーの初日を担当します！
2024年も残りわずか。今年中にやりたかったことの一つが、6月に参加した「アトラクタの認定スクラムマスター研修」の振り返りをまとめることです。この研修では、スクラムの理論を実践しながら学び、多くの気づきと学びを得られました。
私はスクラムマスターではありませんが、チームと共にスクラムを実践する立場です。研修を通して得た知見を、開発者目線で共有したいと思います。同じようにスクラムを学んでいる方々の参考になれば幸いです。
研修の内容と学び
6月に参加した「アトラクタの認定スクラムマスター研修」は、実践を通じてスクラムの考え方やイベントの進め方を学べる宿泊型の研修でした。
詳しい研修内容についてはネタバレを避けるためここでは触れませんが、興味がある方は公式サイトや同じ研修に参加された櫻井さんのレポートをご覧ください。
研修で印象的だった学びを3つのポイントにまとめてお伝えします。
1. バックログ管理の新しい視点
スプリント計画を模擬的に体験する中で、「バックログは優先度ではなく縦の順番で管理する」という考え方に触れました。このアプローチは非常に新鮮で、「今、一番解決したい課題」に集中する仕組みを整えられると感じました。
従来は優先度が高いものから進める方針が多かったため、割り込みや変更による並列作業が増えることが課題でした。 しかし、この研修での「縦に並べたバックログを順番に進めることで効率的に進行できる」というアプローチでは、順番に1つずつ進めることができるので、スイッチングコストが大幅に減り、1つの課題に集中しやすくなります。割り込み依頼が発生した場合も、既存のバックログに新しいタスクを適切に並べ直すだけで対応可能です。このシンプルな管理方法で、優先順位の変更にも柔軟に対応でき、チーム全員が次に進むべきタスクを迷わず把握できるようになります。
また、「バックログアイテムは具体的で詳細であるべき」という原則も再確認しました。特に、外部要因が絡むタスクや準備が整っていないタスクは「Readyではない」と判断し、進めないことが重要です。このルールを守ることで、不確実なタスクに時間を割くことなく、チーム全体の進捗を安定して保つことができるため、重要な考え方だと感じました。
2. チームの柔軟性を高める工夫
「スプリントゴールが変われば、バックログの順番も変わる可能性がある」という考え方はとても印象的でした。この仕組みによって、「チームが今何に集中すべきか」が自然と明確になり、計画そのものがチームの方向性を示すツールとして機能することが分かりました。特に、ゴールが具体的であるほど、チーム全体が一つの目標に向かって足並みを揃えやすくなる効果を実感しました。
さらに、「スプリントゴールは何を基準に決めるべきか」という議論では、明確な正解を求めるのではなく、その時点での最善を試す柔軟な姿勢が重要だと気づきました。このように、状況に応じてアプローチを調整できる点こそが、スクラムの持つ大きな強みだと感じました。
3. イベントごとの目的を見直す
スクラムイベントには、それぞれ明確な目的を持つことが重要だと学びました。
例えば、スプリントレビューでは、進捗を確認するだけで終わらせず、「次にどう進むか」を全員で議論する場にすることの大切さを実感しました。このように未来志向の議論を行うことで、チーム全体が次の課題に向けた共通認識を持つことができます。
さらに、模擬スプリントレビューでは、デモにサンプルデータではなくリアルなデータを使うことの効果を学びました。実際に使うデータを用いることで、ユーザー視点での具体的なフィードバックを得やすくなり、プロダクトの質を高める大きな助けになると感じました。
また、デイリースクラムでは「早期に問題の芽を摘む」という考え方に触れました。短時間であっても、全員で現状を共有することで、予期せぬ問題への迅速な対応力が身につくことを実感しました。
研修を経ての現在地
研修後、すぐに全てが変わったわけではありませんが、少しずつ改善を進めています。最近では、チーム内での見積もり方法を見直しました。
以前は「Tシャツサイズ」を使った見積もりを行っていましたが、「Mサイズが曖昧すぎる」という課題に直面していました。小さなMサイズも大きなMサイズも同じ扱いとなり、多くのタスクがMサイズに分類され、タスクの規模感がぼやけてしまうことが問題でした。
この課題を解決するため、現在は「フィボナッチ数列を使ったストーリーポイント」に切り替え、それぞれのポイントに具体的な基準を設ける方法を採用しています。これにより、リファイメントの際に基準を参照しやすくなり、チーム全体で見積もりの共通認識を持つことができるようになりました。
| ストーリーポイント | チームにとって必要な日数 | 作業例 | 基準となるPBI |
|---|---|---|---|
| 1 | 0.5日以内 | 簡単なfunction追加、エラーハンドリングなど | - |
| 2 | 1日程度 | クラスの作成、簡単なadmin機能の作成など。簡単な既存コードのリファクタリング | - |
| 3 | 2日程度 | 簡単なAPI作成、既存コードのリファクタリング、テストコード作成、デザインの作成、バックエンドの軽微な機能追加など。 | - |
| 5 | 3〜4日程度 | フロントとバックエンドが絡んだ単一機能の開発 | - |
| 8 | 5日程度 | フロントとバックエンドが絡んだ複数機能を持つ1画面程度の機能開発 | - |
| 13 | 10日以上（上限なし）※分割しなければならない | 複数のプラットフォームが絡んだ2画面以上の機能開発、インフラの構築を含む新規アーキテクチャ構築など | - |
まだストーリーポイントで見積もりする手法を実験中のため、これからの振り返りや次のスプリント計画にどのように役立つかを検証し、改善していきたいと考えています。新しい方法を試す中で、チーム全体の共通理解を深めながら、少しずつ改善を重ねています。
締めくくり
スクラムを実践していく中で得られた一番の気づきは、「小さな改善の積み重ねが、チーム全体の成長に繋がる」ということです。今回受けた「アトラクタの認定スクラムマスター研修」は、理論を学ぶだけでなく、実際に手を動かしながら多くの気づきを得られる貴重な機会となりました。
ストーリーポイントの導入や見積もり基準の設定といった取り組みが、これからどのような成果に繋がるのか、さらに試行錯誤を続けていきたいと考えています！
この記事は自分自身にとっての振り返りの一環となりました。 スクラムを学び始めた方や、すでに実践している方の参考になれば幸いです！
それでは、みんなでより良いチーム作りを目指してがんばりましょう！
