5分で分かる、「スクラム」の基本まとめ：開発チームを改善するためのスクラムTips（8）（1/2 ページ）

「スクラム」は、アジャイル開発の手法群の中でも、「チームとしての仕事の進め方」に特化したフレームワークだ。スクラムの知識を応用して、開発チームの日常をちょっとリファクタリングしてみよう。

[かわぐちやすのぶ（@kawaguti），＠IT]

　これまで、アジャイル時代のチーム・マネジメント手法として主流になっている「スクラム」の手法を紹介してきました。今回は総集編として「スクラムの基本」をコンパクトにまとめます。

そもそもスクラムとは

　スクラムは、一言でいえば「チームで仕事の進めるための枠組み（フレームワーク）」です。

　もともとはソフトウェア開発プロジェクトを成功させる仕組みですが、技術的な要素は取り除かれ、多くのチーム作業に共通して適用できる要素だけが残りました。そのため、ソフトウェア開発以外のチームにも適用できるのが特徴です。

●バックログ：チームの待ち行列であり、作業計画であり、計画変更のキャンバス

　スクラムでは、2つのバックログを定義しています。

　プロダクトがユーザーや顧客に提供する価値を記述する「プロダクト・バックログ」、当面の作業計画を示す「スプリント・バックログ」です。

▼プロダクト・バックログ

　プロダクト・バックログは、機能や技術的改善要素を優先順位を付けて記述したものです。ステークホルダ全員が参照し、現在のプロダクトの状況を把握できるようにします。

　「ユーザーストーリー」形式がよく用いられますが、形式が重要なのではなく、関係者がいつでも内容を思い出せるようにすることが目的です。

• 誰のために
• 何のために
• それを実現するのか

について合意し、いつでも思い起こせるようにしておくということです。そうすれば、仕様変更が起きた時、「なぜ変更が必要なのか」が理解しやすくなり、プロダクトの全体の進捗への影響の把握・伝達がスムーズになります。

　緊急な変更の時「そもそもこの機能は……」という議論や説得に時間をかけてしまえば、プロジェクトの死に直結しかねません。危機に陥る前に、定期的に自分たちの状況を共有しておき、透明性、信頼性を醸成しておきたいものです。手の内を隠してポーカーフェイスで交渉するより、手の内をさらして実力をありのままに把握してもらうのです。

▼スプリント・バックログ

　スプリント・バックログは、プロダクト・バックログからスプリント期間（1〜4週間）分を抜き出した「チームのタスクリスト」です。

　チームは、予測どおりにきちんとタスクを終わらせられるかを検討します。チームメンバーの多種多様なスキルを総動員して、自信を持って「終わる」と宣言できるかどうかが、確認すべきポイントです。

　スプリント期間中は、スプリント・バックログにある作業や機能を完了させるべく、チームとしてベストを尽くします。「私の仕事、あなたの仕事」ではなく、「チームの仕事」です。チームとして責任を持ち、全力で仕上げていきます。

　そのため「チームとして情報を共有」することが必要不可欠です。そのために効果的なのが「デイリースクラム」（朝会）です。デイリースクラムは毎日、全員で進捗を確認するミーティングです。

　答えることは3つの質問だけ。

• 昨日やったこと
• 今日やること
• 障害になっていること

　この3つの答えをチーム全員で共有します。細かい問題に立ち入ることは避け（別に時間を取る）、トータル15分を目安に完了させます。

▼タスクボード

　タスクボードは、バックログを壁とふせんで表現したものです。視覚的に状況を把握できるため、短時間で最新状況を共有するのに役立ちます。

• ToDo（これからやること）
• InProgress（着手していること）
• Done（完了したこと）

　という領域の中で、タスクを表すふせんを動かしていきます。

▼使い方

1. スプリント・バッックログの全タスクをふせんに書いて「ToDo」にはる
2. デイリースクラムでは「1.昨日やったこと」は「Done」に動かし、「2.今日やること」は「InProgress」に動かす

　タスクボード自体も、チームの業務の進め方や、仕事を進める過程で出てきた課題に対応し、改善・改造をしていきます。

　バックログやデイリースクラムの詳細については、連載を参考にしてください。

• 第1回「ほう・れん・そう」を15分の朝会に置き換える
• 第2回“なる早”タスクに振り回されないための「バックログ」
• 第3回バックログで、動的に計画変更できる仕組みを作る
• 第4回プロジェクト予測の限界、改善法としてのスクラム

ロール（役割）：リーダー・マネージャ主体から、チーム主体へ

●理想のチームは3〜10人

　「リーダーやマネージャに責任を押し付けすぎず、チーム主体でセルフマネジメントしていこう」

　これが、スクラムのチームのあり方です。

　チームがまっとうなコミュニケーションをするためには、人が多すぎてはいけません。スクラムでは「3〜10人＝1チーム」を推奨しています。10人ならば、デイリー・スクラムで1人1分ほど話しても10分程度で終わります。

●プロダクト・オーナー

　スクラムではチームが主体的に作業を行っていきますが、合議制の意思決定は時に非効率です。そこで、プロダクトオーナーを決めます。

　プロダクトオーナーは、プロダクト・バックログの作成と優先順位付けの最終責任を持ち、どちらともいえない問題にも、責任をもって白黒をつけていきます。世の中には、やってみなければ分からないことがたくさんありますから、100の議論より、とにかく勘でいいから順番を決め、やってみた結果を見てから判断する方が良いことも多いのです。

●スクラムマスター

　スクラムマスターは、メンターであり舞台装置家です。チームを健全に保つ「チーム医」の役割といってもいいでしょう。

　スクラムマスターの仕事は、チームの仕事がうまくいっていっているか、困っていることは何かを確認することです。時にチームから問題を分離し、自ら解決に動くことで、チームの集中を保ちます。プロダクト・オーナーがうまく動けていない場合も、アドバイスを行って修正を試みます。

　チーム、プロダクトオーナー、スクラムマスターについては、連載の後半で詳しく説明しています。

• 第5回最適化した開発チームは3〜10人で美しく回る
• 第6回指示しないリーダー像：プロダクトオーナーは舵取り役
• 第7回スクラムマスター：不都合な事実を見つけるチームの医