 |
||||||||||
|
||||||||||
| 前のページ 1 2 3 | ||||||||||
|
||||||||||
| 目的指向の開発態度 | ||||||||||
|
ここまで目的に着目して開発を進める意義について述べてきた。ではこれらの目的・利点を理解した後具体的にどういう作業を実施するのか。それは目的・利点ごとに具体的な要件として整理した上で、要件を達成するために必要な作業を特定するのである。 例えば「保守性の向上」を例にあげてみよう。いうまでもなくこの目的は保守担当者の観点で整理されるべきものである。表5の要件が主なものとしてあげられる。
表5：保守担当者の観点における要件
さらに一歩掘り下げて考えると、表5の1は自律した単位を特定した上で、コントラクトやポリシーといった自律性を保つ仕組みを必要とする。2を実現するにはモニタリングする対象項目を規定することが必要だ。3は構成可能な項目とそれら項目の格納手段や反映手段を選択することが必要となる。最後に4は状況の応じた柔軟なシステムの配布手段を規定することだ。 あげればきりがないが、このように保守担当者から見た要件を把握した後は、それを満たすアーキテクチャを構築するのである。 アーキテクチャとは一から構築することは少ない。ほとんどの場合は既存のアーキテクチャとその時に扱う要件とのマッピングが主な作業となる。その様子を図3に示す。  図3：マッピング作業のイメージ 繰り返し「目的」を強調しているのは、「目的」が見過ごされるケースがあまりに多いからである。 今回の開発を通じて何を達成したいのかという根本的な部分である「目的」を常に意識した開発作業が望まれる。目的とはコストダウンだけではない。在庫の圧縮や生産リードタイムの短縮など投資対効果を達成することも非常に重要である。きれいごとをいっているのではない。 事実世界では優れた情報システムにより圧倒的な競争力を発揮している企業が少なからず存在するのである。つまりITの価値とはコストダウンや省力化だけではないといいたいのである。 余談だが、あるEA（Enterprise Architecture）関連のカンファレンスのパネルディスカッションで、「EAの目的は1にも2にもコストダウン」と連呼している偉いお方がいて、それに同調する人も多く、残念な思いをしたことがある。 確かに説得力のある言葉だが、コストダウンだけを強調するのは一面的に過ぎる。米国でEAが連邦政府の法律にまでなったのはユーザ（この場合は国民）の利便性を最大限に考えてのことである。 ソフトウェア開発に従事するものにとって、そのソフトウェアを使うユーザの利便性を忘れてはならない。それこそがソフトウェアの提供する価値なのである。話はそれたが、第2回では開発プロセスについて論ずることとする。 |
||||||||||
|
前のページ 1 2 3 |
||||||||||
|
|
||||||||||
|
|
||||||||||
|
||||||||||
|
|
||||||||||
|
||||||||||
|
|
||||||||||
|
||||||||||
-
-
連載
