**************************************************************
_/_/_/_/_/_/_/  ソフトウェア業界　新航海術  _/_/_/_/_/_/_/_/_/
**************************************************************
第69号  2005/04/04
  ▼  まえがき
  ▼  [保存できないエディタ]　日経システム構築4月号の期待はずれな記事
  ▼  [保存できないエディタ]　プロトタイピングは開発プロセスではない
  ▼  [保存できないエディタ]　プロトタイピングは製造ではなく、設計
  ▼  [保存できないエディタ]　プロトタイプのコードは破棄するのが原則
  ▼  [保存できないエディタ]　次回以降の予告


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

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

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

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

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



*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=
  [保存できないエディタ]　日経システム構築4月号の期待はずれな記事
*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=

日経システム構築4月号の「開発現場の『疑問』に答える」という
特集の中に「アジャイル開発に適した契約形態とは？」という記事が
載っていました。

冒頭で「(アジャイル開発は)従来型の開発契約形態がなじまないのである」
と書かれていたので、期待して読み進みましたが、結びは次のように
なっていました。

> アジャイルプロセス協議会では、アジャイルにマッチした契約手法を
> 模索中だ。

> 同協議会では、情報サービス産業協会(JISA)のモデル契約書を基に、
> よりアジャイル開発に適した契約書の策定に取り組んでいる。
> 成果がまとまり次第、公表する予定である。

記事のタイトルは「開発現場の『疑問』に答える」ですが、全く答えに
なっていません。

「ソフトウェア開発委託契約の契約と実務」(2002年7月JISA発行)と同様
期待はずれな内容でした。
第10号( http://www.kei-it.com/sailing/10-040209.html )参照。


「漸増的開発に適した契約形態とは？」という問題を解決するためには、
開発プロセスの本質についての理解が必要です。
今週号では、プロトタイピングを取り上げます。



*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=
  [保存できないエディタ]　プロトタイピングは開発プロセスではない
*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=

多くの書籍やホームページでは、プロトタイピングをウォータフォール型
開発プロセスや漸増型開発プロセスと同じく、「開発プロセス」の一つ
として扱っています。

例：
http://www.stackasterisk.jp/tech/engineer/devp01_02.jsp
http://xn--n9q36mh1hnxuksz7wt.jp/AD14b-am/t33.html
http://pcweb.mycom.co.jp/series/stratesys/011/
http://www.pc-view.net/Outsourcing/030411/


しかし、これは間違いです。

ウォータフォール型開発プロセスや漸増型開発プロセスがシステムの
構想段階から稼動まで、さらに契約や営業までを対象とする開発プロセス
なのに対し、プロトタイピングは設計局面での一手法に過ぎません。
概念レベルは、開発プロセスではなく、外部設計や内部設計と同格です。

プロトタイピングは単独の開発プロセスではなく、他の開発プロセスに
組み込まれて、システムの機能やユーザインタフェースを製造前に評価
するために使用されます。

「ウォータフォール型開発プロセス＋プロトタイピング」も
「漸増型開発プロセス＋プロトタイピング」もあり得ます。

但し、漸増型開発プロセスでは実動可能なバージョンが開発の早い段階で
登場するので、機能の一部の性能面を個別に調査する必要があるとき以外は、
プロトタイピングの必要性はあまりありません。

それに対し、「ウォータフォール型開発プロセス＋プロトタイピング」
という組み合わせは、効果的な故に、広く普及しています。
開発の最後の段階にならないと実動可能な製品が登場しないという
ウォータフォール型開発プロセスの欠点を補うことができるからです。



*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=
  [保存できないエディタ]　プロトタイピングは製造ではなく、設計
*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=

第68号で、「設計が承認されていないのにコーディングをするな」は
ウォータフォールの大原則だと書きました。
しかし、プロトタイピングではコードを書きます。
プロトタイピングがウォータフォール型開発プロセスに組み込まれた場合、
設計が承認されていないのコーディングしてもよいのでしょうか？

よいのです。なぜなら、プロトタイピングは製造ではなく、設計だからです。

例えば、ビルを建てるときに顧客がイメージをつかみやすいように、
100分の1の縮尺の模型を作っても、それは設計の一部であり、製造
ではありません。
あるいは、使用する部品の強度を調べるために、試作品を作って
実験するかもしれません。しかし、それも設計であり、製造ではあり
ません。

それに対し、漸増型開発プロセスでのアルファ版は、たとえ機能が
貧弱だとしても、「核となる小さな製品」つまり出荷可能な「製品」
なのです。プロトタイプは製品ではありません。



*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=
  [保存できないエディタ]　プロトタイプのコードは破棄するのが原則
*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=

プロトタイプは製品ではないということは、「プロトタイプのコードは
製品版では使用しないのが原則」といういことを意味しています。

漸増型開発プロセスでのアルファ版は、熟慮された設計がなければ
なりません。きちんと柔軟性を組み込んでおかないと、機能を追加する
ときに大量の手戻りが発生してしまうからです。
（第66号「漸増的開発、失敗のシナリオ」参照。
http://www.kei-it.com/sailing/66-050314.html　）

それに対し、プロトタイプは製品ではないので、熟慮された設計は必要と
されません。

> 設計者がシステムモデルを作る場合に、急いでいい加減なコードを書く
> ことは許されるだろう。しかし、後でそのコードを捨てる必要がある。
> 　　　　　　　　　　　「基本から学ぶソフトウェアテスト」より


とはいうものの、実際には、日本でも米国でもプロトタイプのコードを
結果的に流用することはよくあります。

> プロトタイピングはコーディングとはみなさない。・・・(中略)・・・
> とはいえ、プロトタイプのかなりのソースコードを製品に流用している
> のが現状だ。
> 　　　　　　　　　　　「基本から学ぶソフトウェアテスト」より



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


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

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

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

・ウォータフォール型開発プロセスでの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サイトではバックナンバーの全文検索も可能です。）

--------------------------------------------------
発行：
株式会社 慶
　代表取締役  蒲生 嘉達
　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  

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