« February 2005 | Main | April 2005 »

March 2005

March 28, 2005

外部設計と内部設計を並行して進めるのが正しいウォータフォール

**************************************************************
_/_/_/_/_/_/_/ ソフトウェア業界 新航海術 _/_/_/_/_/_/_/_/_/
**************************************************************
第68号 2005/03/28
▼ まえがき
▼ [保存できないエディタ] 最適な開発プロセスなどは存在しない
▼ [保存できないエディタ] 「外部設計が終わってから内部設計」は間違い
▼ [保存できないエディタ] 三番目の契約を取り交わす前に実装はできない
▼ [保存できないエディタ] 昔から「外部設計と内部設計は並行」が正しい
▼ [保存できないエディタ] 次回以降の予告


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

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

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

第57号を書いたときは3,4回のシリーズにするつもりでしたが、
請負契約や開発プロセスについては話題が尽きず、今回でシリーズ
12回目となります。

「5年後のシステム開発」シリーズから独立させて、「保存できない
エディタ」シリーズとしました。
まとめて読みたい方は下記URLを参照してください。
http://www.kei-it.com/sailing/back_editor.html

*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=
[保存できないエディタ] 最適な開発プロセスなどは存在しない
*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=

多くの日本の学者は、ウォータフォール型開発プロセスを『悪の枢軸・
戦犯・悪の根源』と決め付けています。
例: http://www.stackasterisk.jp/tech/engineer/devp01_02.jsp
   http://www.ivis.co.jp/prof/07.html

しかし、米国においては、ウォータフォール型開発プロセスの熱烈な
支持者も健在で、今尚、真面目に議論されています。

> テストを担当する立場にいると、どの開発プロセスが最適かという
> 問題に固執するかもしれない。しかし、正論かもしれないが、最適な
> 開発プロセスなどは存在しない。例えばこの本の筆者である我々3人にも、
> それぞれ長いこと熟慮して最適だと信じている開発プロセスがある。
> しかしお互いを説得するのは本当に難しい。
>            「基本から学ぶソフトウェアテスト」より

本号では、日本で行われている、ウォータフォール型開発プロセスについての
説明の誤りの一つを指摘します。

*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=
[保存できないエディタ] 「外部設計が終わってから内部設計」は間違い
*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=

Googleなどの検索エンジンで「ウォータフォール 外部設計 内部設計」
で検索すると、ウォータフォール型開発プロセスについての次のような
記述がすぐに見つかります。

「システムの開発は,おおまかに,要求分析→外部設計→内部設計→
プログラミング→テスト→実施の順序で行なわれます。」
http://www.kogures.com/hitoshi/webtext/kj2-kaihatsu-gihou/

「基本計画,外部設計,内部設計,プログラム設計,プログラミング,
テストの順に進めていくので,全体を見通すことができ,スケジュールの
決定や資源配分が容易にできる。(2種平成11年秋問56ア)」
http://www.shunzei.com/lecture/words/aa.html

「システム開発を,基本計画,外部設計,内部設計,プログラム設計,
プログラム開発,テスト,運用・保守の工程順に実行するウォータフォール
モデルにおいて,工程終了の成果物として要求仕様書を作成する工程は
どれか。」
(システムアドミニストレータ 過去問題 平成15年度 秋期 午前)
http://mt-net.vis.ne.jp/ADFE_mail/0367.htm


これらの記述に共通していることは、「ウォータフォール型開発プロセス
では、外部設計が完了してから内部設計に取り掛かる」という考え方です。

しかし、これは間違いです。
ウォータフォール型開発プロセスでも、外部設計と内部設計は並行して
進めてもよいし、むしろ、並行して進めるべきなのです。

*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=
[保存できないエディタ] 三番目の契約を取り交わす前に実装はできない
*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=

ウォータフォール型開発プロセスの基本形は、計画・設計・実装の峻別、
そして、その間に契約行為を挟むことです。次のように。

 [最初の契約]→[計画]→[2番目の契約]→[設計]→[3番目の契約]→[実装]

 第62号「ウォータフォールでの契約の3段階」
 ( http://www.kei-it.com/sailing/62-050214.html )参照。


各工程の峻別、後戻りを嫌う、工程単位の検証という、ウォータフォール型
開発プロセスの性格は、フェーズ間で契約行為が入るという構造から
生まれてくるものなのです。

そして、最初の契約、二番目の契約、三番目の契約では契約の性格が
異なってくるはずなのです。
それぞれの契約の性格の違いについては、後日解説します。

「設計が承認されていないのにコーディングをするな」はウォータフォール
の大原則です。これは「三番目の契約を取り交わす前に実装はできない」
という意味です。

*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=
[保存できないエディタ] 昔から「外部設計と内部設計は並行」が正しい
*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=

「設計が承認されていないのにコーディングをするな」はウォータ
フォールの大原則ですが、「外部設計が完了していないのに、内部
設計をするな」という原則はありません。
むしろ、外部設計と内部設計を並行して進めるのが、昔も今も正しい
ウォータフォールなのです。

(1)昔
例えば、「人月の神話」(1975年発行)はウォータフォール型開発プロセスを
前提としていますが、その中でブルックスは次のように述べています。

> 制約のない実現グループでは、思考と議論がアーキテクチャの
> 決定に注がれることが多く、インプリメンテーション自体には
> 死刑執行前に与えられる懺悔の時間くらいしか取られないのである。

> 外部仕様書が完成するずっと前に、実現者にはすべきことが
> 山ほどある。

これは「外部設計と内部設計を並行して進めろ」という意味です。


(2)近年
また、「基本から学ぶソフトウェアテスト」(1999年発行)では、
ウォータフォール型開発プロセスでの工程の説明の中で、外部設計と
内部設計の並行は当然のこととして書かれています。

> 設計には、外部設計と内部設計がある。外部設計は、ユーザの視点で
> 製品を記述し、内部設計は、製品内部の仕組みを記述する。
> 外部設計と内部設計は並行に行うため、相手に対し相互に制約を課したり、
> 要求を出すことになる。

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


次回以降は下記の項目について書いていきます。

・プロトタイピングとウォータフォール型開発プロセスの関係

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

・請負開発での重要なマイルストーンは「受け入れテスト項目の決定」。

・ウォータフォール型開発プロセスでの3つの契約の性格の違い。

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

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

乞うご期待!!

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

本メルマガは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サイトではバックナンバーの全文検索も可能です。)

|

March 21, 2005

アルファ版、ベータ版、ガンマ版

**************************************************************
_/_/_/_/_/_/_/ ソフトウェア業界 新航海術 _/_/_/_/_/_/_/_/_/
**************************************************************
第67号 2005/03/21
▼ まえがき
▼ [保存できないエディタ] 市販ソフト開発の手順を具体的に
▼ [保存できないエディタ] アルファ版、ベータ版、ガンマ版
▼ [保存できないエディタ] マイルストーン
▼ [保存できないエディタ] 次回以降の予告


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

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

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

第57号を書いたときは3,4回のシリーズにするつもりでしたが、
請負契約や開発プロセスについては話題が尽きず、今回でシリーズ
11回目となります。

「5年後のシステム開発」シリーズから独立させて、「保存できない
エディタ」シリーズとしました。
まとめて読みたい方は下記URLを参照してください。
http://www.kei-it.com/sailing/back_editor.html

*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=
[保存できないエディタ] 市販ソフト開発の手順を具体的に
*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=

第65号で「市販ソフト開発に見る漸増的開発の基本形」を次のように
述べました。

> (1)後から機能を追加できるように柔軟性のある設計を行い、最初に
>  核となる小さな製品を開発します。
>  「核となる小さな製品」とは、市場の要求をぎりぎり満たしている
>  レベルの製品です。
>
> (2)その後ひとつずつ機能を拡張しテストを完了していきます。
>  製品として出荷可能なバージョンを常に確保しておけるという
>  ところがミソです。
>
> (3)上記作業によって、製品のイメージが固まるにつれて要求仕様を
>  再確認し、設計を見直すことも可能となります。
>
> (4)開発会社は、機能拡張をある時点で中断し、市場に出荷します。


これだけだと今ひとつイメージが湧かないと思うので、今週号では、
実際の手順について、営業系作業も含めて、もう少し具体的に書きます。

また、よく耳にする用語「アルファ版」「ベータ版」などの意味も
解説します。


*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=
[保存できないエディタ] アルファ版、ベータ版、ガンマ版
*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=

表でまとめた方が分かりやすいので、
「漸増的開発プロセスによる市販ソフトウェア開発の作業手順の例」
http://www.kei-it.com/sailing/pdf/67-050321.pdf を参照しながら
読んでください。

この例では、アルファ版、ベータ版、ガンマ版、出荷直前版、出荷版の
5つの版をリリースしています。
アルファ版、ベータ版、ガンマ版について以下に解説します。

----------------------------------------------
(1)アルファ版
核となる小さな製品です。
最低限必要な機能はすべて実装され、出荷できる品質も確保できています。
実際に使ってみて感触を確かめることができますが、まだ実装されて
いない機能もたくさんあります。

この後、ベータ版に向けて、外部設計・内部設計の改善、追加機能の
実装を行います。

また、営業関係では、パッケージデザイン、広告資料の作成、マニュアルや
ヘルプの作成を開始します。

----------------------------------------------
(2)ベータ版
アルファ版よりも機能が追加されています。
社外の協力者に製品を実際に使ってもらい(社外のベータテスト)、感想を
求めることができる状態です

設計上の問題点はほぼ解決していますが、社外の評価次第で修正が
発生する可能性はあります。

----------------------------------------------
(3)ガンマ版
ベータ版よりもさらに機能が追加されています。
これ以降は機能追加も機能削減もありません。
開発系の残り作業は、バグ修正と性能向上のみです。

この時点でユーザインタフェースを凍結し、ヘルプを完成させ、
マニュアルやパンフレットを印刷します。

広告を出し、営業を開始します。

*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=
[保存できないエディタ] マイルストーン
*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=

上記は一つの例であり、アルファ版、ベータ版、ガンマ版という
言葉の意味もプロジェクトによって変わります。

しかし、上記説明で、漸増的開発による市販ソフトウェア開発の
イメージがより明確に浮かんできたのではないでしょうか?

システム開発の進捗管理では「マイルストーン」という言葉が、よく
使われます。日本語に訳すと「里程標」「里標石」「一里塚」です。
スケジュールの中で、日付が振られた、節目となる重要なイベントの
ことです。

上記例では、アルファ版、ベータ版、ガンマ版が重要なマイルストーン
なのです。

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

次回以降は下記の項目について書いていきます。

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

・請負開発での重要なマイルストーンは「受け入れテスト項目の決定」。

・ウォータフォール型開発でまだ論じていない問題点。

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

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

乞うご期待!!

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

本メルマガは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サイトではバックナンバーの全文検索も可能です。)

|

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

|

March 07, 2005

進捗管理はウォータフォール型よりも漸増型の方が容易

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

|

« February 2005 | Main | April 2005 »