図5　サブシステムが構造的に分割されないと統合時の改修に手間がかかる

[画像のクリックで拡大表示]

図6　データを削除できずに情報システムが肥大化
顧客との契約が終了しても債権を回収していない可能性があるので，顧客システムから顧客データを削除できない。そのまま放置すると，顧客情報が漏えいする恐れがある

[画像のクリックで拡大表示]

表1　ユーザー企業とベンダーが共同で策定すべき，
企業情報システムの拡張性を高める指針と設計技法

[画像のクリックで拡大表示]

池田 大造／大和総研　コンサルティングマネージャ

ケース（２）
システム統合が長期化

　次に事業再編や企業合併などのときのシステム統合に手間がかかった商社Y社の事例を挙げる（図5[拡大表示]）。衣料品については，購買・受注・出荷というようにサブシステムが分割されていた。ところが食品については，購買や受注などの管理単位をきっちりと分けていなかった。事業部の再編によって受注システムを統合することになったが，食品管理システムのシステム改修に大変な期間とコストがかかった。購買システムと受注システムの間をまたがって，プログラムがデータベースを参照・更新していたのを1つひとつ分析し，修正したからだ。

　一方，日用品管理システムは，サブシステムの分割が行われていたので，受注システムを統合するときは，食品よりも分割が楽だった。ただし，衣料品とは分割の単位が異なっていた。例えば「出荷日を確定する情報」の管理が衣料品と日用品では異なった。このように統合するシステムの機能やサービスに整合性がないと，やはり作業期間やコストが増加する。

　衣料品と日用品の管理システムを，異なるベンダーが勝手に作るとこうなりやすい。ベンダー独自の基準でサブシステムや機能の分割を行うからだ。その結果，拡張性が低下する。

ケース（３）
データやプログラムを消せない

　不要なデータやリソース（プログラムなど）を消せずにシステムが肥大化し，拡張性を損なったサービス業Z社の例を示す（図6[拡大表示]）。

　システムの拡張性を重視せず，稼働だけを目標に据えたため，不要なデータやリソースの削除方法の規定については，優先順位が低くなり検討されないまま放置した。このため解約した顧客データを消そうと思っても消せない状況になった。

　本来は解約した顧客が料金をすべて支払っていれば，顧客データベースから顧客データを削除できる。しかし，料金が未払いで債権が残っている場合は削除できない。図6のシステムでは支払い済みか未払いかを区別する仕組みを設けていなかったので，顧客データを削除できなかった。

　一般的な話になるが，現在システム連携によって，顧客データを様々な業務アプリケーションが利用するようになっている。連携する業務アプリケーションを無秩序に拡張していくと，データの参照・更新などの管理の整理に手間がかかるので注意すべきだ。システム改修やデータ移行の期間とコストも増えてしまう。セキュリティ対策にも影響を与える。契約を解除した顧客データが情報漏えいする恐れもある。

　従って設計の初期段階における拡張性の考慮が必須である。データについては生成から消滅までのライフサイクルを設計時点において定義し，維持管理すれば解決できる。

開発工程で指針を提示すべき

　このような拡張性の欠如はなぜ起こるのか。理由はシステム構築・保守の管理体制の問題と技術的な問題の2種類に大別できる。技術的な問題については，第2回以降に述べる。今回は構築・保守の管理体制の問題と対策について示す。

　システムの拡張性は，設計時点でそれらを意識しなければ高めることは困難である。しかし最近，特に1990年代後半のオープン化以降，マルチベンダー化などによって，拡張性を高める手立てを講じるのが難しくなっている。よく見うけられる6つのパターンを列挙してみよう。

（1）ベンダーがバラバラに開発

　拡張性向上のためには，システム全体のサブシステム分割，データ項目の整合性確保などが必要である。しかし，複数のベンダーが何の基準もなしに開発を進め，図5のようにシステム分割の考え方がバラバラになっているケースがよくある。こうなると拡張性は著しく低下する。

（2）開発と保守担当が異なる

　開発ベンダーは初期構築時の納品に際して，そのシステムの機能や性能については要求仕様を実現する。しかし，システムのライフサイクルを意識してコストをかけることについては積極的ではない。こうなると，図3のような拡張性向上策を採用せずに，図2のようにユーザーに聞いたままに設計してしまうことになりがちだ。

（3）拡張性の低下を黙認する

　保守にかかわる対価が人月のみで評価される場合，拡張性が低ければ低いほど，工数が増えベンダーの売り上げが増す。結果として拡張性を高めるインセンティブは働きにくい。

（4）コスト削減で拡張性を無視

　ベンダーが保守フェーズを考慮して拡張性の高いシステムを提案しても，拡張性向上のための費用に対する発注者側の理解が得られず，結果として実装できなかったケースがある。発注者側は保守工程までを考慮し，ライフサイクル全体でのコスト低減を主導する必要がある。　

（5）暫定対応システムを放置

　本来であればシステムの全体構造を崩さない形でシステム改修を行うべきであっても，その変化対応に与えられた期間やコストなどの制約により暫定的な対応を行わなければならないことがある。それらをその状態のまま放置すると，図4のように指数関数的にシステム改修に要する期間やコストが増大することになる。

（6）拡張性確保の手法が未確立

　拡張性の重要度は認識していながら，それらを確保するための手法を確立していないケースも多い。例えば，サブシステム分割といっても，やり方によって拡張性は著しく変わってくる。技法が確立していなければ，拡張性を高める意識はあっても，図2のようにシステムを分割してしまうこともある。詳しくは第2回以降に解説するが，確立された体系に基づく技術が必要になる。

　拡張性はこのように発注者が意識して高めようとしなければ，容易に崩れる。しかし，それを理解するのは難しいので，専門家であるベンダーが分かりやすく発注者に説明しなければならないことが少なくない。

拡張性向上・維持ガイドライン

　表1[拡大表示]に拡張性を高めるための指針を示す。基本は，サブシステムの独立性が高いシステムを開発し，維持し続けることだ。この目標に利害関係者が無理なく向かっていくために必要な項目をまとめた。

　組織体制，管理体制については，システムの拡張性の向上・維持という目標を開発時からユーザー企業が掲げ，責任を明確にすることが不可欠だ。複数のベンダーがシステム作りにかかわっている場合は，ユーザー企業が主導するガバナンス体制を作ることが重要である。さらにユーザー企業とベンダーは拡張性を定期的に評価し，拡張性維持について監視する仕組みを作るべきだ。ベンダーの責任者と一緒に，開発工程や保守工程で状況を適宜チェックし，是正すべきところには手を入れなければならない。拡張性を維持するための利害関係者の教育は不可欠である。

　技術面については開発工程で考慮しておかなければならないものもあれば，保守工程において考慮するものもある。第2回では開発の上流工程における設計技法，第3回では詳細設計と保守工程における設計技法を示す。