アジャイル開発を適切に採り入れるためのポイント …code will not fix these kinds of difficulties. The required design changes are likely to be so disruptive that

アジャイル開発を適切に採り入れるためのポイントとアジャイル開発の事例【2】アジャイル開発の事例に学ぶ

2011/12/9 独立行政法人情報処理推進機構

原田騎郎株式会社　情報システム総研

アジェンダ

•  そもそもウォーターフォールとは –  ウォーターフォールがうまくいく理由

•  ユーザー、ベンダーとの関係 –  情報隠蔽の問題

•  アジャイルにおける契約例 –  一括請け負い –  準委任 –  リスク共有契約

•  今回の契約の試み –  三者契約によるアジャイルの実施

2 株式会社　情報システム総研

自己紹介

•  原田騎郎

•  わらじ三足 –  SCM コンサルタント –  ドメインモデラー –  アジャイルコーチ(認定スクラムプロフェショナル-‐CSP、CSM、CSPO)

•  情報処理技術者 –  テクニカルエンジニア(ネットワーク) –  システムアナリスト –  プロジェクトマネージャ –  システム監査技術者


ウォーターフォールの起源

•  Royce 論文

•  初の図に間違った例を書いたのが、大の失敗？

•  論文の主張すること – DO IT TWICE –  INVOLVE CUSTOMER – PLAN YOUR TESTS


Royce – Waterfall 論文 I SYSTE M

I ANALYSIS

PROGRAM DESIGN

I c o o , . o

TESTING

I OPERATIONS

Figure 2. Implementation steps to develop a large computer program for delivery to a customer.

I believe in this concept, but the implementation described above is risky and invites failure. The problem is illustrated in Figure 4. The testing phase which occurs at the end of the development cycle is the first event for which timing, storage, input /output transfers, etc., are experienced as distinguished from analyzed. These phenomena are not precisely analyzable. They are not the solutions to the standard partial differential equations of mathematical physics for instance. Yet if these phenomena fail to satisfy the various external constraints, then invariably a major redesign is required. A simple octal patch or redo of some isolated code wil l not f ix these kinds of diff iculties. The required design changes are l ikely to be so disruptive that the software requirements upon which the design is based and which provides the rationale for everything are violated. Either the requirements must be modif ied, or a substantial change in the design is required. In effect the development process has returned to the origin and one can expect up to a lO0-percent overrun in schedule and/or costs.

One might note that there has been a skipping-over of the analysis and code phases. One cannot, of course, produce software wi thout these steps, but generally these phases are managed wi th relative ease and have l i tt le impact on requirements, design, and testing. In my experience there are whole departments consumed with the analysis of orbi t mechanics, spacecraft att i tude determination, mathematical opt imizat ion of payload activity and so forth, but when these departments have completed their di f f icul t and complex work, the resultant program steps involvea few lines of serial arithmetic code. If in the execution of their d i f f icul t and complex work the analysts have made a mistake, the correction is invariably implemented by a minor change in the code with no disruptive feedback into the other development bases.

However, I believe the illustrated approach to be fundamental ly sound. The remainder of this discussion presents five addit ional features that must be added to this basic approach to eliminate most of the development risks.

329

株式会社　情報システム総研 5

I believe in this concept, but the implementaOon described above is risky and invites failure. コンセプトはすばらしいが、実際にはリスクが大きく失敗を招く。

ウォーターフォールの形式化

•  DoD-‐2167A – Defense Systems SoUware Development – 1988

– 見事なウォータフォールモデル •  ベンダに開発モデルの選択は許しているものの

•  1995 に、MIL-‐STD-‐498 へ


DOD-‐STD-‐2167A DOD-STD-2167

was,.. M, L,WON, 4 M, L, S,ONE ,,

?4,,0DETEFOA,NA,,IJN co,,,,, PROGRAM

SE,,.,,0. GO ,“,,0$11”]’CONCEPT DW40”S1RAT!ONEXmcm,,,rw AN. FULL SCALE DEVELOPMENT“,,,.,,,..

\

</.””’””””> “’L:WS’““o:’‘:’c’”oz“,KJ”,, EMENT,

S“STEINHA, CWA,, ‘NALYSISFIEO”,R, MEWS

. . ..”s.5

I

i i1 - - - - – -DEv’Lw’N’ALcO’’F’GuR’’’ON-

,“.,,,O .,, .L,oc,,,..,s,,,., ,,s,,,.,

““

‘ )

FIGURE 1. Systemdevelopmentcyclewithinthesystemlifecycle.

2

)株式会社　情報システム総研 7

•  DoD-‐2167A は、DoD-‐2167 (1985) の改訂版

で、DoD-‐2167 には？

SoUware development is usually an iteraOve process, in which an iteraOon of the soUware life cycle occurs one or more Ome during each of the system life cycle phases. ソフトウェア開発は通常繰り返しプロセスであり、システムライフサイクルフェーズのそれぞれの中で、一回もしくは複数回繰り返される。 •  2167A にはこの文章はない。


•  2167 と 2167A の間に何があったか。


DOD-STD-2167

1. SCOPE

lol,Purpose. This standard establishes requirements to be appliedduring the development and acquisition of Mission-CriticalComputer ’Systen (MCCSI software, as defined in DOD Directive5000.29. This standard ma: also be applied to non-14CCSsoftwaredevelopment and acquisition.

1.2 A lication.proc~i~O;;wT;~~;;;;OZe?;e ~~fW~l~~v~~~m~;~r~~~l~occurs orieor more times during each of the system life cyclephases (Figure 1). Appendix B describes a typical system lifecycle, the activities that take place during each iteration ofsoftware development, and the documentation which typically existsat the beginning of an iteration in any given system life cyclephase. The requirements of this standard shall be applied to eachiteration, as described below. The requirements of this standardshall also be applied to the development of software for firmwaredevices as described in 4.7.

1.2.1 Application to various - ~ software. This standardapplies .to deliv=a~ software designated as Computer SoftwareConfiguration Items (CSCIS). This standard, or portions thereof,such configuration management,documen~~tion also applies to:

quality evaluation, and

a.

b.

c.

d.

Software developed and delivered as part of a system or aHardware Configuration Item (HWCI) but not explicitlyidentified as a CSCI.

Non-deliverable software used in the development and testingof deliverable software and hardware (such as design andtest tools).

Deliverable unmodsoftware.

Commercially avasoftware (~FS),delivered as part

fied commercially available and reusable

lable software, Government furnishedand reusable software that is modified andof the system.

The specific requirements of this standard which apply to theabove categories will be identified in the statement of work(sow).

1.2.2 Non-applicability of ~ standard. This standard, orportions thereof, may =t apply to small applications whichperform a fixed function that is not expected to change for thelife of the system. Guidelines for applying specific portions ofthis standard to particular categories of software may be found inAppendix D. The SOW will specify the applicable requirements .Ofthis standard.

1

Downloaded from http://www.everyspec.com on 2011-12-09T2:08:06.

Downloaded from http://www.everyspec.com on 2011-12-09T2:10:16.

DOD-‐STD-‐2167A

DOD-‐STD-‐2167

MIL-‐STD-‐498 AlternaOves to Formal Reviews and Audits

•  One of the biggest distracOons from "real work" on a soUware development project is preparing for formal reviews and audits. A common horror story is that everyone stops "real work" six weeks before a formal review and starts generaOng viewgraphs for the review. The result can be tremendous expenditure of Ome and energy on a review that is an overly detailed snapshot of where the project was six weeks before. The developer spends hundreds of staff-‐hours preparing it, and the acquirer is swamped by informaOon overload.

•  Instead of formal reviews and audits, MIL-‐STD-‐498 calls for more frequent, low-‐key joint (acquirer/developer) technical and management reviews, focusing on natural work products rather than viewgraphs or other specially prepared materials. These reviews include informal discussions of status, ideas, approaches, and risks. The idea of these reviews is ongoing communicaOon between the acquirer and developer with minimum Ome wasted. An appendix in MIL-‐STD-‐498 suggests candidate reviews to hold.

hap://www.stsc.hill.af.mil/crosstalk/1995/02/MILSTD.asp


MIL-‐STD-‐498 公式レビューおよび監査の代替手段 •  ソフトウェア開発プロジェクトにおける “実際の作業” からの大の逸脱の一つは、

公式レビューと監査である。よくみかける恐ろしい例は、公式レビューの６週間前になると、開発チームは “実際の作業” を中止してしまい、レビュー用資料のみを作り始めるものだ。結果として、膨大なコストと時間が、６週間も前のプロジェクトのスナップショットを過度に詳細に作るのに費やされるのだ。開発者の時間を何百時間も浪費し、発注者は情報の海におぼれて状況が把握できなくなる。

•  公式レビューおよび監査の代替として、MIL-‐STD-‐498 ではより頻繁に、少ない関係者(発注者/開発者)での技術レビューおよびマネジメントレビューを求めている。それらのレビューでは、レビュー用に特別に作られた資料ではなく、実際の作業の普通の成果物に注目する。また、プロジェクトの状況、アイデア、アプローチ、リスクなどについて非公式に話し合う機会を含む。時間の浪費を小限にしつつ、発注者と開発者の継続的なコミュニケーションとりたい、というのがこのようなレビューの考えである。既存のレビューで残してもよいかもしれないものを、 MIL-‐STD-‐498 の付属文書に記述している。

hap://www.stsc.hill.af.mil/crosstalk/1995/02/MILSTD.asp


WaterFall を動かす力

フォースアクション

発注者仕様追加／変更すると追加費用がかかる。

要件定義で正確な要求を精確に記述しようとする。

ベンダ納期遅れ、人員の超過は利益に直接影響する

開発工数がかさみそうな要件は、技術などをとくに吟味して見積もり精度の向上をめざす


ぐだぐだな Waterfall

•  実際には、 – 要件定義の行程は必ず遅れる – 遅れても仕様変更はなくならない

– 仕様変更は、要件の確認漏れということになる – 結果として仕様変更を無償で受け入れる

•  少なくとも初のうちは

– 要件定義が遅れてもリリース日は、本当に問題になるまで延期されない


ぐだぐだな Watefall フォースアクション

顧客要件定義で正確な記述をすることになっているが、仕様変更にも対応してくれている

必要かもしれないものは全部要件の盛り込む。必要な機能の抜けなど仕様変更・追加は要件確認漏れと主張する。

ベンダ見積もり精度を向上しようにも、見積もりに必要な技術・要件の洗い出しが、後の仕様変更のため困難

先に技術を確定してしまい、技術的制約により仕様変更が難しいという主張をする。人海戦術で、とりあえずすべての要件をそろえたことにしようとする。


ウォーターフォールで仕様変更を認めることは？

•  そもそもの WF をうまくいかせるための力を使えていないことになる。

•  結果として、 – ユーザーが仕様確定を渋るようになる

•  変更される予定の公開をしない

– ベンダーが進捗情報の公開を渋るようになる •  技術的なリスクなどの公開を渋る •  「あらかじめ示されていない要件に対応できないインフラを

使ったので、追加費用が発生します、、、」


ユーザーとベンダーとの関係　　　　　　　　

•  情報隠蔽

•  囚人のジレンマ


アジャイル契約

•  どうやってリスクを共有するか

•  どうやって透明性を確保するか


アジャイル契約のパターン

•  一括請負

•  準委任契約

•  リスク共有契約 – 時間精算と完成時ボーナスの組み合わせ

•  (デンマーク BestBrains 社などで実績あり)


透明性の担保は？

•  ２者間での契約による保証は困難？

– ２者のインセンティブは異なる •  発注者は、使えるシステムを早く、安く調達したい •  開発者は、機能を沢山継続的に開発したい


ありがちな契約構造

施主

二次請け

一次請け

開発契約(一括請負)

開発契約(一括請負)


今回の契約

•  三者による契約 – 既存の契約構造を変えずに、不透明性の問題に

対処する

•  契約例 – RFIDかんばんシステムの開発


契約構造

施主

ベンダ開発支援

支援契約(準委任) 開発契約(期間限定一括 / 準委任)


三者の役割

施主

ベンダ開発支援

目的・目標の提示二週間毎のデモおよびレビュー

ユーザー

バックログの提示

バックログ作成の支援IS アーキテクチャ作成

技術支援Scrum 教育

進捗の開示技術支援依頼など


三者の役割

役割主導対応

施主システムの目的・目標の設定バックログの作成プロダクトオーナー

スプリント計画ミーティングプロダクトレビューテストサイトの準備・対応受け入れテスト・フィードバック

支援開発プロセスの教育(Scrum) バックログ作成の支援業務支援(IS アーキテクチャ) 技術支援スクラムマスター

開発時の問題に対する対応支援業務対応の方法に対する支援

開発ソフトウェアの開発・テストテスト環境の構築・リリース疑問点などの明確化開発チーム

進捗の見える化２週間毎のレビュー　ー動くソフトウェアで指摘点の改善


ユーザは？

•  ユーザの役割は？ – 実際にソフトウェアと使ってみる – 使ってみての要望・問題点を伝える

•  三者はユーザの言葉を傾聴する – ただし、盲従するわけではない。


適用プロジェクト

•  RFID リライタブルかんばんを利用した、かんばんによる調達のしくみの EDI 化 – 「平成２０年度中小企業IT経営革新支援事業」対

象 •  対象共同体　－　こじま事業協同連合組合

•  中小企業向け Saas 型　共通EDI の開発 –  Japan IT Award 2010 – 準グランプリ受賞


開発スケジュール-‐ RFIDかんばん時期内容

2008/6 ～2008/7 概要設計完了フレームワーク実装

2008/8

スクラムチーム立ち上げ初期実装開始「出荷指示、出荷案内、受領確認」実装

2008/9

プロトタイプデモ実施「納期問合、納期回答」実装

2008/10 業務ユーザ向けデモ実施「実業務向けの項目調整、ユーザビリティ」実装「ゲートウェイサーバ実装」

2008/11 「RFID リーダ、プリンタ連携」実装「データ項目調整」

2008/12 実証実験開始準備、および実証実験「内示、出荷指示量調整」実装

2009/1　～実証実験継続追加機能開発 27 株式会社　情報システム総研

開発成果

•  RFID かんばんプロジェクト – 2008/8 のリリース以来、実証実験後も利用継続 – 現在でも稼働中 – システム障害による業務停止なし

•  中小企業用共通 EDI プロジェクト – 2009/冬のリリース以降、業務障害なし


Q&A?


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


Documents

アジャイル開発を適切に採り入れるためのポイント …code will not fix these kinds of difficulties. The required design changes are likely to be so disruptive that