Septeni Japan株式会社でプロダクト開発のエンジニアをしている工藤です。
私が所属する開発チームでは、スクラム開発を実践しています。
最近、社内勉強会を通じてスクラムの基本を再学習し、私たちの取り組みを振り返る良い機会となりました。
この記事では、私たちのチームがどのようにスクラム開発を取り入れているのかを紹介します。
はじめに
「スクラム」と聞いて、何が浮かびますか？
「肩幅の広い男たちが肩を組んで向かい合っている……ラグビー？アメフト？」
そんな暑苦しい（褒め言葉）イメージが浮かぶ方も多いかもしれません。
緑色は人間の目に最も優しい波長だと言われているので、目に優しい色だそうです
スクラム開発の語源は、この肩を組む陣形から来ており、
「一致団結して1つの目標に向かう」という意味合いが込められています。
ボタン引っ張られるのであまりスーツ着て肩組みたくないですね
私たちのチームでは、SCRUM GUIDEという有名なルールガイドを参考にしながら、スクラム開発を実践しています。 私たちのチームでは、スクラム開発を通じて以下のような取り組みを行っています。
チーム構成
スクラム開発ではチームメンバーにはそれぞれ明確な役割が設けられています。
私のチームは、プロダクトオーナー1名と開発者4名の計5名でスクラム開発を進めています。
スクラムマスターがいない！？
スクラムマスターの役割を担当する人がおらず、代わりにスクラムの進行や管理は全員で引き受けています。
スクラムマスターがいない分、問題がうまくいかなかった場合は直接自分たちに返ってくるので、より強い当事者意識を持って進行しています。
お互いに責任を共有することで、より密なコミュニケーションとチームワークが生まれ、問題を解決する意識が高まります。
スプリント
私たちのチームでは、スプリントの期間を1週間に設定しています。
これにより、短期間での成果を出しやすくし、迅速なフィードバックを得ることができます。
成果物
スクラム開発の成果物にはプロダクトバックログ、スプリントバックログなどの概念があります。
私たちのチームでは、Jiraを使用して、以下の解像度で要件や作業を整理しています。
- エピック ・・・ プロダクトバックログの位置付け
- タスク ・・・ スプリントバックログの位置付け
- 背景 ・・・ タスク発生の経緯や前提情報など
- ストーリーポイント ・・・ プランニングポーカーによって決めた想定工数
- 受け入れ条件（テスト項目） ・・・ 関係者に成果を引き渡す際に満たすべき条件
- 完了条件 ・・・ 開発作業が完了したとみなすための条件
- 未完了条件 ・・・ このタスクではやらないと明示すること（曖昧さ回避）
- タスク ・・・ スプリントバックログの位置付け
エピックに分けることで、スクラムチーム外への情報開示が可能になり、プロダクト開発やその他の作業で、どのプロジェクトにどれくらいの工数を割いているのかを計算する際にも役立っています。
会議
私たちのチームでは、毎朝のデイリースクラム、毎週のスプリントプランニング、スプリントレビュー、スプリントレトロスペクティブを定期的に行っています。
スプリントレビューを始めました
私たちのチームでは、最近までスプリントレビューをやっていませんでした。
代わりにプロダクトオーナーがチーム外でステークホルダーへの報告会を行っていたのですが、その結果として、チーム内での成果や進捗が浸透しにくいという問題がありました。
そのため、現在ではこの報告会をスプリントレビューと捉え、スクラムチーム全員が参加するようになりました。
開発者目線で直接ステークホルダーの意見を聞くことで、課題への意識がより強まり、全員が共通のビジョンを持つことができるようになりました。
この取り組みを通じて、進捗がより実感として伝わるようになり、次のスプリントへのモチベーションが向上しました。
メリット
実際に私が現在のチームでスクラム開発に携わっている中で感じたメリデメは以下です。
体内時計がカレンダーと同期されてくる感覚
要件の変化に早めに対応できる
スプリントレビューごとに関係者からフィードバックを受けたり技術調査の結果を報告し合います。
チーム内で情報共有し合って方向性を話し合う為、要件の変化に早めに対応が出来ます。
スプリントが終われば一旦リフレッシュできる
長期間にわたる開発プロジェクトでは、セルフマネジメントがうまくできていないと、
「この問題はいつまでに誰に相談して、次は誰に報告しないと…」といったように、やるべきことが山積みになりがちです。
スクラムではスプリントごとに作業が区切られ、進捗や発生した問題をチーム全体で共有する定期的な会議があるため、タスクや問題が積み重なる前に対処できる環境が整っています。
これにより、ボールを継続的にたくさん抱え込む状況にはなりにくいです。
会議が事前に決まっているのでスケジュール管理しやすい
スクラムは定期的な会議の日程があらかじめ決まっており、いつ何の会議があるかが明確です。
これにより計画的にスケジュールを立てやすくなり、突発的な会議設定に追われることが減ります。
例えば「作業目処が立ったから会議を設定しよう」と思っても、ステークホルダーの予定が詰まっていて会議がうまく調整できない、といった悩みは少なくなります。
事前に予定が決まっているため、時間の調整もスムーズに行えます。
デメリット
最初はこうなりがち、最初だけ！
合流したばかりのメンバーは着いていくのがきつい
スクラム開発に合流したばかりのメンバーは、会議で話される内容やスクラムの進行方法を理解するのが難しい場合があります。
特に、スクラムの用語や進行フローに慣れていないと、発言するのが億劫になったり、内容についていけないこともあります。
また、スクラムは既存メンバーの目線で相対的にストーリーポイントをつけるため、合流したメンバーがアサインされたポイント通りに作業を進められず、進捗が数値化されることでプレッシャーが生じることもあります。
そのため、受け入れ時のオンボーディングは十分に期間を設けて実施することが重要です。
開発手法に対する初期の学習コストはある
（この記事で取り上げているように）スクラムのフレームワークに慣れるには最初に学習コストがかかります。
私もスクラムに参加した当初は、会議の名前や用語に戸惑いました。
例えば、スプリントレビューやスプリントレトロスペクティブなど、カレンダーに慣れない言葉がズラリと並んでいると少し混乱します。
とはいえ、一度スクラムの手法を覚えてしまえば、その後は他のプロジェクトでの参画時に比べて学習コストが大幅に下がります。
スクラムのフレームワークは共通のルールがあるため、新しいプロジェクトやチームに参加する際もスムーズに移行できます。
さいごに
要は「みんなで協力して、一歩ずつゴールに向かって進んでいく」ということです。
うまくいかない時も、それを学びの材料にして次に活かしていきましょう。
チーム全員で手を加えて完成した成果は、みんなで讃え合いましょう。
また、うまくいった時も結果に浮かれすぎず、次に進む準備をしましょう。
そうやって少しずつ、最高の思い出……ではなく、成果を作り上げていきましょう！
これくらいのテンションでお仕事できたらモチベーション上がりますよね
Discussion