書籍転載：エンタープライズアジャイルの可能性と実現への提言（1）

スクラムによるアジャイル開発の進め方、従来手法とのギャップ
――第1章 アジャイル開発とスクラム――

Enterprise アジャイル スクラム

2016年12月14日

アジャイル開発を概説。また、その中の人気手法の一つである「スクラム」の基礎の基礎として、開発の進め方や従来手法との違いについて説明する。

エンタープライズアジャイル勉強会

• 連載 INDEX
• 次回 →

　書籍『エンタープライズアジャイルの可能性と実現への提言』から全3本の記事を転載します。本稿はその1回目です。

書籍転載について

　本コーナーは、インプレスR＆D［Next Publishing］発行の書籍『エンタープライズアジャイルの可能性と実現への提言』の中から、特にBuild Insiderの読者に有用だと考えられる項目を編集部が選び、同社の許可を得て転載したものです。

　『エンタープライズアジャイルの可能性と実現への提言』（Kindle電子書籍もしくはオンデマンドペーパーバック）の詳細や購入はAmazon.co.jpのページをご覧ください。書籍全体の目次は連載INDEXページに掲載しています。

■

　本章では、エンタープライズアジャイルを実現するための前提となるチーム単位のアジャイル開発を理解するために、アジャイル開発の特徴及び、世界的に最も普及しているアジャイル開発のフレームワークであるスクラムを概説する。

1.1. アジャイル開発とは

　本章では、エンタープライズアジャイルを実現するための前提となるチーム単位のアジャイル開発を理解するために、アジャイル開発の特徴及び、世界的に最も普及しているアジャイル開発のフレームワークであるスクラムを概説する。

　90年代の後半に、顧客と開発者との密な協力に基づいて顧客に役立つソフトウェアを開発することを目指すXP (eXtreme Programming) *1やスクラム*2などの複数のアジャイル開発手法が登場した。これらのアジャイル開発手法の提案者は2001年に集まり、アジャイル宣言*3を起草し、アジャイル開発の共通の価値と原則を定めた。このアジャイル宣言の原則*4はアジャイル開発を進めるためのより具体的な心構えを述べており、技術者を含むプロジェクトの利害関係者がアジャイル開発を理解するための助けになる。

　この原則に述べられているアジャイル開発の特徴をまとめると、以下の4点になる。

• A 反復的な開発
• B 顧客との連携
• C チームワークの重視
• D 技術的な裏付け

　Aは、1週間から1ヶ月程度の一定の周期で動くソフトウェアを作るという形で開発を進めるということである。この動くソフトウェアを作る１回の周期のことを「反復」と呼ぶ。A）については、反復の期間が固定であることを強調する「タイムボックス」という言葉で表現することもある。

　Bは、顧客と連携して顧客のビジネスの成功につながるソフトウェアを作るということである。顧客がソフトウェアに求めることは、顧客を取り巻く状況の変化等により開発途上で変化しうる。このような変化を反復単位で顧客からのフィードバックを受け、計画に取り込むことで、顧客のビジネスの成功につながるソフトウェアの開発を行うことができる。

　Cは、開発チームのメンバーの自律性や直接的なコミュニケーションを重視したチームの運営を行うことだ。開発チームのメンバーの自律性という点では、従来のような縦割りで計画や作業の割り当てを行い、メンバーが与えられた計画や割り当てを行うというのではなく、開発チームのメンバー間の話し合いで計画や作業の割り当てを決める必要がある。このように自律性を尊重することで、開発メンバーのモチベーションが高まり、より良い仕事のやり方を考える改善マインドが生まれる。

　Dは、要求の変化の結果としてソースコードの変更が発生するが、そのソースコードの変更のコストをなるべく抑えるような技術的な工夫（プラクティス）を講ずるということである。アジャイル開発で広く使われている技術的なプラクティスとしては、以下のようなものがある。

• テスト駆動開発（TDD: Test Driven Development）： プログラムコードを書くときに、そのコードを検証するための単体テストコードを先に書き、そのテストコードに合格するようにプログラムの本体コードを書く（テストファースト）。作成された単体テストコードにより回帰テストが自動化されるため、以降の開発でコードの変更や改良を安全かつ低コストで行うことが出来る。
• リファクタリング： すでに書いたプログラムコードの機能を保ったまま、プログラムコードの品質を高めるための改良を行うこと。コードを改良することで、１カ所のコードの変更が多くの箇所に波及しないようにする。
• 継続的なインテグレーション（CI: Continuous Integration）： 各開発者が開発した本体コードとテストコードが蓄積された構成管理ツール内のコードを自動的にビルドし、テストコードを自動実行し、それらの結果を開発メンバーに通知するというもの。このような環境を構築することで、コード状態を全員で共有し、不具合を起こすような変更を加えた場合に、それをすばやく検出し、低いコストでコードを修正することができるようになる。

　これらのプラクティスにより、加えたプログラムコードの変更による不具合（デグレード）の発生をすぐに検知したり、プログラムコードの変更が広範に波及しないようにプログラムコードの品質を高めたりすることが可能になる。このような不具合の迅速な検出やプログラムコードの品質向上によりソースコードの変更コストを削減することができる。

1.2. スクラム

　スクラムは、Ken Schwaber とJeff Sutherland、Mike Beedle によって考案されたアジャイル開発手法である。スクラムという開発方法論の名称は、ラグビーのスクラムにちなんで名づけられた。スクラムは、野中郁次郎氏らが80年代に日本の製造メーカーの新製品開発において欧米のメーカーを凌駕した要因の研究をまとめた「知識創造企業」*5などに触発され、Schwaber らがいくつかの失敗プロジェクトを立て直す経験を通じて生み出されたものである。

　スクラムは、プロジェクト管理的な作業に特化しているため、XPや統一プロセス（UP）*6など設計、実装、テストの実践形態を規定しているさまざまな反復的な開発手法と組み合わせやすい開発手法である。

1.2.1.1. スクラムにおける開発の進め方

　スクラムでは、1週間から4週間のサイクルでソフトウェアを作りながら開発を進める。図1は、スクラムによる開発の流れを示したものである。図中の用語の意味は、以下の通りである。

図1 スクラムにおける開発の流れ

• プロダクトバックログ： 開発対象のソフトウェアに対する要求のバックログ
• スプリント： 1週間から4週間サイクルの反復
• スプリント計画ミーティング： スプリントの開発目標（スプリント目標）とスプリントバックログを設定するミーティング
• スプリントバックログ： スプリント目標の達成に必要なタスクのリスト
• デイリースクラム： 日毎の進捗確認ミーティング
• 実行可能なプロダクトのインクリメント： スプリントの結果として作成される実行可能なソフトウェア

　図1に示されている標準、規約、ガイドラインは、開発組織において守ることが求められている標準、規約、ガイドラインを意味する。

　スクラムでは、開発は以下のようなステップで進行する。

1. ソフトウェアに要求される機能とその優先度をプロダクトバックログとして定める
2. プロダクトバックログからスプリントで実装するべき目標（スプリント目標）を選択する
3. スプリント目標をより詳細なタスクに分解したスプリントバックログを作成し、タスクの割り当てを行う
4. スプリントの間、毎日決まった場所及び時間で開発メンバーが参加するミーティング（デイリースクラム）開催する
5. 1回のスプリントが終了すると、スプリントレビューミーティングを開催し、作成されたソフトウェアを評価する
6. スプリントレビューミーティング後に、そのスプリントの振り返りを行い、次のスプリントでの改善策を考える
7. 次回のスプリントに備えてプロダクトバックログの内容と優先度の見直しを行う

　図1のスプリント計画ミーティングは、2、3の2ステップとして実行される。

　スクラムでは、一般の開発メンバーに加えて以下の2つの管理的な役割が定義されている。

• プロダクトオーナー： プロダクトバックログを定義し、優先順位を決める人
• スクラムマスター： プロジェクトが円滑に進むように手助けする人

　スクラムマスターの主たる任務は、通常のプロジェクト管理者のように開発者への作業の割り当て、計画策定、進捗管理等を行うことではなく、開発を阻害するさまざまな障害を解決することである。

　スプリント計画ミーティングでは、スプリント目標とスプリントバックログが決められる。スプリント目標は、次のスプリントで達成されるプロダクトバックログの範囲であり、プロダクトオーナーと開発チームとの議論によって決める。

　スプリント目標が設定された後、開発チームのメンバーが主体になって目標達成に必要なタスクをリストアップしていく。各タスクは、4～16時間で完了できる粒度で定義される。さらに、抽出されたタスクから開発チームのメンバーが話し合いによりスプリントで達成するタスクの割り当てを決める。開発チームのこのようなタスクの定義や割り当ては、顧客やプロダクトオーナーの介入なしに開発メンバーにより自律的に行われる。

　開発チームのメンバー間の自発的な議論を通じて、メンバー間の連携が自然に形成される。このチーム内の連携が自律的に形成される過程をSchwaberらは「自己組織化による真のチーム形成」と呼んでいる。

　最終的に割り当てされたタスクの集合が、スプリントの詳細目標であるスプリントバックログになる。スプリントの途上では、スプリントバックログの消化状況がグラフ化されてプロジェクトの全体の作業進捗状況として共有される。このグラフをバーンダウンチャートと呼ぶ。

　デイリースクラムは、スプリントの期間中に毎日決まった場所及び時間に開催され、開発チームのメンバー全員が参加するミーティングである。デイリースクラムでは、スクラムマスターが開発チームの各メンバーに以下の3点を質問する。

• 前回のデイリースクラム以降の作業内容
• 次回のデイリースクラムまでの作業予定
• 作業を進める上での障害

　デイリースクラムは、チーム内のコミュニケーションを促進するとともに、チームメンバー全員がプロジェクトの現状についての認識を共有し、メンバーの連帯を深めるのに有効である。また、スクラムマスターはデイリースクラムで報告された障害を解決することをできるように支援する。

　スクラムにおいて守るべき大事な点の1つは、スプリントの期間中は開発チームが開発に専念できるようにすることである。そのため、デイリースクラムには開発メンバー以外の人々も参加できるが、意見や要望を述べたりすることは許されていない。

　このようにスクラムは、非常にシンプルなフレームワークである。このシンプルさがスクラムが世界的に最も普及した原動力の１つだと考えられる。スクラムを適用することで、先に述べたアジャイル開発の特徴のAからCが実現できる。アジャイル開発の特徴のDを実現するためには、スクラムに加えて先に記したような技術的なプラクティスを適用する必要がある。

1.2.1.2. スクラムの従来手法とのギャップ

　スクラムはシンプルな手法であるものの、以下のように従来手法では存在しなかったような新たな役割、前提となる開発メンバーの意識やスキルの違いがある。また既存のガバナンスのあり方を変えることを要する。

• 新たな役割： プロダクトオーナーやスクラムマスターという新たな役割が必要になり、プロジェクト管理のやり方が変わる
• 開発メンバーの意識やスキルの違い： 開発メンバーは、指示や割り当てを待つのではなく、自律的に開発に貢献することが求められる。また、なるべく開発に関わる作業を幅広くこなせるスキルを持つことが望ましい。
• ガバナンスや品質管理のあり方の再考： 精緻な長期計画を立案する、作業分解構造による進捗管理を行うなどの既存のガバナンスのあり方を、アジャイル開発に適合するように変更する必要がある。また、品質管理のあり方も再考する必要がある。

　これらのギャップは、エンタープライズアジャイルの実現において解決すべき課題になる。

■

　今回はアジャイル開発の概要と、その中の人気手法の一つである「スクラム」の基礎を説明しました。次回は、企業でアジャイル開発に取り組む際の典型的なアンチパターンを紹介します。

• ▼ この記事の連載 INDEX ▼ 連載 RSS
• 次回 →

1. 【現在、表示中】≫ スクラムによるアジャイル開発の進め方、従来手法とのギャップ

アジャイル開発を概説。また、その中の人気手法の一つである「スクラム」の基礎の基礎として、開発の進め方や従来手法との違いについて説明する。

2016年12月14日(水曜日)

2. アジャイル開発でよく見られるアンチパターンと落とし穴、その対策

日本企業での失敗事例から、企業でアジャイル開発に取り組む際の典型的なアンチパターンを紹介。その原因となる落とし穴と、本来のあるべき姿を明らかにする。

2016年12月19日(月曜日)

3. 企業でのアジャイル開発の戦略 ― その狙い、注意点、投資効果

企業や事業部がどんな狙いでアジャイル開発を使うのか？ 注意すべき点は何か？ 投資効果をどう考えるか？ というエンタープライズアジャイル開発の戦略について考える。

2016年12月26日(月曜日)