経営ニーズに即応できるシステムを作るポイントはモデリングによる上流工程での企業活動全体の把握と，それを反映したデータベース（DB）設計にある。ビジネス活動をデータベース更新規則のソフト部品として作り込み，ソフト部品を組み合わせてアプリケーションを作れば，システムは疎結合になり拡張性が高くなる。
前号の第1回では，拡張性を高める手法の全体像を提示した。今回は，上流設計（概念設計）段階における手法を詳しく説明する。この段階で拡張性確保を考慮することがいかに重要か，また，それを実現するためにどのような手順が必要となるかについて解説していく。
ポイントは，企業活動全体を把握し，それに基づいて，経営ニーズの変化に即応できるようにシステムをモジュール化することである（図1[拡大表示]）。まずビジネスにおいてどのような商品やサービスを，どう提供しているのか，全体を俯瞰しながら把握する。さらに，その商品やサービス提供の仕組みを分析したうえで，システムをモジュール化する。
モジュール化によって，経営のニーズが変わってもシステムの改修範囲は局所化される。さらに既存のソフト部品を活用できるので，改修が素早く終わる。
こうしたシステムを実現するために，われわれは概念データモデル設計を中心にした開発手法を利用している注1）。この手法は1980年代から企業情報システムの構築に利用されており，1990年代には書籍［1］にもまとめられている。
この手法はどんなシステム開発にも適用できるが，システム利用部門が複数あり，各システムが連携している全社的な基幹業務系システムに適用すると，より効果が大きい。通常，基幹業務系システムでは，顧客管理や販売，生産，会計などシステムを構成する要素が多岐にわたるため，開発ベンダーが複数になることが少なくない。このようにシステムの構成要素が多く，お互いに連携している複雑なプロジェクトの場合，システム全体で整合性をとりながら開発できる方法論はあまりない。今回紹介する開発手法は，このような基幹業務系システムの開発で威力を発揮すると考えている。
なお，企業の活動全体を把握し，データモデルを中心に設計するという点は，最近注目を集めているEA（エンタープライズ・アーキテクチャ）と同様のアプローチと言える。またモジュール化は，オブジェクト指向技術の手法と似ている。概念データモデル設計を中心にした開発手法は，企業情報システムにおけるEAやオブジェクト指向技術の実践手法と位置付けられる。
サブシステム分割を体系化
拡張時にシステムの変化の影響を局所的かつ最小にできれば，情報システムの拡張性が高まる。このため，通常はある程度の規模のシステムは，1つの大きなかたまりとはせずにサブシステムに分割する。ところが稼働してしばらくたつと，システムの構造が徐々に悪化し，拡張に時間がかかるようになっていくシステムが多い。やがて経営ニーズに応えられないほど時間とコストがかかるものとなり，全面再構築に至る。
なぜそうなってしまうのだろうか。よく見かけるのは，以下の3種類のケースである。
1つは，サブシステム分割の際に，ユーザー要件の検討が表層的なレベルにとどまっているケースだ。その企業の本来のビジネス活動を検討しないために，稼働後に想定していなかったサブシステムを次々と作らざるを得なくなって，システムがつぎはぎになる。
2つ目は，サブシステムの分類がきっちりとできていないケースである。アプリケーションとミドルウエアの区分けは行うが，アプリケーションの分類については十分に行っているとは言い難い。アプリケーションには変化しづらい部分と変化しやすい部分があるにもかかわらず，それらを分離せずにごちゃまぜにとらえているシステムが少なくない。こうなるとシステムの部分的な変更でも，様々な個所に影響が波及してしまう。
3つ目は，各サブシステムの役割がきちんと定義されていないケース。例えば，当初はフロント系（コールセンターや顧客用ポータルサイトなど），基幹業務系，情報系と分割しても，本来情報系で行うべき顧客分析や利用実績統計作成などの機能を，フロント系や基幹業務系に実装することがしばしばある。利用部門が個別の判断で機能を拡張する場合に，こういう事態になることが多い。利用部門の視点で見ると効率的に思えるが，全社視点およびシステムのライフサイクル全体で考えると決して許されるものではない。
逆に言えば，これらの問題を解決できれば拡張性を高められる。しかし，こういった問題を防ぐのは極めて難しい。単に形式的なルールを作っても，形骸化するだけである。
われわれは，利害関係者（ステークホルダー）が納得しながら，無理なくサブシステムを分割・維持できる，概念データモデル設計を中心とした開発手法を利用している。今回はこの開発手法を具体的に解説する。
企業のビジネス全体をとらえる
開発の手順を前ページの図2[拡大表示]に示す。最初にその企業のビジネスの概観を理解する。現時点の状況だけでなく，経営戦略や事業戦略，事業計画，他社動向，海外動向，情報技術動向などを考慮する。個別のユーザー要求にとらわれず，その企業でどのようなビジネスを行っているのかをとらえる。システムにどんな機能が必要か，といった個々のアプリケーションの要件定義は，上流工程では行わず，詳細設計・プログラミング段階の終盤に行う（詳しくは後述）。
次に開発・保守工程の基準となるモデルとアプリケーション構造図などを作成する。さらに既存システムを考慮しながら，段階的に開発を進める計画を作る。その計画にしたがって，詳細設計・プログラミングをサブシステムごとに行う。
なお実際は，図2のような開発の手順を決めるだけでなく，これをステークホルダーに周知・浸透させ，順守させるとともに，設計手順を随時改訂することも必要である。
以下では，図2の手順に沿って開発手法を説明する。
|
概念データモデル
|
|
システムの安定な部分を
区分け |
概念データモデル策定の目的は，ビジネス自体が変化しない限り変わらない本質的な部分と，変化しやすい部分を分離することにある。
前回，拡張性の低いシステムとして，顧客の申込書単位でシステムを作ったために顧客情報や契約情報，申込経路情報がまぜこぜになった例を挙げた（第1回の図2参照）。申込書は，事務効率の改善，代理店やWebサイトなどの申込経路の追加により変わりやすい。これに対し，企業が扱う顧客情報や契約情報は，その企業が全く別の事業展開を行わない限り変化しない。
従って，こうした変化の頻度の違いを整理したうえで，申込経路は分離し，システムの中核には配置しないようにすべきである。一方，顧客情報や契約情報は安定しているので，システムの中核に位置付ける。こうした分離作業を概念データモデルによって行う。
概念データモデルは主に，「静的モデル」と「動的モデル」から構成される（図3[拡大表示]）。
静的モデルでは例えば，「顧客」は「口座」を「保有している」，というようにビジネスの対象になる人や商品，設備といった「もの」を中心に見ながらビジネス全体の構造を明らかにする。
静的モデルの表記法は，一般的な実体関連図（ER図）と同様である。ただし拡張性を高めるためには，ER図の作成プロセスで注意すべきことがある。帳票や画面からデータを拾い集めて，それらを正規化注2）していく方法をとってはならない。ビジネスで何を顧客に提供しているのか，といったことを深く考える必要がある。
例えば個人の顧客に関しては，「世帯」単位でみるのか，「世帯構成員」にまで分けるのかを，概念データモデルで明確にする。通信事業者の例でいえば，固定電話やADSLの顧客は通常「世帯」だが，携帯電話なら「世帯構成員」を顧客としてとらえることが多い。
このように考慮しながらモデルを描けば，世帯構成員の間には「同一世帯である」という関連があることを，容易に認識できるようになる。その結果，家族単位での割引サービスなどに備えた仕組みを，システムにあらかじめ盛り込んでおくことができる。これによって新たな改修・投資を必要とせずに新規のサービス提供が可能となる。
なお，企業が顧客に対して提供するサービスメニューは，様々なサービスの組み合わせになっていることが多いので，サービス全体の構造を押さえておくべきである。それらの組み合わせにより幅広いサービスメニューのラインアップが可能になるからだ。また，サービスを実現するための設備や仕組みが分かれば，新しいサービスのコストなども把握できる。委託先や取引先も含めて，経営資源の全体をモデルによってとらえることが大切である。
一方の動的モデルは，例えば，顧客からの「契約申込」によって契約の手続きの作業が発生し，それによって交換機の設備手配を行う，というように，「もの」の状態変化を引き起こす活動について規定したものだ。データの生成から消滅までの状態変化規則を定義することになる。例えば「契約申込」から「設備手配完了」，「解約申込」などへの一連の変化を規定する。このモデルを作成することで「もの」に対する認識が静的モデル策定時よりも明確になる。静的モデルが誤っている場合はフィードバックして修正する。つまり静的モデルと動的モデルは相互補完しながら，スパイラルにその精度を高めていく。
なお，このほかに「相互作用モデル」を描くことも多い。例えば，契約申込みは「契約」と「顧客」に作用する，というように示し，「契約」と「顧客」に対する責任や権限を持つ組織を定める。企業が活動を行ううえで必要となる組織間の連携が分かる。現状の組織の形態を考慮せずに，本来あるべき組織連携を定義していくので，システム構築の際のBPR（ビジネス・プロセス・リエンジニアリング）に効果的である。
拡張性の大切さを経営者に説明する情報システムに詳しくないユーザー企業の経営者に，拡張性の大切さや難しさを理解してもらおうとして苦労することは少なくない。筆者はそんなとき，情報システムの構造が悪化していく過程を，パソコンのフォルダ構造に例えて説明している（図A[拡大表示]）。つまりサブシステム分割をフォルダ分割に例えると，「イメージが湧きやすい」という経営者はけっこう多い（ただし，もちろんパソコンを使っている人が対象になる）。 パソコン上の文書ファイルをごちゃまぜにしていると，文書を探す時間がかかる，関連文書の存在を見落とすといった問題が発生する。そのため，フォルダを分割し管理を行うことが多い。 ところが時間の経過とともにフォルダの追加や階層構造の見直しが行われ，複雑になってファイルを容易に見つけられない，といった事態になることが少なくない。最悪の場合は，全く新しいフォルダをつぎはぎで作るか，今後の作業効率向上のためすべてのフォルダの再構成を迫られる。 その原因として，（1）フォルダ分割を行う際に将来の変化を考慮していない，（2）フォルダの役割，分類の基準があいまい，などが挙げられる。これは情報システムの構造が悪化する原因と同様である。 |
| 池田 大造（いけだ だいぞう）／大和総研 テレコムシステム事業本部 コンサルティングマネージャ |
