Agile Development and Contract from IPA at AgileJapan 2011

Software
Engineering
Center
Information-technology Promotion Agency, Japan

アジャイル開発の適切な運用に向けて
～「非ウォタフォル型開発WG活動報告書」の概要～
～「非ウォーターフォール型開発WG活動報告書」の概要～

Agile Japan 2011
2011年4月15日

情報処理推進機構(IPA)
ソフトウェア・エンジニアリング・センター(SEC)
山下博之

Software Engineering Center 1

H22年度版報告書の公開中
H22年度版報告書の公開中 SEC
Software Engineering
for Mo･No･Zu･Ku･Ri

http://sec.ipa.go.jp/reports/20110407.html
Copyright © 2010-2011 IPA, All Rights Reserved. Software Engineering Center 2

非ウォーターフォール型開発に関する検討委員（1/4） SEC
非ウォーターフォール型開発WG
非ウォタフォル型開発WG Agile Japan 2011
A il J
氏名所属実行委員
主査松本　吉弘財団法人京都高度技術研究所顧問
委員稲村　直穂子
稲村直穂子株式会社ディー・エヌ・エーシステム統括本部本部長
大槻　繁株式会社一コンサルティンググループ副社長
合田　治彦富士通株式会社システム生産技術本部本部長代理
田澤　久
田澤久楽天株式会社開発ユット開発環境整備課課長
開発ユニット
株式会社NTTデータ技術開発本部
戸村　元久
プロジェクトマネジメント・イノベーションセンタセンタ長
羽生田　栄一株式会社豆蔵取締役
株式会社永和システムマネジメント副社長、
ジ
平鍋　健児
株式会社チェンジビジョン代表取締役
広瀬　敏久日本電気株式会社主席技術主幹
古川
古川　正伸
伸株式会社東京証券取引所品質管理部課長
前川　徹サイバー大学 IT総合学部教授
馬嶋　宏株式会社日立製作所情報システム事業部方式設計センタ
松島　桂樹武蔵大学経済学部教授
新日鉄ソリューションズ株式会社
南　悦郎
技術本部システム研究開発センター所長
富士通株式会社システム生産技術本部
和田　憲明
SI生産革新統括部 SDEM推進部
エキスパート伊久美　功一 IPA/SEC専門委員／元IPA/SEC研究員
オブザーバ鴨田　浩明経済産業省


開発モデルPT
氏名所属
株式会社永和システムマネジメント副社長、
株式会社永和ネジ副社
リーダ平鍋　健児
株式会社チェンジビジョン代表取締役
委員合田治彦
合田　治彦富通株式会社システム生産技術本部本部長代理
富士通株式会社シテ産技術本部
株式会社NTTデータ技術開発本部
戸村　元久
プロジェクトマネジメント・イノベーションセンタセンタ長
広瀬　敏久
広瀬敏久日本電気株式会社主席技術主幹
本電気株式会社
古川　正伸株式会社東京証券取引所品質管理部課長
前川　徹
前川徹サイバー大学
サイバ大学 IT総合学部教授
松島　桂樹武蔵大学経済学部教授
新日鉄ソリュションズ株式会社
南　悦郎
南悦郎
技術本部システム研究開発センター所長
和
和田　憲明
憲明
エキスパート伊久美　功一 IPA/SEC専門委員／元IPA/SEC研究員


技術・スキルPT
氏名所属
リーダ
ダ松島　桂樹武蔵大学経済学部教授
株式会社永和システムマネジメント
委員天野　勝
コンサルティングセンタセンタ長
コンサルティングセンターセンター長
川端　光義アジャイルウェア代表
児玉　公信株式会社情報システム総研取締役副社長／モデラー
田澤　久楽天株式会社開発ユニット開発環境整備課課長
馬嶋　宏株式会社日立製作所情報システム事業部方式設計センタ
和田　憲明



契約問題PT
氏名所属
リダ
リーダ前川　徹
前川徹サイバ大学
サイバー大学 IT総合学部教授
委員飯塚　顕治
法務・知財財産部法務グループシニアマネージャー
高橋　雅宏
高橋雅宏アジャイルプロセス協議会見積契約ワキンググルプ
見積・契約ワーキンググループ
板東　直樹アップデートテクノロジー株式会社代表取締役社長
平野　高志ブレークモア法律事務所弁護士
古川　正伸株式会社東京証券取引所品質管理部課長
エキスパート梅本　大祐 IPA/SEC専門委員／ブレークモア法律事務所弁護士
オブザーバ
オブザバ鴨田　浩明
鴨田浩明経済産業省
葛山　弘揮経済産業省
下田　裕和経済産業省
柳橋　祥人経済産業省
新保　康夫日本コンピューター・システム株式会社事業推進本部
鈴木　律郎
鈴木律郎社団法人情報サービス産業協会
社団法人情報サビ産業協会企画調査部
茂木　智美社団法人情報サービス産業協会企画調査部／審査業務部

SECセミナーのご案内 SEC

「アジャイル型開発と共通フレーム」
～開発対象と組織の特徴に応じた適切な開発形態を選択するために～
多様なソフトウェア開発プロセスの中から、開発対象と組織の特
徴に応じた適切な開発形態を選択することにより、高品質のソ
徴に応じた適切な開発形態を選択することにより高品質のソ
フトウェアを効率よく開発することができます。
本セミナでは、非ウォタフォル型開発の代表であるアジャ
本セミナーでは、非ウォーターフォール型開発の代表であるアジャ
イル型開発と、ソフトウェア開発プロセスを包括的に規定した「共
通フレーム」について、IPA/SECでの検討結果をご説明します。

キャンセル待ち
2011年4月22日（金）13：30～17：00
年月日（金）於．
於．IPA
約1か月前に
2011年6月10日（金）13：30～17：00 予定受付開始


目次 SEC

1. アジャイル型開発における課題

2. アジャイル型開発活用に向けた課題の検討

3. アジャイル型開発手法の導入に向けて

4. まとめ


H21年度-調査事例一覧(1/2) SEC

No. 事例概要
１小売業における業務システム開発事例
２ソーシャルネットワーキングサービス（SNS）システム開発事例
３サプライチェンマネジメントシステム開発事例
サプライチェーンマネジメントシステム開発事例
４研修運営システム開発事例
５開発案件管理Webアプリケション開発事例
開発案件管理Webアプリケーション開発事例
６製造業向けプロトタイプシステム開発事例
７携帯ソーシャルゲーム開発事例
携帯ソシャルゲム開発事例
８携帯端末向けブログシステム開発事例
９パッケージソフトウェア開発事例
パッケジソフトウェア開発事例
１０共通認証システム開発事例
１１プロジェクト管理システム開発事例
プジクト管理システム開発事例

H21年度-調査事例一覧(2/2) SEC

No. 事例概要
１２アプリケーションプラットフォーム開発事例
アプリケションプラットフォム開発事例
１３教務Webシステム開発事例
１４教育機関向け統合業務パッケジ開発事例
教育機関向け統合業務パッケージ開発事例
１５検索エンジン開発事例
１６システム管理ミドルウェア開発事例
１７株式取引のためのWebアプリケーション開発事例
１８プラント監視制御用計算機システム開発事例
１９生産管理システム開発事例
２０ Webメディア開発事例
２１アジャイル型開発の支援環境開発事例
２２業界共通電子データ交換基盤構築事例
業界共通電子デタ交換基盤構築事例

アジャイル型開発の活用に向けた課題 SEC

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

領域
目指すべき日本におけるソフトウ
日本におけるソフトウェア開発の在り方見定め
開発の在り方
ゴール
契約契約のあり方、調達、制度設計

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

目次 SEC




4. まとめ


顧客・経営層への理解促進に関する検討 SEC


アジャイル型開発の適用領域・試行領域（1/2）SEC Software Engineering

すべてのソフトウェア開発にアジャイル型開発手法を適用できる、
あるいはすべきだ、という立場ではない。
ビジネスや市場、その他の開発の文脈によって、ウォーターフォー
ル型の開発が適している場面もあれば、アジャイル型の開発が適
している場面もある。

大まかには、開発当初に要求を確定せず、ビジネス環境の変化
に伴った市場や顧客
に伴った市場や顧客ニーズの変化への対応が最優先される分野
ズの変化の対応が最優先される分野
が、アジャイル型開発が最も得意とする第一適用領域である。
他方、基幹システム等で開発当初に要求をあるレルで確定可
他方、基幹システム等で開発当初に要求をあるレベルで確定可
能（あるいは確定すべき）な領域のシステムの開発においては、現
在のアジャイル型開発は試行領域となている。
在のアジャイル型開発は試行領域となっている。


アジャイル型開発の適用領域・試行領域（2/2） SEC

適用領域
①ビジネス要求が変化する領域
②リスクの高い領域
③市場競争領域

試行領域
①大規模開発
②分散拠点（オフショア含む）開発
③組織（会社）間をまたぐ開発チームによる開発
④組込みシステム開発

顧客・経営層は開発への一層の関与が必要 SEC

顧客（ユーザ）経営層
ビジネス環境が激しく変化する現状において，ITシステムに関し，従来
のように情報システム部門に任せきりでは適切に対応できない．開発
形態にも深く関与する必要がある．
ソフトウェアにおける大きな品質トラブルの背景：
・経営層の意思決定の遅れ
経営層の意思決定の遅れ
・経営層の理解不足責任問題
・経営層と関係部門との経営上の調整不足

ベンダ経営層
俊敏な開発の実績を武器に受注を狙う海外勢等に対抗するためには，
自ら俊敏な開発を実施できる体制作りに取り組むと共に，その結果を
顧客に売り込む必要がある．
顧客に売り込む必要がある

技術・スキルに関する検討 SEC


アジャイル開発に必要なスキルのまとめ SEC

非ウォーターフォール型開発にとって重要なスキル：
① プロジェクトのアウトプットに関わる判断ではなく，アジャイル開
発の進め方を踏襲させるためのファシリテーションスキル
② 反復活動の中で実際に動くものを作りながら小規模にか
反復活動の中で，実際に動くものを作りながら，小規模に，か
つトータルにプロジェクトのアウトプットを積み重ねていくスキル
③ 設計コディングテストを貫して実施出来るスキル
設計，コーディング，テストを一貫して実施出来るスキル
＜参考＞
欧米ではプロダクトマネージャ，開発者，テスタなどの役割が明確であり，その役割の中で
は技術者はほぼ対等である．開発者は日本に比べると広範囲な開発フェーズを担う．
アジャイル開発の具体論は，このような欧米の開発スタイルを暗黙的に前提としている面
アジャイル開発の具体論はこのような欧米の開発スタイルを暗黙的に前提としている面
が多い．
日本でアジャイル開発を導入する際，プラクティスを機械的に導入するのではなく，開発チ
ームや技術者のあり方，文化のあり方をどう変えていく，または変えていかない，というこ
ムや技術者のあり方文化のあり方をどう変えていくまたは変えていかないというこ
とを考えながら，検討する必要がある．

人材育成の事例－スケジュール SEC

開発メンバ育成プロジェクト立上げ開発チーム育成
ス卒キプセル模
キ開発技術(基礎知識)
技 ( ) 業ッロミー擬 OJT
ル検クジナキ開
診断定オェーー発
フクトズ
・開発できるレベル・開発者向け
まで育てる・ストーリーオーナー
向けも別途行う
・・・・業・・・自
・構成管理 / その他ツル
構成管理その他ツール・
ア・
行・
プア開フ務開チ己
ジ動ロジレー
・テスト駆動開発ャ指ジャ
発
ー
知発
ム
紹・サブチーム単位に行う
イェイ標ム識環介
・オブジェクト指向プログラムル概針クル基準ワ境ビ
ル・作ったものは捨てる
/ 設計ト憲礎ークク知識ド
要獲
章知
・Java言語 / Eclipse 識得

標準1ヶ月(習熟度により前後) 1日 2～3日
2 3日 5日
育組開
成閣発
開開
始始
参画・プロパー
プロパ
・プロダクトオーナー
・パートナー

人材育成の事例－対象別育成カリキュラム例 SEC

開発チースクラム顧客／プ先行チーリーダー PM 経営者層
ムマスターロダクトム／購買担
オーナー当など
アジャイル概要 ○ ○ ○ ○ ○ ○ ○
アジャイル基礎知識 ○ ○ ○ ○ ○ ○
アジャイル擬似体験 ○ ○ ○
業務知識 ○ ＊ ○
開発環境 ○ ＊
基本アーキテクチャ ○ ＊
業務分析／モデリング △ △
開発技術 △ ＊
ファシリテション概要
ファシリテーション概要 ○ ○ ○ ○ ○ ○
ファシリテーション演習 ○ ○ ○
○：立上げ前後の必須教育の領域
アジャイル開発を △：事前に準備が困難でOJTが必要な領域
初めて行う組織を対象＊：内容を組織内で個別に検討する必要がある領域

人材育成方法のまとめ SEC

アジャイル開発の価値（及び原則）の理解が重要
価値

プラクティスの全てを完全に身につけるより，価値原則
に従って行動する習慣を確実に身につけることが
重要手法
（背景）アジャイル開発を実践するためには，
様々な方法論・数あるプラクティスから，
プロジェクトや組織に適したものを取捨選
択し，カスタマイズすることが必要


契約形態に関する検討 SEC


モデル化：ソフトウェア開発に関わる役割と契約の起こる位置 SEC

使う人

契

保守提供補佐
契契する人
する人する人

契契で、契約の起こる可能性がある
今回
今回の場所を示す。同の組織内の場合
場所を示す。同一の組織内の場合
検討対象作る人は、契約はない。
契約には、請負契約や準委任契
契
約等の種類がある。
作る人
作る人2


SEC
アジャイル型開発における請負契約との非整合性 Software Engineering

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

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

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

推奨する契約形態（案１）：基本契約/個別契約モデルSEC Software Engineering

基本契約において、プロジェクト全体における開発側・顧客側の協力体制
を強調し、両者のポジションを明確にしておく。プロジェクトの各フェーズに
おいて、順次、具体的な個別契約を締結する。個別契約では、準委任契
お順次具体的な個別契約を締結する個別契約は準委任契
約/請負契約を使い分ける。
基本契約

準委任

準委任

請負

請負

請負
個別契約
･・・・・・

アジャイル開発プロセスモデルと基本契約/個別契約モデル SEC

シテ運
スム用

要開要開要開要開要開要開
求発テストト求発テストト求発テストト求発テストト求発テストト求発テストト
企画・・・・・・・・・

第反
１復第復
ｎ反第反
１復第復
ｎ反第反
１復第反
ｎ復

第リー
1 リス第リス
2リー第リス
mリー
• n=1のーもり
ケスあ。

基契
本約

個契
別約個契
別約個契
別約


推奨する契約形態（案２）：組合（共同事業体）モデル SEC

組合組合-ベンダ間の制作契約は
アジャイル請負契約を適用する
ベンダ (P)
業務執行組合員
ベンダ
ユーザ (P) （同一）
製作に関わる労務
出資業務執行組合員ベンダ (P)

ユーザ (I)
組合員
イテレーション単位で
組合契約成果物を納品
ユーザ（製作管理と成果管理を規定する）
製作に関わる資本
出資成果物の企画
イテレーション（バックログ）の
決定・スケジュール・予算管理
知的財産管理
成果物の収益分配
組合員の倒産、脱退、清算

(P) : Producer, (I) :Investor

目次 SEC




4. まとめ


アジャイル型開発のスイートスポット SEC

 システム規模・ 0．．１２．．３００（開発メンバー数）
 深刻度・シンプル、経済被害、．．．人身事故
シンプル経済被害人身事故
 システムの成熟度・新規開発、レガシー保守
 要件の変化率・低、中、高
 ビジネスモデル・自社開発、オプンソス、．．．
自社開発、オープンソース、．．．
 アーキテクチャ・安定、変化した、新しい
 チムの分散
チームの分散・一か所、．．、オフショア、外部委託
か所オフショア外部委託
 統制・単純なルール、．．．、SOX、．．．

フィリップ・クルーシュテン（Philippe Kruchten）の講演(2009.12)より

アジャイル型開発手法適用のポイント SEC

 適切な開発手法の選択
-開発対象の特徴や開発組織の置かれた環境などを加味しつつ
徴境
適切な開発手法を選択する・新たに考案する

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

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

■銀の弾丸はない
実践現場でのたゆまない問題解決の積み重ねを続ける

目次 SEC




4. まとめ


SEC

日本のソフトウェア産業を
もっと元気にしよう
もと元気にしよう


参考
SLCP SEC

出典「共通フレーム2007 第2版」


参考
プロセスとプラクティス SEC

XP ・システムのメタファ
タアクティビティ
・シンプルデザイン
ス・テスト駆動開発
ク・頻繁なリファクタリング
・ペアプログラミング

Scrum ・スプリントバックロググラフの作成
・自律的な組織化チーム
・スクラムミーティング
・1日以内の障害除去
・共通の部屋
共屋
・日次ビルド
・スプリントレビ
＜プロセスの構成＞＜プラクティスの例＞
＜プラクテスの例＞
What-to-do (何をするか)を表す． How-to-do (どのようにするか)を表す．
全く異なる観点

参考
従来型とアジャイル型との主な違い(1/2) SEC

プロジェクト要素従来型開発アジャイル型開発
管理「プロセス」重視「人」重視
マネジメントスタイル指揮統制型リーダーシップ・協力型
リダシップ協力型
知識の管理明示暗示
役割個人自組織
自己組織チーム
→専門化を好む →役割の相互入れ替えを推奨
コミュニケーションフォーマルで、必要な時のみインフォーマルで、継続的
顧客の関与
顧客関与重要だが、通常はプロジェクトの分必須で、継続的
重要だが通常はプジクト分必須で継続的
析段階においてのみ
プロジクトサイクル
プロジェクトサイクル業務や活動主導製品特性主導

文化が … 「プロセス」重視
「プセス重視「人」重視
「人重視
異なる
出典 Kieran Conboy, Sharon Coyle, Xiaofeng Wang, Minna Pikkarainen:
”People Over Process: Key People Challenges in Agile Development”, IEEE Software, July 2010.

参考
従来型とアジャイル型との主な違い(2/2) SEC

プロジェクト要素従来型開発アジャイル型開発
開発モデルライフサイクルモデル進化型成果モデル
（ウォーターフォール、スパイラル、ま
（ウォタフォルスパイラルま
たはこれらのバリエーション）
望まれる組織形態/構機械的（官僚的で、形式重視）有機的（柔軟性、参加性に富み、
造協力しあう社会的活動を推奨）
テクノロジー制約なし目標指向のテクノロジーが好まれる
チーム配置
チム配置分散型主体連動型主体
チームサイズ多くの場合で 10 人を超える通常は 10 人以下
継続ラ
継続ラーニング
ングあまり推奨されない積極的に採用される
マネジメント文化指揮統制型対応型
チーム参加必須でない必須
プロジェクト・プラニング管理職主導継続的
フィードバックの仕組み獲得困難通常数多く存在
文書化相当量最小限


プロセス・イノベーションに向けて SEC

イノベーションの意味は，仕組みや社会制度の革新も含まれる．
全く新しい技術や考え方を取り入れて新たな価値を生み出し，
全く新しい技術や考え方を取り入れて新たな価値を生み出し
社会的に大きな変化を起こすことである．
（1911年，経済学者・シュンペーター）
（年経済学者）

イノベーションは，複数の文化が交わるところに生まれる．
イノベションは複数の文化が交わるところに生まれる
それぞれの文化において強固な基盤が必要であり，
各文化のフロンティアにおけるコミュニケーションと協働により
各文化のフロンティアにおけるコミュニケションと協働により
イノベーションがもたらされる．

<参考（意訳）>
Innovate America：（通称“Palmisano Report”）
チャレンジとチェンジの世界における繁栄－全米イノベーションイニシアチブ報告書ブ
http://homepage1.nifty.com/bicycletour/sci-rep.priv.InnovateAmerica.htm

SEC
プロセス・イノベーションでソフトウェア産業の活性化を Software Engineering

異文化
ウォーターフォール型開発
ウォタフォル型開発アジャイル型開発
Cross Culture
相互理解
優れた部分の採り入れ
コラボレーション

（プロセス・インプルーブメント）

プロセス・イノベーション
Process Innovation

SEC

ご清聴，ありがとう
ご清聴ありがとう
ございました
ござ
報告書公開中
http://sec.ipa.go.jp/reports/20110407.html

IPA/SECホムペジ：
IPA/SECホームページ：
http://sec.ipa.go.jp/index.html

Agile Development and Contract from IPA at AgileJapan 2011

Recommandé

Recommandé

Contenu connexe

Tendances

Tendances (15)

Similaire à Agile Development and Contract from IPA at AgileJapan 2011

Similaire à Agile Development and Contract from IPA at AgileJapan 2011 (20)

Plus de Akiko Kosaka

Plus de Akiko Kosaka (19)

Dernier

Dernier (8)

Agile Development and Contract from IPA at AgileJapan 2011