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

乞うご期待！！



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

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

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