はじめまして、レバレジーズ サイトディレクションチームです。
今日はレバレジーズにおける【スクラム体制】についてお話しします。

レバレジーズでは従来ウォーターフォールで制作をしていましたが、ある新規メディアの立ち上げにあたり、社内で初めてスクラム体制での制作を行いました。

■そもそも「スクラム」とは

アジャイル開発の一種で、可能な限り価値の高いものを最短で出荷するという思考を基にした手法です。
要件から工数を見積もるのではなく期間とリソースから開発範囲を見積もり、その期間内を一定の生産性で、出荷可能な状態のものを作り出していきます。頻繁に軌道修正することを前提としているので変化が激しい状況に向いており、属人化せずチームで仕事を進めるのが特徴です。

次に、スクラムで発生するメンバーの役割、工程、利用するツールを説明します。

●メンバーの役割

・プロダクトオーナー
プロダクト（製品）に対する責任者であり、機能の優先順位を最終決定する権限を持ちます。

・スクラムマスター
スクラムのプロセスがうまく回るようにファシリテートを行ったり、問題を確認し解決に動いたりします。

・チーム
3~9人で構成され、実際にプロダクト開発を行うメンバーです。優先度の高いタスクから順に着手し、スプリント（※）内に全てのタスクをDoneさせることをコミットします。各タスクは優先度の高いものから皆で開発するように心がけ、属人化を防いでいます。
※スプリント：プロダクトバックログを一定間隔（1~4週間）に区切ったときの期間

●工程

・スプリントプランニング
次スプリントで着手するストーリーをスプリントバックログ（のちに説明）に移し、それぞれのストーリーをタスク分解します。タスクもストーリー同様「Doneの定義」を明確にし、工数を見積もります。全員の見積もりが出し終われば総工数を計算し、バーンダウンチャート（後述）を作ります。

・デイリースタンドアップミーティング（朝会）
毎日、全員で進捗共有をします。話す内容は①昨日やったこと、②今日やること、③困っていることです。1人1分ほどで話し、全体で10~15分ほどで終わらせます。あくまで全員とのコミュニケーションなので、個別の質問や相談はここでは行いません。

・プロダクトバックログ・リファインメント
スプリントの折り返し地点で、次スプリントのストーリーを確認します。次スプリントのストーリー優先順位に変更はないか、次スプリントに入る前にしておかなければならないストーリーが今スプリント以前に完成しているかを見直すことで、仕様や開発の漏れ・遅れを防ぎます。

・スプリントレビュー・振り返り
スプリントの最終日に、そのスプリントで開発したものがDoneの定義を満たしているかを確認します。
振り返りでは、チームの生産性を上げるために、そのスプリントにおけるチームとしての「Keep（よかったこと）」「Problem（課題」）「Try（課題解決のための具体的なアクション）」を皆で洗い出しています。
「Try」の中にはチームの決まりごと「ワーキングアグリーメント」となるものもあります。次スプリントでより生産性をあげるために全メンバーがワーキングアグリーメントを意識して行動します。

●利用するツール

・プロダクトバックログ
プロダクトオーナーがプロダクトの機能をストーリー形式で記載し、優先順位をつけます。このとき、何をもってそのストーリーを完了とするのか、「Doneの定義」を決めておきます。また、ストーリーの追加はいつでも可能ですが、実施有無や優先順位の最終判断はプロダクトオーナーがします。

・スプリントバックログ
プロダクトバックログを一定間隔（1~4週間）に区切ったときの期間をスプリントと呼びます。スプリント期間はリリースまで均一にします。そのスプリント期間分を抜き出したタスクリストがスプリントバックログです。

・バーンダウンチャート
スプリントの残見積もり工数をグラフにします。デイリースタンドアップミーティングで前日Doneした総時間を引き算し、プロットしていきます。

■ウォーターフォールからスクラムへの移行

ウォーターフォールからスクラムに移行するには、開発の進め方やチーム体制など様々な変化が伴いました。
今回はその中でも、特にインパクトの大きかった3点をお伝えします。

1. スケジュールの立て方の違い
   我々はこれまで全体設計、デザイン、開発と順に進める制作手法を取っていたので、画面ごとに都度「設計」、「デザイン」、「開発」を繰り返していく手法に切り替える必要がありました。初期は慣れていないため、ストーリーからタスクに分解するときも粒度の大きいものになってしまうことが多く、1日でDoneできないタスクが出されていました。
   そこで我々は「基本的に1タスク4時間以内とする」ことを決まりとしてタスクを分解し、たとえミーティングが多い日でも最低1日1タスクはDoneするように心がけました。
2. 開発着手後でも変化には柔軟に
   設計したものでも、開発着手直前でスコープアウトすることもあります。あくまで全機能実装することを第一とするのではなく、期日までに可能な限り価値の高いものを作ることが重要だからです。もちろんスコープアウトだけではなく、開発中に必要な機能の漏れが見つかれば都度新たなストーリーやタスクとして追加します。
3. 職能切り分け型から協業型へ
   スクラムを取り入れた結果、タスクの属人化が減少しました。
   以前はエンジニアが全て作成していたテスト項目書をディレクターが巻き取ることもあれば、ディレクターが作成していたラフをデザイナーが巻き取ること、さらに営業がテストをすることさえありました。このように、チームで仕事を進めるのがスクラムの特徴です。「○○さんにしかできないタスク」というの減らし、優先順位の高いものから全員が協力して進めます。

■さいごに

スクラムを浸透させるのは一筋縄ではいきませんでした。
しかしスクラムを導入し約5ヶ月経った今、チーム全員が多くのメリットを感じています。コミュニケーションが活発になったこと、仕様の把握が属人化しなくなったこと、PDCAのスピードが速くなったことなど。
もちろんスクラムがどのプロジェクトにも合うとは限りません。プロダクトに求められる完成度や組織体制などによっては、うまくいかないこともあると思います。
しかし、もしメンバーのコミュニケーションや自主性、属人化などに課題を感じているチームがあれば、スクラムを取り入れてみてはいかがでしょうか？課題解決の手助けになるかもしれません。