« 「プログラミングの専門家」でも「ツールの専門家」でもなく | トップページ | ビブリオバトルで蘇我入鹿を語る »

2015.06.01

システムモデルを事業別に分割する

 成長する過程で企業はしばしば、複数の事業を擁することになるものだ。新しい事業をみずから立ち上げることもあるし、関係企業と合併することもある。新事業はたいていは既存事業と補完的だったり相互扶助的な関係にあるが、どれとも無関係なこともある。たまたまその事業に進出しやすい条件を持っていたとか、将来を見据えた布石などのさまざまな理由がある。

 では、そういった複数事業を含む企業の業務システムは、どのようにモデリングされたらいいのだろう。たとえば5つの事業を含む企業があるとして、これをそのまま単一の業務システムとしてモデリングしていいものだろうか。

 基本的には、5つの別々の業務システムとしてまとめたほうがよい。なぜなら、ひとつのシステムモデルに含まれる定義要素は少ないほどよいからだ。モデルが洗練されているとしても、全体がむやみにデカいのであれば、モデルの可読性や保守性は劣悪である。少なくとも事業毎の切り分けは必要だ。

 事業毎にモデルを切り分けるといっても、単純に事業の数で分割すればいいということではない。まず、取引先等を含む共用マスターの管理モジュールを切り出す必要がある。事業横断的な請求や入金のしくみがあるなら、債権債務を扱うモジュールとして切り出すといった工夫も要る。その場合、事業が5つあるなら、少なくとも7つのモデルに分かれることになる。

 切り分けるための基準は「データ指向」である。それぞれのまとまりがどんな処理を行うか(プロセス指向)ではなく、どんなデータを主体的に管理するかに着目すればよい。そのようにして切り出されたモデルの全体的な可読性は、確実に向上するだろう。

 興味深いことに、モデルのこういった切り分けを考えることは、企業システムの物理的な構成を考えることとほぼ同義である。モデルが保守性の観点で分割されているのだから、そのままのブロック構造として実装してしまえばよい。結果的にシステムのアーキテクチャは、モデルの管理単位を色濃く反映したものになる。そしてそれは、システム全体の保守性やパフォーマンス、さらに保守の体制や計画に強く影響を及ぼす。モデラーの責任は重大だ。

 ところが、システムモデルをいくつかに分割しようとすると、やっかいな問題が生じる。モデル間で「共用」されている要素の扱いである。そのような要素は複数のモデルに重複的に配置されることになるので、それらの整合性を維持しにくくなる。当然ながら、それらのモデルをEXCELあたりで管理するやり方では無理がある。モデル間の重複要素を「同期」できるような専用のエンジニアリングツールが必要だ。

 このような目的のために、拙作のOSSツールXEAD Modelerの最新版(1.4.20)には「テーブル定義の外部参照」の仕組みが組み込まれている。

 複雑な処理を伴う仕組みだが、使い方は簡単である。たとえば「社員テーブル」が「共通マスター管理システム」のモデルに置かれていて、「A事業データ管理システム」と「B事業データ管理システム」のモデルに「社員テーブル」の定義を重複的に置く必要があるとする。その際に、事業別の「社員テーブル」のテーブル定義に「共通マスター管理システム」を「同期先ファイル」として指定しておく(次図)。

20150601

 これだけで、モデリングツールを立ち上げる度に、同期先ファイル上のテーブルとの整合性が自動的にチェックされる。不整合が見つかった場合には、テーブル単位でインポートして同期することも簡単だ。同一テーブルを複数配置する場合には、事前にどれが「オリジナル」かを決めて、それを一元的な同期先とするのがコツである。複数事業システムを分割する際だけでなく、単一事業システムのモデリングを分業する際にも役立つ。

 システムモデルは適度な粒度で切り分けられるとともに、有機的に管理されなければいけない。なぜなら、システムモデルの読み手は理解力の乏しい人間であり、システムを開発・保守する主体も人間だからだ。だからこそ我々は、専用のエンジニアリングツールを活用しなければいけない。

|

« 「プログラミングの専門家」でも「ツールの専門家」でもなく | トップページ | ビブリオバトルで蘇我入鹿を語る »

コメント

コメントを書く



(ウェブ上には掲載しません)




トラックバック


この記事へのトラックバック一覧です: システムモデルを事業別に分割する:

« 「プログラミングの専門家」でも「ツールの専門家」でもなく | トップページ | ビブリオバトルで蘇我入鹿を語る »