ソフトウェア業界　新航海術　

**************************************************************
_/_/_/_/_/_/_/ ソフトウェア業界　新航海術 _/_/_/_/_/_/_/_/_/
**************************************************************
第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/

「基本計画，外部設計，内部設計，プログラム設計，プログラミング，
テストの順に進めていくので，全体を見通すことができ，スケジュールの
決定や資源配分が容易にできる。（２種平成１１年秋問５６ア）」
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 )参照。

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

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

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

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

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

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

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

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

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

（２）近年
また、「基本から学ぶソフトウェアテスト」(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サイトではバックナンバーの全文検索も可能です。）