**************************************************************
_/_/_/_/_/_/_/  ソフトウェア業界　新航海術  _/_/_/_/_/_/_/_/_/
**************************************************************
第70号  2005/04/11
  ▼  まえがき
  ▼  [保存できないエディタ]　最初にアジャイルありきというアプローチ
  ▼  [保存できないエディタ]　最初に請負契約ありきというアプローチ
  ▼  [保存できないエディタ]　「取引関係において不可欠」という断定
  ▼  [保存できないエディタ]　全体がウォータフォールでもテストは漸増型で
  ▼  [保存できないエディタ]　次回以降の予告


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

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

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

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

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



*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=
  [保存できないエディタ]　最初にアジャイルありきというアプローチ
*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=

第69号では、日経システム構築4月号の「アジャイル開発に適した
契約形態とは？」という記事について、「全く答えになっていなかった」
と書きました。
( http://www.kei-it.com/sailing/69-050404.html　参照)

しかし、本文ではなく、画像の中に、アジャイルプロセス協議会の
「見積・契約ガイドライン」ワーキンググループの案が次のように
書かれていました。

・プロジェクトの初期段階は支援契約を結び、アジャイル開発が
　どのようなものか理解してもらう。
・1枚のストーリーカードごとに見積もるなどして請負契約を結ぶ。

これらの案は、最初にアジャイル開発（漸増型開発の一種）ありきで、
それと請負契約との折り合いをつけていこうというアプローチです。
これらの案については、次号以降で検討していきます。

尚、「初期は準委任、その後は請負」や「発注単位を小さくする」
というアイデアはけっして目新しいものではなく、10年前から言われて
いることです。


*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=
  [保存できないエディタ]　最初に請負契約ありきというアプローチ
*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=

もう一つのアプローチがあります。
最初に請負契約ありきというアプローチです。

請負契約、そして、それに適したウォータフォール型開発プロセスを
前提として、「短納期・低価格・顧客満足」と折り合いを付けていこう
というアプローチです。

第69号で論じたように、プロトタイピングをウォータフォール型の
枠組みの中で効果的に取り入れていくということもその一つです。

さらに、漸増型の良いところをウォータフォールの枠組みの中に取り
入れていくことも検討されるべきでしょう。
その一つが、本号で述べる「プロジェクト全体はウォータフォール型、
テストは漸増型」という方法です。


*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=
  [保存できないエディタ]　「取引関係において不可欠」という断定
*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=

第59号( http://www.kei-it.com/sailing/59-050124.html )にも記した
とおり、「保存できないエディタ」シリーズは、Cem Kaner,Jack Falk,
Hung Quoc Nguyen著「基本から学ぶソフトウェアテスト」(日経BP社発行)
を参考にしています。

Cem Kaner,Jack Falk,Hung Quoc Ngyenは、多くの日本の学者と違い、
ウォータフォール型開発プロセスを「悪」と決め付けるようなことは
していません。

純開発面では「深刻な遅延が発生しやすい」「膨大なテスト工数が予想
できない」などと厳しい指摘をしていますが、二者間契約という視点では、
「ウォータフォール開発プロセスはユーザとの取引関係において不可欠な
ものである」と断定しています。

また、開発面での問題点もけっして克服不可能だは言っていません。

> ウォータフォール開発プロセスの支持者は、開発初期に要求をしっかり
> 分析したうえで製品を設計し、きちんと計画を立てさえすればプロジェクト
> の失敗は防げると主張する。

> 受託型システムや組み込みソフトウェアのように作り直しが難しい
> 製品の場合は、プロジェクトの初期において仕様を詳細に確認すること、
> 適切な計画を立てることが特に重要となる。



*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=
  [保存できないエディタ]　全体がウォータフォールでもテストは漸増型で
*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=

「市販ソフトウェア開発は漸増型開発プロセスが適し、受託型システム
開発はウォータフォール型開発プロセスが適する」というのが、
「基本から学ぶソフトウェアテスト」の基本的はスタンスです。
（おそらく、これが米国での標準的な考え方なのでしょう。）

しかし、同書は、テストとテスト計画作成については、プロジェクト
全体がウォータフォール型であったとしても、漸増型で行うべきだと
主張しています。


> テスト、特にテスト計画は、プログラムが進化型の方法で開発されたか
> どうかに関係なく、進化型で作成していくことが可能である。
> テスト計画作成とテストに対する進化型アプローチは、開発チームの
> その他の部分がウォータフォール開発プロセスのような方法に従っている
> 場合でも、筆者らの考えでは、通常はウォータフォール開発プロセスの
> ようなアプローチでテスト計画を作成するより効果的である。


これは非常に重要な手法です、
「膨大なテスト工数が予想できない」ことがウォータフォール開発
プロセスの最大の問題点の一つだからです。

この手法の詳細については、次号で解説します。



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


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

・「全体がウォータフォールでもテストは漸増型で」の詳細。

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

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

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

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



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

乞うご期待！！



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

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

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