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

**************************************************************
_/_/_/_/_/_/_/ ソフトウェア業界　新航海術 _/_/_/_/_/_/_/_/_/
**************************************************************
第196号 2007/12/3
▼ まえがき
▼ [保存できないエディタ]　(1)4つの価値・12のプラクティス
▼ [保存できないエディタ]　(2)XPと他の開発プロセスとの違い
▼ [保存できないエディタ]　(3)プロセスとプラクティス
▼ [保存できないエディタ]　(4)プロセス中心のスタイル
▼ [保存できないエディタ]　(5)プロセス中心の欠点
▼ [保存できないエディタ]　(6)プラクティス中心の欠点
▼ 次回以降の予告

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

蒲生嘉達（がもうよしさと）です。

先週、第195号を書きながら、XP(eXtreme Programming)の「4つの価値」
を思い出しました。

第195号で述べた「良い製品を生み出す環境」はXPの4つの価値とも
似ていると思ったからです。

　第195号：共通の理解という原理に基づいて行動する
　http://kei-it.tea-nifty.com/sailing/2007/11/post_fce9.html

そこで、今回はXPを取り上げます。

*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=
[保存できないエディタ]　(1)4つの価値・12のプラクティス
*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=

XP(eXtreme Programming)の「4つの価値」は次のとおりです。

・コミュニケーション(Communication)
・シンプルさ(Simplicity)
・フィードバック(Feedback)
・勇気(Courage)

これらはシステム開発の基本方針のみならず、そのまま会社の基本方針
にもなり得る素晴らしい指針です。

XPではさらに下記の「12のプラクティス」を定義しています。

・計画ゲーム　　　　　　　　　・小さなリリース
・メタファー　　　　　　　　　・シンプルデザイン
・テスティング　　　　　　　　・リファクタリング
・ペアプログラミング　　　　　・共同所有権
・継続的インテグレーション　　・週40時間労働
・オンサイト顧客　　　　　　　・コーディング標準

*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=
[保存できないエディタ]　(2)XPと他の開発プロセスとの違い
*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=

XP(eXtreme Programming)をウォータフォール型開発プロセスに対する
アンチテーゼだと思っている人もいます。

しかし、XPと他の開発プロセスとの違いは、ウォータフォール型か
反復型かの違いではありません。
XPの対抗馬であるRUP(Rational Unified Prosess：ラショナル統一
プロセス)は、反復型開発プロセスの代表格です。

それでは、XPと他の開発プロセスとの違いは何でしょうか？

先ほど、XPで定義されている「12のプラクティス」を紹介しました。
ここで「プロセス」ではなく「プラクティス」という言葉が使われて
いることに注目してください。
ここにXPを理解する鍵があります。

XPと他の開発プロセスとの違いは、プロセス中心かプラクティス
中心かという違いです。

そして、「プロセス中心 VS プラクティス中心」という問題は、
ソフトウェア開発特有の問題ではありません。
様々なビジネスで昔から存在し、議論されている問題です。

XPの長所も短所も、プラクティス中心主義の一般的な性格として
説明することが可能です。

*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=
[保存できないエディタ]　(3)プロセスとプラクティス
*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=

プロセスとプラクティスの正確な定義について論じ出すと長くなる
ので、ここでは大雑把に次のように捉えてください。

プロセス：業務全体から見た個々の過程

プラクティス：個々の仕事のこなし方

*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=
[保存できないエディタ]　(4)プロセス中心のスタイル
*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=

プログラマの多くは「12のプラクティス」に感動するでしょう。

しかし、そのプログラマもやがてプロジェクトマネージャとなり、
複数のプロジェクトの管理をする立場になると、次のようなことを
やり出します。

・それぞれのプロジェクトを分析し、各種プロセスに分割する。
・個々のプロセスのインプットとアウトプットを規定する。
・各種プロセス内の作業項目を洗い出す。
・プロセス間、プロセス内の無駄な作業を排除する。
・個々の作業項目について、最も合理的なやり方を考え、作業量を
　見積もり、メンバーに仕事を割り振る。
・複数のプロジェクトで似かよった仕事は、同じ方式で行う。
・作業を可能な限り、定型化する。
・臨機応変の仕事や非公式の仕事を排除するというよりも、それを
　定型的な仕事に取り入れる。

これは管理者として正しい姿勢です。

そして、これがプロセス中心のスタイルなのです。

*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=
[保存できないエディタ]　(5)プロセス中心の欠点
*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=

ジョン・シーリー・ブラウンとポール・ドゥグッドは、「なぜITは
社会を変えないのか」の中で、プロセス中心の考え方を「組織に
しっかりとした形と方向性を与える」と高く評価しています。

しかし、同書の中で、彼らは、コピー機の保守技術者の行動を分析し、
厳格なプロセス中心主義を推し進めると下記の弊害が出てくるという
指摘もしています。

・技術者たちを「横方向の」資源(仲間同士の情報)から切り離してしまう。
・組織を臨機応変の行動や新しいアイデアに対して無関心にしてしまう。
・現場で起きている絶え間ない変化から、組織を切り離してしまう。

ソフトウェア開発においても、厳格なプロセス中心主義を推し進めると、
同様な弊害が出てきます。

XPはそれに対するアンチテーゼなのです。

「プラクティス中心で行こう！」という提案なのです。

*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=
[保存できないエディタ]　(6)プラクティス中心の欠点
*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=

それなら、プラクティス中心主義に欠点がないのかというと、
そのようなことはありません。

下記はジョン・シーリー・ブラウン、ポール・ドゥグッドが「なぜITは
社会を変えないのか」で指摘している、プラクティス中心の危険性です。

・既成の公式や構造の効用をあまり重視しなくなる。
・それ自身があまりにも独立して進化し、そのためにあまりにも
　ゆるやかに組織と「つながれた」状態になる。

XPもまたこのような危険性をはらんでいるのでしょう。

そして、ジョン・シーリー・ブラウン, ポール・ドゥグッドは、
プロセス中心とプラクティス中心のどちらかを選択するのではなく、
両者のバランスをとることが重要だと主張しています。

「グループがそれ自身の新しい知識を十分育てられるだけ緩やかでは
あるが、同時にその知識をプロセスに応用できるだけのしっかりした
つながりの構築」が必要だと主張しているのです。

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

次回発行予定は、12月中旬です。

乞うご期待！！

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

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

したがって、第一の読者としては、慶の社員（正社員・契約社員）及び
慶と契約している個人事業主を想定しています。

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

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

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

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

バックナンバーは、発行者サイトまたはブログで、体系として
見てもらいたいので、「まぐまぐ！」でのバックナンバー公開は
最新号のみとなっています。

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

☆筆者の趣味のブログ：身近にいる小動物の図鑑☆
　http://kei-it.tea-nifty.com/small/

--------------------------------------------------
発行：
株式会社 慶
　代表取締役 蒲生 嘉達

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

**************************************************************
_/_/_/_/_/_/_/ ソフトウェア業界　新航海術 _/_/_/_/_/_/_/_/_/
**************************************************************
第183号 2007/6/18
▼ まえがき
▼ [慶2.0]　(1)インドのERPコンサル会社
▼ [慶2.0]　(2)日本からのオフショア開発はChage Requestが多い
▼ [慶2.0]　(3)欧米のウォータフォール型開発プロセス
▼ [慶2.0]　(4)日本人は「すり合わせ」が得意
▼ [慶2.0]　(5)ソフトウェア請負開発での「あ・うんの呼吸」
▼ [慶2.0]　(6)AsIs(現状)とToBe(あるべき)
▼ 次回以降の予告

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

蒲生嘉達です。

今週号ではインドオフショアから始め、開発プロセスから経営方針に
至る広範囲な話をします。

*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=
[慶2.0]　(1)インドのERPコンサル会社
*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=

先日、インド企業Ｓ社の日本法人のマネージャＫ氏と会談する機会が
ありました。

Ｓ社は某ERP製品のコンサルティングからアドイン開発までを得意と
する会社です。

次のようなビジネスを展開しています。

・インド人ERPコンサルタントが日本で要件定義を行う。
・要件定義に基づいて推奨セットアップをする。
（ERPなのでパラメタでかなりのことができる。）
・顧客に実機で使ってもらい、不足した部分をアドイン開発する。
・アドイン開発では製造からユニットテストまでをインドで行う。
（但し、案件が小さい場合は、全て日本でオンサイト開発する。）

*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=
[慶2.0]　(2)日本からのオフショア開発はChage Requestが多い
*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=

Ｓ社は、ワールドワイドで上記サービスを展開している企業ですが、
Ｋ氏も日本のソフトウェア請負開発は特殊だと言っていました。

日本からのオフショア開発は、Chage Request が非常に多いという
のです。

欧米では「Functional Spec → Technical Spec」というプロセスを
採りますが、日本では、「概要設計 → 詳細設計」です。
ところが、「概要設計とFunctional Specとはイコールではない」と
Ｋ氏は言います。

Functional Specでは、日本の概要設計よりもはるかに詳細まで
記述され、Functional Specが完成すれば、顧客がサインします。
サインオフ後の変更は全てChange Requestであり、追加費用の対象
となります。

*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=
[慶2.0]　(3)欧米のウォータフォール型開発プロセス
*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=

次の点は「保存できないエディタ」シリーズで考察しました。

・日本の学者や技術系マスコミは「日本はウォータフォールだから
　ダメだ」と言うが、実際にはオフショア開発の増加によって、
　欧米ではウォータフォール型が逆に増えている面もある。

　第61号：米国ではウォータフォールは増えているという説
　http://kei-it.tea-nifty.com/sailing/2005/02/post_c0a7.html

・ウォータフォール型開発プロセスの基本形は、計画・設計・実装の
　峻別、そして、その間に契約行為を挟むことである。しかし、日本の
　一括請負は、設計と実装の間に契約行為を挟んでいない。
　したがって、欧米のウォータフォール型開発プロセスとは似て非なる
　ものである。

　第62号：米国のウォータフォールでは開発リスクの多くはユーザが負担する
　http://kei-it.tea-nifty.com/sailing/2005/02/post_f244.html

また、米国におけるインドオフショアの猛威は下記で解説しました。

　第157号：サービス業のオフショアリング
　http://kei-it.tea-nifty.com/sailing/2006/12/post_6f55.html

*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=
[慶2.0]　(4)日本人は「すり合わせ」が得意
*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=

私はＫ氏の話を聞きながら、「変われる国・日本へ」で坂村健氏が
書いていたことを思い出しました。

坂村健氏は、家電や自動車で日本が強い理由は、日本人は「すり合わせ」
が得意だからだと言っています。
家電や自動車では設計から製造に至るまで、多くの「すり合わせ」が
必要で、単一民族、単一言語、単一文化の日本人はそれが得意です。

一方、欧米人は、多民族、多言語、多文化なので、「すり合わせ」が
苦手です。

> 日本のように「あ・うんの呼吸」「紙に書かないで現場で調整」
> というわけにはいきません。
> 従って何かをやろうと思ったら、まず徹底的に制度をつくったり、
> 契約を結んでおかないと、トラブルの連続になってしまう。
> つまり、向こうは要素技術から最終のプロダクトまでの開発において
> 必要なすり合わせのコストが、日本などよりはるかに大きいという
> ことでしょう。
> 　　　　　　　　　　　　（坂村健著「変われる国・日本へ」）

日本人は「すり合わせ」が得意なだけに、逆に「どうすればよいか」
をシステム的に考えません。
そのため日本から要素技術型イノベーションは出てくるが、インフラ型
イノベーションは出てこないのです。

> “どうすればよいか”をシステム的に考えるのが欧米です。

> インフラ型のものは、個別のすり合わせを極力なくすように
> メカニズムとか、制度とか、方式とか、やり方を考えるからこそ
> インフラなわけです
> 　　　　　　　　　　　　（坂村健著「変われる国・日本へ」）

*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=
[慶2.0]　(5)ソフトウェア請負開発での「あ・うんの呼吸」
*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=

ソフトウェア請負開発でも、日本では「あ・うんの呼吸」「紙に書か
ないで現場で調整」が占める割合は大きいです。

開発プロセスがウォーターフォールであってもアジャイルであっても、
Chage Requestは当たり前なのです。

それ自体は、一概に悪いことではありません。

顧客からすれば、取引コストを下げるというメリットがあります。

　第145号：取引コスト
　http://kei-it.tea-nifty.com/sailing/2006/09/post_a811.html

*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=
[慶2.0]　(6)AsIs(現状)とToBe(あるべき)
*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=

Ｋ氏の言葉でもう一つ気づかされたことがあります。

要件定義をするということを、Ｋ氏は「AsIsとToBeをやります」と
表現しました。

ERPコンサルタントのＫ氏からすれば、AsIs(現状)やToBe(あるべき)
という用語は日常用語です。

しかし、日本のソフトウェア会社のSE、プログラマは、AsIsやToBe
という言葉は使いません。
システムはどうあるべきかということをとことん考えることはない
からです。

ソフトウェア会社の経営者や管理職ですら、AsIsやToBeという言葉に
なじみがありません。

先週号で私が言いたかったことは、下記の5点についてとことん
考えていこうということです。

(A)顧客や顧客が属している業界が抱える課題は何か
(B)その問題を解決するために自分たちが目指すことは何か
(C)自社のサービスや製品で実現できることは何か
(D)お客様の声を聞くこと
(E)お客様をサポートする体制をどうするか

また、第173号で、顧客の心の中でも社員の心の中でも慶のポジショ
ニングはコンサルタントであると述べました。

これらは「AsIsとToBeを考えていこう」ということなのです。

　第173号：慶ネクストの経営理念
　http://kei-it.tea-nifty.com/sailing/2007/04/post_fdf1.html

　第182号：事業計画はどのようにして生まれるのか
　http://www.gamou.jp/sailing/2007/06/post_ae08.html

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

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

今回お休みした新会社法活用術シリーズでは、今後、「法人の不思議」
などの基本的な話、そして「社員持ち株制度の是非」「IPOの損得」
などの具体的な話をしていきます。

乞うご期待！！

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

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

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

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

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

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

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

バックナンバーは、発行者サイトまたはブログで、体系として
見てもらいたいので、「まぐまぐ！」でのバックナンバー公開は
最新号のみとなっています。

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

☆筆者の趣味のブログ：身近にいる小動物の図鑑☆
　http://kei-it.tea-nifty.com/small/

--------------------------------------------------
発行：
株式会社 慶
　代表取締役 蒲生 嘉達

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

**************************************************************
_/_/_/_/_/_/_/ ソフトウェア業界　新航海術 _/_/_/_/_/_/_/_/_/
**************************************************************
第80号 2005/06/20
▼ まえがき
▼ [保存できないエディタ]　日経コンピュータ6/13号の問題記事
▼ [保存できないエディタ]　過失がなくても損害賠償や契約解除？
▼ [保存できないエディタ]　無過失責任とそれを限定する特約
▼ [保存できないエディタ]　乙の責に帰すべきものでない瑕疵
▼ [保存できないエディタ]　救済手段は「瑕疵の無償補修」が原則
▼ [保存できないエディタ]　問題の記事のその他の問題点
▼ 次回以降の予告

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

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

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

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

*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=
[保存できないエディタ]　日経コンピュータ6/13号の問題記事
*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=

日経コンピュータ6月13日号に、「【困ったときの法律相談室】
請負か準委任契約か、条項ごと“寄せ”を意識」という記事が載って
いました。( http://store.nikkeibp.co.jp/mokuji/nc628.html 参照)

内田・鮫島法律事務所に所属している弁護士がお書きになった記事です。
後述のとおり問題の多い記事ですが、ソフトウェア請負開発での
瑕疵担保責任について考える材料となるので、今回取り上げます。

下は日経コンピュータの上記記事からの引用です。

> 請負契約では原則、ベンダーに瑕疵担保責任がある。
> ユーザは瑕疵を見つけたら、民法634条以下の規定によって、ベンダー
> に対して責任を追及し、損害賠償や契約の解除を求めることができる。
> ベンダーに過失がなくても、である。

これを読んで読者は違和感を感じないでしょうか？

顧客とソフトウェア会社との間で締結される請負開発基本契約書では、
瑕疵担保責任は通常、下記のように記述されます。
「甲」は顧客、「乙」はソフトウェア会社です。

> 個別契約で定める保証期間内に乙の責めに帰すべき理由により生じた
> 隠れたる瑕疵が発見されて、同期間内に乙に対して通知があった場合、
> 乙は無償で補修を行います。
> この場合の甲に対する救済手段は瑕疵の無償補修に限られます。
> （山崎 陽久著「ソフトウェア開発・利用契約と契約文例事例集」より）
>　　http://www.5291soft.com/7-2-1.htm　より）

> プログラムの検収後、瑕疵が発見された場合、甲及び乙はその原因に
> ついて協議・調査を行うものとする。協議・調査の結果、当該瑕疵が
> 乙の責に帰すべきものであると認められた場合、乙は無償で補修・
> 追完を行うものとし、乙の責に帰すべきものでないと認められた場合
> には、甲は協議・調査によって乙に生じた費用を乙に支払うものとする。
> （「JISAソフトウェア開発委託モデル契約書」
> 　　　「ソフトウェア開発委託契約の契約と実務」より）

*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=
[保存できないエディタ]　過失がなくても損害賠償や契約解除？
*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=

上記の基本契約書の規定と日経コンピュータの記事とでは、下記の点で
大きな違いがあります。

（１）乙の責に帰すべきでない瑕疵の扱い

「ソフトウェア開発・利用契約と契約文例事例集」や
「JISAソフトウェア開発委託モデル契約書」では、瑕疵担保責任は
「乙の責に帰すべきものであると認められた場合」に限定されています。

それに対し、日経コンピュータの記事では、「ベンダーに過失がなくとも
瑕疵担保責任を追求できる」と主張しています。

（２）救済手段
「ソフトウェア開発・利用契約と契約文例事例集」や
「JISAソフトウェア開発委託モデル契約書」では、瑕疵担保責任の
救済手段は「瑕疵の無償補修」です。

それに対し、日経コンピュータの記事では、「損害賠償や契約の解除」
です。

*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=
[保存できないエディタ]　無過失責任とそれを限定する特約
*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=

私はもう一度「ソフトウェア開発・利用契約と契約文例事例集」や
「ソフトウェア開発委託契約の契約と実務」で瑕疵担保責任について
書かれている部分を読み直してみました。
その結果分かったことを記します。

まず、乙の責に帰すべきでない瑕疵の扱いについてです。

請負契約における瑕疵担保責任の一般論としては、日経コンピュータの
記事は正しいです。

> 取引の目的物に瑕疵があった場合、その目的物の提供者は無過失責任
> を負う。すなわち、過失の有無にかかわらず瑕疵が存在したということ
> だけで責任を負わなければならない。
> 　　　　　（「ソフトウェア開発・利用契約と契約文例事例集」より）

「ソフトウェア開発・利用契約と契約文例事例集」や
「JISAソフトウェア開発委託モデル契約書」で、瑕疵担保責任を
乙の責に帰すべきものであると認められた場合のみに限定しているのは
顧客とソフトウェア会社間で決めた特約なのです。

それでは、何故そのような特約を付けているのでしょうか？

*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=
[保存できないエディタ]　乙の責に帰すべきものでない瑕疵
*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=

その前に、「乙の責に帰すべきものでない瑕疵」とはどのような
ものでしょうか？
例えば下記のようなものが考えられます。

・使用したOS、ミドルウェア、パッケージソフトにバグがあった。
　バグと言えないまでも相性が悪かった。
　そして製品選定時点では、それを予見できなかった。

・顧客が提供した情報に誤りがあったことが原因で発生した瑕疵。

・顧客が必要な情報を提供しなかったことが原因で発生した瑕疵。

・顧客の指図が誤っていたために発生した瑕疵。

ソフトウェア請負開発では、他の製造物の請負開発よりも上記のような
ことが発生しやすく、無過失責任の原則をそのまま適用すると、
受託側にとってあまりにも過酷なものになります。
そのため、基本契約で、瑕疵担保責任を「乙の責に帰すべきもので
あると認められた場合」に限定する特約を入れているのです。

*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=
[保存できないエディタ]　救済手段は「瑕疵の無償補修」が原則
*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=

次に救済手段について見てみましょう。

> 請負人であるソフトウエア会社は、まず瑕疵修補責任と損害賠償責任
> を負う。
> すなわち注文者であるユーザーは、瑕疵について相当の修補期間を
> 定めて修補請求ができる（民法634条1項）。ただし、瑕疵が重要
> でない場合で、その修補に過分の費用がかかる場合は修補請求ができず、
> 損害賠償請求しかできない（民法634条1項但書）。

> また、ユーザーは修補請求に代えて損害賠償の請求をすることもできるし、
> 修補請求と共に損害賠償請求も合わせてできる（民法634条2項）。
>
> また、瑕疵によって契約をなした目的を達することができないときは、
> ユーザーは契約の解除をすることができ、合わせて損害賠償の請求も
> できる（民法635条）。
>
> 　　（「ソフトウェア開発・利用契約と契約文例事例集」より）

救済手段として、修補、損害賠償、契約解除の３つが認められています。

しかし、日経コンピュータの記事では、損害賠償、契約解除のみ
示されています。
修補が十分に可能な場合でも、ユーザーは損害賠償請求または契約解除が
できるかのように読み取れます。

しかし、これはソフトウェア業界の常識からはかけ離れています。
ソフトウェア業界の常識では、救済手段は「瑕疵の無償補修」が原則です。

プログラムは他の物理的な製造物よりもはるかに隠れたる瑕疵が発生
しやすいのです。
したがって、基本契約で救済手段を「瑕疵の無償補修」を原則とする
特約を入れるのです。

日経コンピュータの記事は、プログラムが他の物理的な製造物よりも
はるかに隠れたる瑕疵が発生しやすいという認識がない法律家が書いた
記事です。

*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=
[保存できないエディタ]　問題の記事のその他の問題点
*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=

この記事には他にも多くの問題点があります。

例えば、「準委任契約では、ベンダーに瑕疵担保責任はない」と
断定しています。
一方、「ソフトウェア開発・利用契約と契約文例事例集」では
準委任契約でも瑕疵担保責任はあると書かれています。

また、「派遣契約で来た人材に対して成果物の責任を負わせる
『偽装請負』という行為」という記述もあります。
通常は、実態は派遣なのに契約は請負であることを「偽装請負」と
言うはずです。
（第53号　http://www.kei-it.com/sailing/53-041213.html　参照）

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

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

・保存できないエディタシリーズのまとめ
・横受け型アウトソーシング
・見積もりが難しいテスト工程をアウトソーシングする方法
・ソフトウェア工場よりもテストセンターの方が実現しやすい。
・テストのアウトソーシングと漸増型開発プロセス

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

乞うご期待！！

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

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

**************************************************************
_/_/_/_/_/_/_/ ソフトウェア業界　新航海術 _/_/_/_/_/_/_/_/_/
**************************************************************
第78号 2005/06/06
▼ まえがき
▼ [保存できないエディタ]　日本での外部人材活用の2形態(派遣と請負)
▼ [保存できないエディタ]　米国でのアウトソーシングの3分類
▼ [保存できないエディタ]　下請け型・派遣型アウトソーシング
▼ [保存できないエディタ]　意識としては「横受け型アウトソーシング」
▼ 次回以降の予告

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

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

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

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

*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=
[保存できないエディタ]　日本での外部人材活用の2形態(派遣と請負)
*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=

日本では、外部人材活用の形態は、「派遣」と「請負」しかありません。
そして、「派遣」と「請負」の違いは次のように説明されます。

・労働者が派遣会社と雇用契約を結び、指揮命令は客先で受ける形態が
　「派遣」である。

・客先常駐自体は、「派遣」か「請負」を決定付けるものでない。
　「自由裁量の余地のない作業指示」を直接受けているか否かが問題である。

・客先常駐でも雇用されている会社から（例えば雇用されている会社の
　リーダから）作業指示を受けているなら請負である。

・また、技術者が客先に常駐して直接作業指示を受けても、自由裁量の
　余地のある専門的な仕事なら請負(準委任)である。

これらについての詳細は下記を参照してください。

派遣については、第52号「人材派遣業は指揮命令権のレンタル業」
http://www.kei-it.com/sailing/52-041206.html

偽装請負については、第53号「大手業務請負会社の業務請負」
http://www.kei-it.com/sailing/53-041213.html

準委任については第54号「準委任と人材派遣を分かつもの」
http://www.kei-it.com/sailing/54-041220.html

*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=
[保存できないエディタ]　米国でのアウトソーシングの3分類
*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=

> 米国では「請負」「派遣」という区分けよりもむしろ、外部人材活用を
> アウトソーシングと位置づけ、1)下請け型アウトソーシング、
> 2)派遣型アウトソーシング、3)横受け型アウトソーシング（特定の機能を
> 一括して外部に委託する方式）――と区分けする方が一般的なようだ。
>
> 独立行政法人　労働政策研究・研修機構「米国:人材ビジネス最前線」より
> http://www.jil.go.jp/foreign/labor_system/2005_1/america_01.htm

米国では労働者派遣法もなく、「派遣」の正式な定義も存在しません。
「労働市場や労働契約に国が介入すべきではない」という考え方なの
かもしれません。

余談になりますが、米国での人材ビジネスの約30%を占めると言われている
PEO：Professional Employer Organization(簡単に言うと、派遣会社と
クライアントの両方が労働者と雇用契約を結ぶ形態)は、日本では共同雇用
が法律で禁止されているので、成り立ちません。
日本の規制の多さの一例です。

*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=
[保存できないエディタ]　下請け型・派遣型アウトソーシング
*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=

さて、アウトソーシングの3分類について考えていきましょう。
1)下請け型アウトソーシング
2)派遣型アウトソーシング
3)横受け型アウトソーシング（特定の機能を一括して外部に委託する方式）

ソフトウェア業界での「下請け型アウトソーシング」は、いわゆる
一括請負です。
そして米国での一括請負はウォータフォール型であることは既に述べました。
この点については下記を参照してください。
・第73号「ファウラー氏の請負契約観」
　http://www.kei-it.com/sailing/73-050502.html　
・第61号「米国ではウォータフォールは増えている（？）」
　http://www.kei-it.com/sailing/61-050207.html

また、一般の労働者が客先に常駐して作業をした場合は、「派遣型
アウトソーシング」です。
たとえリーダが常駐して、そのリーダの下で作業をしても、やはり
「派遣型アウトソーシング」と扱われるようです。

> 一つの企業や工場に大量の派遣労働者を就労させている派遣元事業者の
> ほとんどが、現場に自社の管理者を置いて労働者の管理を行っており、
> 日本では「請負」の範疇に属するものが、「派遣」の扱いになっている
> 場合も多い。
>
> 独立行政法人　労働政策研究・研修機構「米国:人材ビジネス最前線」より
> http://www.jil.go.jp/foreign/labor_system/2005_1/america_01.htm

*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=
[保存できないエディタ]　意識としては「横受け型アウトソーシング」
*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=

では、プログラマが客先に常駐して作業をした場合は、「派遣型アウト
ソーシング」なのでしょうか？

ピート・マクブリーン著「ソフトウェア職人気質」には、客先常駐を
奨励するような記述があります。

> ユーザのすぐ隣で開発を行うことで、要件に関するコミュニケーション
> の質、量ともに向上させることができます。従って、要件が複雑な
> アプリケーションではこういったことを真剣に考えるべきでしょう。
>
> （ピート・マクブリーン著「ソフトウェア職人気質」より）

果たして、ピート・マクブリーンは「派遣型アウトソーシング」を
奨励しているのでしょうか？

答えは否です。

今週号では、結論だけ言います。

・「大規模開発・一括請負・ウォータフォール型開発プロセス」の中で
　元請会社が派遣会社やソフトウェア会社から人を集めた場合は、
　「派遣型アウトソーシング」です。

・「小規模開発・アジャイル開発」で客先常駐してプログラミングした
　場合には、プログラマの意識としては「横受け型アウトソーシング」です。
　契約的にはおそらく、時給ベースの工数見積による請負契約、または
　実績時給清算でしょう。

・テストのアウトソーシングも「横受け型アウトソーシング」です。

これらについて、次号以降で詳しく解説します。

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

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

・横受け型アウトソーシング

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

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

乞うご期待！！

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

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

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

乞うご期待！！

**************************************************************
_/_/_/_/_/_/_/ ソフトウェア業界　新航海術 _/_/_/_/_/_/_/_/_/
**************************************************************
第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

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