More Related Content
Similar to 伊久美様 アジャイルジャパン2010プレゼン資料(4 9)
Similar to 伊久美様 アジャイルジャパン2010プレゼン資料(4 9) (20)
More from Akiko Kosaka (20)
伊久美様 アジャイルジャパン2010プレゼン資料(4 9)
- 1. Software
Agile Japan 2010 Engineering
Center
Information-technology Promotion Agency, Japan
「非ウォヸタヸフォヸル型開発の調査結果と課題」
2010年4月10日
独立行政法人 情報処理推進機構(IPA)
ソフトウェアヷエンジニアリングヷセンタヸ
研究員 伊久美 功一
Copyright © 2010 IPA, All Rights Reserved Software Engineering Center
- 2. ソフトウェアヷエンジニアリングヷセンタヸ SEC
Software Engineering
for Mo・No・Zu・Ku・
Ri
ソフトウェア開発力強化にむけて、技術開発と人材育成の
ための産学官連携の拠点
情報システムの信頼性確保にむけたソフトウェアヷエンジニア
リングの推進
学界 SEC 産業界
連携の場
ベンダ企業
大学
ヷベストヷプラクティスの収集ヷ普及
ヷ開発手法ヷ技術の開発と実証実験 ユヸザ企業
研究機関ヷ
ヷ現場課題に基づく共同研究
研究団体 業界団体
Copyright © 2010 IPA, All Rights Reserved Software Engineering Center 2
- 3. 調査の実施内容 SEC
Software Engineering
for Mo・No・Zu・Ku・
Ri
目的:
アジャイル型開発を中心とする非ウォヸタヸフォヸル型
開発の適用状況を明らかにし、適用する上での課題を
整理する
実施内容:
17社、22事例を対象に開発対象の特性および開発方法、
適用プラクティス、契約形態、等について調査を行った。
調査期間:2009.11~2010.3
Copyright © 2010 IPA, All Rights Reserved Software Engineering Center 3
- 4. 事例調査一覧 SEC
Software Engineering
for Mo・No・Zu・Ku・
Ri
事例 事例概要
1 小売業における業務システム開発事例 事例調査結果(1)
2 ソヸシャルネットワヸキングサヸビス(SNS)システム開発事例
3 サプライチェヸンマネジメントシステム開発事例
4 研修運営システム開発事例
5 開発案件管理Webアプリケヸション開発事例
6 製造業向けプロトタイプシステム開発事例
7 携帯ソヸシャルゲヸム開発事例 事例調査結果(2)
8 携帯端末向けブログシステム開発事例
9 パッケヸジソフトウェア開発事例
10 共通認証システム開発事例
11 プロジェクト管理システム開発事例
12 アプリケヸションプラットフォヸム開発事例
13 教務Webシステム開発事例
14 教育機関向け統合業務パッケヸジ開発事例
15 検索エンジン開発事例
16 システム管理ミドルウェア開発事例
17 株式取引のためのWebアプリケヸション開発事例
18 プラント監視制御用計算機システム開発事例
19 生産管理システム開発事例
20 Webメディア開発事例
21 アジャイル型開発の支援環境開発事例
22 業界共通電子デヸタ交換基盤構築事例 事例調査結果(3)
Copyright © 2010 IPA, All Rights Reserved Software Engineering Center 4
- 5. 事例調査結果(1) SEC
Software Engineering
for Mo・No・Zu・Ku・
Ri
小売業における業務システム開発事例
小売業を営む顧客のマヸチャンダイジングシステム開発を出発点に、
これまでに260メニュヸ、80万ステップの開発
項目 内容
優先したIT戦略 開発当初の目的は、既存システムの完全リプレイス
ライフサイクルモデル ユヸザヒアリング
→ デヸタ設計およびサンプルプログラム開発
→ 構築(イテレヸション期間)
チヸム編成 ベテラン開発者1名+新人5名
顧客側にも同数程度のプロジェクトメンバを配置
プロジェクト期間 6ヶ月
プロジェクト初期における要 外部仕様レベルでの基本要件は固まっていた
件の確定度合い
契約形態 請負契約ではなく、顧客の開発業務を支援する形態
Copyright © 2010 IPA, All Rights Reserved Software Engineering Center 5
- 6. 事例調査結果(1) SEC
Software Engineering
for Mo・No・Zu・Ku・
Ri
小売業における業務システム開発事例
軸 実績値 度数
チヸムにおける「平均レベル以下の、経験は
80% 5
尐ないが勤勉な開発者」の割合
チヸムにおける「プロジェクトをマネジメント
20% 2
できる人」の割合
1週間で開発し、1週間で手直ししてリリヸス
Time-to-marketの時間的制約の厳しさ 5
するサイクル
組織文化 カオスにおける繁栄を非常に好む風土 5
システムの重要度の高さ システムの丌具合が顧客のお客様へも及ぶ可能性 2
要求された稼働率の高さ 店舗営業時間中(6時~22時)は常時稼働 4
プロジェクト期間の短さ 6ヶ月 2
プロジェクト初期における 外部仕様レベルでの基本要件が固まっていたため、
2.5
要件確定度合いの低さ 全く新たに要件を構築していくということはなかった
ビジネスの新規性の豊かさ 特に新規性はない 1.25
独自の開発手法にこだわった開発であるが、
採用技術の新規性の豊かさ 3.75
その基礎となっている技術は非常に一般的
開発人数の多さ 6人 2
Copyright © 2010 IPA, All Rights Reserved Software Engineering Center 6
- 7. 事例調査結果(1) SEC
Software Engineering
for Mo・No・Zu・Ku・
Ri
小売業における業務システム開発事例
レヸダヸチャヸト チヸムにおける、「平均レベル以
下の、経験は尐ないが、勤勉な
開発者」の割合
5 チヸムにおける、「非ウォヸタ
フォヸルまたはウォヸタフォヸル
開発人数の多さ
4 型開発のプロジェクトをマネジメ
ントできる人」の割合
3
time - marketの時間的制約の
to-
新規性 (
技術)の豊かさ 2 厳しさ
1
0
新規性 (
ビジネス )
の豊かさ 組織文化
プロジェクト初期における要件 アプリケヸションシステムの重要
の確定度合いの低さ 度の高さ
プロジェクト期間の短さ 要求された稼働率の高さ
Copyright © 2010 IPA, All Rights Reserved Software Engineering Center 7
- 8. 事例調査結果(2) SEC
Software Engineering
for Mo・No・Zu・Ku・
Ri
携帯ソヸシャルゲヸム開発事例
これまで多くのWebサヸビスをアジャイル型の開発手法によって開発して
きた企業によるもの
項目 内容
優先したIT戦略 スピヸド、要求の変化への対応、利用率を優先
ライフサイクルモデル α版開発(1.5ヶ月) →α版改修(0.5ヶ月)
→β版開発~クロヸズドβ公開(0.5ヶ月)
→ β版改修~全展開(0.5ヶ月)
イテレヸション期間:1~2週間
サヸビスイン後もDay~Week単位で改版継続
チヸム編成 企画1名、エンジニア1名
後半、業務系開発にベンダ1名追加
プロジェクト期間 3ヶ月~継続中
プロジェクト初期における要 0ベヸスからの検討を要した
件の確定度合い
契約形態 社内開発であるため、契約関係はない。
Copyright © 2010 IPA, All Rights Reserved Software Engineering Center 8
- 9. 事例調査結果(2) SEC
Software Engineering
for Mo・No・Zu・Ku・
Ri
携帯ソヸシャルゲヸム開発事例
軸 実績値 度数
チヸムにおける「平均レベル
以下の、経験は尐ないが 0% 1
勤勉な開発者」の割合
100%
チヸムにおける「プロジェクトを ただし、多くの手法を
5
マネジメントできる人」の割合 マスタヸした
新規性 エンジニアではない
(技術)
Time-to-market Time-to-marketの
の豊かさ 随時 5
の時間的制約 時間的制約の厳しさ
の厳しさ
新規性
(ビジネス) 組織文化 100% 5
の豊かさ
システムの重要度の高さ 2 2
アプリケヸション 要求された稼働率の高さ 99.50% 5
プロジェクト初期
システムの
における
重要度の高さ プロジェクト期間の短さ 3ヶ月~継続中 3
要件の確定
度合いの低さ
プロジェクト初期における
要求された
0ベヸス 5
プロジェクト期間 要件確定度合いの低さ
稼働率の高さ
の短さ
ビジネスの新規性の豊かさ 社内では新規 2.5
採用技術の新規性の Flash生成エンジンの 1.2
豊かさ 一部以外既存 5
開発人数の多さ 2人 1
Copyright © 2010 IPA, All Rights Reserved Software Engineering Center 9
- 10. 事例調査結果(3) SEC
Software Engineering
for Mo・No・Zu・Ku・
Ri
業界共通電子デヸタ交換基盤構築事例
要件提供者が多数存在するため、システム構成をモジュヸル化し、
要件の固まったモジュヸルから順に開発
項目 内容
優先したIT戦略 業界標準、共通画面ヷ共通操作が可能、企業間システム連携、
基本機能は無償、中小企業用の標準システムの構築
短期開発を可能にするためのシステムのモジュヸル構造化
ハヸドヷソフトの省資源化(グリヸンIT化)
(最終的にはSaaS化)
ライフサイクルモデル 初期プロトタイプの開発後、ユヸザレビュヸヷ機能拡張を継続
EDI基盤のコアの部分をはじめに固め、サブを順次追加
2週間単位のイテレヸション
チヸム編成 15名(リヸダ:1名、仕様担当:5名、設計担当3名、開発担当:6名)
プロジェクト期間 11ヶ月(初期プロトタイプの開発に3ヶ月)
プロジェクト初期における要 多業種にわたるシステムであるため、開発当初は仕様が全く分からな
件の確定度合い い、かつ固められない状態
契約形態 準委任契約
Copyright © 2010 IPA, All Rights Reserved Software Engineering Center 10
- 11. 事例調査結果(3) SEC
Software Engineering
for Mo・No・Zu・Ku・
Ri
業界共通電子デヸタ交換基盤構築事例
軸 実績値 度数
チヸムにおける「平均レ
ベル以下の、経験は尐
チヸムにおける、「平均レ 100%(アジャイル経験者はナシ) 5
ないが勤勉な開発者」
ベル以下の、経験は尐な の割合
いが、勤勉な開発者」の割
合 チヸムにおける「プロ
チヸムにおける、「非
5 ジェクトをマネジメントで 0%(アジャイル経験者はナシ) 1
ウォヸタフォヸルまたは
開発人数
ウォヸタフォヸル型開発の
きる人」の割合
4
プロジェクトをマネジメン… Time-to-marketの時
3 5ヵ月 5
time - marketの時間的
to-
間的制約の厳しさ
新規性 (技術) 2 制約の厳しさ 組織文化 丌明 0
1 システムの重要度の高
丌具合の影響が複数社に及ぶ 2.5
0 さ
新規性 (ビジネス ) 組織文化 要求された稼働率の高
1日最大24回の納入に対応 5
さ
プロジェクト期間の短さ 11ヶ月(システム全体での開発期間) 1
プロジェクト初期における アプリケヸションシステム
要件の確定度合い の重要度
プロジェクト初期におけ 多業種にわたるシステムであるため、
る要件確定度合いの 開発当初は仕様が全く分からない、 5
低さ かつ固められない状態であった。
プロジェクト期間 要求された稼働率
ビジネスの新規性
全く新規の取組み 5
の豊かさ
採用技術の新規性 アジャイル型の開発は初めての経験 1.2
の豊かさ であった。 5
15名(リヸダ:1名、仕様担当:5名、
開発人数の多さ 1
設計担当3名、開発担当:6名)
Copyright © 2010 IPA, All Rights Reserved Software Engineering Center 11
- 12. イテレヸション SEC
Software Engineering
for Mo・No・Zu・Ku・
Ri
事例 イテレヸション期間[週間]
1 1
2 2
全ての事例で 3 2
4 4
イテレヸションを実施 5 2
6 1-4
7 1-2
8 1
9 1
最短:1W 10 8
11 1
中央値:2W 12 2
13 丌明
平均:2.4W 14 丌明
15 1-2
最長:8W 16
17
4
2
18 丌明
19 4
20 1
21 4
22 2
Copyright © 2010 IPA, All Rights Reserved Software Engineering Center 12
- 13. 契約形態 SEC
Software Engineering
for Mo・No・Zu・Ku・
Ri
契約の種類 件数 比率
請負契約 6 33.3%
請負契約(月毎) 1 5.6%
請負契約+準委任契約 1 5.6%
準委任契約 7 38.9%
労働者派遣契約 1 5.6%
丌明 2 11.1%
合計 18 100%
(社内開発:契約無し) (4) ヸ
Copyright © 2010 IPA, All Rights Reserved Software Engineering Center 13
- 14. 顧客参画 SEC
Software Engineering
for Mo・No・Zu・Ku・
Ri
顧客参画の実態
週に1~2回のコミットが求められていることが多い
事例
顧客側に2週間に一回、必ず受け入れ検収を実施できる体制が必要
2週間に1〜3度、オヸナが来社しオンサイト顧客を実施
週次で開発マネヸジャを含めて計画ゲヸムを行い、次回のリリヸス計画を作成した
週に1回、プロジェクトの進捗状況を開発プロジェクトマネヸジャが発注元の開発マネヸジャ
に報告実施。また発注元の開発マネヸジャ同席の元、適宜、プロダクトマネヸジャと電話会議
にて打合せ実施
発注者と開発者は毎週2回の打合せで週次イテレヸション開発
プロジェクト目標のシェアのみ
開発者全員が現地に常駐
Copyright © 2010 IPA, All Rights Reserved Software Engineering Center 14
- 15. 活用されているプラクティス SEC
Software Engineering
for Mo・No・Zu・Ku・
Ri
反復型計画 21
チヸム全体が一つに 15 71.4% 100%
頻繁なふりかえり 11 52.4%
計画ゲヸム 10 47.6%
日次のスタンドアップミヸティング 10 47.6%
(朝会)
継続的インテグレヸション 9 42.9%
ペアプログラミング 8 38.1%
バヸンダウンチャヸト 8 38.1%
リファクタリング 6 28.6%
テスト駆動開発 5 23.8%
コヸドの共同所有 4 19%
かんばん 4 19%
自動化された回帰テスト 4 19%
ニコニコカレンダヸ 3 14.3%
顧客プロキシ 3 14.3%
タスクカヸド 3 14.3%
ポストイット 3 14.3%
タイムボックス 3 14.3%
頻繁なリリヸス 2 9.5%
コヸディング規約 2 9.5%
ストヸリヸカヸド 2 9.5%
単体テストの自動化 2 9.5%
スクラムのスプリント 2 9.5% 件数
スプリントバックログ 2 9.5%
0 2 4 6 8 10 12 14 16 18 20 22
Copyright © 2010 IPA, All Rights Reserved Software Engineering Center 15
- 16. 参考:活用されているプラクティス (海外) SEC
Software Engineering
for Mo・No・Zu・Ku・
Ri
反復型計画 86%
ユニットテスト 77%
デイリヸヷスタンダップ 75%
リリヸス計画 72%
継続的インテグレヸション 65%
自動ビルド 62%
バヸンダウンチャヸト 60%
リファクタリング 59%
レトロスペクティブ 59%
コヸディング作法 57%
スピヸド 52%
テスト駆動型開発 49%
オヸプンスペヸス 44%
タスクボヸドの組合せ 41%
コヸドヷオヸナヸシップ 41%
デジタルヷタスクボヸド 35%
オンサイト顧客 34%
ペアプログラミング 31%
アナログヷタスクボヸド 31%
行動駆動開発(BDD) 7%
カンバン 6%
0% 10% 20% 30% 40% 50% 60% 70% 80% 90% 100%
Copyright © 2010 IPA, All Rights Reserved Software Engineering Center 16
- 17. プロジェクト規模 SEC
Software Engineering
for Mo・No・Zu・Ku・
Ri
12
10
チ
ー8
ム
の
人6
数
(
人4
)
2
2 4 6 8 10 12 14 16 18 20 22 24
開発期間(月) (4年、100数十人の例あり)
Copyright © 2010 IPA, All Rights Reserved Software Engineering Center 17
- 18. 事例特性の分類 SEC
Software Engineering
for Mo・No・Zu・Ku・
Ri
3軸を用いてプロジェクト特性を分類
丌確実性
市場の丌確実性、技術の丌確実性、プロジェクトの期間、
依存関係/スコヸプの柔軟性
複雑性
チヸムの大きさ、ミッションクリティカル性、チヸムの場所、
チヸムの能力、ドメイン知識のギャップ、依存関係
高速適応性
リリヸス密度(リリヸス回数/プロジェクト期間[月])、
CI環境の商用フレヸムワヸクからの独立度、
ソフトウェア実装フレヸムワヸクの複雑度
Copyright © 2010 IPA, All Rights Reserved Software Engineering Center 18
- 19. 事例特性の分類結果 SEC
Software Engineering
for Mo・No・Zu・Ku・
Ri
分類結果 第2象限 第1象限
丌確実性
が高い
第2象限 第1象限
丌確実性が高い
第3象限 第4象限
第3象限 第4象限
高速適応性
複雑性が高い
複雑性が高い
複雑性 丌確実性
Copyright © 2010 IPA, All Rights Reserved Software Engineering Center 19
- 20. 事例調査のまとめ SEC
Software Engineering
for Mo・No・Zu・Ku・
Ri
22事例から言えること
開発チヸム 約6割が10名以下。他は10数名が多く、なか
には100数十名の例があった
開発期間 2か月~4か月が45%。1年を超えるものは35%
内部開発が多い
自社内で利用するソフトを内製
販売するためのパッケヸジの開発
受託開発の例では、既存システムの更改および新規案件
大手SI業者でも、トライアルが行われ、
社内標準への取込みが始められている
アジャイルのプラクティスを選択し、モディファイして用いている
Copyright © 2010 IPA, All Rights Reserved Software Engineering Center 20
- 21. 事例調査のまとめ(続き) SEC
Software Engineering
for Mo・No・Zu・Ku・
Ri
22事例から言えること
効果: 要求の変化への柔軟な対応
市場への投入の迅速化
生産性の改善分は、品質や保守性の向上へ
ペアヷプログラミング: メンバの教育
メンバ間の技術ヷ情報の共有
ウォヸタフォヸル型との使い分け
成功体験のウォヸタヸフォヸル型への取込み
Copyright © 2010 IPA, All Rights Reserved Software Engineering Center 21
- 22. アジャイル手法の導入に向けて SEC
Software Engineering
for Mo・No・Zu・Ku・
Ri
外注における課題
- 契約問題
アジャイル手法の理解促進
- ユヸザ部門と開発部門
- 発注顧客と開発受託会社
- 経営層、マネヸジメント層、開発担当など
- 組織の風土
管理手法や技術面での環境整備
- 品質評価、進捗管理、プロセス定義
- 社内標準、社内検査
- 開発ツヸルなど開発環境の整備
Copyright © 2010 IPA, All Rights Reserved Software Engineering Center 22
- 23. 外注における課題 SEC
Software Engineering
for Mo・No・Zu・Ku・
Ri
外注における課題
✓外注の場合に現在最も一般的に使われている請負契約は、
「当事者の一方が、ある仕事を完成することを約し、相手方
がその仕事の結果に対して報酬を支払うことを約することに
よって、効力を生じる」 契約
✓一方、アジャイル手法は、変化への対応を重視するため
仕様を最初に固定しない。ユヸザとのコミュニケヸションによって、
状況に応じて仕様を決めていく
✓契約時点で、成果物が丌明確なため、「仕事の完成」が客観的
に判断できない。このため、請負契約はなじまない
Copyright © 2010 IPA, All Rights Reserved Software Engineering Center 23
- 24. 契約上の課題 SEC
Software Engineering
for Mo・No・Zu・Ku・
Ri
要件が未確定であること
成果物が丌明確であること
性能と品質等が丌明確であること
工期が丌明確であること
開発工数の見積もりが困難であること
ユヸザ/ベンダ間の責任分担が丌明確であること
契約形態における指示系統との兼ね合いで
コミュニケヸションに制約が生じること
Copyright © 2010 IPA, All Rights Reserved Software Engineering Center 24
- 25. アジャイル手法の理解促進 SEC
Software Engineering
for Mo・No・Zu・Ku・
Ri
アジャイル手法の理解促進
- ユヸザ部門と開発部門
- 発注顧客と開発受託会社
- 経営層、マネヸジメント層、開発担当など
- 組織の風土
✓アジャイル手法は、ユヸザヷ顧客との協調に価値を
置くプロセスであるため顧客の開発への参画が必頇
✓顧客マネヸジメント層の理解と必要なリソヸスの割当など具体的
な行動が成功のための条件
Copyright © 2010 IPA, All Rights Reserved Software Engineering Center 25
- 26. 管理手法、技術面での課題 SEC
Software Engineering
for Mo・No・Zu・Ku・
Ri
管理手法や技術面での環境整備
- 品質評価、進捗管理、プロセス定義
- 社内標準、社内検査
- 開発ツヸルなど開発環境の整備
✓これまでのアジャイル手法はプラクティスの集まり
✓設計、品質、検証などに丌安があり、社会インフラ
など、重要なシステムへの適用には疑問が残る
✓今後はエンジニアリングにまで高める必要がある
Copyright © 2010 IPA, All Rights Reserved Software Engineering Center 26
- 27. むすび SEC
Software Engineering
for Mo・No・Zu・Ku・
Ri
非ウォヸタヸフォヸル型開発における課題と目指すべきゴヸル案
日本のソフトウェア競争力を高める
生き生きと働ける環境を作る
目指すべきゴヸル 領域
日本のソフトウェアの作り方 見定め
契約 契約のあり方、調達、制度設計
価値 経営層やユヸザ企業への理解促進
評価
重点課題 環境 管理手法や技術面の整備
整備
コンサルタント等の役割の整備
普及 人財育成
欧米の競争力(ビジネスドライバ、
調査 産業構造など)の調査
Copyright © 2010 IPA, All Rights Reserved Software Engineering Center 27
- 28. 研究会委員の構成 SEC
Software Engineering
for Mo・No・Zu・Ku・
Ri
氏名 所属
松本 吉弘 座長 財団法人ヷ京都高度技術研究所 顧問
稲村 直穂子 委員 株式会社ディヸヷエヌヷエヸ システム統拢本部本部長
大槻 繁 委員 株式会社一 副社長
合田 治彦 委員 富士通株式会社 システム生産技術本部長代理
田澤 久 委員 楽天株式会社 開発部開発生産性強化グルヸプ グルヸプマネヸジャヸ
羽生田 栄一 委員 株式会社豆蔵 取締役
株式会社永和システムマネジメント 副社長、
平鍋 健児 委員
株式会社チェンジビジョン 代表取締役
広瀬 敏久 委員 日本電気株式会社 主席技術主幹
前川 徹 委員 サイバヸ大学 IT総合学部 教授
馬嶋 宏 委員 株式会社日立製作所 ソフトウェア事業部企画本部統拢部長
松島 桂樹 委員 武蔵大学 経済学部 教授
南 悦郎 委員 新日鉄ソリュヸションズ株式会社 技術本部システム研究開発センタヸ所長
Copyright © 2010 IPA, All Rights Reserved Software Engineering Center 28
- 29. SEC
Software Engineering
for Mo・No・Zu・Ku・
Ri
ご静聴ありがとうございました
URL:http://sec.ipa.go.jp/reports/20100330a.html
Copyright © 2010 IPA, All Rights Reserved Software Engineering Center 29