前回に続き、システム関係者や利用者といった“多視点”から、システムのあり方を考える。システムのテスト性や将来の保守性、拡張性などについても、どこまで対応すべきか、そのバランスを検討しておきたい。
 |
システム設計時に将来の拡張性を考えることは極めて大事である。ちょっと回線を増やしたり、レコード数を増やしたりするだけで、プログラムを改造しなければならないようでは保守が大変だ。こういうものは定数を変えるだけで対応できるようにしておきたい。
しかし、汎用性や拡張性を重視しすぎると、選択範囲が広がりすぎ、細かなところまで初期定義をしなければならなくなる。その設定が面倒になったり、選択のための入力が増えたりするため、操作が面倒になることもある。現在の簡便性と将来の拡張容易性のバランスをよく考える必要がある。事務処理システムなど、社会の動きや経営環境の変化に伴って改修が続けられるようなシステムでは、拡張性を重視すべきである。だが、高信頼性が求められ、基本的に毎日同じ操作が繰り返されるようなシステムでは、簡便性を重視したい。
 |
システムの処理能力を拡充する際は、プログラムは変えず、CPUやサーバー、メモリー、ディスクなどの増設によって対応できることが維持運用にとっては都合がよい。基本設計段階から処理能力増強要請にどう対応すべきかを考え、極力ハードの増設とパラメータ設定変更だけで対応できる設計にしておきたいものだ。増強のたびに論理を変えると、変更ミスによって動いていたシステムまでが動かなくなるという事故が起こる危険性が高くなる。
しかし、ハードの増設とパラメータの変更だけでどこまでも拡張できるわけではない。拡張限界をしっかり文書化しておくことと、拡張限界が近づいたらシステムがパンクする前に、拡張に備えたソフト論理の準備を考えておかなければならない。
 |
経済的なシステム開発を行うためには、すでにできたソフトの活用を図り、できるだけ新規の開発量を減らすことである。そのため新規開発時は、少しでも他のシステムにも使えるよう、汎用性の追求が求められる。たとえ他システムに流用しなくても、汎用性を意識して設計しておけば、そのシステムの機能拡張コストは抑えられるだろう。
したがって、一見専用性が強いシステムでも、「将来、他システムに流用する可能性があるはずだ」と考えて設計するのと何も考えないのとでは大きな違いが出てくる。しかし、一方で汎用性を追求すると初期開発コストが増える傾向があるし、操作面でも専用に作られたものと比べればやや面倒になるというマイナスの面もある。汎用性をどこまで追求するか、汎用性と専用性とのバランスを考えておくことが大事である。
 |
要求される機能や性能、信頼性をシステムが満たしていることをいかに検証するかという、検証性やテスト容易性もシステムの重要な特性である。設計時にテスト容易性の配慮が不十分だと、いざテスト段階になったとき、テストやその結果の確認に時間がかかりすぎることになり、テストをサボる傾向が出やすくなりがちだからだ。
製品自体をどう設計し、どういう機能を付加すればあまり工数をかけずにテストできるかを考えておきたい。
さらに、テスト結果の合否判定をいかに容易にするか、不良発見時の問題個所の切り分けを簡単にするプログラム構造はどうあるべきか、不良原因究明のトレース情報として何を取得するか、再テストの自動化をいかに拡大するかなど、テストに備えた設計を実施しておく必要がある。
