SCRUMワークショップ体験記
アジャイル開発手法「SCRUM」の真実−1

関根信太郎（イズニーク株式会社）
黒坂輝彦
2004/10/5

---

　スクラム（SCRUM）という開発手法がある。一時期雑誌をにぎわせたさまざまなアジャイル開発手法群のうちの1つである。日本国内で実際の導入事例はないが、米国では提唱者のケン・シュエイバー（Ken Schwaber）氏によって着実に導入実績を積み重ねているという。今回公開する「スクラムワークショップ体験記」は、筆者2名が日本人として初めて認定スクラムマスターを授与されたワークショップの様子を報告したものである。

　 米国のソフトウェア開発業界における独立系コンサルタントの躍進とアジャイル開発手法群の台頭という現象は切っても切り離せないものだ。このことは、XP（eXtreme Programming）の提唱者であるケント・ベック（Kent Beck）氏をはじめ、ソフトウェア開発手法に関する分野の“カリスマ”が日本のソフトウェア開発業界に紹介されたことからも記憶に新しい。米国のこのような動きは日本にも少しずつ浸透してきている。今回の報告書から、米国のソフトウェア開発業界の最新トレンドを感じ取ってほしい。（アットマーク・アイティ編集局）

---

SCRUM ワークショップの概要

　今回参加したワークショップは、SDフォーラムというソフトウェア企業の起業家や開発者を支援する非営利団体の後援で行われた。SDフォーラムには、BEA 、IBM、オラクル、サン・マイクロシステムズといったシリコンバレーのIT企業が出資しており、エンジニアや経営者向けにさまざまなセミナーを催している。ワークショップは、シリコンバレーの南端、サンノゼ市にあるSDフォーラムの本部で行われた。

　講師は、スクラムの教祖的存在であるケン・シュエイバー氏自らが務め、スクラム養成者の資格を持つカート・ピーターソン氏（Kert Peterson）が助手として参加した。期間は2日間。

ケン・シュエイバー氏と筆者（左が関根信太郎、右が黒坂輝彦）

スクラムの概要

　 スクラム （SCRUM） という名前は、ラグビーのスクラムから来ている。両チームのフォワード合計8人がボールを囲んで組み合うことである。 スクラムは、実は日本と関係が深い。スクラムの基となった考えとスクラムという言葉は、1986年発行の『Harvard Business Review』 誌に掲載された一橋大学の野中郁次郎・竹内弘高氏共著による英文論文 “The New New Product Development Game” （「新新製品開発ゲーム」）に最初に登場した。ただし、この論文はコピー機、カメラ、自動車等の工業製品の開発に関してのものであり、ソフトウェア開発にかかわるものではなかった。この考えをソフトウェア開発に最初に導入したのがシュエイバー氏で、1995年にはシュエイバー氏の会社 ADM社によってスクラムという名前で発表された。

　スクラムは特定のプログラム言語に依存したものではなく、さまざまな言語に応用できるソフトウェア開発技法である。オブジェクト指向言語を使う必要すらないほど応用範囲の広い開発技法である。RUP（Rational Unified Process）やXPといったほかの開発技法と組み合わせて使うこともできる。

　スクラムは、アジャイルと分類される開発技法の1つである。アジャイルという言葉はウォーターフォール型開発技法のアンチテーゼとして登場した開発技法群を指す。その中では特にXP（eXtreme Programming）が有名だろう。

　ウォーターフォール型開発技法は、仕様を決め、設計をし、実際にコードを書く、という一連の順番でソフトウェア開発を進める。実際、これは非常に分かりやすい考えだが、ソフトウェア開発現場で多くの悲劇を生み出してきたのも事実である。 例えば、スケジュールどおりに開発作業が進まないという事態が頻繁に起こる。その結果、

• 納期前数週間は開発者は徹夜が当たり前
• 徹夜の努力にもかかわらず、結局リリースが数週間〜数カ月延びる
• 開発者は常に非難とストレスを受け、モチベーションを維持することが困難
• 完成したソフトウェアは、発注者の本来の目的を達成しない

などの弊害を生み出してきた。また、発注時と完成時では市場も技術も変化し、新たな要求項目ができても、要求変更は契約の変更を意味するため受け入れられにくいという状況も出てくる。さらには、仕様に間違いがあっても修正しにくい、という“欠点”もある。

　つまり、ウォーターフォール型開発技法は、発注者（顧客）も受注者（開発会社）をそろって不幸にしてきたのであった。このような悲劇はなぜ起こるのか？ 開発者の技術不足、甘い見積もり、不慮の事故などさまざまな要因が考えられるが、それだけは説明できない。根本原因を考えていくと、ウォーターフォール型開発では、以下のような問題があることが分かる。

◆ 仕様は変わらないという前提に間違いがある。仕様は実際にはさまざまな理由で変更になる

• 最初に決めた仕様に漏れがある
• 現場からの新たな要求がある
• 市場の変化
• 競合企業との競争
• 新技術の登場、普及

◆ ソフトウェア開発は完全には予測不能

• すべての事態がスケジュール段階で分かっているわけではない
• 基盤技術の不備の発覚（OSのバグ）

　工業製品の製造工程は、定型的 （defined）プロセス制御モデルというカテゴリに属し、同一の入力に対して同一の結果が期待できる。これに対して、ソフトウェア開発は、経験的（empirical）プロセス制御モデルというカテゴリに属し、常に不確実性が伴う。ウォーターフォール型開発技法での悲劇は、経験的プロセス制御モデルに属するソフトウェア開発を、定型的プロセス制御モデルの手法で管理しようとしたことに原因がある。スクラムをはじめとするアジャイル型開発技法は、逆に「仕様は変化するものである」「開発過程では予想できないことが起きる」という事実を素直に認めることから始める。スクラムの詳細は、シュエイバー氏の著書をご覧いただきたいが、その特徴だけいくつか挙げると、

• 製品バックログ：最終的に製品に入れたい機能、改善点のリスト。優先度を付け、定期的に優先順位を見直す
  
  
• スプリント：スクラムの開発サイクル。普通は30日。スプリントの最後にはソフトウェアは動作可能でなければならない
  
  
• スプリント・バックログ：特定のスプリントで実装予定の機能や改善点のリスト
  
  
• スクラム：毎日15分のミーティングを行う。スクラムとはこの会議のこと
  
  
• チーム指向：チームを単位に物事を考える
  
  
• 大部屋主義：チーム内のコミュニケーションを円滑にするため、パーティション等は廃止する
  
  
• 生産性の増大：生産性が2倍から8倍になる
  
  
• 人間性の回復：残業や休日出勤は、不要になる

など。また、下記の図をご覧になると、スクラムの大まかな流れが何となくお分かりいただけると思う。

スクラムでの開発工程（http://www.controlchaos.com/about/中の図をケン・シュエイバー氏承諾のうえ、翻訳、転載）

スクラムマスターとは？

　スクラムマスターとは、簡単にいうとスクラムにおけるプロジェクトマネージャーである。進ちょく管理、要求事項管理等通常のプロジェクトマネージャーの行う仕事のほかに、チーム内のエンジニアに対するメンター（保護者）としての技術指導や助言も行う。そのためソフトウェア・エンジニアとしての高い素養が求められる。

　ADM 社では、スクラムマスターの養成を行っており、同社のセミナーを受講すると認定（Certified）スクラムマスターとなる。スクラムマスターの上級資格としては、公認スクラム実践者（Practioner）と公認スクラム養成者（Trainer）とが用意されている。

　なお通常、スクラムマスターには、プロジェクト責任者（owner）とは別の人が任命される。プロジェクト責任者は、予算をはじめ、プロジェクトあるいは製品全体に責任を持つ。外部から招聘（しょうへい）されたスクラムマスターにとっては、お客さん、社内のスクラムマスターにとっては上司、という立場になる。

1/3

INDEX
SCRUMワークショップ体験記 アジャイル開発手法「SCRUM」の詳細解説
	Page1 SCRUMワークショップの概要
	Page2 ワークショップ 1 日目
	Page3 ワークショップ 2 日目

IT Architect 連載記事一覧

＠IT情報マネジメント メールマガジン　情報マネージャのための情報源（無料）