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

ウォータフォールのまとめ

**************************************************************
_/_/_/_/_/_/_/ ソフトウェア業界　新航海術 _/_/_/_/_/_/_/_/_/
**************************************************************
第72号 2005/04/25
▼ まえがき
▼ [保存できないエディタ]　ウォータフォール型のまとめ(計画・設計)
▼ [保存できないエディタ]　ウォータフォール型のまとめ(製造)
▼ [保存できないエディタ]　仕様変更のコストは誰が負担するのか？
▼ [保存できないエディタ]　ウォータフォール型に対する批判への反論
▼ [保存できないエディタ]　低価格化・短納期化圧力とウォータフォール型
▼ お奨めメルマガ情報
▼ 次回以降の予告

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

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

第57号から「まぐまぐ！」での読者数が急に増えてきました。
第56号までは200名だったのに、今では354名です。
読者も「日本のソフトウェア請負開発は何かおかしい」という思いを
お持ちなのだと思います。

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

「5年後のシステム開発」シリーズから独立させて、「保存できない
エディタ」シリーズとしました。
まとめて読みたい方は下記URLを参照してください。
http://www.kei-it.com/sailing/back_editor.html

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

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

*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=
[保存できないエディタ]　ウォータフォール型のまとめ(計画・設計)
*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=

長かったこのシリーズもいよいよ、まとめの段階となりました。
あと２，３回、おつきあいください。

本号では、ウォータフォール型開発プロセスについてまとめてみます。
図　http://www.kei-it.com/sailing/pdf/72-050425.pdf を参照し
ながら読んでください。

ウォータフォール型開発プロセスでは、次に示すように、計画・設計・
製造を明確に分割して開発の行います。

【計画】
まず最初に、ユーザと請負業者は協同で要求仕様をリストアップし、
凍結します。
この作業は必ずしも請負契約によるものではなく、業者からの営業提案
として無償で行われる場合もあります。

【設計】
次にユーザと請負業者は仕様設計のための請負契約を結びます。
仕様設計は、外部設計・内部設計・プロトタイピングにより行われ、
それらは並行して行われます。

外部設計はユーザの視点で製品を記述する作業、内部設計は製品内部の
仕組みを記述する作業です。
外部設計と内部設計については、第68号を参照してください。
http://www.kei-it.com/sailing/68-050328.html

プロトタイピングは、第69号を参照してください。
http://www.kei-it.com/sailing/69-050404.html

上記作業によって完成した仕様を顧客がレビューし、それらの検収、
署名(日本では捺印)後に、請負業者は製品の製作費用について見積もりを
作成します。

*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=
[保存できないエディタ]　ウォータフォール型のまとめ(製造)
*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=

【製造】
ユーザと請負業者は製造に関する請負契約を結びます。
その内容は、設計作業で完成した仕様どおりに請負業者が製品を作り、
ユーザがその対価を支払うというものです。
その際、受け入れテスト項目を契約で規定しておきます。
(受け入れテスト項目の詳細までは必要ありません。)

請負業者は、詳細設計、コーディング(ホワイトボックステストを含む)、
ブラックボックステストを行い、製品を完成させます。
これらの手順は請負業者に任せられます。

製造を、詳細設計、コーディング、テスト計画書作成、テスト仕様書作成、
・・・という具合に細かく工程を区切り、工程の単位でドキュメント
を完成させ、各工程が終了してから次の工程に進むというやり方でも
構わないし、Cem Kanerが「基本から学ぶソフトウェアテスト」で強く
薦めているように、プロジェクト全体としてはウォータフォール型で
あってもブラックボックステストは漸増型風にやるという方法でも
構わないのです。
プロジェクトの難易度・納期・予算・人的リソースなどを考慮して、
プロジェクトマネージャが決めてよいのです。

ウォータフォール型をウォータフォール型たらしめている最大の
特長は、「製造前に仕様設計が完了している」です。
それさえあれば、製造以降を部分的に漸増型風に進めても、プロジェクト
全体としてはウォータフォール型だと言えるのです。

そして、製造前に仕様設計が完了しているが故に、その完成仕様に基づく
請負契約が可能となり、ユーザによる最終受け入れテストが必須となる
のです。
最終受け入れテストについては、第71号を参照してください。
http://www.kei-it.com/sailing/71-050418.html

*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=
[保存できないエディタ]　仕様変更のコストは誰が負担するのか？
*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=

「ウォータフォール型では製造前に仕様設計を完成させる」と言っても、
設計フェーズで完成された仕様が、製造フェーズで変更になり、手戻り
が発生することはよくあります。
この手戻りのコストは、設計承認した以上、発注者が負担しなければ
なりません。

ただし、その仕様変更が設計時の仕様バグによるものであるなら、
請負業者は設計フェーズの請負契約についての契約責任(瑕疵担保責任)
を問われる可能性があります。
しかし、そこで求められることは、設計書を無償で書き直すことであり、
コーディングのやり直しまで無償で行わなければならないということ
ではないのです。

仮に、それが非常に重大な仕様バグであり、損害賠償を求められた
としても、その損害賠償額は設計の請負のために既に支払われた金額を
超えることはないでしょう。

したがって、第57号の設問の答えの半分は、「ウォータフォール型で
行われたのなら有償追加」なのです。

*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=
[保存できないエディタ]　ウォータフォール型に対する批判への反論
*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=

仕様変更は必ず発生します。
上流工程で下流工程の全てを見通すことは不可能だからです。
そして、ここから「ウォータフォール型は製造前に仕様設計が完了する
ことを前提としているから非現実的だ」という批判が生まれます。

しかし、確かに上流工程で下流工程の全てを見通すことは不可能ですが、
全てがやってみないと分からないということもありません。
見通そうとすれば見通せる部分も大きいのです。
ウォータフォール型開発プロセスとは、ユーザと請負業者に先を見通す
努力を強制する仕組みでもあるのです。

また、「ウォータフォール型はプロジェクトの最終局面にならないと
ユーザが完成イメージをつかめないが故に、仕様変更が多発する」
という批判もあります。
しかし、だからこそ、設計時にプロトタイプを作成し、早期にユーザに
完成イメージを提示するのです。

また、「ウォータフォール型はプロジェクト後半にならないとテストを
開始できず、テストと修正の工数が予測できない」という批判もあります。
しかし、ホワイトボックステストはプログラミング工程の一部として
行えばよいし、ブラックボックステストもインクリメンタルに行えば
よいのです。

*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=
[保存できないエディタ]　低価格化・短納期化圧力とウォータフォール型
*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=

グローバル化と標準化に起因する強烈な低価格化・短納期化圧力が
存在します。
（第8号　http://www.kei-it.com/sailing/08-040126.html　参照）
そして、ウォータフォール型はこの強烈な低価格化・短納期化圧力に
対応できないという批判もあります。

確かにこれらの圧力に対応する一つの方向は、現在マスコミが喧伝
しているアジャイルやセル方式などかもしれません。

しかし、もう一つ、「得意分野に特化した会社同士の効率的な分業」
という方向もあります。
そこには、国際的な分業、つまりオフショアも含まれます。
そして、会社間の請負契約による分業には、本号で解説した柔軟で
正しいウォータフォール型開発プロセスが不可欠なのです。

*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=
　お奨めメルマガ情報
*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=

読者の末富昌幸氏から「実は、私もこのたび、下記のメルマガを創刊
しました」というメールをいただきました。

◆●◆ 中国オフショア開発最前線-中国ソフトウェア産業の実像 ◆●◆
　中国でのソフトウェア開発をお考えの方、悪戦苦闘中の方は必見！
　本メルマガでは、中国ソフトウェア産業の実像に迫る情報や中国オフショア
開発に関する生きた情報、成功ポイント、契約・交渉実務関連情報、中国
現地企業の人材育成情報等々を満載して、上海現地からタイムリーにお届け
しています！
中国オフショア開発サポートサイト→http://www.jp-snic.com
中国オフショア開発Q&A50問50答→http://www.jp-snic.com/q&a/Q&A.html
購読登録はこちら→http://www.mag2.com/m/0000153053.html

先に書いたとおり、私は強烈な低価格化・短納期化圧力に対応する
一つの方向としてオフショアは大きな可能性があると思っています。

また、ここのところ日中関係が緊張しているので、私も最近は新聞を
読んでもまず中国関係の記事に目が行ってしまいます。
実際に中国で活躍されている末富氏からの中国情報は非常に参考に
なります。

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

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

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

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

乞うご期待！！

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

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

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

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

このメルマガに対するご感想・ご質問はこちらにお寄せください。
　　　　　　　　　　　 office@kei-ha.co.jp
--------------------------------------------------
このメールマガジンは『まぐまぐ！』 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

☆　コピーや配布をされる時はご一報ください　☆

テストの分類

**************************************************************
_/_/_/_/_/_/_/ ソフトウェア業界　新航海術 _/_/_/_/_/_/_/_/_/
**************************************************************
第71号 2005/04/18
▼ まえがき
▼ [保存できないエディタ]　テストの大分類
▼ [保存できないエディタ]　ホワイトボックステスト
▼ [保存できないエディタ]　ブラックボックステスト
▼ [保存できないエディタ]　最終受け入れテスト
▼ [保存できないエディタ]　次回以降の予告

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

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

第57号から「まぐまぐ！」での読者数が急に増えてきました。
第56号までは200名だったのに、今では338名です。
読者も「日本のソフトウェア請負開発は何かおかしい」という思いを
お持ちなのだと思います。

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

「5年後のシステム開発」シリーズから独立させて、「保存できない
エディタ」シリーズとしました。
まとめて読みたい方は下記URLを参照してください。
http://www.kei-it.com/sailing/back_editor.html

*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=
[保存できないエディタ]　テストの大分類
*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=

第70号では、「テストとテスト計画作成については、プロジェクト
全体がウォータフォール型であったとしても、漸増型で行うべきだ」
という「基本から学ぶソフトウェアテスト」の主張を紹介しましたが、
その詳細は書きませんでした。
前提として、テスト分類、ウォータフォール型でのテスト、漸増型
でのテストについての基礎知識が必要だからです。

本号ではテスト分類について取り上げます。

「基本から学ぶソフトウェアテスト」を読んで、意外だったことが幾つか
あります。
その一つは、日本の開発現場や情報処理試験でお馴染みの「単体テストと
結合テスト」「トップダウンテストとボトムアップテスト」というテーマが、
ほんの数行で片付けられているということです。

また、日本の請負契約で必ず契約書に記載される「検収」という概念が
全く記述されていないことも意外でした。

同書でのテストの大分類は下記のとおりです。

1.設計段階でのテスト
2.ホワイトボックステスト
3.回帰テスト
4.ブラックボックステスト

設計段階でのテストは主にレビューミーティングのこと、回帰テストは
バグ修正後の再テストのことです。
この両者、特に回帰テストが独立した大分類として扱われていることは
注目に値します。

また、日本で出版されている多くの書籍では、テストが「単体テスト→
結合テスト→システムテスト」という流れで説明されるのに対し、まず
大きくホワイトボックステストとブラックボックステストに分類している
ということも注目に値します。

*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=
[保存できないエディタ]　ホワイトボックステスト
*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=

ホワイトボックステストとは、プログラムの処理方式を考慮し、
ソースコードを利用してテスト項目を抽出するテストです。

ホワイトボックステストはさらに幾つかに分類されていますが、
その中で主なものは次の３つです。
・インクリメンタルテスト
・パステスト（パスを網羅するテスト）
・静的テスト（ウォークスルー、コードレビュー）

インクリメンタルテストは、いわゆる単体テストと結合テストのことです。

> インクリメンタルテスト法では、最初に単体を独立にテストする。
> プロセスやプログラムの最小構成単位をテストすることを、
> モジュールテスト、ユニットテスト、単体テストと呼ぶ。
> 単体同士を組み合わせるテストは、統合テストと呼ぶ。

このインクリメンタルテストの手法として、トップダウンテストと
ボトムアップテストがあります。
最上位のモジュールからテストするのがトップダウンテストで、
最下位のモジュールからテストするのがボトムアップテストです。
それぞれ、長所、短所がありますが、どちらを選択すべきかについては
「基本から学ぶソフトウェアテスト」では、あっさりと「実際には、
モジュールを書いたらすぐにテストするのが一般的なので、時には
ボトムアップで、時にはトップダウンだと言える」と書かれています。

また、ホワイトボックステストは、プログラミング工程の一部です。
「多数のプログラマが、システムに自分のモジュールを組み入れる前後で、
日常的にモジュールのホワイトボックステストをしているから」です。

日本の学者は、「ウォータフォール型開発プロセスでは、コーディング
が全て完了してから、テスト仕様書を作成し、それが完了してからでないと
テストに入れない」と説明していますが、それは間違いです。

ウォータフォール型でもホワイトボックステストはプログラミング
工程の中で行ってもよいのです。

*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=
[保存できないエディタ]　ブラックボックステスト
*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=

ブラックボックステストとは、プログラムを中身が見えないブラック
ボックスとして扱うテストです。

ブラックボックステストはさらに６つに分類されていますが、主な
ものは次の３つです。

・ベータテスト
・検証
・最終受け入れテスト

ベータテストとは、ターゲット市場を代表する人々を選び、実際の
製品と同じ使い方をしてもらって、コメントを集めることです。

検証とは、設計ドキュメントや仕様書と照らし合わせてチェックする
ことです。検証はさらに、次の二つに分類されます。
・機能テスト：外部仕様書どおりに動くことの検証
・システムテスト：ユーザ要求書やシステム要求書どおりに動くことの検証

「基本から学ぶソフトウェアテスト」では、機能テストとシステムテスト
で実行するテストとして、仕様確認テスト、操作性テスト、境界条件テスト、
性能テスト、日常業務テスト、負荷テスト、などの15種類を挙げています

*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=
[保存できないエディタ]　最終受け入れテスト
*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=

最終受け入れテストとは、ブラックボックステストの一つで、
受託開発特有のテストです。発注側が納入時に行うテストです。

> 小規模プロジェクトなら、このテストは非公式に行うかもしれないが、
> 大部分のプロジェクトでは、テストの詳細を事前に書面にして合意する。
> 納入前に、最終受け入れテストに合格することを必ず確認しなければ
> ならない。徹底的にシステムをチェックする訳ではないので、
> 最終受け入れテストは、丸1日もかからないのだ普通だ。

日本の場合、発注元が富士通やNEC等のメーカなら、購買部門が
最終受け入れテストを行います。しかし、それは形骸化されていて、
ほとんどは書類審査のみで、時間的にも30分位です。
発注元がエンドユーザの場合は、それすらありません。

請負契約締結時に最終受け入れテストのテスト項目を契約で規定する
こともありませんし、最終受け入れテストの詳細を事前に書面にして
合意することもありません。

その代わり、日本の請負契約では、ほとんど例外なく、検収期間
(たいがいは1ヶ月)を設けています。
発注元は検収期間中に最終受け入れテストを行い、それに合格すれば、
数十日後(この日数を「支払いサイト」と呼びます)に代金を支払います。

「基本から学ぶソフトウェアテスト」に検収に当たるものが書かれて
いないことから推測すると、米国では最終受け入れテスト後の障害は
契約責任(日本での瑕疵担保責任)で処理されるのだと思われます。

日本でも改正下請代金支払遅延等防止法が平成16年4月1日より施行
されたことにより、支払日の算出の起点は検収完了日ではなく納品日に
なりました。

納品時の最終受け入れテストはどうあるべきなのか、検収とは何なのか
（検収時の障害対応と瑕疵担保責任はどう違うのか）、別の機会に
論じます。

*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=
[保存できないエディタ]　次回以降の予告
*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=

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

・「全体がウォータフォールでもテストは漸増型で」の詳細。
・納品時の最終受け入れテストはどうあるべきなのか、検収とは何なのか。
・オーダーメイド開発の多い日本での漸増的開発はどのように考えたら
　よいのか？
・請負開発での重要なマイルストーンは「受け入れテスト項目の決定」。
・ウォータフォール型開発プロセスでの3つの契約の性格の違い。
・契約には違反していないが、製品として欠陥がある場合（第57号
　での例のような場合）の考え方。

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

乞うご期待！！

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

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

このメルマガに対するご感想・ご質問はこちらにお寄せください。
　　　　　　　　　　　 office@kei-ha.co.jp
--------------------------------------------------
このメールマガジンは『まぐまぐ！』 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

☆　コピーや配布をされる時はご一報ください　☆

全体がウォータフォールでもテストは漸増型

**************************************************************
_/_/_/_/_/_/_/ ソフトウェア業界　新航海術 _/_/_/_/_/_/_/_/_/
**************************************************************
第70号 2005/04/11
▼ まえがき
▼ [保存できないエディタ]　最初にアジャイルありきというアプローチ
▼ [保存できないエディタ]　最初に請負契約ありきというアプローチ
▼ [保存できないエディタ]　「取引関係において不可欠」という断定
▼ [保存できないエディタ]　全体がウォータフォールでもテストは漸増型で
▼ [保存できないエディタ]　次回以降の予告

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

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

第57号から「まぐまぐ！」での読者数が急に増えてきました。
第56号までは200名だったのに、今では335名です。
読者も「日本のソフトウェア請負開発は何かおかしい」という思いを
お持ちなのだと思います。

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

「5年後のシステム開発」シリーズから独立させて、「保存できない
エディタ」シリーズとしました。
まとめて読みたい方は下記URLを参照してください。
http://www.kei-it.com/sailing/back_editor.html

*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=
[保存できないエディタ]　最初にアジャイルありきというアプローチ
*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=

第69号では、日経システム構築4月号の「アジャイル開発に適した
契約形態とは？」という記事について、「全く答えになっていなかった」
と書きました。
( http://www.kei-it.com/sailing/69-050404.html　参照)

しかし、本文ではなく、画像の中に、アジャイルプロセス協議会の
「見積・契約ガイドライン」ワーキンググループの案が次のように
書かれていました。

・プロジェクトの初期段階は支援契約を結び、アジャイル開発が
　どのようなものか理解してもらう。
・1枚のストーリーカードごとに見積もるなどして請負契約を結ぶ。

これらの案は、最初にアジャイル開発（漸増型開発の一種）ありきで、
それと請負契約との折り合いをつけていこうというアプローチです。
これらの案については、次号以降で検討していきます。

尚、「初期は準委任、その後は請負」や「発注単位を小さくする」
というアイデアはけっして目新しいものではなく、10年前から言われて
いることです。

*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=
[保存できないエディタ]　最初に請負契約ありきというアプローチ
*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=

もう一つのアプローチがあります。
最初に請負契約ありきというアプローチです。

請負契約、そして、それに適したウォータフォール型開発プロセスを
前提として、「短納期・低価格・顧客満足」と折り合いを付けていこう
というアプローチです。

第69号で論じたように、プロトタイピングをウォータフォール型の
枠組みの中で効果的に取り入れていくということもその一つです。

さらに、漸増型の良いところをウォータフォールの枠組みの中に取り
入れていくことも検討されるべきでしょう。
その一つが、本号で述べる「プロジェクト全体はウォータフォール型、
テストは漸増型」という方法です。

*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=
[保存できないエディタ]　「取引関係において不可欠」という断定
*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=

第59号( http://www.kei-it.com/sailing/59-050124.html )にも記した
とおり、「保存できないエディタ」シリーズは、Cem Kaner,Jack Falk,
Hung Quoc Nguyen著「基本から学ぶソフトウェアテスト」(日経BP社発行)
を参考にしています。

Cem Kaner,Jack Falk,Hung Quoc Ngyenは、多くの日本の学者と違い、
ウォータフォール型開発プロセスを「悪」と決め付けるようなことは
していません。

純開発面では「深刻な遅延が発生しやすい」「膨大なテスト工数が予想
できない」などと厳しい指摘をしていますが、二者間契約という視点では、
「ウォータフォール開発プロセスはユーザとの取引関係において不可欠な
ものである」と断定しています。

また、開発面での問題点もけっして克服不可能だは言っていません。

> ウォータフォール開発プロセスの支持者は、開発初期に要求をしっかり
> 分析したうえで製品を設計し、きちんと計画を立てさえすればプロジェクト
> の失敗は防げると主張する。

> 受託型システムや組み込みソフトウェアのように作り直しが難しい
> 製品の場合は、プロジェクトの初期において仕様を詳細に確認すること、
> 適切な計画を立てることが特に重要となる。

*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=
[保存できないエディタ]　全体がウォータフォールでもテストは漸増型で
*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=

「市販ソフトウェア開発は漸増型開発プロセスが適し、受託型システム
開発はウォータフォール型開発プロセスが適する」というのが、
「基本から学ぶソフトウェアテスト」の基本的はスタンスです。
（おそらく、これが米国での標準的な考え方なのでしょう。）

しかし、同書は、テストとテスト計画作成については、プロジェクト
全体がウォータフォール型であったとしても、漸増型で行うべきだと
主張しています。

> テスト、特にテスト計画は、プログラムが進化型の方法で開発されたか
> どうかに関係なく、進化型で作成していくことが可能である。
> テスト計画作成とテストに対する進化型アプローチは、開発チームの
> その他の部分がウォータフォール開発プロセスのような方法に従っている
> 場合でも、筆者らの考えでは、通常はウォータフォール開発プロセスの
> ようなアプローチでテスト計画を作成するより効果的である。

これは非常に重要な手法です、
「膨大なテスト工数が予想できない」ことがウォータフォール開発
プロセスの最大の問題点の一つだからです。

この手法の詳細については、次号で解説します。

*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=
[保存できないエディタ]　次回以降の予告
*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=

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

・「全体がウォータフォールでもテストは漸増型で」の詳細。

・オーダーメイド開発の多い日本での漸増的開発はどのように考えたら
　よいのか？

・請負開発での重要なマイルストーンは「受け入れテスト項目の決定」。

・ウォータフォール型開発プロセスでの3つの契約の性格の違い。

・契約には違反していないが、製品として欠陥がある場合（第57号
　での例のような場合）の考え方。

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

乞うご期待！！

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

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

このメルマガに対するご感想・ご質問はこちらにお寄せください。
　　　　　　　　　　　 office@kei-ha.co.jp
--------------------------------------------------
このメールマガジンは『まぐまぐ！』 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

☆　コピーや配布をされる時はご一報ください　☆

プロトタイピング

**************************************************************
_/_/_/_/_/_/_/ ソフトウェア業界　新航海術 _/_/_/_/_/_/_/_/_/
**************************************************************
第69号 2005/04/04
▼ まえがき
▼ [保存できないエディタ]　日経システム構築4月号の期待はずれな記事
▼ [保存できないエディタ]　プロトタイピングは開発プロセスではない
▼ [保存できないエディタ]　プロトタイピングは製造ではなく、設計
▼ [保存できないエディタ]　プロトタイプのコードは破棄するのが原則
▼ [保存できないエディタ]　次回以降の予告

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

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

第57号から「まぐまぐ！」での読者数が急に増えてきました。
第56号までは200名だったのに、今では335名です。
読者も「日本のソフトウェア請負開発は何かおかしい」という思いを
お持ちなのだと思います。

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

「5年後のシステム開発」シリーズから独立させて、「保存できない
エディタ」シリーズとしました。
まとめて読みたい方は下記URLを参照してください。
http://www.kei-it.com/sailing/back_editor.html

*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=
[保存できないエディタ]　日経システム構築4月号の期待はずれな記事
*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=

日経システム構築4月号の「開発現場の『疑問』に答える」という
特集の中に「アジャイル開発に適した契約形態とは？」という記事が
載っていました。

冒頭で「(アジャイル開発は)従来型の開発契約形態がなじまないのである」
と書かれていたので、期待して読み進みましたが、結びは次のように
なっていました。

> アジャイルプロセス協議会では、アジャイルにマッチした契約手法を
> 模索中だ。

> 同協議会では、情報サービス産業協会(JISA)のモデル契約書を基に、
> よりアジャイル開発に適した契約書の策定に取り組んでいる。
> 成果がまとまり次第、公表する予定である。

記事のタイトルは「開発現場の『疑問』に答える」ですが、全く答えに
なっていません。

「ソフトウェア開発委託契約の契約と実務」(2002年7月JISA発行)と同様
期待はずれな内容でした。
第10号( http://www.kei-it.com/sailing/10-040209.html )参照。

「漸増的開発に適した契約形態とは？」という問題を解決するためには、
開発プロセスの本質についての理解が必要です。
今週号では、プロトタイピングを取り上げます。

*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=
[保存できないエディタ]　プロトタイピングは開発プロセスではない
*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=

多くの書籍やホームページでは、プロトタイピングをウォータフォール型
開発プロセスや漸増型開発プロセスと同じく、「開発プロセス」の一つ
として扱っています。

例：
http://www.stackasterisk.jp/tech/engineer/devp01_02.jsp
http://xn--n9q36mh1hnxuksz7wt.jp/AD14b-am/t33.html
http://pcweb.mycom.co.jp/series/stratesys/011/
http://www.pc-view.net/Outsourcing/030411/

しかし、これは間違いです。

ウォータフォール型開発プロセスや漸増型開発プロセスがシステムの
構想段階から稼動まで、さらに契約や営業までを対象とする開発プロセス
なのに対し、プロトタイピングは設計局面での一手法に過ぎません。
概念レベルは、開発プロセスではなく、外部設計や内部設計と同格です。

プロトタイピングは単独の開発プロセスではなく、他の開発プロセスに
組み込まれて、システムの機能やユーザインタフェースを製造前に評価
するために使用されます。

「ウォータフォール型開発プロセス＋プロトタイピング」も
「漸増型開発プロセス＋プロトタイピング」もあり得ます。

但し、漸増型開発プロセスでは実動可能なバージョンが開発の早い段階で
登場するので、機能の一部の性能面を個別に調査する必要があるとき以外は、
プロトタイピングの必要性はあまりありません。

それに対し、「ウォータフォール型開発プロセス＋プロトタイピング」
という組み合わせは、効果的な故に、広く普及しています。
開発の最後の段階にならないと実動可能な製品が登場しないという
ウォータフォール型開発プロセスの欠点を補うことができるからです。

*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=
[保存できないエディタ]　プロトタイピングは製造ではなく、設計
*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=

第68号で、「設計が承認されていないのにコーディングをするな」は
ウォータフォールの大原則だと書きました。
しかし、プロトタイピングではコードを書きます。
プロトタイピングがウォータフォール型開発プロセスに組み込まれた場合、
設計が承認されていないのコーディングしてもよいのでしょうか？

よいのです。なぜなら、プロトタイピングは製造ではなく、設計だからです。

例えば、ビルを建てるときに顧客がイメージをつかみやすいように、
100分の1の縮尺の模型を作っても、それは設計の一部であり、製造
ではありません。
あるいは、使用する部品の強度を調べるために、試作品を作って
実験するかもしれません。しかし、それも設計であり、製造ではあり
ません。

それに対し、漸増型開発プロセスでのアルファ版は、たとえ機能が
貧弱だとしても、「核となる小さな製品」つまり出荷可能な「製品」
なのです。プロトタイプは製品ではありません。

*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=
[保存できないエディタ]　プロトタイプのコードは破棄するのが原則
*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=

プロトタイプは製品ではないということは、「プロトタイプのコードは
製品版では使用しないのが原則」といういことを意味しています。

漸増型開発プロセスでのアルファ版は、熟慮された設計がなければ
なりません。きちんと柔軟性を組み込んでおかないと、機能を追加する
ときに大量の手戻りが発生してしまうからです。
（第66号「漸増的開発、失敗のシナリオ」参照。
http://www.kei-it.com/sailing/66-050314.html　）

それに対し、プロトタイプは製品ではないので、熟慮された設計は必要と
されません。

> 設計者がシステムモデルを作る場合に、急いでいい加減なコードを書く
> ことは許されるだろう。しかし、後でそのコードを捨てる必要がある。
> 　　　　　　　　　　　「基本から学ぶソフトウェアテスト」より

とはいうものの、実際には、日本でも米国でもプロトタイプのコードを
結果的に流用することはよくあります。

> プロトタイピングはコーディングとはみなさない。・・・(中略)・・・
> とはいえ、プロトタイプのかなりのソースコードを製品に流用している
> のが現状だ。
> 　　　　　　　　　　　「基本から学ぶソフトウェアテスト」より

*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=
[保存できないエディタ]　次回以降の予告
*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=

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

・オーダーメイド開発の多い日本での漸増的開発はどのように考えたら
　よいのか？

・請負開発での重要なマイルストーンは「受け入れテスト項目の決定」。

・ウォータフォール型開発プロセスでの3つの契約の性格の違い。

・契約には違反していないが、製品として欠陥がある場合（第57号
　での例のような場合）の考え方。

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

乞うご期待！！

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

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

このメルマガに対するご感想・ご質問はこちらにお寄せください。
　　　　　　　　　　　 office@kei-ha.co.jp
--------------------------------------------------
このメールマガジンは『まぐまぐ！』 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

☆　コピーや配布をされる時はご一報ください　☆