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

乞うご期待！！



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

本メルマガは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/　
--------------------------------------------------



このメールマガジンは『まぐまぐ！』 http://www.mag2.com/ を利用して
発行しています。配信中止はこちら http://www.mag2.com/m/0000136030.htm
（但し、web@kei-ha.co.jp it@kei-it.com には直接配信しています。）

発行者Webサイト: http://www.kei-it.com/sailing/
（発行者Webサイトではバックナンバーの全文検索も可能です。）

--------------------------------------------------
発行：
株式会社 慶
　代表取締役  蒲生 嘉達
　y_gamou@kei-ha.co.jp
　Webシステム開発事業部　http://www.kei-ha.co.jp
　ITサービス事業部　http://www.kei-it.com
　人材コンサルティング事業部　http://www.k-bank.jp
　TEL：03-5951-8490

☆　コピーや配布をされる時はご一報ください　☆
☆　このメルマガに対するご感想・ご質問はこちらにお寄せください。　☆
　　　　　　　　　　　 office@kei-ha.co.jp