残り1回となりました日経SYSTEMS2月号の連載コラムです。
僕が最近強く感じてるのは、
ユーザー・ニーズは「新規開発の生産性」から「追加開発を伴う運用保守性」に移ってきている。
という変化です。これは変えられない流れ。それは、なぜか。
背景にあるのは近年の経済状況だ。この不況下では情報システムをなるべく長期間使うことが必要になるが，ビジネス環境の変化は大きく，システム変更を免れない。できる限り再構築を避けながら，システムの改善を繰り返していくことが求められる。
「運用保守性」を高めるにアーキテクチャの観点は非常に重要です。この例として挙げられるのがクラウド・コンピューティングです。
クラウド上にアプリケーションを追加しても，データ量やユーザー数などが増えたとしても，基本的には問題なくサービスを拡張できる。
その理由というのが、
ただし，現状のクラウド コンピューティングはアーキテクチャにかかわる制約が多い。例えば，オンプレミスのシステムとの連携，処理時間（Google App Engineでは30秒以内）ユーザー，インタフェースの開発（Force.comでは専用ツールが推奨される）制約として挙げられる。
つまり、アーキテクチャに一定の制約を課すことで、拡張性を担保しているわけですね。一方で、オンプレミスを考えてみると
クラウドのような拡張性を担保することは難しいので，（機能などを）「追加」していくのではなく，既存のものを「変更」していくことが求められる。その場合に重要なのは変化の影響を限定することで，言い古された言葉になるが「モジュール化」の徹底を図るのが効果的だと思う。
ただし、これを「徹底」するのが大変です。そもそもオブジェクト指向だってEJBだってモジュール化は大事なテーマでした。しかし、モジュール化を実現するための枠組みが設計思想でしかなかった。そこでOSGiのようなモジュール間での境界制御を可能にする技術が重要になります。その代わりOSGiも制約（バンドルにしないとリリースできないとか）があります。
このように「新しいアーキテクチャを活用する」＝「既存とは異なる制約を受け入れる」ことで、顧客にとってはこれまでにない価値を提供できるようになるのです。これまでの制約や所与を変えることなく都合良く得られるものを変えることはできません。特に今の時期は大きな変化の変わり目だと感じています。
システムを作ることが難しかった時代は開発生産を高めていれば対価を得ることができた。しかし，その時代は終わろうとしている。これからは，システムが長期間にわたって顧客に価値をもたらすことを示さなくてはいけない。そのためにはアーキテクチャの視点からシステム開発全体を見直していく必要がある。
作ることではなく、使ってもらうこと。ここに注目できるか、そのために何を受け入れるべきか。冷静な視点で見るべきだと考えています。
