SEC - IPA 独立行政法人情報処理推進機構

Software 

Engineering 

Center 

Information-technology Promotion Agency, Japan 

IPA/SECにおける 

H23 年度非ウォーターフォール型開発 

に関わる活動成果の概要 

~アジャイル開発を適切に採り入れるためのポイントとアジャイル開発の事例 ~ 

SECセミナー 

2012 年 5 月 23 日 

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

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

山下博之 

Software Engineering Center 

1

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

SEC 

Software Engineering 

for Mo・No・Zu・Ku・Ri 

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

課題抽出 

非ウォーターフォール 

型開発研究会 

▲ 

報告書 


型開発に関する調査 

事例収集 (1) 

▲ 

報告書 

非ウォーターフォール ▲ 非ウォーターフォール 

型開発 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 


型開発 WG 

▲ 

報告書 

▲ 

報告書 


IPA/SEC Special Seminar (2012-05-23) 

Copyright © 2009-2012 IPA, All Rights Reserved. 

Software Engineering Center 2

目次 




1. アジャイル型開発に注目される背景 

2. アジャイル型開発の特徴 

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

4. 中・大規模開発への適用事例 

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




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




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

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

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

出現 

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

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

応が必要 

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

応 




参考 

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

25% 

20% 

22% 21% 

12% 

1.Time-to-Marketの加速 

2. 変化する優先順位管理のため 




15% 

10% 

5% 

0% 

加 Time-to-Marketの 

速 

管変 

理化 

のす 

たる 

め優 

先 

順 

位 


生 

産 

性 

向 

上 

10% 

の 

向 

上 

ソ 

フ 

ト 

ウ 

ェ 

ア 

品 

質 

9% 

融 

合 

ITと 

改ビ 

善 

ジ 

ネ 

ス 

の 

6% 6% 

見 

え 

る 

化 

プ 

ロ 

ジ 

ェ 

ク 

ト 

の 

リ 

ス 

ク 

削 

減 

4% 

簡開 

易発 

化プ 

ロ 

セ 

ス 

の 

3% 

そ 

の 

他 

2% 2% 2% 

のエ 

導ン 

入ジ 

/ ニ 

ア 

向リ 

上ン 

グ 

コ 

ス 

ト 

削 

減 

向 

上 

保 

守 

性 

/ 

拡 

張 

性 

1% 

や 

る 

気 

改 

善 

チ 

ー 

ム 

の 

(VersionOne 社アジャイル開発の現状調査第 3 回 2008より) 







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

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

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

影響 

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

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




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




・全体の要件と計画を初めに決める → 計画駆動型 

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

要件定義 

設計 

コーディング 

テスト 

運用 




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

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

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

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




要件定義 

チェック 

総合テスト 

分 

解 

機能設計 

モジュール 

設計 

チェック 

チェック 

機能テスト 

結合テスト 

合 

成 

コーディング 

単体テスト 




要求の固定が(ビジネス)リスクを拡大 




要求が固定されない 

↓リスク 

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

の遅延 

外部ビジネス環境 

ビジネス戦略 

要求を固定化 

↓リスク 

外部ビジネス環境の 

変化への迅速な対応 

の遅れ 

内 

部 

状 

態 

IT 戦略 

要求 

ITシステム 








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

‣ 開発者 ( 特に若者 )の参画意識・達成感が低い 

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

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




参考 

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




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

仕事では効果があるが,そうでない創造的な仕事では逆効果 . 

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

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

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

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

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

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

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


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

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

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

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



目次 












アジャイル型開発の特徴 




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

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

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

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

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

アジャイル開発は、 

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

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

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

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

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

という特徴を持つ。 




参考 

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




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

を順次踏んでいくという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つの価値 




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

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

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

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

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

3 契約交渉よりも, 顧客との協調を 

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

すなわち,1~4の各文の前者 (「よりも」の前の言葉 )に価値 

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

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

アジャイル宣言 (Agile Manifesto) 

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

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




参考 

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




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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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




アジャイル開発のモデル(1/2) 

顧客の要求にしたがって, 優先度の高い機能から順に, 

要求・開発・テスト(・リリース)を短い期間で繰り返しながら, 

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

原則として, 

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

時間 

スコープ 

反復 

時間 

スコープ 

要求 

開発 

テスト 




反復 

(イテレーション) 

1~4 週間という一定の短い周期で要求・開発・テストを繰り返しながら, 

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

( 対比 ) 

 

 




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




< 標準 > 

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

プロセス(SLCP) 

要求 

開発 

テスト 

( 部品 ) 

注 ) 図形のサイズは意 

味を持たない( 時間 , 

規模を表さない). 

< 実際 > 

要求 

開発 

テスト 

ウォーターフォール型 

大きなプロセスを 

順に実施し, 

それを1 回で終了 

アジャイル型 

小さなプロセスを 

行き来しつつ実施し, 

それを何回も反復 


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






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

( 調査結果に基づく) 




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

モデル1 

システム運用 




企画 

要 

求 

開 

発 

テ 

ス 

ト 

・・・ 

要 

求 

開 

発 

テ 

ス 

ト 

・・・ 

要 

求 

開 

発 

テ 

ス 

ト 

・・・ 

要 

求 

開 

発 

テ 

ス 

ト 

・・・ 

要 

求 

開 

発 

テ 

ス 

ト 

・・・ 

要 

求 

開 

発 

テ 

ス 

ト 

第 1 反復 

第 n 反復 

第 1 反復 

第 n 反復 

第 1 反復 

第 n 反復 

第 1リリース 

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


第 mリリース 

考え方 

シンプルな基本形 





モデル2 





企画 

要求・アーキテ 

クチャ設計 

・基盤開発 

要 

求 

開 

発 

第 1 反復 

テ 

ス 

ト 

・・・ 

要 

求 

開 

発 

第 n 反復 

テ 

ス 

ト 

・・・ 

要 

求 

開 

発 

第 1 反復 

テ 

ス 

ト 

・・・ 

要 

求 

開 

発 

第 n 反復 

テ 

ス 

ト 



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

考え方 

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

成されるソフトウェア( 右図 )において, 最初にまず, 

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

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

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

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

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



機 

能 

1 

機 

能 

2 

機 

能 

3 

機 

能 

4 

基盤・共通部 

… 



モデル3 





企画 

要 

求 

開 

発 

第 1 反復 

テ 

ス 

ト 

・・・ 

要 

求 

開 

発 

第 n 反復 

テ 

ス 

ト 

リリース前 

テスト 

・・・・・・ 

要 

求 

開 

発 

第 1 反復 

テ 

ス 

ト 

・・・ 

要 

求 

開 

発 

第 n 反復 

テ 

ス 

ト 

リリース前 

テスト 



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

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

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

考え方 

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

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

クションを実施する. 




目次 















ユーザ経営層の意識 




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




顧客 (ユーザ) 経営層 

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

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

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

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

< 経営層の責任 > 

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

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

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

ベンダ経営層 

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

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

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




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




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

ムの一員として参画し、タイムリーな意思決定を行ったり、品質や進捗状 

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

分な理解と覚悟を持つ。 

• アジャイル開発においては、反復の都度、コードを書き変えていくスタイ 

ルが採られる。 

品質に重大な悪影響が及ぶかどうかの観点での、プロダクト品質の見え 

る化が必要。 

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

トとの円滑なコミュニケーションを図り、アジャイル開発採用の本来の目 

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







ベンダ経営層の意識 




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




顧客 (ユーザ) 経営層 

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

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

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

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

< 経営層の責任 > 

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

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

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

ベンダ経営層 

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

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

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




参考 

海外勢との競争 (1/2) 




2011 年 04 月 07 日 

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

トヨタ自動車株式会社 

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

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

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

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

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

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

2011 年 05 月 23 日 

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

トヨタ自動車株式会社 

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

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

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

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

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

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

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

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



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


参考 

海外勢との競争 (2/2) 




2011 年 11 月 10 日 

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

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

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

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

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



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





人材の育成と適正配置 




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




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

( 全ての機能の仕様を洗い出す能力よりも)コアとなる機能を見定め 

, 優先度を図りながら開発プロジェクトの運営を指揮していく能力 

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

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

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

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

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

進め方を踏襲させるためのファシリテーションスキル 

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

ータルにプロジェクトのアウトプットを積み重ねていくスキル 

3 設計 ,コーディング,テストを一貫して実施出来るスキル 




人材の育成と配置 

•アジャイル開発の価値 ( 及び原則 )の理解が重要 

•プラクティスの全てを完全に身につけるより, 価値に 

従って行動する習慣を確実に身につけることが重要 

• 様々な方法論・数あるプラクティスから,プロジェクト 

や組織に適したものを取捨選択し,カスタマイズする 

ことが必要 →このようなスキルの醸成 

• 自社用のシステム開発から,アジャイル開発研修 , 

個人 /チーム・プラクティス 

•とはいっても, 

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

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

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






価値 

原則 

手法 





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

[ 注 ] 適用領域も変化する 




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




アジャイル開発は、 

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

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

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

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

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

という特徴を持つ。 

全てのソフトウェア開発に、これらの特徴を有するアジャイル開発 

手法を適用できる、あるいはすべきだ、という立場ではない。 

ビジネスや市場、その他の開発の文脈によって、ウォーターフォー 

ル型の開発が適している場面もあれば、アジャイル型の開発が適 

している場面もある。 




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




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

いる領域 : 

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

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

2リスクの高い領域 

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

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

3 市場競争領域 

・他社に先駆けた製品・サービス市場投入が命題であり,TTM(Time to 

Market)の短縮が優先となる領域 (Webのサービス,パッケージ開発 , 

新製品開発 ). 




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




アジャイル開発による経験が十分には蓄積されておらず、現在、 

チャレンジと創意工夫が求められている領域 : 

1 大規模開発 

・開発者 10 人程度を超えると、システム分割、チーム分割が必要。その分 

割方法、及び、分割されたチーム間のコミュニケーションが課題。 

2 分散拠点 (オフショア含む) 開発 

・開発拠点が分散し、さらに時差によって分断される場合のコミュニケーショ 

ン手法、また、それをサポートするツールが必要。 

3 組織 ( 会社 ) 間をまたぐ開発チームによる開発 

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

4 組込みシステム開発 

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




目次 












参考 

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




No. 

事例概要 

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

2 ソーシャルネットワーキングサービス(SNS)システム開発事例 

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

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

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

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

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

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

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

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

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




参考 

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




No. 

事例概要 

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

13 教務 Webシステム開発事例 

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

15 検索エンジン開発事例 

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

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

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

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

20 Webメディア開発事例 

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

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




参考 

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




チ 

ー 

ム 

の 

人 

数 

( 

人 

12 

10 

8 

6 

4 

) 2 

2 4 6 8 10 12 14 16 18 20 22 24 

開発期間 ( 月 ) 

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

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




参考 

事例 :イテレーション(スプリント)の期間 




7 

6 

事 5 

例 

の4 

数 

3 

( 

件 2 

) 

1 

0 

その他 :1~2 週間 2 件 

1~4 週間 1 件 

1 2 3 4 5 6 7 8 

イテレーション(スプリント) 期間 ( 週 ) 

⇒1~2 週間が中心 




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




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

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

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

3 契約交渉よりも, 顧客との協調を 

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

アジャイル開発のスイートスポット 

• システム規模 0..12..300 ( 開発メンバー数 ) 

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

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

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

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

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

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

• 統制単純なルール、...、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) 




工夫例 (1/2) 

チーム間ローテーション 

チーム間の知識伝播促進のため,メンバのローテーションを行う. 一時的に 

速度は落ちるが, 各チームの知識を効率よく伝播でき多能工化が高まる. 

段階的朝会 

複数チーム間は朝会を段階的に実施 .チーム→ 全体 (→チーム). 

漸進的な展開 

一度にすべてのチームに広げるのではなく,まずは導入障壁の低いところ, 

最も必要なところから順次導入し, 少しづつ展開 .ふりかえりで, 次はどこ 

に広げていけばいいかを考える. 

コミュニケーション・ツールの活用 

TV 会議システム, 雑記帳システム(SNS,Blog 等 ) 




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




工夫例 (2/2) 

アーキテクチャの重視 

プロジェクト前半にアーキテクチャを構築する事例が多く,アーキテクチャ専 

門チームを編成して構築 . 

構築されたアーキテクチャを組織の共通基盤とし, 再利用できるようにして 

いる事例あり. 

疎結合な機能分割 

疎結合な機能でサブシステム分割を行う. 

7 割のチームがCI( 継続的インテグレーション)を実施 . 

テスト専用フェーズ 

プロジェクト後半で専用のテストフェーズを実施 .プログラム開発の反復を 

停止する事例と,テストのみの反復期間を設ける事例あり. 




浮かび上がった問題点 




主な問題点 

全体計画の把握困難 

要求の変化や開発状況に応じて着手する順番や範囲を決めるため, 

プロジェクト開始時にプロジェクト全体の把握が困難な事例あり. 

ビジネス企画側にボトルネック発生 

スクラム導入の結果 ,ビジネス企画者の決定待ち等のボトルネック 

が発生した事例が多い. 中には開発者の信頼をなくした事例もあり. 

反復リズムとの不適合状態の発生 

セキュリティ監査や外部テスト業者 , 発注者の外部組織や関連組織 

との関係において, 反復リズムと適合せずに問題が発生している事 

例あり. 




目次 












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




計画性・確実性・安定性 


変化への適応性・迅速性 


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

開発対象の性質 

・ビジネス上の段階 

・システムの深刻度 

・要件の固まり具合、変化の度合い 

・開発対象の成熟度 

- 新規開発、改造、再構築、保守 

・アーキテクチャの成熟度 

・規模の大小 

開発組織の 

環境条件 

・手法に対する組織の経験、成熟度 

・手法に対するメンバの慣れ、成熟度 

・組織の制度、統制 

・組織の地理的分散 

・組織の風土 

- 新しい試みに対する挑戦の空気 

- 経営 /マネジメント層の理解と支援 




参考 

アジャイル型開発のスイートスポット( 例 ) 




• システム規模・ 0..12..300 ( 開発メンバー数 ) 

• 深刻度 

・シンプル、経済被害、... 人身事故 

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

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

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

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

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

• 統制 

・単純なルール、...、SOX、... 

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




参考 

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

50% 

45% 

40% 

35% 

30% 

25% 

20% 

15% 

10% 

5% 

0% 

45% 44% 

変組 

化織 

能文 

力化 

の 

一変 

般化 

的へ 

の 

な 

抵 

抗 

42% 

経ア 

験 

ジ 

ャ 

者イ 

不ル 

足 

32% 

支マ 

ネ 

援ジ 

メ 

ン 

ト 

の 

1. 組織文化の変化能力 

2. 変化への一般的な抵抗 

3.アジャイル経験者不足 

23% 

複プ 

雑ロ 

ジ 

さェ 

ク 

ト 

模の 

・規 

22% 

顧 

客 

の 

協 

力 

17% 

対規 

応模 

の拡 

自大 

信へ 

の 

14% 

許移 

さ行 

れま 

るで 

時に 

間 




10% 

予 

算 

の 

制 

約 





参考 

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

25% 

20% 

23% 

21% 

1. 企業哲学・文化との相性 

2. 手法への不慣れ 




15% 

10% 

5% 

13% 

12% 

11% 

8% 

7% 

5% 

0% 

文企 

化業 

と哲 

の学 

相又 

性は 


手 

法 

へ 

の 

不 

慣 

れ 

そ 

の 

他 

へ従 

の来 

外型 

部開 

圧発 

力採 

用 

反チ 

発ー 

ム 

内 

で 

の 

欠文 

如化 

的 

な 

移 

行 

の 

支マ 

ネ 

援ジ 

のメ 

欠ン 

如ト 

の 

ト不 

レ十 

ー分 

ニな 

ン 

グ 




H23 年度版報告書の公開中 




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

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




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

欧米の競争力になっているアジャイル開発の普及要因を調査し, 

日本における普及や定着を促進する施策のヒントとする. 




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

普及要因 

調査項目 

調査範囲 

調査対象国 

駆動要因 

土壌 

駆動要因 

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

土壌 

人材 , 社会的環境等 

1 ソフトウェア開発 

プロジェクトの比較 

( 例 :プロジェクト種別 , 

ユーザの関与等 ) 

2 IT 人材の状況 

( 例 :IT 技術者の就労状況や 

人材の流動性等 ) 

3 IT 人材育成 

( 教育カリキュラム)の比較 

米国 

英国 

中国 

ブラジル 

デンマーク 

日本 




ご質問・意見の宛先 




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







ご清聴 ,ありがとう 

ございました 

IPA/SECホームページ: 

http://sec.ipa.go.jp/index.html 







付録 




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




安 

心 

← 変 

化 

の 

俊 

敏 

な 

反 

映 

↙ 

安 

全 

← 高 

信 

頼 

化 

< 依存 >の拡大傾向 

‣ 時間的 : 常時化 

‣ 量的 : 広範囲化 

‣ 質的 :クリティカル域 

国民生活 

社会経済活動 

依存 

ITサービス 

ITシステム 

情報技術 

変化 

( 要求の変化 ) 

反映 

変化 

• 価値観 

• ライフスタイル 

• 法制度 

• 社会情勢 

• ビジネストレンド 

• … 

< 変化 >の拡大傾向 

‣ 時間的 : 頻繁に 

‣ 量的 : 広範囲な影響 

‣ 質的 : 複雑化 

• 技術動向 

• 新技術 

• コスト 

• … 

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




参考 

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

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

ポイント 

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

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

A 社 

2010 年 1 月 2010 年 2 月 




21 22 23 24 25 26 27 28 29 30 31 1 2 3 4 5 6 7 8 9 

サービス発表 

⇒ 柔軟性 

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

• 開発体制 

サービス開始 

B 社 

対抗サービス発表 


C 社 

対抗サービス発表 


< 出典 > 

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

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

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




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




環 

境 

短縮が必要 

最近の 

変化の状況 

変化が進んで 

しまっている 

予 

測 

可 

能 

な 

環 

境 

変 

化 

量 

変化対応のシステム開発期間 

★システム 

完成 

時間 → 

これまでの 

変化の状況 




Faultsの混入 , 発見 , 除去 







参考 

プロセスとプラクティス 




タ 

ス 

ク 

アクティビティ 

XP 

・システムのメタファ 

・シンプルデザイン 

・テスト駆動開発 

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

・ペアプログラミング 

 

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


全く異なる観点 


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

・自律的な組織化チーム 

・スクラムミーティング 

・1 日以内の障害除去 

・共通の部屋 

・日次ビルド 

・スプリントレビ 

 

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


参考 

従来型とアジャイル型との主な違い(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 人以下 

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

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

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

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

継続的 

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

文書化相当量最小限 




参考 

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




< 得られた知見 > 

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

・アジャイル手法 , 技法 , 実践規則の採用は, 増加し, 既に広く普及している.しかし, 採用 

における初期の試みは,ごく一部でしか成功していない. 

・アジャイル手法は,「どのように(how)」ソフトウェア・システムエンジニアリング・アクティビ 

ティを実施すべきか,に焦点を当てているが, 関連するSC7ソフトウェア・システムエンジニ 

アリング標準は,「何を(what)」実施すべきか, 実施すべきプロセス(アクティビティ)の目的 , 

意図されている効果 (outcomes),プロセス及び形成 / 改変されたプロダクト計量法に焦 

点を当てている. 

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

・アジャイル手法を採用するかどうかは, 多くの場合 ,テクニカルな専門職によって決定され, 

ビジネス責任者は,その成功のためにビジネスが関わらなければならない水準 (business 

engagement level)を理解していない. 

・アジャイル手法を利用して開発した場合 , 会計システムに対する第 3 者認定が, 認定者が 

必要とする文書欠落のため, 受けられない可能性がある. 

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

・アジャイル手法の適用が成功するためには,その基礎とする価値及び原則の適用や開発 

メンバのスキル等の因子で成功する必要がある. 




参考 

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




 

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

在しない. 

・ISO/IEC12207やISO/IEC15288 のライフサイクルモデルが適用されているあるいは適 

用が要求されている組織において,アジャイル手法が利用されることを妨げるものではな 

い. 

・ISO/IEC15504(プロセス評価 )やISO/IEC15939( 計量プロセス)がアジャイル開発にお 

いて使われることは差し支えない. 

・SC7 標準に精通していて,アジャイル手法及び技法を採用しようとしている組織は, 

ISO/IEC12207という裏付け(context)の中で,ガイダンス( 現時点では, 存在しない)に 

従って,それを適用することが望ましい. 

・SC7 標準に精通していて,アジャイル手法及び技法を採用しようとしている組織は, 

ISO9001という裏付けの中で,( 可能であれば,ISO/IEC9003で使われているのと似た 

やり方を使って,)ガイダンスに従ってそれらを適用することが望ましい. 


出典 :アジャイル開発に関する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) 



参考 

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




ISO/IEC 29110: Software Engineering — Lifecycle Profiles 

for Very Small Entities (VSEs) 

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

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

れている 

• 中小零細ソフトウェア企業にとり, 既存のソフトウェアエンジニアリング規格総体への 

アクセス及び社内採用は高負荷であるものの, 一定の水準確保はやはり必要である 

• 中小零細ソフトウェア企業の良い特性 ( 特定のコンピタンシーやコミュニケーションが密 

といった点 )に配慮する視点も必要である 

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

• 小規模企業のさまざまな規模 , 特性を表現するために「プロファイル」とい 

う特性区分を設け,それぞれのプロファイルごとに必要事項を整理する 




参考 

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




• 例 :アジャイル開発への適用 : WG24 ガイザースバーグ会議議事 

録から 

• “Prepare the work plan and finish the work for the agile 

implementation project.” 

DoD プロジェクトでもアジャイル開発の利用例が増 

えている(*)といったことが提案理由となっている 

(*) 

Defense Procurement Goes Agile by Jesse Fewell on October 2, 2009 

http://www.jessefewell.com/2009/10/02/defense-procurement-goes-agile/ 

出典 : 

伏見諭 ( 情報規格調査会 SC7/WG24 主査 ): 

ISO/IEC 29110の背景とJIS 化への取り組み 

- 規模ソフトウェア開発組織のソフトウェアプロセス規格 – 

( 第 1 回 VSEセンターフォーラム,2011.6.15) 



プロファイル例 (Part2から) 

Entry Profile 

Basic Profile 

Intermediate Profile 

Advanced Profile 

作成中 

成立 

作成中 

未定 


参考 

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




•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 月以降 ) 




経営層への可視化 (1/3) 




付録 

D 社 

アジャイル 

型開発の 

採用 

ライバル社は,まもなくサービスを 

開始すると発表した. 

わが社も, 早期にサービスを提供 

しないと,シェアを奪われてしまう. 

サービス 

システム/ソフトウェア 

仕様 

実装 

メニュー1 機能 1 コード群 1 

優 

先 

順 

位 





S 社 





 




付録 

 

外 

( 経営層 ) 

から 

見ると 

← 完 

成 

度 

1 

2 

3 

4 

5 

← 完 

成 

度 

1 2 3 4 5 か月後 1 2 3 4 5 か月後 

5 

4 

3 

2 

1 

内 

( 開発側 ) 

での 

実際は 

← 進 

捗 

度 

← 進 

捗 

度 

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 か月後 

← 進 

• 機能 n 完成 ,... 

•コーディング○% 終了 

捗 •レビュー□% 完 ,... 

度 

いつでも 

計画対応の 

進捗度を 

報告可 

1 2 3 4 5 か月後 1 2 3 4 5 か月後 


5 

4 

3 

2 

1 

付録 


参考 

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




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

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

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

【Kelton Research 調査 ( 米国 )】 

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

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

と答えており、50%が、IT 部門を通すと時間がかかりすぎると答えてい 

る。 

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

り、64%が新入社員と既存社員の両方の研修に投資していると答えて 

いる。 


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

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



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




ス 

キ 

ル 

診 

断 

開発メンバ育成 

開発技術 ( 基礎知識 ) 

・開発できるレベル 

まで育てる 

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

・テスト駆動開発 

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

/ 設計 

・Java 言語 / Eclipse 

卒 

業 

検 

定 

プロジェクト立上げ 

キプ 

ッロ 

クジ 

オェ 

フク 

ト 

・ 

ア 

・ 

行 

・ 

プ 

ジ動ロ 

ャ指ジ 

イ 

針ェ 

ルク 

概ト 

要憲 

章 

セル 

ミー 

ナキ 

ーー 

ズ 

・ 

ア 

・ 

開 

・ 

フ 

・ 

業 

ジ発レ務 

ャ標ー知 

イ 

準ム 

ルワ 

識 

基ー 

礎ク 

知 

識 

開発チーム育成 

模 

擬 OJT 

開 

発 

・ 

開 

・ 

チ 

・ 

自 

発ー己 

環ム紹 

境ビ介 

知 

ル 

ド 

識 

獲 

得 

・開発者向け 

・ストーリーオーナー 

向けも別途行う 

・サブチーム単位に行う 

・作ったものは捨てる 

育 

成 

開 

始 


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

組 

閣 

参画・プロパー 

・プロダクトオーナー 

・パートナー 

1 日 2~3 日 5 日 


開 

発 

開 

始 


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




開発チー 

ム 

スクラム 

マスター 

顧客 /プ 

ロダクト 

オーナー 

先行チー 

ム 

リーダー PM 経営者層 

/ 購買担 

当など 

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

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

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

業務知識 ○ * ○ 

開発環境 ○ * 

基本アーキテクチャ ○ * 

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

開発技術 △ * 

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

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

アジャイル開発を 

初めて行う組織を対象 


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

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

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



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

名称 

アジャイル概要 

アジャイル基礎知識 

アジャイル擬似体験 

概要 

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

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

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

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

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

開発環境 

基本アーキテクチャ 

業務分析 /モデリング 

開発技術 

ファシリテーション概要 

ファシリテーション演習 




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

検討 ) 

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

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

業務を整理し、開発側に伝えるための手法を理解する 

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

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

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




参考 

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 

 

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 




 

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) 




動かぬIT 人材 




「IT 人材白書 2012 

~ 行動こそが未来を拓く進むクラウド、動かぬIT 人材 ~」の概要から 

田中理事は 

「( 求められている人材は) 今回の調査からも、これまでIT 技術者の最も 

多かった受託開発業務ではないという傾向が明らかになっている。それ 

もアジャイル開発で、自分で仕様書を書けるにとどまらず、自ら企画して 

手が動く人材が求められている。クラウドなどにも積極的に取り組み、 

SaaSのサービスのインプリメントを積極的に行うといった変化を遂げれば、 

日本のIT 技術者の将来は決して暗いものではない」 

と、旬な技術にいち早く取り組む姿勢の重要性をあらためて強調した。 


< 出典 > 

ITの変化に技術者の対応が遅れている--IPAのIT 人材白書 2012 

(ZDNet Japan, 2012 年 05 月 14 日 ) 

http://japan.zdnet.com/development/analysis/35016977/ 



事例調査結果 1(1/2) 




• 小売業における業務システム開発事例 

• 小売業を営む顧客のマーチャンダイジングシステム開発を出発点に、 

これまでに260メニュー、80 万ステップの開発 

項目 

優先したIT 戦略 


チーム編成 

プロジェクト期間 

プロジェクト初期におけ 

る要件の確定度合い 

契約形態 

内容 

開発当初の目的は、既存システムの完全リプレイス 

ユーザヒアリング 

→ データ設計およびサンプルプログラム開発 

→ 構築 (イテレーション期間 ) 

ベテラン開発者 1 名 + 新人 5 名 

顧客側にも同数程度のプロジェクトメンバを配置 

6ヶ月 

外部仕様レベルでの基本要件は固まっていた 

要求の確認は、ユーザとの会話と実際に動作するプログ 

ラムで行う 

請負契約ではなく、顧客の開発業務を支援する形態 





• 特性レーダーチャート 

開発人数の多さ 

チームにおける、「平均レ 

ベル以下の、経験は少な 

いが、勤勉な開発者」の 

割合 

5 

4 

チームにおける、「非ウォータ 

フォールまたはウォータフォール 

型開発のプロジェクトをマネジメ 

ントできる人」の割合 




新規性 ( 技術 ( )の豊かさ 

新規性 (ビジネス)の豊かさ 

3 

2 

1 

0 

Time-to-marketの 

時間的制約の厳しさ 

組織文化 

プロジェクト初期における要件 

の確定度合いの低さ 

プロジェクト期間の短さ 

アプリケーションシステムの 

重要度の高さ 

要求された稼働率の高さ 





• 携帯ソーシャルゲーム開発事例 

•これまで多くのWebサービスをアジャイル型で開発してきた企業によるもの 

項目 

優先したIT 戦略 

内容 

スピード、要求の変化への対応、利用率を優先 

ライフサイクルモデル α 版開発 (1.5ヶ月 ) →α 版改修 (0.5ヶ月 ) 

→β 版開発 ~クローズドβ 公開 (0.5ヶ月 ) 

→ β 版改修 ~ 全展開 (0.5ヶ月 ) 

イテレーション期間 :1~2 週間 

サービスイン後もDay~Week 単位で改版継続 



プロジェクト初期における 

要件の確定度合い 

契約形態 

企画 1 名、エンジニア1 名 

後半、業務系開発にベンダ1 名追加 

3ヶ月 ~ 継続中 

ゼロベースからの検討を要した 

社内開発であるため、契約関係はない。 












新規性 ( 技術 )の 

豊かさ 

Time-to-marketの 

時間的制約の厳しさ 

新規性 (ビジネス)の 

豊かさ 


要件の確定度合いの低さ 




の短さ 

要求された 

稼働率の高さ 








• 株取引のためのWebアプリケーション開発事例 

• “セル”と称する小集団の枠組みにより開発 

項目 

内容 

優先したIT 戦略投資回収を早めるため早期ビジネス化。 

システム利用者の反応を見ながら構築。 

情報システム部門の負荷軽減、数年間は利用。 

品質要求は保守性を最優先・使いやすさと応答の即応性 


セル開発、収益性の高い機能から開発 

イテレーションは2 週間 




要件の確定度合い 

契約形態 

小集団 (セル)の枠組み 

顧客と2 週間に1 回、受け入れ検収を実施 

23ヶ月 

非常に低い 

請負。対象となるシステムのスコープや品質基準とイテレーショ 

ン回数と各イテレーションで平行稼動させるセル数を基準 





• 特株性取レーダーチャート 

引のためのWebアプリケーション開発事例 













• 業界共通電子データ交換基盤構築事例 

• 要件提供者が多数存在するため、システム構成をモジュール化し、 

要件の固まったモジュールから順に開発 

項目 

内容 

優先したIT 戦略業界標準、共通画面・共通操作が可能、企業間システム連携、 

基本機能は無償、中小企業用の標準システムの構築 

短期開発を可能にするためのシステムのモジュール構造化 


初期プロトタイプの開発後、ユーザレビュー・機能拡張を継続 

EDI 基盤のコアの部分をはじめに固め、サブを順次追加 

2 週間単位のイテレーション 

チーム編成 15 名 (リーダ:1、仕様担当 :5、設計担当 3、開発担当 :6) 


プロジェクト初期におけ 

る要件の確定度合い 

契約形態 

初期プロトタイプの開発に3ヶ月 

多業種にわたるシステムであるため、開発当初は仕様が全く 

分からない、かつ固められない状態 

準委任契約 









チームにおける、「平均レベ 

ル以下の、経験は少ないが、 

勤勉な開発者」の割合 

5 

チームにおける「非ウォータフォール 

開発人数の多さ 

またはウォータフォール型開発のプロ 

4 

ジェクトをマネジメントできる人」の割合 

新規性 ( 技術 )の 

豊かさ 

3 

2 

1 

Time-to-Marketの時間的 

制約の厳しさ 

新規性 (ビジネス)の 

豊かさ 

0 

組織文化 





プロジェクト期間の短さ 

要求された稼働率の高さ 




参考 

事例 : 活用されているプラクティス 




反復型計画 

21 

チーム全体が一つに 15 

71.4% 

100% 

頻繁なふりかえり 

11 

52.4% 

計画ゲーム 

10 

47.6% 

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

10 

47.6% 

( 朝会 ) 

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

9 

42.9% 

ペアプログラミング 

バーンダウンチャート 

8 

8 

38.1% 

38.1% 

リファクタリング 

6 

28.6% 

テスト駆動開発 

5 

23.8% 

コードの共同所有 

かんばん 

自動化された回帰テスト 

ニコニコカレンダー 

顧客プロキシ 

タスクカード 

ポストイット 

タイムボックス 

4 

4 

4 

3 

3 

3 

3 

3 

19% 

19% 

19% 

14.3% 

14.3% 

14.3% 

14.3% 

14.3% 

頻繁なリリース 

コーディング規約 

2 

2 

9.5% 

9.5% 

ストーリーカード 

スクラムのスプリント 

2 

2 

9.5% 

9.5% 

単体テストの自動化 

スプリントバックログ 

2 

2 

9.5% 

9.5% 

件数 

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

0 2 4 6 8 10 12 14 16 18 20 22 




中・大規模開発事例概要 (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なやり方 (できたものから、都度リリースしていくようなやり方 ) からスクラムに移行 




課題 ( 一覧 )と目指すべきゴール 




法 

・ 

環 

境 

プ 

ロ 

ジ 

ェ 

ク 

ト 

人 

材 

組 

織 

リ 

フ 

ァ 

レ 

ン 

ス 

課題 

事業者と開発者のあいだに契約 

やセキュリティ基準の壁や物理的 

な距離による壁がある 

事業者のソフトウェア開発への理 

解とコミットメントが乏しいため、 

中大規模開発に最適な開発手法 

の選択やプロジェクトの進め方で 

きていない 

非ウォーターフォール型開発ができ 

るスキルを持った開発者を一定人 

数以上、集めることが難しい 

中大規模開発では組織を含めた 

改革が必要とされることがあるが、 

成功へ導く組織構造と、変革のプ 

ロセスが明確ではない 

中大規模開発に関して、日本の 

産業構造や文化にあった開発手 

法がまとめられていない 


提言 

• 複数企業、多国籍、多重構造中大規模に適した契約 

テンプレート、コンプライアンスやセキュリティ基準、監 

査基準の整備と提示する 

• 参加型意思決定手法の紹介・導入支援 

• 事業者と開発者の関わり方やプライオリティ付けの 

手法を学び、実践できるようにする 

• 大規模開発であっても、一気に大きくせずに漸進的 

な展開方法を提示する 

• 非ウォーターフォール型開発実践者の育成と人材確保 

• 認定研修・コンサルタント活用・社内外の勉強会への 

助成と人材プールを構築する 

• 「開発手法を変える」ではなく「組織文化を変える」視 

点へ移行する 

• 組織評価とデザイン手法を立ち上げる 

• 非ウォーターフォール型開発リファレンス作成 

• 中大規模開発の幅広く事例を収集し、工夫や指針 

の提示が必要 

• ビジネス、文化や組織構造の調査と設計手法の策 

定 


目指すべき 

ゴール 

日本のソフトウェ 

ア産業の実態に 

適したソフトウェ 

アの作り方を提 

案する 

日本のソフトウェ 

ア産業の競争力 

を高める 

エンジニアが生 

き生きと働ける 

環境を作る 


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

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

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




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



環境条件 

状況に適した開発手法 


変化する 



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




計画性・確実性・安定性 


変化への適応性・迅速性 


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

変化 

今後の境界線 


従来の境界線 

・ビジネス上の段階 

・システムの深刻度 

・要件の固まり具合、変化の度合い 

・開発対象の成熟度 

- 新規開発、改造、再構築、保守 

・アーキテクチャの成熟度 

・規模の大小 




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





環境条件 

・手法に対する組織の経験、成熟度 

・手法に対するメンバの慣れ、成熟度 

・組織の制度、統制 

・組織の地理的分散 

・組織の風土 

- 新しい試みに対する挑戦の空気 

- 経営 /マネジメント層の理解と支援 

ユーザ経営層の意識 

ベンダ経営層の意識 

人材の育成と適正配置 

契約形態 




参考 

アジャイル型開発のスイートスポット(2) 




• 通常は,JavaまたはC#の環境で, 組込みではなくウェブアプリケーショ 

ンを, 最終的なエンドユーザや実際の顧客とかなり近い環境で開発する 

ところ. 

• チームの大きさはふつう,かなり小さく,すべてで12 人にも満たない.し 

かし, 大きなチームでの経験も蓄積され続けている.チームの中には他 

の場所にいるメンバもいるかもしれないが,チームの中核はエンドユー 

ザのかなり近くで仕事をする. 

• まだ開発が始まっていないプロジェクトよりも, 既存のシステムの方が簡 

単にアジャイル型開発を適用できる. 重要なのは, 新しいプロジェクトで 

も既存のシステムでもアジャイル型で開発するための十分な経験が蓄 

積されているということ. 

• アジャイル型開発のスイートスポットには好循環が存在し, 多くの経験 

が多くの成功をもたらし,その成功がまた経験を得る機会を生み出す. 

出典「アジャイルの限界」( 作者 :Alan Kelly, 翻訳者 : 徳武聡 , 投稿日 ;2010 年 8 月 17 日 ) 

http://www.infoq.com/jp/articles/limits-of-agile 




組合せモデルの例 

要件定義 

コア開発 

要 

求 

開 

発 

テ 

ス 

ト 

要 

求 

開 

発 

テ 

ス 

ト 

要 

求 

開 

発 

テ 

ス 

ト 

要 

求 

開 

発 

第一反復第二反復第三反復第四反復 

イテレーション 

テ 

ス 

ト 

システム 

運用 




仕様や設計の ( 場合によっては大幅な) 変更が当然あるものという前 

提で、最初から厳密な仕様を抽出しようとせず、大まかな仕様だけで細 

かいイテレーション ( 反復 ) 開発を始め、すぐに実装・テストを行って仕様 

や設計の妥当性を検証するというアプローチを採る 

IPAグローバルシンポジウム2010 児島プレス兼子邦彦氏講演より 

アイルランドやフィンランドにおける中小ソフトウェア企業 (SMEs) が、車 

載ソフト開発を開発するとき、旧来の計画駆動型 (plan-driven 

software development) とアジャイル型開発手法とを組み合せた手法を 

用いている(この論文は、そのプロセス評価の方法について述べたもの) 

“AHAA-Agile, Hybrid Assessment Method for Automotive, 

Safety Critical SMEs (Small-to-medium sized enterprises)”,ICSE’08 




参考 

ビジネス・ステージと開発手法 (1/3) 




ソフトウェア 

製品の 

ライフサイクル・ 

モデル 

Figure 1. A financial model of software product development. 

< 出典 > Ram Chillarege: The Marriage of Business Dynamics and Software Engineering, 

IEEE SOFTWARE, November/December 2002. 




参考 





ビジネスステージに 

応じて変化する, 

ビジネス価値の要因 

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. 




参考 





ビジネス価値要因 (ビジネスステージに応じ変化 )に整合した開発手法を 






参考 

最適にリスクを取るマネジメントの考え方 




( 変化の激しい)ビジネス・ニーズに応えるためにリスクを取る 

↓ 

どこで( 誰が)リスクを取るか? 

↓ 

顧客経営層 -システム部門間 , 顧客 -ベンダ間の緊密な協力 , 

円滑なコミュニケーションのもとで, 最適な分担でリスクを取る 

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】「設計者のやる気を引き出せるマネジメント」, 経営層 / 管理職向けの講演に涙する 

( 日経 BP 社 EDA Online,2011/06/10) 




参考 

明確な「行動規準」に基づく判断による行動 




震度 5 強の揺れは、...7 万人の来園者 ( 同社ではゲストと呼ぶ)たちは、前代未聞の体 

験に当然パニック状態になる。しかし揺れから40 秒後には、地震発生を伝える園内アナ 

ウンスが流れた。...そしてキャストたちはパニックを起こさなかった。彼らは持ち場のゲ 

ストに対して、すぐさま冷静かつはっきりとした声で、分かりやすい指示を出した。 

「( 店舗で販売用に置いていたぬいぐるみの)ダッフィーを持ち出して、お客様に“これで頭 

を守ってください”と言ってお渡ししました」。彼女は会社から、お客様の安全確保のため 

には、園内の使えるものは何でも使ってよいと聞いていた。そこで、ぬいぐるみを防災ずき 

ん代わりにしようと考えたという。 

同じくキャストのIさんは、店舗で販売していたクッキーやチョコレートを無料で配り始めた。 

幹部は開園以来 28 年間守ってきた“ 禁 ”を破る決断をした。バックヤードという従業員だ 

けが利用する通路にゲストを通して、より短距離で安全にシーに誘導することにしたのだ。 

TDRはキャストが自ら判断し、行動できる前提を用意している。「会社とし 

て大切にするべきことと優先順位」= 行動規準を明確に示し、十分な研 

修を実施して、一人ひとりが判断し行動することを推進している。 


引用 : 武田斉紀「3.11もブレなかった東京ディズニーランドの優先順位」 

( 日経ビジネスオンライン,2011 年 5 月 16 日 ) 



参考 

適用に向けた工夫に関する参考文献等 




・長沢智治 (マイクロソフト), 玉川憲 ( 日本 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%20Agilit 

y%20Overview%20Agile%202009.pdf 

邦訳 : 「アジャイル開発の本質とスケールアップ」( 翔泳社 ) 




ソフトウェアエンジニアリング上の主な課題 (1/3) 




1 機能視点で開発を順次進めるため、システムのアーキテクチャ 

の確立に不安がある。 

アジャイル型開発では、アーキテクチャは「創発」すると捉えられており、こ 

れは、ウォーターフォール型開発においてアーキテクチャに大きな事前コスト 

をかけすぎたことの反省から来ている。しかし、イテレーション毎の局所視 

点とリファクタリングによる創発性のみにアーキテクチャを任せることができ 

るか、また、「十分な」アーキテクチャとは何か、という議論は今後必要であ 

ろう。 

2 機能間に依存性が強い場合、イテレーションに入力する機能 

の順序に制約ができるケースがある。 

アジャイル型開発では、依存性をなるべくなくし、細分化して機能分割す 

ることが求められる。また、その場合でも、リファクタリングの負荷が大きく 

なる場合がある。 








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





4 大規模システムへの適用経験に学ぶ(エントロピー増加 )。 




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

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

IPA/SEC Special Seminar (2012-05-23)




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

契約モデルの提案 




参考 

調査事例 : 契約形態の集計 (H21 年度 ) 




契約の種類件数比率 

請負契約 6 33.3% 

請負契約 ( 月毎 ) 1 5.6% 

請負契約 + 準委任契約 1 5.6% 

準委任契約 7 38.9% 

労働者派遣契約 1 5.6% 

不明 2 11.1% 

合計 18 100 % 

( 社内開発 : 契約無し) (4) ー 

⇒ 海外では、直接雇用やTime&Materialの準委任型契約が中心だが、 

日本では、アジャイル型開発とはなじみにくい請負契約の割合も高い。 




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




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

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

- 担当作業の迅速な実施 

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

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

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

- 性能・品質等が不明確 

- 工数見積りが困難 (コスト未定 ) 

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

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

契約 




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




• 契約 

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

•アジャイル開発 

変化に対応すべく、合意内容の変更を柔軟に認め、 

当事者をなるべく拘束しない 

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

契約 






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


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

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

で完成させるか不明 )。 

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

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

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

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

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

契約 




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




• 基本 / 個別契約モデル: 

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

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

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

• 組合モデル: 

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

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

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

ユーザに分配される)。 

契約 




基本 / 個別契約モデルの概要 





企画 

要 

開 

テ 

求 

発 

ス 

ト 

・・・ 

要 

開 

テ 

求 

発 

ス 

ト 

要 

開 

テ 

求 

発 

ス 

ト 

・・・ 

要 

開 

テ 

求 

発 

ス 

ト 

要 

開 

テ 

求 

発 

ス 

ト 

・・・ 

要 

開 

テ 

求 

発 

ス 

ト 

第 1 反復 

第 n 反復 

第 1 反復 

第 n 反復 

第 1 反復 

第 n 反復 

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



基本契約 

基本契約 


個別契約 

個別契約 

個別契約 

個別契約 

個別契約 

個別契約 

契約 




組合モデルの概要 




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

ベンダ 

製作に関わる労務出資 

組合 

ベンダ 

業務執行組合員 

ユーザ 

業務執行組合員 

投資家 

組合員 

( 

本 

例 

で 

は 

同 

一 

主 

体 

) 

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

組合 -ベンダ間の開発契約 

は 

基本 / 個別契約モデルの 

個別契約を利用する。 

ベンダ 

ユーザ 

製作に関わる資本出資 

投資家 

製作に関わる資本出資 

契約 


組合契約 

( 製作管理と成果管理を規定する) 

成果物の企画 

スケジュール・予算管理 

知的財産管理 

成果物の収益分配 

利害関係者との権利調整 

組合員の倒産、脱退 

清算 


イテレーション単位で 

成果物を納品 


参考 

日本の調達モデル 

ユーザ (CIO) 




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

ハード 

ウエア 

データ 

ベース 

パッケージ 

システム 

開発 

経営 

システム 

外部設計 

ハードウエア 

ベンダ 


ベンダ 

経営システム 

コンサル 


データベース・ 

ベンダ 

システム開発 

ベンダ 

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



参考 

米国の調達モデル 




ユーザ (CIO,PMO) 

ハード 

ウエア 

データ 

ベース 


システム 

開発 

経営 

システム 

外部設計 

ハードウエア 

ベンダ 


ベンダ 

経営システム 

コンサル 


データベース・ 

ベンダ 

システム開発 

ベンダ 




参考 

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











各種調査データ 




参考 

日本ではまだアジャイル手法の利用は少ない(1) 

反復型 

2.4% 

その他 

1.1% 

2012 年秋 

刊行予定 

反復型 

2.7% 




その他 

1.2% 


96.5% 


96.1% 

N=2957 

ソフトウェア開発データ白書 2012-2013 

N=2451 

ソフトウェア開発データ白書 2010-2011 




参考 

日本ではまだアジャイル手法の利用は少ない(2) 




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

http://www.meti.go.jp/policy/mono_info_service/joho/softwaremetrics/2010/index.html 




参考 

日本ではまだアジャイル手法の利用は少ない(2’) 




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

http://www.meti.go.jp/policy/mono_info_service/joho/softwaremetrics/2011/index.html 




使われている開発モデルの調査例 (3) 




出典 : 第 17 回企業 IT 動向調査 2011(10 年度調査 ) (2011.5.17, 社団法人日本情報システム・ユーザー協会 ) 




使われている開発モデルの調査例 (4) 




出典 : 第 17 回企業 IT 動向調査 2011(10 年度調査 ) (2011.5.17, 社団法人日本情報システム・ユーザー協会 ) 




参考 

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




• 2010 年に発表された, 米国調査会社フォレスター・リサーチ 

社のレポートによる, 米国のアジャイル開発利用率 




参考 

アジャイル開発におけるコミュニケーション(1/5) 




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

N=82 

出典 : Ambysoft 

Agile Teams Mini-Survey Results: 

April/May 2011 

平均 17 人 

100 人以上を除くと 

平均 10.1 人 




参考 





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

同室 

同フロア 

同建物 

N=82 

47% were co-located, 

3 時間以内 

何人かは3 時間以上 

23% near located, and 

30% far-located. 




参考 





ステークホルダ( 顧客側 )との距離 

同室 

同フロア 

同建物 

N=82 

9% were co-located, 

56% near located, 

3 時間以内 

何人かは3 時間以上 

and 35% far located. 




参考 


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




N=82 

数回 / 週 

毎日 

1 回 / 週 

終日 

58% indicated at least daily 

communication and an 

additional 36% indicated at 

least weekly 

communication. 




参考 





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

50% 以上 

• 電子メール 

•Face-To-Face 

• 反復終了後のデモ 

•リポジトリ 

•ホワイトボード 

•ドキュメンテーション 

•オンライン・チャット 

•プレゼンテーション 

N=82 




参考 

最重点テーマは「リアルタイム経営」(1/2) 






出典 : 

企業 IT 動向調査 2011 

(JUAS) 


参考 

最重点テーマは「リアルタイム経営」(2/2) 

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




時間間隔を短縮し, 状況 

の観測 ( 計測 )と判断行動 

( 制御 )とを同時並行で実 

行すること 

↓ 

限りなく連続のリアルタイ 

ムのSCMは,そうでない場 

合に比べ, 過剰在庫と機 

会損失を大幅に削減可能 . 

IT 戦略に適用すると 

出典 :サプライチェーンの可能性を求めて, 

http://www.bizdyn.jp/report/scm01/scm01_029.html 



アジャイル開発 


参考 

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




ソフトウェア 

製品の 

ライフサイクル・ 

モデル例 

と 

開発手法 

アジャイル 

ウォーターフォール 

Figure 1. A financial model of software product development. 






参考 

対象に応じてアジャイル手法を( 部分 ) 適用 




プロジェクト管理に 

アジャイルのプラクティスを使う程度 

選択的に 

広範囲に 

無し 



Source: PM NETWORK, 

September 2011, Vol. 25, No. 9 


参考 

ハイブリッド型の適用が進む(1) 




・スクラム系が多い 

・カスタム・ハイブリッド 

も伸びている 


Source: VERSIONONE: State of Agile Survey 2011 



参考 

ハイブリッド型の適用が進む(2) 

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 


参考 

リスクを軽減するアジャイル手法 (1/3) 




出典 : 

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 




参考 


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




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




事例 


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

最初はウォーター 

フォール型で開発 

をスタートしたが, 

途中でアジャイル 

型 (スクラム)に切 

り替え, 成功した. 




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 


中大規模開発調査 

適用分野 

• 大半 (80% 以上 ) がインターネット上のB2Cサービス開発に適用 




• 半数以上が自社組織内に開発部隊を抱える形態 ( 事業者と開発者 

の間に契約関係がない形態 ) を採用 

システム種別 

契約関係 

基幹システム, 8% 

市販ゲーム 

ソフト, 

9% 

受託開発 

( 請負 ), 

17% 

受託開発 

( 非公開 ), 

8% 

自社開発 , 

41% 

B2Cサービス, 83% 

受託開発 

( 準委任 ), 

17% 

自社開発 

( 一部オフショ 

ア), 

17% 




中大規模開発調査 

非ウォーターフォール型開発の採用理由 




ウォーターフォール型開発で 

プロジェクトが失敗した 

理由 No.3 

市場や社会の 

変化に対応したい 

理由 No.1 

要件が固められない 

実際のサービスや製品を見ないと 

ビジネス価値を評価できない 

理由 No.2 

管理コストを下げたい 

効果は… 

1. 動くモノを見ながら開発できた 

2. 管理コスト削減 

3. 迅速なサービスの提供 

でした 

非ウォーターフォール型開発の選択 

成功度 

うまくいった 

部分もある 

が、 

うまくいってい 

ない面もあ… 

うまくいった 

25% 

かなりの部分 

でうまくいった 

12% 




海外普及要因調査 



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


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

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

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

Scrum Master 等人数の経年変化 

単位 ( 人 ) 

米国英国中国デンマークブラジル日本 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 Allianceによる協力 

略 

称 •CSM (Certified Scrum Master) 

説 ‣ 開発チーム側の運営者 

明 •CSPO(Certified Scrum Product Owner) 

‣ユーザ側のプロダクト責任者 

•CSP(Certified Scrum Professional) 

‣CSM、CSPOを育成 

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

単位 ( 人 ) 




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

パ 

フ 

ォ 

ー 

マ 

ン 

ス 

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




ウォーターフォールとアジャイルとの協働により, 

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

プロセス改善 

プロセス改善 


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

アクティビティ 



プロセス・イノベーションに向けて 




イノベーションの意味は, 仕組みや社会制度の革新も含まれる. 

全く新しい技術や考え方を取り入れて新たな価値を生み出し, 

社会的に大きな変化を起こすことである. 

(1911 年 , 経済学者・シュンペーター) 

イノベーションは, 複数の文化が交わるところに生まれる. 

それぞれの文化において強固な基盤が必要であり, 

各文化のフロンティアにおけるコミュニケーションと協働により 

イノベーションがもたらされる. 

< 参考 ( 意訳 )> 

Innovate America: ( 通称 “Palmisano Report”) 

チャレンジとチェンジの世界における繁栄 - 全米イノベーションイニシアチブ報告書 

http://homepage1.nifty.com/bicycletour/sci-rep.priv.InnovateAmerica.htm 




参考 

異文化コラボレーションの事例 




•NTTデータ: 分散開発環境に対するアジャイル開発の適用 

事例 (イノベーションスプリント2011) 

•TDD 研究会 :ウォーターフォール型テストケースへの整合の 

ためのテスト駆動開発 (TDD)の拡張提案 (ソフトウェアテス 

トシンポジウム2011) 

•ソニーEMCS:XDDPとScrumとの組合せ( 派生開発カンファ 

レンス2011) 

まず,アジャイル開発のプラクティスのいくつかを,ウォーター 

フォール型開発に導入してみることから始めるのも一つの手 ? 







日本のソフトウェア産業を 

もっと元気にしよう

SEC - IPA 独立行政法人 情報処理推進機構

You also want an ePaper? Increase the reach of your titles

Delete template?

Save as template?

SEC - IPA 独立行政法人情報処理推進機構