プログラマの思索

業務システムを開発したり保守している時に、本番障害が多発したり、想定外の障害で業務が止まったりしたりするのが「外部接続」という名の外部システム連携機能だ。
今までの経験も含めて考えたことをラフなメモ書き。

【参考】
ERPの落とし穴part1～SW開発ではない。要求開発だ！: プログラマの思索

ERPの落とし穴part2～業務の裏には会計あり: プログラマの思索

【1】業務システムは基本は何らかのERPを真似たり、そのまま取り入れることで実現している。
その時、一つのシステムで全ての業務をカバーできるわけではないので、複数のサブシステムを作って各システムを連携することで、ユーザ企業の業務をカバーする方式設計が多い。

例えば、基本的な業務システム(仕入れ・売上・請求・在庫など)の他に、会計システムは別システムで作っておき、業務が発生したら自動仕訳が起きて、会計システムへデータが流れるようにする。

例えば、物流や在庫に至る全ての業務をSCMでシステム化した後、経営者が経営分析したりするための情報系システムへ連携するために、日々の売上や原価、物流の情報を日次・月次で集計して送ったりする。

例えば、仕入先から仕入れた商品のデータや仕入伝票をEDI経由でデータを受信し、日次で業務システムに取り込み、発注や物流の業務に使ったりする。

例えば、請求や発注業務で、ユーザ企業が開設している銀行の口座預金からEB連携(あるいはファームバンキング)、仕入れ代金や売掛金の回収を月末の締め請求で一括で支払ったり、入金したりする。

例えば、Felicaなどの電子マネーで決済する場合は、業務システムから送付したいデータを商取引の標準形式に変換して、SOAPのようなAPI経由でデータを送受信したりする。

つまり、基幹系業務システムとは、自社内にあるたくさんの業務システムと連携するだけでなく、仕入先のような外部企業のシステムとEDIで接続していたり、銀行のEB連携したり、SOAPでやり取りしたりする。
あるいは、今流行のソーシャルなデータを連携したいがために業務システムとCRMと連携したり、情報系システムへ連携するなどのやり方もあるだろう。

【2】外部システム連携には幾つかの用語がある。

EDIは、外部システムと標準フォーマットの商取引データ(受発注、決済など)をやり取りする仕組み。
FTPやHULFTなどのプロトコルで集配信サーバーを使う外部接続の方式が多いだろう。
電文のようなテキストファイルやバイナリファイルをやり取りするので、原始的なアーキテクチャとも言えるが、普通は最も基本的なアーキテクチャと言える。
EDIツールと言えば集配信サーバーかな。
バッチ処理が基本なので、COBOLがよく使われている。
枯れた方式設計なので、ノウハウは結構ある。

EAIは、異なるシステム間でアプリケーションの統合・連携を行うための仕組み。
データ連携や中継を行う中核サーバーであるハブと、ハブからデータを送受信する各システムというスポークから成り、ハブ＆スポークのパターンで実現されている。

EAIツールはミドルウェアであり、単なるデータ連携だけでなく、システムごとのデータ形式やプロトコルの違いを吸収する変換処理や、受け取ったデータをシステムごとに振り分けるルーティング機能、ワークフロー制御の機能などがある。
例えば、MSのBisTalkServerなどがあるらしい。
新製品のミドルウェアを導入する場合は、ノウハウがないために、試行錯誤しながら運用に苦労する時が多い。

EAIをオブジェクト指向っぽく、サービスの観点で、システム間でメッセージをやり取りしあう仕組みがSOA。
SOAのプロトコルはSOAPと呼ばれ、XML形式で、データやAPIなどが指定されている。
WSDLなど複雑な標準形式になっているので、コーディングがかなり面倒。

EDIとは 【Electronic Data Interchange】 - 意味/解説/説明/定義 ： IT用語辞典

EAIとは 〔エンタープライズアプリケーション統合〕 【Enterprise Application Integration】 - 意味/解説/説明/定義 ： IT用語辞典

SOAとは 〔サービス指向アーキテクチャ〕 【Service Oriented Architecture】 - 意味/解説/説明/定義 ： IT用語辞典

【3】EDI・EAI・SOAのような外部システム連携が必要な理由は、いくつかある。
一つは、ユーザ企業の全ての業務を一つのシステムで実現するのはコストも期間も難しいため、段階的にサブシステムごとに作っていかざるを得ないこと。
だから、普通のユーザ企業の業務システムは、たくさんのサブシステムが乱立していて、情報システム部門の人すら全てのシステムを把握できておらず、訳が分からない状況になっていることが多い。
当然、そこからシステムの障害が発生しやすくなる。

もう一つは、仕入先や取引先、銀行や電子マネーなど、既存の外部システムと連携したい要件が年々増えていること。
だが、外部の企業が自分たちの開発プロジェクトの都合に合わせてくれるとは限らないので、プロジェクト管理の部分の重要性がとても大きい。

例えば、商取引データの標準形式やAPI、プロトコルを早めに公開してくれるように突っついたり、接続テストを行う期間やテストデータの送受信のタイミングを事前に調整しなければならない。

しかし、接続テストをいざ実施してみると、想定外のデータで連携されて障害が起きたり、データ量が多いと性能が落ちたりタイムアウトしたり、提示された文書にあるAPIやプロトコルが間違っていたり、そもそも依頼した時間に送受信できなかったりする。

しかも、接続テストで発覚した障害の原因調査は再現性がなくて難しかったりする。
あるいは、障害の原因が外部企業が持つ外部システムのプログラムにバグがあると分かっても、外部企業が納期までに直してくれなければ、接続テストが完了しないまま本番リリースせざるを得なくなる。
そうすれば、本番リリース後は、障害が多発して、ユーザの業務に支障が出るだけでなく、開発メンバーもその対応に追われて疲労してしまうだろう。

そんな細かな障害は接続テストを実施しなければ判明しないので、経験のあるプロマネは、外部接続テストを早めに実施できるようにスケジュールを組んだり、有能なメンバーを配置したりして、可能な対策は取っておく。
そんなプロマネは、外部接続テストが開発プロジェクトのボトルネックであることを知っているのだ。

つまり、アーキテクチャ設計の弱さをプロジェクトマネジメントでカバーするパターンが現実ではとても多いと思う。

【4】外部システム連携は、まさにITアーキテクトと言う役割の人が、システム全体の観点で、実装レベルよりもユーザ観点のレベルで設計スべきもの。
自前で作るよりも、外部システムを連携して、本来の業務の要件を実現できるように設計する。
その外部システム連携の手法としては、EDI・EAI・SOAなどいろんな手法があるので、コストや納期の観点も入れて、取捨選択する。

でも、外部システム連携のアーキテクチャ設計のノウハウはバラバラに存在していて、パターン化されていない。
しかも、英語3文字の略語が氾濫しているために、何が重要なのかも把握しにくい。
そして、年々増えていくサブシステムを更に連携するために、たくさんのEDIやSOAが作られて、どんどん複雑化していく。
そんな開発作業が、ユーザ企業の本来の価値になっているのか、という評価も忘れたまま進んでいく。

アーキテクトという言葉が広まり、アーキテクトの役割の重要性が知られているにも関わらず、そのアンバランスな事実が業務システム開発の難しさを助長しているように思う。