アジャイル開発概論ー管理者編ー＇手法： Scrum XP ハイブリッ … ·...

アジャイル開発概論ー管理者編ー＇手法： Scrum＋XP ハイブリッド（

2010年 1月 12日＇火（

株式会社戦略スタッフ・サービス

Ｃｏｐｙｒｉｇｈｔｓ©2010 SSS Corporation

2

目次

１．アジャイル開発とは

アジャイル開発手法の紹介

アジャイル・マニフェスト２００１の紹介（アジャイル開発の基本的概念）

スクラム（Scrum）の概要（アジャイル開発プロジェクトのプロセス）

２．アジャイル開発プロジェクトに関わる関係者の役割り

アジャイル開発プロジェクトの組織と運営体制

各役割りの紹介

□ 開発チーム

□ プロダクト・オーナー（ユーザー代表者・リーダー）

□ スクラム・マスター

□ 開発チームの管理者・経営者

□ 支援スタッフ

３．アジャイル開発チームの運営

自律した開発チームの育て方

ファシリテーションとは

開発チームの評価方法


3

１．アジャイル開発とは

ここ十年＇２１世紀に入って（注目されてきたシステム構築のメソドロジー

１．Dynamic System Development Method (Dane Faulkner) -2006

２．Adaptive Software Development (Jim Highsmith)

３．Crystal Clear (Alistair Cockburn)

４．Scrum (Ken Schwaber, Jeff Sutherland, Mark Beedle) 1994-2002

５．XP <eXtreme Programming> (Kent Beck, Eric Gamma) 1996-2000

６．Lean Software Development (Tom and Mary Poppendieck) -2003

７．Feature-Driven Development (Peter Code, Jeff DeLuca) -2002

８．Agile Unified Process (Scott Ambler)

９．RUP <Rational Unified Process> 1999-2003

要求仕様

リソース納期

プラン・ドリブン

実現仕様

リソース納期

バリュー・ドリブン

前提条件＇フィックス（

推定

アジャイルウォーターフォール＇従来（


4

アジャイル開発の特徴

• イタレーション

• 周期的な納品＇１週間～８週間（

• 開発チーム

• 自己統制型、オーナーシップ＇自己申告（

• 開発プロセスの標準化

• 技術、情報の共有化＇見える化（

• 簡潔なデザインとコード

• リファクタリング

• ペア・プログラミング

• コードの標準化

• 技術の共有、技術伝承

• タスクボード

• 機能の提供＇完了（をもって進捗を把握

• 作業の宣言＇タスクと作業時間、見積工数（

• テスト駆動開発

• テストの自動化

• アクセプタンス・テスト＇完了・終了の定義（

• 継続的インテグレーション＇基本的に毎日昼（

• 行灯

• 自動テスト

• 簡潔な文書化

• ユースケースか？ユーザーストリーか？

• ＵＭＬ

イタレーション１イタレーション２イタレーション３イタレーション４イタレーション５

納品納品納品納品納品

２週間２週間２週間２週間２週間

バーンダウン・チャートタスクボード

To Do On Going Done

a

e

d

c b

fg

h

当日の作業タスク用＇８０％（

メンテ用＇１０％（リファクタリング用

＇１０％（

テスト正常終了テスト異常発生

チーム全員でメンテ実行

テスト

コード

デザイン

小さいテストのコード作成

次にソース・コードを作成

最後にデザインをリファクタリングする。

このプロセスを廻す。

ペアの交替＇定期的（


5

「経済財政改革の基本方針2007」では、重要課題として労働生産性を5年間で50％増にすることを目標にしており2007年5月には、

「サービス産業生産性協議会」＇牛尾治朗代表幹事（が発足しました。この様な大きな流れの中で、今後、具体的にどの様にすべきか？がソフトウエア産業として課題となります。またサービス産業の分野でも、製造業にて着実に生産性向上を実現しているトヨタ生産方式＇TPS)が着目され実際に導入されて成果を上げております。

一方で我々ソフトウエア産業では、３Kや５K、最近では７Kと言った言葉が囁かれ、労働生産性どころか、若手の情報産業離れで有能な人材を確保することも困難になってきております。

欧米でのアジャイル開発には九種の手法が存在しますが、どの手法の説明でもアジャイル開発の基本はトヨタ生産方式＇TPS)である事が書かれております。1983年に出版されたTPSの英語訳本より欧米では、このTPSを研究していろいろな分野に適用して来ました。ソフトウエア開発の分野で適用された手法がアジャイル開発です。因みにアジャイル開発の一手法の名称であるスクラム＇Scrum（とはTPSの中で説明されているスクラムを語源といたしております。

アジャイル開発の基本はTPSで言われる現場、現実、現物の現場＇開発チーム（主体でのソフトウエア開発です。また製造業の生産工程で言われている単能工＇ウォーターフォール型開発（から多能工＇アジャイル開発（へのソフトウエア・エンジニアの変革で有ります。

岐阜県NPOでのパイロット・プロジェクトの実績からも開発チーム主体＇プロジェクト・マネジャー不在（でのプロジェクト運営が実現でき、高品質なプログラム作成を残業や休日出勤無で、納期＇計画（通りのソフトウエア開発が可能です。結果的に生産性、品質、お客様からの信頼感が飛躍的に向上いたしました。

アジャイル開発は、ソフトウエア開発での「トヨタ生産方式＇TPS（」

必要な物を、必要な時に、必要なだけ作る！『リーン』と言う考え方は、製造業で提唱されてきましたが、リーンの原則の多くは以前からソフトウエア開発にさまざまな形で存在しておりました。

製造業で言われるサプライチェーンはとりもなおさずソフトウエア・デリバリーです。そこにはインプットとアウトプットと付加価値活動(プロセス（があり、そのプロセスの中で価値を付加しないムダなステップを排除しようとするアプローチは製造業やサービス産業と同様なアプローチです。

リーンで重要な考え方に価値フローの概念があります。別な言い方をすれば製品やサービスをジャスト･イン･タイムで生産し提供すると言う事に尽きます。そのために７つのムダを排除しようとするものです。

反復型＇イタラティブ（での開発はソフトウエアのバリュー･チェーン＇フロー（を実現する最も優れた手法です。

また在庫回転率を上げる＇フローを澱みなく流す（為には、製造業でもサイクルタイムの短縮が重要なファクターです。ソフトウエア開発で言えばアジャイルでの短いイタレーション＇1週間など（が効果を発揮します。

更にフローを促進する為に生産の平準化も大きな要素です。ソフトウエアの現場では、開発チームのベロシティーをある水準で出来るだけ維持できる事が重要です。


6

リーンなソフトウエア開発の為の７つの原則

原則１．ムダ取り

早く仕様を明確にすれば無駄を排除できる

原則２．品質の作り込み

製作作業内でテストを実施すれば早く問題を検知できる

原則３．学習する組織＇チーム（

仮説を立てる＇予想する（事は失敗を回避する予想が立てられる

原則４．直前での決断

計画は即実行である

原則５．短期納品＇素早い提供（

慌てるとムダを作る

原則６．作業者＇開発チーム（の尊重

起業家マインドのリーダー

その道のエキスパート作業者

自律

原則７．全体最適

複雑な問題を細分化して分析した上での全体最適


7

ソフトウエア製造工程におけるムダの排除

TPSでは7つのムダの概念があり、ソフトウエア製造工程でも同様に考えられる。

１．作りすぎのムダ

顧客に使用されない機能、実際には不要な機能、真のビジネス価値を生まない機能などの余分な機能を作らない。

StandishのCHAOSレポートによるとソフトウエアの全機能の６５％は全くあるいは殆ど使用されていない。

２．手待ち＇停滞（のムダ

仕様の提示遅れによる製造開始遅れでの待機、許可待ち、ビルド待ち、障害発生によるテスト待ち

３．運搬のムダ

複数プロジェクトでの作業の切り替え、仕様入荷チェック、納品出荷チェックの提供＆受領双方での重複チェック

４．加工そのもののムダ

開発現場で機能していない作業項目例えば余分な事務処理、報告書作成や作業分担の誤りによる過剰な作業

５．在庫のムダ

最終工程で使用されない文書や計画、コンポーネントなどの中間的な作業成果物と待ち状態で仕掛中のプログラム

６．動作＇作業（のムダ

関係者の作業場所の移動や複数の開発ツールを使用して開発ツール間の切替・移行

７．不良をつくるムダ

バグの作り込み---要求仕様(要件（、設計、コードの欠陥


故大野耐一氏に1970年代から師事しトヨタ生産方式を学び大野氏の晩年に大野氏からトヨタ生産方式の体系化の完成を託された山田日登志氏は、現場ではこの7つの中から2つのムダに注目しこの2つのムダを廃除すれば結果的に７つのムダを廃除できる事を発見し現在いろ色々な現場でカイゼン・リーダーの育成に尽力され、カイゼンの指導をされております。

山田氏のムダ取りの指導は製造業のみではありません。いまやサービス業、金融業、商店、行政組織＇自治体（、福祉法人など様々な分野でこのトヨタ生産方式の考え方、ムダ取りが適用されて効果を発揮しております。情報システム＇ＩＴ（産業では、アジャイル開発手法としてアメリカで再構成されて日本に逆輸入されております。

山田氏の言う注目すべき2つのムダとは、

① 停滞のムダと② 動作・運搬のムダです。

これは生産現場に限った事ではありません。皆さんの作業の中にも沢山存在しております。その証左は知的作業であるソフトウエアの開発プロセスでもScrumによるアジャイル開発を実施する事によりこの２つのムダを廃除できる事が実証されております。

そうですたった2つのムダに注目しこのムダを徹底的に廃除する努力をすればトヨタ生産方式の真髄である『必要な物を必要な時に必要なだけ作る』事を可能にします。とりもなおさず、ムダな非生産的な長時間労働から作業者は解放され、モチベーションを高めて、ユーザーに喜ばれる高品質なサービス＇商品（を提供でき、人間らしい生活ができる労働環境を確立できます。

8

アジャイル・マニフェスト＇２００１（

www.agilemanifesto.org より抜粋 2001年11月13日に作成＇2001年2月、17人の同士がユア州スノーバードにて（

We are uncovering better ways of developing software by doing it and helping others do it. Through this work we have

come to value;

Individuals and interactions over processes and tools.

Working software over comprehensive documentation.

Customer collaboration over contract negotiation.

Responding to change over following a plan.

That is, while there is value in the items on the right, we value the items on the left more.

我々は自ら実践し、また実践しようとしている人を支援することを通して、よりよいソフトウエア開発の方法を見出そうとしている。

この活動をとおして我々は下記のようなことを価値あるものと考えるに至った。

プロセスやツールよりも、個人や相互関係を。------ツールも大事であるが、一人のエース・プログラマーより平均的なプログラマーのチームワーク。

包括的なドキュメントよりも、働くソフトウエアを。----ドキュメントのないプログラムは最悪、しかしドキュメントが多い物よりは尐ない物の方が良い。

契約折衝よりも、顧客とのコラボレーションを。------成功するプロジェクトは顧客を巻き込み、定期的に顧客にフィードバックする事。

計画に従うことよりも、変化への対応を。-------------良い計画とは詳細な２週間の計画と荒い３ヶ月の予定であり、それ以上はメモ。直近２週間の計画を変更する事は、あらゆる点で大変困難である。

これは太字の項目をより重視すると言うことであり、細字の部分を無視して良いと言う事ではない。

大事な事は、人、人と人との交流と協調、適応力、動作するソフトウエア


http://www.agilemanifesto.org/

9

1.Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.

我々の最優先事項は素早いそして継続的な価値あるソフトウエアの提供を通して顧客の満足を得る事である。

2.Welcome changing requirements, even late in development. Agile process harness change for the

customer’s competitive advantage.

開発局面の後半でも要求変更を歓迎する。アジャイルなプロセスを顧客の競争優位の為の変化に利用する。

3.Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the

shorter timescale.

稼動するソフトウエアをより短かい期間を優先して、数週間から数ヶ月で定期的に提供する。

4.Business people and developers must work together daily throughout the project.

プロジェクト期間を通して業務ユーザーと開発者は共同して作業をしなければならない。

5.Build projects around motivated individuals. Give them the environment and support they need, and trust

them to get the job done.

やる気のある個人を集めてプロジェクトを組織し、彼らが必要とする環境と支援を与え、仕事が完了するまで信頼する。

6.The most efficient and effective method of conveying information to and within a development team is face-

to-face conversation.

部門内、間のコミュニケーションで最も効率的かつ効果的な手法は、フェイスツーフェイスの会話である。

Key principles that support the Philosophy of Manifesto ＇１（マニフェストの思想を支える重要な方針＇原理（


10

7.Working software is the primary measure of progress.

ソフトウエアが正常に機能するということが進捗の基本的な評価である。

8.Agile processes promote sustainable development.

アジャイルプロセスは持続可能な開発を促進する。

9.The sponsors, developers, and users should be able to maintain a constant pace indefinitely.

スポンサー、開発者、ユーザーは無期限かつ不断に保守できるようにしなければならない。

10.Continuous attention to technical excellent and good design enhances agility.

技術的に優れた良い設計に継続的に配慮する事は機敏性＇アジリティー（を増長させる。

11.Simplicity- the art of maximizing the amount of work not done- is essential.

簡素が基本－しない仕事の極大化の美学ー

12.The best architectures, requirements, and designs emerge from self-organizing teams.

最良の構想、要求仕様、設計は自己統制された＇自律的（チームより出現する。

13.At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its

behavior accordingly.

定期的にチームが振り返りを行い、より効果的に出来る方法を思案し、チームの行動に協調と調整が働く。

Key principles that support the Philosophy of Manifesto ＇２（マニフェストの思想を支える重要な方針＇原理（


11

Product Backlog

1.---------------

2.---------------

3.---------------

4.---------------

5.--------------- Part 1

Part 2

Sprint Task List

(Sprint Backlog)

a.----------------

b.----------------

c.----------------

d.----------------

e.----------------

f.----------------

Sprint Review

Refactoring

Daily Scrum

Iteration (Sprint)

Sprint Planning

1週間～10週間

Product Owner

＇お客様（

Scrum Master＇ファシリテーター（

Team

Developer (Pair Programming)

バーンダウン・チャート

毎朝15分のスタンドアップ・ミーティング

タスクボード

To Do On Going Done

a

e

d

c b

fg

h

２時間

２時間

確実な優先順位付け＇同位は無し（

追加、修正、変更可能＇Sprintに入っている物以外（

Product Ownerが全て責任を持つ

Scrumによるアジャイル・プロジェクト運営＇管理（


12Ｃｏｐｙｒｉｇｈｔｓ©2010 SSS Corporation

アジャイル・プロジェク・ルーム風景

青：第一週目橙：第二週目のタスク

ペアプログラミングの風景

タスクボード

13

ウォーターフォール型開発＇従来（との違い

要求仕様

設計

コーディングユニット・テスト

システム統合

運用保守

０３６９１２

時間経過＇月（

納期

ウォーターフォール型開発

０３６９１２

２５％

５０％

７５％

１００％

時間経過＇月（

要求の信憑性

要求の時間的変質

２４ヶ月後では２５％程度

平均的な値


ユーザーと開発者の信頼関係が希薄であり、長期間のプロジェクトの間に何処まで進行しているか？要求を満たしているのか？確認する術が無い。完成して初めて解る。

また昨今のビジネス・スピードの短期化により設計時点での要求内容そのものも時間経過と共に時代遅れになる。要求内容が変質する。

シリアルな開発プロセスで、開発プロセスの中にボトルネックとなる工程が発生する。

大型化してプロジェクトの成功率が低い

Standish GroupのCHAOS surveyより

Successful project 16% 26%

Failure project 31% 28%

Challenged project 53% 46%

プロジェクトサイズを適正化＇小口化（

１９９８年

14

ウォーターフォール型開発の問題－１

従来のウォーターフォール型ソフトウエア開発とは、システムの要件を整理した後、システムの設計を行い、その設計書に沿ってプログラムを開発し、完成したプログラムをテストして最終的には対象システム全体での統合テストを完了して、納品＇サービス提供（稼動されます。この様に水が高い所から低い所に向かって流れるように作業が進展していく事からウォーターフォール型開発と言う名称があります。この手法の最大の問題点は、プロジェクトの最終段階である統合テストが実施されるまで、そのシステム＇ビジネス・プロセス（が成立するか？破綻するか？が判断できない事であり、万が一トラブルが発生すると、逆順に作業工程を遡って原因の追究と解決をしなければなりません。

その分、時間と人工と言う多大なコストが掛かります。経営資源がトラブルの解消と言う後ろ向きな作業に費やされる事になります。

一方アジャイル開発では、基本的な手順として、重要度の高いプロセス、リスクが見込まれるプロセスなどクリティカル・パスからプログラムが作成され、作成されたプログラムは完成後幾度と無く統合テストが繰り返される為、プロジェクト＇工期（の終了時点までに完成度が高まります。またプロジェクト開始直後からそのシステム＇ビジネス・プロセス（が成立するか？破綻するか？を判定できますので、プロジェクト投資の安全性をプロジェクト開始直後に担保できます。

ウォーターフォール型開発アジャイル開発

リスクに捉まる潜在的な影響度

何故アジャイル開発が良いのか？


15

ウォーターフォール型開発の問題－２

プログラム開発の『見える化』

従来のウォーターフォール型ソフトウエア開発で皆様どの様に作業進捗を把握、管理されているでしょうか？また従来の手法で満足＇納得（出来るでしょうか？如何に精緻な管理を行なっても設計工程が60％完了しましたとか、プログラミング工程が80％完了しましたと言った報告で、そのシステムが納期＇工期（通りに完成して、当初＇ユーザー要求通り（の機能を提供できると言う事を最終テスト以前に確信を持って言い切れるでしょうか？

残念ながら、現在のウォーターフォール型ソフトウエア開発では否としか言えないのではないかと思います。この最大の問題は、作業工程が『見える化』出来ない事に起因しております。どの様に考えても現在のウォーターフォール型ソフトウエア開発では、不可能でしょう。それは前述いたしました様に、プロジェクトの最終工程の統合テストを行なうまで、何が完成して、何が機能していないのか？プロジェクトの途中では判定できないからです。

またこの様な流れ作業的な進め方で、完了の基準を途中に求める事が困難である為です。従って、従来のウォーターフォール型ソフトウエア開発では、便宜的に流れる作業の完了基準＇目に見える成果物ではなく（を作成して、便宜的に進捗を把握することになります。

一方、アジャイル開発では、毎週、動くプログラムの完成をもって作業の進捗を把握いたしますので、明確な進度を把握できます。また今週の作業予定はタスクボードにポストイットに記入されて貼られておりますので、チームの全員が目で見て進捗が把握できますし、作業完了もバーンダウン・チャートにより動くプログラム＇統合テスト完了（本数によってカウントされます。

バーンダウン・チャートタスクボード

To Do On Going Done

a

e

d

c b

fg

h

イタレーション１イタレーション２イタレーション３イタレーション４イタレーション５

納品納品納品納品納品

1~2週間 1^2週間1~2週間1~2週間1~2週間

何故アジャイル開発が良いのか？


16

２．アジャイル開発プロジェクトに関わる関係者の役割り

開発チーム

開発プロジェクトの全ての責任を持つ

プログラム＇納品物（

品質

納期

ユーザーとの協働

開発チームは自律的に活動する。

スクラム・マスター

開発チームの全ての活動を支援するが、責任と権限は無い。

開発チームが安定した高いパフォーマンス＇産出量（を維持できる様に、プロジェクト関係者すべての協力を得る根回しを行なう。

開発チームへの叱咤激励、ファシリテーションを通して、ムダや問題を廃除する気付きを起こす。

プロダクト・オーナー＇ユーザー代表（

要求仕様の明確化と優先順位設定を行なう。

各イタレーション毎に納品されるプログラムのユーザー・テストを実施し、その評価を開発チームにフィードバックする。

支援スタッフ

専門性が高く、且つ開発チームメンバーで補えないスキルを支援する。例えば、

適用業務SE

データベース・アーキテクト＇アドミニストレーター（

システム・アーキテクト

等など、必要に応じて適宜

管理者

人事管理

人材育成＇スキル管理（


17

管理者

開発チーム＇スクラム（スクラム・マスター

＇Scrum Master（支援スタッフ

リーダー

適用業務SE

アーキテクト

DBA

＇必要に応じて配置（

人事管理、業績管理

仕様確認、設計、作成、テスト、文書化、スケジュール管理

ペアプログラミング

プロジェクト関係者のファシリテーション

特定知識・スキルの提供支援

組織チーム構成例


18

アジャイル開発の為の環境

アジャイル開発チーム＇内部環境（

まず開発チームのメンバー構成は、6人～8人です。＇最大8人を超えない事（

１．チームリーダーの指名

２．スクラムマスター＇ファシリテーター（の指名

３．開発チーム支援スタッフの指名＇対象プロジェクトにより柔軟に対処（

適用業務SE、システム･アーキテクト、DBA等開発チームの不足知識、経験を補い支援するスタッフ

次にプロジェクト・ルーム＇作業場所（ですが、従来プログラマーやSE向けにブースや衝立で個人個人の作業空間を仕切られている所が多いですが、それらを全廃して、会議机の周りに8人のメンバーが着席できる配置とホワイトボード＇２～３（、PC＇開発用端末（4台で十分です。

更に開発チームのモチベーションを高める工夫は、開発チームを信頼し、自律させる事です。

スクラムマスターは開発チームのチームとしての産出量＇ベロシティー（を一定に保つ事とそのチームの生産性の向上のための環境整備を行う事とプロジェクト関係者＇プロジェクトのステークホールダー（間を開発チームのために調整する事です。

特に大事な事は顧客＇ユーザー（をプロジェクトに巻き込む＇積極的に参加させる（事です。

開発チーム支援スタッフは、あくまで開発チームの支援要請により要請を受けた内容の支援のみを行なう事です。

アジャイル開発チームの外部環境＇管理者の役割（

アジャイル開発チームが自律的に活動できる環境を整備、保全し支援を行なう。

自律的に活動できる為の支援とは、チーム･リーダー＆メンバーに気付き＇Awareness（を与えて、自主的に課題を理解把握し対処策を実行させる事で、気付きを与える以外の具体的なアドバイス＇助言（や指摘、ましてや命令＇指示（を出さない事です。

これにより開発チームは、自ら解決策を考え自主的に解決する気運が芽生えます。また顧客に提案できるエンジニア魂＇マインド（が醸成されます。この様に仕向けると品質に拘るエンジニア集団＇チーム（が生まれます。

この品質に拘り品質を向上させる事が、結果的に納期遅れを防止し、生産性の向上などプロジェクトの成功に繋がります。

具体的な指摘をしていると、開発チームは自ら考える事を止めて支持を待ち、顧客や周りの人の顔色を伺うエンドレスなプロジェクトに陥り、モラルも低下します。＇悪いスパイラル（


19

ベテラン社員のキャリア･パス

アジャイル開発では、開発チーム＇現場（が主役になり開発プロジェクトの主要な作業を自律的に実行します。従って、従来のウォーターフォールでのPM、PL、PMOや適用業務コンサルタント、システムアナリスト、システムデザイナー等々の比較的上位層のベテラン社員の役割と立場が大きく変化します。従ってこの様なベテランの処遇や新しい役割などキャリア・パスを再構成する必要があります。

ファシリテーター＇スクラムマスター（

アジャイル・アーキテクト

適用業務エンジニア＇SE（


20

開発チームの増やし方＇横展開（

開発チーム・リーダーはある程度＇10年~15年程度（のシステム開発経験者が好ましいです。他の開発チーム・メンバーは、アジャイル開発の手法を理解＇知識のみ（しているだけで特に経験の前提条件はありません。

プロジェクト途中で新規メンバーを投入してもチーム内で１ヶ月程作業を経験すればほぼ開発チームの一員としてチームの安定したベロシティー＇産出量（を維持できます。

従ってアジャイル開発チームの核となる二人のエンジニアからプロジェクトをスタートさせる事は可能です。

またプロジェクトの途中でのダイナミックな人材投入も可能ですが、原則開発チーム・メンバーは一度構成したら動かさない＇メンバーを入れ替えない（事をお勧めいたします。ある一定期間固定化することによりその開発チームのベロシティー＇産出量（が一定に保て、プロジェクトの計画立案が容易になります。

メンバーの入れ替えを行う時には、リーダーが新たなチームを編成＇メンバー全員がアジャイル新人（するか？

次期リーダー候補と中堅エンジニアのペアで新しいチームに移動させるか？＇暖簾分け（など経験者より古巣のチームから転出させていくと良いでしょう。

大規模プロジェクト＇複数の開発チームでシステムを開発（の場合は、開発チームリーダー間で情報の共有化と作業上の調整を行ないます。＇スクラム・オブ・スクラム（スクラムマスターは一人で複数チームの支援を行ないますが、規模が大きくスクラムマスター一人では手が廻らない場合には、アシスタントを準備すると良いでしょう。

スクラムマスターの育成

スクラムマスターの育成は、経験者のアシスタントなどスクラムマスターの手伝いをしながらアジャイル開発プロジェクトを支援する視点を学ぶ事が効果的です。理由は、従来のウォーターフォール型開発の経験者＇ベテラン（がスクラムマスターを演じる事が多いと思われますが、従来の経験がアジャイル開発チームの足を引っ張る事になりがちです。開発チーム支援の視点が十分身につくまで、相当の葛藤が生まれますので、スクラムマスター経験者が横に居て指導する事が育成への近道です。



チームメンバーの心構え

常にチーム全体の効率向上を意識すること

チームワークを意識する

問題・不明な点は個人で抱え込まない

受動的から能動的へ

意見は何でも発言する。

働くプログラムを優先する。

動作する事ではなく、業務を遂行できるプログラムである。

時間は有限である意識をする。

頭脳労働のムダ取りを意識する

思考停滞

思考ループ

⇒ 他者との意見交換・ペア・プログラミングを積極定期に行う

正解主義に走らず、修正ありきのスタンスで抱えこまず、常に発信・発言・提案・提供する。

22

スクラム・マスター (Scrum Master)

チームの効率を最大限に引き出す為の支援をする。

当事者視点ではなく、管理者視点でもない。

開発作業そのものには一切口出しをしない。

最悪のシナリオを常に想定し、それに対する対策案を把握していること。

問題を指摘するのではなく、気付かせる。

スタンドアップミーティングには極力参加する。

発注元とのミーティングにも参加する。

開発チーム・メンバーが気軽に意見を出せる様な場作りを心がける

開発チームが発注者＇ユーザー（からの信頼を高める様々な支援をする。

開発チームの意思決定のタイミングを外さないようにサポート＇気付き（する。


23

３．アジャイル開発チームの運営


S-0 (ステージ０) 自己管理

アジャイルの知識・技能を習得し、自己管理の為の分析力が働く開発チーム

S-1 (ステージ１) プロセスの見える化

開発チームの活動の『見える化』、活動のログを管理し改善に繋がる

S-2 (ステージ２) プロセスの安定化

顧客、システムの要求品質を理解し、その品質を満たす。＇品質への拘りがチームに出る（

S-3 (ステージ３) 学習する組織

品質、生産性、納期＇リードタイム)を意識し改善が進む学習する組織＇チーム（

S-4 (ステージ４) 自律した組織

完全に自律した問題解決適応力のある組織＇チーム（

アジャイル開発組織＇チーム（成熟度モデル指標 Agile Maturity Model

24

アジャイル開発成功の要因

経営者の理解・支援の欠如

中間管理職の揺り戻し

『・・・でも、我々は違う』と言い訳

コミュニケーションの不足と誤解

0.0% 20.0% 40.0% 60.0% 80.0% 100.0%

全体

同じ部屋

分散

オフショア

ｱｼﾞｬｲﾙプロジェクトの成功率


アジャイル開発成功のために＇KSF)

小さなチーム＇8人以下（から開始＇スタート（

開発チームを信ずる

基本理念と簡潔な手法

開発チームのコミットメント

見える化とコミュニケーション

リファクタリングの徹底

常時結合の徹底

各イタレーショーン＇反復期間（の同期

仮説を立て、提案

イタレーション＇反復（期間の長さ

４週間24%

３週間18%

２週間34%

1週間10%

1週間以内3%

７～８週間2%

8週間以上1%

５～６週間8%

8週間以上

７～８週間

５～６週間

４週間

３週間

２週間

1週間

1週間以内

アジャイル開発を阻害する重大要因

Dr.Dobb’s 2008 Agile Adoption SurveyよりDr.Dobb’s 2008 Agile Adoption Surveyより

Ｎ＝５５３


『学習する組織』の三つの構成要素

組織学習を支える環境

学習プロセスと学習行動

学習を増進するリーダー行動

組織学習を支える環境

精神的な安全

自分の仕事について、気軽に意見を明らかに出来る事が欠かせない

違いの尊重

人は反対意見の存在に気付くことで学習する。反対意見や互いに異なる価値観を認めることがエネルギーと意欲を高め、斬新な発想を呼び、無気力や付和雷同を防止する。

新しいアイデアへの寛容さ

リスクを冒し、まだ検証されていない事や未知なる物を探すように奨励すべきである。

内省の時間

多忙を極めたり、納期やスケジュールに迫られたりした事で過剰なストレスにさらされると、人の分析力や創造力は低下する。その結果、問題の原因を究明したり、経験から学習したり出来なくなる。行動の途中で立ち止まる時間を持ち業務プロセスをじっくり検討する事を奨励する。

自律した開発チームの育て方 – 学習する組織－

26

学習プロセスと学習行動

学習プロセス

情報の生成

収集

解釈

普及

After Action Review＇アメリカ陸軍の学習プログラム（の4つの質問

行動目標は何か？

実際の結果はどうだったか？

そうなった理由は何か？

次の機会では、どの様に行動すべきか？

組織内の知識を最大限に生かすには、具体的且つ体系的な方法に沿って知識を共有することが欠かせない。

内部志向のプロセス＇事後監査や検証を試み、類似する課題に取り込む（

外部志向のプロセス＇定期的な外部意見の取り入れ（

学習を増進するリーダーシップリーダーの行動は、組織学習に強い影響を及ぼす。リーダーが組織メンバー達に積極的に質問をし、彼等の声に耳を傾け、ひいてはその様に対話や

議論を促す事で、組織メンバー達は学習を奨励されていると実感できる。

問題の発見、知識の移転、内省するための事後監査などの活動に時間を割く事の重要性がリーダーから伝わってくれば、そこに勢いが付く。

また自分と異なる視点をすすんで受け入れる姿勢をリーダー達＇管理者層（が身を持って示せば、組織メンバー達も新しいアイデアや選択肢を提案しようと言う気になる。

じっくり検討することなく紋切り型を容認するのを防ぐ為に、物事を異なる切り口から捉える事、例えば次のような質問

判断基準は何か？

その様に考えたのは何故か？

他にどの様な選択肢を検討したのか？

どの様な前提＇条件（に立っているのか？

どの様な根拠に基ついているのか？


自律した開発チームの育て方 – 学習する組織－


ファシリテーション

高校野球（ウォーターフォール型）からラクビー（アジャイル型）への転換

チームの自律を促す指導＝気付き

自律＝他からの支配や助力を受けず、自分の行動を自分の立てた規律に従って正しく規制すること。カント倫理学の中心概念。自己の欲望や他者の命令に依存せず、自らの意志で客観的な道徳法則（規律）を立ててこれに従うこと。（大辞林）

管理者の姿勢• リーダーシップ＝大きな変革を促す場面• マネジメント＝安定した環境下での指導（手順化される）• ファシリテーション＝継続的に変化（改善）を推進する場面

仮説＝ある現象を理論的に統一して説明する為に立てられた経験科学上の仮定、その真偽の検証は、仮説から必然的に演繹された諸命題を実験や観察によるテストで確かめることによってなされる。検証された仮説は法則や理論として公認される。


参考資料

29

＇付録（利用者＇ユーザー（から見たアジャイル開発のメリット

顧客＇ユーザー)から見てこのアジャイル開発手法はどの様なメリットを享受できるのでしょうか？もうシステム屋の言う事は信用しないという経営者の方も多いのではないでしょうか？そうです従来の主流であるウォーターフォール型開発では米国の調査でも計画期間内、計画予算内でプロジェクトが完了した成功率は僅か１６％です。

こうなりますとシステム開発プロジェクトは失敗して当たり前と言う評価を甘んじて受けざるを得ません。アジャイル開発では、この様な失敗を回避可能です。と言いますのも、アジャイル開発とは現有リソース＇資源：人、金、時間（を前提に計画を立て実行する手法だからです。

１．プロジェクト進捗の見える化

完了した働くプログラム本数＇実現した機能の数（で管理

２．製作している機能の見える化

ユーザー用語での機能定義＇理解できる言葉での設計確認（

働くプログラムを稼動させて確認

３．絶え間ない擦り合わせ技術での品質向上

品質とは、要求品質、設計品質、実装品質、検査＇テスト（品質

４．優先、重要機能＇システム（の早期実現

システムを構成する重要機能から優先して開発

５．開発プロジェクト期間中での柔軟な変更対応

プログラム製作期間＇イタレーション（に入る前までは、変更自由

６．ユーザーが参加すべき作業の見える化


30

＇付録（アジャイル研修コース内容

１．アジャイル開発入門

コース概要：アジャイル開発プロセスの中でも基本的なXP＇エクストリームプログラミング（について、その考え方や実践項目＇プラクティス（の使い方、基本的な開発の流れを学習します。

研修のゴール： XPを適用したプロジェクト事例を元にXPの概要を理解します。

受講対象者： XP開発の基礎知識を習得したい技術者や管理者の方

難易度： ★☆☆☆☆

所要日数：１日

コースの内容： XPの概要

XPの思想

XPの戦略

XPの各プラクティス

XP開発の流れ

XP導入について

1.Planning Game(計画ゲーム)

2.Small Release(短期リリース)

3.Metaphor(メタファ)

4.Simple Design(シンプル設計)

5.TDD(テスト駆動開発)

6.Customer Test(ユーザーテスト)

7.Coding Standard(コーディング規約)

8.Sit Together(全員同席)

9.Sustainable Pace(最適ペース)

10.Continuous Integration(常時結合)

11.Collective Code Ownership(コード共同所有)

12.Pair Programming(ペアプログラミング)

13.Design Improvement Refactoring(設計改善・リファクタリング)


31

（付録）アジャイル研修コース内容

2．デザインパターン入門

コース概要：仕様変更や機能追加に強いソフトウエア設計をGoF (Gang of Four)のデザインパター

ンを基に学びます。２３のパターンの中から特に開発現場で良く使用されるパターンを取り上げ、実装コードを交えながら解説していきます。

研修のゴール：デザインパターンを適用した洗練されたオブジェクト指向設計方法を身に付けます。

受講対象者：柔軟で再利用性が高く、より洗練されたオブジェクト指向設計を習得したい技術者の方

難易度： ★★☆☆☆


コースの内容：パターン概要

デザインパターン概要

各デザインパターン詳細解説

演習問題


32

3．テスト駆動開発入門

コース概要：アジャイル開発の中でも主要なプラクティスの一つであるTDD＇テスト駆動開発（についてKent Beck氏が作成したテキストを用いて実践形式で学習します。実践はペアプログラミングで行ないます。使用言語はJava。

研修のゴール：自動化されたテストを行い、常に稼動するシステムを保つ方法を習得します。

受講対象者：オブジェクト指向によるプログラミングに通じている方、TDDを実践したい技術者の方

難易度： ★★★☆☆

所要日数：２日

コースの内容： TDD＇テスト駆動開発（の概要

JUnitの基本

TDD＇テスト駆動開発（の演習

TDD＇テスト駆動開発（の導入について



33

4．リファクタリング入門

コース概要：プログラミングからの設計改善の技術であるリファクタリングについて実戦形式で学習します。実践はペアプログラミングで行ないます。使用言語はJava。

研修のゴール：プログラミングに手を加え、見通しの良いプログラムコードへ改善する方法を習得します。

受講対象者：デザインパターンを習得済みの技術者の方、リファクタリングを実践したい技術者の方

難易度： ★★★★☆


コースの内容：リファクタリングの概要

TDD＇テスト駆動開発（との関連

リファクタリングの操作

リファクタリングの演習



34


5．スクラム（Scrum）入門

目的：アジャイル開発の一手法のScrumプロセスの概要を理解し、その実施方法を疑似体験する。

期待効果：従来のウォーターフォール型開発の手法とのアジャイル開発（Scrumプロセス）の相違点が理解できる。

プロジェクト・リーダー、開発チーム・リーダーとしてScrumプロセスの運営ができる。

ソフトウエア開発プロセスでのムダ取り、カイゼンのヒントが得られる。

アジャイル開発の導入失敗のリスクを軽減できる。

対象者：管理職、プロジェクト・リーダー、開発チーム・リーダー

学習内容：Scrumプロセス

ペアでの作業（チーム運営）

ストーリー（戦略設計）とタスク（戦術設計）

タイムボックス（イタレーション）

カイゼン活動（ムダ取り）


35

アジャイル検定のご案内

（付録）


36

＇付録（ ■ アジャイル検定の意義

近年、ソフトウェア開発に求められる要件は、より広範囲で厳しいものになっています。インターネットを初めとするIT＇Information Technology（は日常生活に不可欠なものとなり、ソフトウェアには、より多くの要件を、高品質に、より短期間で提供することが求められています。

このような環境の下、アジャイル開発手法に多くの注目が集まっています。プロセスやツールより個人とチーム内の相互作用を重視し、ビジネスニーズの変化に敏速に対応することに価値を見出す手法が、時代のニーズに合致したのです。

アジャイル開発は本来、理解しやすく、ソフトウェアを開発する「人」に重きを置く手法ではありますが、従来の開発手法とは全く違う考え方も含まれるため、誤解されがちでもあります。プロジェクトオーナー、マネージャー、メンバーがこのような誤解をしていたせいで、プロジェクト進捗方法を誤り、結果的にプロジェクトが失敗し、アジャイル開発手法に前向きに取り組んでいた人にさえよくない印象を与えることは、プロジェクトチームとアジャイル開発手法の両方にとって不幸なことです。

このような問題解決の一助として、アジャイル開発に対する正しい理解を広めるための一手段として「アジャイル検定」を制定します。この検定は、参考書籍やトレーニングコースと連動しており、アジャイル開発について正しい理解を得るにはどこに行けばよいかが分かります。また、その理解を確認するための手段としてこの検定を使うことができます。

アジャイル開発手法を採用しようとしているチームにとって、この検定は、メンバーを選定する際の一つの基準となりえます。この検定の結果を利用することで、チームは、メンバー＇候補（がアジャイル開発についての最低限の技術的な知識とプロジェクト進捗方法に対する理解、共通語彙に対する理解を持っていることを確認できます。

私たちは、このアジャイル検定をきっかけに、さらに多くのソフトウェア開発チームがアジャイル開発手法を採用し、プロジェクトを成功させる一助としていただけることを期待しています。


37

＇付録（ ■ 検定体系

アジャイル検定は以下のような認定レベルを設け、スキルを段階的に認定します。なお、各認定レベルの受験条件は下図の通りとなります。

Level 内容受験資格参考書籍

L2 後日公開予定対応するトレーニングを受講済みであること後日公開予定

L1 アジャイル開発チームのメンバーとして必要な知識を持っている対応するトレーニングを受講済みであること ※下記参照

対応するトレーニング

・アジャイル開発入門・テスト駆動開発入門・リファクタリング基礎

※Ｌ1の参考書籍

・XPエクストリーム・プログラミング入門 - 変化を受け入れる第2版

【著作】 Kent Beck 【監訳】長瀬嘉秀【出版】株式会社ピアソン・エデュケーション

・アジャイルソフトウェア開発

【著作】 Alistair Cockburn 【翻訳】株式会社テクノロジックアート【監訳】長瀬嘉秀、今野睦【出版】株式会社ピアソン・エデュケーション

・テスト駆動開発入門

【著作】 Kent Beck 【翻訳】株式会社テクノロジックアート【監訳】長瀬嘉秀【出版】株式会社ピアソン・エデュケーション

・リファクタリング - プログラムの体質改善テクニック

【著作】 Martin Fowler 【翻訳】児玉公信、平澤章、友野晶夫、梅沢真史【出版】株式会社ピアソン・エデュケーション


38

2010年1月18日＇月（～

下記URLより受付可能となります。

＜認定試験URL＞ http://www.agilecert.org/

＇付録（ ■ 受験方法


http://www.agilecert.org/

39

＇付録（ ■ 認定証

L1アジャイル太郎

L1

2009年6月1日

00000001

合格者受験合格者様へは右記認定証がPDFファイルとなりまして

メール送付されます。

不合格者不合格者様は受験後３ヶ月間は再受験できません。

事務局のご案内

アジャイル検定事務局＇株式会社テクノロジックアート内（

〒113-0033

東京都文京区本郷4-1-4 コスモス本郷ビル9F

電話：03-5803-2788 FAX：03-5803-2989MAIL: [email protected]


mailto:[email protected]

アジャイル開発概論ー管理者編ー＇手法： Scrum XP ハイブリッ … ·...

Documents

Transcript of アジャイル開発概論ー管理者編ー＇手法： Scrum XP ハイブリッ … ·...

アジャイル開発概論ー管理者編ー ＇手法： Scrum XP ハイブリッ … ·...

Documents

Transcript of アジャイル開発概論ー管理者編ー ＇手法： Scrum XP ハイブリッ … ·...

アジャイル開発概論ー管理者編ー＇手法： Scrum XP ハイブリッ … ·...

Transcript of アジャイル開発概論ー管理者編ー＇手法： Scrum XP ハイブリッ … ·...