ご覧になって頂いてる方、はじめまして。株式会社メディアフォースの小山と申します。EAIソリューション部に在籍しています。主にDataSpiderを活用したEAI、ETL関連のシステム提案、開発をしてます。
#EAIドリヴンって言いたいんです
このサイトをご覧になっている方はEAI界隈の方が多いかと思いますが、データ連携開発のスコープって狭いと感じている方は少なくないのではないでしょうか。因みに私もそう感じていた時期がありました。この領域で仕事をして10年程になりますが、開発規模（工数）は大小ありますが、規模の違いは連携本数の違いで、設計要素としてはシステム間の連携方式（プロトコルやアーキテクチャ設計）、運用設計、項目間のマッピング設計のみということが多く、システム全体の中では狭い領域のイメージを持っていました。
ですが最近は、業務要件を定義するところからEAIチームとして参画することも増え、考え方が変わってきました。
ゼロベースからEAIをシステムへ適用しようとすると、業務フローを作成して自動化やシステム間の連携ポイントを検討するところから始めます。観点は業務改善に繋がるかどうかとなり、システム全体がスコープになります。私がEAIというキーワードを初めて調べたときに定義されていた説明文は、「異なるシステム間を有機的に繋げ、システム全体を効率的に動作させて変化するビジネスへの対応速度を上げる」というものでした。この内容に繋がるところであり、EAIを構築するチームはシステム全体を最適化をリードする存在になり、まさにEAIドリヴンのシステム開発が始まるのです。

#何から始めるべきか
１．EAIの概念を広める
プロジェクトチーム内で「EAIチーム」というものの存在を知ってもらうようにします。
プロジェクト内で「EAI」という単語が使用されていない場合は、設計書に「EAI」と積極的に書いていきます。打ち合わせでも「連携サーバ」とか「XXXX（システム愛称）」で呼ばれていても「EAI」とあえて呼んで、相手に単語を知ってもらいます。
聞いている相手が知らないようであれば、それとなく説明します。「EAI、つまりデータ連携基盤で…」
開発当初に定着しなくても、大丈夫です。結合試験期間に入ると、多くのチームがEAIチームへ質問に来ます。（結合試験時のインシデント解析はEAIチーム起点になることが多いのです）この期間に定着します。

２．プロジェクト内の全チームの役割を把握する
マルチベンダーのプロジェクトの場合は領域ごとに縦割りの体制になりやすく、領域間でどちらとも言えないような仕様の検討漏れが発生する事があります。その場合、結合試験でEAIチームで検知され、一旦、EAIチームの責任になったりするのですが、EAIドリヴンのシステム開発としてはこの断崖の仕様漏れを無くす為に、チーム間のスコープを明確にしておき各システムの外部仕様の整合性をチェックする必要があります。もはやシステムアーキテクトの仕事ですが、EAIドリヴンのシステム開発においてはそういうものです。

３．プロジェクト内のチーム間の情報伝達ルールを作成し、認識をあわせる
EAIチームがIF仕様を理解していくプロセスにおいて、IF仕様が複雑（項目間の紐付けが名称では理解不能な場合など）ではない場合は、個別にチャットツールやQ&A表のみで完結することが多いと思いますが、前述のように領域ごとにチームが縦割りになっている且つ、IF仕様が複雑だと連携仕様を決めるのが困難になります。

【失敗パターン】
（連携先）レイアウト仕様が出る　⇒　（EAIチーム）連携元に連絡　⇒　（連携元）項目の意味をEAIチームに問合せ　⇒　（EAIチーム）連携先に確認　⇒ ...繰り返す中でEAIチームが伝達漏れやミスが発生すると、全員にとって不幸なことになります。

【改善パターン】
（前提）EAIチームがマッピング仕様決定プロセスをパート図などで定義し、連携先と連携元間で決定プロセスの合意をする
(連携元)レイアウト仕様書が出る　⇒　（連携元と連携先）語彙の共有をし概念レベルでマッピング　⇒　（EAI）概念レベルのマッピングについて連携先へ不明点を確認

他にも色々あるかとは思いますが、とにかくコミュニケーションにおけるマネージメント力がEAIの生産性を大きく上げる要因になると感じています。

最後に

今回の投稿を見たEAIエンジニアが「伸びしろですね」と感じていただければ嬉しく思います。