----------------------------------------------------------------------

　（システム間連携の見直しについて）

----------------------------------------------------------------------


----------------------------------------------------------------------
（設問ア）
----------------------------------------------------------------------
１−１．現システムの概要
----
　Ｇ社は中規模の出版社であり、注文、物流在庫管理、
顧客管理などの処理を自社所有のコンピュータシステム
で行っている。
　今回、そのなかの物流システムを再構築することにな
った。
　現在、Ｇ社には３パターンの注文ルートがあり、それ
ぞれの注文ごとに注文処理システムが稼動している。個
々のシステムで作成された注文データは物流システムに
渡され、個別に発注処理が行われる。
　しかし、この流れでは新しい注文ルートが開拓される
度に物流システムを改訂しなければならない。物流シス
テムは社内システムの中でもクリティカルな部分であり、
頻繁に改訂を行うことは避けたい。
　Ｇ社では販売チャネルの拡大を基本方針として挙げて
おり、今後も注文ルートは増え続けると思われる。そこ
で、物流システムの安定性と保守性の向上を目指し、物
流システムの再構築を行うことになった。
　私はこの再構築プロジェクトにアプリケーションエン
ジニアとして参加した。　

----
１−２．再構築の概要
----
　注文共通フォーマットを定義し、各注文システムでこ
の共通フォーマットの形に注文データを変換する。その
後、物流システムへ渡し、物流システムでは個々の注文
データを一本化して一括処理をする。

----
１−３．全体システムに与える影響
----
　３つの注文システムでそれぞれ作成している物流シス
テムへのインターフェイスファイルを変更しなければな
らない。
　物流システムはクリティカルなシステムであるため、
誤動作で異常停止した場合の損失は非常に大きい。シス
テム全体としての信頼性を最優先させる必要がある。
　

----------------------------------------------------------------------
（設問イ）
----------------------------------------------------------------------
２．受渡しデータの洗い出しと標準化
----------------------------------------------------------------------
２−１．物流システム現行モデル分析
----
　まずは現行の物流システムで行われている注文データ
ごとの発注処理を詳細に分析することにした。再構築を
決定する際のシステム分析結果を見ると、これら各発注
処理では重複した処理が多数存在していることがわかっ
た。
　私はＤＦＤを使って物流システムの各発注処理の現行
物理モデルを作成した。この時点でも明らかな処理の重
複やデータの二重持ちが判明したが、さらに厳密に分析
を行うために現行物理モデルから現行論理モデルへの変
換を行うことにした。
　論理モデルを作成したことによって、現行の発注シス
テムの処理内容が明確になった。
　また、ＤＢ上に多数の重複項目（シノニム、ホモニム）
が存在していること、コード体系についても一部で不整
合があり、標準化が必要であることが判明した。

----
２−２．物流システム新モデル作成
----
　この発注システムを共通フォーマットを使用した一括
処理に切り替えるために、ＤＦＤを使用して新論理モデ
ルを作成した。
　上述のとおり、各注文処理ではもともと同じような処
理をあえて別処理で行っている箇所が多い。これら処理
を統合すること自体は比較的容易であることが判明した。
　次に、新論理モデルから新物理モデルへの展開を行っ
た。ここでは処理やデータの重複削除や項目の標準化な
どを重点的にチェックし、データについてはＥＲ図を作
成して正規化を行った。この時点でインターフェイスの
共通フォーマットが仮決定された。

----
２−３．注文システム変更
----
　次に、各注文システムの物流インターフェイス作成ロ
ジックの変更を行った。出力フォーマットを共通のもの
に変更する他標準化された項目や正規化されたテーブル
への対応も行なわなければならない。
　この作業を行う上で、次のような問題が発生した。

----------------------------------------------------------------------
３．標準化にあたっての問題点とその解決策
----------------------------------------------------------------------
３−１．テーブル正規化の問題
----
　当初、共通フォーマットを設計する際の方針として、
出来る限り正規化することを重視していた。しかし、３
つの注文処理のうちの１つは完全に正規化した形のレコ
ードを作成するのが困難であることが判明した。この作
業を無理に進めると、工数の増大から納期遅れが起きる
ことは確実であった。さらに改訂内容が複雑なことから、
バグ発生によるリスクも増大すると思われた。

----
３−２．データ項目標準化の問題　
----
　データ項目の標準化を考える際に、システム全体の整
合性、保守性を考慮すると入力から最終的な出力まです
べての処理において標準化されたデータを使用するべき
である。
　しかし、３つの注文システムのすべてについて標準化
に則った改訂を行うのは、工数とスケジュールの関係か
ら不可能であった。

----
３−３．問題点の解決策
----
　先にも述べたように物流システムはＧ社の情報システ
ムにおいて非常に重要なシステムである。
　正規化や標準化も重要であるが、システム間連携の見
直しにおいては、統合システムとしての整合性・性能・
信頼性の確保が最優先課題である。この観点から、私は
以下のような対応を取ることにした。
　テーブルの正規化に関しては、既存の注文システムの
改訂工数とのバランスを考慮し、無理に完全正規形には
しないことにした。
　データの標準化に関しては、注文システムの内部処理
は現行のままとし、インターフェイスファイル作成時に
標準形への変換ロジックを通すことで共通フォーマット
を作成することにした。
　なお、標準化資料は明確にドキュメントとして残し、
今後新しい注文システムを追加する際の資料として残し
た。

----------------------------------------------------------------------
（設問ウ）
----------------------------------------------------------------------
４．他システムへの要求と再構築の評価
----------------------------------------------------------------------
４−１．他システムへの要求で重視した点
----
　注文システムの変更において重視した点は処理時間の
極端な増加を招かないようにすることである。
　今回のシステム統合では、３つの注文処理を一括して
行うようにした。当然、物流システムは３つのインター
フェイスの作成を待ってから動き出すことになる。
　インターフェイス作成処理に極端に時間がかかるシス
テムが１つでもあると、全体の処理が遅延することにな
る。このような理由から、各注文システムの処理時間の
上限を設定し、それを超えないことを制約条件とした。

----
４−２．再構築の評価
----
　物流システムへのインターフェイスを共通化したこと
によって、今後、注文ルートが増えた際のシステム改訂
工数は大幅に削減できると思われる。
　また、物流システムの発注処理がシンプルになったこ
とから、システム全体における整合性や信頼性のアップ
にも貢献できた。

　　　　　　　　　　　　　　　　　　　　　（以上）