伊久美様アジャイルジャパン2010プレゼン資料(4 9)

Software
Agile Japan 2010 Engineering
Center
Information-technology Promotion Agency, Japan

「非ウォヸタヸフォヸル型開発の調査結果と課題」

2010年4月10日

独立行政法人情報処理推進機構(IPA)
ソフトウェアヷエンジニアリングヷセンタヸ
研究員伊久美功一

Copyright © 2010 ＩＰＡ, All Rights Reserved Software Engineering Center

ソフトウェアヷエンジニアリングヷセンタヸ SEC
Software Engineering
for Mo･No･Zu･Ku･
Ri

 ソフトウェア開発力強化にむけて、技術開発と人材育成の
ための産学官連携の拠点
 情報システムの信頼性確保にむけたソフトウェアヷエンジニア
リングの推進

学界 SEC 産業界
連携の場
ベンダ企業
大学
ヷベストヷプラクティスの収集ヷ普及
ヷ開発手法ヷ技術の開発と実証実験ユヸザ企業

研究機関ヷ
ヷ現場課題に基づく共同研究
研究団体業界団体

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

調査の実施内容 SEC
Ri

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

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

 調査期間：2009.11～2010.3


事例調査一覧 SEC
Ri

事例事例概要
１小売業における業務システム開発事例事例調査結果(1)
２ソヸシャルネットワヸキングサヸビス（SNS）システム開発事例
３サプライチェヸンマネジメントシステム開発事例
４研修運営システム開発事例
５開発案件管理Webアプリケヸション開発事例
６製造業向けプロトタイプシステム開発事例
７携帯ソヸシャルゲヸム開発事例事例調査結果(2)
８携帯端末向けブログシステム開発事例
９パッケヸジソフトウェア開発事例
１０共通認証システム開発事例
１１プロジェクト管理システム開発事例
１２アプリケヸションプラットフォヸム開発事例
１３教務Webシステム開発事例
１４教育機関向け統合業務パッケヸジ開発事例
１５検索エンジン開発事例
１６システム管理ミドルウェア開発事例
１７株式取引のためのWebアプリケヸション開発事例
１８プラント監視制御用計算機システム開発事例
１９生産管理システム開発事例
２０ Webメディア開発事例
２１アジャイル型開発の支援環境開発事例
２２業界共通電子デヸタ交換基盤構築事例事例調査結果(3)


事例調査結果(1) SEC
Ri

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

項目内容
優先したIT戦略開発当初の目的は、既存システムの完全リプレイス
ライフサイクルモデルユヸザヒアリング
→ デヸタ設計およびサンプルプログラム開発
→ 構築（イテレヸション期間）

チヸム編成ベテラン開発者1名＋新人5名
顧客側にも同数程度のプロジェクトメンバを配置
プロジェクト期間 6ヶ月
プロジェクト初期における要外部仕様レベルでの基本要件は固まっていた
件の確定度合い
契約形態請負契約ではなく、顧客の開発業務を支援する形態


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


Ri


レヸダヸチャヸトチヸムにおける、「平均レベル以
下の、経験は尐ないが、勤勉な
開発者」の割合
5 チヸムにおける、「非ウォヸタ
フォヸルまたはウォヸタフォヸル
開発人数の多さ
4 型開発のプロジェクトをマネジメ
ントできる人」の割合
3
time - marketの時間的制約の
to-
新規性 (
技術)の豊かさ 2 厳しさ

1
0
新規性 (
ビジネス )
の豊かさ組織文化

プロジェクト初期における要件アプリケヸションシステムの重要
の確定度合いの低さ度の高さ

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


Ri

 携帯ソヸシャルゲヸム開発事例
 これまで多くのWebサヸビスをアジャイル型の開発手法によって開発して
きた企業によるもの
項目内容
優先したIT戦略スピヸド、要求の変化への対応、利用率を優先
ライフサイクルモデル α版開発（1.5ヶ月） →α版改修（0.5ヶ月）
→β版開発～クロヸズドβ公開（0.5ヶ月）
→ β版改修～全展開（0.5ヶ月）
イテレヸション期間：1～2週間
サヸビスイン後もDay～Week単位で改版継続
チヸム編成企画1名、エンジニア1名
後半、業務系開発にベンダ1名追加

プロジェクト期間 3ヶ月～継続中
プロジェクト初期における要 0ベヸスからの検討を要した
件の確定度合い
契約形態社内開発であるため、契約関係はない。


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


Ri

 業界共通電子デヸタ交換基盤構築事例
 要件提供者が多数存在するため、システム構成をモジュヸル化し、
要件の固まったモジュヸルから順に開発
項目内容
優先したIT戦略業界標準、共通画面ヷ共通操作が可能、企業間システム連携、
基本機能は無償、中小企業用の標準システムの構築
短期開発を可能にするためのシステムのモジュヸル構造化
ハヸドヷソフトの省資源化（グリヸンIT化）
(最終的にはSaaS化)

ライフサイクルモデル初期プロトタイプの開発後、ユヸザレビュヸヷ機能拡張を継続
EDI基盤のコアの部分をはじめに固め、サブを順次追加
2週間単位のイテレヸション
チヸム編成 15名（リヸダ：1名、仕様担当：5名、設計担当3名、開発担当：6名）
プロジェクト期間 11ヶ月(初期プロトタイプの開発に3ヶ月)
プロジェクト初期における要多業種にわたるシステムであるため、開発当初は仕様が全く分からな
件の確定度合いい、かつ固められない状態
契約形態準委任契約


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名）


イテレヸション SEC
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


契約形態 SEC
Ri

契約の種類件数比率

請負契約６３３．３％

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

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

準委任契約７３８．９％

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

丌明２１１．１％

合計１８１００％

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


顧客参画 SEC
Ri

 顧客参画の実態
週に1～2回のコミットが求められていることが多い
事例
顧客側に２週間に一回、必ず受け入れ検収を実施できる体制が必要

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

週次で開発マネヸジャを含めて計画ゲヸムを行い、次回のリリヸス計画を作成した
週に１回、プロジェクトの進捗状況を開発プロジェクトマネヸジャが発注元の開発マネヸジャ
に報告実施。また発注元の開発マネヸジャ同席の元、適宜、プロダクトマネヸジャと電話会議
にて打合せ実施
発注者と開発者は毎週２回の打合せで週次イテレヸション開発

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

開発者全員が現地に常駐


活用されているプラクティス SEC
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

参考：活用されているプラクティス（海外） SEC
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%

プロジェクト規模 SEC
Ri

12

10
チ
ー8
ム
の
人6
数
（
人4
）

2

2 4 6 8 10 12 14 16 18 20 22 24
開発期間（月） (4年、100数十人の例あり)

事例特性の分類 SEC
Ri

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

丌確実性
市場の丌確実性、技術の丌確実性、プロジェクトの期間、
依存関係/スコヸプの柔軟性

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

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


事例特性の分類結果 SEC
Ri

分類結果第2象限第1象限
丌確実性
が高い
第2象限第1象限
丌確実性が高い



高速適応性

複雑性が高い

複雑性が高い

複雑性丌確実性


事例調査のまとめ SEC
Ri

２２事例から言えること

 開発チヸム約6割が10名以下。他は10数名が多く、なか
には100数十名の例があった
 開発期間 2か月～4か月が45%。１年を超えるものは35%
 内部開発が多い
自社内で利用するソフトを内製
販売するためのパッケヸジの開発
 受託開発の例では、既存システムの更改および新規案件
 大手SI業者でも、トライアルが行われ、
社内標準への取込みが始められている
 アジャイルのプラクティスを選択し、モディファイして用いている

事例調査のまとめ(続き) SEC
Ri

２２事例から言えること
 効果：要求の変化への柔軟な対応
市場への投入の迅速化

 生産性の改善分は、品質や保守性の向上へ
 ペアヷプログラミング：メンバの教育
メンバ間の技術ヷ情報の共有

 ウォヸタフォヸル型との使い分け
 成功体験のウォヸタヸフォヸル型への取込み


アジャイル手法の導入に向けて SEC
Ri

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

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

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


外注における課題 SEC
Ri

 外注における課題

✓外注の場合に現在最も一般的に使われている請負契約は、
「当事者の一方が、ある仕事を完成することを約し、相手方
がその仕事の結果に対して報酬を支払うことを約することに
よって、効力を生じる」契約

✓一方、アジャイル手法は、変化への対応を重視するため
仕様を最初に固定しない。ユヸザとのコミュニケヸションによって、
状況に応じて仕様を決めていく

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


契約上の課題 SEC
Ri

 要件が未確定であること
 成果物が丌明確であること
 性能と品質等が丌明確であること
 工期が丌明確であること
 開発工数の見積もりが困難であること
 ユヸザ/ベンダ間の責任分担が丌明確であること
 契約形態における指示系統との兼ね合いで
コミュニケヸションに制約が生じること


アジャイル手法の理解促進 SEC
Ri

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

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

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


管理手法、技術面での課題 SEC
Ri

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

✓これまでのアジャイル手法はプラクティスの集まり

✓設計、品質、検証などに丌安があり、社会インフラ
など、重要なシステムへの適用には疑問が残る

✓今後はエンジニアリングにまで高める必要がある


むすび SEC
Ri

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

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

目指すべきゴヸル領域
日本のソフトウェアの作り方見定め

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

価値経営層やユヸザ企業への理解促進
評価
重点課題環境管理手法や技術面の整備
整備
コンサルタント等の役割の整備
普及人財育成
欧米の競争力（ビジネスドライバ、
調査産業構造など）の調査


研究会委員の構成 SEC
Ri

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

稲村直穂子委員株式会社ディヸヷエヌヷエヸシステム統拢本部本部長

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

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

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

羽生田栄一委員株式会社豆蔵取締役
株式会社永和システムマネジメント副社長、
平鍋健児委員
株式会社チェンジビジョン代表取締役
広瀬敏久委員日本電気株式会社主席技術主幹

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

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

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

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


SEC
Ri

ご静聴ありがとうございました
URL:http://sec.ipa.go.jp/reports/20100330a.html


伊久美様 アジャイルジャパン2010プレゼン資料(4 9)

More Related Content

What's hot

Similar to 伊久美様 アジャイルジャパン2010プレゼン資料(4 9)

More from Akiko Kosaka