from ipa for agile japan

SoftwareEngineering

Information-technology Promotion Agency, JapanCenter

アジイルのABCに向けたヒントアジャイルのABCに向けたヒント～IPA/SECの調査検討から見えてきたもの～

Agile Japan 20122012年3月16日

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

2012年3月16日

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

山下博之

1Software Engineering Center

山下博之

SECSoftware Engineeringfor Mo･No･Zu･Ku･Ri

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

H21年度 H22年度 H23年度

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

課題抽出

開発研究会開発WG 開発WG▲報告書

▲報告書

△課題検討検証・改善

提案

非ウォーターフォール型開発に関する調査

実証/模擬実験（契約形態） △▲

提案

開発に関する調査（契約形態）

大規模開発事例調査

△▲報告書事例収集(1) 事例収集(2)

大規模開発事例調査

報告書（公開中）H21年度版 http://sec ipa go jp/reports/20100330a html

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

H21年度版 http://sec.ipa.go.jp/reports/20100330a.htmlH22年度版 http://sec.ipa.go.jp/reports/20110407.html

Agile Japan 2012 (2012-03-16)


日本におけるアジャイル型開発にふさわしい契約モデルの提案～基本契約/個別契約モデル～

①①

システム運用

テ開要テ開要テ開要テ開要テ開要テ開要

システム運用

テ開要テ開要テ開要テ開要テ開要テ開要テ開要テ開要テ開要テ開要テ開要テ開要企画

第１反復

テスト

開発

要求

第ｎ反復

テスト

開発

要求・・・

第１反復

テスト

開発

要求

第ｎ反復

テスト

開発

要求・・・

第１反復

テスト

開発

要求

第ｎ反復

テスト

開発

要求・・・企画

第１反復

テスト

開発

要求

第１反復

テスト

開発

要求

第ｎ反復

テスト

開発

要求

第ｎ反復

テスト

開発

要求・・・

第１反復

テスト

開発

要求

第１反復

テスト

開発

要求

第ｎ反復

テスト

開発

要求

第ｎ反復

テスト

開発

要求・・・

第１反復

テスト

開発

要求

第１反復

テスト

開発

要求

第ｎ反復

テスト

開発

要求

第ｎ反復

テスト

開発

要求・・・

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

第1リリース第2リリース第mリリース

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

第1リリース第2リリース第mリリース

基本契約

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

基本契約

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

基本契約

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

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

小さな機能単位ごとに開発対象と費用がある程度確定したタイミングで

Software Engineering Center 3Copyright © 2009-2012 IPA, All Rights Reserved.Agile Japan 2012 (2012-03-16)

小さな機能単位ごとに、開発対象と費用がある程度確定したタイミングで個別契約（請負/準委任）を順次締結する。

今月(2012年3月)末改訂版公開予定


適切な開発手法の選択②②

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

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

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

開発対象の性質環境条件

ビジネス上の段階・手法に対する組織の経験、成熟度・ビジネス上の段階・システムの深刻度・要件の固まり具合、変化の度合い

手法に対する組織の経験、成熟度・手法に対するメンバの慣れ、成熟度・組織の制度、統制組織の地理的分散・開発対象の成熟度

- 新規開発、改造、再構築、保守・アーキテクチャの成熟度

・組織の地理的分散・組織の風土- 新しい試みに対する挑戦の空気

Software Engineering Center 4

アキテクチャの成熟度・規模の大小 - 経営/マネジメント層の理解と支援

Copyright © 2009-2012 IPA, All Rights Reserved.Agile Japan 2012 (2012-03-16)


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

選択的に選択的に

広範囲に無し

Software Engineering Center 5Agile Japan 2012 (2012-03-16) Copyright © 2009-2012 IPA, All Rights Reserved.

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


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

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

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

Figure 1. A financial model of software product development.


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


参考ハイブリッド型の適用が進む

28 percent of 450 software professionalssaid they use a hybrid approach. y y ppAnother 12 percent use lean software development,which includes agile processes.g pSource: 2011 Agile ALM and Testing Survey,SearchSoftwareQuality.com

Of 4,770 respondents from 91 countries,90 t id th f f il90 percent said they use some form of agile.Only 27 percent of respondents solely use one type of agile,

hil 35 t i il ith t f llwhile 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: VERSIONONE: State of Agile Survey 2011


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

出典：CHAOS MANIFESTO 2011

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

当初QCD目標通り完了

目標QCDの全ては満たせず

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

• 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


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

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


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


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

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

全てのソフトウェア開発に、これらの特徴を有するアジャイル開発手法を適用できる、あるいはすべきだ、という立場ではない。

ジネ市他文脈にビジネスや市場、その他の開発の文脈によって、ウォーターフォール型の開発が適している場面もあれば、アジャイル型の開発が適

場

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

している場面もある。

Agile Japan 2012 (2012-03-16)


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

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

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

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

②リスクの高い領域

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

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

③市場競争領域③市場競争領域

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

新製品開発）．



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

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

①大規模開発

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

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

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

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

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

④組込みシステム開発

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


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

Agile Japan 2012 (2012-03-16) Copyright © 2009-2012 IPA, All Rights Reserved.


速報中・大規模開発事例の調査結果から(1/4)

No.規模

部分適用

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

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

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

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

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

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

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

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

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

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

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

中規模：30～100名，大規模：100名以上 *：準委任


中規模：30 100名，大規模：100名以上

独自：特に手法を決めず自ら定義，Scrum+XP：両手法を組み合わせて実践

*：準委任



チーム間ローテーション

工夫例(1/2)

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

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

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

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




アーキテクチャの重視

工夫例(2/2)

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

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

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




全体計画の把握困難

主な課題

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

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

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

今月(2012年3月)末調査報告書公開予定


今月(2012年3月)末調査報告書公開予定


アジャイルのABCに向けたヒント

今こそ語り合おう、アジャイルのABCAgileを知る、Businessをつくる、Changeを起こすAgileを知る、Businessをつくる、Changeを起こすアジャイルジャパン 2012

Aggressively

Bravelyravely

CollaborativelyCollaboratively


from ipa for agile japan

Technology