Mark’s MIC:オープンAPIを効率よく実現する世界標準、Swagger(OAS3) の導入を

こんにちは、マネーツリーのマークです。多くの銀行がフィンテックなどと共に銀行APIの仕様に関する話し合いを続けています。銀行のオープンAPIをより適切に、より早く実現するにはどうしたら良いのでしょうか。また、一度公開したAPIを効率的にアップデートしていくにはどうしたら良いのでしょうか。実はどちらの課題も、金融業界以外では一般的な、ある技術を用いることで解決できるんです。

銀行APIの導入のカギは、技術仕様評価のスピード化

オープンAPIの実装にあたっては、APIの技術仕様の評価に多くの時間が費やされていますが、銀行にとっても電代業にとっても、お客さまに正しい情報をお見せするというのは最重要項目であり、この評価は慎重におこなう必要があります。しかしAPI基盤と銀行の勘定系をつなぐプログラムの仕様や、勘定系そのものの仕様は銀行によって全く異なり、非常に複雑な仕組みになっているため、読み解くのに多大な労力と時間を要してしまうのです。

銀行APIの導入を期限内に実現できるかどうかは、この作業をどれだけ効率化できるかにかかっていると言っても過言ではないでしょう。

アップデートのしやすさも重要なファクター

また、銀行APIをリリースした後、アップデートのしやすさも考慮せねばなりません。アップデートの際には、新旧の仕様書を確認しながらテストをおこなうのですが、その効率化も同じくらい重要です。

マネーツリーでは銀行APIのアップデートをご依頼いただく機会も増えてきています。現在、銀行APIの仕様書はExcelファイルで作成されているケースがほとんどで、しかもそのフォーマットは新旧で全く異なる場合が多いんです。そのため、ある仕様を変更する際には、膨大な数のExcelファイルの中から該当するファイルを探し出し、更にその内容をチェックし、変更点を見つけ出さねばなりません。一つのアップデートをおこなうのに、実に数時間もかけて間違い探しをする必要があります。

加えて大きな問題になるのが、このExcelファイルの仕様書のやり取りでは、ヒューマンエラーが発生する可能性が大いにあるということです。これは正確性を重視する金融機関にとって致命傷となります。

今後オープンAPIを実現し、その後も安定したアップデートを続けるためには、いかに銀行APIの技術仕様にかかわる作業を効率よく・正確におこなえるかがカギとなります。そこで我々が勧めたいのが、Swagger (現: Open API Spec 3.0) というAPIを記述するフレームワーク(ひな形仕様) です。

他業界のAPIでは、世界標準。Swaggerとは

APIをどのように定義するか、という課題を解決すべく、10年ほど前に登場したのがSwagger (OAS3) です。その利便性は、ここには書ききれないほど。Swagger (OAS3) による仕様の記述方法はネット上できちんと定義されており、正しく記述できているかどうかをチェックするツールまで公開されています。フォーマットが決まっているため、誰が記述しても、誰もが正確に読み解くことができるのです。

また、ツールを使えば、非エンジニアの人でも読みやすい仕様書の形式にも簡単に変換できるので、仕様書のバージョン管理も容易です。しかもSwagger(OAS3) はとても簡単に記述できるので、プログラミング経験がない人でもすぐに使いこなすことができます。実際、マネーツリーでは要件定義の際にプロジェクトマネージャーやビジネスアナリストといった非テクノロジー職種の人にSwagger(OAS3) を記述してもらいました。書いた仕様書をそのまま開発チームに渡せるため、非常にスムーズです。

このように、Swagger(OAS3) を使えばAPIの技術仕様に関するやり取りを効率よく・正確におこなうことができます。これらのメリットから、Swagger(OAS3) はAPIの仕様を記述するフォーマットとして世界標準になりつつあり、他業界では当たり前で、幅広く使われている技術です。2017年にはSwagger 3.0改めOpen API Spec 3.0（OAS3）という、そのものずばりの名称でアップデートがなされました。今後銀行APIを展開するにあたっても、Swagger(OAS3) は必要不可欠だと感じています。

実際、オーストラリアの金融業界ではそのあたりがかなり進んでいます。技術仕様は政府認定のフォーマットに標準化されており、バージョン管理ツール(GitHubなど) 上で公のフィードバックを集めながらバージョン管理をおこなっています。オーストラリアを始め、フィンテックの先進国であるイギリスなどでもSwagger (OAS3) は国際標準化されたツールとして認知されています。

銀行・ベンダーも認めるSwaggerの利便性

最後に、ある銀行とのプロジェクトの実例を紹介します。その銀行とはAPIの仕様についてディスカッションを何度か重ねており、毎回Excelファイルの仕様書を使っていました。先に述べたように、Excelファイルでの変更確認には非常に労力がかかります。Swagger(OAS3) を使った開発も持ち掛けたのですが、Swagger(OAS3) の存在すら知られていないような状況で、従来通りのExcelファイルをもとにしたやり方を変えるのは無理だと言われてしまいました。

そこで、マネーツリー側でSwagger(OAS3) ファイルと、Swagger(OAS3) ファイルから変換された仕様書を用意し、変更があるたびにアップデートして提出し続けました。はじめのうちは「無理です」と突っぱねられてしまいましたが、何度かやり取り続けるうち、先方がSwagger(OAS3) ファイルに編集を加えて返送してきてくれました。「Swagger(OAS3) の方がよっぽど効率がいい」と、銀行もベンダーも含め、先方の関係者が理解してくれたんです。

その後は完全にSwagger(OAS3) での開発を続けています。マネーツリーがGitで変更を管理しており、変更点はGitを使って簡単に確認することができます。変更があった点だけをPDF化して返送し、確認してもらう、というプロセスをとっています。

簡単・便利なSwagger(OAS3) を試してみませんか

‍

このように、Swagger(OAS3) を使えば仕様書を簡単に管理しながら銀行APIの開発を進めることができます。もちろん、以前から使っていた仕様書のフォーマットに沿って開発を続ける安心感もあります。しかしその一方で、独自のフォーマットを使い続けることで、他社とのコミュニケーションに無駄が生じ、実装にかかる時間やヒューマンエラーが起こる可能性を増してしまいます。参照系APIですらそうなのですから、更新系APIとなればなおさらです。そこで我々としては、まずはSwagger(OAS3) を試しに導入してみることをお勧めします。従来の仕様書とSwagger(OAS3) を並行して運用してみれば、その効率の良さをすぐに実感できることと思います。

Swagger(OAS3) を使えば、銀行APIをより適切に早く実現し、更にアップデートも効率的におこなうことができます。Swagger(OAS3) はとても簡単に使いこなすことができます。まずは気楽な気持ちでSwagger(OAS3) を導入してみて頂きたいです。

‍

Swagger (OAS3) に興味がある方は以下のアンケートにご記入ください。