**************************************************************
_/_/_/_/_/_/_/  ソフトウェア業界　新航海術  _/_/_/_/_/_/_/_/_/
**************************************************************
第64号  2005/02/28
  ▼  まえがき
  ▼  [保存できないエディタ]　創作活動として見たら、漸増型の方が自然
  ▼  [保存できないエディタ]　漸増型と請負契約との軋轢
  ▼  [保存できないエディタ]　仕様がない世界でのソフトウェア開発
  ▼  [保存できないエディタ]　次回以降の予告


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

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

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


*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=
  [保存できないエディタ]　創作活動として見たら、漸増型の方が自然
*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=

漸増的開発については、本メルマガでもこれまでに何度も論じてきました。
例えば下記のとおり。

第6号　漸増的(ぜんぞうてき)開発
http://www.kei-it.com/sailing/06-040112.html

第11号　漸増的開発によって次の段階に／目を閉じて高速道路を運転する
http://www.kei-it.com/sailing/11-040216.html

第13号　読者からの質問
http://www.kei-it.com/sailing/13-040301.html

第22号　ウォーターフォールモデルと漸増的モデル／漸増的開発のきわどさ
http://www.kei-it.com/sailing/22-040503.html


上記で「ソフトウェア開発を創作活動として見た場合、漸増的開発
プロセスの方が自然だが、請負作業として見た場合は不自然」という
意味のことを書いてきました。

ソフトウェア開発は本の執筆のようなものであり、何度も書き直す
ことがむしろ普通です。したがって、ソフトウェア開発を創作活動
として見た場合、漸増的開発プロセスの方が自然なのです。

> ウォーターフォールモデルの欠点は、工程をまたがった反復が
> 行なわれず、その結果、できあがったものがユーザニーズから乖離
> してしまう可能性が高いという点です。
> 設計段階で全てが見通せるわけではなく、実装してみて初めて分かる
> ことも多いのに、下流から上流への流れを想定していないのです。
> ・・・（中略）・・・
> その欠点を是正するために漸増的開発が登場しました。
> 本の執筆のようにどんどん反復しようという手法です。
> （第22号　http://www.kei-it.com/sailing/22-040503.html　より）



*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=
  [保存できないエディタ]　漸増型と請負契約との軋轢
*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=

しかし、漸増的開発プロセスでは、ウォータフォール開発プロセスと
異なり、ユーザが仕様承認のリスクを取りません。
したがって、必然的に下記の問題が発生します。
（第10号　http://www.kei-it.com/sailing/10-040209.html　参照）

(1)ユーザのニーズとシステム仕様が過不足なく合致している
　ということを誰がどのようにして確認できるのか？
(2)一度、決めた仕様がユーザニーズと合致していなかった場合、
　その責任の所在はどこにあるのか？
　（第57号での設問もこれに当たります。）
(3)仕様を決める作業が遅れ、システムの納入が遅れた場合、
　ユーザとベンダの責任はどのようになるのか？
(4)システムの開発をベンダに委託する場合、納入されたシステムの
　受入れ検査では、何を基準として検査が行われるのか？
(5)ベンダが仕様の確定を見込んで先行的に製造作業をスタート
　させたが、目論見が外れて仕様が変わり、手戻りが発生し、
　コストと開発時間に関する損失が発生した場合、その費用は
　誰が負担するのか？


これらの難問を検討する前に、漸増的開発プロセスが最も威力を
発揮する市販ソフトウェアの漸増的開発について一瞥しておきま
しょう。ヒントが見つかるかもしれません。



*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=
  [保存できないエディタ]　仕様がない世界でのソフトウェア開発
*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=

第63号で述べたとおり、市販ソフトウェアの世界では、品質は「仕様に
合っていること」ではなく、「顧客満足」です。
そして、「顧客満足」は多様で、曖昧で、その上に気まぐれです。
仕様が完全な形で現れない世界、それらしきものが現れたかと思うと
すぐに変わってしまう世界なのです。

そこでは、仕様を仮定する作業から始まります。
市場調査、顧客調査、競合製品の分析などです。
これによって、方向性が固まります。

しかし、本当のことは最後まで分かりません。予想どおり売れるのか、
予想以上にヒットするのか、とんでもない思い違いをしていて全く
売れないのか、あるいは方向性を少し変えればうまくいきそうなのか・・・。

ウォータフォール開発プロセスでは発注者が仕様承認のリスクを
取りましたが、市販ソフトウェアの世界では開発会社が企画承認の
リスクを取るのです。このリスクを最小限に抑えるために、漸増的
開発プロセスが活用されます。

下記は「基本から学ぶソフトウェアテスト」(Cem Kaner,Jack Falk,
Hung Quoc Nguyen著)からの引用です。

・後から機能を追加できるように柔軟性のある設計を行い、核となる
　小さな製品を開発する。独立したプログラムとしてテストできるよう
　必要最小限の機能があればよい。
　競合製品との兼ね合いなどから追加したい機能はまだたくさんあるのに
　違いないが、市場の要求をぎりぎり満たしているレベルに達していると
　いうことに意味がある。

・その後ひとつずつ機能を拡張しテストを完了していくことで、製品
　としていつでも出荷可能なバージョンを確保しておくことができる。

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

・必要最小限の機能を実装した製品は完成しているので、機能追加を
　あきらめるのは簡単である。ここで止めれば仕様検討や設計、コーディ
　ングの工数は発生しない。

・進化型開発プロセスで開発を進めると、進捗に応じた経営判断をする
　際に威力を発揮する。プロジェクトマネージャは、機能を追加して出荷を
　延ばすという選択肢と、機能追加をあきらめて納期を優先するという
　選択肢の２つから常に判断することができる。



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

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

・市販ソフトウェア開発に見る漸増的開発プロセスの基本形。
　（ウォータフォールと漸増型の比較をもう少し掘り下げます。）

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

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


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

乞うご期待！！



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

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

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