「非ウォーターフォール型開発の現状と課題」 ·...

Information-technology Promotion Agency, Japan

SoftwareEngineeringCenter

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

「非ウォーターフォール型開発の現状と課題」

2010年5月12日

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

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

SECSoftware Engineeringfor Mo･No･Zu･Ku･Ri

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

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

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

実施内容：17社、22事例を対象に開発対象の特性および開発方法、適用プラクティス、契約形態、等について事例調査を行った

調査期間：2009.11～2010.3



事例調査一覧

事例事例概要

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

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

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

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

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

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

７携帯ソーシャルゲーム開発事例事例調査結果(2)８携帯端末向けブログシステム開発事例

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

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

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

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

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

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

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

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

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

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

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

２０ Webメディア開発事例

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

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



事例調査結果(1)

小売業における業務システム開発事例小売業を営む顧客のマーチャンダイジングシステム開発を出発点に、これまでに260メニュー、80万ステップの開発

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

外部仕様レベルでの基本要件は固まっていた要求の確認は、ユーザとの会話と実際に動作するプログラムで行う

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

6ヶ月プロジェクト期間

ベテラン開発者1名＋新人5名顧客側にも同数程度のプロジェクトメンバを配置

チーム編成

ユーザヒアリング→ データ設計およびサンプルプログラム開発→ 構築（イテレーション期間）

ライフサイクルモデル

開発当初の目的は、既存システムの完全リプレイス優先したIT戦略

内容項目



26人開発人数の多さ

3.75独自の開発手法にこだわった開発であるが、その基礎となっている技術は非常に一般的

採用技術の新規性の豊かさ

1.25特に新規性はないビジネスの新規性の豊かさ

2.5外部仕様レベルでの基本要件が固まっていた要求の確認は、ユーザとの会話と実際に動作するプログラムで行う

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

26ヶ月プロジェクト期間の短さ

4店舗営業時間中（6時～22時）は常時稼働要求された稼働率の高さ

2システムの不具合が顧客のお客様へも及ぶ可能性システムの重要度の高さ

5自由、闊達な風土組織文化

51週間で開発し、1週間で手直ししてリリースTime-to-marketの時間的制約の厳しさ

220%チームにおける「プロジェクトをマネジメントできる人」の割合

580%チームにおける「平均レベル以下の、経験は少ないが勤勉な開発者」の割合

度数実績値軸


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



レーダーチャート


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

0

1

2

3

4

5

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

下の、経験は少ないが、勤勉な開発者」の割合

チームにおける、「非ウォータフォールまたはウォータフォール型開発のプロジェクトをマネジメ

ントできる人」の割合

time-to-marketの時間的制約の

厳しさ

組織文化

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

度の高さ

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

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

の確定度合いの低さ

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

新規性(技術)の豊かさ

開発人数の多さ




携帯ソーシャルゲーム開発事例これまで多くのWebサービスをアジャイル型の開発手法によって開発して

きた企業によるもの

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

0ベースからの検討を要したプロジェクト初期における要件の確定度合い

3ヶ月～継続中プロジェクト期間

企画1名、エンジニア1名後半、業務系開発にベンダ1名追加

チーム編成

α版開発（1.5ヶ月） →α版改修（0.5ヶ月）→β版開発～クローズドβ公開（0.5ヶ月）→ β版改修～全展開（0.5ヶ月）イテレーション期間：1～2週間サービスイン後もDay～Week単位で改版継続


スピード、要求の変化への対応、利用率を優先優先したIT戦略

内容項目



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

要件の確定度合いの低さ

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

重要度の高さ

Time-to-marketの時間的制約

の厳しさ新規性

(ビジネス)の豊かさ

新規性(技術)の豊かさ

プロジェクト期間の短さ

要求された稼働率の高さ


12人開発人数の多さ

1.25

Flash生成エンジンの一部以外既存


2.5社内では新規ビジネスの新規性の豊かさ

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

33ヶ月～継続中プロジェクト期間の短さ

599.50%要求された稼働率の高さ

22システムの重要度の高さ

5100%組織文化

5随時Time-to-marketの時間的制約の厳しさ

5

100%ただし、多くの手法をマスターしたエンジニアではない

チームにおける「プロジェクトをマネジメントできる人」の割合

10%チームにおける「平均レベル以下の、経験は少ないが勤勉な開発者」の割合

度数実績値軸

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



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

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

準委任契約契約形態

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

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

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

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

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


業界標準、共通画面・共通操作が可能、企業間システム連携、中小企業用の標準システムの構築短期開発を可能にするためのシステムのモジュール構造化

優先したIT戦略

内容項目




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

115名（リーダ：1名、仕様担当：5名、設計担当3名、開発担当：6名）

開発人数の多さ

1.25

アジャイル型の開発は初めての経験であった。


5全く新規の取組みビジネスの新規性の豊かさ

5開発当初は仕様が全く分からない、かつ固められない状態であった。

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

111ヶ月（システム全体での開発期間）プロジェクト期間の短さ

51日最大24回の納入に対応要求された稼働率の高さ

2.5不具合の影響が複数社に及ぶシステムの重要度の高さ

0不明組織文化

15ヵ月Time-to-marketの時間的制約の厳しさ

10%（アジャイル経験者はナシ）チームにおける「プロジェクトをマネジメントできる人」の割合

5100%（アジャイル経験者はナシ）

チームにおける「平均レベル以下の、経験は少ないが勤勉な開発者」の割合

度数実績値軸


0

1

2

3

4

5

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

ベル以下の、経験は少な

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

チームにおける、「非

ウォータフォールまたは

ウォータフォール型開発のプロジェクトをマネジメン…

time -to-marketの時間的

制約の厳しさ

組織文化

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

の重要度

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

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

要件の確定度合い

新規性(ビジネス )

新規性 (技術)

開発人数



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

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

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

複雑性チームの大きさ、ミッションクリティカル性、チームの場所、

チームの能力、ドメイン知識のギャップ、依存関係

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

事例特性の分類



高速適応性

不確実性複雑性

分類結果第1象限第2象限

第4象限第3象限



不確実性が高い

複雑性が高い

複雑性が高い

不確実性が高い

事例特性の分類結果



イテレーション

全ての事例で

イテレーションを実施

最短：1W

中央値：2W

平均：2.4W

最長：8W

419不明18

120

416217

181-271-462544232211

81019

212111

不明14不明13

222421

1-215

イテレーション期間[週間]事例



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

ソフトウェア

実装企画/要件定義

運用

要求仕様

エンドユーザ（業務）

要求

時間

分析設計実装テスト

要求

時間

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



ー

１００％

１１．１％

５．６％

３８．９％

５．６％

５．６％

３３．３％

比率

１８合計

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

２不明

１請負契約＋準委任契約

１請負契約（月毎）

契約の種類件数

請負契約６

準委任契約７

労働者派遣契約１

契約形態



(参考)契約の種類

契約の種類内容

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

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

労働者派遣契約

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



顧客参画の実態

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

事例

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

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

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

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

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

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

開発者全員が現地に常駐

顧客参画



件数

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

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



(参考)アジャイル型開発手法の例

・スクラム

・エクストリーム・プログラミング(XP)

・クリスタルクリア

・フィーチャー駆動開発（FDD）

・適応型開発プロセス

・変化への迅速な対応・反復（Iteration)と漸進(Incremental)

✓ 反復型計画✓ リリース計画✓ デイリースタンダップ✓ 継続インテグレーション✓ 共通の部屋✓ テスト駆動型開発✓ バーンダウンチャート✓ ペアプログラミング✓ ・・・✓ ・・・・・・・

アジャイル型手法プラクティス



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）

アナログ・タスクボード

ペアプログラミング

オンサイト顧客

デジタル・タスクボード

コード・オーナーシップ

タスクボードの組合せ

オープンスペース

テスト駆動型開発

スピード

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

リファクタリング

バーンダウンチャート

自動ビルド

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

リリース計画

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

反復型計画

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



チームの人数（人）

2

4

6

8

10

12

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

プロジェクト規模

開発期間（月） (4年、100数十人の例あり)



事例調査のまとめ(１)

開発チーム約8割が10名以下。他は10数名が多い

開発期間 2か月～4か月が45%。１年を超えるものは35%

内部開発が多い自社内で利用するソフトを内製

販売するためのパッケージの開発

受託開発の例では、既存システムの更改および新規案件がある

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

アジャイルのプラクティスを選択し、モディファイして用いている

２２事例から言えること



事例調査のまとめ(２)

変化への対応、市場への迅速な投入の効果市場の声を聞きながら改善

要件の確定度合いが低い

要件が変化する

生産性の改善分は、品質や保守性の向上へ

従来型開発(ウォーターフォール型)との使い分け

大規模なシステムへの適用は見当たらない



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

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

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

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



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

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

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

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



外注における課題

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

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

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

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

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

仕様を最初に固定しない。ユーザとのコミュニケーションによって、

状況に応じて仕様を決めていく

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



契約上の課題

要件が未確定であること

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

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

工期が不明確であること

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

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

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

契約のあり方、調達等について検討が必要



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

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

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

✓ 経営層、マネージメント層へアジャイル手法を理解し適用していくよう促進していくことが必要



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

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

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

順位の決定

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

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

✓ 定期進捗報告への参加

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



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

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

◆ 社内標準、社内検査

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

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

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



むすび

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

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

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

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

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

普及

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

調査

重点課題

目指すべきゴール

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

領域見定め

非ウォーターフォール型開発における課題と目指すべきゴール案



研究会委員の構成

新日鉄ソリューションズ株式会社技術本部システム研究開発センター所長委員南悦郎

武蔵大学経済学部教授委員松島桂樹

株式会社日立製作所ソフトウェア事業部企画本部統括部長委員馬嶋宏

サイバー大学 IT総合学部教授委員前川徹

日本電気株式会社主席技術主幹委員広瀬敏久

株式会社永和システムマネジメント副社長、株式会社チェンジビジョン代表取締役

委員平鍋健児

株式会社豆蔵取締役委員羽生田栄一

楽天株式会社開発部開発生産性強化グループグループマネージャー委員田澤久

富士通株式会社システム生産技術本部長代理委員合田治彦

株式会社一副社長委員大槻繁

株式会社ディー・エヌ・エーシステム統括本部本部長委員稲村直穂子

財団法人・京都高度技術研究所顧問座長松本吉弘

所属氏名



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

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

「非ウォーターフォール型開発の現状と課題」 ·...

Documents