秋のスペシャル関西例会２０１９「アジャイル開発への道案内」～経済競争力を得るための方法論～
２０１９年１１月３０日
小原 由紀夫, PMP, ｹｲﾃﾞﾝｽﾏﾈｼﾞﾒﾝﾄ社認定講師（富士通株式会社）

2019/12/11
Copyright (C) ,Masanori Kataoka. & Yukio Kohara All Rights Reserved.

11

講師紹介

⼩原

由紀夫（コハラ

ユキオ)
Kohara.yukio@jp.fujitsu.com
富⼠通シニア・アジャイリスト
プロフェッショナルサービス本部
第⼆プロフェッショナルサービス事業部

富⼠通株式会社

担当部⻑

1983年

電機・⾃動⾞の⼯場基幹システム構築の担当・ＰＭ

2000年

プロジェクトマネジャー育成

2005年

ケイデンスマネジメント社(2009PMI Best Provider)講師

2015年(株)富⼠通アドバンストエンジニアリング ⼈材開発室⻑

2017年「アジャイル開発への道案内」(⽇本PM協会編)共著

2018年

富⼠通におけるアジャイル関連ビジネスの⽴上げ・推進
アジャイルコンサルティング、⼈材育成トレーニング、アジャイルコーチ「ＩＴサービスのためのアジャイル」(⽇本ＰＭ協会編)共著

2019年

Copyright (C) ,Masanori Kataoka. & Yukio Kohara All Rights Reserved.

2

目次
１．はじめに
２．アジャイル開発の概要
３．アジャイル開発の特徴
４．アジャイル開発プロセス（XPとスクラム）
５．アジャイル開発の効果とリスク
６．上流工程を組み込んだ拡張アジャイル開発
７．アジャイル開発の事例

Copyright (C) ,Masanori Kataoka. & Yukio Kohara All Rights Reserved.

3

１．はじめにアジャイル開発方式は、今や米国におけるソフトウェア開発方式の大勢を占めるようになっている。かつての「ウォーターフォール対アジャ
イル」論争は影を潜め、議論の中心は如何にしてアジャイル開発の適用範囲を拡大していくか、に移っている。
一方、日本でのアジャイル開発の普及は遅々として進展していない。日本のソフトウェア業界は何を恐れているのであろうか？発表者達は、日本のアジャイル開発普及を加速すべく、次の書籍をまとめた。
「アジャイル開発への道案内」 片岡雅憲・小原由紀夫・光藤昭男
共著 日本プロジェクトマネージメント協会（PMAJ）編
２０１７ 近代科学社
この講演では、当書籍の紹介を通じて、アジャイル開発全般を概説
するとともに、日本でのアジャイル開発に伴う「リスク」あるいは「心配ごと」について考えたい。
（注）PMAJでは、当書籍に基づくアジャイル開発教育を計画している。
Copyright (C) ,Masanori Kataoka. & Yukio Kohara All Rights Reserved.

4

（調査）アジャイル適用率
皆さんの組織で、アジャイルを適⽤する割合はどのくらいですか︖

A 常に
B 頻繁に
C 時々
D まれに
E 使⽤しない
お隣の⽅とアジャイルの適⽤する割合に関して話してください。
（２分）

Copyright (C) ,Masanori Kataoka. & Yukio Kohara All Rights Reserved.

5

（参考）デジタル変革に関する予言• 2011年 ⽶国の著名な投資家であるマーク・アンドリーセンは「Why Software Is Eating The World」の⼿記を発表• ソフトウェアを中⼼に駆動する企業が台頭し始めており、
今後、あらゆる産業を飲み込んでいくと予⾔した
2011.8.20 ウォールストリートジャーナル

世の中で⼀番⼤きな書店 Amazon
世界で最⾼・最新の映画制作会社 Pixar
⼤規模ダイレクトマーケティングのプラットフォーム Google
最も急速に成⻑している通信会社 Skype
最も急速に成⻑しているリクルーティング会社

LinkedIn

世界で市場を制圧している⾳楽会社 AppleのiTunes
現実世界でも、WalMartやFeDexはロジスティックスと配送機能を増強するためにソフトウェアの⼒を使っている
ソフトウェアはあらゆる世界に⼊り込んで、世界を変えようとしている
Copyright (C) ,Masanori Kataoka. & Yukio Kohara All Rights Reserved.

6

（参考）ITの企業内の位置付けの変化＜これからの経営＞

ITは活動効率化の道具

ITが価値創造の中心

企画

企画

⼈・モノ・
カネ・情報
販売

⽣産

ＩＴ
(Software)
Copyright (C) ,デジタル変革＜これまでの経営＞

⼈

情報
ＩＴ

(Software)

モノ
販売
Masanori Kataoka. & Yukio Kohara All Rights Reserved.

カネ
⽣産
7

（参考）ＤＸレポート「2025年の崖」
経済産業省

http://www.meti.go.jp/shingikai/mono_info_service/digital_transformation/20180907_report.html

注）ＤＸ=デジタルトランスフォーメーション

2025年の崖の脅威︓既存システムがブラックボックス化＆データ活⽤ができない■構築後２１年以上の基幹システム ︓２割(現在)⇒６割 (2025年)（技術的負債(短期的観点で⻑期的な維持費が⾼騰)により維持管理費がＩＴ予算の9割に）2025年以降、12兆円／年の損失
2025年の崖の好機︓ブラックボックス解消＆本格的なＤＸを実⾏し、“デジタル企業”へ

2030年、実質ＧＤＰ130兆円の押し上げ対策案︵抜粋︶１. 「⾒える化」指標、中⽴的な診断スキームの構築
経営者⾃らが適切にガバナンス
２. 「DX推進システムガイドライン」の策定 経営者、取締役会、株主等のチェック・リスト
３．DX実現に向けたITシステム構築におけるコスト・リスク低減のための対応策 マイクロサービス
等の活⽤
４．ユーザ企業・ベンダー企業間の新たな関係 アジャイル開発契約ガイドライン
５．DX⼈材の育成・確保 アジャイル開発の実践による事業部⾨⼈材のIT⼈材化

経営層とアジャイルが焦点
Copyright (C) ,Masanori Kataoka. & Yukio Kohara All Rights Reserved.

8

（参考）電子政府への取り組み
1. デジタルガバメント実⾏計画
2018年7⽉20⽇ 改定（デジタル・ガバメント閣僚会議決定）「デジタル・ガバメント推進⽅針」に組み込まれた
サービスデザイン思考を具体化した、「サービス設計１２箇条」を⽰している。
https://cio.go.jp/node/2422＜サービス 設計 12 箇条＞
第１条 利⽤者のニーズから出発する
第２条 事実を詳細に把握する
第３条 エンドツーで考える
第４条 全ての関係者に気を配る
第５条 サービスはシンプルにする
第６条 デジタル技術を活⽤ し、サービスの価値を⾼める
第７条 利⽤者の⽇常体験に溶け込む
第８条 ⾃分で作りすぎない
第９条 オープンにサービスを作る
第１０条 何度も繰り返す
第１１条 ⼀遍にやらず、⼀貫してやる
第１２条 システムではなくサービスを作る

2. ⽶国連邦政府のＩＴプロジェクトでアジャイルまたはイテレイティブの割合

2011年 10％ ⇒ 2017年 80%

3. アジャイル開発を推奨するためのガイドライン
⽶国、英国、オーストラリアが採⽤。
シンガポール、ブラジルが追従
Copyright (C) ,出典︓PMNetwork by PMI
2018 February

http://www.pmnetworkdigital.com/pmnetwork/fe
bruary_2018/MobilePaged
Replica.action?pm=1&folio=46#pg48

Masanori Kataoka. & Yukio Kohara All Rights Reserved.

9

（参考）アジャイル開発の適用率
グローバルでは、もはやアジャイル開発が主流

29%

71%

出典︓PMI 第9回グローバルPM調査より
Copyright (C) ,Masanori Kataoka. & Yukio Kohara All Rights Reserved.

102.1 アジャイル開発方法論の誕生（１）アジャイル開発とは
１９９０年代の後半に、従来のプロセス重視の重い管理手法に対するアンチテーゼとして、軽量プロセスを提唱・実践する人が出始めた。
アジャイルとはこのような軽量級のソフトウェア開発方法論の総称である。そして、それらのソフトウェア開発方法論に共通する考え方や哲学を指す言葉でもある。
したがって、アジャイルに関する厳密な定義はなく、ソフトウェア開発
方法論の大きな枠を指すものといえる。
（２）アジャイルマニフェスト
アジャイル開発方法論は多様であり、一義的に定義することは困難な状況にあった。そこで、関連する人達が、2001年2月にアメリカ・ユタ州に会し、それぞれの手法の共通部分を見出すべく、議論した。 そして、その結果として合意出来たことを、アジャイルソフトウェア開発宣言（アジャイルマニフェスト）
としてまとめて発表した。
アジャイルマニフェストを次のページに示す。
Copyright (C) ,Masanori Kataoka. & Yukio Kohara All Rights Reserved.

11

２．アジャイル開発の概要（２）アジャイルマニフェスト（続き）
私たちは、ソフトウェア開発の実践あるいは実践を手助けをする活動
を通じて、よりよい開発方法を見つけだそうとしている。この活動を通して、私たちは以下の価値に至った。

プロセスやツールよりも 個人と対話 を、包括的なドキュメントよりも 動くソフトウェア を、契約交渉よりも 顧客との協調 を、計画に従うことよりも 変化への対応 を、価値とする。すなわち、左記のことがらに価値があることを認めながらも、私たちは右記のことがらにより価値をおく。
Kent Beck
James Grenning
Robert C. Martin
Mike Beedle
Jim Highsmith
Steve Mellor
Arie van Bennekum
Andrew Hunt
Ken Schwaber
Alistair Cockburn
Ron Jeffries
Jeff Sutherland
Ward Cunningham
Jon Kern
Dave Thomas
Martin Fowler
Brian Marick© 2001, 上記の著者たち
この宣言は、この注意書きも含めた形で全文を含めることを条件に自由にコピーしてよい。
Copyright (C) ,Masanori Kataoka. & Yukio Kohara All Rights Reserved.

12

（参考）アジャイル宣言の背後にある原則＜アジャイル開発を⼀⾔で＞＜アジャイル宣⾔の背後にある原則＞
原則01:顧客の満⾜を求め続ける戦略的（欧⽶＞⽇本）

原則02:要求の本質を⾒抜き、変更を前向きに

戦略的な納期を⾃ら設定する

原則03:成果物を2-3週間でリリースし続ける
原則04:全員で共通の⽬標に向かう持続的（グローバル共通）
UVCA環境変化に常に対応し続ける緊急(トラブル)対応

原則05:⼈の意欲は信頼から
原則06:顧客も開発チームも直接対話で
原則07:進捗も品質も現物で(欧⽶＜⽇本)

原則08:⼀定のペースでプロジェクトにリズムを

業務上のデットラインまでに提供

原則09:よい技術、よい設計、よい品質の追求⇒チーム⼀丸で、やるべきことをやる｡

原則10:ムダ=価値を⽣まない、を探してやめる⇒優先順位を付けて対応する。

原則11:よいモノはよいチームから⇒提供できないものについて利⽤者と協議

原則12:⾃分たちのやり⽅を毎週、調整する
参照︓「アジャイルソフトウェア開発宣⾔の読みとき⽅2018」、
IPA https://www.ipa.go.jp/files/000065601.pdf

Copyright (C) ,Masanori Kataoka. & Yukio Kohara All Rights Reserved.

13

２．アジャイル開発の概要
2.2 代表的なアジャイル開発技法

表2.1 代表的なアジャイル開発技法

技法名称

発案者

概要

XP(eXtreme Programming)

Ward Cunningham,
Kent Beck,
Ron Jeffries
Ken Schwaber,
Jeff Sutherland,
Mike Beedle

比較的少人数の開発に適用。5つの価値と12の具体的プラクティスを定義

Scrum（スクラム）

CrystalAlistair Cockburn

ASD(Adaptive Software
Development)

Jim Highsmith

FDD(Feature Driven
Development)

Jeff De Luca,
Peter Coad
Stephen R. Palmer,
John M. Felsing

DSDM(Dynamic Systems
Development Method)

DSDM Consortium
Copyright (C) ,プロジェクト管理技術が中心。開発途中で、顧客は要求を変更可、素早い対応のためのチーム能力最大化が主テーマチーム内のコミュニケーション重視、高頻度のリリース、自動テスト、構成管理
開発環境、開発条件は常に変化する、
それに適応(Adapt)していく開発
Featureとは顧客価値に基づく機能性、
シンガポール銀行での開発経験、
Object Modeling技法が基礎

DSDMは、British Air, AMEX, Oracle等によるコンソーシアム、固定された予算と工期の範囲で、優先付けされた機能を開発
14
Masanori Kataoka. & Yukio Kohara
All Rights Reserved.

３．アジャイル開発の特徴
3.1 アジャイル開発とウォーターフォール開発の比較
表3.1 ソフトウェアエンジニアの理解と利用のレベル(注）Cockburnが提案したものに、Boehm等が改定を加えたもの
レベル

特徴

3

先例のない新しい状況に適合するために、（ルールを破ってでも）手法を改定することができる。

2

先例のある新しい状況に適合するために、手法をカスタマイズできる。

1A

トレーニングを受ければ、手法の手順のうち自由裁量の部分を遂行できる（例えば、インクレメントに応じた開発ストーリーの調整、パターンの開発、リファクラリング、パッケージの活用・統合等）。経験を積めばレベル2になれる。

1B

トレーニングを受ければ、手法の手順のうち手続き的な部分を遂行できる（例えば、単純なメソッドのコーディング、簡単なリファクタリング、コーディング
標準や構成管理基準への準拠、テストの実行等）。経験を積めば、レベル1Aに
なれる。

‐1

技術的スキルは持ち合わせているかもしれないが、協調したり共通の手法に従ったりできない（あるいはしたがらない）。
Copyright (C) ,Masanori Kataoka. & Yukio Kohara All Rights Reserved.

15

３．アジャイル開発の特徴
表3.2 アジャイル開発とウォーターフォール開発を特徴つける５つの主要因
要因
アジャイル
ウォーターフォール規模

小規模な製品、チーム向け。暗黙知に依存しているため大規模化は困難。

大規模な製品、チーム向け。小さなプロジェクト用に切り詰めるのは
困難。

重要度

安全性が重視される製品への適用例はない。設計がシンプルで文書が少ないことが前提。

重要度の高い製品向けに進化した手法である。重要度の高くない製品用に切り詰めるのは困難。

変化の度合い変化の度合いが高い環境で、設計をシンプルにして継続的にリファクタリングしていく。

安定した環境で事前の大きな設計(Big Design Up Front)を実施する。
不安定な環境ではやり直しのコストが高くつく。

人

レベル2,3の熟練者が開発期間を プロジェクトの初期段階ではレベ
通じて十分な割合で必要。レベル ル2,3の熟練者が必須。後期の段
1Bのアジャイルに慣れていない
階では、レベル1Bの人も使える。
人を使うことによるリスクは高い。

文化

高い自由度を持つことで、快適で権限が与えられていると感じられる文化で繁栄する。
（カオスにおける繁栄）。
Copyright (C) ,明確な方針と手続きで自分の役割が定義されていることを感じられる文化で繁栄する。
（秩序における繁栄）。

Masanori Kataoka. & Yukio Kohara All Rights Reserved.

16

３．アジャイル開発の特徴

人の質(1Bの割合％） (2,3の割合％）

自
由
裁
量
の
資
金

重要度（欠陥による損失）

多
数
の
生
命

一
人
の
生
命

貴
重
な
資
金

４０

１５

３０

２０

２０

２５

１０

３０

快
適 ０

３５

変化の度合い（月当りの変更
回数 ％）

１０
５０

３
１０
３０

１００

９０

５

１

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

７０
５０
３０

３００

１０

文化（カオスの度合い％）

規模（人数）

図3.1 アジャイル開発とウォーターフォール開発
かの選択要因Copyright (C) ,Masanori Kataoka. & Yukio Kohara All Rights Reserved.

17

３．アジャイル開発の特徴（１）アジャイル開発の基本理念
アジャイル開発の基本理念は、システム全体を一括して開発するのではなく、小さな単位に分割し、段階的に積み上げていくことにある。
－時間（開発期間）を分割する－機能（開発対象機能）を分割する－対象機能を開発期間に割り当てる（ビジネス優先順位順）
ことを行なう。結果として、アジャイル開発は表3.3に示すような8つの特徴を持っている。
（２） 自動化ツールの高度に活用
アジャイル開発における自動化ツールの活用を表3.4に示す。
① 作業効率を向上させ、作業の正確性を改善させることが出来る。
② また、自動化ツールは各種の作業管理指標を自動収集し、図表などの分かり易い形式で集計してくれる。
③ 代表的なアジャイル開発技法の一つであるXPにおいては、コード分析・評価ツール、継続的インテグレーションCIツール、単体テスト支援ツール 等の活用をXPの標準プロセスの中に組み込んでいる。
Copyright (C) ,Masanori Kataoka. & Yukio Kohara All Rights Reserved.

18

３．アジャイル開発の特徴
表3.3 Agile開発技術の特徴
分類

項番

特徴

ビジネス
優先順位

１

重要度の高い機能から優先的に開発する

時間分割

２

動くソフトウェアで顧客と確認（ドキュメント量を最小限に）

３

反復型開発期間＝タイムボックス（開発期間を固定化）

４反復型開発期間を固定するが開発項目は固定しない

５

開発対象機能の分割（一つの反復型開発期間内に収まるように分割）

６

すべての作業をチケット管理する

７

顧客、チームメンバー間の直接対話

８

自動化ツールの高度に活用

機能分割

その他

Copyright (C) ,Masanori Kataoka. & Yukio Kohara All Rights Reserved.

19

（参考）コストと期間を固定し要件を可変にする
ウォーターフォール

アジャイル

要件
要求

固定

効果
コスト
⾒積り
提供
リスク

期間

開発視点
機能視点（全ケース）
脅威(曖昧性)を減少

コスト

どのくらい
できるか
⾒積もる

期間

投資

価値
要件(スコープ)

ビジネス視点
業務視点（限定可）＋好機(曖昧性)を活かす
参考︓「アジャイルソフトウェア要求」 Dean Leffingwell著 2014年

Copyright (C) ,Masanori Kataoka. & Yukio Kohara All Rights Reserved.

20

３．アジャイル開発の特徴
表3.4 アジャイル開発の各工程で活用される自動化ツール
Agile開発工程名
コーディング

自動化ツール分類
変更歴管理ツール、バージョン管理ツール

具体的な自動化ツール（例）CVS, Subversion, Git, GitHub

ビルド

ビルドツール、
構成管理ツール

ANT, Maven, Gradle

統合（CI）

CI(Continuous Integration)ツール

Jenkins

単体テスト
単体テスト支援ツール
コードレビュー、リファク コード分析・評価ツール
タリング

JUnit
Checkstyle, PMD, FindBugs,
Jtest, PMD‐CPD, JDepend,
JavaNCSS, Covertura

機能テスト、
GUIテストSelenium2

GUIテスト支援

システムテスト（クラウド システム環境設定・管理上のテストを含む）
ITS (Issue Tracking System)
工程全般

Copyright (C) ,puppet, Chef
Trac, Redmine

Masanori Kataoka. & Yukio Kohara All Rights Reserved.

21

（参考）狩野モデル
満⾜

仕⽅ない

気にいる
気にいる

魅⼒的品質
魅⼒品質
充⾜

不充⾜
⼀元的品質

当たり前品質当たり前
当たり前
気にいらない気にいらないCopyright (C) ,不満⾜

参考︓「アジャイル開発への道案内」⽚岡雅憲、
⼩原由紀夫、光藤昭男著 2017年, P53

Masanori Kataoka. & Yukio Kohara All Rights Reserved.

22

（演習＃１）アジャイル開発への疑問
アジャイル開発に対する懸念・疑問を挙げて下さい。
１．懸念・疑問のキーワードを以下の余⽩に記⼊してください。
(２分）
２．お隣の⽅と記⼊した懸念・疑問に関して話してください。
（２分）

Copyright (C) ,Masanori Kataoka. & Yukio Kohara All Rights Reserved.

23

４．アジャイル開発プロセス（XPとスクラム）
4.1 XP（１） XPとはXP(eXtreme Programming)とは、良いと思われるもの・ことを極限(extreme)まで行い、不要と思われるもの・ことは一切行わないプログラム開発手法である。
XPは、代表的なソフトウェアアジャイル開発手法の一つとしてとらえられている。
（２） XPの提唱者
次の3人が共同で、XPを提唱した。
Ward Cunningham - the inventor (発案者)
Kent Beck - the articulator (表現者)
Ron Jeffries - the realizer (実現者)
上記のうち、Kent Beckが表面にたつことが多いため、XPは、Kent Beck個人によるものと誤解している人が多い。
Copyright (C) ,Masanori Kataoka. & Yukio Kohara All Rights Reserved.

24

４．アジャイル開発プロセス（XPとスクラム）（３） XPの実践（プラクティス）
XPで実践すべき項目（プラクティス）として、次の12項目がある。
P-1. きめ細かなフィードバック－ペアプログラミング－計画ゲーム－テスト駆動開発－チーム全体P-2. 継続的プロセス－常時結合－リファクタリング－短期リリース

P-3. 理解の共有－コーディング標準－コードの共有－シンプル設計－システムメタファー
P-4. 労働時間－継続可能な作業ペース

以下では、上記のうち、テスト駆動開発、常時結合、継続可能な作業
ペース について、更に詳細を説明する。
Copyright (C) ,Masanori Kataoka. & Yukio Kohara All Rights Reserved.

25

４．アジャイル開発プロセス（XPとスクラム）（４） テスト駆動開発（TDD：Test Driven Development）
TDDではテスト仕様を先に記述し、そのテストに合格する様にコーディングをする。（TDDは、テスト法ではなく開発法である、としている）
TDDのキイワード：
テスト
Red/Green/Refactor―最初はテストだけなので不合格（赤）、コードを書いてテストに合格（緑）、そしてそれを磨いてきれいにする（リファクコンパイル
タリング）。
―Test a little/Code a little/ Refactor a little(少しづつ着実に進む)＝＞テストを繰り返し実施する必要があり、テストの自動化が、必須である(xUnitとセットで発展）（注）TDDを、”Test First Programing”と呼ぶ場合もある
Copyright (C) ,動作

リファクタリング
図4.1 TDDの概念図

Masanori Kataoka. & Yukio Kohara All Rights Reserved.

26

４．アジャイル開発プロセス（XPとスクラム）（５） 常時結合(Continuous Integration)
CIサーバは、ソースコード管理リポジトリ、ビルドツール、リグレッ
ションテストツール他と連動する。
フィードバック手段
プラベート
ビルド

開発者

結果をフィー
ドバック

変更を
コミット

監視

変更を
コミット

ツール類を
起動、結果
を得る

開発者
変更を
コミット

開発者

バージョン管理リポジトリ（ソースコード
管理リポジリ）CI サーバー（インテグレーションビルドマシーン）

ビルドスクリプト‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐

・ソースコードのコンパイル
・DB のインテグレーション・リグレッションテスト
・インスペクション・ソフトウェアのデプロイ

図4.2 CI サーバの動作環境（参考文献１１））（注） 開発者は各々がプライベートビルドを実行、結果が正しいことを確認した上でバージョン管理
リポジトリに変更をコミットする。CI サーバは、これを監視していて、ビルド他のプロセスを自動実行する。
Copyright (C) ,Masanori Kataoka. & Yukio Kohara All Rights Reserved.

27

４．アジャイル開発プロセス（XPとスクラム）（６） 継続可能な作業ペース① 適正な作業時間により、良好な作業ペースを維持することが大切である。疲れていては最善のことは出来ない。結果として、混乱が生じ、生産性を落とす。
② したがって、最適なペースを維持できるように作業計画を立てて、その計画を守っていくことが大切である。このことは、作業を安易にしようとすることではなく、作業を効率良く進めようとの発想に基づいて進めるものである。
③ アジャイル開発では、反復型開発期間ごとに開発内容を調整しながら開発を進める。したがって、作業対象項目と作業時間との関係を調整し易い。
④ 米国における統計では、アジャイル開発チームの残業時間の平均は、ウォターフォール開発チームそれよりも少ない。

Copyright (C) ,Masanori Kataoka. & Yukio Kohara All Rights Reserved.

28

４．アジャイル開発プロセス（XPとスクラム）
4.2 スクラム（１） 新製品開発方法論としてのスクラム製品開発の動きが早く、競争率が高い今日の世界では、速度と柔軟性が重要である。従来の直線的な方法では仕事を成し遂げることができず、ラグビーにおいてチー
ム内でボールをパスしながらチームが一群となって動くというような方法が必要である。日本や米国の先進的企業では、このような全体論的な開発方法を用いるようになってきている。この考え方に基づく開発方法をスクラムと名付けた。

by 竹内弘高、野中郁次郎“The New New Product Development Game” Harvard Business
Review, January-February 1986 pp.137-146（２） システム開発方法論としてのスクラム
Ken Schwaber とJeff Sutherland は、この考え方をシステム開発方
法論「スクラム」へと、発展させ、１９９５年のOOPSLA’95で、初めて公的に発表した。 また、Ken SchwaberとMike Beedleは、これを次の著書にまとめた。“Agile Software Development with Scrum”（監訳）長瀬嘉秀/今野睦、（編集）株式会社テクノロジックアート、（出版）ピアソン・エデュケーション、2003年9月（原著は、２００１年に出版）
Copyright (C) ,Masanori Kataoka. & Yukio Kohara All Rights Reserved.

29

４．アジャイル開発プロセス（XPとスクラム）（３） スクラムの構成要素とその流れ
表4.1 スクラムのフレームワーク構成要素

構成要素
内容
詳細要素
ス ク ラ ム プロダクトを反復的・漸進的に届ける ・プロダクトオーナー
・開発チームチーム
チームである。
・スクラムマスター
・プロダクトバックログ
作成物
作業や価値を表したものである。
・スプリントバックログ
・インクリメント
イベント
透明性を維持し、検査・適応の機会で ・スプリント
・スプリントプラン二ングある。
・デイリースクラム・スプリントレビュー
・スプリントレトロスペクティブ
ルール
スクラムチームとその役割・イベント・ 全体で説明。
作成物をまとめ、それらの関係性や相互作用を統括するものである。
Copyright (C) ,Masanori Kataoka. & Yukio Kohara All Rights Reserved.

30

４．アジャイル開発プロセス（XPとスクラム）

図4.3 スクラム構成要素の流れ
Copyright (C) ,Masanori Kataoka. & Yukio Kohara All Rights Reserved.

31

４．アジャイル開発プロセス（XPとスクラム）（４）インセプションデッキ（プロジェクト憲章に相当）
表4.2 インセプションデッキの10の質問と課題
質問と課題
目的
1

我々はなぜここにいるのか？

2

エレベーターピッチ(elevator pitch) プロジェクト、プロダクトの概要を短時間を作る
で明確に説明する3

パッケージデザインを作る

プロダクトの価値を明確にする

4

やらないことリストを作る

プロジェクトのスコープを明確にする

5「ご近所さん」を探せ

ステークホルダーを明確にする

6

技術的な解決案を描く

アーキテクチャを具体化する

7

夜も眠れなくなるような問題は何だ リスクを明確にする
ろう？

8期間を見極める

スケジュールを明確にする

9

何を諦めるのかをはっきりさせる

QCD、スコープの優先順位を明確にする

10

何がどれだけ必要かリソースを明確にする

Copyright (C) ,プロジェクトの目的を明確にする

Masanori Kataoka. & Yukio Kohara All Rights Reserved.

32

４．アジャイル開発プロセス（XPとスクラム）（５） スクラムで使われる用語について（注意）
スクラムには、特徴的な用語が多い。日本国内のアジャイル開発では、XP の用語が使われることが多い。
スクラムの用語

一般的な用語意味スプリント

イテレーション

繰り返しの開発期間、リリース計画

プロダクトバックログ

ストーリー

顧客が選択する製品の機能を整理したもの

スプリントバックログ

タスク（チケット）

開発チームが実施する作業

スクラムマスター

アジャイルマスター

アジャイルプロセスのファシリテータ

Copyright (C) ,Masanori Kataoka. & Yukio Kohara All Rights Reserved.

33

５．アジャイル開発の効果とリスク
5.1 アジャイル開発により期待される効果
アジャイル開発では次の観点から著しい改善効果があげられる。
（１） 顧客満足度の向上
顧客が開発に深く関与し、顧客満足度の向上に寄与している。
（ⅰ） 開発計画への顧客の参加、機能の開発優先度を顧客が指定（ⅱ） 短期開発により動作するソフトウェア機能を早期に顧客へ提供（ⅲ） 顧客による受け入れテスト（２） 開発期間の短縮
アジャイル開発は、開発期間を二つの観点で短縮する。
（ⅰ） 全体開発期間（開発開始から全体機能のリリースまで）の短縮（ⅱ） 優先度の高い機能の早期提供による実質効果上の短縮（３） 開発効率の向上（ⅰ） ソフトウェアを早期に動かして理解を深める。
（ⅱ） 分からないこと、新しいことを理解するために、仲間の知恵を借りる。このための、5～15分程度の短期の打ち合わせを頻繁に行う。
（ⅲ） 自動化ツールを活用して自動化する。
Copyright (C) ,Masanori Kataoka. & Yukio Kohara All Rights Reserved.

34

５．アジャイル開発の効果とリスク（４） 製品品質の改善
アジャイル開発では製品品質の確保の観点から次の施策を実施している。
（ⅰ） 単体テストの徹底（ⅱ） 顧客テストの徹底

すなわち、アジャイル開発では、内部部品の積み上げである単体テストと顧客へのリリース機能に基づく外部機能の２通りのテストを行っていく。そして、これらのテストは開発と共に積み上げられ、再テストは自動化されて品質を保証していく。アジャイル開発での品質管理はテ
スト資産の着実な積み上げと、そのための自動化に支えられている。
（５） 参加メンバーの技量の向上
アジャイル開発チームでの働き方の基本は「自主独立」である。各メンバーは自分で考え、自分で開発し、誰かの指示や、命令で開発するのではない。同じチーム内の他のメンバーの助けを借りることはでき
るし、逆に、他のメンバー作業を支援することもある。しかし、他のメン
バーから指示を受け、他のメンバーに指示をすることはない。各々のメンバーは独立であり、自分で自分の仕事を行う。
Copyright (C) ,Masanori Kataoka. & Yukio Kohara All Rights Reserved.

35

５．アジャイル開発の効果とリスク
5.2 アジャイル開発における開発リスクへの対応
アジャイル開発は従来開発の延長線上にはない。飛躍が必要。
表5.2 アジャイル開発のリスク
項番

アジャイル開発のリスク

１

アジャイル文化の継承なし

チームにアジャイル開発の経験者がいない

２

顧客の参加なし

具体的な要求仕様を顧客から直接に聴けない

３

ドメインモデルと用語集なし

設計仕様の基礎が固められていない

４

機能分割が不十分機能（ユーザーストーリー）分割が不十分で、
小規模くり返し型開発が出来ない

５

一つの部屋で作業できない

チーム全体が一つの部屋でまとまって作業できない

６

チケットによる進捗管理をしていない

チケットを用いたITS(Issue Tracking System)が、アジャイル開発の進捗管理に必須

７

自動化ツールの活用が不十分

アジャイル開発では自動化ツールの積極的活用が前提

８

大規模ソフトウェア開発への 大規模ソフトウェア向きのアジャイル開発が確適用立されていないCopyright (C) ,説明

Masanori Kataoka. & Yukio Kohara All Rights Reserved.

36

５．アジャイル開発の効果とリスク（１） チームにアジャイル開発の経験者が不在
アジャイル開発を始めるに当たっては、開発チームの中にアジャイ
ル開発の経験者がいることが望ましい。ウォーターフォール開発とアジャイル開発との間にあるギャップを乗り越える必要がある。
－文化的ギャップ（アジャイル開発の「自主」、「試してみる」精神）－技術的ギャップ（アジャイル開発で「標準化」、「自動化」がMust）（２） 顧客の参加なし
アジャイル開発では、チームへの顧客の参加が前提になっている。
① 業務仕様は顧客が一番知っている② ドキュメントによりこれを伝えるには膨大な記述工数がかかる。
③ 開発したソフトウェアを顧客にすぐに見てもらいFBしてもらう。

日本では対米国比、顧客側にIT技術者が少ないという問題がある。
（３） ドメインモデルと用語集なし
システムの概念やオブジェクト名称が決まっていないと、ソフトウェ
アの開発はうまく進まない。これは、アジャイル開発だけでなくウォー
ターフォール開発においても言える。開発に当たっては、ドメインモデ
ルとこれにリンクした用語定義集を作成しなければならない。
Copyright (C) ,Masanori Kataoka. & Yukio Kohara All Rights Reserved.

37

５．アジャイル開発の効果とリスク（４） 機能分割が不十分
アジャイル開発では、開発項目をユーザストーリーと呼ばれる小機能に展開し、作業管理対象としていく。ウォーターフォール開発においても機能分割が必要である。
しかし、アジャイル開発での機能分割では、その分割したそれぞれを短期間のうちに動作させなければならない。
アジャイル開発では、各リリース対応の大きな機能分割をし、そのリリース対応の開始時点で反復開発期間毎の小さな機能に分割する。

（５） 一つの部屋で作業できない
アジャイル開発では、チームメンバー全員がフェースツフェースでコミュニケーション
できる環境で作業する。このことを前提に小規模な非公式ミーティングを頻繁に行い、また、ドキュメントの量を減らしている。

（６） チケットによる進捗管理をしていない
アジャイル開発では、高速開発での正確な作業管理のためにすべての開発項目（
ユーザストーリー）にIDを付ける。ユーザストーリーに展開されない非機能項目であっても、その調査、検討に時間を取られるのであればIDを付ける。すなわち、すべての作業にIDを付ける。IDのない作業は、プロジェクトとして認められていない非公式の作業となる。
Copyright (C) ,Masanori Kataoka. & Yukio Kohara All Rights Reserved.

38

５．アジャイル開発の効果とリスク（７） 自動化ツールの活用が不十分
アジャイル開発では自動化ツールを積極的に活用することが当たり前になっている。そして、アジャイル開発では、自社固有のツールは殆ど使わない。オープンの世界から外部調達する。しかも、大半のツールはOSS(Open Source Software)であり、無料で調達できる。例えば、表3.4 に紹介した自動化ツールはすべてがOSSである。

（８） 大規模ソフトウェア開発への適用
アジャイル開発は、提案され始めた当初は小規模なシステム開発に適用されてきた。大規模なシステム開発では、過去の文化の慣性が強く、アジャイル開発の適用はなかなか進まなかった。このために、アジャイル開発は小規模システム開発のプロ
グラミング工程以降を主たる対象としてきた。
しかし、工期短縮、開発効率向上の観点から、アジャイル開発へのニーズは高く、大規模システム開発への適用が検討され、その成果が出てき始めている。具体的には、要求分析・定義、概念設計、等の上流工程へのアジャイル開発の適用が検討されるようになってきている。このような新しい流れについては、次の６章で解説する。

Copyright (C) ,Masanori Kataoka. & Yukio Kohara All Rights Reserved.

39

６．上流工程を組み込んだ拡張アジャイル開発
表6.1 上流工程を組み込んだAgile開発技法
Agile開発技法名称
開発・提案者
概要
Agile Modeling (AM)

Scott Ambler

Agile ICONIX

Doug Rosenberg

ScaledFramework(SAFe)

Agile Dean Leffingwell

Copyright (C) ,AMは、軽量な設計方法を提案している。設計法
自体は既存のものから選択して用いる。AMはそれを軽量に、短期間で用いる方法を提案している。AMは、設計方法のみを提案していて、実際の開発ではAMとXP、RUPなどと組み合わせて使う。
ICONIXは、オブジェクト指向ベースの開発法であり、ユースケースを系統的に変換してコードを得る。上流工程での曖昧性を早期に取り除くのが特徴である。Agile ICONIXは、それをアジャイル
化したもの。XPを強く批判していて、XPの悪いところを補ったアジャイル技法を目指している。
①単独チームによるアジャイル開発から、②複数チームによるアジャイル開発、③企業ポートフォリオレベルのアジャイル開発
へとスケールアップしていく方法を提唱する。その中で、ART(Agile Release Train)、アーキテクチャ
滑走路(Architectural Runway)などの大規模システムのためのアジャイル技法を提案している。

Masanori Kataoka. & Yukio Kohara All Rights Reserved.

40

６．上流工程を組み込んだ拡張アジャイル開発（１）SAFeSAFe(Scaled Agile Framework)とはSAFeとは、名前の通り、小規模システム開発向けとみなされてきたアジャイル開発技法を、大規模システム開発向けに拡張した技法である。SAFe開発・普及活動のリーダーであるDean Leffingwellは、一貫して大規模システム開発領域で活動してきた。
（２）スケールアップ可能なアジャイルプラクティス
Leffingwellは、大規模システムにもスケールアップが可能なプラク
ティス7件と大規模システムアジャイル化特別プラクティス7件を抽出した。スケールアップ可能なプラクティスは下記の通りである。
① 定義/ビルド/テストコンポーネントチーム② 2 レベル計画作りと追跡③ 反復型開発の習得④ 頻繁な小規模リリース⑤ コンカレントテスティング⑥ 継続的インテグレーション⑦ 継続的な考察と適応
Copyright (C) ,Masanori Kataoka. & Yukio Kohara All Rights Reserved.

41

６．上流工程を組み込んだ拡張アジャイル開発（３）大規模システムのアジャイル化のための特別プラクティス① 意図的なアーキテクチャ（アーキテクチャ滑走路（Architectural Runway））② リーン要求開発のスケールアップ－ビジョン：開発構想、共通フィーチャー
－ロードマップ：個別フィーチャーをリリース計画に展開－ジャストインタイムの詳細化：ユーザーストーリーなどで展開③ システムオブシステムとアジャイルリリーストレイン－アジャイルリリーストレインART(Agile Release Train)（すべてのコンポーネントのリリース日程を同期化）④ 高度に分散したチームの管理－インスタントメッセージ、Eメール、カンファレンスルーム－CI(Continuous Integration)ツール⑤ 顧客とオペレーションへのインパクトの調整⑥ 組織を変化させる－トップレベルの決断、トップの説得⑦ ビジネスパフォーマンスを計測する
Copyright (C) ,Masanori Kataoka. & Yukio Kohara All Rights Reserved.

42

６．上流工程を組み込んだ拡張アジャイル開発
アジャイル開発とポートフォリオ・プログラムマネジメントを連携させたフレームワークを実践した事例が多数発表されている。経営層とチームが連動。
Scaled Agile Framework
ポートフォリオレベル︓
経営陣の戦略的な投資判断に基づいて企画を⾏います。
プログラムレベル︓
企画に対して複数チームで開発する計画を⽴案し、プロダクトとして同期してリリースします。

チームレベル︓
チームが分担した要求を5-9名のチームでプロダクトを開発します。

Copyright (C) ,Masanori Kataoka. & Yukio Kohara All Rights Reserved.

43

（演習＃2）アジャイル開発への疑問の見直し
P23で挙げた、アジャイル開発に対する懸念・疑問を⾒直して下さい。
１．P23の懸念・疑問のキーワードを分類して下さい。
・ 懸念・疑問が解消した。（×、横線を引いて下さい）
・ 懸念・疑問が残っている（そのままにしてください）
２．新たな懸念・疑問を追加して下さい。
３．お隣の⽅と上記に関して話してください。

Copyright (C) ,Masanori Kataoka. & Yukio Kohara All Rights Reserved.

44

７．アジャイル開発の事例
７．１ アジャイル開発事例の説明方法（１）事例一覧
事例

利用者

P.O.

開発チーム

特徴
多様なチームの共創による新たなサービス構築事例 新しいサービス プロ野
球球団
１ の共創

大手ＩＴベンダー

事例 新しい業務へ
２ の挑戦

一般
住民

自治
体

大手IT
業務ノウハウを活用した開発によるベンダー 新たな業務の実現

事例 請負開発での
３ 導入

社員
等

顧客
企業

独位系IT 開発ノウハウの活用と顧客の参加のベンダー 喚起による請負開発での導入

事例 米国ﾊｲﾌﾞﾘｯﾄﾞｱ
４ ｼﾞｬｲﾙ

社員

顧客
企業

ｸﾞﾛｰﾊﾞﾙ 大規模チームへのハイブリッドアジャ
ベンダー イルの導入

消費者

社長

Copyright (C) ,Masanori Kataoka. & Yukio Kohara All Rights Reserved.

５

新商品開発

社員

３５年間継続のＩＴ以外の新製品開発

45

７．アジャイル開発の事例（１）事例におけるアジャイルの特徴の実践
質問視点

事例１

事例２

事例３

事例４

事例５

高重要度から
優先開発

チームで議論

機能、業務の両面から設定顧客と価値を掘り起こす基盤となる機
能を優先

注力事業を優先動くソフトで顧客と確認称賛をフィード
バック

利用者との協調体感と連動させた

領域毎の利用者代表が参加試作品で確認開発期間を固定化

２週間＋スプリント０

２週間（初回
のみ４週間）

２週間

３週間

開発項目は固定しない

Ｐ．Ｏの一貫した優先付け

10ｲﾃﾚｰｼｮﾝまでに基本機能試使用スプリントを活用

20%を可変とし フィードバック
たに対応

開発対象機能の分割

リーダーの自律的分割業務と処理・
操作で分割

チーム全員での計画

全員での計画立案伴走方式で対応

全作業を
チケット管理５つのステー
タスで管理

プロセスとツールを連動ﾀｽｸﾎﾞｰﾄﾞ+ﾊﾞｰ
ﾝアップﾁｬｰﾄ

PMOが管理チームで管理顧客、チームの直接対話

定期的なメー
ティング実施検証イテレー
ションを設定試使用結果のフィードバック

非公式に利用者代表と会話プレゼン会議で社長確認自動化ツールの高度に活用Ａｔｌａｓｓｉａｎの適用

Git, Jenkins,
Redmine等

Redmine,TestLink等

ﾊﾞｰﾝﾀﾞｳﾝﾁｬｰ
ﾄ

ＴＶ会議を活用ドキュメント量を最小限にＡｔｌａｓｓｉａｎのWikiを活用

運用・保守
ﾌｪｰｽﾞを分離

受託契約に従うｳｫｰﾀｰﾎｰﾙ開発規約を準拠

１枚のみ

Copyright (C) ,Masanori Kataoka. & Yukio Kohara All Rights Reserved.

１週間(35年間継続)46

７．アジャイル開発の事例
７．２ 新しいサービスの共創（１）概要目的
プロ野球の価値を高める。（映像提供、選手の価値）
サービス プロ野球ファン、プロ野球球団向けの新たな野球映像ソリューション
時期

２０１５年４月プロジェクト開始、２０１６年５月サービス提供

体制

２０名／６社（デザイン、技術、マネジメントの各専門家）、３チーム

開発環境 ＣＩ環境＠渋谷シェア・オフィス推進方法 ２週間のスプリントを推進、一部の遠隔メンバーと協働

プロ野球球団
編成・選⼿・監督・コーチ向け
選⼿向けアプリ

編成・監督・コーチ向けアプリ

野球サービスプラットホーム
Copyright (C) ,野球映像検索API

Masanori Kataoka. & Yukio Kohara All Rights Reserved.

47

７．アジャイル開発の事例
（２）体制

デザイン
• 洗練された
ＵＩ／ＵＸ• クラウド技術• モバイルアプリ• 動画再⽣• アジャイル• 品質管理技術

マネジメントCopyright (C) ,Masanori Kataoka. & Yukio Kohara All Rights Reserved.

48

７．アジャイル開発の事例（４）推進スプリント１

スプリント２

スプリント３

スプリント計画

開発・要件確認
・タスク上げ、⼯数⾒積り・発スケジュール検討

・朝会／⼣会・ミーティング・リーダーレビュー

Copyright (C) ,

・・・
リリース

・動くソフトウェアをリリース
・オーナーによるレビュー
・ふりかえりMasanori Kataoka. & Yukio Kohara All Rights Reserved.

49

７．アジャイル開発の事例
７．３ 新しい業務への挑戦
（１）概要
目的

区民をできるだけ庁舎内を歩かずに効率的に用件を済ませる窓口の提供

サービス

複数の手続きを短時間で効率よく済ませられるサービス時期

２０１３年２月プロジェクト開始、２０１４年２月サービス提供

体制

利用者： 名／ 部門（豊島区役所）
開発チーム：５名／１チーム（富士通株式会社）

開発環境 ＣＩ環境＠富士通開発センター
推進方法 ２週間のイテレーションＸ２５回（1年間）
初回のイテレーション完了時から「動くソフトウェア」を提供

７５％の区民の満足度が2倍、不満が３分の１にCopyright (C) ,Masanori Kataoka. & Yukio Kohara All Rights Reserved.

50

７．アジャイル開発の事例（２）新たな業務
受付・交付

⼊⼒・検査
区⺠課

国保課

⼦育て⽀援課

⾼齢者医療年⾦課

Copyright (C) ,区民が歩かずに、効率的に用件を済ませる

従来業務＜新たな業務＞
受付・交
付

⼊⼒

区⺠課

検査・検定

国保課

⼦育て⽀援
課

⾼齢者医
療年⾦課

Masanori Kataoka. & Yukio Kohara All Rights Reserved.

51

７．アジャイル開発の事例（３）利用者と共創するイテレーション
ｲﾃﾚｰｼｮﾝ5

ｲﾃﾚｰｼｮﾝ6「窓⼝受付」
を評価

利⽤者「受付状況」を評価「窓⼝受付」と「本⼈確認」
を評価

計画「受付状況」
を開発「受付状況」のFB対応「本⼈確認」
を開発

計画

開発
チーム

ｲﾃﾚｰｼｮﾝ8「窓⼝受付」
のFB対応

計画

計画

「窓⼝受付」
を開発

ｲﾃﾚｰｼｮﾝ7「追加項⽬⼊⼒」

を開発

Copyright (C) ,Masanori Kataoka. & Yukio Kohara All Rights Reserved.

52

７．アジャイル開発の事例（４）チケット管理の流れとツール
チケット
起票

コミット

分散
開発

⾃動
テスト

プッシュ

(ローカ
ル)

(リモート)

⾃動
デプロイ

サーバ
(ノートPC)

ローカル
リポジト
リ

タスク管理ツール
Redmine共有
リポジト
リ分散バージョン管理ツールGit

Copyright (C) ,

リポジト
リ
(コピー)

CIツールJenkins

Masanori Kataoka. & Yukio Kohara All Rights Reserved.

53

７．アジャイル開発の事例
７．4 請負開発でのアジャイル開発の導入
（１）概要
目的

「ソフトウェア技術を通じて、社員と家族、そして関係するすべてのお客様の幸せを追求する」（ＡＳＥ社経営理念より）サービス 請負契約におけるアジャイル開発 ２０案件以上
時期
２０１１年３月より、スプリントは原則２週間
体制
社内およびビジネスパートナー
１ケ所での開発または、ニアショアでの開発
開発環
境
要件定義：お客様が真に必要としてい価値を掘り出す。
推進方
テスト：ＣＩ環境は必須とし、自動テストを原則とする。
法
スプリント計画：メンバー全員でタスクを洗い出し、チケット化する。
作業：チケット駆動型で行う。
進捗：バーンダウンチャートをアナログ（手書き）更新して確認する。

開発チーム（ベンダー）

スクラムマスタプロキシープロダクト
オーナー

お客様
プロダクトオーナー

・・・・
Copyright (C) ,Masanori Kataoka. & Yukio Kohara All Rights Reserved.

54

７．アジャイル開発の事例（２）スプリントの流れ
スプリント5

スプリント７と「ｱﾝｹｰﾄ機能」に注⽬

利⽤者

スプリント６

スプリント７

スプリント８スプリント９「ﾌｫｰﾗﾑ機能」
を試使⽤「ﾗｲﾌﾞﾗﾘ機能」
を試使⽤「ｱﾝｹｰﾄ機能」
を試使⽤「ｺﾗﾎﾞﾚｰｼｮﾝ機能」を試使⽤「ﾌｫｰﾗﾑ機能」
を開発
計画「ﾗｲﾌﾞﾗﾘ機能」
を開発

Copyright (C) ,「ｺﾚﾎﾞﾚｰｼｮﾝ機能」を設計「ｺﾚﾎﾞﾚｰｼｮﾝ機能」を開発「Q&A機能」
を分析「Q&A機能」
を設計

Masanori Kataoka. & Yukio Kohara All Rights Reserved.

「ｱﾝｹｰﾄ機能」のFB対応
計画「ｺﾚﾎﾞﾚｰｼｮﾝ機能」を分析

「ｱﾝｹｰﾄ機能」
を開発「ﾗｲﾌﾞﾗﾘ機能」
のFB対応
計画

「ｱﾝｹｰﾄ機能」
を設計

計計画
画

「ｱﾝｹｰﾄ機能」
を分析「ﾌｫｰﾗﾑ機能」
のFB対応

計画

開発チ ム

「ﾗｲﾌﾞﾗﾘ機能」
を設計

FB=フィードバック「Q&A機能」
を開発
55

７．アジャイル開発の事例（３）バーンアップチャート

Copyright (C) ,Masanori Kataoka. & Yukio Kohara All Rights Reserved.

56

７．アジャイル開発の事例
７．５ 米国におけるハイブリッドアジャイルの採用（１）概要
目的
大規模公共システム
サービス 複数システムと連携し、データ移行したセキュリティの高いサービス時期
全体＝１年半、アジャイルスプリント＝２０１２年５月から７ケ月
体制
大規模ウォーターフォール開発体制とスプリント時の体制の両立
開発環境 １ケ所での開発推進方法 企画、要件定義：ウォーターフォール開発（一部、スプリント）
アジャイルスプリント（２～３週間：７ケ月）：アジャイル開発
品質確認、デプロイ：ウォーターフォール開発
役割
スクラムマスター/
副ﾌﾟﾛｼﾞｪｸﾄﾏﾈｰ
ｼﾞｬｰ
開発チーム
テストチームＰＭＯ
全員

責任・スプリント計画とイテレーションバックログ定義を管理・リスクと懸念事項の軽減と必要に応じたエスカレーション
・日々のスクラムミーティングを管理
・開発タスクの作成と実施
・日単位のタスク進捗の更新
・テストケース作成と実施
・リグニッションテストの定義とユーザー受入テスト(UAT)の定義
・作業計画とタスク割り当ての管理
・ステークホルダーへのプロジェクト状況報告
・スプリント計画とレビューへの参加
・日々のステータスミーティングの参加
Copyright (C) ,Masanori Kataoka. & Yukio Kohara All Rights Reserved.

57

７．アジャイル開発の事例
ｳｫｰﾀｰﾌｫｰﾙ
ﾌｪｰｽﾞ

設計

テスト

デプロイ

ｽﾌﾟﾘﾝﾄ
計画

作成

レビュー
・成果物
・ﾌﾟﾛｾｽ

Ｑ＆Ａ

初期要求分析

企画

ｱｼﾞｬｲﾙ ｽﾌﾟﾘﾄ

部分的ＵＡＴ
ﾃﾞｲﾘｰ
ﾐｰﾃｨﾝｸﾞ
Copyright (C) ,Masanori Kataoka. & Yukio Kohara All Rights Reserved.

58

（参考）ライフサイクル• ウォーターフォール︓要件が固定＆全体で１回実⾏・リリース• アジャイル
︓要件が変動＆頻繁で⼩さな反復・リリース• ハイブリッド
︓上記の複合参考︓アジャイル実務ガイド、ＰＭＩ、2016

ウォーター
フォール
アジャイル

ハイブリッド
（例）

要件定義

設計

開発

要件定義
設計
開発
テスト
リリース

要件定義
設計
開発
テスト
リリース

要件定義
設計
開発
テスト
リリース

アジャイル

ウォーター
フォール

Copyright (C) ,

テスト

リリース

・・・・・・

要件定義
設計
開発
テスト
リリース

アジャイル
ウォーターフォール

Masanori Kataoka. & Yukio Kohara All Rights Reserved.

ウォーターフォール
アジャイル

59

７．アジャイル開発の事例

Copyright (C) ,Masanori Kataoka. & Yukio Kohara All Rights Reserved.

60

７．アジャイル開発の事例
７．６ 変化に対応する新製品開発
（１）特徴
目的

移り変わる生活者ニーズに常に応える

サービス

現実の生活者が困っている悩みを解決する新製品

時期

３５年前（１９７０年代）から開始、毎週月曜日（朝～夕方）

体制

社長、各部門の責任者、開発チーム

開発環境

専用のプレゼン室、ＴＶ会議（動画）

推進方法

資料は１画面。「要点から話す」。途中で合否判定。５～１０分／件

新製品を出し続ける

Copyright (C) ,Masanori Kataoka. & Yukio Kohara All Rights Reserved.

61

（参考）組織アジリティ
部⾨毎の完了の連携では、市場変化に対応できないことが増えている。
市場変化に対応するため、市場〜企画〜開発のサイクルを早める必要がある。

組織としての俊敏性（組織アジリティ）を⾼め、”デジタル企業”へ

市場分析

開発

企画

市場
提供

市場

依頼

企画

納⼊

開発

参考︓経営者のための「DX時代のイノベーション戦略」（第2回）平鍋 健児／2017.12.20
https://jbpress.ismedia.jp/articles/-/51870?page=4
Copyright (C) ,Masanori Kataoka. & Yukio Kohara All Rights Reserved.

62

７．アジャイル開発の事例（３）３５年間継承している日本の実践ノウハウ

Copyright (C) ,Masanori Kataoka. & Yukio Kohara All Rights Reserved.

63

７．アジャイル開発の事例（３）日本の実践ノウハウとスクラム

アジャイル開発は⽇本の実践ノウハウを触媒とした。

産業界

⽇本
トヨタ⽣産⽅式(ＴＰＳ)
・⼤野耐⼀
・新郷重夫

アメリカ
1984年

⼤学

新製品開発
1986年

トヨタ⽣産⽅式
（ＴＰＳ）
１９９０年

「SCRUM」

リーン(考え⽅)（The New New ProductDevelopment Game)

1994年

2001年
参考︓「アジャイル開発への道案内」
⽚岡雅憲、⼩原由紀夫、光藤昭男著、近代科学社、2017年

Copyright (C) ,アジャイル開発

Masanori Kataoka. & Yukio Kohara All Rights Reserved.

年
2001

ＩＴ

スクラム

XP
64

（参考）リーン・スタートアップとトヨタ生産方式『リーン・スタートアップ』 エリック・リース著, ⽇経BP社、2012
 「⽇本のトヨタ⽣産⽅式の各種の概念をうまく応⽤すれば、企業に伴う様々な問題を解き明かせる」 「５回のなぜとは、単に真因を調べることではなく、チーム内に共通の理解と視点を醸成する⽅法である」

シリコンバレーも、トヨタ⽣産⽅式を学んでいる。

Copyright (C) ,なぜなぜ５階層モデル

ムダ
実施
判断
遵守
遵守
⽀援
組織
運営

現場

 「リーン・スタートアップの⼿法のすべてが５回のなぜから導ける」

世界で100万部

管理者
組織
運営者

参考︓「アジャイル開発への道案内」 ⽚岡雅憲、
⼩原由紀夫、光藤昭男著、近代科学社、2017年

Masanori Kataoka. & Yukio Kohara All Rights Reserved.

65

補遺︓P2Mプログラムマネジメントとアジャイル開発
・Ｐ２Ｍもアジャイル開発も「顧客価値の向上」を目指す
・プロジェクト（スプリント）の実施を繰り返し、その経過や個別のプロジェクト（スプリント）の結果を評価しながら、次第に目標を明らかにする。その目標を達成するために複数のプロジェクト（スプリント）を繰り返し実施する。
ミッションプロファイリング （プログラムによって価値を創造する中核のプロセス）
到達レベル

当初の抽象的・多義的なプログラムミッションの概念を環境の複雑性や組織制約条件等を踏まえつつ具現化して可視化していくプロセスである。
あるべき姿
P2M：ギャプを理解し、プロジェクトクトを定義、シナリオを作り実行する（To-Be)プロジェクトC
課題４
スプリントC
プログラム
課題３
プロジエクトB
課題２
スプリントB
プロジェクトA
アジャイル開発
課題１
スプリントA
ありのままの姿（As-Is)〜改訂3版Ｐ２Ｍ

ガイドブック ⾖本より著者が改編〜

時間

図7.13 Ｐ２Ｍとアジャイル開発
Copyright (C) ,Masanori Kataoka ＆Yukio Kohara. All Rights Reserved.

66

（演習＃３）アジャイル開発への疑問の見直し
P23で挙げた、アジャイル開発に対する懸念・疑問を⾒直して下さい。
１．P23の懸念・疑問のキーワードを分類して下さい。
・ 懸念・疑問が解消した。（×、横線を引いて下さい）
・ 懸念・疑問が残っている（そのままにしてください）
２．新たな懸念・疑問を追加して下さい。
３．お隣の⽅と上記に関して話してください。
４．残った、懸念・疑問に優先順位１〜３(１が優先度⾼)を振って下さい。

Copyright (C) ,Masanori Kataoka ＆Yukio Kohara. All Rights Reserved.

67

おわりに
チャールズ・R・ダーウィンは、環境変化に適応できる者だけが生き残れる名言を残した。アジャイル開発は環境適応型の開発方法論だ。
短期間に高い効率で改善することができ、顧客にも受け入れられ、結果として企業や組織は成長できる。
ハードウェア資源では、資産が経費に変わるイノベーションが起きている。「クラウド化」である。ソフトウェア資源でも、利用者自らが所有せず、ＩＴサービス企業と連携したアジャイル開発を採用したサービスとして提供することを受ける選択をすれば、資産が経費となる。
・大規模システム開発プロジェクト
・ＩＯＴの応用面で急拡大を続けるエンベデットシステム
へのアジャイル開発の適用が広がり、アジャイル開発を前提としたＷｅｂアーキテクチャーが整備され、企業活動を大きく革新させることになるだろう。
Copyright (C) ,Masanori Kataoka ＆Yukio Kohara. All Rights Reserved.

68