« 進捗管理はウォータフォール型よりも漸増型の方が容易 | Main | アルファ版、ベータ版、ガンマ版 »

March 14, 2005

漸増的開発、失敗のシナリオ

**************************************************************
_/_/_/_/_/_/_/ ソフトウェア業界 新航海術 _/_/_/_/_/_/_/_/_/
**************************************************************
第66号 2005/03/14
▼ まえがき
▼ [保存できないエディタ] 漸増的開発、失敗のシナリオ
▼ [保存できないエディタ] 核となる製品が無設計
▼ [保存できないエディタ] テスト、修正せずに機能追加
▼ [保存できないエディタ] マーケティングの確認不足
▼ [保存できないエディタ] 次回以降の予告


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

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

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

2/9には読者である名古屋のソフトウェア会社(従業員240名、資本金
4億円)の社長が来社され、「請負開発ではいつもいじめられている」
とおっしゃっていました。


*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=
[保存できないエディタ] 漸増的開発の失敗のシナリオ
*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=

第65号では市販ソフトウェア開発における漸増的開発の利点を次の
ように述べました。

・まず核になる小さな製品を作って、その後ひとつずつ機能を拡張
 していくので、開発の進み具合が容易に把握できます。

・したがって納期と機能のトレードオフについて、進捗に応じた経営
 判断ができます。

・製品のイメージが固まるにつれて要求仕様を再確認し、設計を
 見直すことが可能となります。

・新たな追加機能のテストで既存機能のテストも繰り返すので、
 信頼性が向上します


それでは、漸増的開発プロセスで市販ソフトウェアを開発すれば
失敗することは無いのでしょうか?
そんなことはありません。
ウォータフォール型開発での失敗プロジェクト並に、予算超過、
スケジュール遅延、品質低下が起きることがあるのです。

今週号では、漸増的開発での市販ソフトウェア開発で起きる、失敗の
シナリオについて解説します。


*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=
[保存できないエディタ] 核となる製品が無設計
*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=

【失敗シナリオ1】核となる製品が無設計

「基本から学ぶソフトウェアテスト」では次のように書かれています。

> 核となる製品にきちんと柔軟性を組み込んでおかないと、機能を
> 追加するときに大量の手戻り(作業のやり直し)が発生してしまう

また、ブルックスは「人月の神話から二十年を経て」で、漸増的開発
方針で作成された中間的バージョンを製品ファミリーと見なすべきだと
した上で、次のように述べています。

> こうした系図をデザインするこつは、まず変更されることがないと
> 見込まれるデザインの部分の決定内容を根元付近に置くことである。

*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=
[保存できないエディタ] テスト、修正せずに機能追加
*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=

【失敗シナリオ2】各バージョンを十分テストせずに機能追加してしまう。

漸増的開発の基本形は、「まず核になる小さな製品を作り、テスト、
修正し、その後ひとつずつ機能を追加、テスト、修正していく」です。

バージョン単位で品質を確保していくことが漸増的開発のミソなのです。
したがって、次のようなことをしていまうと、漸増的開発の意味がない
のです。

・核になる製品を十分にテスト、修正せずに機能追加してしまう。
・各バージョンを十分にテスト、修正せずに、次々と機能追加して
 しまう。
・テストで見つかったバグを修正せずにコードにどんどん手を入れて
 しまう。

これでは、ウォータフォール型以上に予算管理も進捗管理も難しく
なってしまいます。


*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=
[保存できないエディタ] マーケティングの確認不足
*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=

【失敗シナリオ3】マーケティングの確認不足

これは市販ソフトウェア開発ならではの失敗シナリオです。

> どの機能が重要なのかをマーケティングが確認し忘れたりすると、
> 出荷直前にどうでもよい機能ばかりが実現されていることに気づいて、
> 本当に必要な機能がでそろうまで出荷を見合わせざるを得なくなって
> しまう。
>   (「基本から学ぶソフトウェアテスト」より)

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

漸増的開発は市販ソフトウェア開発に適しています。
そして、米国では市販ソフトウェア開発・利用が日本よりはるかに
進んでいます。
だから米国の学者は漸増的開発の一種であるXP、RUP、アジャイルを
喧伝するのです。

では、オーダーメイド開発の多い日本での漸増的開発はどのように
考えたらよいのでしょうか?

次号では、この点について論じます。


次号は、3月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サイトではバックナンバーの全文検索も可能です。)

|

« 進捗管理はウォータフォール型よりも漸増型の方が容易 | Main | アルファ版、ベータ版、ガンマ版 »