企業情報システムの設計者に現在最も求められているスキルの1つが，変化に即応できる設計力だ。経営ニーズの変化に対応して，情報システムを迅速に改修できなければ企業の競争力が落ちてしまうからだ。3回の連載で情報システムの拡張性を高める設計技法を，組織体制から開発工程，保守工程の全域にわたって解説する。
池田 大造／大和総研 コンサルティングマネージャ
企業が自社のビジネスに情報システムを利用する領域は，広がる一方だ。以前は会計や生産など企業活動の部分的な処理を効率化するに過ぎなかったが，現在ではほとんどの業務に使われ，業務を連携する役目を果たすようになった。言い換えるとシステム注1）は，企業のビジネスを投影したものになっている。
一方，企業の経営環境は日々変化している。新商品や新サービスは次々と登場し，顧客管理や販売・物流，生産などの業務の変化も絶えることがない。システムの拡張性が低く，こうした変化への対応が遅れた場合，競争優位を維持することは困難になる。いくら良い経営戦略を立てたとしても，その戦略を執行できなければ企業の持続的成長は難しい。
つまり企業が持続的に成長するためには，システムも「継続的に変化し成長するもの」でなければならない。システムは，カットオーバー（稼働）を無事に済ませるだけでは不十分になったのである。稼働直後から新たな拡張作業が始まることを想定しておかなければならない。
そのためには，ユーザー企業とベンダーのITエンジニアが共同で，開発から運用・保守まで全工程にわたって拡張性の向上・維持に取り組む必要がある。ここでは，当社が実際に大手通信事業者などのシステム構築に適用した設計技法を体系化し，3回にわたって解説する。今回は，「拡張性が低下し変化に即応できないシステム」が，どのようなものかを示す。さらに拡張性低下の原因を，組織や管理体制面から述べる。第2～3回で設計技法を解説する。
ライフサイクル全体の指針作成
拡張性を高めるには一貫した指針と設計技法が必要になる。まず企画・設計段階から拡張性の向上・維持という目標をユーザー企業が掲げ，その目標に基づいて組織体制や管理体制，開発，保守の指針を，ITエンジニアの視点からユーザー企業とベンダーが共同で策定する（図1[拡大表示]）。
図1左のように拡張性を軽視してシステムを設計し，保守工程でその場しのぎのシステム改修を続けていけば，システム構造が複雑になっていく。その結果，システム改修に時間も費用もかかって，経営ニーズの変化にシステムが対応できなくなる。どのユーザー企業も減らしたいと思っている保守費は下げられず，むしろ膨れ上がっていく。システムの寿命は5～10年で尽きてしまい，全面再構築の労力とコストが新たに発生する。ユーザー企業はシステムの中身が分からなくなってしまい，ベンダーへの依存度が高くなる。ベンダーにとっては，保守工数が大きくなり，全面再構築を行う機会が増えることになる。
一方，図1右のように拡張性を重視して開発・保守すれば，システムは肥大化せずに，経営ニーズの変化に迅速に対応できるシステムであり続ける。つまり新規の事業や商品・サービスの開始をシステムが素早く支援できる。企業価値の向上とともにシステムの価値も向上する，と見ることができる。ベンダーには，システム改修の方針が明確に示され，つぎはぎのシステムを放置することがなくなる。
このような経営ニーズに即応できるシステムを作るためには，組織全体の目標として拡張性の向上・維持の方針を掲げ，ユーザー企業とベンダーの1人ひとりのエンジニアにその方針を浸透させる必要がある。拡張性に関する責任者を決め，ITエンジニアやマネジャーが無理なく実行できる具体的な設計手法やガイドラインを設けなければならない。開発工程では，拡張性を向上・維持する仕組みを作り込む。ただし，保守工程で気を抜くと，システムはすぐに老化への道をたどるので，拡張案件の受け入れ体制や暫定対応のルールなどをあらかじめ決めておくべきだ。
ただ，これらが「言うは易し，行うは難し」であることを，システムの開発・保守の現場にいる人は日々実感しているだろう。拡張性を高める作業は，開発工程では機能が増えないのにコストはかさむ要因になりがちだ。そのためシステムに詳しくない経営者や経営企画担当者には拡張性を高める作業の意義が理解されないことが多い（もちろんシステムのライフサイクル全体ではコストは下がるが，それを説明するのは難しい）。保守工程での作業も，地味で目立たない。経営とシステムの両方を考えるプロ意識の高いITエンジニアでなければ，拡張性の向上・維持策は提案・実施できない。
このような状況において，システム開発のすべての利害関係者が，拡張性の向上・維持という目標に進むためには，現状の問題点を明確に共有する必要がある。
変化に追随できない実態
現状のシステムの多くは，初期構築時から1年，2年と経過すると，内部構造が複雑化してくる。ではシステムの内部構造が複雑化するとはどういうことだろうか。一般的に多いと思われるケースは次の3つだ。
(1)新サービスを提供するための改修に時間がかかるケース。同じデータやプログラムを2重，3重にシステム内に抱えているため，システム改修時の変更作業も2重，3重になって工数が膨大になる。
(2)事業再編や企業合併などのためのシステム統合が長期化するケース。
(3)データやプログラムを消去できずシステムが肥大化するケース。これは拡張性だけでなく，セキュリティ対策にも悪影響を与える。契約を解除した顧客情報がその後も残っていて漏えいし，問題になる恐れがある。
以下では，それぞれのケースに当てはまる事例を挙げ，問題点を具体的に見てみよう。
ケース（１）
新サービス向けの改修が困難
まず新しいサービスを提供するときに，システムが迅速に対応できなかった会員制サービス業X社の例を示す（図2[拡大表示]）。複数の事業を利用している顧客に対する請求書を統合し，新たなサービス（割引など）を新設するというビジネスの変化にシステムが対応できなかった。この例は，金融機関の複数商品を統合した新サービスや通信事業における割引サービスなど，顧客と複数の契約を結ぶことがある事業の多くに当てはまる。
図2を見れば分かるように，X社は顧客情報と契約情報をひとくくりのデータとして管理していた。ユーザー企業がベンダーのシステム設計者に対して，「契約者に対する請求業務を，システムを使って省力化したい。割引サービスの計算も自動にしたい。この伝票に契約者の住所や契約内容が書いてあるので，そのデータを使ってシステムを作ってくれ」と伝え，そのままシステムを設計したからだ。
A事業とB事業が分離されたままならこれでも問題にならなかった。しかし競合他社が，請求書を顧客ごとにまとめて発送し，A事業とB事業の両方を利用している顧客には割引率を高める，という新サービスを提供した。X社も対抗するために同じサービスを提供できるように，システムを改修することにした。
X社はこの改修で，既存システムとは別に「A事業とB事業の両方を利用する顧客のための統合請求用顧客管理システム」を新たに作り，ここにA事業とB事業を利用する顧客情報を集約する方法を採用した。ただし，これが拡張性に悪影響を与え，次の2つの問題を引き起こした。
問題の1つは，顧客情報が多重管理になったことである。顧客情報に「事業所」や「家族」といった属性の項目の追加が発生した場合，「顧客情報A」，「顧客情報B」，「顧客情報T」のすべてにその項目を追加しなければならなかった。本来は1カ所の変更で済ませたい。ただし，例えば「顧客情報T」だけに属性を追加すればよい，というわけにはいかない。A事業とB事業を利用していた顧客が，そのうちに事業Aか事業Bのどちらかしか利用しない状況になるかもしれないからだ。このため，実際には3カ所変更することになった。
もう1つの問題は，割引プログラムについても新たに「統合請求単位割引プログラム」が加わり，割引規則の変更に伴う作業がやはり3重管理になったことだった。顧客に対する割引の適用判定が複雑になりシステムが肥大化した。
ここで，どうすればよかったのかを示しておく。図3[拡大表示]のようにシステムを作っておけば，請求や割引サービスの統合は容易だった。図3（a）のように，顧客情報と契約情報を別々に分けておく。顧客単位の割引プログラムと，契約単位の割引プログラムも分割する。このようにしておけば，統合する場合もシステムの構成がほとんど変わらないので，図2のような問題は発生しない。
なお，図2の状況から顧客情報と契約情報を分離するのは容易ではない。例えば，鈴木一郎さん（仮名）という顧客がA事業とB事業を利用していたとしよう。図2（a）では2つのシステムにそれぞれ鈴木一郎さんの名前や住所などが入っている。図2（b）のように統合したとき，A事業の顧客の鈴木一郎さんとB事業の顧客の鈴木一郎さんが同一人物なら，本来はどちらかのデータに統合して一元管理したい。
しかし，図2のシステムでは「A事業の顧客の鈴木一郎さん」というように契約情報と顧客情報の組み合わせでしか管理していない。「鈴木一郎さん」を一元管理するには，顧客情報と契約情報を分離して，顧客を1人ひとり識別できるようにする必要がある。ただし，図2の状況からそれを実行するのはシステム再構築に匹敵する期間と費用を要する。
指数関数的に工数が増大
図2と図3は小規模なシステムなので，差がはっきりと分からないかもしれない。しかし事業がC事業，D事業というように増えると，住所など顧客の属性が変わることによるシステム変更個所が大きく広がってしまう。さらに，顧客情報や契約情報のほかに顧客の申込登録情報などが新たに加わってくると，指数関数的に複雑度が増す（図4[拡大表示]）。すなわち，代理店経由で申し込むか，Webサイト経由で申し込むかによって，データベースを変えて管理するシステムになる可能性がある。こうなるととてつもなく複雑なシステム注2）になり，中核的なデータである顧客情報の項目追加や属性を変更すると，その影響が広範囲に及び，システム改修の期間とコストが膨れ上がる。
システムを作るときに，同じ伝票に記載された顧客情報と契約情報を分割するという発想は，ユーザーは考えもしない。しかし拡張性を重視する場合，ITエンジニアはこのように設計すべきである。
池田 大造／大和総研 コンサルティングマネージャ1963年生まれ。1986年4月，メインフレーマ系システム会社入社。証券取引所のシステム開発・保守を担当。1989年から大和総研で，流通系受発注管理システム，メーカーの生産管理システムを開発。1995年から通信事業のシステム化構想・基本設計を担当。「成長し続けるシステム」の構築を目標に掲げ，手順定義や概念データモデル策定を担当 |
