スクラム提唱者から学ぶ、チームの不幸を減らすたった2つの方法：スクラム提唱者が教える、チームの不幸を減らす方法（1/2 ページ）

スクラム提唱者のジェフ･サザーランド氏を講師に招いた、日本初の「スクラムアライアンス認定プロダクトオーナー研修 レポート」レポート。チームも顧客も不幸な状態をなくす方法は実にシンプルだ。

[永瀬美穂，スクラム道]

2011年はアジャイル実践者にとって歴史的な年となった

　デスマーチ続きでリリースは遅延、チームはプレッシャーを受けてマネージャはてんてこ舞い、顧客も不幸……そんな状態を良い方向に転換する方法はたった2つである――「スクラム」提唱者の1人である、ジェフ・サザーランド氏の言葉です。

　1月11日と12日、サザーランド氏による日本初のスクラムアライアンス認定プロダクトオーナー研修（Certified Scrum Product Owner 研修、以下CSPO研修）が開催されました。翌日の1月13日、Innovation Sprint 2011の基調講演では、スクラムの名付け親である野中郁次郎氏と、スクラムをソフトウェア開発のメソドロジーに昇華させたサザーランド氏が初めて対面するという、歴史的な瞬間が実現しました。2011年は、アジャイルの実践者、とりわけスクラムの実践者にとっては早くも忘れられない年となりました。

　「ジェフ･サザーランド氏から直接、スクラムの教えを受けることができる」――スクラムマスターとして、日々スクラムとエクストリーム・プログラミング（XP）のハイブリッド型でアジャイル開発を実践している筆者は、さっそくCSPO研修に参加を申し込みました。これから、CSPO研修の模様をレポートしつつ、スクラムのメソドロジーやプロジェクト改善のコツを紹介します。

まずはスクラムについて

　まず、スクラムについて簡単にご説明しましょう。

　スクラムは、数あるアジャイルな開発手法のうちの1つで、顧客とチームがゴールや目標を共有したうえで、小さなリリースと小さな改善を積み重ねながら、ビジネス価値の高いプロダクトを無駄なく生み出すためのフレームワークです。「スプリント」「スクラムボード」「バーンダウンチャート」といった言葉を聞いたことがある方も多いでしょう。

【用語解説辞典：スクラム】

　野中郁次郎氏と竹内弘高氏が論文 “The New New Product Development Game”（『 Harvard Business Review』、1986年）で、日本の製造業における新製品開発に対するアプローチを、ラグビーのスクラムになぞらえた。これに着想を得たアメリカのエンジニア、ジェフ・サザーランド氏とケン・シュエイバー氏が、ソフトウェア開発にこのアプローチを取り入れて実践。プラクティスは、『アジャイルソフトウェア開発スクラム』（ピアソンエデュケーション、2003年）にまとめられている。

豪華すぎる講師陣

　CSPO研修は、何といっても講師陣が素晴らしく豪華でした。

　ジェフ・サザーランド氏は、戦闘機パイロット、製薬会社、銀行というキャリアの中で培った経験を生かし、現在はスクラムの教育や導入支援を専門に行う The Scrum Foundation を設立して活動しています。

　ガブリエル・ベネフィールド氏は、 サザーランド氏とともに働くアジャイルのエキスパートで、米Yahoo! などでスクラムの適用支援をしています（そこでのスクラムチームの数は200を超えるとか！） 。

　研修には、40名以上が参加しました。認定スクラムマスター研修（以下、CSM研修）の受講者や、日本のアジャイルをけん引しているエキスパートや、さまざまな関連領域の有名人もいることから、日本初のCSPO研修への期待の高さがうかがえました。コースの2日間、講師陣はとても気さくに正直に接してくれました。その空間に思いをはせながら、親しみを込めて本レポートでも、両名をジェフ、ギャビーと呼ばせていただきます。

チームの不幸をなくす、たった2つの方法

　「Ready」と「Done」、この2つがデスマーチ続きでリリースが遅延し、、チームもマネージャも顧客も不幸になるという悲惨な状態を良い方向に転換する方法だと、ジェフは講義の冒頭で切り出しました。

• Ready

　1つは、プロダクトバックログの準備ができていること（Ready）。これによって、チームのメンバーは何を最優先でやるべきかを知り、共有できます。

【用語解説辞典：プロダクトバックログ】

　スクラムで定義されている成果物の1つで、プロダクトオーナーによって優先順位づけされた、ユーザーストーリーを積み上げたリストのこと。プロダクトオーナーは、このリストを管理する責任を持つ。これは“優先度高とか優先度低とかのフラグがついたもの”ではなく、必ず“優先順位づけ”されたものであり、同じ優先度のものは存在させられない。

• Done

　もう1つは、準備のできたものを完了させること（Done）。フィーチャーレベルのテストまで終わっている、必ず動くソフトウェアを作ることです。

　ギャビーがスクラムを導入したチームでは、スクラム導入前に比べてチームのスピードが確実に向上しました。もちろん、いいこと尽くめではありません。スピード感もなく、プロダクトバックログはReadyでもなければDoneにもならないこともあったそうです。しかし、ジェフはいろいろなチームを見てきた中でこう言いました――「少なくとも、スクラムのアプローチを行うのは、やらないより全然マシ」。

タスクスイッチングは、生産性を確実に落とす

　スクラムチームが行うべきことは “Ready,ready.Done,done!!” 、すなわち今やるべきことに全力で集中することです。では、具体的に「集中」とは、どのように行えばいいのでしょうか。筆者は集中するとはどういうことかを、「数字の足し算」による個人ワークで学びました。参加者は、ルールに従って数字を書き出します。ルールは2つ。

• ルールA：1、3、5……と、前の数字に2を足しながら書く
• ルールB：1、4、7……と、3を足しながら書く

　ルールAで1分間、ルールBで1分間、集中して数字をひたすら書き出すことは比較的、簡単です。では、紙を上下に分け、ルールA、ルールB、ルールA、ルールB……と交互に数字を書き出す作業を2分間行ったらどうでしょうか。実際に紙とペンがある人はやってみてください。書き出せた数字の量と正確さに違いがあることが実感できるはずです。

　ルールAとルールBを交互にやる作業、すなわち2つのタスクを切り替えながら作業することを「タスクスイッチング」と呼びます。このワークを通して受講者は、「タスクの切り替えコストは生産性を落とす」ということを実感しました。

　タスクスイッチングは、生産性を落とすだけではなく、「タスクスイッチングをしている方が忙しいので、たくさんタスクをこなしているように勘違いしてしまう」というデメリットもあります。皆さんも、経験があるのではないでしょうか。

期日は延長しない。期日までにいかに作業を完了させるか

　スクラムでは、他のアジャイル開発プロセスと同様に「タイムボックス」の考え方があります。特にスクラムでは、「スプリント」と呼びます。

【用語解説辞典：スプリント】

　スクラムにおける、時間に関する定義の1つ。同じくスクラムの儀式として定義された「スプリント計画ミーティング」に始まり、「レトロスペクティブ（ふりかえり）」で終わるタイムボックス。理想的には3週間と言われ、この間にチームは、ユーザーストーリーをソフトウェアという形にして出荷可能にするために、タスクをこなすことに全力を上げる。タイムボックスを固定することによって、チームが一定の期間にどれだけ生産できるかを計測でき、それによって近い将来のスプリントでどのぐらい生産できるかを予測できる。スクラムの特徴は「実測駆動」である。

　スプリントはスプリント計画ミーティングで始まります。プロダクトオーナーは優先順位をつけた要求項目リスト(プロダクトバックログ)を提示します。チームは、各項目の規模を全員で1つひとつ見積り、今回のスプリントでどの項目まで完了可能かを見積もります。チームは予定した項目から詳細タスクを洗い出し、スプリントバックログを作成します。

　スプリント期間中、チームはスプリントバックログの項目をこなしていきます。チームは毎日、スクラムミーティングを行い、昨日やったことと今日やること、阻害要因について共有します。スクラムマスターは、そこで出た阻害要因を取り除くために奔走します。スプリント終了時にはプロダクトのレビューを行い、プロダクトオーナーはチームの成果を承認します。チームはレトロスペクティブ（ふりかえり）を行い、プロセスの改善を試みます。

　従来型のプロジェクト管理においては、各フェイズが完了するまで期間が延長される可能性がありますが、スクラムでは作業が終わっていようといまいと完了期日はやってきます。一定の時間枠の中で、いかに生産的にプロダクトをインクリメントするのか――これがチームの責任です。

制約の中で動き、制約を外して動く

　このワークは、座ったテーブルごとに、6名ずつのチームで行いました。紙とハサミで紙飛行機を作り、時間内に多くの紙飛行機を飛ばしたチームが勝ち、というチーム対抗戦です。

• 計画して
• 実施して
• 振り返る

床に散らばった紙屑ヒコーキ
　（c）Takashi Imagire

　チームは、1スプリントの中で上記の作業をリズミカルに繰り返し、やり方を改善することを学びます。

　チームには、あらかじめ「ハサミで大きな紙を切らなければいけない」「紙ヒコーキの先端は丸めなければいけない」「1カ所を折ったら隣の人に回さなければいけない」「テスト用の飛行エリアが限られている」といった制約が与えられています。課せられた制約を外してみる、という体験もします（普段の開発プロジェクトでも、制約はがんじがらめに存在していることがありますよね）。

　制約を外されたエンジニアの行動は爽快でした。いいオトナが紙屑をぼんぼん放り投げるのです！ 非常にエキサイティングな体験でした。