**************************************************************
_/_/_/_/_/_/_/  ソフトウェア業界　新航海術  _/_/_/_/_/_/_/_/_/
**************************************************************
第65号  2005/03/07
  ▼  まえがき
  ▼  [保存できないエディタ]　市販ソフト開発に見る漸増的開発の基本形
  ▼  [保存できないエディタ]　改善に明け暮れて開発が遅れるとゴミになる
  ▼  [保存できないエディタ]　本当は漸増型の方が進捗管理がしやすい
  ▼  [保存できないエディタ]　漸増的開発の方が信頼性が向上する
  ▼  [保存できないエディタ]　次回以降の予告


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

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

第57号から「まぐまぐ！」での読者数が急に増えてきました。
第56号までは200名だったのに、今では325名です。
読者も「日本のソフトウェア請負開発は何かおかしい」という思いを
お持ちなのだと思います。


*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=
  [保存できないエディタ]　市販ソフト開発に見る漸増的開発の基本形
*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=

市販ソフトウェア開発における漸増的開発の基本形を復習してみましょう。

(1)後から機能を追加できるように柔軟性のある設計を行い、最初に
　核となる小さな製品を開発します。
　「核となる小さな製品」とは、市場の要求をぎりぎり満たしている
　レベルの製品です。

(2)その後ひとつずつ機能を拡張しテストを完了していきます。
　製品として出荷可能なバージョンを常に確保しておけるという
　ところがミソです。

(3)上記作業によって、製品のイメージが固まるにつれて要求仕様を
　再確認し、設計を見直すことも可能となります。

(4)開発会社は、機能拡張をある時点で中断し、市場に出荷します。



*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=
  [保存できないエディタ]　改善に明け暮れて開発が遅れるとゴミになる
*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=

(4)の判断をするに当たり、開発会社は「商品力を高めるためにもっと
機能拡張したいが、それは開発費増と納期遅延をもたらす」という
トレードオフに悩まされます。
市販ソフトウェアでは、納期遅延が特に重大な問題となります。

> 家電製品のような成熟型商品ではなく、ソフトウェアのような成長型
> 商品の場合、最初か二番目に市場に投入された製品がシェアの大半を
> 奪ってしまうことを肝に銘じて欲しい。後から品質の高い製品を投入
> してもダメなのだ。改善に明け暮れて開発が遅れると、製品そのものを
> ゴミにしてしまう。
> 　　　　　　　　　　（「基本から学ぶソフトウェアテスト」より）


開発会社は、市場の動向、製品の出来具合、そして、自らの懐具合を
常に見ながら、機能拡張をストップし市場に出荷するタイミングを
計ります。

ウォータフォールでは、「出荷可能なバージョンを常に確保しておく」
という発想はないので、このような芸当はできません。



*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=
  [保存できないエディタ]　本当は漸増型の方が進捗管理がしやすい
*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=

ここで、日本の学者や技術系マスコミの誤りをもう一つ指摘して
おきましょう。

Googelなどの検索エンジンで「ウォータフォール」で検索すれば、
下記のような説明がすぐに出てきます。

> 本来的なウォーターフォール・モデル開発は、「仕様書による定義」
> という原則を厳格に適用することを目的としたドキュメント駆動型の
> 開発プロセスといえる。全体を見通すことができ、スケジュール立案
> や資源配分、進ちょく管理が容易にできるなどの点から、現在でも
> 大規模プロジェクトでは基本的にこの方法が取られている。
> http://www.atmarkit.co.jp/aig/04biz/waterfall.html

「進捗管理は漸増型よりもウォータフォール型の方が容易だ」という
のが、日本の学者や技術系マスコミの見解です。
しかし、本当は、進捗管理はウォータフォール型よりも漸増型の方が
容易なのです。

ウォータフォール型開発の最大の欠点は、プロジェクト後半になら
ないとテストを開始できず、テストと修正の工数が予測できないと
いうことです。
プロジェクトの終盤まで上流工程のバグが見つからず、見つかった
場合の修正工数が膨大なものになるということはウォータフォールの
欠陥としてよく指摘されます。
テスト工程のフタを開けてみないと上流工程の品質も下流工程の品質も
予想がつかず、したがって、テストと修正の工数が予測できないのです。

一方、漸増型開発プロセスでは、新しい機能が追加される時には、既に
実装されている機能に関するテストや修正はすべて完了しています。
つまり、ひとつずつ機能を拡張している段階では、開発の進み具合が
容易に把握できるのです。

開発の進み具合が容易に把握できるからこそ、機能拡張をストップし
市場に出荷するタイミングを見極めることができるのです。

> 進化型開発プロセスでは開発の前半からテストを行うので、テストの
> 総工数は増える。しかしプロジェクトの終盤になってテストが予想外
> に増えすぎてしまうことはない。
> 　　　　　　　　　　（「基本から学ぶソフトウェアテスト」より）



*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=
  [保存できないエディタ]　漸増的開発の方が信頼性が向上する
*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=

もう一つ漸増的開発の利点をあげます。

ウォータフォールではすべてのコーディングが完了してからテストを
開始するので、設計やコーディングの遅れのしわ寄せでテスト期間が
短縮され、優先度の低い一部の機能について十分なテストが行われない
ことがよくあります。

一方、常に出荷できる品質を確保しながら進めるのが漸増的開発です。
新たな機能を追加している時であっても、他の機能はすべて品質を
確保しているはずです。また、新たな追加機能のテストで既存機能の
テストも繰り返すので、信頼性はさらに向上します。



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

次回以降では次のようなことを順次解説していきます。

・いいことずくめに見える漸増的開発の落とし穴。

・請負開発を漸増的に行うためにはどうすればよいか。

・契約には違反していないが、製品として欠陥がある場合（第57号
　での例のような場合）の考え方。


次号は、3月14日発行予定です。

乞うご期待！！



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

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

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