From IPA for Agile Japan

Software
Engineering
Center
Information-technology Promotion Agency, Japan

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

Agile Japan 2012
2012年3月16日

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

Software Engineering Center 1

アジャイル開発に関するIPA/SECの取組み SEC
Software Engineering
for Mo･No･Zu･Ku･Ri

H21年度 H22年度 H23年度
課題抽出
非ウォーターフォール型非ウォーターフォール型非ウォーターフォール型
開発研究会 ▲ 開発WG ▲開発WG △
報告書課題検討報告書検証・改善
提案
非ウォーターフォール型実証/模擬実験
開発に関する調査 ▲ （契約形態） △
事例収集(1) 報告書事例収集(2)
大規模開発事例調査
報告書（公開中）
H21年度版 http://sec ipa go jp/reports/20100330a html
http://sec.ipa.go.jp/reports/20100330a.html
H22年度版 http://sec.ipa.go.jp/reports/20110407.html
Agile Japan 2012 (2012-03-16) Copyright © 2009-2012 IPA, All Rights Reserved. Software Engineering Center 2

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

システム運用

要開テ要開テ要開テ要開テ要開テ要開テ
求発ス求発ス求発ス求発ス求発ス求発ス
企画ト
・・・
トト
・・・
トト
・・・
ト
第１反復第ｎ反復第１反復第ｎ反復第１反復第ｎ反復

第1リリース第2リリース第mリリース
• n=1のケースもあり。

基本契約
基本契約
個別契約個別契約個別契約
個別契約個別契約個別契約

プロジェクト全体に共通する事項につき、基本契約を締結し、
小さな機能単位ごとに、開発対象と費用がある程度確定したタイミングで
小さな機能単位ごとに開発対象と費用がある程度確定したタイミングで
今月(2012年3月)末改訂版公開予定
個別契約（請負/準委任）を順次締結する。

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

計画性・確実性・安定性変化への適応性・迅速性
ウォーターフォール型
アジャイル型

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

・ビジネス上の段階
ビジネス上の段階・手法に対する組織の経験、成熟度
手法に対する組織の経験、成熟度
・システムの深刻度・手法に対するメンバの慣れ、成熟度
・要件の固まり具合、変化の度合い・組織の制度、統制
・開発対象の成熟度・組織の地理的分散
組織の地理的分散
- 新規開発、改造、再構築、保守・組織の風土
アキテクチャの成熟度
・アーキテクチャの成熟度 - 新しい試みに対する挑戦の空気
・規模の大小 - 経営/マネジメント層の理解と支援

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

選択的に

広範囲に
無し

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

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

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

Figure 1. A financial model of software product development.

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

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

28 percent of 450 software professionals
said they use a hybrid approach.
y y pp
Another 12 percent use lean software development,
which includes agile processes.
g p
Source: 2011 Agile ALM and Testing Survey,
SearchSoftwareQuality.com

Of 4,770 respondents from 91 countries,
90 percent said they use some f
t id th form of agile.
f il
Only 27 percent of respondents solely use one type of agile,
while 35 percent mix agile with waterfall,
hil t i il ith t f ll
and 39 percent mix agile with Scrum.
Source: Analysis.Net and VersionOne Source: PM NETWORK,
January 2012, Vol. 26, No. 1

参考
使用されるアジャイル手法の種別 SEC

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

Source: VERSIONONE: State of Agile Survey 2011

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

出典：
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

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

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

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

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

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

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

アジャイル開発が得意とし、現在、その適用により効果を挙げて
いる領域：
①ビジネス要求が変化する領域
・要求の変化が激しく，あらかじめ要求が固定できない領域。
・要求の変化が激しくあらかじめ要求が固定できない領域
②リスクの高い領域
・不確実な市場を対象としたビジネス領域（市場リスク）
不確実な市場を対象としたビジネス領域（市場リスク）
・技術的な難易度が高い開発領域（技術リスク）
③市場競争領域
・他社に先駆けた製品・サービス市場投入が命題であり，TTM（Time to
Market）の短縮が優先となる領域（Webのサービス，パッケージ開発，
）短縮が優先領域（ジ開発
新製品開発）．


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

アジャイル開発による経験が十分には蓄積されておらず、現在、
チャ
チャレンジと創意工夫が求められている領域：
ジと創意夫が求られてる領域
①大規模開発
・開発者10人程度を超えると、システム分割、チム分割が必要。その分
・開発者10人程度を超えるとシステム分割チーム分割が必要その分
割方法、及び、分割されたチーム間のコミュニケーションが課題。
②分散拠点（オフショア含む）開発
・開発拠点が分散し、さらに時差によって分断される場合のコミュニケーショ
ン手法、また、それをサポトするツルが必要。
ン手法、また、それをサポートするツールが必要。
③組織（会社）間をまたぐ開発チームによる開発
・共通のビジネスゴールを持ったチームを組むことが難しい。
・共通のビジネスゴールを持ったチームを組むことが難しい
④組込みシステム開発
・リリース後のソフトウェア修正が極めて困難であり、採用には工夫要。
リリス後のソフトウア修正が極めて困難であり採用には工夫要

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

規部分
No. 採用手法対象システム種別契約
模適用
1 大独自 B2Cサービス
B2Cサビス (SNS) 無(自社内)
2 大 Scrum B2Cサービス (ソーシャルゲーム) 無(自社内)
3 大 ○ Scrum ゲームソフト
ゲムソフト受託(未公開)
4 大 ○ 独自基幹システム受託(準委任)
5 中 Scrum B2Cサビス (会員サビス)
B2Cサービス (会員サービス) 無(自社内)
6 中 Scrum+XP B2Cサービス (医療・健康) 無(自社内)+オフショア*
7 中 Scrum XP B2Cサビス ( ンタテインメント) 無(自社内) オフシア*
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月)末調査報告書公開予定

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

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

Aggressively
Bravely
ravely
Collaboratively


SEC

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

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

From IPA for Agile Japan

Recomendados

Recomendados

Más contenido relacionado

Similar a From IPA for Agile Japan

Similar a From IPA for Agile Japan (20)

Más de Kenji Hiranabe

Más de Kenji Hiranabe (20)

From IPA for Agile Japan