CData Japan の疋田です。
先日、パートナーイベントの懇親会で「Web API の連携部分は技術負債になる運命。それに気づかずに自社実装している会社が多すぎる」という話が出たので、その点をまとめてみました。
Web API 連携は必然的に不安定：
結果として、将来にメンテナンス費用が発生する負債的性格を持ってしまいます。連携部分を独自実装する前に将来のメンテナンス費用を勘案し、CData Drivers で連携部分を標準インターフェースに統一することで、負債をヘッジしませんか？
API は変化のスピードが速い
従来のDB のバージョンアップやテクノロジープラットフォームの変化のスピードが数年に一度であったとすれば、SaaS のアップデートスピードは年に数回です。
業務で利用されるWeb API はクラウドサービス（SaaS）をベースにしたものが多いです。Salesforce、G Suite、kintone などをイメージしてください。そもそもSaaS のメリットの一つに、サービス提供者側が速いペースで機能追加を行い、すぐに本番サービスに機能追加を適用できる点があります。Salesforce では1年に3回の大幅なアップデート、Google Analytics などは3カ月に1回といった頻繁なアップデートがあります。また機能追加だけでなく、ある機能がサービスされなくなることもあります。SaaS は、多くのプレーヤーが競合しているため、機能追加やよりAPI を使いやすくする不断の努力をして競争力を維持向上しています。
当然SaaS の機能変化に伴いWeb API も仕様が変化します。機能追加、機能削除、そしてAPI 自体を丸々変更する場合（SOAP→REST、REST→GraphSQLなどは最たる例）もあります。
たしかにFacebook やTwitter で「しらないボタンが出てきた！」と気づくことがあります。これはユーザーが目で見てボタンを押している分には大きな問題ではありませんが、API 連携となると変更に追従するためには既存連携部分の改修や新規機能の追加という開発リソースを使う問題になります。
RESTはプロトコルではない
REST もしくは、RESTfull と言われるAPI についての大きな誤解は、それが実装規約が統一されたプロトコルのごとくに語られていることです。
こちらのブログ記事にあるよう、REST は単なるアーキテクチャスタイルです。
言ってしまえば、「REST API と呼ばれるAPI 群は、REST というアーキテクチャスタイルを参考にした、まったく独自のプロトコルのインターフェース群」です。各社・各API で自由にプロトコルを作っているという状況です。プロトコルとして統一しようとしたOData 規格やOpen API Initiative という流れもありますが、標準化にはまだまだ遠いと感じます。
それらが独自プロトコルであるため、メタデータの扱い、データモデル、フィルタリングやソート、ページングなどの実装方法がすべて異なります。Web API 連携の実装ポイントについては、別記事にて説明してますので、是非ご覧ください。 www.cdatablog.jp
API 連携部分を自社で実装するエンジニアは統一ルールがないAPI をそれぞれの解釈で自社のアプリケーションに統合します。自社アプリケーションはリレーショナルなデータの扱いをするものがほとんどですので、エンジニアは独自REST →リレーショナルモデルの変換をそれぞれ独自の方法で行っていることになります。よほどWeb API 実装をルール化しない限り、実装を行ったエンジニアの意向に重度に依存した連携コードができてしまいます。
結論：Web API 連携の独自実装は負債
変化が速い＝改修頻度が高い。
実装したエンジニアの意向に依存＝改修時に別のエンジニアが作業をする場合の開発コスト高い
→Web API 連携の独自実装は、発生頻度が高く対応コストが高い資産となります。コストを生む資産ということは、負債というべきでしょう。
多くの場合には、API 連携部分の実装時には実装コストだけが注目され、メンテナンスに多くのコストがかかることは意識されていないと思われます。
技術負債とは
会計用語で、「負債とは、将来的に他の経済主体に対して、金銭などの経済的資源を引き渡す義務のこと」と定義されています。簡単に言うと、将来お金が出て行ってしまうことが決まっているモノのことです。借金をイメージしてもらえれば理解が簡単です。
ソフトウェアの世界には「技術的負債」と呼ばれるものがあります。1992年にカニンガム氏が技術的な債務との比較を報告したことがこの用語のはじまりで、「最初のコードを出荷することは、借金をしに行くのと同じである。小さな負債は、代価を得て即座に書き直す機会を得るまでの開発を加速する。危険なのは、借金が返済されなかった場合である。品質の良くないコードを使い続けることは、借金の利息としてとらえることができる。技術部門は、欠陥のある実装や、不完全なオブジェクト指向などによる借金を目の前にして、立ち尽くす羽目になる。」
通常技術負債は、バグを含むコードや不味いアーキテクチャの文脈で語られますが、Web API 連携部分も将来の定期的な改修が必須で開発コストがかかるという点では負債的性格をもっています。
こんなケースは負債が膨らみがち
連携を実装しているWeb API が1種類で、自社の複数のエンジニアが連携部分を理解しているケースであれば、API 連携部分のメンテナンス費用は限定的です。
以下の場合には、Web API 連携部分の負債額は大きいです：
複数のWeb API 連携を実装している
1つのWeb API でも複数のエンドポイントの連携を実装している
データドリブンな実装（イベント的な実装の方が単純）
連携部分の実装は外注
連携部分を実装したエンジニアが退職した
連携数が多ければ負債金額は大きいです。特にBI、帳票、DWH、ETL、ワークフローといった多くの連携先を求められる製品・サービスの場合には、普通にAPI 連携数が30 を超え、連携部分の負債が億円単にになっていてもおかしくありません。
また、当初実装したエンジニアの意向が強く反映されているため、当人がいなくなると改修にかかる費用は圧倒的に大きくなります。「うーん、何やったんだろう？ いいや、わからないから連携部分書き直そう！」というスクラッチ改修もよく起こっていると聞きます。
サードパーティ製品の利用による負債のヘッジを！
将来に負債が発生する可能性が高い場合には、そのリスクをヘッジするのが経営の定石です。CData Drivers の利用でヘッジを検討してください。
CData Software では、100を超えるSaaS / NoSQL をODBC やJDBC といったリレーショナルなインターフェースに標準化するデータドライバー製品を開発・提供しています。 https://www.cdata.com/jp/products/#drivers
ドライバー製品を利用することで、BI、帳票、DWH、ETL といったツールからシームレスにSaaS/NoSQL データ連携が可能になります。カスタムアプリケーションからは、Web API をリレーショナルなDB にモデル化した状態で扱うことができます。
当初の実装が数分の1 の工数でできるという効果に加え、「API の変更に追従するメンテナンス費用が圧倒的に下がる」というメリットがあります。
CData では、データソースであるSaaS などのAPI 変更に対して絶えずモニタリングをし、追従したドライバーを提供しています。これにより、大概のAPI 変更はドライバー内で吸収されます。大幅な変更や新機能追加であっても、CData Drivers がODBC やJDBC という標準技術でモデル化されているため、連携しているアプリケーションの改修が当初実装のエンジニアの意向に左右されることがありません。
このような背景から、CData Drivers は、WingArc、ASTERIA などデータ活用の最先端の企業にOEM として採用されています。
Web API 連携は、実装時に将来のメンテナンスコストも含めた検討をお勧めします。 OEM についてはこちらをご参照ください：
