非ウォーターフォール型開発の適用事例と課題 ·...

Information-technology Promotion Agency, Japan

SoftwareEngineeringCenter

Software Engineering CenterCopyright © 2010 ＩＰＡ, All Rights Reserved

非ウォーターフォール型開発の適用事例と課題

2010年12月2日

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

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

専門委員伊久美功一

SECSoftware Engineeringfor Mo･No･Zu･Ku･Ri

2Software Engineering Center

非ウォーターフォール型開発における課題と

目指すべきゴール案(1/2)

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

適用に適した領域を見定め、

その活用を普及促進していく

●日本のソフトウェア産業の実態に適しており、かつ世の中のパラダイム転換に対応することのできるソフトウェアの作り方の提案になる。

●グローバルな視点から見た我が国のソフトウェア産業の競争力を強化することにつながる。

●エンジニア一人ひとりが生き生きと働くことのできる環境の整備につながる。

Copyright © 2010 ＩＰＡ, All Rights Reserved



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

契約のあり方、調達、制度設計契約

日本のソフトウェアの作り方

経営層やユーザ企業への理解促進価値評価

コンサルタント等の役割の整備人財育成

普及

欧米の競争力（ビジネスドライバ、産業構造など）の調査

調査

重点課題

目指すべきゴール

管理手法や技術面の整備環境整備

領域見定め


非ウォーターフォール型開発における課題と

目指すべきゴール案(2/2)



非ウォーターフォール型開発に向けた検討の背景

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

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

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

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

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

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

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

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

C) ソフトウェア産業構造上の課題

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

→開発の過程と各開発者の役割や成果を可視化し、モチベーション向上をはかる




アジャイルの得意、不得意領域

■ 得意領域・ビジネス要求の変化が激しく、あらかじめ固定できない。

・リスクの高い領域

・不確実なマーケット

・不案内な技術領域の探索

・短いTTM（Time to Market）への対応したいというビジネス（Webのサービス、パッケージ開発、自社製品開発）

■ 現状の不安領域（今後なんとかしていきたい領域）・大規模

・分散拠点（オフショア）

・契約をまたぐチーム（受託、外注）

・ビジネス価値より計画遵守を重視する場面


※以降、非ウォーターフォール型開発とアジャイルとを同義語として扱う。



IPA/SECにおける取組み

■非ウォーターフォール型開発の適用が限定的であるため、

適用領域を定め、拡大したい。

H21年度：事例調査(22事例)の実施と共に、有識者研究会での議論

H22年度：調査研究に基づき抽出した課題へ対応

① 顧客・経営層へのアピール

② 契約の形態(非ウォーターフォール型開発に適した契約モデル)

③ 非ウォーターフォール型開発に必要な技術の明確化

④ 普及・展開施策

H22年度末に「SECガイドブック」または、「報告書」としてとりまとめる予定




H21年度の事例調査：概要

目的：アジャイル型開発を中心とする非ウォーターフォール型開発の適用状況を明らかにし、適用する上での課題を明らかにする

実施内容：17社、22事例を対象に開発対象の特性・適用領域および開発方法、適用プラクティス、契約形態、等について事例調査を実施。併せて研究会を発足し、適用にあたっての課題を抽出

→報告書として公開：URL:http://sec.ipa.go.jp/reports/20100330a.html




事例調査一覧(1/2)

No. 事例概要

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

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

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

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

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

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

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

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

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

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

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




事例調査一覧(2/2)

No. 事例概要

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

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

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

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

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

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

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

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

２０ Webメディア開発事例

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

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




事例調査結果①(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ヶ月～継続中


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

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


13Software Engineering CenterCopyright © 2010 ＩＰＡ, All Rights Reserved

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

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

要件の確定度合いの低さ

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

重要度の高さ

Time-to-marketの時間的制約

の厳しさ

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

新規性(技術)の豊かさ

プロジェクト期間の短さ

要求された稼働率の高さ




事例調査結果③（1/2）

株取引のためのWebアプリケーション開発事例セルと称する小集団枠組によって開発

非常に低いプロジェクト初期における要件の確定度合い

セル開発、収益性の高い機能から開発イテレーションは2週間

ライフサイクルモデル

請負。対象となるシステムのスコープや品質基準とイテレーション回数と各イテレーションで平行稼動させるセル数を基準

契約形態

23ヶ月プロジェクト期間

小集団(セル)の枠組み顧客と2週間に1回、受け入れ検収を実施

チーム編成

投資回収を早めるため早期ビジネス化。システム利用者の反応を見ながら構築。情報システム部門の負荷軽減、数年間は利用。品質要求は保守性を最優先・使いやすさと応答の即応性

優先したIT戦略

内容項目




事例調査結果③(2/2)株取引のためのWebアプリケーション開発事例

プロジェクト初期における要件の確定度合いの低さ




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

業界共通電子データ交換基盤構築事例要件提供者が多数存在するため、システム構成をモジュール化し、

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

項目内容

優先したIT戦略業界標準、共通画面・共通操作が可能、企業間システム連携、基本機能は無償、中小企業用の標準システムの構築短期開発を可能にするためのシステムのモジュール構造化ハード・ソフトの省資源化（グリーンIT化）(最終的にはSaaS化)

ライフサイクルモデル初期プロトタイプの開発後、ユーザレビュー・機能拡張を継続EDI基盤のコアの部分をはじめに固め、サブを順次追加2週間単位のイテレーション

チーム編成 15名（リーダ：1名、仕様担当：5名、設計担当3名、開発担当：6名）

プロジェクト期間初期プロトタイプの開発に3ヶ月


多業種にわたるシステムであるため、開発当初は仕様が全く分からない、かつ固められない状態

契約形態準委任契約Copyright © 2010 ＩＰＡ, All Rights Reserved



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



0

1

2

3

4

5

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

ベル以下の、経験は少な

いが、勤勉な開発者」の割合

チームにおける「非ウォータフォールまたはウォータフォール型開発のプロジェクトをマネジメントできる人」の割合

Time-to-Marketの時間的制約の厳しさ

組織文化

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

の重要度

要求された稼働率プロジェクト期間

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

要件の確定度合い

新規性 (ビジネス )

新規性 (技術 )

開発人数



3軸を用いてプロジェクト特性を分類

不確実性市場の不確実性、技術の不確実性、プロジェクトの期間、

依存関係/スコープの柔軟性

高速適応性リリース密度(リリース回数/プロジェクト期間[月])、CI環境の商用フレームワークからの独立度、ソフトウェア実装フレームワークの複雑度

複雑性チームの大きさ、ミッションクリティカル性、チームの場所、チームの能力、ドメイン知識のギャップ、依存関係

事例特性の分類(1)




適応領域のマップを作成し、仮説を設けて検証仮説「高い高速適応性」「高い不確実性」の領域

⇒企業内知識共有、研究・企画支援、等「高い高速適応性」「低い不確実性」の領域

⇒パッケージ、ユーティリティなどのいわゆるプロダクト開発「低い高速適応性」「低い不確実性」の領域

⇒基幹システム「低い高速適応性」「高い不確実性」の領域

⇒ネット販売、ネット取引、教育・訓練支援、等検証結果

22事例をマップにプロットすると、概ね仮説と一致。しかし、一部一致しない事例もあった。

考察複雑性が高いと高速適応性が低い（複雑性が低いと高速適応性が高

い）不確実性の高低に関わらず、様々な組み合わせに対し、非ウォーター

フォール型開発の適応が広がっていると考えられる。

事例特性の分類(2)




高速適応性

不確実性複雑性

分類結果不確実性が高い

事例特性の分類結果(3) 企業内知識共有支援・企画支援、等

パッケージなどプロダクト開発

第1象限第2象限

第4象限第3象限複雑性が高い

不確実性が高い

第1象限第2象限

第4象限第3象限複雑性が高い

基幹系システム

ネット販売、ネット取引、教育・訓

練支援、等

凡例:

● 第1象限の性質を持つ事例







チームの人数

（人）

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

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％



件数

14121086420 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

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


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



6%

7%

31%

31%

34%

35%41%

41%

44%

49%52%

57%

59%

59%60%

62%

65%72%

75%

77%

86%

0% 10% 20% 30% 40% 50% 60% 70% 80% 90% 100%

カンバン

行動駆動開発（BDD）アナログ・タスクボード

ペアプログラミング

オンサイト顧客

デジタル・タスクボード

コード・オーナーシップ

タスクボードの組合せ

オープンスペース

テスト駆動型開発

スピード

コーディング作法レトロスペクティブ

リファクタリング

バーンダウンチャート

自動ビルド

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

リリース計画

デイリー・スタンダップユニットテスト

反復型計画

参考：活用されているプラクティス（海外）


※22事例とは項目が異なる。（VersionOne社アジャイル開発の現状調査第3回2008より）



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

0

1

2

3

4

5

6

7

1 2 3 4 5 6 7 8イテレーション(スプリント)期間（週）

事例の数

（件）

その他：1～2週間 2件1～4週間 1件


⇒1～2週間が中心



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

22%21%

12%10%

9%

6% 6%4%

3%2% 2% 2%

1%

0%

5%

10%

15%

20%

25%

Tim

e-to

-Marke

t

の

加速

変化する優先順位

管理のため

生産性向上

ソフトウェア品質の

向上

IT

とビジネスの

融合改善

プロジェクトの

見える化

リスク削減

開発プロセスの

簡易化

その他

エンジニアリングの

導入／向上

コスト削減

保守性／拡張性向上

チームの

やる気改善

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

（VersionOne社アジャイル開発の現状調査第3回2008より）Copyright © 2010 ＩＰＡ, All Rights Reserved



22事例の契約形態

契約の種類件数比率

請負契約６３３．３％

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

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

準委任契約７３８．９％

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

不明２１１．１％

合計１８１００％

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


⇒海外では、直接雇用やTime&Materialの準委任型契約が中心だが、一方、日本では、非ウォーターフォール型開発とはなじみにくい請負契約の割合も高い。



(参考)契約の種類

契約の種類内容

請負契約ベンダ企業側が成果物の完成を請負い、ユーザ企業側が成果物に対する報酬の支払いを約束する契約形態

準委任契約業務を委託する契約であり、ベンダ企業側の責任は、業務を実施することにあり、成果物に対する完成責任を負わない

労働者派遣契約

派遣元の社員を派遣先の指揮命令で働かせることができる契約通常は、派遣先が就労場所になる派遣先と労働者とは、指揮命令関係こそあるけれども、雇用関係はない




顧客参画の実態

週に1～2回のコミットが求められていることが多い

事例

プロジェクト目標のシェアのみ

顧客側に２週間に1回、必ず受け入れ検収を実施

2週間に1〜 3度、オーナが来社しオンサイト顧客を実施

週に１回、プロジェクトの進捗状況を開発プロジェクトマネージャが発注元の開発マネージャへ報告

週次で開発マネージャを含めて計画ゲームを行い、次回のリリース計画を作成した

発注者と開発者は毎週２回の打合せで週次イテレーション開発

開発者全員が現地に常駐

顧客参画


参画

小

大



事例調査のまとめ(１)

開発チーム

約8割が10名以下

他は10数名が多い

開発期間

2か月～4か月が45%

１年を超えるものは35%

契約形態

請負契約、準委任契約が多い

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

反復型計画、チーム全体が一つに、頻繁なふりかえりが多い

２２事例から言えること




事例調査のまとめ(２)


開発内容・方法社内開発が多い自社内で利用するソフトを内製販売するためのパッケージの開発

Webアプリケーション領域だけでなく、企業系システムへの適用が始まっている。但し、成功事例が共有されておらず、ベンダ・ユーザもコンサル会社に依存している面がある。

大手SI業者でも、トライアルが行われ、社内基準への取組みが始められている。

変化への対応、市場への迅速な投入の効果市場の声を聞きながら改善、用件の確定度合いが低い、用件が変化する

生産性の改善分は、品質や保守性の向上へ対応従来型開発(ウォーターフォール型)と使い分け大規模なシステムへの適用は見当たらない



アジャイル手法適用のポイント

適切な開発手法の選択-開発対象の特徴や開発組織の置かれた環境などを加味しながら適切な開発手法を選択する

プラクティスの活用-それぞれのプロジェクト・組織(企業)で、自らの開発に合った方法を、プラクティスを選択あるいは参考にして利用する

開発手法に対する正しい理解の促進-プラクティスの意図やプラクティスが提唱されている背景についても理解を深める




アジャイル手法の導入・普及に向けて

外注における課題- 契約問題

アジャイル手法の理解促進- ユーザ部門と開発部門- 発注顧客と開発受託会社- 経営層、マネージメント層、開発担当など- 組織の風土

管理手法や技術面での環境整備- 品質評価、進捗管理、プロセス定義、定量化技術- 社内標準、社内検査- 開発ツールなど開発環境の整備




外注における課題

✓ 外注の場合に現在最も一般的に使われている請負契約は、

「当事者の一方が、ある仕事を完成することを約し、相手方

がその仕事の結果に対して報酬を支払うことを約することに

よって、効力を生じる」契約

✓ 一方、アジャイル手法は、変化への対応を重視するため

仕様を最初に固定しない。

ユーザとのコミュニケーションによって、状況に応じて仕様を決めていく

✓ 契約時点で、成果物が不明確なため、「仕事の完成」が客観的に判断できない。このため、請負契約はなじまない




契約上の課題

要件が未確定であること

成果物が不明確であること

性能と品質等が不明確であること

工期が不明確であること

開発工数の見積もりが困難であること

ユーザ/ベンダ間の責任分担が不明確であること

契約形態における指示系統との兼ね合いでコミュニケーションに制約が生じること




アジャイル手法の理解促進(１)

◆ ユーザ部門と開発部門◆ 発注顧客と開発受託会社◆ 経営層、マネージメント層、開発担当など◆ 組織の風土

✓ アジャイル手法は、ユーザ・顧客との協調に価値を置くプロセスであるため、顧客の参画が必須

✓ 顧客マネージメント層の理解と必要なリソースの割当など具体的な行動が成功のための条件




アジャイル手法の理解促進(２)

◆ 顧客が参画すべき作業の例

✓ 繰返し毎のリリース計画の作成要件の優先

順位の決定

✓ リリース毎の受け入れ検収の実施

✓ 計画ゲーム・振り返りへの参加

✓ 定期進捗報告への参加

✓ 問題に対する迅速な判断・決定など




管理手法や技術面での環境整備

◆ 品質評価、進捗管理、プロセス定義、定量化技術

◆ 社内標準、社内検査

◆ 開発ツールなど開発環境の整備

✓ 設計、品質、検証などに不安があり、重要なシステムへの適用には疑問が残る

✓ これまでのアジャイル手法はプラクティスの集まり、今後はエンジニアリングまで高める必要がある




①顧客・経営層へのアピール

②契約の形態(非ウォーターフォール型開発に適した契約モデル)

③非ウォーターフォール型開発に必要な技術の明確化

④普及・展開施策

(1)プロセス・モデル作成非WF型開発の典型的プロセスのモデル化

(2) マネジメント手法の検討適切な開発形態の選択、見積り、品質評価、進捗管理、及びこれらの可視化、等の手法の検討

(3) 契約モデルの検討（日本における）非WF型開発に適した契約モデルの検討

(4) エンジニアリング手法と人材育成方法の検討必要な技術・スキルの明確化とその獲得方法（人材育成方法）の検討

今年度中に一定の成果とりまとめを目指す

今年度の活動




(1)プロセス・モデル作成

従来のウォーターフォール型開発とアジャイル開発の間に様々な手法が並び、それぞれ数々の工夫がなされ、適用されている。

これらの非ウォーターフォール型開発における典型的なプロセスを、22事例の調査結果に基づいてモデル化し、技術・スキル、契約問題の検討のベースとする。




(参考)アジャイル型開発モデル

ソフトウェア

実装

運用

要求仕様

エンドユーザ（業務）

要求

時間

分析設計実装テスト

要求

時間

（平鍋健児氏講演資料より）ウォーターフォール型アジャイル型

企画/要件定義




事例からのプロセス・モデル(1)

モデル2(しっかり設計する派生モデル)

モデル1(基本のモデル)

企画

システム運用

• n=1のケースもあり。• 全体の基盤設計・開発を第一反復／リリースとして行う場合もあり。

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

企画

システム運用

第１反復

テスト

開発

要求

第ｎ反復

テスト

開発

要求・・・

第1リリース

・・・

第１反復

テスト

開発

要求

第ｎ反復

テスト

開発

要求・・・

第2リリース

・・・

第１反復

テスト

開発

要求

第ｎ反復

テスト

開発

要求・・・

第mリリース

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

第１反復

テスト

開発

要求

第ｎ反復

テスト

開発

要求・・・

第1リリース

・・・

第１反復

テスト

開発

要求

第ｎ反復

テスト

開発

要求・・・

第mリース

(参考)




システム運用

事例からのプロセス・モデル(2)

モデル3(しっかりテストする派生モデル)

• イテレーションごとには結合テストなどを実施せず、リリース前に1度のみ実施• リリースは複数回繰り返される

企画リリース前テスト

・・・

第１反復

テスト

開発

要求

第ｎ反復

テスト

開発

要求・・・

第1リリース

リリース前テスト

第１反復

テスト

開発

要求

第ｎ反復

テスト

開発

要求・・・

第mリリース

(参考)




◆顧客・経営層へのアピールのために必要な管理手法等

適切な開発形態の選択、見積り、品質評価、進捗管理、顧客側と開発側のロール（役割）の明確化、及びこれらの顧客・経営層への可視化、等の手法の検討

例えば以下のような項目を視野に入れて検討する。

①見積り

②統合管理

③スコープ管理

④スケジュール管理

⑤コスト管理

(2)マネジメント手法の検討

⑥品質管理

⑦組織・要員管理

⑧コミュニケーション管理

⑨リスク管理

⑩開発体制

・ロール（役割）の明確化




(3)契約モデルの検討(1/3)

契約モデルの検討（日本における）非ウォーターフォール型

開発に適した契約モデルの検討

・非ウォーターフォール型開発に適した契約モデル・非ウォーターフォール型開発に適した契約のひな型




<参考：ウォーターフォール型開発における契約モデル（経済産業省）>

[準委任型][請負型]

[準委任型][請負型]

■ 開発手法は、ウォーターフォール型モデルを前提

■ ウォーターフォール型モデル以外の多様な開発モデルに基いた契約のあり方については、今後の検討課題

システム化の方向性

システム化の計画

要件定義システム設計ソフトウェア設計プログラミング

ソフトウェアテスト

システムテスト

運用テスト

企画支援業務要件定義

作成支援業務

外部設計書作成業務

[準委任型] [準委任型][請負型]

ソフトウェア開発業務システムテスト業務

運用準備移行支援

[準委任型]

契約契約契約契約契約契約

（METI 第1版 2007.4）Copyright © 2010 ＩＰＡ, All Rights Reserved




<検討：非ウォーターフォール型開発に適した契約モデル>

発注者

元請け

下請け

契約ａ

契約ｂ

契約ｃ？

プレイヤーの基本モデルプロセス・モデル

作成したモデル

非ウォーターフォール型開発向け契約モデル

開発プロセスのどの区間において、各プレイヤー間では、どういった形態の契約が適切か？





◆必要な技術・スキルの明確化

アジャイル型開発における例

・開発技術：オブジェクト指向の設計原則、

テスト駆動、リファクタリング、等●開発技術プラクティス例

① 反復＆イテレーション

② テスト駆動型開発（TDD）

③ ペアプログラミング

④ リファクタリング

⑤ ソースコードの共同所有

⑥ 継続した結合

⑦ YAGNI（いま必要なことだけを行なう）

⑧ ストーリーの作成

⑨ 自動化された回帰テスト

⑩ コーディング規約

⑪ 単体テストの自動化

⑫ 受け入れテスト

(4)必要な技術・スキルと人材育成方法の検討(1/3)


プラクティスの集まりからエンジニアリングまで高めることを目指す



◆必要な技術・スキルの明確化アジャイル型開発における例・プロジェクト運営（ファシリテーション）技術：チーム運営，反復型計画，等

●プロジェクト運営技術プラクティス例

① 見積り（全体・イテレーション別）

② 統合管理

③ スコープ管理

④ スケジュール管理

・リリース

・マイルストーン

・スプリント

・デイリースクラム

⑤リリース計画

⑥コスト管理

⑦品質管理

・テスト

・レビュー

・リファクタリング

・頻繁なリリース

・受け入れテスト

⑧組織・要員管理

⑨コミュニケーション管理

⑩リスク管理

⑪外注管理





①人材像

②スキル体系

・セル生産方式に対応できるオールラウンドプレイヤー

・ ITSSとの比較

・開発プロセス別の技術・スキル

ロードマップ

カリキュラム

③人材育成方法



◆必要な技術・スキルの獲得方法の検討◆ウォーターフォール型開発に必要な技術・スキルと

非ウォーターフォール型開発に必要な技術・スキルとの対比



H22年度の活動：H21年度の調査研究に基づき抽出した課題へ対応

① 顧客・経営層へのアピール

② 契約の形態(非ウォーターフォール型開発に適した契約モデル)

③ 非ウォーターフォール型開発に必要な技術の明確化

④ 普及・展開施策

H22年度末に「SECガイドブック」または、「報告書」としてとりまとめる予定




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

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


非ウォーターフォール型開発の適用事例と課題 ·...

Documents