 |
||||||||||
|
||||||||||
| 1 2 3 次のページ | ||||||||||
|
||||||||||
| はじめに | ||||||||||
|
これまで第1回と第2回を通じて、開発方法論とその作業手順に相当する開発プロセスについて論じてきた。これらはソフトウェア開発を行う上で基盤となるものである。またモデル駆動型開発は成果物の自動生成のみならず、ステークホルダごとの観点を成果物より一段高い抽象度で調整することによって、開発効率の向上に大きな役割を果たすことを述べた。 ではそれ以外に開発効率を向上するためのキーとなる要素は何か。最終回である今回は、まさに開発効率向上の核ともいえる「ソフトウェア資産の再利用」について解説していこう。 |
||||||||||
| ソフトウェア資産の再利用性 | ||||||||||
|
オブジェクト指向やコンポーネント指向、サービス指向を通じて、ソフトウェア資産の再利用性を実現するための試みは長年継続しており、議論されている概念でもある。しかしながらソフトウェア産業では、いまだに実現できていない。再利用性を阻む要因を分析してそれに対処しない限り大きな進展はないだろう。 一方で製造業においては、部品を組み立てることによって完成品を開発するというアプローチが当たり前のように実現されている。なぜソフトウェア産業ではこれが実現できないのか。 ここに「ハードウェアとソフトウェアの本質的な違い」が存在するのである。ソフトウェアは、仕様が不明確でかつカスタマイゼーションが頻繁に発生するという特徴を持つ。いわゆる「マスカスタマイゼーション」と呼ばれる特性だ。特に日本では他の国に比べてカスタマイズの要求が多い。 この問題に対して今日まで十分な対応を取らなかったことが、ソフトウェア資産の再利用性を困難なものにしてしまった大きな原因なのだ。開発時に想定したのと同じコンテキストに限り、再利用できる資産というものはある程度存在する。しかし少しでもコンテキストが変化した瞬間に再利用できないというのが現実なのである。 ではこのようなコンテキストの可変性をどのように解決すればよいのか。答えは「可変性に対して徹底的に対処すること」である。 |
||||||||||
| 可変性への対処 | ||||||||||
|
可変性に対処するには、まず対象ドメインにおける可変部分を特定するという作業が非常に重要である。筆者の経験からいうと対象ドメインを10年以上経験している開発スタッフには、そのドメインにおける可変部分が暗黙的にわかっているものである。 ただ可変性とは大小入り乱れて様々な形で存在するため、明確に把握できていないケースが多い。これを分類し、形式知化する作業が重要なのである。そして分類ごとに最適な対処方針を決定し、それをアーキテクチャに反映していく。アーキテクチャが決定されれば、それに従って実装を進めるのである（図1）。  図1：可変性への対処の流れ では次項から順を追って説明していこう。 |
||||||||||
| 可変性の特定と分類 | ||||||||||
|
まず可変性を特定する作業が非常に重要だ。これを実現するには、開発組織に存在するナレッジを掘り起こして活用することが求められる。筆者も複数の開発プロジェクトで実際にこの作業に関わっているが、大抵の場合、10年以上前からの変更要求履歴などが存在しており、それを参照することである程度の項目はカバーできる。 ただし、100%のカバー率に近づけるには開発スタッフ自身に蓄積されているナレッジをいかに引き出すかがポイントとなる。この段階の作業は地道であるが、その効果ははかりしれない。 次に特定された可変性を分類するための項目を洗い出す。表1の分類項目は一般的なものであり、対象ドメインによっては違う項目が含まれることもあるが、それも含めて対象ドメインに対する深いナレッジが求められる。
表1：分類項目 |
||||||||||
|
1 2 3 次のページ |
||||||||||
|
|
||||||||||
|
|
||||||||||
|
||||||||||
|
|
||||||||||
|
||||||||||
|
|
||||||||||
|
||||||||||
-
-
連載
