ファウラー氏の請負契約観

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

乞うご期待！！