日経SYSTEMS 8月号のコラムは「機能拡張の方向性を要件定義しておこう」です。
最近，システム開発案件の話を顧客から聞くことが多くなってきた。景気が回復したというよりも，「不況だからこそITを活用していきたい」という趣旨である。システム開発へのニーズは減少するどころか，むしろ重要性は増していると考えた方がよさそうだ。ただ，顧客の言葉を聞いていると，求められるITの質が大きく変化していることに気づかされる。その一つが拡張性である。スケーラビリティはもちろんのこと，機能の拡張性への期待が大きい。ところが、ですよ。我々エンジニアが考える「機能拡張性」というのは
「想定される範囲内の機能を，後からどれだけ低コスト・短期間で追加できるか」
ということなのですが、ユーザーが考える「機能拡張性」というのは
開発時には予測できない機能を想定しているが，エンジニアは開発時に予測される範囲内の機能を想定している。
ということで、ここにズレがあります。
現実のシステム開発の精度から考えると前者にならざるを得ないのが実際でしょう。そこで、想定される範囲についてきちんと定義をすることが重要になるわけです。可変性分析というのは、未来の不確定要素について変化の方向性の枠組みを決めることで、少しで機能拡張性を確保しようという試みです。
ですから、可変性分析はシステム工学やアーキテクチャパターンの知識があるだけではできません。なぜなら、機能拡張はビジネス環境の変化に対応することが目的だからです。ですから、
拡張性の高いシステムを提供するには，ユーザーのビジネス環境をきちんと理解することが不可欠
なのです。
本来、ビジネスを意識しない中立的なアーキテクチャなんて存在しないのです。確かに鉄板と言えるアーキテクチャパターンはあるのですが、大抵の場合は非機能要件に関するものです（セキュリティとかね）。ビジネスロジック辺りのパターンが少ないのは、そのパターンの適用判断要素となるべき要件が、あまりにも多様である（たとえば業種や業務で単純に分析できない）ことに原因があります。
アーキテクチャに関する知識を持った上でビジネス環境を理解することで、価値あるアーキテクチャが提供できるようになります。
