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

**************************************************************
_/_/_/_/_/_/_/ ソフトウェア業界　新航海術 _/_/_/_/_/_/_/_/_/
**************************************************************
第64号 2005/02/28
▼ まえがき
▼ [保存できないエディタ]　創作活動として見たら、漸増型の方が自然
▼ [保存できないエディタ]　漸増型と請負契約との軋轢
▼ [保存できないエディタ]　仕様がない世界でのソフトウェア開発
▼ [保存できないエディタ]　次回以降の予告

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

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

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

*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=
[保存できないエディタ]　創作活動として見たら、漸増型の方が自然
*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=

漸増的開発については、本メルマガでもこれまでに何度も論じてきました。
例えば下記のとおり。

第6号　漸増的(ぜんぞうてき)開発
http://www.kei-it.com/sailing/06-040112.html

第11号　漸増的開発によって次の段階に／目を閉じて高速道路を運転する
http://www.kei-it.com/sailing/11-040216.html

第13号　読者からの質問
http://www.kei-it.com/sailing/13-040301.html

第22号　ウォーターフォールモデルと漸増的モデル／漸増的開発のきわどさ
http://www.kei-it.com/sailing/22-040503.html

上記で「ソフトウェア開発を創作活動として見た場合、漸増的開発
プロセスの方が自然だが、請負作業として見た場合は不自然」という
意味のことを書いてきました。

ソフトウェア開発は本の執筆のようなものであり、何度も書き直す
ことがむしろ普通です。したがって、ソフトウェア開発を創作活動
として見た場合、漸増的開発プロセスの方が自然なのです。

> ウォーターフォールモデルの欠点は、工程をまたがった反復が
> 行なわれず、その結果、できあがったものがユーザニーズから乖離
> してしまう可能性が高いという点です。
> 設計段階で全てが見通せるわけではなく、実装してみて初めて分かる
> ことも多いのに、下流から上流への流れを想定していないのです。
> ・・・（中略）・・・
> その欠点を是正するために漸増的開発が登場しました。
> 本の執筆のようにどんどん反復しようという手法です。
> （第22号　http://www.kei-it.com/sailing/22-040503.html　より）

*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=
[保存できないエディタ]　漸増型と請負契約との軋轢
*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=

しかし、漸増的開発プロセスでは、ウォータフォール開発プロセスと
異なり、ユーザが仕様承認のリスクを取りません。
したがって、必然的に下記の問題が発生します。
（第10号　http://www.kei-it.com/sailing/10-040209.html　参照）

(1)ユーザのニーズとシステム仕様が過不足なく合致している
　ということを誰がどのようにして確認できるのか？
(2)一度、決めた仕様がユーザニーズと合致していなかった場合、
　その責任の所在はどこにあるのか？
　（第57号での設問もこれに当たります。）
(3)仕様を決める作業が遅れ、システムの納入が遅れた場合、
　ユーザとベンダの責任はどのようになるのか？
(4)システムの開発をベンダに委託する場合、納入されたシステムの
　受入れ検査では、何を基準として検査が行われるのか？
(5)ベンダが仕様の確定を見込んで先行的に製造作業をスタート
　させたが、目論見が外れて仕様が変わり、手戻りが発生し、
　コストと開発時間に関する損失が発生した場合、その費用は
　誰が負担するのか？

これらの難問を検討する前に、漸増的開発プロセスが最も威力を
発揮する市販ソフトウェアの漸増的開発について一瞥しておきま
しょう。ヒントが見つかるかもしれません。

*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=
[保存できないエディタ]　仕様がない世界でのソフトウェア開発
*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=

第63号で述べたとおり、市販ソフトウェアの世界では、品質は「仕様に
合っていること」ではなく、「顧客満足」です。
そして、「顧客満足」は多様で、曖昧で、その上に気まぐれです。
仕様が完全な形で現れない世界、それらしきものが現れたかと思うと
すぐに変わってしまう世界なのです。

そこでは、仕様を仮定する作業から始まります。
市場調査、顧客調査、競合製品の分析などです。
これによって、方向性が固まります。

しかし、本当のことは最後まで分かりません。予想どおり売れるのか、
予想以上にヒットするのか、とんでもない思い違いをしていて全く
売れないのか、あるいは方向性を少し変えればうまくいきそうなのか・・・。

ウォータフォール開発プロセスでは発注者が仕様承認のリスクを
取りましたが、市販ソフトウェアの世界では開発会社が企画承認の
リスクを取るのです。このリスクを最小限に抑えるために、漸増的
開発プロセスが活用されます。

下記は「基本から学ぶソフトウェアテスト」(Cem Kaner,Jack Falk,
Hung Quoc Nguyen著)からの引用です。

・後から機能を追加できるように柔軟性のある設計を行い、核となる
　小さな製品を開発する。独立したプログラムとしてテストできるよう
　必要最小限の機能があればよい。
　競合製品との兼ね合いなどから追加したい機能はまだたくさんあるのに
　違いないが、市場の要求をぎりぎり満たしているレベルに達していると
　いうことに意味がある。

・その後ひとつずつ機能を拡張しテストを完了していくことで、製品
　としていつでも出荷可能なバージョンを確保しておくことができる。

・製品のイメージが固まるにつれて要求仕様を再確認し、設計を見直す
　ことが可能となる。

・必要最小限の機能を実装した製品は完成しているので、機能追加を
　あきらめるのは簡単である。ここで止めれば仕様検討や設計、コーディ
　ングの工数は発生しない。

・進化型開発プロセスで開発を進めると、進捗に応じた経営判断をする
　際に威力を発揮する。プロジェクトマネージャは、機能を追加して出荷を
　延ばすという選択肢と、機能追加をあきらめて納期を優先するという
　選択肢の２つから常に判断することができる。

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

次回以降では次のようなことを順次解説していきます。

・市販ソフトウェア開発に見る漸増的開発プロセスの基本形。
　（ウォータフォールと漸増型の比較をもう少し掘り下げます。）

・請負開発を漸増的に行うためにはどうすればよいか。

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

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

乞うご期待！！

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

本メルマガは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サイトではバックナンバーの全文検索も可能です。）

**************************************************************
_/_/_/_/_/_/_/ ソフトウェア業界　新航海術 _/_/_/_/_/_/_/_/_/
**************************************************************
第63号 2005/02/21
▼ まえがき
▼ [保存できないエディタ]　途中放棄の米国、品質低下の日本
▼ [保存できないエディタ]　第57号の設問対象が市販ソフトだったら
▼ [保存できないエディタ]　顧客の満足の気まぐれさ
▼ [保存できないエディタ]　次回以降の予告

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

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

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

*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=
[保存できないエディタ]　途中放棄の米国、品質低下の日本
*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=

第62号では「日本より米国の方がソフトウェア開発プロジェクトが
破綻するケースが多い」という前川徹氏の指摘を紹介しましたが、
保田勝通著「ソフトウェア品質管理の考え方と実際」（1995年日科技連
発行）の中でも次のような記述を見つけました。

> 米国でのいくつかの調査によれば、クライアント／サーバシステム
> 開発において55%が予算オーバー、68%が納期遅延であり、また
> 35%～50%が途中放棄されたという報告もある。

この数字は日経コンピュータ1995年2月6日号の「失敗相次ぐ大規模
開発　プロジェクト管理の徹底が急務」（ロシェル・ガーナー）という
記事を基にしています。
古いデータですが、予算オーバーと途中放棄の多さに驚きます。

読者の中で、同様なテーマでの米国の最新のデータをお持ちの方が
いらっしゃったら教えてください。

一方、日本ではプロジェクトの失敗で問題となる順番は、1.品質不良、
2.納期遅延、3.予算オーバーです。途中放棄はあまり聞きません。

例えば、日経コンピュータ2003年11月17日号「プロジェクト成功率は
26.7％　2003年情報化実態調査」という記事に1万2546社に対する
アンケート結果（回答企業1746件）が載っていました。
( http://itpro.nikkeibp.co.jp/free/NC/TOKU1/20031111/1/　参照）
そこでは、回答企業の76.2%がコスト面では満足しています。
ちなみに納期についての満足率は54.9%、品質については46.4%です。

これらの数字は第62号での次の説を裏付けています。

-------------------------------------
米国の請負開発では、設計承認のリスクをユーザが負うという
ウォータフォール開発プロセスの原則が守られているが故に、
予算超過のリスクの多くをユーザが負います。
そのため、予算を上積みしてもうまくいかなかったら、ユーザは
開発自体を途中放棄してしまいます。
一方、日本では請負業者が予算超過のリスクを負います。そのため
ユーザ側の開発予算は超過しません。しかし、品質が低下します。

*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=
[保存できないエディタ]　第57号の設問対象が市販ソフトだったら
*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=

現在の日本では、小規模請負開発の多くは漸増的開発プロセスで行わ
れています。
したがって、漸増的開発プロセスでの請負開発について話を進めたい
のですが、その前に市販ソフトウェア開発について解説します。
ウォータフォール開発プロセスが請負契約と密接な関係があるのに対し、
漸増的開発プロセスは市販ソフトウェア開発と密接な関係があるからです。

第60号では、市販ソフトウェアの保証には、「明示的な保証」と
「黙示の保証」とがあることを説明しました。
また、ほとんどの企業は商品の保証規定の中で、黙示の保証の放棄を
宣言していることも説明しました。
黙示の保証は現実には保証範囲の線引きが難しく、これを広く解釈
すれば、企業は莫大な損害賠償を要求される可能性があります。
したがって、米国の裁判所も良心的な黙示の保証の放棄は認めています。

しかし、黙示の保証の放棄が認められるのは法律の世界での話しです。
経済の世界では違います。

第57号の設問で製品が市販ソフトウェアだった場合を考えてください。
そしも、ある商品にユーザが「あって当たり前」と思っている機能が
なければ、ユーザはそのような商品に見向きもしません。
商品は売れず、開発会社は開発費をドブに捨てることになります。

また、知らずに買った人は様々な手段を通じて、メーカに対して
クレームをあげ、インターネットなどでも批判的な情報発信をする
でしょう。
開発会社が「販売用パンフレットやユーザマニュアルには『保存機能
がある』とは買いていません」と言っても、何の役にも立ちません。
さらにユーザの怒りを買うだけです。

その商品が売れないだけでなく、ブランドイメージも傷つくので、
その企業の他の商品にも影響が及びます。

したがって、開発会社は次のどちらかの選択を迫られることになります。
・開発費をドブに捨て、商品を回収し、撤退する。
・予算を追加し、機能追加し、既存ユーザには無償バージョンアップする。

*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=
[保存できないエディタ]　顧客の満足の気まぐれさ
*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=

第57号での無償追加派の下記の主張は、市販ソフトウェアの世界では
完全に正しいことです。

> ソフトウェアの品質というものは顧客の満足度であって、仕様に
> 合っていることではありません。
> ソフトウェアのバグとは、「仕様に合っていないこと」ではなく
> 「エンドユーザが期待しているような動作をしないこと」なのです。

しかし、顧客の満足度を目標にするなら、我々はその多様性、相対性、
曖昧さ、気まぐれさとも付き合わなければならないのです。

> 品質は誰かにとっての価値である。（ワインバーグ）

> 顧客満足度は我々のゴールである。しかし、顧客の視点は毎月
> でも変わりうる。（PRAXIS社マーチン・トマス氏）

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

次回以降では次のようなことを順次解説していきます。

・市販ソフトウェア開発に見る漸増的開発プロセスの基本形。
・漸増的開発プロセスと市販ソフトウェア開発との密接な関係。
・請負開発を漸増的に行うためにはどうすればよいか。

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

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

乞うご期待！！

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

本メルマガは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サイトではバックナンバーの全文検索も可能です。）

**************************************************************
_/_/_/_/_/_/_/ ソフトウェア業界　新航海術 _/_/_/_/_/_/_/_/_/
**************************************************************
第62号 2005/02/14
▼ まえがき
▼ [保存できないエディタ]　ウォータフォールへの批判
▼ [保存できないエディタ]　日本では請負業者がリスクを負担する
▼ [保存できないエディタ]　ウォータフォールでの契約の3段階
▼ [保存できないエディタ]　第57号の設問の答えの一部
▼ [保存できないエディタ]　米国の方がプロジェクト破綻が多い理由
▼ [保存できないエディタ]　次回以降の予告

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

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

第57号から「まぐまぐ！」での読者数が急に増えてきました。
第56号までは200名だったのに、今では269名です。
読者もそれだけ請負契約には苦しめられているということだと思います。

*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=
[保存できないエディタ]　ウォータフォールへの批判
*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=

ウォータフォール開発プロセスはこれまでに多くの学者や技術者から
批判されてきました。
例えば、ブルックスは1995年に書いた「人月の神話から二十年を経て」で
「ウォーターフォールモデルは間違いだ！」と断定しています。
また、ピート・マクブリーンは「ソフトウェア職人気質」の中で
「ウォーターフォール・アプローチは、危険かつ問題をはらんだ、企業
における風土病とも言えるものなのです」と厳しく批判しています。

しかし、第61号で解説したとおり、米国においても中規模以上の開発は
今でもウォータフォール型が主流です。また、オフショア開発の増加
により、米国においてもウォータフォール型はむしろ増えているとさえ
言われているのです。

これほど批判されるウォータフォールが何故今でも健在なのでしょうか？

答えは簡単です。
ウォータフォールは請負契約と相性がいいからです。

*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=
[保存できないエディタ]　日本では請負業者がリスクを負担する
*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=

日本の学者や技術系マスコミは、請負契約では請負業者が開発リスク
を負担すると説いています。

例を二つあげます。

下記は、日経コンピュータ2004年12月27日号「特集：見直し必須の
外部委託」からの引用です。

> 委託形態には、請負と準委任の2形態がある。請負は、成果物の
> 完成責任を委託先に負わせる契約で、委託した成果物に対して
> 費用が発生する。一方、準委任の場合は、委託先は成果物の完成
> 責任までは負わない。費用も労働に対する対価となる。
> ユーザ企業にとっては請負が有利、ベンダーにとっては準委任が
> 有利な委託契約とされる。

もう一つはインターネットで見つけた記事です。
( http://hotwired.goo.ne.jp/original/maegawa/050208/02.html 参照)
前川徹氏は「日本より米国の方がソフトウェア開発プロジェクトが
破綻するケースが多い」と指摘しています。ここで言う「破綻」とは、
開発中止という意味です。そして、その理由は契約方式の違いにある
と前川氏は述べています。その部分を引用します。

> 日本では、ソフトウェア開発は、一括して定額契約（請負契約）で
> 実施するケースが多いからである。この契約方式の場合、契約に定
> められた成果物を納入しないと対価が受け取れない。
> したがって、ベンダーは予算が超過しても、少しでもコストを回収
> しようと、システムが動くまで頑張ることになる。
> 一方、米国ではプロジェクトによって様々な契約が行われている。
> 例えば、実際に要したコストに適正な利潤を加えるタイプのコスト
> 保証型の契約の場合、プロジェクトの進捗に応じて経費が支払われる。
> この場合、プロジェクトが泥沼化すると、開発費は際限なく膨らんで
> いくことになる。

前川氏が言う「コスト保証型の契約」が日本での準委任契約に当たる
のかどうかは不明です。
しかし、日経コンピュータも前川氏も共通して、「請負契約では
請負業者が開発リスクを負担する」と考えています。
これが日本の学者や技術系マスコミの一般的な認識なのです。

*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=
[保存できないエディタ]　ウォータフォールでの契約の3段階
*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=

しかし、本当は、ウォータフォールで行われた請負開発では、開発
リスクの多くはユーザが負担するのです。

ウォータフォール開発プロセスは一般には次のように説明されます。

> システム全体を一括して管理し、分析・設計・実装・テスト・運用
> をこの順に行っていく。各工程が完了する際に、前の工程への逆戻
> りが起こらないよう、綿密なチェックを行なう。
> ( http://www.itmedia.co.jp/dict/software/develop/02921.html　より）

そして、「実際の開発作業では頻繁に逆戻りが発生するのに・・・」
と批判されます。技術論としてはその批判は正しいのです。

しかし、ウォータフォールはもともと請負開発のために考案された
モデルです。請負契約との関係を論じないと、ウォータフォールの
本質は理解できません。

ウォータフォール開発プロセスにおいては、契約には次の3段階が
あります。

[最初の契約]
要求仕様の事前調査のための契約です。
ユーザ、業者は要求仕様をリストアップし、凍結します。

[2番目の契約]
仕様設計のための契約です。
仕様検討時に、ユーザ、業者ともにしばしば仕様変更をします。
その結果、凍結された要求仕様の変更が発生したら、業者は追加
コストを請求できます。
顧客が仕様をレビューし、それらの検収、署名（日本の場合は捺印）
後に、業者は製品の製作費用について見積もりを作成します。

[3番目の契約]
業者は仕様どおりに製品を作り上げることを約束します。
業者は要求書、設計書に変更が入り、その結果コーディングし直さ
なければならない場合、追加の費用を請求できます。

*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=
[保存できないエディタ]　第57号の設問の答えの一部
*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=

さて、ようやく第57号で提起した問題の答えの一部を書けるように
なりました。

ウォータフォール開発プロセスで開発した場合には有償追加です。

ユーザが要求書、設計書に合意している以上、業者は仕様を満たす
プログラムを書きさえすればよいのです。

プログラムで一般的な使い方をする人が期待するごく基本的なこと
さえ、できなかったとしても、（それが要求仕様に含まれていないなら）
仕方がありません。仕様のバグを修正するには、顧客は追加料金を
払うしかないのです。

下記は「基本から学ぶソフトウェアテスト」(Cem Kaner,Jack Falk,
Hung Quoc Nguyen著)からの引用です。

・ウォータフォール開発プロセスはユーザとの取引関係において
　不可欠なものである。なぜなら、ユーザは考え方も要求もしばしば
　変えるし、たくさんの新規要求を出してもコストは増えないと思って
　いるからだ。また、コーディングが終わるまで仕様のレビューさえ
　しないのに、コーディングが終わると、全然気に入らないと言って
　きたりもする。

・もしユーザが設計承認しているなら、最終成果物が気に入らなくても、
　ユーザは対価を払わなければならない。

・ユーザはすべての変更に対する費用を払わなければならないため、
　変更依頼を慎重にする。

・ユーザにとって後工程になるほど変更が高くつくため、製品の仕上
　がりを待って不満を上げるのではなく、要求、仕様のレビューを
　するようになる。

*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=
[保存できないエディタ]　米国の方がプロジェクト破綻が多い理由
*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=

先ほど「日本より米国の方がソフトウェア開発プロジェクトが破綻
するケースが多い」という前川徹氏の指摘を紹介しました。
前川氏は、米国では請負契約ではないから開発費が際限なく膨らみ、
破綻すると説明していますが、第61号で解説したとおり、米国でも
中規模以上の開発は請負契約です。
米国の方がプロジェクト破綻が多いということが事実なら、その原因は、
米国では「開発リスクの多くをユーザが負担する」というウォータ
フォールの原則を忠実に守っているが故に開発費が際限なく膨らむ
ということでしょう。

また、日本の請負契約について前川氏は「ベンダーは予算が超過しても、
少しでもコストを回収しようと、システムが動くまで頑張る」と指摘
していました。そして、その理由を請負契約に求めていました。
しかし、ウォータフォール開発プロセスで予算超過のリスクを一方的に
請負業者が負うということはありません。
日本の学者や技術系マスコミが「日本はウォータフォールだからダメだ」
と言うにもかかわらず、日本の請負開発は本当のウォータフォール開発
ではなかったということなのです。

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

次回以降では次のようなことを順次解説していきます。

・漸増的開発プロセスと市販ソフトウェア開発との密接な関係。
　　漸増的開発プロセスの基本に戻り、請負開発を漸増的に行う
　　ためにはどうすればよいのか考えます。

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

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

乞うご期待！！

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

本メルマガは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サイトではバックナンバーの全文検索も可能です。）

**************************************************************
_/_/_/_/_/_/_/ ソフトウェア業界　新航海術 _/_/_/_/_/_/_/_/_/
**************************************************************
第61号 2005/02/07
▼ まえがき
▼ [保存できないエディタ]　米国では小規模開発は請負契約で行わない
▼ [保存できないエディタ]　米国ではウォータフォールは増えている（？）
▼ [保存できないエディタ]　次回以降の予告

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

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

下記はメルマガ「中国ビジネス入門 ～信頼と契約」からの引用です。

> ●日本の企業間取引は、ある意味、信頼関係でなりたっているといっ
> た文化的な側面があります。最近は、そうでもないかもしれませんが。
> でも、中国や韓国は、やはり契約主義的な性格が強く、信頼関係が
> あっても契約上で明記しておかないと問題になるケースがあります。
> ( http://www.ai-coach.com/backno/cip0179.html　参照）

オフショア開発でも国内の請負開発でも、請負開発についての原則を
理解した上で、現実の様々な事情に合わせた対応をする必要があります。

今週号から請負開発の保証について考えていきます。

*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=
[保存できないエディタ]　米国では小規模開発は請負契約で行わない
*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=

下記は「基本から学ぶソフトウェアテスト」(Cem Kaner,Jack Falk,
Hung Quoc Nguyen著)からの引用です。

> 数年前は、ほとんどのソフトウェアは請負契約によって開発され
> ていた。大規模プロジェクト、また多くの中規模プロジェクトは
> 今日でも請負契約によって開発されている。

この文章の前半は「数年前は、ほとんどのソフトウェアは請負契約に
よって開発されていたが、現在では市販ソフトウェアや小規模プロ
ジェクトは請負契約では開発されていない」と解釈できます。

近年、米国で市販ソフトウェア開発や小規模開発が請負契約で行われ
なくなったことが事実なら、その理由として次の二つが考えられます。

（１）漸増的開発プロセスの普及
市販ソフトウェア作成や小規模プロジェクトは漸増的開発プロセス
（進化的開発プロセス、反復的開発プロセスとも言います）で開発
されるようになりました。
漸増的開発プロセスでは、作りながら仕様を固めていくので、請負
契約にはなじまないのです。

> 市販ソフトウェアは、短期間に、比較的組織的でない方法で
> 開発されている。開発とテストは全ての仕様が完全になる前に
> 開始され、完全な仕様は存在しないかもしれず、プログラムの
> 全ての仕様を市場の要求があればすぐに変更する。
> 　　（「基本から学ぶソフトウェアテスト」より）

このような開発は請負契約ではやりにくいのです。
これは日本でも同じで、「完全な仕様は存在しないかもしれない」
というような開発は、社員、契約社員で行うか、外部委託するに
しても準委任契約で行う方が自然なのです。

（２）市販ソフトウェアの勢力
もう一つの理由として、米国では小規模プロジェクトの多くは市販
ソフトウェアまたは市販ソフトウェアのカスタマイズに置き換わった
ということが考えられます。
米国では日本よりもはるかに市販ソフトウェアの力が強いのです。
日本では各企業が個別に基幹システムや販売管理システムなどを
特注するのに対し、米国ではそれらのシステムもERP、SMCなどの
パッケージソフトで構築します。

*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=
[保存できないエディタ]　米国ではウォータフォールは増えている（？）
*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=

先の引用文の後半は、「大規模プロジェクト、また多くの中規模
プロジェクトは今日でも請負契約によって開発されている」です。

そして、これらのプロジェクトは今日でもウォータフォール型で開発
されています。

日本の学者や技術系マスコミは、ウォータフォールは時代遅れの開発
プロセスであり、米国では廃れているようなことを言います。
しかし、米国でも中規模以上のプロジェクトはウォータフォール型で
開発されています。それも日本以上に徹底したウォータフォール型で。

> 「本当のウォータフォール開発プロセス」では、テスト計画作成の
> 開始は、正式な変更管理とプロジェクト全体に対する通知プロセスに
> 従った、承認された、完全で、正確で、詳細な仕様書を受け取った時
> である。この状況は、市販ソフトウェアでは稀であるが、より大きい
> プロジェクトではそうでもない。
> 　　（「基本から学ぶソフトウェアテスト」より）

「詳細な仕様書」にかかる修飾語がたくさんある読みにくい文章ですね。
しかし、この文章から「本当のウォータフォール開発プロセス」は
今日の米国の請負開発でも珍しいものではないことが分かります。

もう一つインターネットで見つけた記事を紹介しましょう。
http://www.ogis-ri.co.jp/otc/hiroba/specials/ScottAmbler/interview20Nov2003.html#offshore

XPの提唱者であるスコット・アンブラー氏に対して、藤井拓氏が
2003年9月にインタビューした記事です。

「北米でウォータフォール型開発プロセスは減り、絶滅しそうな
状況なのでしょうか？」という質問に、スコット・アンブラー氏は
次のように答えています。

「絶滅しないでしょう。それどころか、オフショア開発にはウォータ
フォール型開発プロセスが適しているので、増えてさえいます。」

上記回答でスコット・アンブラー氏が本当に言いたいことは、
「ウォータフォール型開発はオフショア開発に移行するから、
米国の技術者はXPに移行しなさい」ということです。
そのことの当否はさておいて、この発言から、ウォータフォール型
開発プロセスが、今なお、米国においても健在であり、増えている
分野すらあるということが分かります。

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

第57号での有償追加派と無償追加派の対立は重要な問題を提起して
いるので、結論を出すのはあと数回かかります。
次回以降では次のようなことを順次解説していきます。

・ウォータフォール型開発プロセスと請負開発との密接な関係。
　　これだけ批判されるウォータフォールが何故廃れないのでしょうか？
　　開発プロセスを技術的側面からではなく、契約的側面から見ると、
　　ウォータフォールの別の顔が見えてきます。

・漸増的開発プロセスと市販ソフトウェア開発との密接な関係。
　　漸増的開発プロセスの基本に戻り、請負開発を漸増的に行う
　　ためにはどうすればよいのか考えます。

・市販ソフトウェアの保証と請負開発の保証の違い。

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

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

乞うご期待！！

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

本メルマガは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サイトではバックナンバーの全文検索も可能です。）