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