非ウォーターフォール型開発の課題と対策を知る！ …software engineering...

Software Engineering Center

Information-technology Promotion Agency, Japan

Software Engineering Center

非ウォーターフォール型開発の課題と対策を知る！

SODEC 2012 IPAブースセミナー

技術本部ソフトウェア・エンジニアリング・センター柏木雅之

SEC Software Engineering for Mo･No･Zu･Ku･Ri

Software Engineering Center 1

アジャイル型開発の動向

メインストリームとなったアジャイル型開発 (米国)

出典：米フォレスターリサーチ社の調査データに基づき作成

米フォレスター・リサーチ社の調査によると、調査したIT技術者のうち、45%が

アジャイル手法を使っていると回答。

前年度の同調査では、35％だった。 (出典：Forrester Research Inc.)

アジャイル関連のツールベンダのVersionOne社の調査では、自社の中でア

ジャイルを採用しているチーム数を聞いたところ、回答者のうち2/3 以上が、自社において3つ以上のチームでアジャイルを実践していると回答。（出典: VersionOne社 2011 State of Agile Development Survey Results）

参考

14% 17%26%

35%

45%

0%

25%

50%

75%

2005 2006 2007 2008 2009



2009年度 2010年度 2011年度

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

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

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

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

実証/模擬実験（契約形態）

中大規模開発事例調査

海外普及要因調査 (5月公開予定)

IPA/SECの取り組み

2009年度： http://sec.ipa.go.jp/reports/20100330a.html 2010年度： http://sec.ipa.go.jp/reports/20110407.html 2011年度： http://sec.ipa.go.jp/reports/20120326.html (契約書案改訂)

http://sec.ipa.go.jp/reports/20120328.html (中大規模事例)

※ 海外普及要因調査公開準備中(2012・5月末公開予定)

研究会報告書

WG報告書 WG報告書

調査報告書

調査報告書

調査報告書

事例収集(1)

課題抽出課題検討検証・改善

事例収集(2)

提案

【報告書公開中】

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


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









アジャイル型開発の特徴

アジャイル型開発は、

顧客の参画の度合いが強い

動くソフトウェアを成長させながら作る

反復・漸進型である

人と人のコミュニケーション、コラボレーションを重視する

開発前の、要求の固定を前提としない

という特徴を持つ。

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



適用領域

アジャイル開発が得意とし、その適用により効果を挙げている領域：

①ビジネス要求が変化する領域

• 要求の変化が激しく、あらかじめ要求が固定できない領域。

②リスクの高い領域

• 不確実な市場を対象としたビジネス領域（市場リスク）

• 技術的な難易度が高い開発領域（技術リスク）

③市場競争領域

• 他社に先駆けた製品・サービス市場投入が命題であり、

TTM（Time to Market：市場投入期間）の短縮が優先となる領域（Webのサービス、パッケージ開発、新製品開発）



試行領域

アジャイル開発による経験が十分には蓄積されておらず、現在、チャレンジと創意工夫が求められている領域：

①大規模開発

• 開発者10人程度を超えると、システム分割、チーム分割が必要。その分割方法、及び、分割されたチーム間のコミュニケーションが課題。

②分散拠点（オフショア含む）開発

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

③組織（会社）間をまたぐ開発チームによる開発

• 共通のビジネスゴールを持ったチームを組むことが難しい。

④組込みシステム開発

• リリース後のソフトウェア修正が極めて困難であり、採用には工夫要。



大規模開発への適用(中大規模事例調査から)

非ウォーターフォール型開発を導入するための工夫



課題に工夫で取り組む！

人材の育成 ⇒ チーム間ローテーションチーム間の知識伝播促進のため、別のチームにメンバをローテーションする。一時的な減速はあるが、各チームの知識を効率よく伝播でき多能工化が高まる。

段階的朝会 ⇒ 全体でのコミュニケーション複数チーム間は朝会を段階的に実施。チーム単位の朝会→リーダだけの全体の朝会（→チーム単位の朝会）

組織内への展開 ⇒ 漸進的な展開一度にすべてのチームに広げるのではなく、まずは導入障壁の低いところ、最も必要なところから順次導入し、少しづつ展開。

分散開発、オフショア開発 ⇒ コミュニケーション・ツールの活用 TV会議システム、チケット管理システム、雑記帳システム（SNS、Blog等）の活用オフショア先は、時差のない地域から選定

中大規模開発での工夫例 (1/2)



課題に工夫で取り組む！

漸進的アーキテクチャ設計 ⇒ アジャイル型で開発しないアーキテクチャ専門チームを編成して、アジャイル型でない方法で開発する。

あるいは、既存の組織標準のアーキテクチャを再利用する。

機能分割と統合 ⇒ 疎結合な機能分割疎結合な機能でサブシステム分割を行う。

サブシステム間の結合部分を優先的に開発し、統合テストを早くから行う。

テスト専用フェーズプロジェクト後半で専用のテストフェーズを実施。プログラム開発の反復を停止してウォーターフォール型でテストをする事例と、テストのみの反復期間を設ける事例があった。

中大規模開発での工夫例 (2/2)

ユーザ側メンバの過負荷 ⇒ 開発側メンバで補完ユーザ側メンバが要件出し、受入れテストなどで過負荷になる場合は、開発側メンバがユーザ役を務める（ユーザプロキシ：顧客代理人）。



契約を考える！

ビジネス構造パターン

で、契約の起こる可能性がある場所を示す。同一の組織内の場合は、契約はない。

契約には、請負契約や準委任契約等の種類がある。

契

使う人

提供する人

作る人

作る人2

保守する人

契

契

契

契補佐

する人

契

今回の検討対象検討対象



基本／個別契約

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

準委任契約準委任契約請負契約



基本/個別契約モデルのポイント (1/2)

Point１ -相互協力の義務付け（基本契約5条）相手方への協力義務違反⇒法的責任

-頻繁な連絡協議会の開催（基本契約6条）開発機能の内容検討の他、プロジェクト全体/個別開発の

進捗管理、リスク・問題点の検討を行い、必要事項を決定

定期開催 + 一方当事者の要求では随時開催

ユーザとベンダの緊密な協力体制の確保

Point２ -個別契約における決定事項は別紙に集約（個別契約の別紙参照）個別契約書本文ではなく、別紙記載の項目を取り決め

-連絡協議会による決定（基本契約6条）契約書に記載がない事項は連絡協議会で決定

決定事項は、議事録に記載して証跡を残す

スピーディーな意思決定の実現



基本/個別契約モデルのポイント (2/2)

Point３ -変更協議による決定事項の事後的変更（基本契約4条）一旦決定した事項（連絡協議会での決定、個別契約での

合意）を変更する必要があれば、変更協議で誠実に協議する

一方当事者が変更協議を求めた場合、相手方は応じなければならない

変更協議が調わないまま一定期間が経過した場合には、個別契約を終了できる

決定事項の事後的な変更を許す



組合型モデルとは？

非ウォーターフォール型開発の特徴である、開発側と顧客側の密な協力体制をそのまま、契約に反映ユーザ企業は資金を、ベンダ企業は開発業務の労務を出資し、一つのシステ

ムを共同で企画・製作するための組織（共同企業体）を創る。

プロジェクトのコーディネートとマネジメントを組合が担当し、開発作業は、組合がベンダに委託して行う。

民法第667条（組合契約）



組合モデルのポイント

Point 組合契約による、共同事業のパートナーとしての協働体制（契約1条）

ベンダは技術・知識を持つスタッフの労務を、ユーザは資金をそれぞれ出資（4条）

開発の成果から収益が得られた場合は、出資比率に応じて分配（7条）

連絡協議会によるプロジェクト運営・管理（10条）、変更協議（11条）

具体的な開発は、組合からベンダに委託（5条）



まとめ・・・アジャイル型開発を始める人へ

従来のウォーターフォール型開発から、アジャイル型開発への切り替えは覚悟が必要

強力なリーダシップが必要

手法・プロセスの変更ではなく、組織・文化の変革

スキルが必要（Scrum Masterなどの資格取得、コンサル支援）

QCD(品質、コスト、納期）至上主義から顧客ビジネスの成功（早期出荷、迅速な修正等）がゴール

顧客側の決意が必要

ベンダへの丸投げをしない

幹部への説得

：



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

2009年度： http://sec.ipa.go.jp/reports/20100330a.html 2010年度： http://sec.ipa.go.jp/reports/20110407.html 2011年度： http://sec.ipa.go.jp/reports/20120326.html (契約書案改訂)

http://sec.ipa.go.jp/reports/20120328.html (中大規模事例)

※ 海外普及要因調査公開準備中(2012・5月末公開予定)

【報告書公開中】










非ウォーターフォール型開発の 課題と対策を知る！ …software engineering...

Documents

非ウォーターフォール型開発の課題と対策を知る！ …software engineering...