ipa/secにおける非ウォーターフォール型開発に関する調査検討 … ·...

1 Software Engineering Center

Information-technology Promotion Agency, Japan

Software Engineering Center

アジャイル型開発適用のヒント～IPA/SECにおける非ウォーターフォール型開発に関する調査検討結果から～

独立行政法人情報処理推進機構(IPA) 技術本部ソフトウェア・エンジニアリング・センター(SEC)

山下博之

第2回 ITC近畿会セミナー「IPA共催セミナー(2/2)」 2012年8月25日

配布用資料

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

Software Engineering Center 2

講演の趣旨

IPA/SECでは，対象のシステムやソフトウェア，及びそれらが使用される社会やビジネス環境，あるいは構築・開発組織やプロジェクトの特徴（コンテキスト）に応じて最も適したシステム構築・ソフトウェア開発形態を選択することが望ましいと考えている．

最近，環境の変化に俊敏に対応可能なソフトウェア開発形態として注目度が増し，内外での成功例の報告も徐々に増えつつあるアジャイル型開発について，調査検討を通して整理を試みてきた．

その内容を紹介することにより，コンテキストに応じて適切な開発形態を選択するためのヒントを得てもらうことを期待している．

2012-08-25 ITC近畿会/IPA共催セミナー Copyright © 2009-2012 IPA, All Rights Reserved.



講演の対象者

経営層

情報システム開発運用部門

契約部門

業務部門開発部門

品質保証部門

契約部門経営層

人事部門育成部門

顧客（ユーザ企業）ベンダ企業

人材育成方法

アジャイル型開発にふさわしい契約モデル・契約書案

顧客・経営層の理解促進

アジャイル型開発に必要な技術及びスキル




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

H21年度 H22年度 H23年度 H24年度

非ウォーターフォール型開発研究会

非ウォーターフォール型開発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)

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

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


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




目次

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

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

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

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

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

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




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




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

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

他社に先駆けた市場投入が必須で、それにより徐々に明確となるニーズを迅速に反映し改善していくことが必要な分野の出現

顧客ニーズは最初に全ては把握できず、またビジネス環境の激しい変化に伴いニーズも変化するが、この状況に迅速な対応が必要

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


H21年度



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

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

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

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

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

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


H21年度



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

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

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

→開発の過程と各開発者の役割や成果を可視化し、創造的な開発スタイルを採り入れ、モチベーション向上をはかる


H21年度



最近の傾向：注目度がより高まってきている背景

1. ビジネスの俊敏さへの対応要求の増大

2. グローバル化の拡大

3. ウォーターフォール型開発に適合しにくいケースの増大


会社に足りないとされるのが経営のスピード感。「まずは七分でよし。利用者のお叱りを受けながら100%に磨き上げていく」（加藤薫・NTTドコモ社長）

2012.7.21 朝日新聞朝刊

現在

従来：100%にしてから世に出す

現在：エンドユーザとの共同作業により，よいものにしていく（β版文化）

2012.7.23 総務省・谷脇康彦氏講演



↙

安心 ←

変化の俊敏な反映

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


情報技術

ITシステム

ITサービス

国民生活社会経済活動

依存

変化

変化

反映

• 価値観 • ライフスタイル • 法制度 • 社会情勢 • ビジネストレンド • …

• 技術動向 • 新技術 • コスト • …

＜変化＞の拡大傾向時間的：頻繁に量的：広範囲な影響質的：複雑化

安全 ←

高信頼化

(要求の変化)

＜依存＞の拡大傾向時間的：常時化量的：広範囲化質的：クリティカル域

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

環境



外部ビジネス環境

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

ビジネス戦略

IT戦略

ITシステム

要求が固定されない

↓リスク

システム開発スケジュールの遅延

要求を固定化

↓リスク

外部ビジネス環境の変化への迅速な対応の遅れ

要求内部状態




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


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

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

現在：加えて，取引システムの性能（高速性），信頼性

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

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

このIT化に伴い，取引に参加する個人投資家やファンドマネジャーが，世界各地の証券取引所で売買できるようになり，どの取引所で売買を行うのかを選択できるようになり，取引所のサービスの質が問われるようになってきた．（実際，東証での取引の半分以上は海外投資家によるもの） →

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

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

<出典> CIOインタビュー：東京証券取引所グループ鈴木義伯氏，ソフトバンクビジネス+IT．http://www.sbbit.jp/article/cont1/22270

参考



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

モバイル端末の2008年までの年間出荷実績，および 2009年から2013年までの出荷予測（単位：百万台）「Mobile Internet Report」（モルガンスタンレー，2009年12月）

変化(1) スマートフォンの急激な普及 →携帯電話からの代替

「スマートフォン市場に関する調査（2009年7月～2010年4月）」（矢野経済研究所，2011年5月11日）

参考


変化(2) 単なる接続端末から高度サービスのフロントへ

（PC出荷台数との逆転）



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

出典：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 の成長

参考




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


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年春）における各社の状況

ポイント・業務を現場に展開するスピード（スピード開発）・プロジェクトの粒度に対する考え方

⇒柔軟性 • システム・アーキテクチャ • 開発体制



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


予測性：可変要素が将来変化をする予兆を事前にとらえること拡張性：既存のリソース（人，モノ，カネ，情報等）に将来の可変要素を想

定した余裕を持たせておくこと迅速性：起きた変化／起こすべき変化に対して，すぐに対応できること適用性：これまでと違った環境、シチュエーションに，うまく対応できること

<出典> 平成22年度経済産業省委託調査：「IT 経営普及促進に向けた調査研究」報告書，社団法人日本情報システム・ユーザー協会，平成23年2月，p.76． http://www.meti.go.jp/meti_lib/report/2011fy/0022948.pdf



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


親会社

子会社

孫会社孫会社

子会社

孫会社

協力会社

協力会社（子会社）

連携会社

人材のクラウド企画要求設計製造試験運用

ウォーターフォール型アジャイル型（非ウォーターフォール型）

多様性



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


俊敏な開発(構築)手法

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

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

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

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

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

利用者(=ビジネスサイド)：提供される価値を見極める手法の提供者：提供する価値を高める



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


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

<出典> 国際線予約システムを欧州系のクラウドに移行ＩＴに競争優位性を求めず、「自前」から「利用」へ：ＡＮＡ DIAMONDonline，2012年5月1日．

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

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

参考

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

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

•他社，新幹線との競争 •スマホ利用によるサービス高度化

•ITコスト削減 •グローバル標準のサービス提供

提供される価値の見極め



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


＜出典＞パブリッククラウドの現状: クラウド導入企業の調査株式会社アピリオ 2011年4月 http://www.appirio.com/jp/company/press/2011_0408.php

クラウドの価値はコスト削減だけでなくビジネスにもたらす俊敏性

注) 本調査は，2010年8月11日～25日の間，150社以上の北米企業を対象に実施．IT-BCP対応目的は，本調査後の東日本大震災以降の傾向．



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


<出典> vPLAT powered by AWS (NRI) http://vplat.nri.co.jp/concept/powered-by-aws.html

パブリック・クラウド上での迅速なシステム開発の実現



「クラウドサービスに関するアンケート」実施機関：マクロミル実施期間：2012年06月04日(月)～2012年06月05日(火) 調査方法：インターネットリサーチ調査対象：年商10～1000億円の企業における情報システム担当者200サンプル（クラウドを既に導入している企業の情報システム担当者100サンプルを含む）

http://special.nikkeibp.co.jp/ts/article/ab0f/123382/


参考クラウドコンピューティング導入への期待［国内調査］



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

ビジネス・アーキテクチャ写像 ITシステム・アーキテクチャ

ビジネス戦略 → IT戦略

ビジネス・プロセス＋

ビジネス・ルール

固定的・汎用的変更不要

変動的・個別的変更対象

エンジン

ビジネス・プロセスが，ビジネス・ルールを実行

ビジネス環境の変化要求変化対応ソフトウェア・アーキテクチャ

ビジネス環境の変化に伴う，ビジネス・ルールの変動に対応する，パラメータのみ（小規模）を変更

XMLベースのマークアップ言語による記述？

SEC特別セミナー(2011.7.12)講演「ビジネスアナリシス最前線～北米のビジネスアナリシスを取り巻く最新技術動向解説～」（IIBA日本支部理事．宗雅彦） http://sec.ipa.go.jp/seminar/2011/20110712.html の内容をもとに作成

パラメータ

コア部分に適用


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



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


ビジネスルール管理システム（BRMS）の導入により，新規開発とシステム保守の両方で詳細設計とプログラミング，単体テストの工程がほとんど不要になる

＜出典＞「超高速開発」が日本を救う ITpro, 2012/03/14 http://itpro.nikkeibp.co.jp/article/NC/20120309/385541/ 日経コンピュータ，2012年3月15日号

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

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



要求変化対応と安心・安全（BRMS 3/3）

システムの複雑さは信頼性を低下させる

ルール処理モジュール

第3階層

第2階層

第1階層ルール１

ルール21

ルール31 ルール32

ルール22

ルール33

ルール・データ

モジュール 5

モジュール 2

モジュール 1

モジュール 4

モジュール 3

v.s.

変化に追随しないシステムは安心して使えない

システムシステム

変更

変更




反復（イテレーション）

アジャイル開発の概要

スコープ時

間

要求

開発

テスト

スコープ時

間

要求

開発

テスト

スコープ

時間

反復

スコープ

時間

反復

顧客の要求にしたがって，優先度の高い機能から順に，要求・開発・テスト（・リリース）を短い期間で繰り返しながら，システム全体を構築していく．原則として，事前に開発の詳細な計画は作らず， 1～4週間という一定の短い周期で要求・開発・テストを繰り返しながら，動作可能なソフトを作り上げる．

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

（対比）




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

ウォーターフォール

アジャイルイテレーション

顧客と開発者の

距離

時間

可視性

イテレーション毎に動作させて確認

リリース

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

技術リスク動作するものをベースに徐々に機能を追加

変更容易性

確定できた要件があれば開発可能

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




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




アジャイル型開発の特徴

アジャイル開発は、不確実なビジネス環境の中で変化するニーズへの迅速な対応を目的としたソフトウェア開発手法。

この目的を達成するために、アジャイル開発では、徐々に明確となる顧客ニーズや要件をシステムへ反映し、プロジェクトマネジメント・リスクの早期低減、顧客側と開発側のギャップを解消。

アジャイル開発は、 •「顧客の参画の度合いが強い」 •「動くソフトウェアを成長させながら作る」 •「反復・漸進型である」 •「人と人のコミュニケーション、コラボレーションを重視する」 •「開発前の、要求の固定を前提としない」という特徴を持つ。




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

非ウォーターフォール型開発とは、仕様を開発前に固定し、それを分析、設計、テスト等のフェイズを順次踏んでいくという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」)

参考




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

アジャイル宣言（Agile Manifesto）アジャイルな開発手法の提唱者17名が集まり，2001年に発表． http://agilemanifesto.org/iso/ja/manifesto.html

私たちは，ソフトウェア開発の実践を手助けする活動を通じて，よりよい開発方法を見つけだそうとしている．

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

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

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

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

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

すなわち，①～④の各文の前者（「よりも」の前の言葉）に価値があることを認めながらも，私たちは後者（「よりも」の後の言葉）の事柄により価値をおく．




アジャイル宣言の背後にある12の原則私たちは以下の原則に従う。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

参考




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

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




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

モデル1

企画

システム運用

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

第１反復

テスト

開発

要求

第ｎ反復

テスト

開発

要求・・・

第1リリース

・・・

第１反復

テスト

開発

要求

第ｎ反復

テスト

開発

要求・・・

第2リリース

・・・

第１反復

テスト

開発

要求

第ｎ反復

テスト

開発

要求・・・

第mリリース

考え方シンプルな基本形





Copyright © 2009-2012 IPA, All Rights Reserved.

モデル2

要求・アーキテクチャ設計・基盤開発

企画

システム運用

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

第１反復

テスト

開発

要求

第ｎ反復

テスト

開発

要求・・・

第1リリース

・・・

第１反復

テスト

開発

要求

第ｎ反復

テスト

開発

要求・・・

第mリリース

考え方拡張形．基盤・共通部といくつかの機能部とから構成されるソフトウェア（右図）において，最初にまず，基盤・共通部の開発を終えた後，機能部群について，アジャイル開発を行う．基盤・共通部が確固としていないと，追加・変更時の機能部への影響が大きくなりすぎることを避ける．アジャイル開発では，基盤・共通部の変更は，原則として行わない．

基盤・共通部

機能 1

機能 2

機能 3

機能 4

…

2012-08-25 ITC近畿会/IPA共催セミナー




モデル3 システム運用

・アジャイル開発では反復ごとにリリースできる品質までテストを行うことが原則だが、各リリース工程前に行う重点的なテストを実施することがある。・リリースは複数回繰り返される

企画リリース前

テスト・・・・・・

第１反復

テスト

開発

要求

第ｎ反復

テスト

開発

要求・・・

第1リリース

リリース前テスト

第１反復

テスト

開発

要求

第ｎ反復

テスト

開発

要求・・・

第mリリース

考え方顧客やビジネスの特徴から，特に高い品質が求められたり，品質がクリティカルであったりする場合に，リリース前に品質確保のための特別のアクションを実施する．




開発手法の比較




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

要件定義

設計

コーディング

テスト

運用

・全体の要件と計画を初めに決める →計画駆動型・前工程を誤りなく完了させて、次の工程へ進む


対比



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

要件定義

機能設計

モジュール設計

コーディング

総合テスト

機能テスト

結合テスト

単体テスト

分

解

合

成

チェック

チェック

チェック

・要件が事前に全ては決まらない/決められない・要件の誤りが最後のテストまで発見されにくい・時間がかかり過ぎて変化への対応が遅れる


対比



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

要求

開発

テスト

<標準> ソフトウェアライフサイクルプロセス（SLCP）

要求

開発

テスト

<実際>

注) 図形のサイズは意味を持たない（時間，規模を表さない）．

（部品）

ウォーターフォール型

大きなプロセスを順に実施し，それを1回で終了

アジャイル型

小さなプロセスを行き来しつつ実施し，それを何回も反復

注) 図形のサイズは意味を持つ． 2012-08-25 ITC近畿会/IPA共催セミナー Copyright © 2009-2012 IPA, All Rights Reserved.



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

アクティビティタスク

＜プロセスの構成＞

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

XP ・システムのメタファ・シンプルデザイン・テスト駆動開発・頻繁なリファクタリング・ペアプログラミング Scrum ・スプリントバックロググラフの作成・自律的な組織化チーム・スクラムミーティング・1日以内の障害除去・共通の部屋・日次ビルド・スプリントレビ

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

＜プラクティスの例＞

全く異なる観点 2012-08-25 ITC近畿会/IPA共催セミナー Copyright © 2009-2012 IPA, All Rights Reserved.



プロジェクト要素従来型開発アジャイル型開発

管理「プロセス」重視「人」重視

マネジメントスタイル指揮統制型リーダーシップ・協力型

知識の管理明示暗示

役割個人

→専門化を好む

自己組織チーム

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

コミュニケーションフォーマルで、必要な時のみインフォーマルで、継続的

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

析段階においてのみ

必須で、継続的

プロジェクトサイクル業務や活動主導製品特性主導

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

「プロセス」重視「人」重視

出典 Kieran Conboy, Sharon Coyle, Xiaofeng Wang, Minna Pikkarainen: ”People Over Process: Key People Challenges in Agile Development”, IEEE Software, July 2010.

参考

文化が異なる

…


“計画”駆動型 (顧客)“価値”駆動型



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

プロジェクト要素従来型開発アジャイル型開発

開発モデルライフサイクルモデル

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

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

進化型成果モデル

望まれる組織形態/構

造

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

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

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

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

チーム配置分散型主体連動型主体

チームサイズ多くの場合で 10 人を超える通常は 10 人以下

継続ラーニングあまり推奨されない積極的に採用される

マネジメント文化指揮統制型対応型

チーム参加必須でない必須

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

フィードバックの仕組み獲得困難通常数多く存在

文書化相当量最小限




計画駆動

Q：品質

S：スコープ (R：要求)

C：コスト D：納期

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


機能Ｎ

:

機能Ｍ

:

機能3

機能2

機能1

要求（優先順）

価値

実装範囲

S：スコープ (R：要求)

C：コスト

Q：品質

D：納期固定

見積り→実際には変動

固定固定

優先順に従って変動

価値駆動

品質を維持しようとすると

コストと納期に影響

スコープ(要求)のサイズが品質に影響

優先度の低い機能は実装しても結局は使われない

→無駄な実装はしない

参考ＱＣＤの優先順位



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


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

品質 : 29%

コスト: 24%

納期 : 47%

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

参考

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

ベンダの目指すべきところは，総合的な“顧客満足”か？



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




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

日本のソフトウェア競争力を高める生き生きと働ける環境を作る

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

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

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

人材の育成と適正配置

適用領域と適用事例の調査欧米の競争力（普及要因）の調査普及

事例収集(1)により抽出された

重点課題

目指すべきゴール

管理手法や技術面の整備ツールによる支援

環境整備

領域見定め

契約

価値評価

人材




ユーザ経営層の意識




37%

29% 26%

23%

18% 16% 15% 14%

11% 10% 9% 5%

0%

5%

10%

15%

20%

25%

Tim

e-to

-M

arke

t

の

加速

変化する優先順位

管理のため

生産性向上

ソフトウェア品質

の向上

IT

とビジネスの

融合改善

プロジェクトの

見える化

リスク削減

開発プロセスの

簡易化

分散チーム管理

エンジニアリング

の導入／向上

コスト削減

保守性／拡張性

向上

チームの

やる気改善

１．Time-to-Marketの加速２．変化する優先順位管理のため

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

参考


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

35%

30%

40% 39%



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

顧客（ユーザ）経営層

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

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

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

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

ベンダ経営層

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

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

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

＜経営層の責任＞・情報システムに関する理解の増進・迅速かつ適切な意思決定・関係部門との経営上の綿密な調整




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迅速導入の動き



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

顧客・経営層は、アジャイル開発の採用を決断した時点で、顧客がチームの一員として参画し、タイムリーな意思決定を行ったり、品質や進捗状況の把握等に関し、主体的に開発に関わらざるを得ないということに十分な理解と覚悟を持つ。

「最初に全ての要件を決めないでもよく、途中で適宜明確にしていけばよい」という安易な心構えで開始すると、途中で破たんすることが多い。

アジャイル開発の特徴に応じた「見える化」項目を用いて開発プロジェクトとの円滑なコミュニケーションを図り、アジャイル開発採用の本来の目的が損なわれないように努める。

ユーザ/ベンダ間の信頼感の醸成が、円滑に進めるために重要。




ベンダ経営層の意識




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

顧客（ユーザ）経営層

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

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

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

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

ベンダ経営層

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

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

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

＜経営層の責任＞・情報システムに関する理解の増進・迅速かつ適切な意思決定・関係部門との経営上の綿密な調整




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

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

2011年04月07日マイクロソフトコーポレーション

トヨタ自動車株式会社

マイクロソフトとトヨタ、次世代テレマティクスのプラットフォーム構築に向けた戦略的提携について基本合意

マイクロソフトコーポレーション（以下、マイクロソフト、本社：米国ワシントン州レドモンド市、最高経営責任者：スティーブ・バルマー）とトヨタ自動車株式会社（以下、トヨタ、本社：愛知県豊田市、代表取締役社長：豊田章男）は、マイクロソフトのクラウドプラットフォーム「Windows AzureTM」をベースとしたトヨタの次世代テレマティクス向けグローバルクラウドプラットフォームの構築に向けた戦略的提携について基本合意した。

2011年05月23日株式会社セールスフォース・ドットコム

トヨタ自動車株式会社

セールスフォース・ドットコムとトヨタ、クルマ向けソーシャルネットワーク「トヨタフレンド」の構築に向けた戦略的提携に基本合意セールスフォースのクラウドサービスをベースに構築

米国セールスフォース・ドットコム（NYSE：CRM、以下、セールスフォース、本社：米国カリフォルニア州サンフランシスコ市、最高経営責任者：マーク・ベニオフ）とトヨタ自動車株式会社（以下、トヨタ、本社：愛知県豊田市、代表取締役社長：豊田章男）は、セールスフォースの企業向けソーシャルネットワークサービスである「Chatter（チャター）」をベースに、クルマ向けソーシャルネットワーク「トヨタフレンド」の構築に向け提携することで基本合意した。「トヨタフレンド」は2012年市販予定のEV及びPHVでのサービス開始を予定している。


配布用



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

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

2011年11月10日

トヨタ自動車、インテル社と次世代車載情報通信システムに関する技術の共同研究についてMOUを締結トヨタ自動車(株)は、11月10日、インテルコーポレーション（以下、インテル最高経営責任者：ポール・オッテリーニ本社：米国カリフォルニア州サンタクララ市）と、現在のナビゲーション等に代わる、次世代の車載情報通信システムに関する技術の共同研究についてMOUを締結した。


さらに，先進的なユーザ企業は，

内製を進めている

配布用



リーン開発/アジャイル開発の展開参考

出典：リーン開発の生みの親、ポッペンディーク夫妻に聞く，ITpro 2012/06/21, http://itpro.nikkeibp.co.jp/article/COLUMN/20120619/403762/


リーンの実践は三つの指標の計測からリーン開発未経験の企業が実践時に利用した方がよい三つの指標

(1)サイクルタイム：何かをすることに決めてから，実際に成果物を手にするまでにかかる時間

(2) 目標達成度 (3) 顧客満足度

業界にとって次のステップ「正しいものを作る」こと．ただ動くソフトウエアを提供するのではなく，「いかに顧客の求めるものを作るか」が大切になってくる．ソフトウエアを劇的に改善するよりよい方法を示したという点で，アジャイルはほぼ完了している．

一方，「顧客に価値をもたらして喜ばせる」という意味では、まだ改善の余地がある．



大手IT企業の取組み


参考

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

ねらい

主に大手顧客を対象に，「新規ビジネスを支えるシステムを早期に立ち上げたい」といったニーズに対応アジャイル手法をウォーターフォール型開発手法と併用することにより，

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

人材育成

開発標準

「品質会計」と組み合わせたアジャイル開発ガイドも作成

10月24日(水)に，本テーマでSECセミナー開催予定



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

ToDo Doing Done

タスクボード


<出典> 株式会社豆蔵堀江弘志：「初めての取組み事例に見るアジャイル導入の勘所」， JASA主催/IPA共催セミナー，2011-11-18．http://sec.ipa.go.jp/events/2011/20111116.html



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

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

（全ての機能の仕様を洗い出す能力よりも）コアとなる機能を見定め，優先度を図りながら開発プロジェクトの運営を指揮していく能力

明確な仕様を決めなくても良いとはいうものの，定期的なサイクルで実物を見てフィードバックのポイントを増やすことにより，実際のシステムを目で確認しながら，積み上げるように仕様を決定していく

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

① プロジェクトのアウトプットに関わる判断ではなく，アジャイル開発の進め方を踏襲させるためのファシリテーションスキル

② 反復活動の中で，実際に動くものを作りながら，小規模に，かつトータルにプロジェクトのアウトプットを積み重ねていくスキル

③ 設計，コーディング，テストを一貫して実施出来るスキル 2012-08-25 ITC近畿会/IPA共催セミナー Copyright © 2009-2012 IPA, All Rights Reserved.



人材の育成の考え方

価値

原則

手法

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

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

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

様々な方法論・数あるプラクティスから，プロジェクトや組織に適したものを取捨選択し，カスタマイズすることが必要


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

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

↓

全てを完全に身につけるより，価値に従って行動する習慣を確実に身につけることが重要



件数

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事例は活用プラクティス不明


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



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

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

初めの頃の実プロジェクトでは，コンサルタント（アジャイル・コーチ等）の支援を得る

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

とはいっても，

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

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

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




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


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

<出典> Dan Pink on the surprising science of motivation ダニエル・ピンク「やる気に関する驚きの科学」

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

報酬のインセンティブは，視野を狭め，心を集中させることから，単純な仕事では効果があるが，そうでない創造的な仕事では逆効果．

成果を高めるのは，内的な動機付けに基づくアプローチ．

すなわち，重要だからやる，好きだからやる，面白いからやる，何か重要なことの一部を担っているからやる，というもの．

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

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

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

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

参考

（ある程度の）裁量

顧客の"価値"を高める

スキルアップになる



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


Wikipedia

1990年代半ば MicrosoftはEncartaという百科事典を作り始めた．適切なインセンティブを設定し，何千というプロにお金を払って記事を書いてもらった．高額の報酬をもらうマネージャが全体を監督し，予算と納期の中で出来上がるようにした．

何年か後に別な百科事典が開始された．別なモデルを採っていた．楽しみでやり，1セント，1ユーロ，1円たりとも支払われない．みんな好きだからやる．

ほんの10年前に経済学者のところへ行って，こう聞いたとする．「百科事典を作る2つのモデルを考えたが，対決したらどちらが勝つと思うか?」 10年前，世界のまともな経済学者で，Wikipediaのモデルが勝つという人は1人もいなかっただろう．

Google社の20％ルール

エンジニアは仕事時間の20パーセントを何でも好きなことに使うことができる．時間，タスク，チーム，使う技術すべてに自主性が認められる．その結果，Googleではよく知られている通り，新製品の半分近くがこの20パーセントの時間から生まれている．Gmail，Orkut，Google Newsなどがその例．

参考



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




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





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

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

駆動要因

土壌

普及要因

① ソフトウェア開発プロジェクトの比較（例：プロジェクト種別，

ユーザの関与等）

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

人材の流動性等）

③ IT人材育成（教育カリキュラム）の比較

調査項目

日本

デンマーク

英国

米国

中国

ブラジル

調査対象国

調査範囲

欧米の競争力になっているアジャイル開発の普及要因を調査し，日本における普及や定着を促進する施策のヒントとする．

駆動要因

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

土壌

人材，社会的環境等




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

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。ハイブリッドも伸びている

Copyright © 2009-2012 IPA, All Rights Reserved. 2012-08-25 ITC近畿会/IPA共催セミナー

海外普及要因調査



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月)





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


米国では、ソフトウェアに対する投資は「自社開発（内製）」「市販パッケージソフトの利用」が約2/3を占めている（下図「米国民間部門におけるソフトウェア投資」参照）さらに、他国に比べて多くのIT技術者がユーザ企業に所属している（下図「IT技術者の所属先」参照）米国のプロジェクトの形態の特徴は、37%が内製していること

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人材確保・育成施策に関する調査」概要報告書 2011年 3月 (IPA)

N/A

N/A

IT技術者の所属先

Prepackaged : パッケージソフトを購入 Custom : 外部発注作業 Own account : 自社開発ソフト

出典：「Bureau of Economic Analysis http://www.bea.gov/national/xls/soft-invest.xls」

単位(人)

73.4

88.2

96.3

Prepackaged Custom Own account

単位(Billions of dollars)

米国民間部門におけるソフトウェア投資



http://www.bea.gov/national/xls/soft-invest.xls





（大手）システムインテグレータ(PMO)

日本の調達モデル

ユーザ（CIO）

ハードウエアベンダ

データベース・ベンダ

パッケージベンダ

システム開発ベンダ

パッケージシステム

開発ハードウエア

データベース

経営システム外部設計

経営システムコンサル

IPAグローバルシンポジウム2010 一色浩一郎教授講演より

参考




米国の調達モデル

ユーザ（CIO，PMO）

ハードウエアベンダ

データベース・ベンダ

パッケージベンダ

システム開発ベンダ

パッケージシステム

開発ハードウエア

データベース

経営システム外部設計

経営システムコンサル


参考




米国におけるアジャイル開発の例


参考




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

過去の５つの政府調達ITプロジェクトの経験から、将来のプロジェクトに対する提言をまとめたもの。当該資料の付録には、組織、契約、調達側と提供側のコミュニケーション、開発チームの組織、などに関する３１の実践なチェックリストがある。（以下に例）・できる限り小さく始める。30以下の開発者で最初の納期は6ヶ月以内。・柔軟な計画変更ができる契約。・違約金でなく、インセンティブのある契約。・体制全体に行き渡る、コミュニケーション計画を含むこと。・実ユーザをフルタイムで参加させ、役割を定義すること。・調達側と提供側の役割を明確にし、協働でプロジェクトの共通理解を作る活動を、分割した納品の後に毎回行う。

出典： http://www.tekno.dk/pdf/projekter/p01_Rapport_it_proj.pdf

デンマークでは政府が発注するソフトウェア開発をアジャイル型開発で実施することを推奨している


※上記レポートを発行しているデンマーク技術委員会（tekno: DBT:Danish Board of Technology）は、デンマーク及びＥＵの議会の政治的意思決定者に対してアドバイスをするための機関で、研究省の下部組織。

デンマークでは、アジャイルの採用が進み、現在でも成長していると言える(strong and growing)。何らかのアジャイル手法を取り込んでいるプロジェクトは半数以上あるだろう。特に、ScrumはITに関与するすべての人が知っており、広く利用されている。アジャイルの採用率は高くなっており（予想では50%）、大きな企業でも取り組みが始まっている（例： Den Danske Bank -デンマークで最大の銀行 -、Maersk Line IT等) 。政府から、アジャイル採用の推奨が出ている。

Rapport: Erfaringer fra statslige IT-projekter - Hvordan gør man det bedre (『Lessons from government IT projects – How to do it better』)

（出典： Bent Jensen氏インタビュー）





デンマークにおける“ユーザー・ドリブン・イノベーション”


参考

<出典> 砂田薫: デンマークの情報化とユーザー・ドリブン・イノベーション，国際CIO学会2011年秋季大会予稿，http://cio-japan.waseda.ac.jp/publication.htm

デンマークの電子政府は，ポータルの設計から開発・運用・評価・改善にいたるサイクルで，市民の直接的かつ主体的な参加がみられる点が大きな特徴．

デンマーク政府が利用者にとって使いやすい電子政府サービスの提供に力を注ぐのは，第一に市民の利便性が向上するためであり，第二にポータルの利用者が増えるほどインターネットでのセルフサービスが拡大するので行政コストの削減効果が大きいため．

ユーザーを重視して，ボトムアップでシステムを設計していこうとするデンマークのアプローチは，分権的な民主主義社会で伝統的に根付いてきたもの．ユーザー志向が乏しくテクノロジー・ドリブンといえるアプローチを採用してきた日本にとって，新たな発展の方向としてデンマークのイノベーション戦略は参考になる．



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

ブラジルでは、アジャイルは圧倒的(massive)。私たちの80%の顧客がアジャイルを取り入れており、そのうち半分がアジャイルを「メインの開発手法」としている。普及要因は、やってみて実際の成功率。従来のウォーターフォールよりもビジネスが成功しやすい。それから、これは推測だが、ブラジル人は強い管理が苦手。ソフトな管理手法の方がマッチしている。また、これは経済が急速に発展していることとも関係すると思う。急速な成長には柔軟な手法が合う。また、ブラジルは北米と時差がなく、このことは、北米からのソフトウェア開発のアウトソーシングを受ける受託開発では大きな要因。アジャイルは顧客との高レベルなコミュニケーションが必要。質問があったときに顧客に電話等で不明点を明らかにできることは、非常に重要。我々の会社は中国にも支社があるが、中国では米国から受託できない。このように、顧客と開発チームはアジャイルでは、時差が少ないことが要求される。


ブラジルの状況ブラジルではアジャイル型開発が普及している実践した結果、顧客のビジネスの成功率が高いことが普及要因

北米からのアジャイル受託開発が伸びている理由は北米とブラジルは時差が少なく、

リアルタイムコミュニケーションが可能であること

（出典： Bruno Guicardi氏インタビュー）





IT人材の状況【特徴的なデータ】

Copyright © 2012 IPA, All Rights Reserved.

米国ではIT関連職が人気の職業 2009年：

Systems Engineer が1位 2010年：

Software Architectが1位

システムズ・エンジニア

看護師

医師助手

大学教授

ITプロジェクトマネージャー

ソフトウェア開発者

ソフトウェアプロダクト

マネージャー

弁護士

最高給与給与中央値

ランク

<出典> Focus, Best Jobs in America: http://kelsocartography.com/blog/?p=3585 CNN Money: http://money.cnn.com/magazines/moneymag/bestjobs/2010/index.html

米国では恒常的にIT関連職の給与が高く、人気も高い中国、ブラジルでは、 IT関連職の人材が不足しているため、IT関連職の給与が高く、人気が高い米国、中国、ブラジルでは、IT関連職が人気であるため、優秀な人材が集まる

システムズ・エンニアとは、日本のSEのニュアンスとは異なる。ソフトウェアを含むシステム全体の構造を検討・定義する役割を持つ職種をさす(出典：CNN Money をもとに編集)



http://kelsocartography.com/blog/?p=3585

http://money.cnn.com/magazines/moneymag/bestjobs/2010/index.html



普及要因


項番分類普及要因

1

駆動要因

顧客（開発依頼側）が開発チームに参加しやすい関係

2 顧客と開発チームが「いつでもコミュニケーションをとること」ができる環境

3 アジャイル型開発を実践し、顧客のビジネスの成功率が高いことを実感し、定着・伝播する環境

4 ソフトウェアの変更に対応しやすい（計画を変更しやすい）顧客と開発チームの関係

5 顧客（開発依頼側）と開発チームで、ゴールを共有できる関係

6 政府がアジャイル型開発の効果を認め、調達においてアジャイル型開発を積極的に採用し、普及を促進する

7

土壌

開発側、顧客側ともに、ソフトウェアに関する幅広い知識を持った人材を育てる環境

8 コミュニケーション、コラボレーションの重要性を学べる実践的な教育（PBL）

9 顧客の関与や、コミュニケーションの重要性を経験的に学ぶ産学連携を通した教育

10 コミュニケーション能力の高い人材が育成される環境

11 IT業界へ優秀な（向上心が強く、目的意識の高い）人材を供給できる環境

12 技術や経験が組織や人に蓄積される仕組み

13 IT産業に技術と知識を流通させる方法として、アジャイル型開発のトレーニングを受けやすい環境




海外でもアジャイルの普及が進みにくい領域がある

「プロジェクト」から「プロダクト開発」へと形態が変化

品質を高める活動としてのアジャイル（CMMIからの移行）

顧客の参画は、アジャイルプロジェクトの必須要件である

コンテキスト（文脈）の重要性

日本に普及しない理由についての参考意見

インタビューから明らかになった注目すべきトピックス



ソフトウェア開発とラインのビジネスのギャップが大きい組織，大規模開発，コンプライアンスや安全性がクリティカルなシステム，レガシーシステムの拡張

CMMIを取得した企業が，プロセス改善によるさらなる効率の追求と，よりよいユーザ体験を目指して，アジャイルを採用するケース（中国）

日本の商習慣（定額請負型契約，多重下請構造，等），CIOの軽視，等



日本におけるアジャイル型開発にふさわしい

契約モデルの提案





調査事例：契約形態の集計（H21年度）

契約の種類件数比率

請負契約６３３．３％

請負契約（月毎）１５．６％

請負契約＋準委任契約１５．６％

準委任契約７３８．９％

労働者派遣契約１５．６％

不明２１１．１％

合計１８１００％

（社内開発：契約無し）（４）ー

⇒海外では、直接雇用やTime&Materialの準委任型契約が中心だが、日本では、アジャイル型開発とはなじみにくい請負契約の割合も高い。


参考



WF型開発と比較したアジャイル開発の特徴

ユーザとベンダの緊密な協力体制が必須

- 相手方の問合せへの迅速な応答

- 担当作業の迅速な実施

- ユーザ/ベンダ間の責任分担が不明確になりがち

ユーザ要求の詳細が契約時点では未確定

- 何を作るか決まっていない（成果物未定）

- 性能・品質等が不明確

- 工数見積りが困難（コスト未定）

開発途中でのユーザ要求の変化を柔軟に受け入れる必要

- 決定した事項も変更されることがある

契約 2012-08-25 ITC近畿会/IPA共催セミナー Copyright © 2009-2012 IPA, All Rights Reserved.



アジャイル開発と契約の対立

契約合意内容を固定して、当事者を法的に拘束する

アジャイル開発変化に対応すべく、合意内容の変更を柔軟に認め、当事者をなるべく拘束しない

⇒アジャイル開発にはふさわしい契約とは?




システム開発において主に使われる契約類型

請負契約（民法632条～642条）

一方が仕事を完成させることを請負い、その相手方が完成した仕事に対して報酬を支払うことを約束する契約。

⇒契約時点で、ベンダが完成すべき仕事の内容を明確にしておく必要。

準委任契約（民法643条～656条）

事務処理を目的とする契約であり、仕事の完成を目的としない。ベンダは、善良な管理者の注意をもって、委任された事務を処理する義務（善良管理者注意義務）を負う。

⇒ベンダに完成義務がなく、ユーザにとって不安。




アジャイル開発には、どんな契約がふさわしいのか?

開発内容が決まっていない段階で、開発プロジェクト全体に

つき、一つの請負契約を結ぶのは適切ではない（何をいくら

で完成させるか不明）。

他方、開発プロジェクト全体を準委任契約にすることは、ベ

ンダが完成義務を負わない点で、ユーザ側に不安がある（た

とえ成果物が完成しなくても、ユーザは対価を支払う必要）。

また、アジャイル開発の特徴であるユーザとベンダの協働関

係を、契約に取り入れる必要がある。


注) ユーザ側での労働者派遣契約に基づく開発チーム構成には，契約上の問題は特にない．

(内製傾向の高まりに伴い増加？)



契約問題PTで検討された契約モデル案

基本/個別契約モデル：

プロジェクト全体に共通する事項につき、基本契約を締結し、

小さな機能単位ごとに、開発対象と費用がある程度確定し

たタイミングで個別契約（請負/準委任）を順次締結する。

組合モデル：

ユーザとベンダが共同でジョイント・ベンチャーとしての組合を

組成し、協力してシステム開発（収益性のあるもの）を企画・

製作する（開発された成果から得られた収益は、ベンダと

ユーザに分配される）。




基本/個別契約モデルの概要（１／２）

企画

システム運用


第１反復

テスト

開発

要求

第ｎ反復

テスト

開発

要求・・・

第1リリース

第１反復

テスト

開発

要求

第ｎ反復

テスト

開発

要求・・・

第2リリース

第１反復

テスト

開発

要求

第ｎ反復

テスト

開発

要求・・・

第mリリース

基本契約

個別契約個別契約個別契約

企画

システム運用


第１反復

テスト

開発

要求

第１反復

テスト

開発

要求

第ｎ反復

テスト

開発

要求

第ｎ反復

テスト

開発

要求・・・

第1リリース

第１反復

テスト

開発

要求

第１反復

テスト

開発

要求

第ｎ反復

テスト

開発

要求

第ｎ反復

テスト

開発

要求・・・

第2リリース

第１反復

テスト

開発

要求

第１反復

テスト

開発

要求

第ｎ反復

テスト

開発

要求

第ｎ反復

テスト

開発

要求・・・

第mリリース

基本契約

個別契約個別契約個別契約個別契約個別契約個別契約

契約

基本契約

個別契約個別契約個別契約


- 例 -



基本/個別契約モデルの概要（２／２）

要件定義

設計

実装

テスト

導入

WF開発における基本/個別契約モデル

開発対象機能群１ time

フェーズごとに

個別契約を締結

開発対象機能群２

開発対象機能群３

開発対象機能群４

開発対象機能群ｎ

アジャイル開発における基本/個別契約モデル

time

開発対象機能群ごとに個別契約を締結

（経済産業省情報システム・モデル取引契約書など）




組合モデルの概要

組合

組合契約（製作管理と成果管理を規定する）

成果物の企画スケジュール・予算管理

知的財産管理成果物の収益分配

利害関係者との権利調整組合員の倒産、脱退

清算

ベンダ業務執行組合員

ユーザ製作に関わる資本出資

ベンダ

ユーザ業務執行組合員

組合-ベンダ間の開発契約は基本/個別契約モデルの個別契約を利用する。

イテレーション単位で成果物を納品

ベンダ製作に関わる労務出資

（本例では

同一主体）

投資家製作に関わる資本出資

投資家組合員

契約

(本例では，管理分のみ)

(実際の開発分について)




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


[注] •適用領域も変化する •領域のコンテキストに応じ，適切な開発手法を



アジャイル開発の適用領域・試行領域

全てのソフトウェア開発に、これらの特徴を有するアジャイル開発手法を適用できる、あるいはすべきだ、という立場ではない。ビジネスや市場、その他の開発の“コンテキスト”によって、ウォーターフォール型の開発が適している場面もあれば、アジャイル型の開発が適している場面もある。

アジャイル開発は、 •「顧客の参画の度合いが強い」 •「動くソフトウェアを成長させながら作る」 •「反復・漸進型である」 •「人と人のコミュニケーション、コラボレーションを重視する」 •「開発前の、要求の固定を前提としない」という特徴を持つ。




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

アジャイル開発が得意とし、現在、その適用により効果を挙げている領域：

①ビジネス要求が変化する領域

・要求の変化が激しく，あらかじめ要求が固定できない領域。

②リスクの高い領域

・不確実な市場を対象としたビジネス領域（市場リスク）

・技術的な難易度が高い開発領域（技術リスク）

③市場競争領域

・他社に先駆けた製品・サービス市場投入が命題であり，TTM（Time to Market）の短縮が優先となる領域（Webのサービス，パッケージ開発，新製品開発）．




アジャイル開発の試行領域

アジャイル開発による経験が十分には蓄積されておらず、現在、チャレンジと創意工夫が求められている領域：

①大規模開発

・開発者10人程度を超えると、システム分割、チーム分割が必要。その分割方法、及び、分割されたチーム間のコミュニケーションが課題。

②分散拠点（オフショア含む）開発

・開発拠点が分散し、さらに時差によって分断される場合のコミュニケーション手法、また、それをサポートするツールが必要。

③組織（会社）間をまたぐ開発チームによる開発

・共通のビジネスゴールを持ったチームを組むことが難しい。

④組込みシステム開発

・リリース後のソフトウェア修正が極めて困難であり、採用には工夫要。




No. 事例概要

１小売業における業務システム開発事例事例調査結果①

２ソーシャルネットワーキングサービス（SNS）システム開発事例

３サプライチェーンマネジメントシステム開発事例

４研修運営システム開発事例

５開発案件管理Webアプリケーション開発事例

６製造業向けプロトタイプシステム開発事例

７携帯ソーシャルゲーム開発事例事例調査結果②

８携帯端末向けブログシステム開発事例

９パッケージソフトウェア開発事例

１０共通認証システム開発事例

１１プロジェクト管理システム開発事例


参考 H21年度調査事例一覧(1/2)



No. 事例概要

１２アプリケーションプラットフォーム開発事例

１３教務Webシステム開発事例

１４教育機関向け統合業務パッケージ開発事例

１５検索エンジン開発事例

１６システム管理ミドルウェア開発事例

１７株式取引のためのWebアプリケーション開発事例事例調査結果③

１８プラント監視制御用計算機システム開発事例

１９生産管理システム開発事例

２０ Webメディア開発事例

２１アジャイル型開発の支援環境開発事例

２２業界共通電子データ交換基盤構築事例事例調査結果④


参考 H21年度調査事例一覧(2/2)



チームの人数

（人） 2

4

6

8

10

12

2 4 6 8 10 12 14 16 18 20 22 24 開発期間（月）

⇒チームの人数は8割が10人以下

⇒開発期間は2～4ヶ月が45％、1年超が35％


参考事例：アジャイル型開発プロジェクトの規模



中・大規模開発事例の調査





アジャイル開発のスイートスポットシステム規模 0．．１２．．３００（開発メンバー数）

深刻度シンプル、経済被害、．．．人身事故

システムの成熟度新規開発、レガシー保守

要件の変化率低、中、高

ビジネスモデル自社開発、オープンソース、．．．

アーキテクチャ安定、変化した、新しい

チームの分散一か所、．．、オフショア、外部委託

統制単純なルール、．．．、SOX、．．．

(Philippe Kruchten, 2009, “Is Agility a New Passing Fad?”)

中・大規模開発事例の調査：背景

アジャイルソフトウェア開発宣言[※]

①プロセスやツールよりも，個人と対話を ②包括的なドキュメントよりも，動くソフトウェアを ③契約交渉よりも，顧客との協調を ④計画に従うことよりも，変化への対応を

平成21年度事例調査中大規模(30名〜)の事例はなかった

協調とコミュニケーションを重視して動くソフトウェアを

成長させながら変化に対応する

スウィートスポットは大規模開発ではない

近年、国内での大規模事例が増えてきた。

海外では大規模事例も紹介されつつある

※:http://agilemanifesto.org/iso/ja/




中・大規模開発事例の調査：事例一覧

No. 規模

部分適用

採用手法対象システム種別契約

1 大独自 B2Cサービス (SNS) 無(自社内)

2 大 Scrum B2Cサービス (ソーシャルゲーム) 無(自社内)

3 大 ○ Scrum ゲームソフト受託(未公開)

4 大 ○ Scrum+独自基幹システム受託(準委任)

5 中 Scrum B2Cサービス (会員サービス) 無(自社内)

6 中 Scrum+XP B2Cサービス (医療・健康) 無(自社内)+オフショア*

7 中 Scrum+XP B2Cサービス (エンタテインメント) 無(自社内)+オフショア*

8 中 XP B2Cサービス (会員サービス) 受託(請負)

9 中 ○ XP B2Cサービス (ECサイト) 受託(請負)

10 中 ○ XP B2Cサービス (会員サービス) 受託(準委任)

中規模：30～100名，大規模：100名以上独自：特に手法を決めず自ら定義，Scrum+XP：両手法を組み合わせて実践

*：準委任




適用にあたっての主な工夫(1/3) （一覧）

中・大規模開発特有の工夫

組織体制チーム間ローテーション

コミュニケーション段階的朝会チーム跨ぎのふりかえり

展開漸進的な人数増加漸進的な展開社内勉強会

分散拠点開発同一拠点から分散へ TV会議

アーキテクチャ組織の共通基盤アーキテクチャの利用アーキテクチャについての教育

システム分割/インテグレーション同じリズム

小規模開発と同様だが特に注意して実施する工夫

コミュニケーション完全透明性

展開パイロット導入認定研修・コンサルタントの利用

分散拠点開発チケットシステムリアルタイムチャット

アーキテクチャアーキテクチャの改善

システム分割/インテグレーション疎結合で分割早期からのインテグレーション継続的インテグレーション

品質重視するビジネス価値ビジネス価値の変化タイムボックス優先の品質自動単体テスト

小規模開発とは逆のアプローチをとる工夫

アーキテクチャ最初のアーキテクチャ構築アーキテクチャ専門チーム運用保守チーム

品質テスト・フェーズ

品質第三者テスト

部分適用必要な部分のみ適用疎結合なチーム工程の見える化


詳細は付録に



適用にあたっての主な工夫(2/3)

チーム間ローテーションチーム間の知識伝播促進のため，メンバのローテーションを行う．一時的に速度は落ちるが，各チームの知識を効率よく伝播でき多能工化が高まる．

段階的朝会複数チーム間は朝会を段階的に実施．チーム→全体（→チーム）．

漸進的な展開一度にすべてのチームに広げるのではなく，まずは導入障壁の低いところ，最も必要なところから順次導入し，少しづつ展開．ふりかえりで，次はどこに広げていけばいいかを考える．

コミュニケーション・ツールの活用 TV会議システム，雑記帳システム（SNS，Blog等）

工夫例(1/2)




適用にあたっての主な工夫(3/3)

アーキテクチャの重視プロジェクト前半にアーキテクチャを構築する事例が多く，アーキテクチャ専門チームを編成して構築．構築されたアーキテクチャを組織の共通基盤とし，再利用できるようにしている事例あり．

疎結合な機能分割疎結合な機能でサブシステム分割を行う． 7割のチームがCI(継続的インテグレーション)を実施．

テスト専用フェーズプロジェクト後半で専用のテストフェーズを実施．プログラム開発の反復を停止する事例と，テストのみの反復期間を設ける事例あり．

工夫例(2/2)



Software Engineering Center 106 Copyright © 2009-2012 IPA, All Rights Reserved.

浮かび上がった問題点

全体計画の把握困難要求の変化や開発状況に応じて着手する順番や範囲を決めるため，プロジェクト開始時にプロジェクト全体の把握が困難な事例あり．

ビジネス企画側にボトルネック発生スクラム導入の結果，ビジネス企画者の決定待ち等のボトルネックが発生した事例が多い．中には開発者の信頼をなくした事例もあり．

反復リズムとの不適合状態の発生セキュリティ監査や外部テスト業者，発注者の外部組織や関連組織との関係において，反復リズムと適合せずに問題が発生している事例あり．

主な問題点




6. 適切な開発手法の選択

（まとめに代えて）




適切なシステム/ソフトウェア開発手法の選択

計画性・確実性・安定性変化への適応性・迅速性

開発対象の性質開発組織の環境条件

・ビジネス上の段階・システムの深刻度・要件の固まり具合、変化の度合い・開発対象の成熟度 - 新規開発、改造、再構築、保守・アーキテクチャの成熟度・規模の大小

・手法に対する組織の経験、成熟度・手法に対するメンバの慣れ、成熟度・組織の制度、統制・組織の地理的分散・組織の風土 - 新しい試みに対する挑戦の空気 - 経営/マネジメント層の理解と支援





開発（構築）手法の選択


俊敏な開発(構築)手法

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

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

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

環境の変化に対する俊敏な開発(構築)が求められる場合

作らないで，使う

パラメータを変更するだけ

少しずつ作って，確かめながら

1つのシステム全体を単一の手法で開発（構築）する

ことが適切ではない（かもしれない）異なる手法で開発した部品の組合せ？



システム規模・ 0．．１２．．３００（開発メンバー数）

深刻度・シンプル、経済被害、．．．人身事故

システムの成熟度・新規開発、レガシー保守

要件の変化率・低、中、高

ビジネスモデル・自社開発、オープンソース、．．．

アーキテクチャ・安定、変化した、新しい

チームの分散・一か所、．．、オフショア、外部委託

統制・単純なルール、．．．、SOX、．．．

フィリップ・クルーシュテン（Philippe Kruchten）の講演(2009.12)より

参考


アジャイル型開発のスイートスポット（例１）



Figure 1. A financial model of software product development.

<出典> Ram Chillarege: The Marriage of Business Dynamics and Software Engineering, IEEE SOFTWARE, November/December 2002.

ソフトウェア製品のライフサイクル・モデル例と開発手法

参考

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

ビジネス・ステージと開発手法




対象の性質に応じたマネジメントの考え方


<出典> 日本マイクロソフト株式会社，TFSUG監訳：「アジャイル・ソフトウェアエンジニアリング」日経BP社，2012年． The Stacey Matrix: http://www.gp-training.net/training/communication_skills/consultation/equipoise/complexity/stacey.htm

（要件の）合意

（経験等に基づく）判断の確からしさ

カオス状態

ビルや橋の建設

ネット上でのコンテンツ検索・販売サイトの開発

作るものも使用する技術も明確

計画時には，ビジネス上，システム上の課題が未解決，開始後も変更の可能性大・コンテンツの品揃え，値付け・割引き，特典等の顧客サービス・検索機能・ユーザインタフェース・顧客管理データの内容，等々

最初から綿密な計画を立てるより，少し試して，その結果に基づいて次のステップを進める．



開発手法の選択であるが．．．

自分たちの開発対象は、どんな性質か？

自分たちの置かれた環境はどうか？

自分たちの状況に最も合うのは、どの開発手法か？

開発対象の性質開発組織の環境条件

状況に適した開発手法


変化する



開発対象の性質：境界線の変化傾向

計画性・確実性・安定性変化への適応性・迅速性

開発対象の性質

・ビジネス上の段階・システムの深刻度・要件の固まり具合、変化の度合い・開発対象の成熟度 - 新規開発、改造、再構築、保守・アーキテクチャの成熟度・規模の大小



変化

従来の境界線今後の境界線

ハイブリッド型の採用も増加

傾向


Software Engineering Center 115 2012-08-25 ITC近畿会/IPA共催セミナー Copyright © 2009-2012 IPA, All Rights Reserved.

<出典> 特集1：ここがヘンだよ日本のシステム開発 - 楽天日本と米国のいいとこ取り，日経SYSTEMS，2012年8月号，no.232，7月26日発行．

日本で仕事をし始めて最も驚いたのは，全ての部分を完全なものにして

からリリースすることです．極めて細かいテストケースを多数作って，完璧に

実施していきます．それにより得られる品質の高さは，日本の開発において

最も素晴らしい点の一つです．米国では，ある程度のところまでいったらリ

リースして，不具合が生じたら修正していきます．一時的にうまくいかない

場面が生じますが，全体として開発が早く進みます．

日本と米国のいいとこ取りをして，高品質はそのままに開発速度を高める

ことを目指しました．そのために，品質保証（ＱＡ）部門が手作業で行ってい

たＱＡテストの自動化に取り組みました．

参考楽天における工夫例



Source: VERSIONONE: State of Agile Survey 2011

・スクラム系が多い・カスタム・ハイブリッドも伸びている

参考ハイブリッド型の適用が進む（１／２）




28 percent of 450 software professionals said they use a hybrid approach. Another 12 percent use lean software development, which includes agile processes.

Source: 2011 Agile ALM and Testing Survey, SearchSoftwareQuality.com Of 4,770 respondents from 91 countries, 90 percent said they use some form of agile. Only 27 percent of respondents solely use one type of agile, while 35 percent mix agile with waterfall, and 39 percent mix agile with Scrum.

Source: Analysis.Net and VersionOne Source: PM NETWORK, January 2012, Vol. 26, No. 1

参考ハイブリッド型の適用が進む（２／２）




Source: PM NETWORK, September 2011, Vol. 25, No. 9

無し広範囲に

選択的に

参考対象に応じてアジャイル手法を（部分）適用


プロジェクト管理にアジャイルのプラクティスを使う程度



• Successful: delivered on time, on budget, with required features and functions • Challenged : late, over budget, and/or with less than the required features and

functions • Failed: cancelled prior to completion or delivered and never used

出典： CHAOS MANIFESTO 2011

目標QCDの全ては満たせず

プロジェクト途中でキャンセル

当初QCD目標通り完了

参考リスクを軽減するアジャイル手法（１／２）


プロジェクトの結果（成功/失敗）に関する調査例



参考リスクを軽減するアジャイル手法（２／２）


アジャイル手法をうまく使い，リスクを軽減している

開発手法によるプロジェクト成功/失敗の比較



開発組織の環境条件：求められる“変化”


・手法に対する組織の経験、成熟度・手法に対するメンバの慣れ、成熟度・組織の制度、統制・組織の地理的分散・組織の風土 - 新しい試みに対する挑戦の空気 - 経営/マネジメント層の理解と支援

開発組織の環境条件

ユーザ経営層の意識

ベンダ経営層の意識


契約形態



アジャイル型開発手法の導入拡大の障壁（海外）

52%

40% 39%

34%

30% 27% 26%

14% 14%

0%

5%

10%

15%

20%

25%

30%

35%

40%

45%

50%

組織文化の

変化能力

変化への

一般的な抵抗

アジャイル

経験者不足

マネジメントの

支援

プロジェクトの

複雑さ･

規模

顧客の協力

規模拡大への

対応の自信

移行までに

許される時間

予算の制約

１．組織文化の変化能力２．アジャイル経験者不足３．変化への一般的な抵抗


参考




アジャイル型開発プロジェクトの失敗理由（海外）

13% 11% 11%

9% 8% 7%

6% 6%

0%

5%

10%

15%

20%

25%

企業哲学又は

文化との相性

手法への不慣れ

分からない

従来型開発採用

への外部圧力

文化的な移行の

欠如

ビジネスと開発

の相互不信

初めてのために

プロジェクト未完

１．（分からない）２．手法への不慣れ３．組織変化への不理解


参考


組織変化に

対する不理解

16% （ :

失敗なし）



http://www.ibm.com/smarterplanet/us/en/business_analytics/article/agiledevelopment.html For many organizations, teams and individuals, the transformation to an agile development process is challenging. That’s because it requires a cultural change.

Agile transformation


参考アジャイル開発への転換

多くの組織，チーム，

個人にとって，アジャ

イル開発プロセスへ

の転換は“挑戦的”

である．それは，ある

種の文化的変革を

必要とするからだ．

「アジャイルは，プロセスではなく文化である．」 Michael Sahota: “An Agile Adoption and Transformation Survival Guide: Working with Organizational Culture,” 2012.



異文化の協働によるプロセス・イノベーション

プロセス・イノベーション

パフォーマンス

アクティビティ

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

プロセス改善プロセス改善

ウォーターフォールとアジャイルとの協働により，プロセス・イノベーションを！




SWE iPedia (ソフトウェア・エンジニアリング情報データベース)




●ご質問、ご意見は、ＳＥＣホームページからお願い致します。

ご質問・意見の宛先




IPA/SECホームページ： http://sec.ipa.go.jp/index.html

ご清聴，ありがとうございました




参考. 各種調査データ（追加分）




2012年秋刊行予定

日本ではまだアジャイル手法の利用は少ない（１）

N=2957

反復型 2.4％

その他 1.1％

ウォーターフォール型 96.5％

反復型 2.7％

その他 1.2％

ウォーターフォール型 96.1％

N=2451 ソフトウェア開発データ白書2010-2011 ソフトウェア開発データ白書2012-2013


参考



日本ではまだアジャイル手法の利用は少ない（２）

出典：平成22年度ソフトウェア開発管理基準に関する調査報告書（ソフトウェアメトリックス調査）

（経済産業省） http://www.meti.go.jp/policy/mono_info_service

/joho/softwaremetrics/2010/index.html


参考

出典：平成23年度ソフトウェア開発管理基準に関する調査報告書（ソフトウェアメトリックス調査）（経済産業省）

http://www.meti.go.jp/policy/mono_info_service/joho/softwaremetrics/2011/index.html [予定]

ウォーターフォール型 577 88％

ウォーターフォール型 712 89％



米国におけるアジャイル開発の採用状況

2010年に発表された，米国調査会社フォレスター・リサーチ社のレポートによる，米国のアジャイル開発利用率

参考




アジャイル開発におけるコミュニケーション（１／５）参考

平均17人

100人以上を除くと平均10.1人

出典: Ambysoft Agile Teams Mini-Survey Results: April/May 2011

N=82


アジャイル開発チームの大きさ



アジャイル開発におけるコミュニケーション（２／５）参考

同室

同フロア

同建物

何人かは3時間以上

3時間以内

47% were co-located,

23% near located, and

30% far-located.

N=82


アジャイル開発チームメンバ間の距離



アジャイル開発におけるコミュニケーション（３／５）参考

9% were co-located,

56% near located,

and 35% far located.

同室

同フロア

同建物

何人かは3時間以上

3時間以内

N=82


ステークホルダ（顧客側）との距離



アジャイル開発におけるコミュニケーション（４／５）参考

58% indicated at least daily communication and an additional 36% indicated at least weekly communication.

N=82

1回/週

数回/週

終日

毎日


顧客側とのコミュニケーション頻度



アジャイル開発におけるコミュニケーション（５／５）参考

50%以上電子メール Face-To-Face 反復終了後のデモリポジトリホワイトボードドキュメンテーションオンライン・チャットプレゼンテーション

N=82


顧客側とのコミュニケーション手段



出典：企業IT動向調査2011 (JUAS)

参考最重点テーマは「リアルタイム経営」（１／２）




最重点テーマは「リアルタイム経営」（２／２）

出典：サプライチェーンの可能性を求めて， http://www.bizdyn.jp/report/scm01/scm01_029.html

時間間隔を短縮し，状況の観測（計測）と判断行動（制御）とを同時並行で実行すること ↓ 限りなく連続のリアルタイムのSCMは，そうでない場合に比べ，過剰在庫と機会損失を大幅に削減可能．

サプライチェーンマネジメント(SCM)における「リアルタイム経営」

IT戦略に適用すると

アジャイル開発

参考




リスクを軽減するアジャイル手法（３／３）事例

最初はウォーターフォール型で開発をスタートしたが，途中でアジャイル型（スクラム）に切り替え，成功した．

1. Used an iterative process 2. Used steppingstones and small, concerted deliverables 3. Used short time boxes 4. Used a flexible process 5. Had constant user interaction 6. Used the right agile style for their organization 7. Had rapid feedback 8. Had end-of-iteration retrospectives 9. Performed constant refactoring 10. Used a feature pipeline

出典： CHAOS MANIFESTO 2011


事例分析：Total Attorneysの弁護士紹介システム



Faultsの混入，発見，除去




付録




進化的設計

テスト駆動開発

テスト駆動要求

<出典> Amr Elssamadisy: Patterns of Agile Practice Adoption, C4Media Inc., 2007.

参考例プラクティスの分類例




Figure 3 Cost of Change Curve with Waterfall and Evolutionary Design

参考例変化対応のコスト



Business Value

Clusters of Agile Practices

Agile Practice Patterns

Reduce time to market

Test-driven Development, Evolutionary Design, Test-driven Requirements

Simple Design, Refactoring, Test- First Development, Test-Last Development, Continuous Integration, Functional Tests

Increase value to market

Test-driven Requirements

Functional Tests

Increase quality to market

Test-driven Development, Test- driven Requirements, Evolutionary Design

Test-First Development, Test- Last Development, Refactoring, Simple Design, Continuous Integration

Practices and Clusters that Improve Business Value

Increase flexibility

Evolutionary Design, Test-driven Development, Test- driven Requirements

Automated Developer Tests, Refactoring, Collective Code Ownership, Functional Tests

Increase visibility

Test-driven Requirements

Functional Tests, Continuous Integration

Reduce cost Evolutionary Design, Test-driven Development, Test- driven Requirements.

Simple Design, Refactoring, Collective Code Ownership, Test- First Development, Test Last Development, Functional Tests

Increase product lifetime

Test-driven Development, Evolutionary Design, Test-driven Requirements

Refactoring, Automated Developer Tests, Functional Tests, Simple Design


参考例ビジネス価値を高めるためのプラクティスとクラスタ



<出典> Jez Humble & Rolf Russell: THE AGILE MATURITY MODEL APPLIED TO BUILDING AND RELEASING SOFTWARE, ThoughtWorks, Inc., September 2009.

参考例アジャイル成熟度モデル



事例集（SECセミナーより）(1/3)


アジャイル開発を適切に採り入れるためのポイントとアジャイル開発の事例 2011年7月8日(金) http://sec.ipa.go.jp/seminar/2011/20110708.html [1]反復開発からアジャイルへプロジェクト管理勘所の違い株式会社豆蔵堀江弘志氏 [2]XPによる金融システム業向け大規模開発適用事例と最先端ソーシャルWebシステム開発適用事例のご紹介アジャイルウェア代表川端光義氏 [3]ＤｅＮＡのソーシャルゲーム開発における事例 (40分) 株式会社ディー・エヌ・エー稲村直穂子氏

アジャイル開発を適切に採り入れるためのポイントとアジャイル開発の事例【1】 2011年10月4日（火） http://sec.ipa.go.jp/seminar/2011/20111004.html ■ 新しい契約形態での受託開発実践記～価値創造契約へのチャレンジ～株式会社永和システムマネジメント木下史彦氏 ■ BIGLOBEにおけるスクラム開発の導入事例 NECビッグローブ株式会社杉森隆行氏

アジャイル開発を適切に採り入れるためのポイントとアジャイル開発の事例【2】 2011年12月9日（金） http://sec.ipa.go.jp/seminar/2011/20111209.html ■ アジャイル開発の事例に学ぶ株式会社情報システム総研原田騎郎氏 ■ はじめてのアジャイル開発取組み事例株式会社豆蔵堀江弘志氏

参考








JASA主催/IPA共催セミナー【第8部】「エンタ系セミナーⅣ」 2011年11月18日(金) http://sec.ipa.go.jp/seminar/2011/20111118d.html ■ 初めての取組み事例に見るアジャイル導入の勘所株式会社豆蔵堀江弘志氏

参考

アジャイル開発の取組み事例に学ぶ 2012年1月16日（月） http://sec.ipa.go.jp/seminar/2012/20120116.html （1）アジャイルマインドにあふれるチームの育み方株式会社ハウインターナショナル高橋剛氏（2）新しい契約形態での受託開発実践記～価値創造契約へのチャレンジ～株式会社永和システムマネジメント木下史彦氏（3） BIGLOBEにおけるスクラムチーム作り NECビッグローブ株式会社安西剛氏（4）はじめての取り組み事例に見るアジャイル要素の導入事例株式会社豆蔵山田悦朗氏

http://sec.ipa.go.jp/seminar/2011/20111118d.html






JASA【SEC特別セミナー】俊敏なビジネスに貢献するアジャイル型開発を知る 2012年4月11日（水） http://sec.ipa.go.jp/seminar/2012/20120411.html 【事例1】アジャイル開発から継続的デリバリーへ株式会社NTTデータ柴山洋徳氏【事例2】IT新市場開拓プロジェクトにおけるアジャイル開発富士通株式会社山口真幸氏株式会社富士通ソフトウェアテクノロジーズ神部知明氏

参考

日本におけるアジャイル開発に適した契約モデル案と事例 2012年5月23日（水） http://sec.ipa.go.jp/seminar/2012/20120523.html ■ 顧客との緊密な協働によるアジャイル型開発の成功により高い信頼を得た事例株式会社プロビズモ女鹿田晃和氏





ビジネス環境の変化とITシステムの対応

時間→

環境

予測可能な環境変化量

変化対応のシステム開発期間これまでの変化の状況

最近の変化の状況

★システム完成

短縮が必要

変化が進んでしまっている




アジャイル開発に関する国際(ISO)標準(1/2)

＜得られた知見＞

・アジャイル開発が何を意味するかに関しては，さまざまな解釈がある．

・アジャイル手法，技法，実践規則の採用は，増加し，既に広く普及している．しかし，採用における初期の試みは，ごく一部でしか成功していない．

・アジャイル手法は，「どのように(how)」ソフトウェア・システムエンジニアリング・アクティビティを実施すべきか，に焦点を当てているが，関連するSC7ソフトウェア・システムエンジニアリング標準は，「何を(what)」実施すべきか，実施すべきプロセス（アクティビティ）の目的，意図されている効果(outcomes)，プロセス及び形成/改変されたプロダクト計量法に焦点を当てている．

・アジャイル手法は，主要な関連ソフトウェア・システムエンジニアリング標準とは抵触しない．

・アジャイル手法を採用するかどうかは，多くの場合，テクニカルな専門職によって決定され，ビジネス責任者は，その成功のためにビジネスが関わらなければならない水準(business engagement level)を理解していない．

・アジャイル手法を利用して開発した場合，会計システムに対する第3者認定が，認定者が必要とする文書欠落のため，受けられない可能性がある．

・アジャイル手法の適用には，ビジネスや組織の文化等に関する適合すべき状況がある．

・アジャイル手法の適用が成功するためには，その基礎とする価値及び原則の適用や開発メンバのスキル等の因子で成功する必要がある．

参考




アジャイル開発に関する国際(ISO)標準(2/2)

出典：アジャイル開発に関するISO標準またはガイダンス策定の必要性（松本吉弘訳） Study Group Report on the possibility of new standards or guidance in

the area of Agile Development (ISO/IEC /JTC 1/SC 7/N4289, 2009-04-19)

＜SC7標準との関係＞

・現時点では，アジャイル手法，技法及び実践規則に限定して対処しているSC7標準は存在しない．

・ISO/IEC12207やISO/IEC15288 のライフサイクルモデルが適用されているあるいは適用が要求されている組織において，アジャイル手法が利用されることを妨げるものではない．

・ISO/IEC15504（プロセス評価）やISO/IEC15939（計量プロセス）がアジャイル開発において使われることは差し支えない．

・SC7標準に精通していて，アジャイル手法及び技法を採用しようとしている組織は，ISO/IEC12207という裏付け(context)の中で，ガイダンス（現時点では，存在しない）に従って，それを適用することが望ましい．

・SC7標準に精通していて，アジャイル手法及び技法を採用しようとしている組織は，ISO9001という裏付けの中で，（可能であれば，ISO/IEC9003で使われているのと似たやり方を使って，）ガイダンスに従ってそれらを適用することが望ましい．

参考




国際標準化：最近の動き(1/2)

ISO/IEC 29110: Software Engineering ― Lifecycle Profiles for Very Small Entities (VSEs)

小規模企業向けのソフトウェアライフサイクル

国際的にみて，ソフトウェア開発のかなりの部分が多数の中小零細企業によって担われている

中小零細ソフトウェア企業にとり，既存のソフトウェアエンジニアリング規格総体へのアクセス及び社内採用は高負荷であるものの，一定の水準確保はやはり必要である

中小零細ソフトウェア企業の良い特性（特定のコンピタンシーやコミュニケーションが密といった点）に配慮する視点も必要である

小規模企業のソフトウェアプロセスの現実的な必要事項を明確化する

小規模企業のさまざまな規模，特性を表現するために「プロファイル」という特性区分を設け，それぞれのプロファイルごとに必要事項を整理する

参考




DoD プロジェクトでもアジャイル開発の利用例が増えている(*)といったことが提案理由となっている

国際標準化：最近の動き(2/2)

プロファイル例（Part2から）

Entry Profile

Basic Profile

Intermediate Profile

Advanced Profile

成立

作成中

作成中

未定

例：アジャイル開発への適用： WG24 ガイザースバーグ会議議事録から

“Prepare the work plan and finish the work for the agile implementation project.”

出典：伏見諭（情報規格調査会SC7/WG24主査）： ISO/IEC 29110の背景とJIS化への取り組み - 規模ソフトウェア開発組織のソフトウェアプロセス規格– （第１回VSEセンターフォーラム，2011.6.15）

参考

(*) Defense Procurement Goes Agile by Jesse Fewell on October 2, 2009 http://www.jessefewell.com/2009/10/02/defense-procurement-goes-agile/




各種知識体系等におけるアジャイル開発の取込み

CMMIバージョン1.3へのアジャイル開発の反映アジャイルに関する導入ガイドラインと導入における注意、どのようにアジャイル・プラクティスを解釈すべきかを含む．また，ユーザーストーリー，プロダクトバックログ，ストーリーカード，ペアプログラミング，日次（頻繁な）ビルド，ふりかえり，等のプラクティスにも言及．

米国PMI（PMBOK発行）の中に，Agile Community of Practiceを設立（2009年） PMI Agile Certified Practitioner(PMI-ACP)SMの開始（2011年第3四半期）を発表 http://www.pmi.org/en/Certification/New-PMI-Agile-Certification.aspx

プロジェクトマネジメント(PM)におけるアジャイル開発のマネジメントは日々重要さを増しており，多くのPM専門家が仕事に使えるアジャイル技術を習得したいと熱望．プロジェクト経営環境におけるこのような変化への対応のため，PMIが導入を決定．

IIBAがBABOKアジャイル拡張版を発表（2010年）ビジネスアナリシスの中核的活動である，「エンタープライズアナリシス」，「要求アナリシス」，「リューションのアセスメントと妥当性確認」を含めた知識エリア全体にアジャイル開発の考えを反映．

BABOK Version3.0に知識エリアの全体構造の再構想を含めたアジャル開発への対応を計画（2011年4月以降）


参考



PMI Agile Certified Practitioner(PMI-ACP)SM

PMIが，新しいアジャイル認証

PMI Agile Certified Practitioner(PMI-ACP)SM

の開始（2011年第3四半期）を発表 http://www.pmi.org/en/Certification/New-PMI-Agile-Certification.aspx

参考

<Tools & Techniques> Communications Planning, monitoring and adapting Agile estimation Agile analysis and design Product quality Soft skills negotiation Value-based prioritization Risk management Metrics Value stream analysis

<Domains> I. Value-Driven Delivery II. Stakeholder

Engagement III. Boosting Team

Performance Practices IV. Adaptive Planning V. Problem Detection and

Resolution VI. Continuous

Improvement (Product, Process, People)




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

育成開始

スキル診断

卒業検定

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

開発技術(基礎知識) プロジェクト

キックオフ

ルーキーズ

セミナー

模擬開発

開発開始

・構成管理 / その他ツール・テスト駆動開発・オブジェクト指向プログラム / 設計・Java言語 / Eclipse

1日 2～3日 5日

開発メンバ育成開発チーム育成

OJT

・自己紹介

・チームビルド

・開発環境知識獲得

・業務知識

・フレームワーク

・開発標準

・アジャイル基礎知識

・サブチーム単位に行う・作ったものは捨てる

・開発者向け・ストーリーオーナー向けも別途行う

・プロジェクト憲章

・行動指針

・アジャイル概要

・開発できるレベルまで育てる

組閣

参画・プロパー・プロダクトオーナー・パートナー

プロジェクト立上げ




○：立上げ前後の必須教育の領域 △：事前に準備が困難でOJTが必要な領域＊：内容を組織内で個別に検討する必要がある領域

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

開発チーム

スクラムマスター

顧客／プロダクトオーナー

先行チーム

リーダー PM 経営者層／購買担当など

アジャイル概要 ○ ○ ○ ○ ○ ○ ○

アジャイル基礎知識 ○ ○ ○ ○ ○ ○

アジャイル擬似体験 ○ ○ ○

業務知識 ○ ＊ ○

開発環境 ○ ＊

基本アーキテクチャ ○ ＊

業務分析／モデリング △ △

開発技術 △ ＊

ファシリテーション概要 ○ ○ ○ ○ ○ ○

ファシリテーション演習 ○ ○ ○

アジャイル開発を初めて行う組織を対象




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

名称概要

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

アジャイル基礎知識一般的なプラクティスについての紹介

アジャイル擬似体験アジャイル開発のプロセスを体験を通して理解するチームビルディング的な狙いもある

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

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

基本アーキテクチャ開発対象のシステム構成や、利用するフレームワークなどを理解する(内容は先行チームと検討)

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

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

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

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




Figure 1. A financial model of software product development.


ソフトウェア製品のライフサイクル・モデル

参考ビジネス・ステージと開発手法（１／３）




Figure 2. Innovation and predictability shift in importance over a product’s life cycle. The x axis isn’t to scale, and the growth stage can be much longer than it appears here.

ビジネスステージに応じて変化する，ビジネス価値の要因

参考ビジネス・ステージと開発手法（２／３）





ビジネス価値要因（ビジネスステージに応じ変化）に整合した開発手法を

参考ビジネス・ステージと開発手法（３／３）




使われている開発モデルの調査例（３）

出典：第17回企業IT動向調査2011（10年度調査）（2011．5．17，社団法人日本情報システム・ユーザー協会）




使われている開発モデルの調査例（４）

出典：第17回企業IT動向調査2011（10年度調査）（2011．5．17，社団法人日本情報システム・ユーザー協会）




ＩＴ企業の各ＩＴ業務を担当するＩＴ人材に不足している「質」ユーザ企業の各ＩＴ業務を担当するＩＴ人材に不足している「質」(1)

企業とIT人材個人の意識の違い

自分自身に，最も不足しているスキルや知識自分自身に，具体的に特に不足しているスキルや知識

ユーザ企業の各ＩＴ業務を担当するＩＴ人材に不足している「質」(2)

参考調査データから：IT人材白書2012(IPA)



動かぬIT人材


田中理事は「（求められている人材は）今回の調査からも、これまでIT技

術者の最も多かった受託開発業務ではないという傾向が明らかになって

いる。それもアジャイル開発で、自分で仕様書を書けるにとどまらず、自ら

企画して手が動く人材が求められている。クラウドなどにも積極的に取り

組み、SaaSのサービスのインプリメントを積極的に行うといった変化を遂

げれば、日本のIT技術者の将来は決して暗いものではない」と、旬な技

術にいち早く取り組む姿勢の重要性をあらためて強調した。

<出典> ITの変化に技術者の対応が遅れている--IPAのIT人材白書2012 （ZDNet Japan, 2012年05月14日） http://japan.zdnet.com/development/analysis/35016977/

「IT人材白書2012 ～行動こそが未来を拓く進むクラウド、動かぬIT人材～」の概要から

参考



経営層への可視化（１／３）

サービスシステム/ソフトウェア

仕様実装

メニュー１機能１コード群１

メニュー２機能２コード群２

メニュー３機能３コード群３

メニュー４機能４コード群４

メニュー５機能５コード群５

優先順位

ライバル社は，まもなくサービスを開始すると発表した．わが社も，早期にサービスを提供しないと，シェアを奪われてしまう．

アジャイル型開発の採用

Ｄ社Ｓ社


配布用



経営層への可視化（２／３）

５

４

３

２

１

５

４

３

２

１


1 2 3 4 5 か月後 1 2 3 4 5 か月後

←

完成度

←

進捗度

←

完成度

←

進捗度

1 2 3 4 5 か月後 1 2 3 4 5 か月後

外 (経営層) から見ると

内 (開発側) での実際は




経営層への可視化（３／３）

５

４

３

２

１

５

４

３

２

１

外 (経営層) から見ると

内 (開発側) での実際は


1 2 3 4 5 か月後 1 2 3 4 5 か月後

←

完成度

←

進捗度

←

完成度

←

進捗度

1 2 3 4 5 か月後 1 2 3 4 5 か月後

段階的に順次リリース可能





ﾘﾘｰｽ内では進捗度を報告しにくい

•コーディング○％終了 •レビュー□％完，．．．

いつでも計画対応の進捗度を報告可

•機能ｎ完成，．．．

経営層は理解と覚悟が必要 2012-08-25 ITC近畿会/IPA共催セミナー Copyright © 2009-2012 IPA, All Rights Reserved.



機能6

機能5

機能4

機能3

機能2

機能1

機能群

時間

一括リリース

要求テスト開発 →運用

機能利用率

参考ウォーターフォール型開発のイメージ

あまり使われない機能も実装しがち




機能6

機能5

機能4

機能3

機能2

機能1

機能群

時間

機能1 再リリース

要求

テスト

開発

→運用

機能利用率

機能2 リリース


機能１リリース


・・・

参考アジャイル開発のイメージ

使用される機能のみを優先して実装

利用者の評価を反映

ある機能の可視化により,次の機能の要求明確化を加速




0

1

2

3

4

5

6

7

1 2 3 4 5 6 7 8 イテレーション(スプリント)期間（週）

事例の数

（件）

その他：1～2週間 2件 1～4週間 1件

⇒1～2週間が中心

参考事例：イテレーション(スプリント)の期間


H21年度事例収集(1)の集計結果



事例調査結果①(1/2)

小売業における業務システム開発事例小売業を営む顧客のマーチャンダイジングシステム開発を出発点に、

これまでに260メニュー、80万ステップの開発

項目内容

優先したIT戦略開発当初の目的は、既存システムの完全リプレイス

ライフサイクルモデルユーザヒアリング → データ設計およびサンプルプログラム開発 → 構築（イテレーション期間）

チーム編成ベテラン開発者1名＋新人5名顧客側にも同数程度のプロジェクトメンバを配置

プロジェクト期間 6ヶ月

プロジェクト初期における要件の確定度合い

外部仕様レベルでの基本要件は固まっていた要求の確認は、ユーザとの会話と実際に動作するプログラムで行う

契約形態請負契約ではなく、顧客の開発業務を支援する形態




特性レーダーチャート

0

1

2

3

4

5

チームにおける、「平均レベル以下の、経験は少ないが、勤勉な開発者」の割合

チームにおける、「非ウォータフォールまたはウォータフォール型開発のプロジェクトをマネジメントできる人」の割合

Time-to-marketの時間的制約の厳しさ

組織文化

アプリケーションシステムの重要度の高さ

要求された稼働率の高さプロジェクト期間の短さ

プロジェクト初期における要件の確定度合いの低さ

新規性(ビジネス)の豊かさ

新規性(技術)の豊かさ (

開発人数の多さ

事例調査結果①(2/2)




事例調査結果②(1/2)

携帯ソーシャルゲーム開発事例これまで多くのWebサービスをアジャイル型で開発してきた企業によるもの

項目内容

優先したIT戦略スピード、要求の変化への対応、利用率を優先

ライフサイクルモデル α版開発（1.5ヶ月） →α版改修（0.5ヶ月） →β版開発～クローズドβ公開（0.5ヶ月） → β版改修～全展開（0.5ヶ月）イテレーション期間：1～2週間サービスイン後もDay～Week単位で改版継続

チーム編成企画1名、エンジニア1名後半、業務系開発にベンダ1名追加

プロジェクト期間 3ヶ月～継続中


ゼロベースからの検討を要した

契約形態社内開発であるため、契約関係はない。






Time-to-marketの時間的制約の厳しさ


新規性(技術)の豊かさ

プロジェクト期間の短さ

要求された稼働率の高さ


事例調査結果②(2/2)




事例調査結果③(1/2)

株取引のためのWebアプリケーション開発事例 “セル”と称する小集団の枠組みにより開発

項目内容

優先したIT戦略投資回収を早めるため早期ビジネス化。システム利用者の反応を見ながら構築。情報システム部門の負荷軽減、数年間は利用。品質要求は保守性を最優先・使いやすさと応答の即応性

ライフサイクルモデル

セル開発、収益性の高い機能から開発イテレーションは2週間

チーム編成

小集団(セル)の枠組み顧客と2週間に1回、受け入れ検収を実施

プロジェクト期間 23ヶ月


非常に低い

契約形態

請負。対象となるシステムのスコープや品質基準とイテレーション回数と各イテレーションで平行稼動させるセル数を基準




事例調査結果③(2/2)

株取引のためのWebアプリケーション開発事例






事例調査結果④(1/2)

業界共通電子データ交換基盤構築事例要件提供者が多数存在するため、システム構成をモジュール化し、

要件の固まったモジュールから順に開発

項目内容

優先したIT戦略業界標準、共通画面・共通操作が可能、企業間システム連携、基本機能は無償、中小企業用の標準システムの構築短期開発を可能にするためのシステムのモジュール構造化

ライフサイクルモデル初期プロトタイプの開発後、ユーザレビュー・機能拡張を継続 EDI基盤のコアの部分をはじめに固め、サブを順次追加 2週間単位のイテレーション

チーム編成 15名（リーダ：1、仕様担当：5、設計担当3、開発担当：6）

プロジェクト期間初期プロトタイプの開発に3ヶ月


多業種にわたるシステムであるため、開発当初は仕様が全く分からない、かつ固められない状態

契約形態準委任契約





0

1

2

3

4

5 チームにおける「非ウォータフォールまたはウォータフォール型開発のプロジェクトをマネジメントできる人」の割合

Time-to-Marketの時間的制約の厳しさ

組織文化

要求された稼働率の高さ


新規性(技術)の豊かさ

開発人数の多さ


プロジェクト期間の短さ


チームにおける、「平均レベル以下の、経験は少ないが、勤勉な開発者」の割合

事例調査結果④(2/2)




適用分野

B2Cサービス, 83%

市販ゲーム

ソフト,

9%

基幹システム, 8%

システム種別

自社開発,

41%

自社開発

(一部ｵﾌｼｮ

ｱ),

17%

受託開発

(準委任),

17%

受託開発

(請負),

17%

受託開発

(非公開),

8%

契約関係

• 大半 (80%以上) がインターネット上のB2Cサービス開発に適用

• 半数以上が自社組織内に開発部隊を抱える形態 (事業者と開発者の間に契約関係がない形態) を採用


中大規模開発調査



（参考）非ウォーターフォール型開発の採用理由

実際のサービスや製品を見ないとビジネス価値を評価できない

理由 No.3 市場や社会の変化に対応したい

理由 No.2 管理コストを下げたい

ウォーターフォール型開発でプロジェクトが失敗した

理由 No.1 要件が固められない

非ウォーターフォール型開発の選択

うまくいった

25%

かなりの部分

でうまくいった

12%

うまくいった

部分もある

が、

うまくいってい

ない面もあ…

効果は… 1. 動くモノを見ながら開発できた 2. 管理コスト削減 3. 迅速なサービスの提供でした

成功度


中大規模開発調査



中・大規模開発事例概要(1/4)

A社大規模 (103名) インターネット上のB2Cサービス開発 (SNS)

•サービスを小さく作って大きく育てる自然な成長を伴う大規模適用 •アジャイル/スクラムをあまり意識していない •人数の多いデザイナー/イラストレーターと、開発の間を疎結合にしておくことで人数増に対応

B社大規模 (100名) インターネット上のB2Cサービス開発 (ソーシャルゲーム)

•段階的朝会により複数チームが連携 •ビジネスのミッション (ビジネスタスク) によってチームを分割 •企画・開発・デザイナが一体となりチームを構成、スクラムで定義されているプロダクトオーナー・スクラムマスター・開発者というロールを超えて活動

C社大規模 (100名) ゲームソフト開発

•開発者が現場からボトムアップで徐々に導入 •開発者・企画者・サウンド担当者・デザイナの一部がスクラムを実施 (部分適用) •発注者にはスクラムであることは言わずに内部的に実施、発注者との連携 (進捗報告等) は窓口となる担当者を設置することにより解消





D社大規模 (100名以上)

基幹システム再構築

•要求が変わりやすいフロントの部分を中心にアジャイルを適用、要件が固まっているバックエンドの部分はウォーターフォール型開発 (部分適用)

E社中規模 (40名) インターネット上のB2Cサービス開発 (会員サービス)

•開発部門の事業責任者が開発全体を取り仕切ってスクラムを導入、チーム全員の進捗をチェックするなど強力なリーダーシップを発揮

•職能横断チーム[※1]ではなく、職能別チーム[※2]となっており、五月雨式にタスクを流している

F社-1 中規模 (40名) インターネット上のB2Cサービス開発 (医学・健康)

•会社のトップ (執行役員) がトップダウンでスクラム導入を推進 •手はじめにIT部門と企画部門を統合する社内改革を実施、その後、2つのプロジェクトで成功事例を作って、全社展開 (この事例はそのうちの1つ)

•中国へのオフショアを積極活用 (分散拠点開発)

※1:企画、開発、デザイナのような異なる職能をもった人々を集めて構成されたチーム ※2:単一の職能を持った人々を集めて構成されたチーム





F社-2 中規模 (50名) インターネット上のB2Cサービス開発 (エンターテイメント)

•F社-1の成功をうけて全社展開が決まったことに伴い、F社-1の事例を後追いする形で導入 •中国へのオフショアを積極活用 (分散拠点開発)

G社中規模 (50名) インターネット上のB2Cサービス開発 (実証実験)

•顧客と開発との間の透明性を最大限に実現し信頼関係を構築 •チーム間でメンバーローテーションを実施して知識を伝播 •最新技術、ツールを使いこなしての高速開発のため脱落者も出る •国内数拠点での分散拠点開発

H社中規模 (50名) インターネット上のB2Cサービス開発 (ECサイト)

•特定のサブシステムのみアジャイル開発を適用、他はウォーターフォールで開発したという部分適用事例

•開発会社がアジャイル開発を提案 •国内数拠点での分散拠点開発





I社中規模 (50名) インターネット上のB2Cサービス再構築 (会員サービス)

•部分適用、国内数拠点での分散拠点開発 •スコープの見直しに柔軟に対応するためにアジャイルを適用 •一気に人数を増やすのではなく、チームを徐々に拡大 •顧客プロキシを設けることで顧客側のボトルネックを解消

J社組織展開インターネット上のB2Cサービス開発 (会員サービス)

•アジャイル開発の要素を取り入れた標準プロセスをつくって全社に展開 •規模が30〜40人になると、ウォーターフォール型開発の要素を取り入れたカスタマイズ (仕様変更のコントロールのやり方を変える、テスト項目やドキュメントのボリュームを増やす) を行って対応

K社組織展開インターネット上のB2Cサービス開発 (SNS)

•アジャイル導入を推進する横断組織が存在、コーチ役を果たす •この企業の文化・風土がアジャイルなやり方との親和性が高い •Ad-Hocなやり方 (できたものから、都度リリースしていくようなやり方) からスクラムに移行




課題（一覧）と目指すべきゴール

法・環境

複数企業、多国籍、多重構造中大規模に適した契約テンプレート、コンプライアンスやセキュリティ基準、監査基準の整備と提示する

プロジェクト

参加型意思決定手法の紹介・導入支援事業者と開発者の関わり方やプライオリティ付けの

手法を学び、実践できるようにする大規模開発であっても、一気に大きくせずに漸進的

な展開方法を提示する

人材

非ウォーターフォール型開発実践者の育成と人材確保認定研修・コンサルタント活用・社内外の勉強会への

助成と人材プールを構築する

リファレンス

非ウォーターフォール型開発リファレンス作成中大規模開発の幅広く事例を収集し、工夫や指針

の提示が必要ビジネス、文化や組織構造の調査と設計手法の策

定

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

エンジニアが生き生きと働ける環境を作る

日本のソフトウェア産業の実態に適したソフトウェアの作り方を提案する

事業者と開発者のあいだに契約やセキュリティ基準の壁や物理的な距離による壁がある

事業者のソフトウェア開発への理解とコミットメントが乏しいため、中大規模開発に最適な開発手法の選択やプロジェクトの進め方できていない

非ウォーターフォール型開発ができるスキルを持った開発者を一定人数以上、集めることが難しい

中大規模開発に関して、日本の産業構造や文化にあった開発手法がまとめられていない

目指すべきゴール

課題提言

組織

「開発手法を変える」ではなく「組織文化を変える」視点へ移行する組織評価とデザイン手法を立ち上げる

中大規模開発では組織を含めた改革が必要とされることがあるが、成功へ導く組織構造と、変革のプロセスが明確ではない




施策と提言(1/2)


番号施策普及要因

1 リアルタイムにコミュニケーションがとれる環境を構築すること

1 顧客（開発依頼側）が開発チームに参加しやすい関係



2 成功事例（またはケーススタディ）を世間に広く伝えること


3 アジャイル型契約の事例を収集し世間に広く伝えること


4 ユーザ企業で内製する（契約を介さない）こと

1 顧客（開発依頼側）が開発チームに参加しやすい関係



5 顧客（開発依頼側）と開発チームで、ゴールを共有できる関係

5 ソフトウェアの価値の最優先がビジネスの成功であることを広く啓発する


6 ジョイントベンチャー方式を採用すること 5 顧客（開発依頼側）と開発チームで、ゴールを共有できる関係

7 国や自治体が調達でアジャイル型開発を採用すること

6 政府がアジャイル型開発の効果を認め、調達においてアジャイル型開発を積極的に採用し、普及を促進する

8 幅広い知識をもった人材を育てるカリキュラムを策定し、教育機関に広く適用すること

7 開発側、顧客側ともに、ソフトウェアに関する幅広い知識を持った人材を育てる環境




施策と提言(2/2)

番号施策普及要因

9 教育機関でPBLなどの実践的なコースと質の高いコンテンツを増やすこと

8 コミュニケーション、コラボレーションの重要性を学べる実践的な教育（PBL）


10 教育機関で産学連携を通した教育を増やすこと

9 顧客の関与や、コミュニケーションの重要性を経験的に学ぶ産学連携を通した教育

11 IT技術者の処遇改善、社会的地位を向上すること


12 留学生の受入を拡大すること



13 IT人材の流動性を高めること 12 技術や経験が組織や人に蓄積される仕組み

14 コミュニティを拡充すること 12 技術や経験が組織や人に蓄積される仕組み

15 アジャイル型開発のトレーニングの窓口を日本に設立すること

13 IT産業に技術と知識を流通させる、アジャイル型開発のコーチを育成・増加する環境

16 ガイドラインやTips集を作成し、世間に広く伝えること


12 技術や経験が組織や人に蓄積される仕組み

17 アジャイル型開発を調達する際の要件として、開発チームに有資格者をふくめること

13 IT産業に技術と知識を流通させる、アジャイル型開発のコーチを育成・増加する環境





ソフトウェア開発のイニシエーション(1/2)


近年では、IT技術の発展に伴いソフトウェアも複雑化しており、特に膨大な人件費が発生する大規模なソフトウェアの開発プロジェクトでは、プロジェクトの成功率が低いことが問題視されている。例えば、Standish Group社が2011年に発行したレポート「CHAOS Report 2011」によると、2008年以降に開始された約5,000件のプロジェクトのうち、3割程度が失敗に終わっていたという。

とは言え、現在プロジェクトマネジメント方法についての普遍的な標準規格は存在しておらず、開発者は通常、これまでの経験や慣例によるベストプラクティスに基づいてプロジェクトを準備（イニシエーション）することがほとんどのようである[1]。

例として、英国Queens大学Belfast校のGreer教授、ノルウェー・Norwegian工科大学のConradi教授が、ノルウェーのソフトウェア開発企業14社によるソフトウェアプロジェクトのイニシエーション及び計画について調査し、2009年に発表した論文によると、以下のような所見が得られたという[2]。

[1] http://books.google.com/books?id=BPD5Czu-HH8C&lpg=PP1&pg=PA50#v=onepage&q&f=false [2] http://www.idi.ntnu.no/grupper/su/publ/reidar/iet-sw-greer-preproj-14apr09.pdf

<出典> 「米国連邦政府の情報システム・ソフトウェア品質に関する取り組み」 JETRO/IPA New York，2012年5月．

参考

http://books.google.com/books?id=BPD5Czu-HH8C&lpg=PP1&pg=PA50

http://www.idi.ntnu.no/grupper/su/publ/reidar/iet-sw-greer-preproj-14apr09.pdf



ソフトウェア開発のイニシエーション(2/2)


•反復型開発方法では、特に固定された契約（fixed contract）ベースのプロジェクトを実施する場合、イニシエーション時に困難が発生することが多い。

•プロジェクト開始前には、フィージビリティ（実現可能性）調査が行われることが多いが、その性質は概ね非形式的である。

•特にプロジェクト領域の策定に関して、プロジェクト計画プロセスにおける文書化の実施状況はまちまちである。

•反復型開発方法では、プロジェクトの進行に応じてソフトウェアアーキテクチャを自然的に発展させる方式よりも、プロジェクト開始前にソフトウェアアーキテクチャを決定する方式が好まれる。

•リスクマネジメントの必要性は広く認識されているものの、実施状況は未完全である場合が多い。

以上から、ソフトウェア開発のプロジェクトマネジメント方法は、ベンダ及びプロジェクトの性質によって差異があるように見受けられる。しかし、ソフトウェア開発プロジェクトの成功を保証するためには、プロジェクトのイニシエーション段階が重要である以上、その改善の必要性は世界的に認識されている共通課題であり、今後イニシエーション方法の体系化に向け、更なる研究開発が行われることが期待される。

<出典> 「米国連邦政府の情報システム・ソフトウェア品質に関する取り組み」 JETRO/IPA New York，2012年5月．

参考



アジャイル型開発のスイートスポット（例２）

通常は，JavaまたはC#の環境で，組込みではなくウェブアプリケーションを，最終的なエンドユーザや実際の顧客とかなり近い環境で開発するところ．

チームの大きさはふつう，かなり小さく，すべてで12人にも満たない．しかし，大きなチームでの経験も蓄積され続けている．チームの中には他の場所にいるメンバもいるかもしれないが，チームの中核はエンドユーザのかなり近くで仕事をする．

まだ開発が始まっていないプロジェクトよりも，既存のシステムの方が簡単にアジャイル型開発を適用できる．重要なのは，新しいプロジェクトでも既存のシステムでもアジャイル型で開発するための十分な経験が蓄積されているということ．

アジャイル型開発のスイートスポットには好循環が存在し，多くの経験が多くの成功をもたらし，その成功がまた経験を得る機会を生み出す．

出典「アジャイルの限界」(作者:Alan Kelly, 翻訳者:徳武聡, 投稿日;2010年8月17日) http://www.infoq.com/jp/articles/limits-of-agile

参考




組合せモデルの例

仕様や設計の（場合によっては大幅な）変更が当然あるものという前提で、最初から厳密な仕様を抽出しようとせず、大まかな仕様だけで細かいイテレーション（反復）開発を始め、すぐに実装・テストを行って仕様や設計の妥当性を検証するというアプローチを採る

要件定義コア開発システム運用

テスト

開発

要求

第一反復第二反復第三反復第四反復イテレーション

テスト

開発

要求

テスト

開発

要求

テスト

開発

要求

IPAグローバルシンポジウム2010 児島プレス兼子邦彦氏講演より

“AHAA-Agile, Hybrid Assessment Method for Automotive, Safety Critical SMEs （Small-to-medium sized enterprises）”,ICSE’08

アイルランドやフィンランドにおける中小ソフトウェア企業（SMEｓ）が、車載ソフト開発を開発するとき、旧来の計画駆動型（plan-driven software development）とアジャイル型開発手法とを組み合せた手法を用いている（この論文は、そのプロセス評価の方法について述べたもの）




最適にリスクを取るマネジメントの考え方

SamsungのKee Sup Kim氏による「Best-in-Class Mobile SoC」と題する講演より：消費電力・性能と生産性のトレードオフは，設計マージンによって決まる。ここで，設計マージンとは，プロセス・バラつき，温度，電圧変動，HCI（hot carrier injection），TDDB（time dependent dielectric breakdown），NBTI（negative bias temperature instability）などの信頼性に関連した各種の指標を指す。プロセスのトレンドを考えれば，信頼性は高まる傾向にあるものの，すべての設計マージンを満たすことはビジネス的にはありえず，どこかでリスクを取らざるを得ない。それには，製造サイドと設計者の協力が不可欠である。両者のコミュニケーションを円滑にすることで，37.5%の消費電力削減と17.8%のチップ面積削減が可能になった例があるという。

出典：【DAC 2011】「設計者のやる気を引き出せるマネジメント」，経営層／管理職向けの講演に涙する（日経ＢＰ社ＥＤＡＯｎｌｉｎｅ，2011/06/10）

（変化の激しい）ビジネス・ニーズに応えるためにリスクを取る ↓

どこで（誰が）リスクを取るか？ ↓

顧客経営層-システム部門間，顧客-ベンダ間の緊密な協力，円滑なコミュニケーションのもとで，最適な分担でリスクを取る

参考




明確な「行動規準」に基づく判断による行動

引用：武田斉紀「3.11もブレなかった東京ディズニーランドの優先順位」（日経ビジネスオンライン，2011年5月16日）

TDRはキャストが自ら判断し、行動できる前提を用意している。「会社として大切にするべきことと優先順位」＝行動規準を明確に示し、十分な研修を実施して、一人ひとりが判断し行動することを推進している。

参考

震度5強の揺れは、．．．7万人の来園者（同社ではゲストと呼ぶ）たちは、前代未聞の体験に当然パニック状態になる。しかし揺れから40秒後には、地震発生を伝える園内アナウンスが流れた。．．．そしてキャストたちはパニックを起こさなかった。彼らは持ち場のゲストに対して、すぐさま冷静かつはっきりとした声で、分かりやすい指示を出した。

「（店舗で販売用に置いていたぬいぐるみの）ダッフィーを持ち出して、お客様に“これで頭を守ってください”と言ってお渡ししました」。彼女は会社から、お客様の安全確保のためには、園内の使えるものは何でも使ってよいと聞いていた。そこで、ぬいぐるみを防災ずきん代わりにしようと考えたという。

同じくキャストのIさんは、店舗で販売していたクッキーやチョコレートを無料で配り始めた。

幹部は開園以来28年間守ってきた“禁”を破る決断をした。バックヤードという従業員だけが利用する通路にゲストを通して、より短距離で安全にシーに誘導することにしたのだ。




ソフトウェアエンジニアリング上の主な課題（1/3）

①機能視点で開発を順次進めるため、システムのアーキテクチャの確立に不安がある。

アジャイル型開発では、アーキテクチャは「創発」すると捉えられており、これは、ウォーターフォール型開発においてアーキテクチャに大きな事前コストをかけすぎたことの反省から来ている。しかし、イテレーション毎の局所視点とリファクタリングによる創発性のみにアーキテクチャを任せることができるか、また、「十分な」アーキテクチャとは何か、という議論は今後必要であろう。

②機能間に依存性が強い場合、イテレーションに入力する機能の順序に制約ができるケースがある。

アジャイル型開発では、依存性をなるべくなくし、細分化して機能分割することが求められる。また、その場合でも、リファクタリングの負荷が大きくなる場合がある。





③大規模システムへの適用経験に学ぶ（「プロセス」より「人」）。

a.スキル欠如が透明化できないことに起因する開発者の危惧(fear)

b.開発者全員が，すべてのやりとり(trades)に熟達する(master)必要性

c.社会性スキル(social skills)への依存性増大

d.開発者におけるビジネス知識の欠如

e.アジャイル・プラクティスではなく，アジャイルの価値と原理(principle)を学ぶ必要

f. アジャイル手法の利用に対する開発者のモチベーションの欠如

g.意思決定の譲渡(devolve)が行きつくところ

h.行動が，アジャイル性に適合しているかどうかを評価する必要性

i. アジャイルに特化した採用および適切に訓練されたITコース卒業生獲得に対する戦略欠如

People Over Process: Key People Challenges in Agile Development, IEEE Software, March/April (2011).





④大規模システムへの適用経験に学ぶ（エントロピー増加）。

i. 大規模システムの進化に対して，アジャイル手法を適用して保守・改善を続けた結果，ソフトウェア・エントロピが増大（aging 老化）し，構造が輻輳化し，管理できなくなり，アジャイル開発を続けられなくなる危険性に直面した．

ii. 対策として，NDepend ツールを使って，イテレーションの度に，構造の整列を行い，リファクタリングを行った．

iii. スプリント期間中に，構造整列，リファクタリング，Working Softwareの顧客レビュー・承認，実装を行おうとしたが，当初決めたスプリント期間はとても守れなかった．

iv. リファクタリングは，業界で説明されているほど，簡単な作業ではない．ごく限られたリファクタリング手法を選定して，これを自動化するツールを開発し，これを利用しながら行った．

Hanssen, G. K., et al., Software entropy in agile product evolution, Proceedings of the 43rd Hawaii International Conference on System Sciences (2010).




異文化コラボレーションの事例

NTTデータ：分散開発環境に対するアジャイル開発の適用

事例（イノベーションスプリント2011）

TDD研究会：ウォーターフォール型テストケースへの整合の

ためのテスト駆動開発(TDD)の拡張提案（ソフトウェアテス

トシンポジウム2011）

ソニーEMCS：XDDPとScrumとの組合せ（派生開発カンファ

レンス2011）

参考

まず，アジャイル開発のプラクティスのいくつかを，ウォーターフォール型開発に導入してみることから始めるのも一つの手？




適用に向けた工夫に関する参考文献等参考

・長沢智治(マイクロソフト)，玉川憲(日本IBM): マイクロソフトもIBMもやっている！アジャイル開発の実践事例（IBM Rational Software Conference 2009） http://download.microsoft.com/download/A/6/2/A62E3B55-E07D-4B82-819B-82C639718187/rsc09_c3.pdf

・Dean Leffingwell: Scaling Software Agility （Agile 2009, Chicago, IL, August 26, 2009） http://agile2009.agilealliance.org/files/session_pdfs/Scaling%20Software%20Agility%20Overview%20Agile%202009.pdf 邦訳: 「アジャイル開発の本質とスケールアップ」（翔泳社）


・Sam Guckenheimer, Neno Loje: Agile Software Engineering with Visual Studio: From Concept to Continuous Feedback

（Addison-Wesley, 2012）邦訳: 日本マイクロソフト株式会社，TFSUG監訳：「アジャイル・ソフトウェア

エンジニアリング」日経BP社，2012年

http://download.microsoft.com/download/A/6/2/A62E3B55-E07D-4B82-819B-82C639718187/rsc09_c3.pdf

http://download.microsoft.com/download/A/6/2/A62E3B55-E07D-4B82-819B-82C639718187/rsc09_c3.pdf

http://agile2009.agilealliance.org/files/session_pdfs/Scaling Software Agility Overview Agile 2009.pdf

http://agile2009.agilealliance.org/files/session_pdfs/Scaling Software Agility Overview Agile 2009.pdf

ipa/secにおける非ウォーターフォール型開発に関する調査検討 … ·...

Documents