アジャイル型開発を適切に採り入れるために -...

1Software Engineering Center

Information-technology Promotion Agency, Japan

SoftwareEngineeringCenter

アジャイル型開発を適切に採り入れるために

～IPA/SEC「非ウォーターフォール型開発WG活動報告書」から～

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

山下博之

平成23年度 SEC主催セミナー2011年6月1日

SECSoftware Engineeringfor Mo･No･Zu･Ku･Ri

Software Engineering Center 2

講演の趣旨（１）

Copyright © 2010-2011 IPA, All Rights Reserved.

非ウォーターフォール型開発の代表であるアジャイル型

開発を中心に、平成22年度にIPA/SECが実施した検

討の結果を「非ウォーターフォール型開発WG活動報告

書」として公開しました。

本日は、顧客・経営層の理解促進、アジャイル型開発に

必要な技術及びスキル、人材育成方法や、アジャイル

型開発にふさわしい契約モデル・契約書案など、報告書

の概要について、検討の背景を交えてご説明します。

2011-06-01



講演の趣旨（２）


アジャイル型開発形態にあまり馴染んでいない，ユーザ

企業のシステム部門やベンダ企業のマネージャー，技術

者の方々を主たる対象とし，「IPA/SEC非ウォーター

フォール型開発WG活動報告書」のポイントを中心に説

明します．

ソフトウェア開発において重要とされる，開発対象と組

織・プロジェクトの特徴に応じた適切な開発形態の選択

のためのヒントとなることを期待しています。

2011-06-01



講演の対象者


経営層

情報システム開発運用部門

契約部門

業務部門開発部門

品質保証部門

契約部門経営層

人事部門育成部門

顧客（ユーザ企業）ベンダ企業

人材育成方法

アジャイル型開発にふさわしい契約モデル・契約書案

顧客・経営層の理解促進

アジャイル型開発に必要な技術及びスキル

2011-06-01



アジャイル型開発に向けたIPA/SECの検討


ウォーターフォール型でないソフトウェア開発手法、すなわち、

アジャイル開発など「非ウォーターフォール型」の開発手法は、

日本国内のソフトウェア開発においても、

WebアプリケーションやWebサービス開発などを中心に広がり、

・競争力のある製品およびサービス開発、

・顧客ニーズへの迅速な対応、

・開発者、技術者のモチベーション向上

等に成果を上げている。

IPA/SECでは、「非ウォーターフォール型」開発手法の成果の源

を分析し、その適用領域や適用方法について整理するための

検討に取り組んでいる。

この検討の結果として、日本のソフトウェア産業全体が同様の

成果を享受できるようになることを期待している。2011-06-01



IPA/SECにおける取組み


H21年度 H22年度 H23年度

非ウォーターフォール型開発研究会

非ウォーターフォール型開発WG


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

実証実験（契約形態）

▲報告書

▲報告書

△

△▲報告書

報告書（公開中）H21年度版 http://sec.ipa.go.jp/reports/20100330a.htmlH22年度版 http://sec.ipa.go.jp/reports/20110407.html

本日の内容

事例収集

課題抽出

課題検討

2011-06-01

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

http://sec.ipa.go.jp/reports/20110407.html�


Software Engineering Center 7Copyright © 2010-2011 IPA, All Rights Reserved.

H22年度版報告書の公開中

http://sec.ipa.go.jp/reports/20110407.html2011-06-01



目次

1. アジャイル型開発に注目される背景

2. アジャイル型開発の特徴

3. 日本でのアジャイル型開発の現状

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

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

6. まとめ

Copyright © 2010-2011 IPA, All Rights Reserved.2011-06-01



現状のソフトウェア開発を取り巻く課題(1)

ビジネス・ニーズへの適切な対応

他社に先駆けた市場投入が必須で、それにより徐々に明確となるニーズを迅速に反映し改善していくことが必要な分野の出現

顧客ニーズは最初に全ては把握できず、またビジネス環境の激しい変化に伴いニーズも変化するが、この状況に迅速な対応が必要

→早期サービス提供と効果確認、ニーズ変化への俊敏な対応




ビジネス環境の変化とITシステムの対応


時間→

環境

予測可能な環境変化量

変化対応のシステム開発期間これまでの変化の状況

最近の変化の状況

★システム完成

短縮が必要

変化が進んでしまっている

2011-06-01



現状のソフトウェア開発を取り巻く課題(２)

（純粋な）ウォーターフォール型開発における問題点

初期段階では必ずしも全ての要求内容は確定しない

誤要求や要求の誤解が総合テスト段階で判明すると、多大な影響

開発途中で要求が変更されると、対応が非常に困難

→要求確定部分からの順次開発開始と、妥当性の早期確認




ビジネス戦略・構想

実現プラン

業務設計・事務設計

基本設計

詳細設計

システム構築

経営層・経営企画

経営企画・業務企画・営業企画・ＩＴ企画

業務管理・事務管理・営業推進・ＩＴ企画

担当責任部門

ＩＴ開発・ベンダ



事業計画

制度設計・業務設計・事務設計（人・物・金・時間・組織）

システム要件定義

企画・稟議・決済

構想具体化・開発

構想力

構築力

超上流

システム開発の流れ

(1) 業務要件とシステム要件

２００６Ｙ．ＫＩＫＵＳＨＩＭＡ

2011-06-01 Copyright © 2010-2011 IPA, All Rights Reserved.




実現プラン


基本設計

詳細設計

システム構築

システムが実現するビジネス

作成するシステム

（発注者が欲しいもの）発注者が見ている要件

受注者が欲しい要件

早く決めてよ


(2) ユーザ（発注者）が欲しいのはシステムではない






(3) ベースラインで始めても，後で変更


実現プラン


基本設計

詳細設計

システム構築

業務要件（構想の具体化）

システム要件(システムは業務の写像）

ベースライン（こういう仕組みでこれを実現する。

実現したことになる条件の明確化）

事情が変わった

考えが変わった

考えもれた

誤った

未承認だった等

理解違い

把握漏れ

設計ミス

リソース不足等

契約

変更管理





プロジェクトの進行

オーナー

テスト

＜製造装置＞

開発部隊（内製･

ｿﾌﾄｳｪｱﾊｳｽ）

アプリケーションオーナー（発注部門）

負担量

サプライヤー（開発部門）製造責任

提供責任こういう物（要件）を

作って欲しい

こういう物（要件）で

どうですか

要求通りになっているか

確認＆Validation

要求通りにできているか

確認

テスト

要件確定設計・製造テスト稼働・供給

利用促進

マニュアル

教育


(4) ユーザ（発注者）の役割とタイミング





要求の誤解による影響

発注者と開発者の認識の齟齬により，要求と実現されるソフトとの間にギャップが生じる

システム化計画

業務部門の要求内容

要件定義内容

外部設計内容

実現される

ソフトウェア

④開発者が何らかの理由により誤認・拡大解釈し，実現範囲に取り込んでしまった

③発注者が開発者に説明し，共通理解が得られた

発注者が要件定義までを行い，それ以降の工程を開発者が行う場合の例

発注者開発者

A B C

バグや障害

バグや障害

バグや障害

①要件定義すべき内容が抜けており，開発者に説明していない

②発注者が開発者に説明したが，何らかの理由で漏れた


プレゼンター

プレゼンテーションのノート

実際の役割分担は、様々考えられるが、ここでは、発注者が要件定義までを行い、それ以降の工程を開発者が行う場合の例を図示した。矢印のＡからCのいづれでも、また、ここに記載していない部分でも、抜けもれや誤認などが考えられる。この絵の例では、発注者と開発者の接点であるBの矢印部分で起きることに注目している。本日はIPA/SECのこの部分に注目して活動している「機能要件の合意形成ＷＧ」の活動とその成果物の紹介をします。



ウォーターフォール型開発の流れ

要件定義

設計

コーディング

テスト

運用

・全体の要件と計画を初めに決める →計画駆動型・前工程を誤りなく完了させて、次の工程へ進む




ウォーターフォール型開発への疑問

要件定義

機能設計

モジュール設計

コーディング

総合テスト

機能テスト

結合テスト

単体テスト

分

解

合

成

チェック

チェック

チェック

・要件が事前に全ては決まらない・要件の誤りが最後のテストまで発見されにくい・時間がかかり過ぎて変化への対応が遅れる




Faultsの混入，発見，除去




現状のソフトウェア開発を取り巻く課題(３)

ソフトウェア産業構造（多重下請構造）上の課題

開発者（特に若者）の参画意識・達成感が低い

→開発の過程と各開発者の役割や成果を可視化し、創造的な開発スタイルを採り入れ、モチベーション向上をはかる




アジャイル型開発への期待


ウォーターフォール型のソフトウェア開発では、品質の高いソフトウェアを生産性高く開発するために、開発初期に要求の固定をはかり、ドキュメントの形で仕様を形式化してソフトウェア・エンジニアリング的な開発モデルに乗せようと努力してきた。

しかし、そもそも要求が刻々と変化している場面では、要求を固定すること自体が製品やサービスの販売リスクを拡大してしまう場合が多い。また、開発の中には技術リスクが大きく、実際に作ってみないとそのリスクを解消できない場合がある。

このような状況においては、従来のウォーターフォール型ではない、別のソフトウェア開発モデルが必要とされてきている。

そのような「非ウォーターフォール型」のソフトウェア開発モデルの代表として、アジャイル型開発に着目する。

2011-06-01



アジャイル型開発に関する検討の意義


ウォーターフォール型開発は、

高信頼性が求められる基幹システム等、

過去のほとんどの分野で実績がある。

これに対し、非ウォーターフォール（アジャイル）型開発は、

情報システムを市場へいち早く提供していくことに価値があると考えられる分野に向いている。

特に、開発形態が多様化している後者の分野において、

非ウォーターフォール型開発の適用に適した領域を見定め、

その活用を促進していくことが必要である。

また、現在、非ウォーターフォール型開発があまり適用されていない領域においても、その特質を明らかにすることにより、今後の適用を検討していくことは有意義である。

2011-06-01



アジャイル型開発の検討により期待される効果


①日本のソフトウェア産業の実態に適しており、かつ世の中のパラダイム転換に対応することのできるソフトウェアの作り方の提案になる。

②グローバルな視点から見た、わが国のソフトウェア産業の競争力を強化することにつながる。

③優先度の高い機能が順次提供され、提供された機能を検証・投入することにより、変化が激しく、優先度も変化するビジネス環境に対応できるサービスやシステムを手に入れられる。

④エンジニアが自分自身の成長を実感でき、開発したシステムが利用者の役に立っていると実感できることにより、エンジニア一人ひとりが生き生きと働くことのできる環境の整備につながる。

2011-06-01



目次






6. まとめ




アジャイル型開発の特徴


アジャイル開発は、不確実なビジネス環境の中で変化するニーズへの迅速な対応を目的としたソフトウェア開発手法。

この目的を達成するために、アジャイル開発では、徐々に明確となる顧客ニーズや要件をシステムへ反映し、プロジェクトマネジメント・リスクの早期低減、顧客側と開発側のギャップを解消。

アジャイル開発は、•「顧客の参画の度合いが強い」•「動くソフトウェアを成長させながら作る」•「反復・漸進型である」•「人と人のコミュニケーション、コラボレーションを重視する」•「開発前の、要求の固定を前提としない」という特徴を持つ。

2011-06-01



非ウォーターフォール型開発の例


非ウォーターフォール型開発とは、仕様を開発前に固定し、それを分析、設計、テスト等のフェイズを順次踏んでいくという1970年の Winston W. Royce の論文「Managing the Development of Large Software Systems」でのウォーターフォール型以外の開発モデルの総称である。非ウォーターフォール型開発の例として、以下のものが挙げられる：・プロトタイプ (Frederick P.Brooks, Jr.－1975年「人月の神話」)・スパイラル (Barry w. Boehm－1988 年

「A Spiral Model of Software Development and Enhancement」)・RAD (James Martin－1991年「ラピッドアプリケーションデベロップメント」)・RUP (Philippe Kruchten－2000年「ラショナル統一プロセス入門」)・アジャイル

Evo (Tom Gilb－1976年「Software Metrics」)Scrum (Ken Schwaber－1993年「アジャイルソフトウェア開発スクラム」)DSDM (1995年「DSDM ver1」)XP (Kent Beck－1996年「XPエクストリーム・プログラミング入門」)FDD－Feature-Driven Development

(Peter Coad－1997年「Javaエンタープライズ・コンポーネント」)

Lean Software Development(Mary Poppendieck, Tom Poppendieck－2002年「リーンソフトウェア開発」)

Crystal Clear (Alistair Cockburn－2004年「アジャイルソフトウェア開発」)EssUp－Essential UP

(Ivar H.Jacobson－2005年「Rational Software Development Conference」)

Kanban (David Anderson－2010年「Kanban」)

参考

2011-06-01



アジャイル宣言における4つの価値


アジャイル宣言（Agile Manifesto）アジャイルな開発手法の提唱者17名が集まり，2001年に発表．http://agilemanifesto.org/iso/ja/manifesto.html

私たちは，ソフトウェア開発の実践を手助けする活動を通じて，よりよい開発方法を見つけだそうとしている．

この活動を通して，私たちは以下のことを重視する：

①プロセスやツールよりも，個人と対話を

②包括的なドキュメントよりも，動くソフトウェアを

③契約交渉よりも，顧客との協調を

④計画に従うことよりも，変化への対応を

すなわち，①～④の各文の前者（「よりも」の前の言葉）に価値があることを認めながらも，私たちは後者（「よりも」の後の言葉）の事柄により価値をおく．

2011-06-01



アジャイル宣言の背後にある12の原則


私たちは以下の原則に従う。

①顧客満足を最優先し、価値のあるソフトウェアを早く継続的に提供する。

②要求の変更はたとえ開発の後期であっても歓迎する。

変化を味方につけることによって、顧客の競争力を引き上げる。

③動くソフトウェアを、2-3週間から2-3ヶ月というできるだけ短い時間間隔でリリースする。

④ビジネス側の人と開発者は、プロジェクトを通して日々一緒に働く。

⑤意欲に満ちた人々を集めてプロジェクトを構成する。

環境と支援を与え仕事が無事終わるまで彼らを信頼する。

⑥情報を伝える最も効率的で効果的な方法は、フェイス・トゥ・フェイスで話をすることである。

⑦動くソフトウェアこそが進捗の最も重要な尺度である。

⑧アジャイル･プロセスは持続可能な開発を促進する。

一定のペースを継続的に維持できるようにしなければならない。

⑨技術的卓越性と優れた設計に対する不断の注意が機敏さを高める。

⑩シンプルさ（ムダなく作れる量を最大限にすること）が本質である。

⑪最良のアーキテクチャ・要求・設計は、自己組織的なチームから生み出される。

⑫チームがもっと効率を高めることができるかを定期的に振り返り、それに基づいて自分たちのやり方を最適に調整する。

参考

2011-06-01



反復（イテレーション）

アジャイル型開発のモデル


スコープ

要求

開発

テスト

スコープ時

間要求

開発

テスト

スコープ

時間

反復

スコープ

時間

反復

顧客の要求にしたがって，優先度の高い機能から順に，要求・開発・テスト（・リリース）を短い期間で繰り返しながら，システム全体を構築していく．原則として，事前に開発の詳細な計画は作らず，1～4週間という一定の短い周期で要求・開発・テストを繰り返しながら，動作可能なソフトを作り上げる．

＜アジャイル型開発＞＜ウォーターフォール型開発＞

（対比）

反復開発・順次ﾘﾘｰｽ

一括開発・一括ﾘﾘｰｽ

2011-06-01



各開発モデルにおけるプロセスの対応


要求

開発

テスト

<標準>ソフトウェアライフサイクルプロセス（SLCP）

要求

開発

テスト

<実際>

注) 図形のサイズは意味を持たない（時間，規模を表さない）．

（部品）

ウォーターフォール型

大きなプロセスを順に実施し，それを1回で終了

アジャイル型

小さなプロセスを行き来しつつ実施し，それを何回も反復

注) 図形のサイズは意味を持つ．

参考

2011-06-01



プロセスとプラクティス


アクティビティタスク

＜プロセスの構成＞

What-to-do (何をするか)を表す．

参考

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

Scrum ・スプリントバックロググラフの作成・自律的な組織化チーム・スクラムミーティング・1日以内の障害除去・共通の部屋・日次ビルド・スプリントレビ

How-to-do (どのようにするか)を表す．

＜プラクティスの例＞

全く異なる観点2011-06-01



アジャイル開発に関する国際(ISO)標準(1/2)


＜得られた知見＞

・アジャイル開発が何を意味するかに関しては，さまざまな解釈がある．

・アジャイル手法，技法，実践規則の採用は，増加し，既に広く普及している．しかし，採用における初期の試みは，ごく一部でしか成功していない．

・アジャイル手法は，「どのように(how)」ソフトウェア・システムエンジニアリング・アクティビティを実施すべきか，に焦点を当てているが，関連するSC7ソフトウェア・システムエンジニアリング標準は，「何を(what)」実施すべきか，実施すべきプロセス（アクティビティ）の目的，意図されている効果(outcomes)，プロセス及び形成/改変されたプロダクト計量法に焦点を当てている．

・アジャイル手法は，主要な関連ソフトウェア・システムエンジニアリング標準とは抵触しない．

・アジャイル手法を採用するかどうかは，多くの場合，テクニカルな専門職によって決定され，ビジネス責任者は，その成功のためにビジネスが関わらなければならない水準(business engagement level)を理解していない．

・アジャイル手法を利用して開発した場合，会計システムに対する第3者認定が，認定者が必要とする文書欠落のため，受けられない可能性がある．

・アジャイル手法の適用には，ビジネスや組織の文化等に関する適合すべき状況がある．

・アジャイル手法の適用が成功するためには，その基礎とする価値及び原則の適用や開発メンバのスキル等の因子で成功する必要がある．

参考

2011-06-01



アジャイル開発に関する国際(ISO)標準(2/2)


出典：アジャイル開発に関するISO標準またはガイダンス策定の必要性（松本吉弘訳）Study Group Report on the possibility of new standards or guidance in the area of Agile Development (ISO/IEC /JTC 1/SC 7/N4289, 2009-04-19)

＜SC7標準との関係＞

・現時点では，アジャイル手法，技法及び実践規則に限定して対処しているSC7標準は存在しない．

・ISO/IEC12207やISO/IEC15288 のライフサイクルモデルが適用されているあるいは適用が要求されている組織において，アジャイル手法が利用されることを妨げるものではない．

・ISO/IEC15504（プロセス評価）やISO/IEC15939（計量プロセス）がアジャイル開発において使われることは差し支えない．

・SC7標準に精通していて，アジャイル手法及び技法を採用しようとしている組織は，ISO/IEC12207という裏付け(context)の中で，ガイダンス（現時点では，存在しない）に従って，それを適用することが望ましい．

・SC7標準に精通していて，アジャイル手法及び技法を採用しようとしている組織は，ISO9001という裏付けの中で，（可能であれば，ISO/IEC9003で使われているのと似たやり方を使って，）ガイダンスに従ってそれらを適用することが望ましい．

参考

2011-06-01



目次






6. まとめ




使われている開発モデルの調査例（１）

N=2451

反復型2.7％

その他1.2％

ウォーターフォール型96.1％




使われている開発モデルの調査例（２）


出典：平成22年度ソフトウェア開発管理基準に関する調査報告書（ソフトウェアメトリックス調査）（経済産業省）http://www.meti.go.jp/policy/mono_info_service/joho/softwaremetrics/2010/index.html

2011-06-01



使われている開発モデルの調査例（３）


出典：第17回企業IT動向調査2011（10年度調査）（2011．5．17，社団法人日本情報システム・ユーザー協会）

2011-06-01



使われている開発モデルの調査例（４）


出典：第17回企業IT動向調査2011（10年度調査）（2011．5．17，社団法人日本情報システム・ユーザー協会）

2011-06-01


Software Engineering Center 39Copyright © 2010-2011 IPA, All Rights Reserved.

米国におけるアジャイル開発の採用状況

2010年に発表された，米国調査会社フォレスター・リサーチ社のレポートによる，米国のアジャイル開発利用率

参考

2011-06-01



（大手）システムインテグレータ(PMO)

日本の調達モデル

ユーザ（CIO）

ハードウエアベンダ

データベース・ベンダ

パッケージベンダ

システム開発ベンダ

パッケージシステム

開発ハードウエア

データベース

経営システム外部設計

経営システムコンサル

IPAグローバルシンポジウム2010 一色浩一郎教授講演より

参考




米国の調達モデル

ユーザ（CIO，PMO）

ハードウエアベンダ

データベース・ベンダ

パッケージベンダ

システム開発ベンダ

パッケージシステム

開発ハードウエア

データベース

経営システム外部設計

経営システムコンサル


参考




米国におけるアジャイル開発の例



参考

2011-06-01



H21年度の事例調査：概要

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

実施内容：17社・22事例を対象に，開発対象の特性・適用領域及び開

発方法，適用プラクティス，契約形態，等について調査．併せて産学官の有識者をメンバとする研究会を設置し，適用

にあたっての課題を抽出．

→報告書として公開：URL=http://sec.ipa.go.jp/reports/20100330a.html


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



調査事例一覧(1/2)

No. 事例概要

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

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

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

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

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

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

７携帯ソーシャルゲーム開発事例事例調査結果②

８携帯端末向けブログシステム開発事例

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

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

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




調査事例一覧(2/2)

No. 事例概要

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

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

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

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

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

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

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

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

２０ Webメディア開発事例

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

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




チームの人数

（人）

事例：アジャイル型開発プロジェクトの規模

2

4

6

8

10

12

2 4 6 8 10 12 14 16 18 20 22 24開発期間（月）

⇒チームの人数は8割が10人以下

⇒開発期間は2～4ヶ月が45％、1年超が35％




事例：イテレーション(スプリント)の期間

0

1

2

3

4

5

6

7

1 2 3 4 5 6 7 8イテレーション(スプリント)期間（週）

事例の数

（件）

その他：1～2週間 2件1～4週間 1件

⇒1～2週間が中心




件数

14121086420 16 18 20 22

頻繁なふりかえり計画ゲーム

日次のスタンドアップミーティング（朝会）

継続的インテグレーションペアプログラミング

バーンダウンチャートリファクタリングテスト駆動開発

コードの共同所有かんばん

自動化された回帰テストニコニコカレンダー

顧客プロキシタスクカードポストイット

タイムボックス頻繁なリリース

コーディング規約ストーリーカード

単体テストの自動化スクラムのスプリントスプリントバックログ

チーム全体が一つに 71.4％

52.4％

47.6％

42.9％

38.1％

28.6％

23.8％

19％

14.3％

1511

10109

88

65

444

33333

222222

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

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

※1事例は活用プラクティス不明




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

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

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

日本におけるソフトウェア開発の在り方

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

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

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

重点課題

目指すべきゴール

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

領域見定め

契約

価値評価

普及




目次






6. まとめ




平成21年度の課題と平成22年度の取組み


非ウォーターフォール型開発の適用に適した領域を見定め、その活用を促進していく

平成21年度の研究により明らかになった課題

平成22年度の取組み


日本のソフトウェアの作り方目指すべきゴール

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

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


普及

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

調査


非ウォーターホール型開発における重点課題








普及


調査






普及


調査






普及


調査



・非ウォーターフォール型開発に適した契約モデルの検討

・非ウォーターフォール型開発に適した契約モデルに沿った契約のひな型の作成

・顧客・経営層が考慮すべき点とその検討

・顧客側と開発側に必要な包括的エンジニアリング技術、プロジェクト運営技術・スキルの明確化

・人材育成方法の検討・必要な技術・スキルの獲得方法の検討

2011-06-01



開発プロセス・モデルに関する検討




調査事例から導かれた開発プロセス・モデル(1)

モデル2

モデル1

企画

システム運用

• n=1のケースもあり。

第１反復

テスト

開発

要求

第ｎ反復

テスト

開発

要求・・・

第1リリース

・・・

第１反復

テスト

開発

要求

第ｎ反復

テスト

開発

要求・・・

第2リリース

・・・

第１反復

テスト

開発

要求

第ｎ反復

テスト

開発

要求・・・

第mリリース

要求・アーキテクチャ設計・基盤開発

企画

システム運用

• 比較的大規模システム／新規開発で全体のシステム構造が不明確なケースなど

第１反復

テスト

開発

要求

第ｎ反復

テスト

開発

要求・・・

第1リリース

・・・

第１反復

テスト

開発

要求

第ｎ反復

テスト

開発

要求・・・

第mリリース




調査事例から導かれた開発プロセス・モデル(2)

モデル3システム運用

・アジャイル開発では反復ごとにリリースできる品質までテストを行うことが原則だが、各リリース工程前に行う重点的なテストを実施することがある。

・リリースは複数回繰り返される

企画リリース前

テスト・・・・・・

第１反復

テスト

開発

要求

第ｎ反復

テスト

開発

要求・・・

第1リリース

リリース前テスト

第１反復

テスト

開発

要求

第ｎ反復

テスト

開発

要求・・・

第mリリース




開発プロセス・モデルの考え方


基盤・共通部

機能1

機能2

機能3

機能4

…

モデル１基本形

モデル２拡張形．基盤・共通部といくつかの機

能部とから構成されるソフトウェア（右上図）において，最初にまず，基盤・共通部の開発を終えた後，機能部群について，アジャイル開発を行う．基盤・共通部が確固としていないと，追加・変更時の機能部への影響が大きくなりすぎることを避ける．アジャイル開発では，基盤・共通部の変更は，原則として行わない．

モデル３顧客やビジネスの特徴から，

特に高い品質が求められたり，品質がクリティカルであったりする場合に，リリース前に品質確保のための特別のアクションを実施する．

2011-06-01



アジャイル型開発のビジネス構造モデル


■ビジネス構造モデルの基本パターン

使う人

提供する人

作る人

作る人2

保守する人

契

契

契

契補佐

する人

契

使う人

提供する人

作る人

作る人2

保守する人

契

契

契

契補佐

する人

契

・使う人 ⇒ システムを実際に使用する人（システムの利用者、エンドユーザ）

・提供する人 ⇒ 開発されたシステムやサービスを使う人に提供する人

・作る人 ⇒ システムの開発者

・作る人２ ⇒ 作る人の会社と契約している、作る人と一緒に開発する人

（作る人の会社とは別会社が多い）

・保守する人 ⇒ リリースされたシステムを保守する人

（作る人と重なることが多い）

・補佐する人 ⇒ アジャイル開発の進め方等で、開発プロジェクトを支援する人

（コンサルタントやファシリテーターが多い）

契約の起こる可能性がある場所（同一の組織内の場合には契約なし）

契

2011-06-01



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




アジャイル型開発手法の導入理由（海外）

22% 21%

12%10% 9%

6% 6%4% 3% 2% 2% 2% 1%

0%

5%

10%

15%

20%

25%

Tim

e-to

-M

arke

t

の

加速

変化する優先順位

管理のため

生産性向上

ソフトウェア品質

の向上

IT

とビジネスの

融合改善

プロジェクトの

見える化

リスク削減

開発プロセスの

簡易化

その他

エンジニアリング

の導入／向上

コスト削減

保守性／拡張性

向上

チームの

やる気改善

１．Time-to-Marketの加速２．変化する優先順位管理のため

（VersionOne社アジャイル開発の現状調査第3回2008より）

参考




アジャイル型開発の適用領域・試行領域


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

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

2011-06-01



アジャイル型開発の適用領域


アジャイル開発は，「顧客の参画の度合いが強い」，「動くソフトウェアを成長させながら作る」，「反復・漸進型である」，「人と人とのコミュニケーション・コラボレーション重視」，「開発前の仕様の固定を前提としない」等を特徴とするため，以下の領域での開発を得意とする：①ビジネス要求が変化する領域・要求の変化が激しく，あらかじめ要求が固定できない領域。

②リスクの高い領域・不確実な市場を対象としたビジネス領域（市場リスク）・技術的な難易度が高い開発領域（技術リスク）

③市場競争領域・他社に先駆けた製品・サービス市場投入が命題であり，TTM（Time to

Market）の短縮が優先となる領域（Webのサービス，パッケージ開発，新製品開発）．

2011-06-01



アジャイル型開発の試行領域


アジャイル型開発による経験が十分には蓄積されておらず、現在、チャレンジと創意工夫が求められているのは、以下の領域である：①大規模開発・開発者10人程度を超えると、システム分割、チーム分割が必要。その分割方法、及び、分割されたチーム間のコミュニケーションが課題。

②分散拠点（オフショア含む）開発・開発拠点が分散し、さらに時差によって分断される場合のコミュニケーション手法、また、それをサポートするツールが必要。

③組織（会社）間をまたぐ開発チームによる開発・共通のビジネスゴールを持ったチームを組むことが難しい。

④組込みシステム開発・リリース後のソフトウェア修正が極めて困難であり、採用には工夫要。

2011-06-01

プレゼンター


アジャイル開発の試行領域アジャイル開発による経験が十分には蓄積されておらず、現在、チャレンジと創意工夫が求められているのは、以下の領域である。 ①大規模開発アジャイル開発はコミュニケーションを重視するために、開発者10人程度の規模が最もうまく機能する。これを超えると、システム分割、チーム分割が必要となる。この場合、サブシステムやチームの分割方法、および、そのチーム間のコミュニケーションについては課題であり、さまざまな方法が提案されている。 ②分散拠点（オフショア含む）開発アジャイル開発はコミュニケーションを重視するために、コロケーション（１つの場所に集まったチーム）が原則である。開発拠点が分散し、さらに時差によって分断される場合のコミュニケーション手法、また、それをサポートするツールの必要性が指摘されている。 ③組織（会社）間をまたぐ開発チームによる開発アジャイル開発は、共通のビジネスゴールをもったチーム、を前提とする。会社や組織をまたいだ構成のチームでは、このような体制を組むことが難しい。特に、日本では複数の会社が契約をまたいでチームを構成することが多いため、これが大きな課題になる可能性がある。 ④組込みシステム開発　ハードウェアの開発と並行してソフトウェアが開発され、高信頼性が求められる組込みシステムでは、リリース後のソフトウェアの修正が極めて困難であることからも、アジャイルの特性の一部が適用しにくく、採用には工夫を要する。大規模、分散については、現在多くのシステム開発がこれを避けられなくなってきていることもあり、かなりの事例が出ている。さらに、開発組織全体をアジャイルに転換する企業も増えており、組織改革と同時に企業戦略としてアジャイルが採用されている例も多い。



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


顧客（ユーザ）経営層

ビジネス環境が激しく変化する現状において，ITシステムに関し，従来

のように情報システム部門に任せきりでは適切に対応できない．開発

形態(*)にも深く関与する必要がある．

(*) アジャイル開発の採用，クラウドコンピューティングの利用，など

ベンダ経営層

俊敏な開発の実績を武器に受注を狙う海外勢等に対抗するためには，

自ら俊敏な開発を実施できる体制作りに取り組むと共に，その結果を

顧客に売り込む必要がある．

＜経営層の責任＞・情報システムに関する理解の増進・迅速かつ適切な意思決定・関係部門との経営上の綿密な調整

2011-06-01



顧客・経営層が開発上で考慮すべき点


顧客・経営層は、アジャイル開発の採用を決断した時点で、顧客がチームの一員として参画し、タイムリーな意思決定を行ったり、品質や進捗状況の把握等に関し、主体的に開発に関わらざるを得ないということに十分な理解と覚悟を持つ。

アジャイル開発においては、反復の都度、コードを書き変えていくスタイルが採られる。品質に重大な悪影響が及ぶかどうかの観点での、プロダクト品質の見える化が必要。

アジャイル開発の特徴に応じた「見える化」項目を用いて開発プロジェクトとの円滑なコミュニケーションを図り、アジャイル開発採用の本来の目的が損なわれないように努める。

2011-06-01



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




役割によるスキルの相違


ウォーターフォール型開発と比較したアジャイル開発の大きな相違点：

① ファシリテーターが存在する

② 毎日コードをチェックインしている

③ 品質検証・保証の機能は，プロジェクトの普段の活動に組み込まれる

②③は役割の違いによる差であり，スキルの差ではない．

①に関しても役割の差とも言えるが，アジャイル開発に求められる新たな役割でもあり，それは必要なスキルの相違につながる可能性がある．

2011-06-01



アジャイル型開発における役割とスキルの対応例

テクニカルコーチ

アジャイルコーチ

プロダクトオーナ

ストーリーオーナー

ビジネスアーキテクト

開発チーム代表

開発メンバ

◎ ◎ ◎ ○ ○ ◎ ○スクラム一般 ◎ ◎ ◎ ◎ ○ ◎ ◎スクラム PJ固有 ◎ ◎ ◎ ◎ ○ ◎ ◎実務－－ ○ ◎ ○ ○ ◎ドメインモデル－－ ○ ○ ◎ ◎ ◎モデリング ○ ◎ △ ○ ◎ ○ ◎Java ◎ ◎ －－－ ○ ◎OOプログラミング ◎ ◎ －－－ ○ ◎OO設計 ◎ ◎ －－－ ○ ◎UML ◎ ◎ －－ ◎ ○ ◎リファクタリング ◎ ◎ －－－ ○ ◎TDD ◎ ◎ －－－ ○ ◎単体・結合テスト ◎ ◎ －－－ ○ ◎システムテスト ◎ △ －－－ ○ ◎HTML/CSS ◎ △ － ○ － ○ ◎JavaScript ◎ △ － △ － ○ ◎WebUIテスト ◎ △ － ○ － ○ ◎SQL ◎ △ －－－ ○ ◎DB物理設計 ◎ △ －－－ ○ ◎DBチューニング ◎ △ －－－ ○ ◎Eclipse ◎ ◎ －－－ ○ ◎Subversion ◎ ◎ －－－ ○ ◎Trac ◎ ◎ －－－ ○ ◎Hudson ◎ ◎ －－－ ○ ◎フレームワーク ◎ △ －－－ ○ ◎ステージング環境 ◎ △ －－－ ○ ◎

業務知識

技術

開発環境

役割

プロジェクト運営

運営チーム




進め方（プロセス）によるスキルの相違


ウォーターフォール型開発と比較したアジャイル開発の大きな相違点：

① 全部やろうとしない

② ドキュメントだけで設計はしないでコーディング

③ ２週間程度で実際に動くものを見せる

④ 繰返し型のプロセスがある

①②については，技術，スキルの相違は生じない．

③④を実施するには，ドメイン領域の知識，幅広い言語知識が求められる．

ウォーターフォール型開発では，特に設計とコーディングを別々のメンバが担当することがよくある．

アジャイル開発では，繰返し型のプロセスであるため，設計，コーディング，テストコード作成を含むテストが，同じメンバにより一貫して実施される．アジャイル開発の全メンバには，これらマルチのスキルが求められる．

2011-06-01



ユーザ側に求められるスキル


ウォーターフォール型開発におけるユーザに求められること：

・実現するシステム，アプリケーションの業務仕様についての責任を負う

・プロジェクトの進行管理：決めた機能，スケジュールの通りにプロジェクトが進行しているか確認し，進行していない場合に適切な対応を取る

アジャイル開発におけるユーザに求められること：

（全ての機能の仕様を洗い出す能力よりも）コアとなる機能を見定め，優先度を図りながら開発プロジェクトの運営を指揮していく能力

明確な仕様を決めなくても良いとはいうものの，定期的なサイクルで実物を見てフィードバックのポイントを増やすことにより，実際のシステムを目で確認しながら，積み上げるように仕様を決定していく

2011-06-01



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


非ウォーターフォール型開発にとって重要なスキル：

① プロジェクトのアウトプットに関わる判断ではなく，アジャイル開発の進め方を踏襲させるためのファシリテーションスキル

② 反復活動の中で，実際に動くものを作りながら，小規模に，かつトータルにプロジェクトのアウトプットを積み重ねていくスキル

③ 設計，コーディング，テストを一貫して実施出来るスキル

＜参考＞

欧米ではプロダクトマネージャ，開発者，テスタなどの役割が明確であり，その役割の中では技術者はほぼ対等である．開発者は日本に比べると広範囲な開発フェーズを担う．

アジャイル開発の具体論は，このような欧米の開発スタイルを暗黙的に前提としている面が多い．

日本でアジャイル開発を導入する際，プラクティスを機械的に導入するのではなく，開発チームや技術者のあり方，文化のあり方をどう変えていく，または変えていかない，ということを考えながら，検討する必要がある．

2011-06-01



人材育成方法（1/3）


アジャイル開発を実践するためには，

様々な方法論・数あるプラクティスから，

プロジェクトや組織に適したものを取捨選択し，カスタマイズ

することが必要

＜カスタマイズの例＞

現在の日本の商慣習に基づき一括請負契約でアジャイル開発を実践する場合，要件が変更される度にITベンダには負担がかかり，うまくマネジメントできなければたちまち赤字プロジェクトとなってしまう．したがって，イテレーション計画は当然のこと，顧客と頻繁にコミュニケーション出来るためのプラクティス，環境が非常に重要となってくる．また，不具合の瑕疵担保責任を全て開発側が負うため，テストやシステムの保守容易性に関するプラクティスを整備しておくべきである．

留意点

2011-06-01





今までアジャイル開発を実践した経験がない開発チームや技術者にとってプラクティスのカスタマイズは容易ではない。何故ならば、あらゆるプラクティスは他のプラクティスと相互作用するからである。

アジャイルプロセスの価値・原則も理解しなければならない．

アジャイル開発を初めて実施するチームであれば，まずは全てのプラクティスを適用し，模範に従って忠実に実践することが大事である．

相互作用を十分に理解した上で，次に，プラクティスをカスタマイズし，自分のプロジェクトでうまくいくかどうかを検証する．そこまで実践できれば，他のカスタマイズが必要なプロジェクトでも影響が予測でき，新しいプラクティスを創造して対処出来るようになる．

2011-06-01





全てのプラクティスを適用して実践する方法：

(1) 社外的に影響しない自社用のシステム開発プロジェクトにアジャイル開発を適用する

(2) 社内プロジェクトへの適用が困難な場合，アジャイル開発研修を行う．約１ヶ月から３ヶ月程度の仮想プロジェクトとしてアジャイル実践経験者を講師に迎えることにより，効率良く習得出来る．

教育に時間や費用が掛けられない中小企業の場合，２-３日の短期間の研修でも効果は得られる．この場合，チームプラクティス(*)をメインとした内容が望ましい．一人で出来るプラクティスは，研修後，各自で習得することが出来る．

(*) チームビルディング，計画ゲーム，ふりかえり，コードの共同所有，ペアプログラミング

2011-06-01



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


育成開始

スキル診断

卒業検定

標準1ヶ月(習熟度により前後)

開発技術(基礎知識) プロジェクト

キックオフ

ルーキーズ

セミナー

模擬開発

開発開始

・構成管理 / その他ツール・テスト駆動開発・オブジェクト指向プログラム/ 設計・Java言語 / Eclipse

1日 2～3日 5日

開発メンバ育成開発チーム育成

OJT

・自己紹介

・チームビルド

・開発環境知識獲得

・業務知識

・フレームワーク

・開発標準

・アジャイル基礎知識

・サブチーム単位に行う・作ったものは捨てる

・開発者向け・ストーリーオーナー向けも別途行う

・プロジェクト憲章

・行動指針

・アジャイル概要

・開発できるレベルまで育てる

組閣

参画・プロパー・プロダクトオーナー・パートナー

プロジェクト立上げ

2011-06-01



○：立上げ前後の必須教育の領域△：事前に準備が困難でOJTが必要な領域＊：内容を組織内で個別に検討する必要がある領域

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

開発チーム

スクラムマスター

顧客／プロダクトオーナー

先行チーム

リーダー PM 経営者層／購買担当など

アジャイル概要 ○ ○ ○ ○ ○ ○ ○

アジャイル基礎知識 ○ ○ ○ ○ ○ ○

アジャイル擬似体験 ○ ○ ○

業務知識 ○ ＊ ○

開発環境 ○ ＊

基本アーキテクチャ ○ ＊

業務分析／モデリング △ △

開発技術 △ ＊

ファシリテーション概要 ○ ○ ○ ○ ○ ○

ファシリテーション演習 ○ ○ ○

アジャイル開発を初めて行う組織を対象




人材育成の事例－カリキュラム概要


名称概要

アジャイル概要アジャイル開発に携わる方向けの基礎知識

アジャイル基礎知識一般的なプラクティスについての紹介

アジャイル擬似体験アジャイル開発のプロセスを体験を通して理解するチームビルディング的な狙いもある

業務知識開発対象の業務を理解する(内容は先行チームと検討)

開発環境開発に使用するツールなどを理解する(内容は先行チームと検討)

基本アーキテクチャ開発対象のシステム構成や、利用するフレームワークなどを理解する(内容は先行チームと検討)

業務分析／モデリング業務を整理し、開発側に伝えるための手法を理解する

開発技術開発に必要な技術を身につける（必要に応じて）

ファシリテーション概要ファシリテーションに関する知識を理解する

ファシリテーション演習ファシリテーションに関する知識を体験を通して理解する

2011-06-01



人材育成方法のまとめ


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

プラクティスの全てを完全に身につけるより，価値に従って行動する習慣を確実に身につけることが重要

価値

原則

手法

2011-06-01



契約形態に関する検討




各調査事例での契約形態


No. 事例契約方式1 携帯向けブログシステム請負契約（毎月更新）2 共通認証システム請負契約3 プロジェクト管理システム請負契約4 教務Webシステム請負契約5 システム管理ミドルウェア開発請負契約6 株式取引のためのWebアプリケーション請負契約7 プラント監視制御用計算機システム請負契約8 パッケージソフトウェア準委任契約（四半期単位）9 アプリケーションプラットフォーム準委任契約

10 生産管理システム準委任契約11 小売業における業務システム準委任契約12 社内版SNSシステム準委任契約13 OSS版SNSシステム準委任契約14 Webメディア開発準委任契約15 共通EDI開発準委任契約

16 研修運営システム準委任契約（推敲フェーズまで）+請負契約（作成フェーズ以降）

17 検索エンジン開発派遣契約

18 サプライチェーンマネジメントシステムサービスの利用料金がビジネスの基本単位となる、ASP契約

19 携帯ソーシャルゲーム社内開発のため契約なし20 教育機関向け統合業務パッケージ社内開発のため契約なし21 開発案件管理Webアプリケーション社内開発のため契約なし22 アジャイル型開発の支援環境開発社内開発のため契約なし23 製造業向けプロトタイプシステム不明

2011-06-01



調査事例：契約形態の集計

契約の種類件数比率

請負契約６３３．３％

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

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

準委任契約７３８．９％

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

不明２１１．１％

合計１８１００％

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

⇒海外では、直接雇用やTime&Materialの準委任型契約が中心だが、日本では、アジャイル型開発とはなじみにくい請負契約の割合も高い。




ソフトウェア開発で使われる主な契約形態

契約の種類内容

請負契約

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

準委任契約

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

労働者派遣契約

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

解説




契約形態の比較

項目準委託契約請負契約

仕事の完成義務

善良な管理者の注意をもって委託事務を処理する義務

仕事の完成義務は負わない

ベンダは受託業務の完成義務を負う

瑕疵担保責任

事務処理に関し、善良注意義務違反があった場合には、債務責任を負う

成果物に瑕疵があった場合、瑕疵担保責任を負う

注文者は、補修や損害賠償を請求できる

解説




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

事例

顧客側に2週間に1回、必ず受入れ検収を実施できる体制が必要

2週間に1～3度、オーナが来社し、オンサイト・ミーティングを実施

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

週1回、プロジェクトの進捗状況を開発プロジェクトマネージャが発注元のマネージャに報告また、発注元のマネージャ同席の下、適宜、プロダクトマネージャと電話会議を実施

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

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

開発者全員が現地に常駐

調査事例：顧客参画の実態




現状の契約種類(WF型開発）

ソフトウェア開発に関わる契約の種類

①請負契約

②準委任契約

③システム・エンジニアリング・サービス契約（SES契約）

④労働者派遣契約

◆非WF型開発に適した契約形態種類

(Peter Stevensの分析による)

①Sprint Contract（スプリント契約）

②Fixed Price/Fixed Scope （固定価格／固定スコープ）

③Time and Materials （タイム・アンド・マテリアル）④Time and Materials with Fixed Scope and Cost Ceiling

（タイム・アンド・マテリアル固定スコープとコスト上限付）

⑤Time and Materials with Variable Scope and Cost Ceiling

（タイム・アンド・マテリアル変動スコープとコスト上限付）

⑥Phased Development （フェーズ開発）

⑦Bonus/Penalty Clauses （ボーナス／ペナルティ条項）

⑧Fixed Profit （固定利益）

⑨Money for Nothing , Changes for Free

（早期中止、変更無料）

⑩Joint Ventures （ジョイントベンチャ）2011-06-01 Copyright © 2010-2011 IPA, All Rights Reserved.

ソフトウェア開発に関わる契約の種類



新しい契約の試行：デンマークの事例


＜特徴＞

・予算の半分を工数に応じた支払いに充てる（変動費）

・変動費を支払った残り半分を納品が完了した時点で支払う（固定費）

発注側は開発工数変動による費用変動幅が少なくなり、開発側は、開発期間中に最低限の開発費用が回収できるメリットがある。

発注側、開発側双方とも、早く完成させるためのモチベーションが高くなる。一括請負契約や準委任契約のようにどちらか片方だけがリスクを負うような事態が避けられる。

すなわち、発注側と開発側がプロジェクトの成否による利害を共有しており、成功するとどちらも得をするし、失敗するとお互いに損をするという契約モデル。

出典：「アジャイルが大企業に採用されるために解決すべきたったの２つの課題」

2011-06-01



新しい契約の試行：開発費不要の受託開発


＜特徴＞

・開発したシステムを初期費用0円で提供し、その後、顧客がサービス利用料という形で月々システムサービス料を支払う。

・開発したソフトウェアの著作権はサービス会社に帰属する。

・いつでも手数料なしで解約でき、データベースに蓄積された顧客のデータについては、顧客の手元に残る。

＜顧客のメリット＞

・初期投資が不要なため、まとまった資金を調達する必要がない。

・継続してメンテナンスをし続けるので、短期的にリプレイスを繰り返すことなく、システムを長く使える。

・月額費用の中に保守・サポートも含まれる。

・毎月、費用対効果を測定し、効果がなければすぐに止められる。

出典：急増、「開発費不要」の受託開発クラウド活用が普及を後押し（日経コンピュータ2011年4月28日号）

2011-06-01



日本におけるアジャイル型開発にふさわしい契約モデルの提案


契約

（別資料参照）

2011-06-01



適用性評価について


2011年度は，今回提案した契約モデル・契約書（案）を実際

のアジャイル開発案件で使ってもらい，問題点があればその

解を反映して改訂する予定．

・専門家（契約関連の検討委員）の助言が得られる．

・開発内容の秘密は守る．

・レポートを提出するか，ヒアリングに対応して頂く．

ご興味があれば，ご連絡を: [email protected]

2011-06-01



モデル取引・契約書

[準委任型]

[請負型]

[準委任型]

[請負型]

開発手法は、ウォーターフォール型モデルを前提

ウォーターフォールモデル以外の多様な開発モデルに基いた契約のあり方については、今後の検討課題

システム化の方向性

システム化の計画

要件定義システム設計ソフトウェア設計プログラミング

ソフトウェアテスト

システムテスト

運用テスト

企画支援業務要件定義

作成支援業務

外部設計書

作成業務

[準委任型] [準委任型][請負型]

ソフトウェア開発業務システム

テスト業務運用準備移行支援

[準委任型]

契約契約契約契約契約契約

参考

策定：経済産業省（第1版 2007.4）Copyright © 2010-2011 IPA, All Rights Reserved.2011-06-01



目次






6. まとめ




適切な開発モデルの選択

計画性・確実性・安定性変化への適応性・迅速性

開発対象の性質開発組織の環境条件

・システムの深刻度・要件の固まり具合、変化の度合い・開発対象の成熟度

- 新規開発、改造、再構築、保守・アーキテクチャの成熟度・規模の大小

・手法に対する組織の経験、成熟度・手法に対するメンバの慣れ、成熟度・組織の制度、統制・組織の地理的分散・組織の風土- 新しい試みに対する挑戦の空気- 経営/マネジメント層の理解と支援

ウォーターフォール型アジャイル型




アナロジー

国際/業界標準（規格を含む）

組織（企業）標準

技法、ツール特性別（領域別）標準

プロジェクト標準

第１レベル

第２レベル

第３レベル

第４レベル

例）事務処理系，制御系など

修整

修整

修整

修整（テーラリング）の適用について（1／3）

■修整（テーラリング）とは、

標準/モデルをそのまま適用するのではなく、開発対象、組織（企業）やプロジェクトの特性に合わせて、標準/モデルで規定されているプロセスやプラクティスなどを取捨選択したり、部分的に変更したり、繰り返し実行できるように、または複数を一つに括って実行できるように組み替えたりする作業をいう。

例） XP, Scrumなど

＜修整の考え方の例＞2011-06-01 Copyright © 2010-2011 IPA, All Rights Reserved.



アナロジー

●テーラリングのポイント（１）「標準/モデルとして書かれていることをすべてそのまま実

行しなければならない」ということではない。

（２）「標準/モデルとして書かれていること」を、妥当と判断した場合には、省略してもよい。

（必ずしも全ての事項を組織（企業）標準やプロジェクト標準に加えなくてもよい、ということ。）

（３）「標準/モデルとして書かれていないこと」を、組織（企業）標準やプロジェクト標準に追加してもよい。

→ 組織やプロジェクトの特性（例えば二者間契約の内容もその一つ）に合わせて、できるだけ最適と思われる作業の組み立て（「プロセス設計」）を行うために必要な活動が、修整（テーラリング）である。･･･「修整」であり、「修正」ではない！





アナロジー

●もし修整（テーラリング）をしなければ、どうなるのか？

（例）・対象プロジェクトにとって必要でない作業項目が含ま

れ、生産性が低下する。

・プロジェクトメンバの特性（スキル，性格など）と

合わない作業が含まれ、生産性・信頼性が低下する。

・安全性が特に求められるシステムを構築する場合は、

品質保証活動（レビュー／検証／妥当性確認／監査な

ど）が不足することとなり、システムの信頼性につい

て確実な確信が持てなくなる。

→だからこそ、開発対象や組織やプロジェクトの特性に合わせ、適切な修整（テーラリング）が必要となる！





テーラリングの例：定量的品質管理方法(1/8)

i. 品質管理方法の選定

① プロジェクト特性の見極め

評価対象とするプロジェクト特性を特定し、個々のプロジェクト特性要素の評価方法を取り決めておく

② 品質管理レベルの特定

プロジェクト特性要素各々に評価して、品質管理方法を決定するレベルを選択する

③ 品質管理プロセスの設定

選択した品質管理レベルから品質管理方法のテーラリングを行い、プロセスを決定する。

６章

モデルを用いた評価

分析方法と対策の実践例

２章

組織的準備

標準プロセスとガイドラインの整備

３章

目標設定

品質管理方法と目標の設定

４章

測定

品質データの測定と収集

５章

分析・対策

品質分析と対策の実施

＜出典＞

参考


プレゼンター


プロジェクトの特性を表す要素には、売上金額・国益・人命・社会環境・企業経営・利用者の健康・財産、繰り返し開発のプロジェクト、初物の技術を駆使するプロジェクト、マルチベンダが参加するプロジェクト、プロジェクトリスク（短納期、複雑なシステム、有識者が少ない、超高信頼性）など様々なものがある。品質管理方法を選定するには、まず、これら多岐にわたる要素の中から評価対象とするプロジェクト特性要素を特定し、さらに個々のプロジェクト特性要素の評価方法を取り決めておく必要がある。




システムリスク

S1S2S3S4S5

23455P5

23444P4

22333P3

22222P2

11111P1プロジェクトリスク

システムリスク

S1S2S3S4S5

23455P5

23444P4

22333P3

22222P2

11111P1プロジェクトリスク

統合リスク

小

大

大

小

S2システムリスク総合評価（ランク）

・・・・・・・・・・

20102信頼性

30103社会性・公共性

評価重み評価システムリスク

S2システムリスク総合評価（ランク）

・・・・・・・・・・

20102信頼性

30103社会性・公共性

評価重み評価システムリスク

P3プロジェクトリスク総合評価（ランク）

・・・・・・・・・・

824要求納期

551新規／継続

評価重み評価プロジェクトリスク

P3プロジェクトリスク総合評価（ランク）

・・・・・・・・・・

824要求納期

551新規／継続

評価重み評価プロジェクトリスク

事例１：プロジェクト管理プロセスと品質保証（QA)プロセスのテーラリングプロジェクトのリスクを分類して「群」に割り振り、その群単位に順次評価しプロジェクトをランク付けする

社会性・公共性、信頼性、性能等、これから開発するシステムの重さを表す要素群。

開発にあたるプロジェクトが内包するリスク、あるいはプロジェクトが置かれる環境・状況が呈するリスクの大きさを表す要素群

統合リスク

参考


プレゼンター


割り振り方法については、統合リスク評定（ランク）に応じた選択肢のみに制限する必要はない。その組織が有する開発の経験と実績から得た知見を入れて、開発コストその他の選定基準と組み合わせるなど、関係者から管理対象プロセスにかなうとの納得と実感が得られるよう、柔軟な選択肢を用意しておくのが良い。




プロジェクト管理プロセスのテーラリング

作業成果物と設計作業の状況から、プロジェクトの設計品質を評価し開発作業を次工程に進めてよいかどうかを判定するゲートレビューを、統合リスクとコストからテーラリングし、プロジェクト特性に応じた質・量で実施する。

品質保証（QA)プロセスのテーラリング

品質保証（QA）の活動を、統合リスクとコストからテーラリングする。

○事業部として実施○部として実施YY百万円以上

○事業部として実施○事業部として実施ZZ百万円以上開発コスト

○全社として実施○全社として実施統合リスク１、２

○部として実施ーXX百万円以上

製造開始可否判定詳細設計開始可否判定

○事業部として実施○部として実施YY百万円以上

○事業部として実施○事業部として実施ZZ百万円以上開発コスト

○全社として実施○全社として実施統合リスク１、２

○部として実施ーXX百万円以上

製造開始可否判定詳細設計開始可否判定

・「標準QA」は、業務規程に照らしたプロジェクト監視を主体に品質保証する

・「CL」は、プロジェクト個別に作成したチェックリストを使用して品質保証する

・「V2」は、成果物の検証および妥当性確認を品質保証部署独自に実施する

標準QA+CL+V2標準QA+CL標準QA５

標準QA+CL+V2標準QA+CL+V2標準QA４

標準QA+CL+V2標準QA+CL+V2標準QA+CL３

標準QA+CL+V2標準QA+CL+V2標準QA+CL+V2１、２統合リスク

YY百万円以上XX百万円以上XX百万円未満

開発コスト

・「標準QA」は、業務規程に照らしたプロジェクト監視を主体に品質保証する

・「CL」は、プロジェクト個別に作成したチェックリストを使用して品質保証する

・「V2」は、成果物の検証および妥当性確認を品質保証部署独自に実施する

標準QA+CL+V2標準QA+CL標準QA５

標準QA+CL+V2標準QA+CL+V2標準QA４

標準QA+CL+V2標準QA+CL+V2標準QA+CL３

標準QA+CL+V2標準QA+CL+V2標準QA+CL+V2１、２統合リスク

YY百万円以上XX百万円以上XX百万円未満

開発コスト

参考


プレゼンター





事例２：レビュープロセスのテーラリング

個々のレビュー対象成果物に対して、特徴に応じたレビュープロセスをテーラリング【対象成果物】

設計ドキュメント（要件定義書、基本設計書、外部仕様書、内部仕様書、運用マニュアル等）

【レビュー実施手順選択に用いる成果物特徴】

成果物サイズ（A４換算ページ数）

成果物の重要度（重要／通常、レビュー責任者が判断する）

非熟練者（開発経験２年未満の者など）が担当した成果物のレビュー実施手順を別途定める。

【レビュー実施手順の構成項目】（ △選択、 ◎必須）

部分レビュー： △ 急ぎ過ぎを防ぐため、ミーティング１回でレビューする量を制限する。

自己チェック： ◎ 作成基準違反、誤字脱字、体裁の乱れ、あいまい表現をチェックし是正する。

概要説明： △ レビューアに対し、レビュー実施に必要な情報を提供し質問に答える。

レビュー手法： ◎ 個人レビュー／ウォークスルー／チームレビューを組み合せる。

レビューツール： △ 観点の特定／チェックリストの整備を事前に行い適用する。

レビュー記録： ◎ 所定の記録項目を記録し保管する。

レビュー分析： ◎ レビューが効果的・効率的に実施できたかどうかを振り返り改善する。

参考





手順１）品質管理レベルの評価

成果物サイズ（大／小）と重要度（重要／通常）を組み合せた４区分（非熟練者分を含めると６区分）で管理レベルを評価する。

手順２）管理方法の選択

成果物特徴に応じて負担軽重に配慮したドキュメントレビュー実施手順を選択する

B-2B-1通常部分

(C-2)(C-1)（非熟練者）

A-2A-1重要部分成果物の重要度

小目安：10頁((A4)以下

大目安：11頁(A4)以上

成果物のサイズレビュー

実施手順

B-2B-1通常部分

(C-2)(C-1)（非熟練者）

A-2A-1重要部分成果物の重要度

小目安：10頁((A4)以下

大目安：11頁(A4)以上

成果物のサイズレビュー

実施手順

――――△△概要説明

○○○○○○レビュー分析

○○○○○○レビュー記録

――○○○○チェックリスト

――○○○○特定観点ツール

――△△○○チームレビュー

△△――――ウォークスルー

○○○○○○パスアラウンド

○○○○――ピアデスクチェック

個人レ

ビュー

レビュー手法

○○○○○○自己チェック

―（推奨）○

―（推奨）○

―（推奨）○部分レビュー

212121サイズ（1大>10頁, 2小<=10頁）

CBA重要度（A重要,B通常,C非熟練者）

――――△△概要説明

○○○○○○レビュー分析

○○○○○○レビュー記録

――○○○○チェックリスト

――○○○○特定観点ツール

――△△○○チームレビュー

△△――――ウォークスルー

○○○○○○パスアラウンド

○○○○――ピアデスクチェック

個人レ

ビュー

レビュー手法

○○○○○○自己チェック

―（推奨）○

―（推奨）○

―（推奨）○部分レビュー

212121サイズ（1大>10頁, 2小<=10頁）

CBA重要度（A重要,B通常,C非熟練者）

参考


プレゼンター


インスペクション：もっとも厳格で体系的、公式に実施されるレビューチームレビュー：軽量化されたインスペクション。構造化されているがインスペクションほど公式、厳格でない。ピアデスクチェック：ペアレビューとも呼ばれ、作業者以外はただ一人だけが作業成果物を調べる個人レビュー　　　パスアラウンド：作成者が成果物のコピーを複数人に配布し、複数のコメント・フィードバックを獲得する方法　　　ウォークスルー：作成者が主導して実施されるレビュー。作成者自らが対象成果物内容を説明することで実施する。



テーラリングの例：定量的品質管理方法(6/8)【凡例】必須

レビュー責任者が要否判断

【凡例】必須


【凡例】必須


レビュー

承認Ｘｘｘ設計

作成審査

自己ﾁｪｯｸ

承認

ﾚﾋﾞｭｰ

Ａ-１：重要部分の大量成果物のレビュー実施手順

個人

ﾚﾋﾞｭｰ

ﾁｰﾑ

ﾚﾋﾞｭｰ概要説明

１００％１００％Ｎ％(ex.機能単位)

１００％

個人

ﾚﾋﾞｭｰ

ﾁｰﾑ

ﾚﾋﾞｭｰ個人

ﾚﾋﾞｭｰ

ﾁｰﾑ

ﾚﾋﾞｭｰ

概要説明

レビュー

承認Ｘｘｘ設計承認Ｘｘｘ設計

作成審査

自己ﾁｪｯｸ

承認

ﾚﾋﾞｭｰ

Ａ-１：重要部分の大量成果物のレビュー実施手順

個人

ﾚﾋﾞｭｰ

ﾁｰﾑ

ﾚﾋﾞｭｰ

個人

ﾚﾋﾞｭｰ

ﾁｰﾑ

ﾚﾋﾞｭｰ概要説明概要説明

１００％１００％Ｎ％(ex.機能単位)

１００％

個人

ﾚﾋﾞｭｰ

ﾁｰﾑ

ﾚﾋﾞｭｰ

個人

ﾚﾋﾞｭｰ

ﾁｰﾑ


ﾚﾋﾞｭｰ

ﾁｰﾑ

ﾚﾋﾞｭｰ

個人

ﾚﾋﾞｭｰ

ﾁｰﾑ

ﾚﾋﾞｭｰ

概要説明概要説明


作成

レビュー

審査

１００％

自己ﾁｪｯｸ

個人

ﾚﾋﾞｭｰ

承認

ﾚﾋﾞｭｰ

Ａ-２：重要部分の少量成果物のレビュー実施手順

ﾁｰﾑ



作成

レビュー

審査

１００％

自己ﾁｪｯｸ

個人

ﾚﾋﾞｭｰ

承認

ﾚﾋﾞｭｰ

Ａ-２：重要部分の少量成果物のレビュー実施手順

ﾁｰﾑ


参考


プレゼンター







【凡例】必須


【凡例】必須



作成

レビュー

審査

１００％

自己ﾁｪｯｸ

個人

ﾚﾋﾞｭｰ

承認

ﾚﾋﾞｭｰ

Ｂ-１：通常部分の大量成果物のレビュー実施手順

１００％１００％Ｎ％(ex.機能単位) ﾁｰﾑ

ﾚﾋﾞｭｰﾁｰﾑ


ﾚﾋﾞｭｰ

個人


ﾚﾋﾞｭｰ


作成

レビュー

審査

１００％

自己ﾁｪｯｸ

個人

ﾚﾋﾞｭｰ

承認

ﾚﾋﾞｭｰ

Ｂ-１：通常部分の大量成果物のレビュー実施手順

１００％１００％Ｎ％(ex.機能単位) ﾁｰﾑ

ﾚﾋﾞｭｰ

ﾁｰﾑ


ﾚﾋﾞｭｰ

ﾁｰﾑ


ﾚﾋﾞｭｰ

ﾁｰﾑ

ﾚﾋﾞｭｰ

個人


ﾚﾋﾞｭｰ


作成

レビュー

審査

１００％

自己ﾁｪｯｸ

個人

ﾚﾋﾞｭｰ

承認

ﾚﾋﾞｭｰ

Ｂ-２：通常部分の少量成果物のレビュー実施手順

ﾁｰﾑ

ﾚﾋﾞｭｰ


作成

レビュー

審査

１００％

自己ﾁｪｯｸ

個人

ﾚﾋﾞｭｰ

承認

ﾚﾋﾞｭｰ

Ｂ-２：通常部分の少量成果物のレビュー実施手順

ﾁｰﾑ

ﾚﾋﾞｭｰ

参考


プレゼンター







【凡例】必須


【凡例】必須



作成

レビュー

審査

１００％

自己ﾁｪｯｸ

個人

ﾚﾋﾞｭｰ

承認

ﾚﾋﾞｭｰ

Ｃ-１：（非熟練者が担当する）大量成果物のレビュー実施手順

１００％１００％Ｎ％(ex.機能単位) ｳｫｰｸ

ｽﾙｰ個人


ﾚﾋﾞｭｰ

ｳｫｰｸｽﾙｰｳｫｰｸｽﾙｰ


作成

レビュー

審査

１００％

自己ﾁｪｯｸ

個人

ﾚﾋﾞｭｰ

承認

ﾚﾋﾞｭｰ

Ｃ-１：（非熟練者が担当する）大量成果物のレビュー実施手順

１００％１００％Ｎ％(ex.機能単位) ｳｫｰｸ

ｽﾙｰ個人


ﾚﾋﾞｭｰ

ｳｫｰｸｽﾙｰｳｫｰｸｽﾙｰｳｫｰｸｽﾙｰ


作成

レビュー

審査

１００％

自己ﾁｪｯｸ

個人

ﾚﾋﾞｭｰ

承認

ﾚﾋﾞｭｰ

Ｃ-２：（非熟練者が担当する）少量成果物のレビュー実施手順

ｳｫｰｸｽﾙｰ


作成

レビュー

審査

１００％

自己ﾁｪｯｸ

個人

ﾚﾋﾞｭｰ

承認

ﾚﾋﾞｭｰ

Ｃ-２：（非熟練者が担当する）少量成果物のレビュー実施手順

ｳｫｰｸｽﾙｰ

参考


プレゼンター





アジャイル型開発のスイートスポット（１）

システム規模・ 0．．１２．．３００（開発メンバー数）

深刻度・シンプル、経済被害、．．．人身事故

システムの成熟度・新規開発、レガシー保守

要件の変化率・低、中、高

ビジネスモデル・自社開発、オープンソース、．．．

アーキテクチャ・安定、変化した、新しい

チームの分散・一か所、．．、オフショア、外部委託

統制・単純なルール、．．．、SOX、．．．

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


参考

2011-06-01



アジャイル型開発のスイートスポット（２）

通常は，JavaまたはC#の環境で，組込みではなくウェブアプリケーションを，最終的なエンドユーザや実際の顧客とかなり近い環境で開発するところ．

チームの大きさはふつう，かなり小さく，すべてで12人にも満たない．しかし，大きなチームでの経験も蓄積され続けている．チームの中には他の場所にいるメンバもいるかもしれないが，チームの中核はエンドユーザのかなり近くで仕事をする．

まだ開発が始まっていないプロジェクトよりも，既存のシステムの方が簡単にアジャイル型開発を適用できる．重要なのは，新しいプロジェクトでも既存のシステムでもアジャイル型で開発するための十分な経験が蓄積されているということ．

アジャイル型開発のスイートスポットには好循環が存在し，多くの経験が多くの成功をもたらし，その成功がまた経験を得る機会を生み出す．

出典「アジャイルの限界」(作者:Alan Kelly, 翻訳者:徳武聡, 投稿日;2010年8月17日)http://www.infoq.com/jp/articles/limits-of-agile


参考

2011-06-01



アジャイル型開発手法の導入拡大の障壁（海外）

45% 44%42%

32%

23% 22%

17%14%

10%

0%

5%

10%

15%

20%

25%

30%

35%

40%

45%

50%

組織文化の

変化能力

変化への

一般的な抵抗

アジャイル

経験者不足

マネジメントの

支援

プロジェクトの

複雑さ

･

規模

顧客の協力

規模拡大への

対応の自信

移行までに

許される時間

予算の制約

１．組織文化の変化能力２．変化への一般的な抵抗３．アジャイル経験者不足


参考




アジャイル型開発プロジェクトの失敗理由（海外）

23%21%

13% 12% 11%

8% 7%5%

0%

5%

10%

15%

20%

25%

企業哲学又は

文化との相性

手法への不慣れ

その他

従来型開発採用

への外部圧力

チーム内での

反発

文化的な移行の

欠如

マネジメントの

支援の欠如

不十分な

トレーニング

１．企業哲学・文化との相性２．手法への不慣れ


参考




目次






6. まとめ




まとめ


検討の背景、目的を述べ、そのコンテキストの中で「非ウォーターフォール型開発」および「アジャイル開発」を定義した。

検討WGでは、現在の日本の産業構造の問題点を認識した上で、日本のソフトウェア競争力を高めるために、および、エンジニアがいきいきと働ける環境を作るために、非ウォーターフォール型開発手法を位置づけたいと考えている。

アジャイル開発はすべての領域で最も優れた手法である、という立場はとっていない。アジャイル開発には得意領域があり、その領域が現代の不確実性の高いビジネス環境の中で日々に拡大しているという認識である。

経営層への理解浸透が、次の一歩への大きな要素であるという認識から、企業情報システム開発における考え方のパラダイムシフトの意義を考察し、アジャイルへの懸念事項とともにまとめた。

わが国におけるアジャイル開発にふさわしい契約のモデルと契約書２種を提案した。

2011-06-01



アジャイル型開発手法への期待：ビジネス面

これからの時代が要求するパラダイムに対応できるソフトウェア開発手法

✓経営環境の変化に対し、スピーディに柔軟に対応- 製品の高速開発、部分製品の逐次開発によって、

早期に市場へ投入、投資効果を享受しつつ、価値を逐次向上する手法

✓「生きたシステム」への対応- 開発中や運用後に生起する要件の変更、使い勝手の調整- 安心・安全への対応のための逐次改良

✓ソフトウェア開発のグローバルな競争- グローバル・ユーザ、グローバル・ワーカ／サプライヤをマネージ

できる組織的能力、人材を支えるソフトウェア・エンジニアリング




アジャイル型開発手法への期待：「人」の面

やりがいを持って生き生き働ける職場へ

✓アジャイル開発は、一人ひとりの開発者が

やりがいと働きがいを感じられる

✓意欲ある人材、優秀な人材が集まる職場へ

✓日本の多重下請けなどの産業構造を転換する

可能性も秘めている




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

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

適切な開発手法を選択する・新たに考案する

プラクティスの活用-それぞれのプロジェクト・組織(企業)で、自らの開発に

合った方法を、プラクティスを選択あるいは参考にして利用する

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

についても理解を深める


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

2011-06-01



プロセスとプラクティス


アクティビティタスク

＜プロセスの構成＞

What-to-do (何をするか)を表す．

参考

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

Scrum ・スプリントバックロググラフの作成・自律的な組織化チーム・スクラムミーティング・1日以内の障害除去・共通の部屋・日次ビルド・スプリントレビ

How-to-do (どのようにするか)を表す．

＜プラクティスの例＞

全く異なる観点2011-06-01



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


「プロセス」重視「人」重視

出典 Kieran Conboy, Sharon Coyle, Xiaofeng Wang, Minna Pikkarainen:”People Over Process: Key People Challenges in Agile Development”, IEEE Software, July 2010.

参考

プロジェクト要素従来型開発アジャイル型開発

管理「プロセス」重視「人」重視

マネジメントスタイル指揮統制型リーダーシップ・協力型

知識の管理明示暗示

役割個人

→専門化を好む

自己組織チーム

→役割の相互入れ替えを推奨

コミュニケーションフォーマルで、必要な時のみインフォーマルで、継続的

顧客の関与重要だが、通常はプロジェクトの分

析段階においてのみ

必須で、継続的

プロジェクトサイクル業務や活動主導製品特性主導

文化が異なる

…

2011-06-01



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


参考

プロジェクト要素従来型開発アジャイル型開発

開発モデルライフサイクルモデル

（ウォーターフォール、スパイラル、ま

たはこれらのバリエーション）

進化型成果モデル

望まれる組織形態/構

造

機械的（官僚的で、形式重視）

有機的（柔軟性、参加性に富み、

協力しあう社会的活動を推奨）

テクノロジー制約なし目標指向のテクノロジーが好まれる

チーム配置分散型主体連動型主体

チームサイズ多くの場合で 10 人を超える通常は 10 人以下

継続ラーニングあまり推奨されない積極的に採用される

マネジメント文化指揮統制型対応型

チーム参加必須でない必須

プロジェクト・プラニング管理職主導継続的

フィードバックの仕組み獲得困難通常数多く存在

文書化相当量最小限

2011-06-01



異文化の協働によるプロセス・イノベーション

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

パフォーマンス

アクティビティ

ウォーターフォールアジャイル

プロセス改善プロセス改善

ウォーターフォールとアジャイルとの協働により，プロセス・イノベーションを！




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


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

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

イノベーションの意味は，仕組みや社会制度の革新も含まれる．

全く新しい技術や考え方を取り入れて新たな価値を生み出し，

社会的に大きな変化を起こすことである．

（1911年，経済学者・シュンペーター）

2011-06-01

http://homepage1.nifty.com/bicycletour/sci-rep.priv.InnovateAmerica.htm�



氏名所属

主査松本　吉弘財団法人京都高度技術研究所顧問

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

大槻　繁株式会社一コンサルティンググループ副社長

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

田澤　久楽天株式会社開発ユニット開発環境整備課課長

戸村　元久株式会社NTTデータ技術開発本部プロジェクトマネジメント・イノベーションセンタセンタ長

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

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

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

古川　正伸株式会社東京証券取引所品質管理部課長

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

馬嶋　宏株式会社日立製作所情報システム事業部方式設計センタ

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

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

和田　憲明富士通株式会社システム生産技術本部SI生産革新統括部 SDEM推進部

エキスパート伊久美　功一 IPA/SEC専門委員／元IPA/SEC研究員

オブザーバ鴨田　浩明経済産業省


非ウォーターフォール型開発に関する検討委員（1/4）






開発モデルPT

氏名所属

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

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

戸村　元久株式会社NTTデータ技術開発本部プロジェクトマネジメント・イノベーションセンタセンタ長

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


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

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

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


エキスパート伊久美　功一 IPA/SEC専門委員／元IPA/SEC研究員2011-06-01



技術・スキルPT

氏名所属

リーダ松島　桂樹武蔵大学経済学部教授

委員天野　勝株式会社永和システムマネジメントコンサルティングセンターセンター長

川端　光義アジャイルウェア代表

児玉　公信株式会社情報システム総研取締役副社長／モデラー

田澤　久楽天株式会社開発ユニット開発環境整備課課長

馬嶋　宏株式会社日立製作所情報システム事業部方式設計センタ






契約問題PT

氏名所属

リーダ前川　徹サイバー大学 IT総合学部教授

委員飯塚　顕治新日鉄ソリューションズ株式会社法務・知財財産部法務グループシニアマネージャー

高橋　雅宏アジャイルプロセス協議会見積・契約ワーキンググループ

板東　直樹アップデートテクノロジー株式会社代表取締役社長

平野　高志ブレークモア法律事務所弁護士


エキスパート梅本　大祐 IPA/SEC専門委員／ブレークモア法律事務所弁護士

オブザーバ鴨田　浩明経済産業省

葛山　弘揮経済産業省

下田　裕和経済産業省

柳橋　祥人経済産業省

新保　康夫日本コンピューター・システム株式会社事業推進本部

鈴木　律郎社団法人情報サービス産業協会企画調査部

茂木　智美社団法人情報サービス産業協会企画調査部／審査業務部





ご協力頂きたい事項


契約

番外

2011-06-01



１．契約モデル案のアンケート評価


公開されている契約モデル・契約書案について、ご契約担当の方や法務部門の方に、

① 自社で採用可能かどうか

② そのままでは採用できないとしたら、契約書案のどこが受け入れられないか

③ 採用できるようにするためには、契約書案のどこをどのように修正すれば良いか

等に関してご検討いただき、ご意見を別添EXECLファイル「モデル契約書案の妥当性評価」にご記入いただきたい。

期限：7月25日(月)

返信先： [email protected]

いただいたご意見は、IPA/SECにおいて、契約モデル・契約書案の改訂のために活用予定。

契約

番外

2011-06-01



アンケート評価の評価項目


自社における契約書案採用の可否

契約書案に対する全体を通しての評価

契約書案で受入れ難い箇所（箇条・項番号も明示願います）

契約書案で変更すべき箇所と変更内容とその理由（箇条・項番号も明示願います）（必須／可能ならば／等のレベルも付記願ます）契約書案に関するその他のコメント（箇条・項番号も明示願います）

契約書案以外に対する関連コメント（アジャイル型開発における契約に関する全般的なご意見がございましたら，こちらにまとめて記載願います．）

契約

番外

2011-06-01



２．契約モデル案実証実験への参加

基本/個別契約モデル

組合モデル

IPAからの提案

実プロジェクトでの適用（今回のご相談）

フィードバック

適用

フィードバック

非ウォーターフォール型開発WG契約問題PT

適用

助言ユーザ

契約

※実証実験で調査したい内容

・実契約での変更点の把握

・契約後の課題の把握

・契約モデルを受け入れられない理由

など

契約モデルの改訂募集

ベンダ

WG委員所属企業を紹介

＜契約モデル案実証実験の概要＞

契約

番外




実証実験における条件


契約モデル・契約書案を実際のアジャイル開発案件で使って

もらい，問題点を抽出すると共に，解決策を検討する．

・ベンダ（IPA/SECの検討参加委員の所属企業）を紹介．

・専門家（契約関連の検討委員）の助言が得られる．

・開発内容の秘密は守る．

・開発費は参加企業が負担．

・レポートを提出するか，ヒアリングに対応して頂く．

契約

ご興味のある方はご連絡いただきたい。

連絡先： [email protected]

番外

2011-06-01



●ご質問、ご意見は、ＳＥＣホームページからお願い致します。


ご質問・ご意見の宛先



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


報告書公開中http://sec.ipa.go.jp/reports/20110407.html

2011-06-01

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

128Software Engineering Center

Information-technology Promotion Agency, Japan

SoftwareEngineeringCenter

アジャイル開発にふさわしい契約モデルの紹介

IPA/SEC専門委員

ブレークモア法律事務所

弁護士梅本大祐

2011.4.15 版

契約




主催： IPA / SEC（独立行政法人情報処理推進機構

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

目的：非WF型開発の適用に適した領域を見定め、その活用を促進

設置されたPT：

開発モデルPT（アジャイルの定義）

技術スキルPT（アジャイルの技術、人材等）

契約問題PT（アジャイルに適した契約）


契約2011-06-01



WF型開発と比較したアジャイル開発の特徴

ユーザとベンダの緊密な協力体制が必須

- 相手方の問合せへの迅速な応答

- 担当作業の迅速な実施

- ユーザ/ベンダ間の責任分担が不明確になりがち

ユーザ要求の詳細が契約時点では未確定

- 何を作るか決まっていない（成果物未定）

- 性能・品質等が不明確

- 工数見積りが困難（コスト未定）

開発途中でのユーザ要求の変化を柔軟に受け入れる必要

- 決定した事項も変更されることがある


契約2011-06-01



アジャイル開発と契約の対立

契約合意内容を固定して、当事者を法的に拘束する

アジャイル開発変化に対応すべく、合意内容の変更を柔軟に認め、当事者をなるべく拘束しない

⇒アジャイル開発にはふさわしい契約とは?


契約2011-06-01



で、契約の起こる可能性がある場所を示す。同一の組織内の場合は、契約はない。

契約には、請負契約や準委任契約等の種類がある。

契

使う人

提供する人

作る人

作る人2

保守する人

契

契

契

契補佐

する人

契

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

今回の検討対象今回の

検討対象


発注者/ユーザ

受注者/ベンダ

契約

参考

2011-06-01

プレゼンター


・使う人 ⇒ システムを実際に使用する人（システムの利用者、エンドユーザー）。・提供する人　⇒　開発されたシステムやサービスを、使う人に提供する人。・作る人　　　⇒　システムの開発者　　　　　　　　　・作る人2　　⇒　作る人の会社と契約している、作る人と一緒に開発する人。（作る人の会社とは別会社が多い）・保守する人　⇒　リリースされたシステムを保守する人。（作る人と重なることが多い）・補佐する人　⇒　アジャイル開発の進め方等で、開発プロジェクトを支援する人。（コンサルタントやファシリテーターが多い）



システム開発において主に使われる契約類型 -請負契約と準委任契約

請負契約（民法632条～642条）

一方が仕事を完成させることを請負い、その相手方が完成した仕事に対して報酬を支払うことを約束する契約。

⇒契約時点で、ベンダが完成すべき仕事の内容を明確にしておく必要。

準委任契約（民法643条～656条）

事務処理を目的とする契約であり、仕事の完成を目的としない。ベンダは、善良な管理者の注意をもって、委任された事務を処理する義務（善良管理者注意義務）を負う。

⇒ベンダに完成義務がなく、ユーザにとって不安。

契約



アジャイル開発には、どんな契約がふさわしいのか?

開発内容が決まっていない段階で、開発プロジェクト全体に

つき、一つの請負契約を結ぶのは適切ではない（何をいくら

で完成させるか不明）。

他方、開発プロジェクト全体を準委任契約にすることは、ベ

ンダが完成義務を負わない点で、ユーザ側に不安がある（た

とえ成果物が完成しなくても、ユーザは対価を支払う必要）。

また、アジャイル開発の特徴であるユーザとベンダの協働関

係を、契約に取り入れる必要がある。


契約2011-06-01



契約問題PTで検討された契約モデル案

基本/個別契約モデル：

プロジェクト全体に共通する事項につき、基本契約を締結し、

小さな機能単位ごとに、開発対象と費用がある程度確定し

たタイミングで個別契約（請負/準委任）を順次締結する。

組合モデル：

ユーザとベンダが共同でジョイント・ベンチャーとしての組合を

組成し、協力してシステム開発（収益性のあるもの）を企画・

製作する（開発された成果から得られた収益は、ベンダと

ユーザに分配される）。


契約2011-06-01



基本/個別契約モデルの構成

全体構成

プロジェクト全体に共通する事項を定めた基本契約を締結

した上で、個別の機能開発の内容について協議を行い、開

発対象が確定し次第、（例えばリリース単位の開発対象機

能群をまとめて）順次、個別契約（請負契約/準委任契約）

を締結する。


契約2011-06-01



基本/個別契約モデルの概要（１）

企画

システム運用


第１反復

テスト

開発

要求

第ｎ反復

テスト

開発

要求・・・

第1リリース

第１反復

テスト

開発

要求

第ｎ反復

テスト

開発

要求・・・

第2リリース

第１反復

テスト

開発

要求

第ｎ反復

テスト

開発

要求・・・

第mリリース

基本契約

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

企画

システム運用


第１反復

テスト

開発

要求

第１反復

テスト

開発

要求

第ｎ反復

テスト

開発

要求

第ｎ反復

テスト

開発

要求・・・

第1リリース

第１反復

テスト

開発

要求

第１反復

テスト

開発

要求

第ｎ反復

テスト

開発

要求

第ｎ反復

テスト

開発

要求・・・

第2リリース

第１反復

テスト

開発

要求

第１反復

テスト

開発

要求

第ｎ反復

テスト

開発

要求

第ｎ反復

テスト

開発

要求・・・

第mリリース

基本契約

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


契約

基本契約

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

2011-06-01



基本/個別契約モデルの概要（２）

要件定義

設計

実装

テスト

導入

WF開発における基本/個別契約モデル

開発対象機能群１time

フェーズごとに

個別契約を締結

開発対象機能群２

開発対象機能群３

開発対象機能群４

開発対象機能群ｎ

アジャイル開発における基本/個別契約モデル

time

開発対象機能群ごとに個別契約を締結

（経済産業省情報システム・モデル取引契約書など）


契約2011-06-01



基本/個別契約モデルのポイント（１）

ユーザとベンダの緊密な協力体制の確保

- 相互協力の義務付け（基本契約5条）

相手方への協力義務違反⇒法的責任

- 頻繁な連絡協議会の開催（基本契約6条）

開発機能の内容検討のほか、プロジェクト全体/個別開

発の進捗管理、リスク・問題点の検討を行い、必要事項

を決定

定期開催 + 一方当事者の要求では随時開催

連絡協議会外でも問い合わせには迅速に対応


契約2011-06-01



基本/個別契約モデルのポイント（２）

スピーディーな意思決定の実現

- 個別契約における決定事項は別紙に集約（個別契約の別

紙参照）

別紙記載の項目を取り決めればよい

- 連絡協議会による決定（基本契約6条）

契約書に記載がない事項は連絡協議会で決定

連絡協議会での決定事項は、議事録に記載して証拠化

議事録のみなし承認


契約2011-06-01



基本/個別契約モデルのポイント（３）

決定事項の事後的な変更を許す

- 変更協議による決定事項の事後的変更（基本契約4条）

一旦決定した事項（連絡協議会での決定、個別契約での

合意）を変更する必要があれば、変更協議で誠実に協議

する

一方当事者が変更協議を求めた場合、相手方は応じなけ

ればならない

変更協議が調わないまま一定期間が経過した場合には、

個別契約を終了できる


契約2011-06-01



組合モデルの構成

全体構成

システム開発プロジェクトにおいて、ユーザは資金を、ベン

ダ（複数社も可）はプロマネ要員を出し、一つのシステムを

ユーザとベンダの企業が共同で企画・製作するための組織

－共同企業体－を作り、開発を行うモデル。スキームとし

ては，民法上の組合（任意組合）を用いている。

組合モデルでは、システム開発プロジェクトのコーディネート

とプロジェクトマネジメントのみを組合が担当し、具体的な

開発作業は、組合がベンダに委託して行う。


契約2011-06-01



組合契約とは

民法第667条（組合契約）

1 組合契約は、各当事者が出資をして共同の事業を営むこ

とを約することによって、その効力を生ずる。

２出資は、労務をその目的とすることができる。


契約2011-06-01



組合モデルの概要

組合

組合契約（製作管理と成果管理を規定する）

成果物の企画スケジュール・予算管理

知的財産管理成果物の収益分配

利害関係者との権利調整組合員の倒産、脱退、

清算

ベンダ業務執行組合員

ユーザ製作に関わる資本出資

ベンダ

ユーザ業務執行組合員

組合-ベンダ間の開発契約は基本/個別契約モデルの個別契約を利用する。

イテレーション単位で成果物を納品

ベンダ製作に関わる労務出資

（本例では

同一主体）

投資家製作に関わる資本出資

投資家組合員


契約

(本例では，管理分のみ)

(実際の開発分について)

2011-06-01



組合モデルのポイント

組合契約による、共同事業のパートナーとしての協働体制

（契約1条）

ベンダは技術・知識を持ったスタッフの労務を、ユーザは資

金を、それぞれ出資（4条）

開発の成果から収益が得られた場合は、出資比率に応じて

分配（7条）

連絡協議会によるプロジェクト運営・管理（10条）、変更協

議（11条）

具体的な開発は、組合からベンダに委託（5条）


契約2011-06-01



組合モデルの課題

組合モデルの契約は試案であり、改善の余地が大きい。例

えば下記の点などが、未検討事項として残されている。

組合を適切に運営するための組織体制（組合内部の運

営に関する規定等）

組合をスムーズに解散するための処理

税務・会計上の処理

開発の成果を事業化する場合の、他のスキーム（会社）

への移行処理


契約2011-06-01



今後のさらなる改善に向けて

アジャイル開発の「自由さ」を損なわない契約

いまだ信頼関係が十分でない「初めての相手」とも安心して

アジャイル開発を行える契約、契約内容の運用ガイドライン

☆より使いやすい契約にするためには、現場からのフィードバッ

クが必須です！


契約

「モデル取引・契約書」（経産省）への提案

2011-06-01



契約書ひな型（MS-Word形式）のダウンロード


http://sec.ipa.go.jp/reports/20110407.html

MS-Word形式の契約書案のダウンロード可

2011-06-01



おわり

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

参考： IPA 非WF型開発WG報告書（契約書モデルのMS Word版もDL可能）http://sec.ipa.go.jp/reports/20110407.html


契約2011-06-01

http://sec.ipa.go.jp/reports/20110407.html�



各種知識体系等におけるアジャイル開発の取込み


付録

CMMIバージョン1.3へのアジャイル開発の反映アジャイルに関する導入ガイドラインと導入における注意、どのようにアジャイル・プラクティスを解釈すべきかを含む．また，ユーザーストーリー，プロダクトバックログ，ストーリーカード，ペアプログラミング，日次（頻繁な）ビルド，ふりかえり，等のプラクティスにも言及．

米国PMI（PMBOK発行）の中に，Agile Community of Practiceを設立（2009年）PMIはアジャイル認証パイロットを5月から開始すると発表（2011年）

プロジェクトマネジメント(PM)におけるアジャイル開発のマネジメントは日々重要さを増しており，多くのPM専門家が仕事に使えるアジャイル技術を習得したいと熱望．プロジェクト経営環境におけるこのような変化への対応のため，PMIが導入を決定．

IIBAがBABOKアジャイル拡張版を発表（2010年）ビジネスアナリシスの中核的活動である，「エンタープライズアナリシス」，「要求アナリシス」，「リューションのアセスメントと妥当性確認」を含めた知識エリア全体にアジャイル開発の考えを反映．

BABOK Version3.0に知識エリアの全体構造の再構想を含めたアジャル開発への対応を計画（2011年4月以降）

2011-06-01

アジャイル型開発を適切に採り入れるために -...

Documents