********************************************************************
_/_/_/_/_/_/_/_/_/  ソフトウェア業界　新航海術  _/_/_/_/_/_/_/_/_/_/
********************************************************************
第11号  2004/02/16
  ▼  まえがき
  ▼  前号までのまとめ
  ▼  初期の「設計と製造の並行」
  ▼  漸増的開発によって次の段階に
  ▼  目を閉じて高速道路を運転する
  ▼　次回以降の予告

*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*
  まえがき
*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*
蒲生嘉達です。お疲れ様です。

本メルマガは、慶の社員（正社員・契約社員）及び慶と
契約している個人事業主の方々に配信しています。
感想をお持ちなら是非返信してください。


*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*
  [5年後、会社はどのようになっているか？]
　前号までのまとめ
*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*

前号までに下記の説明をしました。

(1)グローバル化と標準化に起因する強烈な低価格化・短納期化
　圧力が存在します。
(2)しかし、設計は技術的・非技術的要因によって容易には圧縮
　できません。
(3)したがって、製造部分に圧縮圧力が集中し、その結果として
　設計と製造とが極限にまでオーバーラップした漸増的開発が
　求められます。
(4)しかし、請負契約というものは、設計が完了してから製造を
　開始することを前提とした契約モデルであり、もともと「設計と
　製造の並行」や「漸増的開発」とは本質的になじまないものです。
(5)したがって、システム開発会社がユーザの低価格化・短納期化
　要求に応えて、「設計と製造の並行」と「漸増的開発」を
　進めようとすればするほど、実際の作業と請負契約との間に
　軋轢を生むことになります。
(6)かといって全てを準委任契約でやろうとすると、予算がオーバー
　するリスクをユーザが負うことになり、(1)の低価格化・短納期化
　圧力と矛盾することになります。


*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*
  [5年後、会社はどのようになっているか？]
　初期の「設計と製造の並行」
*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*

さて、そもそも設計と製造とはどこまで並行して進められる
ものなのでしょうか？

設計と製造を並行して進めるということは、昔からありました。
例えば、ブルックスは「人月の神話」の中で次のように記しています。

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

(2)創造的作業には、アーキテクチャ、インプリメンテーション、
　そして実現という別々の三つの局面がある。実は、それらは
　実際には並行して着手し、同時に進めていくことが可能なのだ。

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

ブルックスは外部設計グループと実装グループを分割し、並行して
作業を進めることによって、スケジュールを短縮することは可能
だと言っているのです。

しかし、「人月の神話」は1975年に書かれた本です。
この時点では、ブルックスも「設計が完了する前にコーディングを
始めろ」とは言っていません。「設計と並行して、コーディング
以外にできる作業が実装者と実現者には山ほどある」と言っている
のです。

これはウォーターフォールを修正した開発手法であり、
契約形態で言えば、請負契約を若干修正する程度で済む範囲内の
「設計と製造の並行」でした。


*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*
  [5年後、会社はどのようになっているか？]
　漸増的開発によって次の段階に
*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*

漸増的開発の登場によって「設計と製造の並行」は「設計と並行
して製造の準備をする」という以上の段階に入りました。
設計が完了する前にコーディングを始めるようになったのです。

漸増的開発とは第6号で解説したとおり、「システムはたとえ
適当なダミーサブプログラムを呼び出すこと以外役立つことは
何もしないにしても、まず動くように作られるべきである。
それから少しずつシステムを肉付けしていく」(ブルックス
「銀の弾などない」より)という手法です。

1980年前後から普及し出した手法で、ブルックスも1986年に
書いた「銀の弾などない」では、積極的に奨励しています。

漸増的開発は、低価格化・短納期要求の強まりを背景に、
オープン系・WEB系技術と結びつき、今日では一般的な開発手法と
なりました。

しかし一般的になるにしたがって、ユーザによる仕様決定の
遅れを容認する手法として理解され、無計画、無設計、無仕様な
まま製造をスタートするということが行なわれるようになりました。


*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*
  [5年後、会社はどのようになっているか？]
　目を閉じて高速道路を運転する
*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*

漸増的開発とは、ユーザによる仕様決定の遅れを容認する手法では
ありません。逆に仕様決定を強制する手法なのです。
漸増的開発の本質は、製造→フィードバック→製造→
フィードバック→・・・の繰り返しです。
したがって、ユーザの積極的な関与と迅速なフィードバックが
不可欠な手法なのです。

ピート・マクブリーンは「ソフトウェア職人気質」でこの点を
下記のように強調しています。

　開発者に対してフィードバックを与えることなく、作業を
　1日以上にわたって任せてしまうのは、ユーザ側の大きな
　ミスと言えるでしょう。同様に、ユーザに結果確認を1日以上
　遅らせることを許してしまうのも、開発者側の大きなミスと
　言えます。どちらのミスも、目を閉じて高速道路を運転する
　ようなものであり、遅かれ早かれ、大慌てでハンドルを
　切らなければならない羽目に陥るのです。

漸増的開発とは、積極的に関与しないユーザにとっては、また、
そのユーザを許す開発者にとっては、むしろ有害な、正しく
「目を閉じて高速道路を運転する」手法なのです。

そのように考えると漸増的開発を前提とした請負契約は、
プロジェクトはユーザとの共同作業であるということを前提
としたものにならなければならないでしょう。


*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*
  次回以降の予告
*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*

次号は、2月23日発行予定です。乞うご期待！！
今後は、技術よりも会社や組織について話題を移していこうと
思っています。


--------------------------------------------------
発行：
株式会社 慶
　代表取締役  蒲生 嘉達
y_gamou@kei-ha.co.jp http://www.kei-ha.co.jp
TEL：03-5951-8490  携帯：090-1258-6347