« December 2004 | Main | February 2005 »

January 2005

January 31, 2005

商品性、特定目的適合性に対する黙示の保証

**************************************************************
_/_/_/_/_/_/_/ ソフトウェア業界 新航海術 _/_/_/_/_/_/_/_/_/
**************************************************************
第60号 2005/01/31
▼ まえがき
▼ [保存できないエディタ] 明示的な保証
▼ [保存できないエディタ] 商品性に対する黙示の保証
▼ [保存できないエディタ] 特定目的適合性に対する黙示の保証
▼ [保存できないエディタ] 保証放棄
▼ [保存できないエディタ] 次回以降の予告


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

こんにちは、蒲生嘉達(がもう よしさと)です。
最近のできごとです。

(1)ソフト人脈
業界紙「ソフト人脈」1月25日号に、慶の「倍速開発」の記事と、慶が
加盟しているコンソーシアム「羅針盤21」の記事が掲載されました。
見出しは次のとおりです。
------------------------------------------

注目の開発手法 
Webシステム開発のコスト・工期を従来の約1/2に
------------------------------------------
羅針盤21
一致団結
システム開発会社12社集結 在庫管理システムを共同受注
------------------------------------------

(2)無償対応/有償対応アンケート
第57号で私が提起した問題について、メルマガ「新・中国ビジネス入門」
の発行者である幸地司氏がサイトでアンケートを実施しました。
非常に参考になりますので、下記URLを参照してください。

アンケート結果:
http://clickenquete.com/a/r.php?Q0003268C5aac

新・中国ビジネス入門:
http://www.ai-coach.com/cipmag.html

*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=
[保存できないエディタ] 明示的な保証
*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=

第59号では次の2点を述べました。
・品質を決める要素は魅力と不具合である。
・品質に関する約束のことを保証という。

今週号では、市販ソフトウェアの保証について解説します。

家電製品を買った人が、製造元に不良品の無料修理、交換、返品を
要求するとき、何を根拠に「これは不良品である」と言うのでしょうか?

販売用パンフレット、仕様書、ユーザマニュアル、パッケージの
記載内容、テレビでのCMなどです。
これらの文章、映像、音声によって明示された約束は、「明示的な
保証」です。

これは、車でも、玩具でも、パソコンでも、市販ソフトウェアでも
同じです。

*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=
[保存できないエディタ] 黙示の保証
*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=

しかし、保証は明示的なものだけではありません。
「黙示の保証」もあるのです。

「黙示の保証」という概念は米国においてはごく一般的なものであり、
米国企業の製品はハードウェアでもソフトウェアでも、その保証条件の
中でほぼ例外なく「黙示の保証」について言及しています。

ここでは二つだけ例を挙げます。

・iPod保証条件
http://store.apple.com/Catalog/Japan/Images/apple_ipod_warranty.html
「アップルは、特に一切の黙示保証をしないもとのし、これには商品性、
特定目的適合性に対する黙示の保証等を含むものですがこれに限るもの
ではありません。もし、黙示の保証に対する制限を法的に認めない地域
がある場合、黙示の保証は、本保証の期間に制限されます。」

・SUN MICROSYSTEMS, INC.バイナリコードライセンス契約書
http://www.java.com/ja/download/license.jsp
「本契約に明記されていない限り、商品性、特定目的への適合性、または
権利の非侵害性に関する黙示の保証を含む、すべての明示的または黙示
的な条件、表明および保証を否認します。ただし、これらの否認が法令
で認められていない場合はこの限りではありません。」


読者も試しにGoogle等の検索エンジンで「黙示の保証」で検索して
みてください。膨大な件数の文書がヒットします。
そして、それらの中身を見てみると、米国製品の保証条件、及びその
マネをした日本製品の保証条件のほとんどが「商品性、特定目的適合性
に対する黙示の保証」という同じ文言を使用していることに気付く
でしょう。

*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=
[保存できないエディタ] 商品性に対する黙示の保証
*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=

この「商品性、特定目的適合性に対する黙示の保証」とはいったい
何でしょうか?

まず「商品性に対する黙示の保証」について説明します。

これは、米国統一商事法典(U.C.C.)中の「売り手が小売商であった場合
その売買契約は商品が商品性を持つことを黙示的に保証する」という
規定に基づく保証です。
「商品が商品性を持つことを黙示的に保証する」と言われても、よく
分かりませんね。

ここの部分が「基本から学ぶソフトウェアテスト」(Cem Kaner,Jack Falk,
Hung Quoc Nguyen著)では次のように分かりやすく書かれています。

> 言い換えると、プログラムは一般のユーザの期待どおりに動かな
> ければならないということだ。ワープロは、テキストファイルが扱え、
> 分かりやすく画面に表示し、印刷もできなければならない。そして
> すべての機能は、普通の分別を持ち合わせているユーザがうんざり
> しない程度に使い勝手が良くなければならない。・・・(中略)・・・
> この「黙示の保証」はプログラムにバグが皆無であることまでは要求
> していない。ただし、プログラムは同等の機能を持つ製品との比較に
> おいて、信頼性に重大な欠陥があってはならない。またバグが通常の
> 使用方法を妨げてはならない。


*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=
[保存できないエディタ] 特定目的適合性に対する黙示の保証
*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=

次に「特定目的適合性に対する黙示の保証」について説明します。

これも米国統一商事法典中の「売り手が契約締結時、商品に要求される
特定の利用目的を知り得、適性な商品の選択および取付けについて、
買い手が売り手の専門知識と判断を信任したと認められる場合、
・・・(中略)・・・その特定目的に適合するという黙示の保証責任が
発生する」という規定に基づく保証です。

例えば、パソコンショップで客が「私はWindows98を使用しています。
Windows98で動く画像編集ソフトをください」と頼んだのに、店員が
Windows2000以上でないと動かないソフトを売ってしまった場合が
これにあたります。

*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=
[保存できないエディタ] 保証放棄
*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=

ここでもう一度、上記「iPod保証条件」や「SUN MICROSYSTEMS, INC.
バイナリコードライセンス契約書」を読んでください。
これらは、黙示の保証の存在自体は認めながらも、「黙示の保証はしない」
と言っているのです。このようなことは許されるのでしょうか?

「基本から学ぶソフトウェアテスト」によれば、米国各州によって
違いはありますが(iPod保証条件でも「黙示の保証に対する制限を
法的に認めない地域」という言葉があります)、ほとんどの州では、
保証の除外は良心的であれば可能であるとしているそうです。

ただし、明示的保証は放棄することができません。
パンフレットで保証したことを免責条項で取り消すことはできません。

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

第57号での有償追加派と無償追加派の対立は重要な問題を提起して
いるので、結論を出すのはあと数回かかります。
次回以降では次のようなことを順次解説していきます。
・市販ソフトウェアの保証と請負開発の保証の違い。
・ウォータフォール型開発プロセスと請負開発との密接な関係。
・漸増的開発プロセスと市販ソフトウェア開発との密接な関係。
・契約には違反していないが、製品として欠陥がある場合(第57号
 での例のような場合)の考え方。
・請負開発をインクリメンタルにやるためにはどうすればよいのか。


次号は、2月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サイトではバックナンバーの全文検索も可能です。)

|

January 24, 2005

品質とは

**************************************************************
_/_/_/_/_/_/_/ ソフトウェア業界 新航海術 _/_/_/_/_/_/_/_/_/
**************************************************************
第59号 2005/01/24
▼ まえがき
▼ [保存できないエディタ] 基本から学ぶソフトウェアテスト
▼ [保存できないエディタ] 品質とは
▼ [保存できないエディタ] 保証とは
▼ [保存できないエディタ] 次回以降の予告


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

こんにちは、蒲生嘉達(がもう よしさと)です。
最近のできごとです。

(1)無償対応/有償対応アンケート
第57号で私が提起した問題について、メルマガ「新・中国ビジネス入門」
の発行者である幸地司氏がサイトでアンケートを実施しています。
非常に参考になりますので、下記URLを参照してください。

アンケート結果:
http://clickenquete.com/a/r.php?Q0003268C5aac

関連するメルマガ:
http://www.ai-coach.com/backno/ciplatest.html
http://www.ai-coach.com/backno/cip0171.html


(2)ソフト人脈
ソフト人脈1月25日号に、慶の「倍速開発」の記事と、慶が加盟
しているコンソーシアム「羅針盤21」の記事が掲載される予定です。


*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=
[保存できないエディタ] 基本から学ぶソフトウェアテスト
*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=

第57号以降は下記の本を参考にしています。

 「基本から学ぶソフトウェアテスト」
 Cem Kaner,Jack Falk,Hung Quoc Nguyen著
 日経BP社発行

米国では1999年、日本では2001年に出版された本です。

日経BP社の宣伝文句では「世界で最もたくさん読まれているソフト
ウェアテスト技術の決定版的教科書」ですが、Amazon.co.jpの
カスタマーレビューでは、「技術として目新しいものや、生産工程の
省略に繋がるものはない」とか「カタログみたいな本」といった
批判的な記事も載っています。
http://www.amazon.co.jp/exec/obidos/ASIN/4822281132/249-4981904-2459539

実際に教科書的なだけに、網羅的で、分厚いです。
本メルマガの読者が読んでも多分退屈するでしょう。
なにぶん500ページ近い大著なので、私も全部は読んでいません。
しかし、下記の章では、品質、テスト、開発プロセス、法的責任に
ついての米国での基本的で一般的な考え方が公平に述べられている
ので、参考になりました。

 第4章 ソフトウェアエラー
 第12章 テスト計画とドキュメント
 第13章 開発全体におけるテストの役割
 第14章 ソフトウェアの不具合に対する法的責任
 第15章 テストチームの管理

*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=
[保存できないエディタ] 品質とは
*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=

下記は二つとも「基本から学ぶソフトウェアテスト」からの引用です。

> 魅力と不具合は両方で品質を決めているもので、どちらか一方が
> 絶対というわけではない。

> 品質とは、幅広い概念である。品質の高い製品は、顧客の望む機能を
> 備えており、不具合とも無縁である。


昔のMACは(今もそうかもしれませんが)、しょっちゅうフリーズして
いました。
初期のUNIXは同時期に存在していたオフコンに比べてバグの多い代物でした。
初期のウォークマンは故障の多い製品でした。
しかし、それらがユーザに広く受け入れられた理由は、それらが魅力的
だったからです。それらは、魅力的な機能を備えているという意味で
品質の良い製品だったのです。

一方、1980年代に日本の工業製品が世界中を席捲した理由の多くは、
それらが他国の製品に比べて革新的な機能を備えていたからというよりも、
故障しなかったからです。
それらは、不具合が少ないという意味で品質の良い製品だったのです。

「品質が良い」という言葉は、「魅力的だ」という意味と「不具合が少ない」
という両方の意味で使われます。
両方とも兼ね備えているのがベストですが、両者は時にはトレードオフの
関係にもなり得るものです。
革新的で魅力的な製品ほど、不具合も多くなりがちだからです。

*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=
[保存できないエディタ] 保証とは
*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=

下記も「基本から学ぶソフトウェアテスト」からの引用です。

> 製品の品質と性能に関する約束のことを保証という。


製品はそれを購入した人が期待していた機能の全てを備えていなければ
ならないのでしょうか?
また、不具合は皆無でなければならないのでしょうか?

いずれも不可能です。
したがって、製品を顧客に販売するに当たって「ここまでなら品質を
保証します」という約束が必要となるのです。
「保証」とはこの約束のことです。

そして、この保証の範囲が、市販ソフトウェアと請負開発とでは
大きく異なるのです。

例えば、第57号で無償追加派で持ち出している「黙示の仕様」という
概念は、市販ソフトウェアでのみ適用される概念なのです。
(詳細は次号以降で)


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

第57号での有償追加派と無償追加派の対立は重要な問題を提起して
いるので、結論を出すのはあと数回かかります。
次回以降では次のようなことを順次解説していきます。
・市販ソフトウェアの保証と請負開発の保証の違い。
・ウォータフォール型開発プロセスと請負開発との密接な関係。
・漸増的開発プロセスと市販ソフトウェア開発との密接な関係。
・契約には違反していないが、製品として欠陥がある場合(第57号
 での例のような場合)の考え方。
・請負開発をインクリメンタルにやるためにはどうすればよいのか。


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

乞うご期待!!

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

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

|

January 17, 2005

請負開発のあるべき論の不在

**************************************************************
_/_/_/_/_/_/_/ ソフトウェア業界 新航海術 _/_/_/_/_/_/_/_/_/
**************************************************************
第58号 2005/01/17
▼ まえがき
▼ [保存できないエディタ] 第57号の反響
▼ [保存できないエディタ] 技術書、マスコミのウソ
▼ [保存できないエディタ] 請負開発のあるべき論の不在
▼ [保存できないエディタ] マスコミの論調とそれに反する声
▼ 次回以降の予告


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

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

・IT Proに「“倍速開発”掲げるソフトハウスの慶、自社フレーム
 ワークを社外提供へ」という記事が載りました。
 http://itpro.nikkeibp.co.jp/free/NC/NEWS/20050106/154491/ 参照。

・ソフト人脈1月25日号に、慶の「倍速開発」の記事と、慶が加盟
 しているコンソーシアム「羅針盤21」の記事が掲載される予定です。


*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=
[保存できないエディタ] 第57号の反響
*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=

第57号について多くの方々からご感想をいただきました。
例えば、次のような・・・。

「次回1月17日発行号、楽しみにしております」(ソフト会社営業マン)

「面白かったです。中国オフショアで似たようなことがあったんですよ。
当然あると思っていた機能がなくて、それを指摘したら、『仕様書に
書かれていない』なんと言われてしまって・・・。」
(ソフト会社取締役)

また下記のご意見をメールでいただきました。

○汎用機系SEのKMさんのご意見

> 私の意見は、請負契約でのことであれば、
> 基本は有償追加に賛成します。
>
> 仕様を決めるにあたってどちらに落ち度があったとしても、
> 合意してハンコをついたら、それをオーソライズして動くのが
> 基本だと考えます。
> 現在の(日本の?)ソフトウェア業界(とユーザー)の社会認識・
> 哲学がそうなっていないのなら、それは変えていかなければならない、
> と考えます。
>
> 商売上、「競争社会を生き残っていく」うえで、無償追加をする人・
> 会社が目の前にいたとしたら、その振る舞いの頭から尾までを非難する
> ことは自分は出来ません。
>
> でもそれは、少し前のガソリンスタンドがバタバタと倒産していくにも
> かかわらず売値を下げていった道・発想と同じものだと考えます。

○ERPコンサルタントのHNさんのご意見

> 合意した仕様書に明記されない機能付加についてですが、
>
> このケースで言えば最善の方法は、仕様書作成の時点で
> SEないしコンサルタント等が保存の機能について、本当に
> 必要がないかユーザーに確認すべきだったと思います。
>
> ユーザーが仕様書(詳細設計)段階で仕様の漏れについて
> 指摘できることはそうそうないと思います。
>
> こういった行き違いを回避するためには、概要設計書で
> そのシステムの目的を、誰が読んでも誤解が起こらない
> 文章でまとめることが大切だと思います。
> そして開発者も含めて概要設計を読んで内容を理解して
> いれば、必要と思われる機能が漏れていることに気が
> つくことがあるかもしれません。これは経験が物を言う
> ところかもしれませんが。
>
> こういう部分で付加価値をつけて顧客満足を得ることが、
> 会社または個人への信頼となり、次の取引につながって
> いくのだと思います。


*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=
[保存できないエディタ] 技術書、マスコミのウソ
*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=

見出しを「技術書、マスコミのウソ」としましたが、記事を書いている
人々には嘘をつく意図はないと思います。
また、書かれていることの多くは、それ自体は事実です。
しかし、全体的に情報が偏るから、情報を受け取る側が注意しないと
判断を誤る可能性があるのです。

情報が偏っている典型的な例として、汎用機の扱いがあります。

「世界中で動いているプログラムの70%は今でもCOBOLで書かれている」
と言われます。この数字の根拠は不明ですが、汎用機が今でも重要な
存在であり、多くの分野でUNIXやPCの挑戦を退けているということは
事実です。
しかし、インターネットでも書籍でも世の中に流通している情報の中で、
汎用機が占める比重は極端に少ないのです。
したがって、汎用機の重要性を過小評価してしまう危険性があるのです。

それが原因かどうかは分かりませんが、国産メーカのいくつかは
汎用機から撤退し、残りも積極的な投資をしなくなりました。
一方IBMは逆に、汎用機を強化し、PCから撤退しました。
その結果、汎用機の世界は再びIBM寡占状態に向かっています。

*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=
[保存できないエディタ] 請負開発のあるべき論の不在
*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=

汎用機に関する情報が極端に少ないのと同様、「請負開発」も技術書や
マスコミにはほとんど登場しません。

エンピリカルやアジャイルなどの開発方法論はインターネットでも
書籍でも無数に存在するのに、請負開発のあるべき姿についての考察は
ほとんど存在しません。若干あるとしたら、「請負契約書の書き方」
といった類であり、これらは請負開発全体の中で極めて限定した部分を
扱っているにすぎません。
例えば、「アメリカで請負開発はどのように行われているのか」と
いったことを調査しようとしても適当な資料がなかなか見つからないのです。
(第10号 http://www.kei-it.com/sailing/10-040209.html 参照)

日経○○の記事も、請負業者の視点ではなく、発注者の視点で書かれて
います。
開発段階では実際には請負業者が主導権を握り、多くの提案をし、
非常に苦労したとしても、それは記事にはならないのです。
システム開発を企画し、発注した会社名と担当者の顔が華々しく
載るのに対し、請負会社は名前すら載らない場合がほとんどです。

確かに請負会社は発注者の意思を実現する下請け業者に過ぎません。
もともと華やかな存在ではないのです。
しかし、請負開発のあるべき姿が技術書や技術系マスコミで論じられない
理由は、それだけではないと思います。

日本の技術書や技術系マスコミは、アメリカ発の技術情報に基づいて
書かれています。そのアメリカ発の技術情報のほとんどがパッケージや
商品の開発を前提としているということが、もう一つの理由だと思います。
アメリカは日本以上にパッケージや商品が重視されているのかも
しれません。
また、アメリカでの情報発信者は学者か企業にいる研究者であり、
彼らは請負開発という、契約や金が絡む非技術的で世俗的な分野は
書きたがらないのかもしれません。

*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=
[保存できないエディタ] マスコミの論調とそれに反する声
*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=

私は第51号で、WEDGEの12月号の「SE、プログラマー150万人 
大失業時代がやってくる」という記事を紹介しました。
http://www.kei-it.com/sailing/51-041129.html 参照。

その記事の内容は端的に言えば「日本のシステム開発はウォータ
フォール開発プロセスを引きずっているからダメで、海外では新しい
開発プロセスを導入しているから生産性が高い」というものでした。
実は、これは今の日本の技術系マスコミの代表的な論調でもあるのです。

下記は日経コンピュータ12月13日号の特集記事「日本のソフト
開発力を取り戻せ」からの引用です。
http://store.nikkeibp.co.jp/mokuji/nc615.html 参照)

> 大規模ソフト開発技術は、いまだにハードウェアにおけるコンベヤ
> 式生産を目指している。工程を分断し、一部外注するケースも多い。
> これでは顧客からの変更に対応しにくいうえに、品質の低下や
> コストの上昇を招きかねない。
> この問題の解決策として、組み立て生産工程で採用されている
> セル生産方式の考え方をソフト開発に応用する手法を提案する。

WEDGEよりも複雑な書き方をしていますが、要するにWEDGEの記事と同じく
「日本はウォータフォールだからダメだ」と言っているのです。

しかし、マスコミのこのような大きな声にかき消されそうになり
ながらも、それとは正反対の次のような声も聞こえてきます。

・海外でもウォータフォールが主流です。
(WEDGEの記事に反発したインターネット上の書き込み)

・ウォータフォール開発プロセスはユーザとの取引関係において
 不可欠なものである。
(Cem Kaner,Jack Falk,Hung Quoc Nguyen「基本から学ぶソフトウェア
 テスト」より)

・(中国オフショアでは)ドキュメントが「主」、プロトタイプは「従」。
(幸地司氏のメルマガ「新・中国ビジネス入門」より)
 http://www.ai-coach.com/backno/cip0144.html 参照。

・中国オフショアでは、日本のソフトウェア会社よりもアメリカの
 ソフトウェア会社の方が厳密な仕様書を作ります。
(中国オフショアを行っているソフトウェア会社のSEから聞いた話)

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

第57号での有償追加派と無償追加派の対立は下記の重要な問題を
提起しています。

・請負開発で納品したプログラムは商品かサービスか?
・商品かサービスかによって保証の差はあるのか?
・ソフトウェアのバグとは「仕様に合っていないこと」なのか?
 それとも「エンドユーザが期待しているような動作をしないこと」なのか?
・製造前の仕様凍結を前提としたウォータフォール型開発プロセスは、
 請負開発において不可欠なのか?

考察は次号に続きます。


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

乞うご期待!!


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

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

|

January 10, 2005

一括請負の仕様バグ

**************************************************************
_/_/_/_/_/_/_/ ソフトウェア業界 新航海術 _/_/_/_/_/_/_/_/_/
**************************************************************
第57号 2005/01/10
▼ まえがき
▼ [保存できないエディタ] 一括請負の仕様バグ
▼ [保存できないエディタ] 有償追加派の言い分
▼ [保存できないエディタ] 無償追加派の言い分
▼ [保存できないエディタ] 読者の見解募集
▼ 次回以降の予告


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

蒲生嘉達です。

IT Proに「“倍速開発”掲げるソフトハウスの慶、自社フレーム
ワークを社外提供へ」という記事が載りました。
http://itpro.nikkeibp.co.jp/free/NC/NEWS/20050106/154491/ 参照。
この記事は日経コンピュータEXPRESSのトップページ「ニュース」
http://itpro.nikkeibp.co.jp/NC/ からリンクされています。


さて、これから数回にわたるテーマは次のとおりです。

(1)請負開発(準委任を含む)の本来あるべき姿を明らかにします。
(2)ソフトウェアにおける品質管理(QC)。
(3)慶ITサービス事業部を具体例として、準委任を中心とする
 ソフトウェア会社の最適な組織について考察します。
(4)慶WEBシステム開発事業部を具体例として、一括請負を中心とする
 ソフトウェア会社の最適な組織について考察します。

これらのテーマは相互に関連しています。


*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=
[保存できないエディタ] 一括請負の仕様バグ
*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=

請負開発の本来あるべき姿を論じるきっかけとして、一括請負での
仕様バグについて考えてみます。

例えばシステムの一部にエディタ機能があり、要求仕様ではその機能は
「テキストファイルを読み込み、画面に表示し、編集し、印刷できること」
と書かれていたとしましょう。
保存機能については何も書かれていませんでした。

このシステム開発を請負った会社が、要求仕様どおり、保存機能の
無いプログラムを納品しました。
すると、顧客は、「エディタとして当たり前の機能なのだから」と
言って無償で機能追加することを要求してきました。

この要求に対して請負会社の社内でも有償追加派と無償追加派に意見が
分かれました。両者の言い分を聞いてみましょう。それぞれ正論です。


*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=
[保存できないエディタ] 有償追加派の言い分
*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=

我々(請負会社)は下記の約束をしています。
・納期までにプログラムを提供すること。
・そのプログラムが、約束した全ての機能を備えていること。
・また、しないと約束してる動作は一切しないこと。

たとえ、プロジェクトが赤字になったとしても我々は上記を保証します。
約束を守れなければ、契約不履行となり、損害賠償まで請求される
可能性もあるのです。

しかし、これは逆に言えば、「できると約束していないこと」は
できなくても契約違反にはならないということです。

ユーザは要求仕様について合意しました。
したがって、我々は仕様を満たすプログラムを書きさえすればよいのです。
いかなる変更も追加請求の対象となります。

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


*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=
[保存できないエディタ] 無償追加派の言い分
*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=

それに対し、無償追加派は次のように反論します。

そもそもソフトウェアの品質とは何でしょうか?
顧客の多くは、明確に仕様を定義してくれるわけではありません。
ソフトウェアの品質というものは顧客の満足度であって、仕様に
合っていることではありません。
ソフトウェアのバグとは、「仕様に合っていないこと」ではなく
「エンドユーザが期待しているような動作をしないこと」なのです。
エディタの保存機能などはごく一般的なユーザが期待する機能なので、
無償で機能追加しなければなりません。

また、請負会社は契約締結時、システムの利用目的を知り得たはずです。
システム開発の専門家なら、その利用目的から保存機能が必要である
ことは十分に推測できたはずです。
したがって、これはシステムの目的から導かれる黙示の仕様なのです。
やはり、無償で機能追加しなければなりません。


*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=
[保存できないエディタ] 読者の見解募集
*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=

「保存機能のないエディタ」はあまりにも極端な例ですが、
似たようなことは一括請負の現場でよくあることです。

例えば、去年、慶でも、顧客の現場担当者が作成した仕様どおり
プログラムを作成したところ、後からその担当者の上司に「あの仕様は
間違えていた。慶さんもシステム開発のプロならあの仕様がおかしい
と思ったはずです」と言われ、無償で追加変更を求められたことが
ありました。

さて、あなたは有償追加派でしょうか無償追加派でしょうか?
次号で私の見解を述べますが、読者の方々も見解をお持ちなら、
是非メールで教えて下さい。

本号は第10号 http://www.kei-it.com/sailing/10-040209.html
関連していますので、参考にしてください。


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

次号は、1月17日発行予定です。
有償追加、無償追加のどちらが正しいのか明らかにします。
乞うご期待!!


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

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

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

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


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

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

このメルマガに対するご感想・ご質問はこちらにお寄せください。
            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サイトではバックナンバーの全文検索も可能です。)

|

« December 2004 | Main | February 2005 »