講演の趣旨 IPA/では, 対象のシステムやソフトウェア, 及びそれらが使用される社会やビジネス環境, あるいは構築開発組織やプロジェクトの特徴 ( コンテキスト ) に応じて最も適したシステム構築ソフトウェア開発形態を選択することが望ましいと考えている. 最近, 環境の変化に俊敏に対応可能なソ

(1)

Information-technology Promotion Agency, Japan

Software

Engineering

Center

アジャイル型開発適用のヒント

～IPA/SECにおける非ウォーターフォール型開発に関する調査検討結果から～

独立行政法人情報処理推進機構(IPA)

技術本部ソフトウェア・エンジニアリング・センター(SEC)

山下博之

ソフトウェア・エンジニアリング・セミナー@神戸2012 –PARTⅡ-

2012年6月25日

(2)

SEC

Software Engineering for Mo･No･Zu･Ku･Ri

講演の趣旨

IPA/SECでは，対象のシステムやソフトウェア，及びそれ

らが使用される社会やビジネス環境，あるいは構築・開

発組織やプロジェクトの特徴（

コンテキスト

）に応じて最

も適したシステム構築・ソフトウェア開発形態を選択す

ることが望ましいと考えている．

最近，環境の変化に俊敏に対応可能なソフトウェア開

発形態として注目度が増し，内外での成功例の報告も

徐々に増えつつある

アジャイル型開発

について，調査

検討を通して整理を試みてきた．

その内容を紹介することにより，

コンテキストに応じて適

切な開発形態を選択

するための

ヒント

を得てもらうこと

を期待している．

(3)

SEC

講演の対象者

経営層

情報システム

開発運用部門

契約部門

業務部門

開発部門

品質保証部門

契約部門

経営層

人事部門

育成部門

顧客（ユーザ企業）

ベンダ企業

人材育成方法

アジャイル型開発にふさわしい

契約モデル・契約書案

顧客・経営層

の理解促進

アジャイル型開発に必要な

技術及びスキル

本日の講演

(4)

SEC

アジャイル開発に関するIPA/SECの取組み

H21年度

H22年度

H23年度

H24年度

非ウォーターフォール

型開発研究会

非ウォーターフォール

型開発WG

非ウォーターフォール

型開発WG

非ウォーターフォール

型開発WG

非ウォーターフォール

型開発に関する調査

実証/模擬実験

（契約形態）

大規模開発

普及要因

▲

報告書

▲

報告書

▲

報告書

報告書（公開中）

H21年度版

http://sec.ipa.go.jp/reports/20100330a.html

H22年度版

http://sec.ipa.go.jp/reports/20110407.html

H23年度版

http://sec.ipa.go.jp/reports/20120326.html

http://www.ipa.go.jp/about/press/20120328.html

http://sec.ipa.go.jp/reports/20120611.html

事例収集(1)

課題抽出

課題検討

検証・改善

事例収集(2)

提案

▲

報告書

▲

報告書

▲

報告書

▲

報告書

事例収集(3)

(5)

SEC

1. ITシステムを取り巻く世の中の傾向

2. アジャイル型開発手法

3. アジャイル型開発の活用に向けた課題

4. アジャイル型開発の普及に向けた課題

5. アジャイル型開発の適用領域

6. 適切な開発手法の選択（まとめに代えて）

(6)

SEC

(7)

SEC

↙

安心

←

変化の

俊敏な

反映

ITシステムへの依存と，システム環境の変化

情報技術

ITシステム

ITサービス

国民生活

社会経済活動

依存

変化

反映

• 価値観

• ライフスタイル

• 法制度

• 社会情勢

• ビジネストレンド

• …

• 技術動向

• 新技術

• コスト

• …

＜変化＞の拡大傾向

時間的：頻繁に

量的：広範囲な影響

質的：複雑化

安全

←

高信頼化

(要求の変化)

＜

依存

＞の拡大傾向

時間的：常時化

量的：広範囲化

質的：クリティカル域

⇒このような傾向を考慮した，ITシステムの開発・運用

環境

(8)

SEC

ビジネス環境の変化の例（１／３）

証券取引所に対する評価軸の変化

従来：取引所に上場されている株式の質，時価総額，出来高

現在：加えて，取引

システム

の性能（高速性），信頼性

以前は，“場立ち” と称し，株券を売買者が1つの「場」に実際に集まり取引き．

現在では，その「場」がコンピュータ上に形成されている．

このIT化に伴い，取引に参加する個人投資家やファンドマネジャーが，世界各地の証券

取引所で売買できるようになり，どの取引所で売買を行うのかを選択できるようになり，

取引所のサービスの質が問われるようになってきた．（実際，東証での取引の半分以上

は海外投資家によるもの）

→

世界中の取引所間の競争．

ITの使い方1つ，工夫1つにより，存在意義が決まるといっても過言ではない．

<出典> CIOインタビュー：東京証券取引所グループ鈴木義伯氏，ソフトバンクビジネス+IT．

http://www.sbbit.jp/article/cont1/22270

参考

(9)

SEC

ビジネス環境の変化の例（２／３）

モバイル端末の2008年までの年間出荷実績，および

2009年から2013年までの出荷予測（単位：百万台）

「Mobile Internet Report」（モルガンスタンレー，2009年12月）

変化(1) スマートフォンの急激な普及

→携帯電話からの代替

「スマートフォン市場に関する調査

（2009年7月～2010年4月）」

（矢野経済研究所，2011年5月11日）

参考

変化(2) 単なる接続端末から

高度サービスのフロントへ

(10)

SEC

ビジネス環境の変化の例（３／３）

出典：Unless they evolve, video game consoles may go extinct.

By Alex Pham and Ben Fritz, Los Angeles Times June 5, 2011

Social,

Online,

Mobile

Games

の成長

参考

(11)

SEC

俊敏な開発がビジネスに影響を与える事例

http://www.nri.co.jp/opinion/chitekishisan/2011/pdf/cs20110305.pdf

古川昌幸：「Gen-Y」世代が主力ユーザーとなる時のIT，知的資産創造，2011年3月号，野村総研，pp. 32-45.

2010年1月

2010年2月

21 22 23 24 25 26 27 28 29 30 31 1

2

3

4

5

6

7

8

9 Ａ社

Ｂ社

Ｃ社

対抗サービス発表

サービス開始

サービス発表

対抗サービス発表

サービス開始

谷川史郎(野村総研)：岐路に立つ情報システム部門，ソフトウェア開発環境展特別講演SD-S，2012年5月11日.

<出典>

携帯電話の「学割サービス」（2010年春）における各社の状況

ポイント

・業務を現場に展開するスピード（スピード開発）

・プロジェクトの粒度に対する考え方

⇒柔軟性

• システム・アーキテクチャ

• 開発体制

(12)

SEC

環境変化に即応できるための経営の「柔軟性」

予測性：可変要素が将来変化をする予兆を事前にとらえること

拡張性：既存のリソース（人，モノ，カネ，情報等）に将来の可変要素を想

定した余裕を持たせておくこと

迅速性：起きた変化／起こすべき変化に対して，すぐに対応できること

適用性：これまでと違った環境、シチュエーションに，うまく対応できること

<出典>

平成22年度経済産業省委託調査：「IT 経営普及

促進に向けた調査研究」報告書，社団法人日本情

報システム・ユーザー協会，平成23年2月，p.76．

http://www.meti.go.jp/meti_lib/report/2011fy/

0022948.pdf

(13)

SEC

システム開発ベンダにも求められる「柔軟性」

親会社

子会社

孫会社

子会社

孫会社

協力会社

（子会社）

連携会社

人材のクラウド

企画

要求

設計

製造

試験

運用

ウォーターフォール型

_{アジャイル型}

（非ウォーターフォール型）

(14)

SEC

変化に対する俊敏な開発手法

俊敏な開発(構築)手法

a. 非ウォーターフォール型開発（アジャイル開発）

b. クラウドコンピューティング

c. 自動コード生成／ビジネスルールマネジメントシステム（BRMS）

ビジネス環境の変化に対する俊敏な開発(構築)が求められる



ビジネスとしてのアジリティ

↓



開発(構築)手法としてのアジリティ

利用者(=ビジネスサイド)：

提供される価値を見極める

手法の提供者：

提供する価値を高める

(15)

SEC

航空券予約システムの開発判断：ANA

クラウド：サービスの差別化対象外の領域に適用

<出典>

国際線予約システムを欧州系のクラウドに移行ＩＴに競争優位性を求めず、「自前」から「利用」へ：ＡＮＡ

DIAMONDonline，2012年5月1日．

ビジネスの根幹システム ⇒ 要求変化の視点

一般システム ⇒ 開発(構築)手法の選択の視点

参考

国内線予約システム：オープンシステムで自前開発

国際線予約システム：欧州系のクラウドに移行

•他社，新幹線との競争

•スマホ利用によるサービス高度化

•ITコスト削減

•グローバル標準のサービス提供

提供される価値の見極め

(16)

SEC

クラウドコンピューティングと環境変化への俊敏対応例（1/2）

＜出典＞

パブリッククラウドの現状: クラウド導入企業の調査

株式会社アピリオ 2011年4月

http://www.appirio.com/jp/company/press/2011_0408.php

クラウドの価値は

コスト削減だけでなく

ビジネスにもたらす俊敏性

注) 本調査は，2010年8月11日～25

日の間，150社以上の北米企業を対

象に実施．IT-BCP対応目的は，本調

査後の東日本大震災以降の傾向．

(17)

SEC

クラウドコンピューティングと環境変化への俊敏対応例（2/2）

<出典>

vPLAT powered by AWS (NRI)

http://vplat.nri.co.jp/concept/powered-by-aws.html

(18)

SEC

要求変化対応ソフトウェア・アーキテクチャ（BRMS 1/2）

ビジネス・アーキテクチャ

_写像

ITシステム・アーキテクチャ

ビジネス戦略 → IT戦略

ビジネス・プロセス

＋

ビジネス・ルール

固定的・汎用的

変更不要

変動的・個別的

変更対象

エンジン

ビジネス・プロセスが，

ビジネス・ルールを実行

ビジネス環境の変化

要求変化対応

ソフトウェア・アーキテクチャ

ビジネス環境の変化に伴う，

ビジネス・ルールの変動に対応する，

パラメータのみ（小規模）を変更

XMLベースのマークアップ言語

による記述？

SEC特別セミナー(2011.7.12)講演

「ビジネスアナリシス最前線～北米のビジネスアナリシスを

取り巻く最新技術動向解説～」

（IIBA日本支部理事．宗雅彦）

http://sec.ipa.go.jp/seminar/2011/20110712.html

の内容をもとに作成

パラメータ

コア部分に適用

(19)

SEC

ビジネスルール管理システム（BRMS 2/2）

ビジネスルール管理システム（BRMS）の導入により，

新規開発とシステム保守の両方で詳細設計とプログラミング，単体テスト

の工程がほとんど不要になる

＜出典＞

「超高速開発」が日本を救う ITpro, 2012/03/14

http://itpro.nikkeibp.co.jp/article/NC/20120309/385541/

日経コンピュータ，2012年3月15日号

ルール記述可能な部分に適用

(20)

SEC

反復

（イテレーション）

アジャイル開発の概要

スコープ

時間

_要求

開発

テスト

スコープ

時間

_要求

開発

テスト

スコープ

時間

反復

スコープ

時間

反復

顧客の要求

にしたがって

，優先度

の高い機能から

順に，

要求・開発・テスト（・リリース）を短い期間で繰り返しながら，

システム全体を構築していく．

原則として，

事前に開発の詳細な計画は作らず，

1～4週間という

一定の短い周期

で要求・開発・テストを繰り返しながら，

動作可能なソフトを作り上げる．

＜アジャイル型開発＞

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

（対比）

(21)

SEC

迅速なリリース・要求変化対応

ウォーターフォール

アジャイル

イテレーション

顧客と

開発者の

距離

時間

可視性

イテレーション毎に

動作させて確認

リリース

優先機能から早期にリリース可能

技術リスク

動作するものを

ベースに徐々に

機能を追加

変更容易性

確定できた要件が

あれば開発可能

<出典>

永和システムマネジメント：新しい契約形態での受託開発実践記，SECセミナー資料，2011-10-04.

(22)

SEC

外部ビジネス環境

要求の固定が（ビジネス）リスクを拡大

ビジネス戦略

IT戦略

ITシステム

要求が固定されない

↓リスク

システム開発スケジュール

の遅延

要求を固定化

↓リスク

外部ビジネス環境の

変化への迅速な対応

の遅れ

要求

内部状態

(23)

SEC

注目の背景：現状のソフトウェア開発を取り巻く課題(1)

ビジネス・ニーズへの適切な対応



他社に先駆けた市場投入が必須で、それにより徐々に明確

となるニーズを迅速に反映し改善していくことが必要な分野の

出現



顧客ニーズは最初に全ては把握できず、またビジネス環境の

激しい変化に伴いニーズも変化するが、この状況に迅速な対

応が必要

→早期サービス提供と効果確認、ニーズ変化への俊敏な対

応

(24)

SEC

注目の背景：現状のソフトウェア開発を取り巻く課題(２)

（純粋な）ウォーターフォール型開発における問題点



初期段階では必ずしも全ての要求内容は確定しない



誤要求や要求の誤解が総合テスト段階で判明すると、多大な

影響



開発途中で要求が変更されると、対応が非常に困難

→要求確定部分からの順次開発開始と、妥当性の早期確認

(25)

SEC

注目の背景：現状のソフトウェア開発を取り巻く課題(３)

ソフトウェア産業構造（多重下請構造）上の課題



開発者（特に若者）の参画意識・達成感が低い

→開発の過程と各開発者の役割や成果を可視化し、創造的

な開発スタイルを採り入れ、モチベーション向上をはかる

(26)

SEC

(27)

SEC

アジャイル型開発の特徴

アジャイル開発は、不確実なビジネス環境の中で変化する

ニーズへの迅速な対応を目的としたソフトウェア開発手法。

この目的を達成するために、アジャイル開発では、

徐々に明確となる顧客ニーズや要件をシステムへ反映し、プロジェクトマ

ネジメント・リスクの早期低減、顧客側と開発側のギャップを解消。

アジャイル開発は、

•「顧客の参画の度合いが強い」

•「動くソフトウェアを成長させながら作る」

•「反復・漸進型である」

•「人と人のコミュニケーション、コラボレーションを重視する」

•「開発前の、要求の固定を前提としない」

という特徴を持つ。

(28)

SEC

非ウォーターフォール型開発の例

非ウォーターフォール型開発とは、仕様を開発前に固定し、それを分析、設計、テスト等のフェイズ

を順次踏んでいくという1970年の Winston W. Royce の論文「Managing the Development of

Large Software Systems」での

ウォーターフォール型以外の開発モデルの総称

である。

非ウォーターフォール型開発の例として、以下のものが挙げられる：

・プロトタイプ (Frederick P.Brooks, Jr.－1975年「人月の神話」)

・スパイラル (Barry w. Boehm－1988 年

「A Spiral Model of Software Development and Enhancement」)

・RAD (James Martin－1991年「ラピッドアプリケーションデベロップメント」)

・RUP (Philippe Kruchten－2000年「ラショナル統一プロセス入門」)

・

アジャイル

Evo (Tom Gilb－1976年「Software Metrics」)

Scrum (Ken Schwaber－1993年「アジャイルソフトウェア開発スクラム」)

DSDM (1995年「DSDM ver1」)

XP (Kent Beck－1996年「XPエクストリーム・プログラミング入門」)

FDD－Feature-Driven Development

(Peter Coad－1997年「Javaエンタープライズ・コンポーネント」)

Lean Software Development

(Mary Poppendieck, Tom Poppendieck－2002年「リーンソフトウェア開発」)

Crystal Clear (Alistair Cockburn－2004年「アジャイルソフトウェア開発」)

EssUp－Essential UP

(Ivar H.Jacobson－2005年「Rational Software Development Conference」)

Kanban (David Anderson－2010年「Kanban」)

(29)

SEC

アジャイル宣言における4つの価値

アジャイル宣言（Agile Manifesto）

アジャイルな開発手法の提唱者17名が集まり，2001年に発表．

http://agilemanifesto.org/iso/ja/manifesto.html

私たちは，ソフトウェア開発の実践を手助けする活動を通じて，

よりよい開発方法を見つけだそうとしている．

この活動を通して，私たちは以下のことを重視する：

①プロセスやツールよりも，個人と対話を

②包括的なドキュメントよりも，動くソフトウェアを

③契約交渉よりも，顧客との協調を

④計画に従うことよりも，変化への対応を

すなわち，①～④の各文の前者（「よりも」の前の言葉）に価値

があることを認めながらも，私たちは後者（「よりも」の後の言葉）

の事柄により価値をおく．

(30)

SEC

アジャイル宣言の背後にある12の原則

私たちは以下の原則に従う。

①顧客満足を最優先し、価値のあるソフトウェアを早く継続的に提供する。

②要求の変更はたとえ開発の後期であっても歓迎する。

変化を味方につけることによって、顧客の競争力を引き上げる。

③動くソフトウェアを、2-3週間から2-3ヶ月というできるだけ短い時間間隔でリリースする。

④ビジネス側の人と開発者は、プロジェクトを通して日々一緒に働く。

⑤意欲に満ちた人々を集めてプロジェクトを構成する。

環境と支援を与え仕事が無事終わるまで彼らを信頼する。

⑥情報を伝える最も効率的で効果的な方法は、フェイス・トゥ・フェイスで話をすることである。

⑦動くソフトウェアこそが進捗の最も重要な尺度である。

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

一定のペースを継続的に維持できるようにしなければならない。

⑨技術的卓越性と優れた設計に対する不断の注意が機敏さを高める。

⑩シンプルさ（ムダなく作れる量を最大限にすること）が本質である。

⑪最良のアーキテクチャ・要求・設計は、自己組織的なチームから生み出される。

⑫チームがもっと効率を高めることができるかを定期的に振り返り、それに基づいて自分たち

のやり方を最適に調整する。

参考

(31)

SEC

アジャイル開発のプロセス・モデル

（H21年度調査結果に基づく）

(32)

SEC

調査事例から導かれた開発プロセス・モデル(1)

モデル1

企画

システム運用

• n=1のケースもあり。

第１反復

テ

ス

ト

開発

要求

第ｎ反復

テ

ス

ト

開発

要求

・・・

第1リリース

・・・

第１反復

テ

ス

ト

開発

要求

第ｎ反復

テ

ス

ト

開発

要求

・・・

第2リリース

・・・

第１反復

テ

ス

ト

開発

要求

第ｎ反復

テ

ス

ト

開発

要求

・・・

第mリリース

考え方

シンプルな基本形

(33)

SEC

調査事例から導かれた開発プロセス・モデル(2)

モデル2

要求・アーキテ

クチャ設計

・基盤開発

企画

システム運用

• 比較的大規模システム／新規開発で全体のシステム構造が不明確なケースなど

第１反復

テ

ス

ト

開発

要求

第ｎ反復

テ

ス

ト

開発

要求

・・・

第1リリース

・・・

第１反復

テ

ス

ト

開発

要求

第ｎ反復

テ

ス

ト

開発

要求

・・・

第mリリース

考え方

拡張形．基盤・共通部といくつかの機能部とから構

成されるソフトウェア（右図）において，最初にまず，

基盤・共通部の開発を終えた後，機能部群につい

て，アジャイル開発を行う．基盤・共通部が確固とし

ていないと，追加・変更時の機能部への影響が大き

くなりすぎることを避ける．アジャイル開発では，基

盤・共通部の変更は，原則として行わない．

基盤・共通部

機

能

1 機

能

2 機

能

3 機

能

4 …

(34)

SEC

調査事例から導かれた開発プロセス・モデル(3)

モデル3

システム運用

・アジャイル開発では反復ごとにリリースできる品質までテストを行うことが原則だが、

各リリース工程前に行う重点的なテストを実施することがある。

・リリースは複数回繰り返される

企画

リリース前

テスト

・・・・・・

第１反復

テ

ス

ト

開発

要求

第ｎ反復

テ

ス

ト

開発

要求

・・・

第1リリース

リリース前

テスト

第１反復

テ

ス

ト

開発

要求

第ｎ反復

テ

ス

ト

開発

要求

・・・

第mリリース

考え方

顧客やビジネスの特徴から，特に高い品質が求められたり，品質がクリ

ティカルであったりする場合に，リリース前に品質確保のための特別のア

クションを実施する．

(35)

SEC

(36)

SEC

ウォーターフォール型開発の流れ

要件定義

設計

コーディング

テスト

運用

・全体の要件と計画を初めに決める

→計画駆動型

・前工程を誤りなく完了させて、次の工程へ進む

対比

(37)

SEC

ウォーターフォール型開発への疑問

要件定義

機能設計

モジュール

設計

コーディング

総合テスト

機能テスト

結合テスト

単体テスト

分

解

合

成

チェック

・要件が事前に全ては決まらない/決められない

・要件の誤りが最後のテストまで発見されにくい

・時間がかかり過ぎて変化への対応が遅れる

対比

(38)

SEC

アジャイル開発のモデル(1/2)- プロセスの対応 -

要求

開発

テスト

<標準>

ソフトウェアライフサイクル

プロセス（SLCP）

要求

開発

テスト

<実際>

注) 図形のサイズは意

味を持たない（時間，

規模を表さない）．

（部品）

ウォーターフォール型

大きなプロセスを

順に実施し，

それを1回で終了

アジャイル型

小さなプロセスを

行き来しつつ実施し，

それを何回も反復

注) 図形のサイズは意味を持つ．

(39)

SEC

アジャイル開発のモデル(2/2) - プロセスとプラクティス -

アクティビティ

タ

ス

ク

＜プロセスの構成＞

What-to-do (何をするか)を表す．

XP ・システムのメタファ

・シンプルデザイン

・テスト駆動開発

・頻繁なリファクタリング

・ペアプログラミング

Scrum ・スプリントバックロググラフの作成

・自律的な組織化チーム

・スクラムミーティング

・1日以内の障害除去

・共通の部屋

・日次ビルド

・スプリントレビ

How-to-do (どのようにするか)を表す．

＜プラクティスの例＞

全く異なる観点

(40)

SEC

プロジェクト要素

従来型開発

アジャイル型開発

管理

「プロセス」重視

「人」重視

マネジメントスタイル

指揮統制型

リーダーシップ・協力型

知識の管理

明示

暗示

役割

個人

→専門化を好む

自己組織チーム

→役割の相互入れ替えを推奨

コミュニケーション

フォーマルで、必要な時のみ

インフォーマルで、継続的

顧客の関与

重要だが、通常はプロジェクトの分

析段階においてのみ

必須で、継続的

プロジェクトサイクル

業務や活動主導

製品特性主導

従来型とアジャイル型との主な違い(1/2)

「プロセス」重視

「人」重視

出典 Kieran Conboy, Sharon Coyle, Xiaofeng Wang, Minna Pikkarainen:

”People Over Process: Key People Challenges in Agile Development”, IEEE Software, July 2010.

参考

文化が

異なる

…

(41)

SEC

従来型とアジャイル型との主な違い(2/2)

参考

プロジェクト要素

従来型開発

アジャイル型開発

開発モデル

ライフサイクルモデル

（ウォーターフォール、スパイラル、ま

たはこれらのバリエーション）

進化型成果モデル

望まれる組織形態/構

造

機械的（官僚的で、形式重視）

有機的（柔軟性、参加性に富み、

協力しあう社会的活動を推奨）

テクノロジー

制約なし

目標指向のテクノロジーが好まれる

チーム配置

分散型主体

連動型主体

チームサイズ

多くの場合で 10 人を超える

通常は 10 人以下

継続ラーニング

あまり推奨されない

積極的に採用される

マネジメント文化

指揮統制型

対応型

チーム参加

必須でない

必須

プロジェクト・プラニング管理職主導

継続的

フィードバックの仕組み獲得困難

通常数多く存在

文書化

相当量

最小限

(42)

SEC

計画

駆動

Q：品質

S：スコープ

(R：要求)

C：コスト

D：納期

開発プロジェクトのパラメータ間の関係

機能Ｎ

:

機能Ｍ

:

機能

3 機能

2 機能

1 要求（優先順）

価値

実装範囲

S：スコープ

(R：要求)

C：コスト

Q：品質

D：納期

固定

見積り→実際には変動

固定

優先順に従って変動

価値

駆動

品質を維持

しようとすると

コストと納期に影響

スコープ(要求)の

サイズが品質に影響

優先度の低い機能は

実装しても結局は使われない

→無駄な実装はしない

参考

ＱＣＤの優先順位

(43)

SEC

システム開発におけるQCDの優先順位

システム企画工程におけるQCDの優先順位

 品質 : 29%

 コスト: 24%

 納期 : 47%

<出典>

ソフトウェアメトリックス調査2012，一般社団法人日本情報システム・ユーザー協会(JUAS)．

参考

調査で収集した801プロジェクトのうち，

「QCDのうちのどれかを優先した」という回答(313プロジェクト)の内訳

(44)

SEC

アジャイル型開発に関わる重点課題

日本のソフトウェア競争力を高める

生き生きと働ける環境を作る

（日本にふさわしい）契約のあり方

日本におけるソフトウェア開発の在り方

ユーザ・ベンダ経営層の意識

人材の育成と適正配置

適用領域と適用事例の調査

欧米の競争力（普及要因）の調査

普及

事例収集(1)に

より抽出された

重点課題

目指すべき

ゴール

管理手法や技術面の整備

ツールによる支援

環境整備

領域

見定め

契約

価値評価

人材

(45)

SEC

(46)

SEC

(47)

SEC

37%

29%

26%

23%

18%

16%

15% 14%

11%

10%

_9%

5%

0%

5%

10%

15%

20%

25%

Tim

e

-to

-M

ar

ke

t の

加速

変化す

る

優先順位

管理の

た

め

生産性向上

ソ

フ

ト

ウ

ェ

ア

品質

の

向上

IT

と

ビ

ジ

ネ

ス

の

融合改善

プ

ロ

ジ

ェ

ク

ト

の

見え

る

化

リ

ス

ク

削減

開発プ

ロ

セ

ス

の

簡易化

分散チ

ー

ム

管理

エ

ン

ジ

ニ

ア

リ

ン

グ

の

導入

／向上

コ

ス

ト

削減

保守性／

拡張性

向上

チ

ー

ム

の

や

る

気改善

１．Time-to-Marketの加速

２．変化する優先順位管理のため

（VersionOne社アジャイル開発の現状調査第6回2011より）

参考

アジャイル型開発手法の導入理由（海外）

35%

30%

40%

39%

(48)

SEC

顧客・経営層は開発への一層の関与が必要

顧客（ユーザ）経営層

ビジネス環境が激しく変化する現状において，ITシステムに関し，従来

のように情報システム部門に任せきりでは適切に対応できない．開発

形態(*)にも深く関与する必要がある．

(*) アジャイル開発の採用，クラウドコンピューティングの利用，など

ベンダ経営層

俊敏な開発の実績を武器に受注を狙う海外勢等に対抗するためには，

自ら俊敏な開発を実施できる体制作りに取り組むと共に，その結果を

顧客に売り込む必要がある．

＜経営層の責任＞

・情報システムに関する理解の増進

・迅速かつ適切な意思決定

・関係部門との経営上の綿密な調整

(49)

SEC

2割の企業がIT部門を通さずにクラウドを導入

――おエライさんの独断で決定

「IT部門を通すと時間がかかりすぎる」との見方が背景に

参考

2011年6月2日 Computerworld.jp (IDG Japan)

http://www.computerworld.jp/topics/cloud/191782.html

【Kelton Research調査（米国）】

Chiefレベルの役員やビジネス部門長など573人の経営幹部が回答

 これらの回答者のうち61％が、クラウド・サービスは容易に導入できた

と答えており、50％が、IT部門を通すと

時間がかかりすぎる

と答えてい

る。

 企業は社員を対象にクラウド・プラットフォームに関する研修を行ってお

り、64％が新入社員と既存社員の両方の

研修に投資

していると答えて

いる。

経営層の判断に基づくIT迅速導入の動き

(50)

SEC

顧客・経営層が開発上で考慮すべき点



顧客・経営層は、アジャイル開発の採用を決断した時点で、顧客が

チー

ムの一員として参画

し、タイムリーな意思決定を行ったり、品質や進捗状

況の把握等に関し、主体的に開発に関わらざるを得ないということに十

分な理解と覚悟を持つ。



「最初に全ての要件を決めないでもよく、途中で適宜明確にしていけば

よい」という

安易な心構え

で開始すると、

途中で破たん

することが多い。



アジャイル開発の特徴に応じた「見える化」項目を用いて開発プロジェク

トとの

円滑なコミュニケーション

を図り、アジャイル開発採用の本来の目

的が損なわれないように努める。



ユーザ/ベンダ間の

信頼感の醸成

が、円滑に進めるために重要。

(51)

SEC

(52)

SEC

顧客・経営層は開発への一層の関与が必要

顧客（ユーザ）経営層

ビジネス環境が激しく変化する現状において，ITシステムに関し，従来

のように情報システム部門に任せきりでは適切に対応できない．開発

形態(*)にも深く関与する必要がある．

(*) アジャイル開発の採用，クラウドコンピューティングの利用，など

ベンダ経営層

俊敏な開発の実績を武器に受注を狙う海外勢等に対抗するためには，

自ら俊敏な開発を実施できる体制作りに取り組むと共に，その結果を

顧客に売り込む必要がある．

＜経営層の責任＞

・情報システムに関する理解の増進

・迅速かつ適切な意思決定

・関係部門との経営上の綿密な調整

(53)

SEC

海外勢との競争（１／２）

参考

出典：トヨタ自動車株式会社ホームページ

2011年04月07日

マイクロソフトコーポレーション

トヨタ自動車株式会社

マイクロソフトとトヨタ、次世代テレマティクスのプラットフォーム構築に向けた

戦略的提携について基本合意

マイクロソフトコーポレーション（以下、マイクロソフト、本社：米国ワシントン州レドモンド市、最高経営責任者：スティーブ・バ

ルマー）とトヨタ自動車株式会社（以下、トヨタ、本社：愛知県豊田市、代表取締役社長：豊田章男）は、マイクロソフトのクラ

ウドプラットフォーム「Windows Azure

TM

_{」をベースとしたトヨタの次世代テレマティクス向けグローバルクラウドプラットフォーム}

の構築に向けた戦略的提携について基本合意した。

2011年05月23日

株式会社セールスフォース・ドットコム

トヨタ自動車株式会社

セールスフォース・ドットコムとトヨタ、クルマ向けソーシャルネットワーク

「トヨタフレンド」の構築に向けた戦略的提携に基本合意

セールスフォースのクラウドサービスをベースに構築

米国セールスフォース・ドットコム（NYSE：CRM、以下、セールスフォース、本社：米国カリフォルニア州サンフランシスコ市、最

高経営責任者：マーク・ベニオフ）とトヨタ自動車株式会社（以下、トヨタ、本社：愛知県豊田市、代表取締役社長：豊田章

男）は、セールスフォースの企業向けソーシャルネットワークサービスである「Chatter（チャター）」をベースに、クルマ向けソー

シャルネットワーク「トヨタフレンド」の構築に向け提携することで基本合意した。

「トヨタフレンド」は2012年市販予定のEV及びPHVでのサービス開始を予定している。

(54)

SEC

海外勢との競争（２／２）

参考

出典：トヨタ自動車株式会社ホームページ

2011年11月10日

トヨタ自動車、インテル社と次世代車載情報通信システムに関する技

術の共同研究についてMOUを締結

トヨタ自動車(株)は、11月10日、インテルコーポレーション（以下、インテル最高経営責任者：ポール・オッテリーニ

本社：米国カリフォルニア州サンタクララ市）と、現在のナビゲーション等に代わる、次世代の車載情報通信システムに

関する技術の共同研究についてMOUを締結した。

(55)

SEC

大手IT企業の取組み

参考

出典：大手IT企業が「アジャイル開発」を強化，日経コンピュータ，2012年5月24日号．

ねらい

主に大手顧客を対象に，「新規ビジネスを支えるシステムを早期に立ち

上げたい」といったニーズに対応

アジャイル手法をウォーターフォール型開発手法と併用することにより，

「仕様変更でプロジェクトが遅延しやすい」といった弱点をカバー

人材育成

開発標準

(56)

SEC

(57)

SEC

アジャイル開発プロセスの流れ：スクラムの例

ToDo

Doing

Done

タスクボード

<出典> 株式会社豆蔵堀江弘志：「初めての取組み事例に見るアジャイル導入の勘所」，

(58)

SEC

ユーザ側・ベンダ側に求められるスキル

アジャイル開発におけるユーザ側に求められること：

（全ての機能の仕様を洗い出す能力よりも）

コア

となる機能を

見定め

，

優先度を図りながら

開発プロジェクトの運営を指揮していく能力

明確な仕様を決めなくても良いとはいうものの，定期的なサイクル

で実物を見てフィードバックのポイントを増やすことにより，実際のシ

ステムを目で確認しながら，積み上げるように仕様を決定していく

アジャイル開発のベンダ開発者にとって重要なスキル：

① プロジェクトのアウトプットに関わる判断ではなく，アジャイル開発の

進め方を踏襲させるための

ファシリテーション

スキル

② 反復活動の中で，実際に動くものを作りながら，小規模に，かつト

ータルにプロジェクトの

アウトプットを

積み重ね

ていくスキル

③ 設計，コーディング，テストを

一貫して実施出来るスキル

(59)

SEC

人材の育成の考え方

価値

原則

手法

＜アジャイル開発の実際＞



一つのプロジェクトで全てのプラクティスを使う訳ではない



各プラクティスに厳格な規範はない



様々な方法論・数あるプラクティスから，プロジェクトや組織に

適したものを取捨選択し，カスタマイズすることが必要



(平時) 一通りのプラクティスを理解する



(プロジェクト参画時) 使用するプラクティスの習得

↓

全てを完全に身につけるより，

価値に従って行動する

習慣

を確実に身につけることが重要

(60)

SEC

件数

14

12

10

8

6

4

2

0

16

18

20

22 頻繁なふりかえり

計画ゲーム

日次のスタンドアップミーティング

（朝会）

継続的インテグレーション

ペアプログラミング

バーンダウンチャート

リファクタリング

テスト駆動開発

コードの共同所有

かんばん

自動化された回帰テスト

ニコニコカレンダー

顧客プロキシ

タスクカード

ポストイット

タイムボックス

頻繁なリリース

コーディング規約

ストーリーカード

単体テストの自動化

スクラムのスプリント

スプリントバックログ

チーム全体が一つに

71.4％ 52.4％ 47.6％ 42.9％ 38.1％ 28.6％ 23.8％ 19％ 14.3％ 15 11 10 10 9 8 8 6 5 4 4 4 3 3 3 3 3 2 2 2 2 2 2 9.5％ 9.5％ 9.5％ 9.5％ 9.5％ 9.5％ 14.3％ 14.3％ 14.3％ 14.3％ 19％ 19％ 38.1％ 47.6％

反復型計画

100％ 21

※1事例は活用プラクティス不明

参考

調査事例：活用されているプラクティス

(61)

SEC

人材の配置（プロジェクト対応）の考え方



自社用のシステム開発から，アジャイル開発OJT



初めの頃の実プロジェクトでは，

コンサルタント（アジャイル・コ

ーチ等）

の支援を得る



個人プラクティスは個人で，チーム・プラクティスを組織で



とはいっても，

アジャイル開発に向いている技術者と，

ウォーターフォール型開発に向いている技術者と，

人材の見極めと適切な配置

が必要

(62)

SEC

人材育成の事例－スケジュール

育成開始

ス

キ

ル

診断

卒業検定

標準1ヶ月(習熟度により前後)

開発技術(基礎知識)

プ

ロ

ジ

ェ

ク

ト

キ

ッ

ク

オ

フ

ル

ー

キ

ー

ズ

セ

ミ

ナ

ー

模擬開発

開発開始

・構成管理 / その他ツール

・テスト駆動開発

・オブジェクト指向プログラム

/ 設計

・Java言語 / Eclipse

1日

2～3日

5日

開発メンバ育成

開発チーム育成

OJT

・

自己紹介

・

チ

ー

ム

ビ

ル

ド

・

開発環境知識獲得

・

業務知識

・

フ

レ

ー

ム

ワ

ー

ク

・

開発標準

・

ア

ジ

ャ

イ

ル

基礎知識

・サブチーム単位に行う

・作ったものは捨てる

・開発者向け

・ストーリーオーナー

向けも別途行う

・

プ

ロ

ジ

ェ

ク

ト

憲章

・

行動指針

・

ア

ジ

ャ

イ

ル

概要

・開発できるレベル

まで育てる

組閣

参画・プロパー

・プロダクトオーナー

・パートナー

プロジェクト立上げ

(63)

SEC

○：立上げ前後の必須教育の領域

△

：事前に準備が困難でOJTが必要な領域

＊

：内容を組織内で個別に検討する必要がある領域

人材育成の事例－対象別育成カリキュラム例

開発チー

ム

スクラム

マスター

顧客／プ

ロダクト

オーナー

先行チー

ム

リーダー

PM

経営者層

／購買担

当など

アジャイル概要

_○

アジャイル基礎知識

_○

アジャイル擬似体験

_○

業務知識

_○

_＊

_○

開発環境

_○

_＊

基本アーキテクチャ

_○

_＊

業務分析／モデリング

_△

開発技術

_△

_＊

ファシリテーション概要

_○

ファシリテーション演習

_○

アジャイル開発を

初めて行う組織を対象

(64)

SEC

人材育成の事例－カリキュラム概要

名称

概要

アジャイル概要

アジャイル開発に携わる方向けの基礎知識

アジャイル基礎知識

一般的なプラクティスについての紹介

アジャイル擬似体験

アジャイル開発のプロセスを体験を通して理解する

チームビルディング的な狙いもある

業務知識

開発対象の業務を理解する(内容は先行チームと検討)

開発環境

開発に使用するツールなどを理解する(内容は先行チームと

検討)

基本アーキテクチャ

開発対象のシステム構成や、利用するフレームワークなどを

理解する(内容は先行チームと検討)

業務分析／モデリング業務を整理し、開発側に伝えるための手法を理解する

開発技術

開発に必要な技術を身につける（必要に応じて）

ファシリテーション概要ファシリテーションに関する知識を理解する

ファシリテーション演習ファシリテーションに関する知識を体験を通して理解する

(65)

SEC

モチベーション…科学的実証の結果 (1/2)

http://www.ted.com/talks/lang/ja/dan_pink_on_motivation.html

<出典> Dan Pink on the surprising science of motivation

ダニエル・ピンク「やる気に関する驚きの科学」

モチベーションと報酬の関係性を，科学的証拠に基づいて丁寧に説明．

報酬

のインセンティブは，視野を狭め，心を集中させることから，単純な

仕事では効果があるが，そうでない

創造的な仕事では逆効果

．

成果を高める

のは，

内的な動機付け

に基づくアプローチ．

すなわち，重要だからやる，好きだからやる，面白いからやる，何か重要

なことの一部を担っているからやる，というもの．

仕事において重要な要素は次の3つ：

• 自主性

…自分の人生の方向は自分で決めたい

• 成長

…何か大切なことについて上達したい

• 目的

…私たち自身よりも大きな何かのためにやりたい

参考

（ある程度

の）裁量

顧客の"価値"

を高める

スキルアップ

になる

(66)

SEC

モチベーション…科学的実証の結果 (2/2)

Wikipedia

1990年代半ば MicrosoftはEncartaという百科事典を作り始めた．適切なインセ

ンティブを設定し，何千というプロにお金を払って記事を書いてもらった．高額の報

酬をもらうマネージャが全体を監督し，予算と納期の中で出来上がるようにした．

何年か後に別な百科事典が開始された．別なモデルを採っていた．

楽しみでやり，

1セント，1ユーロ，1円たりとも支払われない

．みんな好きだからやる．

ほんの10年前に経済学者のところへ行って，こう聞いたとする．「百科事典を作る

2つのモデルを考えたが，対決したらどちらが勝つと思うか?」 10年前，世界のま

ともな経済学者で，Wikipediaのモデルが勝つという人は1人もいなかっただろう．

Google社の20％ルール

エンジニアは

仕事時間の20パーセントを何でも好きなことに使う

ことができる．時

間，タスク，チーム，使う技術すべてに自主性が認められる．その結果，Googleで

はよく知られている通り，新製品の半分近くがこの20パーセントの時間から生まれ

ている．Gmail，Orkut，Google Newsなどがその例．

参考

(67)

SEC

(68)

SEC

海外における普及要因の調査

(69)

SEC

海外におけるアジャイル開発の普及要因調査

各調査対象国における普及要因を明らかにするため，次の3項目を調査

駆動要因

土壌

普及要因

① ソフトウェア開発

プロジェクトの比較

（例：プロジェクト種別，

ユーザの関与等）

② IT人材の状況

（例：IT技術者の就労状況や

人材の流動性等）

③ IT人材育成

（教育カリキュラム）の比較

調査項目

日本

デンマーク

英国

米国

中国

ブラジル

調査対象国

調査範囲

欧米の競争力になっている

アジャイル開発の

普及要因

を調査し，

日本における

普及や定着を促進する施策

のヒントとする．

駆動要因

ビジネス的背景，産業構造等

土壌

人材，社会的環境等

(70)

SEC

参考：海外でのアジャイルの台頭

Forrester2010調査：「メインストリームとなったアジャイル型開発」

“1,300人のIT開発者のうち、約半数(45%)がアジャイル手法を使っていると回答

(2009年の調査では35%) … アジャイルと非アジャイルの技術とプラクティスを組み

合わせて、より大きな組織にあうようにハイブリッドにすることに苦闘している。”

(出典 eWeek 2010/1/22: が報じた、Forrester 2010: “AGILE DEVELOPMENT: MAINSTREAM ADOPTION HAS CHANGED AGILITY”)

※ 2010年の調査で、はじめてアジャイルはウォーターフォールを超えた。

自社の中でアジャイルを採用しているチームの数

出典: Version One社 2011 State of Agile Development Survey Results

具体的なアジャイル方法論

回答者のうち2/3 以上が、自社において3つ

以上のチームでアジャイルを実践している

Scrumとその変化形が2/3。ハイブリッドも伸びている

(71)

SEC

Scrum Master等の推移から見るアジャイル開発の普及状況



アジャイル型開発方法論で最も有名なスクラムに関する資格者が、2005年以降急増



米国の取得者が群を抜いて多く、ついで英国が多い。日本は極めて少ない（試験は英語）

出典：

Scrum Allianceによる協力

Scrum Master等人数の経年変化

CSM (Certified Scrum Master)

チーム全体の支援者

CSPO(Certified Scrum Product Owner)

製品の責任者

CSP(Certified Scrum Professional)

スクラムの実践者

略称説明

単位(人)

Scrum Master等の人数の経年変化

2002 2003 2004 2005 2006 2007 2008 2009 2010 2011 TOTAL CSM 5 344 907 2,647 6,841 12,857 22,514 26,886 34,601 43,028 150,630 CSPO 83 503 1,891 3,514 5,325 8,629 19,945 CSP 1 2 14 26 38 116 264 366 534 501 1,862 TOTAL 6 346 921 2,673 6,962 13,476 24,669 30,766 40,460 52,158 172,437

各国の現在のScrum Master等人数 (2012年3月)

米国英国中国デンマークブラジル日本 TOTAL CSM 67,000 11,800 3,800 3,700 4,600 350 91,250 CSPO 8,000 1,800 400 750 900 120 11,970 CSP 1,100 0 30 30 60 6 1,226 TOTAL 76,100 13,600 4,230 4,480 5,560 476 104,446

単位(人)

各国の現在のScrum Master等人数 (2012年3月)

海外普及要因調査

(72)

SEC

ソフトウェア開発プロジェクトの比較【特徴的データ】

米国では、ソフトウェアに対する投資は「

自社開発（内製）

」「

市販パッケージソフトの利用

」が約2/3を

占めている（下図「米国民間部門におけるソフトウェア投資」参照）

さらに、他国に比べて

多くのIT技術者がユーザ企業に所属

している（下図「IT技術者の所属先」参照）

米国のプロジェクトの形態の特徴は、3割が

内製している

こと

941,410

0 1,452,000

450,000

0 771,426

1,446,809

49,024

128,000

100,000

2,362,300

0 554,069

150,000

19,961

254,721

365,416

49,669

104,732

124,170

0 500,000

1,000,000

1,500,000

2,000,000

2,500,000

3,000,000

3,500,000

ユーザ企業

ITサービス企業

出典：「グローバル化を支えるIT人材確保・育成施策に関する調査」概要

Software

Engineering

Center

アジャイル型開発適用のヒント

～IPA/SECにおける非ウォーターフォール型開発に関する調査検討結果から～

独立行政法人情報処理推進機構(IPA)

技術本部ソフトウェア・エンジニアリング・センター(SEC)

山 下 博 之

ソフトウェア・エンジニアリング・セミナー@神戸2012 –PARTⅡ-

2012年6月25日

SEC

講演の趣旨

IPA/SECでは，対象のシステムやソフトウェア，及びそれ

らが使用される社会やビジネス環境，あるいは構築・開

発組織やプロジェクトの特徴（

コンテキスト

）に応じて最

も適したシステム構築・ソフトウェア開発形態を選択す

ることが望ましいと考えている．

最近，環境の変化に俊敏に対応可能なソフトウェア開

発形態として注目度が増し，内外での成功例の報告も

徐々に増えつつある

アジャイル型開発

について，調査

検討を通して整理を試みてきた．

その内容を紹介することにより，

コンテキストに応じて適

切な開発形態を選択

するための

ヒント

を得てもらうこと

を期待している．

SEC

講演の対象者

経営層

情報システム

開発運用部門

契約部門

業務部門

開発部門

品質保証部門

契約部門

経営層

人事部門

育成部門

顧客（ユーザ企業）

ベンダ企業

人材育成方法

アジャイル型開発にふさわしい

契約モデル・契約書案

顧客・経営層

の理解促進

アジャイル型開発に必要な

技術及びスキル

本日の講演

SEC

アジャイル開発に関するIPA/SECの取組み

H21年度

H22年度

H23年度

H24年度

非ウォーターフォール

型開発研究会

非ウォーターフォール

型開発WG

非ウォーターフォール

型開発WG

非ウォーターフォール

型開発WG

非ウォーターフォール

型開発に関する調査

実証/模擬実験

（契約形態）

大規模開発

普及要因

▲

報告書

▲

報告書

▲

山下博之

目次

6. 適切な開発手法の選択（まとめに代えて）