ソフトウェア業界 新航海術

アウトソーシングは丸投げではない

**************************************************************
_/_/_/_/_/_/_/ ソフトウェア業界　新航海術 _/_/_/_/_/_/_/_/_/
**************************************************************
第77号 2005/05/30
▼ まえがき
▼ [保存できないエディタ]　「テストのアウトソーシング」アンケート
▼ [保存できないエディタ]　アウトソーシングは丸投げではない
▼ [保存できないエディタ]　持ち帰り可、しかし面接は躊躇せず徹底的に
▼ [保存できないエディタ]　発注側が工数を見積もる
▼ [保存できないエディタ]　漸増型開発プロセスでの請負に話は続く
▼ 次回以降の予告

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

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

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

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

*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=
[保存できないエディタ]　「テストのアウトソーシング」アンケート
*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=

幸地司氏が発行しているメルマガ「中国ビジネス入門」(2005/05/16
第238号)で、本メルマガ第75号「米国でのテストのアウトソース・ビジネス」
が紹介されました。
（http://www.ai-coach.com/backno/cip0238.html 参照）

また、幸地司氏は、「海外拠点での『テスト工程のアウトソーシング』、
あなたの会社では可能性ありますか？」というクリックアンケートを
実施しています。
（http://clickenquete.com/a/r.php?Q0005859C74ad 参照）

そのアンケートのコメントボードに次のような意見が書き込まれていました。

> テストは、開発会社にとって、エンドユーザに対する責任であり、
> エンドユーザにとって、開発会社に対して、ほしがっている機能が
> 手に入ったかどうかの受け入れる検証である。これをアウトソーシ
> ングすることは、開発会社が責任を放棄し、エンドユーザが何が手
> に入るかも構わないと言うことを意味する。

実はこのコメントは非常に重要なところをついているのです。

*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=
[保存できないエディタ]　アウトソーシングは丸投げではない
*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=

私が第75号( http://www.kei-it.com/sailing/75-050516.html )で
「テスト工程のアウトソーシング」を取り上げた理由の一つは、
アウトソーシングをアウトソーシングする側から捉えたかったからです。

我々はシステム開発受託会社です。
したがって、「請負」を請負う側から捉えてしまいます。
請負契約について書かれている本にも、請負う側の義務は書かれて
いますが、請負わせる側の義務はほとんど書かれていません。
せいぜい、「成果物の納入後代金を支払わなければならない」程度です。

その点、「テスト工程のアウトソーシング」をテーマとした場合には、
自然とアウトソーシングする側から見ることができます。

「基本から学ぶソフトウェアテスト」(Cem Kaner,Jack Falk,
Hung Quoc Nguyen著)でテストのアウトソーシングについて触れている
章がありますが、そこもアウトソーシングする側から書かれています。
Cem Kanerらはそこで「アウトソーシングは丸投げではない」と強調
しています。

> 自社でテストを行わずに丸投げするのは、無理な注文である。
> 自分たちと同じように、アウトソーシング先の仕事についてもきちんと
> 把握し管理すべきである。

これは進捗管理のみを言っているわけではありません。
アウトソーシング先と一緒に働かなければならない、それも優秀な
技術者が一緒に働かなければならないと言っているのです。

> アウトソーシングする場合には、社内のテストチームも一緒に
> プロジェクトに参加させることだ。

> アウトソーシングの効果を最大限にするためには優秀な技術者を
> 一緒に働かせなくてはならない。

*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=
[保存できないエディタ]　持ち帰り可、しかし面接は躊躇せず徹底的に
*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=

しかし、これは物理的に一緒の場所で働けと言っているわけでは
ありません。

日本での「作業請負」「業務請負」は客先常駐を意味します。
しかし、同書での（そして、おそらく米国での一般的な）テストの
アウトソーシングは、客先常駐を前提としていません。
例えば、Cem Kanerらは同書で「報告された障害を社内ですべて再現
しておくこと」とも記しています。
これは、アウトソーシング先のテスト場所と社内のテスト場所とが
異なることを示しています。

テスト作業はアウトソーシング先に持ち帰ってやってよいのです。
しかし、それでいてCem Kanerらは「アウトソーシングの契約を結ぶ前に、
技術者の面接を躊躇せず徹底的に行う必要がある」とも言っています。
アウトソーシング先の営業やリーダではなく、実際に担当する技術者の
面接です。

日本では、持ち帰りの請負の場合は「請負だから担当者の選定は
受託会社に任されている。だから、担当する技術者の面接は必要ない」
と言われています。
少なくとも「躊躇せず徹底的に」というレベルの面接は行われません。

*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=
[保存できないエディタ]　発注側が工数を見積もる
*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=

また、同書には、アウトソーシングする側が工数を見積もることを
前提とした記述が、数箇所あります。例えば、次のように。

> 社内より少ないサイクルでテストできると考えるべきではない
> 社内で3回テストするつもりなら、アウトソーシング先にも3回分の
> 予算を組んでおく必要がある。

ここで第76号で解説した「サイクル型作業による見積もり精度の向上」
http://www.kei-it.com/sailing/76-050523.html　が生きてきます。

*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=
[保存できないエディタ]　漸増型開発プロセスでの請負に話は続く
*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=

・アウトソーシング先と一緒に働くこと。
・アウトソーシング先に積極的に介入すること。
・アウトソーシング先に期待することを限定し、明確化すること。
・発注側が工数を見積もること。

これなしにテストのアウトソーシングは成功しません。

しかし、これは漸増型開発プロセスでの請負(第74号　
http://www.kei-it.com/sailing/74-050509.html　参照)
についても言えることではないでしょうか？
この点について次号以降で論じます。

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

次回以降は引き続き下記の項目について書いていきます。

・見積もりが難しいテスト工程をアウトソーシングする方法
・ソフトウェア工場よりもテストセンターの方が実現しやすい。
・テストのアウトソーシングと漸増型開発プロセス

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

乞うご期待！！

*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=
本メルマガについて
*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=

本メルマガは2003年12月8日に創刊されました。
創刊号 http://www.kei-it.com/sailing/01-031208.html で述べたとおり、
本メルマガのコンセプトは「読みものとしても面白い慶の事業計画」であり、
目的は「事業計画の背後にある基本的な考え方を語ること」です。

したがって、第一の読者としては、慶の社員（正社員・契約社員）及び
慶と契約している個人事業主を想定しています。
彼らには慶社内のメーリングリストで配信しています。

また、多くのソフトウェア会社・技術者が直面している問題を扱っているので、
ソフトウェア会社の経営者、管理者、技術者にとっても参考になると思い、
第33号(2004年7月19日号)からは「まぐまぐ！」で一般の方々にも公開する
ことにしました。

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

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

テストのアウトソーシングの素地

**************************************************************
_/_/_/_/_/_/_/ ソフトウェア業界　新航海術 _/_/_/_/_/_/_/_/_/
**************************************************************
第76号 2005/05/23
▼ まえがき
▼ [保存できないエディタ]　テストは商慣習の違いの影響を受ける
▼ [保存できないエディタ]　ファウラー氏の友人はテスト項目を契約に入れる
▼ [保存できないエディタ]　素地：製造チームとテストチームの分離
▼ [保存できないエディタ]　素地：サイクル型作業による見積もり精度の向上
▼ 次回以降の予告

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

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

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

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

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

*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=
[保存できないエディタ]　テストは商慣習の違いの影響を受ける
*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=

１プログラマの製造工程の作業は、日本でも米国でも大差ないでしょう。

与えられた要求仕様と素材（ハードウェア、ＯＳ、プログラミング言語、
通信環境など）が同じなら、日本でも米国でも優秀なプログラマは
同じようなアイデア、アルゴリズム、コーディング技法を生み出して
いくでしょう。
これらは純技術的な必然性から生み出されるものであり、商慣習や
文化とはほとんど関係ありません。

一方、ブラックボックステストは、通常は、作成したプログラマとは
別の人達が行います。
立場の違う人達、しかも、大概は対立的な立場の人達（社内のテスト
チーム、顧客、ベータテストの協力者など）が行います。

ブラックボックステストは、プログラミングよりもはるかに社会的な
行為です。
したがって、商慣習の違い、契約についての考え方の違い、さらには
組織のあり方や文化の違いが影響を与えます。

*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=
[保存できないエディタ]　ファウラー氏の友人はテスト項目を契約に入れる
*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=

このシリーズで何度も引用している「基本から学ぶソフトウェアテスト」
(Cem Kaner,Jack Falk,Hung Quoc Nguyen著)には、米国でのソフトウェア
テストの現状とあるべき姿が書かれています。
その本の中には、商慣習の違いを感じさせる部分が幾つもあります。

例えば、第71号でも指摘しましたが、同書では「受託の場合は最終受け
入れテスト項目を契約で規定すべきだ」ということが繰り返し述べられて
います。
また、そのテスト項目は発注者が一方的に決めるのではなく、受注者も
そのテスト設計に参加すべきであるということも強調されています。

> 重要なのは、テストチームが顧客と一緒になってテスト設計を行う
> 必要があるという点である。テストに精通していない者が関わることは
> 非常に危険なのである。曖昧なテスト項目や非常に時間のかかるテスト
> 項目を設計してしまったり、開発費に対して高すぎる品質を保証する
> という過ちをしかねない。顧問弁護士にも相談しておいた方がよいだろう。
> 　　　　　　　　（「基本から学ぶソフトウェアテスト」より）

「ソフトウェア品質保証の考え方と実際」(保田勝通著　1995年出版）
によれば、日本でも産業構造審議会の情報産業部会が1993年7月に出した
「ソフトウェアの適正な取引を目指して」という報告書には、
「発注者と供給者は協議のうえ、発注者の受け入れ検査の基準となる
機能仕様書、テスト項目、テストデータおよびテスト方法を定めた
検査仕様書を作成する」と書かれているそうです。

しかし、日本では、最もウォータフォール的であった1980年代ですら、
テスト項目を契約に盛り込むことはありませんでした。
「ウォータフォールは良くない」と言われるようになってからは、
受け入れテスト基準はますます曖昧になってしまいました。

それに対し、米国は何かというとすぐに訴訟する社会です。

「マーチン・ファウラー氏の友人」(第73号　
http://www.kei-it.com/sailing/73-050502.html　参照）は、
最終受け入れテスト項目をきちんと契約で規定していたはずです。

*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=
[保存できないエディタ]　素地：製造チームとテストチームの分離
*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=

第75号では、今後の予告として下記の3点を書きました。

(1)見積もりが難しいはずのテスト工程をアウトソーシングする方法。
(2)テストのアウトソーシングは漸増型開発プロセスとも相性がいい。
(3)ソフトウェア工場よりもテストセンターの方が実現しやすい。

今週号では(2)について簡単に解説します。

第74号で図解した「漸増型開発プロセスの基本形」
http://www.kei-it.com/sailing/pdf/74-050509.pdf
をもう一度参照してください。

「設計からテストまでを並行して進める」と言っても、実際に作業が
被っている部分は、ブラックボックステストと他の作業であることが
分かります。

製造チームは、一つのバージョンの詳細設計からホワイトボックス
テストまでを行ったら、ブラックボックステストはテストチームに
任せて、自分達は基本設計の見直しと次のバージョンの詳細設計・
コーディングに入ります。

プログラマが通常ブラックボックステストを行わない理由は、
ブラックボックステストが持つ次のような性格によります。
・非常に時間がかかる、根気がいる作業である。
・独自のノウハウが必要な作業である。
・製作者の思い込みがない方がよい。

このようにして、漸増型開発プロセスでは、開発の初期の段階で、
製造チームとテストチームの分離が起きます。

*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=
[保存できないエディタ]　素地：サイクル型作業による見積もり精度の向上
*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=

ブラックボックステストには、「テスト工程としての受け入れテスト」
と「回帰テスト」が含まれます。

ここでの「テスト工程としての受け入れテスト」は「受託開発での
最終受け入れテスト」とは別物です。
テストチームが新バージョンを受け取ったときに実施する受け入れ
テストです。テストに耐え得るだけ安定しているかをチェックする
簡単な機能テストです。

一方、回帰テストとは、想定したとおりにプログラムが修正できたか、
変更が他の機能に悪影響を与えていないかを確認するテストです。

これらのテストは、バージョンのたびに発生するサイクル型作業です。
これがテスト作業の見積もりを容易にします。

> プロジェクトも半ばを過ぎると、単発型とサイクル型の作業をうまく
> 区別できるようになり、精度の高い見積もりが可能となる。
> そこまでのバグの発見及び修正の状況から、あとテストにどのくらい
> 時間がかかるのかをかなり正確に見積もることができるようになる。
> 　　　　　　　　（「基本から学ぶソフトウェアテスト」より）

製造チームとテストチームの分離、サイクル型作業の発生による見積もり
精度の向上が、テストのアウトソーシングの素地となります。

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

次回以降は引き続き下記の項目について書いていきます。

・見積もりが難しいテスト工程をアウトソーシングする方法
・テストをアウトソーシングは漸増型開発プロセスと意外と相性がいい
・ソフトウェア工場よりもテストセンターの方が実現しやすい。

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

乞うご期待！！

米国でのテストのアウトソース・ビジネス

**************************************************************
_/_/_/_/_/_/_/ ソフトウェア業界　新航海術 _/_/_/_/_/_/_/_/_/
**************************************************************
第75号 2005/05/16
▼ まえがき
▼ [保存できないエディタ]　米国でのテストのアウトソース・ビジネス
▼ [保存できないエディタ]　テストのオフショア（米国→インド）
▼ [保存できないエディタ]　実は漸増型開発とも意外と相性がいい
▼ [保存できないエディタ]　付け足し：第三者検証(IV&V)
▼ 次回以降の予告

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

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

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

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

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

第72号を書いているときには、「そろそろ本シリーズのまとめに入って、
第75号くらいで完結させよう」と思っていました。
しかし、第74号でテストのアウトソーシングにまで言及したので、
このシリーズはもうしばらく続きます。
テストのアウトソーシングについては、いくつか気になっていることが
あるからです。

尚、テストのアウトソーシングの話をするときの「テスト」とは、
通常はブラックボックステストのことです。
ホワイトボックステストとブラックボックステストについては第71号
http://www.kei-it.com/sailing/71-050418.htmlを参照してください。

*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=
[保存できないエディタ]　米国でのテストのアウトソース・ビジネス
*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=

日本では、昔も今も「テストのアウトソーシング」という発想はほとんど
ありません。
外注を使う場合にも、日本のメーカや元請SIは製造からホワイトボックス
テストまでを下請けに出し、ブラックボックステストは社内でやるのが
一般的です。
しかし、米国ではテストをアウトソーシングすることがよくあります。

本シリーズでよく引用している「基本から学ぶソフトウェアテスト」
(Cem Kaner,Jack Falk,Hung Quoc Nguyen著)でも、テストのアウトソーシング
について非常に具体的に説明されています。
いかに具体的で実務的な説明であるか理解していただくために、二つだけ
文章を引用します。

> アウトソーシングの契約を結ぶ前に、技術者の面接を躊躇せず徹底的に
> 行う必要がある。

> 技術の高い企業は、間接費や固定費の分を上乗せして契約を行うもの
> である。コンサルティング企業であれば3倍の請求をすることが多い。
> 例えば時間当たり3000円で契約していても、そのうち技術者に相当する
> コストは1000円である。

一方、日本の学者が書いたソフトウェアテストの本で、テストのアウト
ソーシングについて書かれているものは、私は見たことがありません。

「基本から学ぶソフトウェアテスト」ではテストのアウトソーシングの
具体的な説明の後で、次のように総括しています。

> 全体的に見ると、テストのアウトソーシングはそこそこ評価できる。
> デメリットよりもメリットの方がとても多い。アウトソーシングを
> 役立てることができる組織は多いだろう。

これが米国における標準的な考え方だと思います。
つまり、米国ではテストがアウトソース・ビジネスとして独立して存在
しているのです。

*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=
[保存できないエディタ]　テストのオフショア（米国→インド）
*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=

インドもテストを独立したアウトソース・ビジネスとして捉えています。

インドのメジャーなITサービス企業であるウィプロ(Wipro)には、
2,000名以上の品質保証（QA）の専門家がいるそうです。
http://www.mercury.com/jp/company/pr/press-releases/113004wipro.htmlには、次のように書かれています。

> Wiproは、現在、2,000名以上の品質保証（QA）の専門家が、金融・流通・
> 公共・製造・通信などのさまざまな業界、および組み込みシステム/
> アプリケーション分野で、100 社以上の顧客に対して、テストサービスと
> 品質保証サービス、ならびにテストプロセスのコンサルティングを提供
> しています。

日本での中国オフショアは、製造からホワイトボックステストまでを
中国で行い、ブラックボックステストは日本で行うのが通常のパターンです。
国内ソフトウェア会社への外注と同じパターンです。

しかし、米国からインドへのオフショアでは、米国で製造したシステムを
インドでテストするというパターンも多いようです。

*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=
[保存できないエディタ]　実は漸増型開発とも意外と相性がいい
*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=

開発コストの中でテストが占める割合はどの程度でしょうか。
製品の性格によって異なりますが、運用と保守を除く初期開発コストの
30%～50%を占めると言われています。
これをアウトソーシングできるなら、その意義は大きいはずです。

しかし、テストのスケジュールは上流の工程の進捗に依存してしまうため、
見積もりが難しいはずです。
また、実装が遅れたり、予想よりバグが多かったり、ユーザインタフェース
が確定しない場合には、テストの時間が膨らんでしまいます。
普通に考えると、テストのアウトソーシングは難しいと思ってしまいます。
これを米国ではどのようにやっているのか、次号以降で解説します。

また、普通に考えると、設計からテストまでを並行して進める漸増型開発
プロセスではテストのアウトソーシングはやりづらいと思ってしまいます。
しかし、本当は違います。
実は、漸増型開発プロセスとテストのアウトソーシングとは、意外と
相性がいいのです。
このあたりも次号以降で解説します。

もう一つあります。
製造業の製造工程と、ソフトウェアの製造工程とは全く異なっています。
しかし、製造業における品質管理とソフトウェアの品質管理とは
似ているのです。
これは、ソフトウェア工場よりもテスト工場の方が実現しやすいことを
意味しています。
このあたりも次号以降で解説します。

*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=
[保存できないエディタ]　付け足し：第三者検証(IV&V)
*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=

本シリーズで取り上げる「テストのアウトソーシング」は、いわゆる
「第三者検証」IV&V(Independent Verification and Validation)とは
違います。
第三者検証(IV&V)は、独立したテスト機関が実施する検証や評価
であり、通常の商用アプリケーションのテストではありません。

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

次回以降は下記の項目について書いていきます。

・米国でのテストのアウトソーシング。
・漸増型開発プロセスとテストのアウトソーシング。
・ソフトウェア工場かテスト工場か。

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

乞うご期待！！

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

**************************************************************
_/_/_/_/_/_/_/ ソフトウェア業界　新航海術 _/_/_/_/_/_/_/_/_/
**************************************************************
第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日発行予定です。

乞うご期待！！

ファウラー氏の請負契約観

**************************************************************
_/_/_/_/_/_/_/ ソフトウェア業界　新航海術 _/_/_/_/_/_/_/_/_/
**************************************************************
第73号 2005/05/02
▼ まえがき
▼ [保存できないエディタ]　ファウラー氏の請負契約観
▼ [保存できないエディタ]　一括請負契約は危険な幻想(ファウラー)
▼ [保存できないエディタ]　米国では一括請負は仕様変更で儲ける
▼ [保存できないエディタ]　要求仕様すら凍結されていない一括請負
▼ 次回以降の予告

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

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

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

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

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

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

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

*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=
[保存できないエディタ]　マーチン・ファウラー氏の請負契約観
*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=

マーチン・ファウラー氏が請負契約についてどのように考えているか
示す記事をWEB上で見つけました。
「マーチン・ファウラー特別ラウンドテーブル」(@IT提供)です。
http://www.atmarkit.co.jp/farc/special/fowler01/fowler01b.html

マーチン・ファウラー氏は米国でのシステム設計分野の第一人者で、
パターン、UML、軽量型方法論、リファクタリングで著名です。
著書に、『アナリシス・パターン』(1996)、『リファクタリング』(1999)、
『UMLのエッセンス』(1999)、『XPのプランニング』(2000)などが
あります。

上記記事でインタビュアーは次のように質問しています。

> ファウラーさんのお話ですと、アジャイルプロセスの場合は、変更を
> 是として受け入れていくことになるので、もし一括請負契約で受けると、
> コストとの兼ね合いからそれをどうコントロールするかが問題になると
> 思います。それについてはどうお考えですか？

*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=
[保存できないエディタ]　一括請負契約は危険な幻想(ファウラー)
*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=

それに対して、ファウラー氏は次のように答えています。

> 基本的に、一括請負契約という考えは危険な幻想だと思っています。

> 以前大きなコンサルティング・ファームに勤めていた友人の営業マン
> がいっていましたよ。彼がそのコンサルティング・ファームを辞めた
> 理由の1つは、担当した開発案件で仕様変更を勝ち取るたびに報酬を
> 受け取れる仕組みだったからです。その企業では一括請負契約を安い
> 価格で受け、仕様変更で非常に高額な費用を請求していたのです。
> こうしたことは珍しいケースではありませんが、顧客企業にとって
> いいことではありません。

> 顧客企業が一括請負契約を選択すれば、そのリスクの付けが開発する
> アプリケーションに回ります。なぜなら簡単に仕様変更ができなく
> なるからです。もし、そうした状況が起こらなかったとしても、一括
> 請負契約は顧客企業にとって大きなリスクとなるでしょう。なぜなら、
> 開発側は要求どおりにしか作らないので、それが彼らにとって使える
> ものであるかどうかは尋ねません。

> 一括請負契約は顧客企業にとって最悪の契約です。
> 大きなコンサルティング・ファームの多くがこれで大もうけしていますよ。

*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=
[保存できないエディタ]　米国では一括請負は仕様変更で儲ける
*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=

ファウラー氏の回答は、これまで「保存できないエディタ」シリーズ
で私が述べてきたことを裏付けるものです。

ファウラー氏は「顧客企業が一括請負契約を選択すれば簡単に仕様変更
ができなくなる」と言っています。
これは米国では一括請負契約のシステム開発は、開発初期で仕様凍結する
開発プロセス、つまりウォータフォール型で行うことを意味しています。
そして、仕様変更は全て有料なのです。

日本では、「一括請負契約は開発側がリスクを取るから、顧客にとって
有利な契約であるが、生産性を上げれば開発側も利益を出せる」と
説明されています。(第62号「日本では請負業者がリスクを負担する」
http://www.kei-it.com/sailing/62-050214.html 参照)

しかし、米国では一括請負契約は開発者側にとって有利な契約です。
そして、その理由は、生産性を上げて利益を出せるからというよりも、
仕様変更は不可避で且つ全て有料だからです。
顧客がその費用をケチると、開発側は最初の要求どおりにしか作ら
ないので、使えないものができてしまうのです。

アジャイルは日本では純技術的な進化として受け止められていますが、
米国でアジャイルが喧伝される理由は技術的な理由だけではありません。
一括請負契約は仕様変更のたびに金を払わなければならないからです。
（他にも、米国ではアジャイルに適した市販ソフトウェア開発が盛ん
だからという理由もあります。）

*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=
[保存できないエディタ]　要求仕様すら凍結されていない一括請負
*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=

設計仕様が決まっているものに対して、一括請負することはごく自然な
ことです。
また、仕様設計自体を一括請負することも可能です。
要求仕様が凍結されていれば、仕様設計にかかる工数は見積可能
だからです。

しかし、「要求仕様すら凍結されていない一括請負」というものは
論理的にあり得ません。

ところが、日本では、それが存在するのです。
仕様変更が発生しても「設計から一括でお任せしているんだから」
という理由で追加工数を払わないお客さんが存在するのです。
むしろ、日本では仕様変更があっても追加工数を払わないために、
定額契約である一括請負を選択する場合が多いのです。

つまり、米国では一括請負と言えば仕様凍結型アプローチ、すなわち
ウォータフォール型なのに対し、日本では「仕様漸増型の一括請負」が
存在するのです。

「漸増型の一括請負」をどのように考えればよいか、次号以降で解説します。

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

次回以降は下記の項目について書いていきます。
長かったこのシリーズもいよいよ最終局面を迎えます。

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

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

乞うご期待！！