上流の担当者が押さえたい、システム連携方式の選び方

システム連携の方式は、基盤やアーキテクチャの担当者が決めるもの、と思われがちです。ただ実際には、要件定義の段階で発注者と話しておかないと決められないことが多くあります。データはどのくらいの間隔で届けばよいのか。止まったときに業務はどうなるのか。そのデータの正しさに誰が責任を持つのか。これらは技術ではなく、業務の条件です。

上流の担当者が連携方式の議論に入るとき、求められるのは製品や技術の細かい比較ではありません。業務側の言葉で条件を引き出し、それを方式の選択につなげる役割です。この記事では、ファイル連携、API、メッセージング、データベース連携という代表的な方式を、発注者と話すときの判断軸で整理します。

連携方式の話は、業務の条件から始める

連携方式の打ち合わせで、最初から「APIにしましょう」「今まで通りファイルで」と方式の話を始めると、議論が技術の好みのぶつけ合いになりがちです。新しい方式を推す人と、慣れた方式を守りたい人がいて、どちらも業務上の理由を説明できないまま時間が過ぎます。

方式は、業務の条件が決まれば、ある程度は自然に絞れます。たとえば、受注データが夜間にまとめて届けば十分な業務と、受注した瞬間に在庫を引き当てないと困る業務とでは、選ぶ方式が違って当然です。逆に言えば、条件を決めないまま方式を選ぶと、後から「思っていたより遅い」「止まったときの手当てがない」という問題が出てきます。

そこで、発注者と話すときは、方式の名前を出す前に条件を確かめます。この記事では、その条件を四つの軸に分けて考えます。頻度、即時性、障害時の扱い、そして所有者です。

代表的な4つの方式と、その性格

判断軸の話に入る前に、それぞれの方式の性格を簡単に押さえておきます。多くの方がご存じの内容だと思いますので、発注者に説明するときの言い方を意識して書きます。

ファイル連携

送る側がデータをファイルに書き出し、受ける側がそれを取り込む方式です。一度にまとまった量を渡せ、仕組みが分かりやすく、今も多くの基幹システムで使われています。一方、ファイルが作られるタイミングに合わせて処理するため、即時性は低くなります。発注者には「決まった時刻に、まとめて渡す方式」と説明すると伝わりやすいです。

API連携

受ける側が用意した窓口に、必要なときに問い合わせや登録をする方式です。一件ずつ、すぐに結果を返せるのが強みです。その代わり、相手のシステムが止まっていると処理できません。呼び出す側が、相手の都合に引きずられる関係になります。発注者には「その場で相手に聞きに行く方式」と言い換えられます。

メッセージング

送る側がメッセージを中継の仕組みに置き、受ける側が自分の都合で取り出す方式です。送る側と受ける側が同時に動いている必要がないため、片方が止まってもデータが失われにくくなります。ただ、仕組みが一つ増えるぶん、運用と監視の対象も増えます。「郵便受けに入れておき、相手が取りに来る方式」と説明すると、イメージを持ってもらいやすいです。

データベース連携

相手のデータベースを直接読んだり、共有のテーブルに書いたりする方式です。作るのは手早く、大量のデータも扱えます。ただし、相手のテーブル構造に依存するため、相手が構造を変えると連携が壊れます。現状調査で、正式な連携一覧に載っていない連携として見つかるのは、この方式であることが多いです。

実際のシステムでは、これらを組み合わせて使うことがほとんどです。一つの方式ですべての連携をそろえる必要はありません。むしろ、連携ごとに条件を見て、方式を使い分けることが前提になります。

頻度と即時性 ― 「すぐに」はどれくらいすぐか

頻度は、どのくらいの間隔でデータを渡すか。即時性は、データが発生してから相手に届くまで、どこまで待てるかです。似ていますが、分けて聞くと条件がはっきりします。

発注者に「このデータはリアルタイムで必要ですか」と聞くと、多くの場合「はい」と返ってきます。遅いよりは速いほうがよいので、当然の答えです。しかしそれでは方式を決める材料になりません。代わりに、業務の場面で聞きます。「営業担当が受注を登録したあと、倉庫で出荷指示を見るのはいつですか」「その間に何分、何時間あれば困りませんか」。こう聞くと、実は翌朝に届けば十分だった、という答えが出ることもあります。逆に、在庫の引き当てのように、わずかな遅れで二重に引き当ててしまう業務も見えてきます。

即時性の要求が高いほど、APIやメッセージングが候補になります。反対に、一日一回で足りる業務に即時の連携を入れると、作る費用も運用の手間も増えるだけで、業務上の得はありません。同じシステム間でも、データの種類ごとに条件が違うことは普通にあります。マスタは夜間にファイルで、受注は都度APIで、という組み合わせは珍しくありません。

頻度とあわせて、一回に渡すデータの量も確かめます。一日に数件しか発生しないデータと、まとまった件数が一度に発生するデータとでは、同じ「一日一回」でも向く方式が違います。件数が多いものを一件ずつAPIで送ると、相手のシステムに負荷がかかり、時間内に処理が終わらないこともあります。発注者には「一番多い日に、何件くらい発生しますか」と、ピークの日を基準に聞いておくと、後で性能の議論になったときに困りません。

気をつけたいのは、今の運用に引っ張られることです。「今は夜間バッチだから、新しい仕組みも夜間で」と決めると、本当は日中に欲しかったデータの要求を拾い損ねます。逆に「新しくするのだから全部リアルタイムに」も、費用に見合わない設計になりがちです。業務の場面に戻って確かめる姿勢が、どちらの偏りも防ぎます。

障害時の扱い ― 止まったとき、業務はどうなるか

連携方式の選び方で、発注者と一番話しておきたいのが、止まったときの扱いです。どの方式でも、相手のシステムやネットワークはどこかで必ず止まります。そのときに業務をどう続けるかで、選ぶべき方式が変わります。

確かめたいのは、たとえば次のような点です。

• 連携が止まったとき、業務は待てるのか、別の手段で続けるのか
• 止まっている間のデータは、後から送り直せばよいのか、捨ててよいのか
• 同じデータが二度届いたら、受ける側で困るか
• 止まったことに、誰が、どうやって気づくか

たとえば、API連携で受注を登録する設計にしたとします。相手のシステムが保守で止まっている間、受注を受け付けられないのか、いったん手元にためて後から送るのか。後者なら、ためる仕組みと送り直す仕組みが要ります。そこまで含めて考えると、最初からメッセージングを選んだほうがよい、という判断になることがあります。

二重に届いたときの扱いも、業務の側で決めてもらう必要があります。送り直しの仕組みを作ると、同じデータが二回届く可能性はどうしても残ります。受ける側で重複を見分けられるように、データに一意の番号を持たせるのか、業務の確認で吸収するのか。技術だけでは決められない話です。

止まったことに誰が気づくか、という点も見落とされがちです。ファイルが届かなかったとき、受ける側のシステムはエラーを出さず、単に何もしないことがあります。そうなると、業務の担当者が「今日のデータが反映されていない」と気づくまで、誰も知らないままです。届かなかったことを検知して知らせる仕組みを、方式とセットで考えておきます。

ここで発注者に障害時の業務を決めてもらっておくと、運用設計の段階で揉めずに済みます。決めていないと、稼働後に初めて止まったとき、誰が何をすればよいのか分からない状態になります。

所有者 ― そのデータと窓口は、誰のものか

四つめの軸は、データと連携の窓口が誰のものか、という観点です。見落とされやすいのですが、長く使う連携ほど効いてきます。

データの所有者とは、そのデータの正しさに責任を持つ部署やシステムのことです。たとえば取引先マスタを、販売システムと会計システムの両方で更新できる状態だと、どちらが正しいのか分からなくなります。連携方式を決める前に、「このデータの正しい値は、どのシステムが持っているのか」を一つに決めておく必要があります。

窓口の所有者とは、連携の仕様を決め、変えるときに責任を持つ側です。APIなら、提供する側が仕様を持つのが普通です。ファイル連携でも、項目の並びや文字コードを誰が決めるのかを明確にしておかないと、片方の都合で変更が入り、もう片方が動かなくなります。データベース連携が後々問題になりやすいのは、この窓口の所有者がはっきりしないまま、相手の内部構造に依存してしまうからです。

たとえば、ある項目の桁数を増やしたい、という要望が出たとします。連携先が三つあれば、三つのシステムで改修とテストが要ります。窓口の所有者が決まっていれば、その部署が影響を受ける相手に知らせ、日程を調整する役を担えます。決まっていないと、変更したい側が一つずつ相手を探して頼み込むことになり、変更そのものが見送られがちです。

所有者の話は、組織の話でもあります。連携の両側が別の部署や別の会社だと、仕様の変更に予算と調整が要ります。たとえば、相手のシステムの更改に合わせて連携を作り直すことになったとき、その費用をどちらが持つのか。要件定義の段階で、連携ごとに「仕様を決める側」と「合わせる側」を書いておくだけでも、後の議論がずっと楽になります。

発注者との打ち合わせで使える問いの順番

四つの軸を、実際の打ち合わせでどう使うか。連携一本ずつについて、次の順番で聞いていくと、方式を選ぶ材料が自然にそろいます。

1. このデータは、どの業務で生まれ、どの業務で使われますか
2. 生まれてから使われるまで、どのくらい待てますか
3. 連携が止まったら、その業務はどうしますか
4. このデータの正しい値を持っているのは、どのシステムですか
5. 仕様を変えたいとき、誰に相談すればよいですか

方式の名前は、この問いに答えてもらったあとで出します。「待てるのは翌朝まで、止まったら翌日に送り直せばよい、ということなので、今まで通りファイルで十分だと考えます」。このように業務の言葉で理由を添えると、発注者も判断の根拠を社内で説明できます。

すべての連携に同じ時間をかける必要はありません。業務への影響が大きい連携と、件数が多い連携に絞って深く聞き、残りは一覧で条件を確かめる程度にしておくと、打ち合わせの回数を抑えられます。

打ち合わせの相手も選びます。頻度や即時性、障害時の業務は業務部門の担当者に、所有者や仕様の変更の窓口は情シスや相手システムの担当者に聞くのが近道です。同じ問いを全員に投げると、答えがばらついて、かえって整理に時間がかかります。

連携一覧を、決めたことの記録にするために

多くのプロジェクトで連携一覧は作られます。ただ、相手システム名と方式だけが並んだ一覧では、なぜその方式にしたのかが残りません。数年後に連携を見直すとき、当時の条件が分からず、また一から調べ直すことになります。

次に連携一覧を作るときは、方式の列の横に、頻度と待てる時間、止まったときの扱い、データと窓口の所有者を書く列を足してみてください。それぞれ一言で構いません。列を足すと、空欄が目立つはずです。その空欄が、まだ発注者と話していない論点です。方式が選ばれた理由が一覧の中で読めるようになり、発注者との合意の記録にもなります。上流の担当者がこの形を最初に用意しておくと、設計や運用の担当者にも判断の背景がそのまま伝わります。