ベータ版のリリース時点あたりで仕様凍結

**************************************************************
_/_/_/_/_/_/_/ ソフトウェア業界　新航海術 _/_/_/_/_/_/_/_/_/
**************************************************************
第74号 2005/05/09
▼ まえがき
▼ [保存できないエディタ]　図：漸増型開発プロセスの基本形
▼ [保存できないエディタ]　ベータ版のリリース時点あたりで仕様凍結
▼ [保存できないエディタ]　「テストのみの請負」という切り口
▼ 次回以降の予告

*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=
まえがき
*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=

こんにちは、蒲生嘉達（がもう よしさと）です。

「保存できないエディタ」シリーズをスタートした第57号から
「まぐまぐ！」での読者数が急に増えてきました。
シリーズ開始前は約200名だったのに、今では360名です。
読者も「日本のソフトウェア請負開発は何かおかしい」という思いを
お持ちなのだと思います。

当初は3，4回のシリーズにするつもりでしたが、請負契約や開発プロセス
については話題が尽きず、今回でシリーズ18回目となります。
このシリーズはもう少し続きそうです。

「保存できないエディタ」シリーズをまとめて読みたい方は下記URLを
参照してください。
http://www.kei-it.com/sailing/back_editor.html

本メルマガの内容に興味を持つであろう方をご存知なら、是非
本メルマガの存在を教えてあげてください。

（以下をそのまま転送するだけです。）
---------------------------------------------------
【お勧めメルマガ　ソフトウェア業界　新航海術】
⇒ http://www.mag2.com/m/0000136030.htm　または
　http://www.kei-it.com/sailing/　
　
---------------------------------------------------

*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=
[保存できないエディタ]　図：漸増型開発プロセスの基本形
*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=

漸増型開発プロセスの基本形を図解しました。
下記URLを参照してください。
http://www.kei-it.com/sailing/pdf/74-050509.pdf

内容的には第67号「アルファ版、ベータ版、ガンマ版」
http://www.kei-it.com/sailing/67-050321.html第65号「市販ソフト開発に見る漸増的開発の基本形」
http://www.kei-it.com/sailing/65-050307.htmlで述べたことと同じですが、この図の方が分かりやすいと思います。

簡単に解説します。

最初に核となる小さな製品を開発し、機能を段階的に付加していきます。
「図：漸増型開発プロセスの基本形」の黄色いボックスの流れがこれを
示しています。

また、製品イメージが固まるにつれて要求仕様を再確認し、設計を
見直します。図での青い渦巻きはこれを表現しています。
渦巻き線が製品版に近づくにつれて徐々に細くなっていくのは、設計上の
問題が徐々に収束していくことを表しています。

また、この図では表現できていませんが、新たな追加機能のテストで
既存機能のテストも繰り返すので、信頼性が高まります。

*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=
[保存できないエディタ]　ベータ版のリリース時点あたりで仕様凍結
*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=

ウォータフォール型開発プロセスでは開発の初期の段階でシステムの
完成形を決めるのに対し、漸増型開発プロセスでは最終段階まで
システムの完成形を決めません。

「商品力を高めるためにもっと機能拡張したいが、それは開発費増と
納期遅延をもたらす」というトレードオフに悩みながら、ベータ版の
リリース時点当たりで、ようやく完成形を決めます。

ウォータフォール型開発プロセスでは、最初に要件の凍結があるから、
次に仕様設計の見積と請負が可能となります。
また、仕様設計の凍結があるから、製造の見積と請負が可能となります。
(第72号「ウォータフォール型のまとめ」
http://www.kei-it.com/sailing/72-050425.html　参照)

しかし、漸増型開発プロセスではプロジェクトの最終段階になって、
ようやく仕様が凍結します。
それまでの作業はどのようにして見積もり、どのようにして請負えば
よいのでしょうか？

この問題に対するまともな解答を私は見たことがありません。
（第69号「日経システム構築4月号の期待はずれな記事」
http://www.kei-it.com/sailing/69-050404.html、
第10号「ソフトウェア開発委託契約の契約と実務」
http://www.kei-it.com/sailing/10-040209.html　参照）

*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=
[保存できないエディタ]　「テストのみの請負」という切り口
*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=

しかし、本メルマガではこの問題にまともな解答を与えたいと思います。

そのために別の切り口から考えてみましょう。

「ブラックボックステストのみの請負」という切り口です。
いきなり開発全体の請負を考えるのではなく、作業範囲を限定して
考えて見ましょう。

ブラックボックステストのみを専門に請負う会社は、日本では大手は
ベリサーブ( http://www.veriserve.co.jp/index.htm )のみでしょう。
しかし、米国ではテストのアウトソーシングは日本よりも盛んで、
テスト専業の会社も多いようです。

それらの会社は、プロジェクトにコンサルタントとして加わる場合、
テスターとして加わる場合、そしてテスト全体を請負う場合があります。

彼らはどのようにしてプロジェクトに関わっていくのでしょうか。
それが、システム開発のアウトソーシング（請負）のあるべき姿を
考えるヒントとなりそうな気がするのです。

*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=
　次回以降の予告
*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=

次回以降は下記の項目について書いていきます。
このシリーズは、もう少し続きそうです。。

・ブラックボックステストのみの請負
・オーダーメイド開発の多い日本での漸増的開発はどのように考えたら
　よいのか？
・「全体がウォータフォールでもテストは漸増型で」の詳細。
・納品時の最終受け入れテストはどうあるべきなのか、検収とは何なのか。

次号は、5月16日発行予定です。

乞うご期待！！