システム連携 = 組織間・担当者間の連携

私はメインで扱っているシステムの性質上、他のシステムとの連携を行うことが多く、対向システムの管理者と関わることが多いです。その際、システム間の連携の成否は、組織同士・担当者同士の連携の成否がそのまま反映されると思っています。

システム連携 = 組織間・担当者間の連携

異なるシステムでは、アーキテクチャや思想が異なることが多いため、システム連携を構築する際には、まずはお互いがお互いのシステムのことを理解する必要があります。その際に重要なのが、当然ですが、コミュニケーションです。対向システムの仕様を調べれば概要はわかりますが、実際の環境構成や、利用ポリシーなどはその企業・組織によって異なるため、コミュニケーションは必須です。

組織・担当者がお互いに協力的で、コミュニケーションがうまくいっているときは、システム間の連携もスムーズにいきますし、問題もすぐに解決できます。しかし、一方が自分のシステムの都合ばかりを押し付けていると、中々進みません。

最近、一方が日本人で、他方が海外の担当者という場合にシステム連携がうまくいっていないケースを横目に見ました。互いに悪気はなかったようなのですが、言語の壁によって日本側が無意識にコミュニケーションを避けており、中々認識が合わずコミュニケーションに時間がかかっているのに直接話さずチャットでのやり取りに固執し結果、自然とシステム同士も連携したがらないかのように時間がかかり、当初の納期から大幅に遅れていました。

コンウェイの法則

これは、コンウェイの法則の一種と言ってもよいかもしれません。アーキテクチャは組織と同じ形になるというものです。

Any organization that designs a system (defined broadly) will produce a design whose structure is a copy of the organization's communication structure.
------引用者訳------
（広義の意味での）システムをデザインする組織は、その組織のコミュニケーション構造と同じ構造のデザインを生み出すことになる。

CONWAY'S LAW　http://www.melconway.com/Home/Conways_Law.html

ちなみに、コンウェイの法則について改めて調べたところ、論文誌や書籍として発表されたものではなく、コンウェイさんが自身のサイトで投稿した下記の記事がソースになっているようです。個人サイトの1ポストですが、多くの人が納得する経験則として、今なお語り継がれています。

（補足）上述のポストには、ハーバードビジネスレビューに提出したけどRejectされたと少し不満げに書かれていました 笑

そして、この法則はシステム間連携にも拡張できるのではないか、ということです。

経験則を生かす

プロジェクト/プロダクトマネジメントにおけるリスクの置き場所

プロジェクト/プロダクトマネジメントにおいて、システム間連携はリスクのある個所として認識されることが多いですが、その多くは技術的な部分に次いです。

しかし、上述の経験則から、コミュニケーションに関するリスクを考慮することが重要だと考えます。そのため、例えば部下に任せる際は、担当者間のコミュニケーションの様子を定期的にチェックしておくと、遅延等のリスクを早期に防ぐことができそうです。

逆コンウェイ作戦

『エンジニアリング組織論への招待』によると、コンウェイの法則を逆手にに取って、積極的な組織設計やコミュニケーション設計をビジネス戦略に基づいて行うことで、システムのアーキテクチャをよりよいもの・戦略に沿ったものに変えていこうとする考え方があり、これを「逆コンウェイ作戦（INverse COnway Maneuver）と呼ぶそうです。

システム連携 = 組織間・担当者間の連携と考え、システムをよりよいものにするためには、意識的に互いの連携を深めるという戦略がとれるでしょう。

APIを解釈する

最後に、公開済みのAPIを用いる場合など、組織や担当者間でのコミュニケーションが発生しないシステム連携についても、考えてみたいと思います。

この場合、コミュニケーションという観点だと、サービス利用側が、サービス提供側が提供するAPI仕様（APIドキュメントなど）を一方的に見に行くというコミュニケーションの構造になっています。

システムの観点で見てみると、サービス利用側が、提供されたAPIを一方的にcallするという、コミュニケーションと同じ構造になっていることがわかります。

以上です。