**************************************************************
_/_/_/_/_/_/_/  ソフトウェア業界　新航海術  _/_/_/_/_/_/_/_/_/
**************************************************************
第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サイトではバックナンバーの全文検索も可能です。）

--------------------------------------------------
発行：
株式会社 慶
　代表取締役  蒲生 嘉達
　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  

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