APIファーストアプローチのソフトウェア開発、成功の秘訣：先人の失敗に学ぶ

開発する機能を再利用可能なAPIとして実装することにより、ソフトウェア開発の生産性が向上する。だがAPI化すればいいというものでもない。APIファーストのメリットとともに再利用性を高める方法を紹介する。

[Cliff Saran，Computer Weekly]

　APIは、プログラム的な結び付きを使って他のコードにアクセスできるようにする仕組みだ。これを利用するとソフトウェア開発に要する時間が根本的に短縮する。

　「既にあるものを作るな」という理念がある。機能やアルゴリズムが既にコードになっていて、それにアクセスできるAPIがあるのなら、似たものを一からコーディングするのではなくそのAPIを使うべきだという考え方だ。

　専門家は、ソフトウェア開発にAPIファーストのアプローチを取ればソフトウェア開発の作業を洗練できると言う。そのためには、利用できるAPIを公開し、ある程度のガバナンスを提供するポータルが必要になる。

　AstraZenecaでAPIと統合部門のディレクターを務めるサティシュ・マラム氏は、「基本的に、APIは1回構築して複数回使うことを可能にする」と話す。同氏によると、再利用可能なAPIが適した例は、2つのシステムを統合する必要があり、その統合が複数の場所で使われるケースだという。

　こうした再利用は、英労働年金省（DWP）のIT戦略にとって不可欠になりつつある。DWPで統合部門の責任者を務めるジャッキー・リゲッター氏は次のように話す。「再利用を目的にサービスを構築することが当部門の戦略的目標だ」

　英ロンドンで開催された「MuleSoft CONNECT 2019」（2019年10月）のパネルディスカッションで、リゲッター氏とマラム氏、そしてフェローパネリストのベン・ターナー氏が、APIのメリットと再利用性を踏まえてAPIを構築するためのベストプラクティスについて語った。ベン・ターナー氏は損害保険会社Legal & GeneralのCTO（最高技術責任者）を務めている。

　パネリストらは、APIの概念は企業にとってしばしば捉えにくいものになることに同意する。むしろAPIがどのようなビジネスサービスを実現するかについての議論が必要だとして、ターナー氏は次のように語る。「APIを話題にするのではなく、企業が利用したいサービスを話題にし、それを表す日常のシナリオを見つけることを試みる」

　リゲッター氏によるとDWPは、APIの使用を開始した最初の年にAPIの命名法を工夫し始めたという。以前のAPI名は番号だった。「チームはAPIを番号で呼ぶことをやめた。API名は全て動詞から始めるというルールにした」と同氏は語り、これによってAPIへの考え方が変わったという。

関連記事

• APIは万能ではない――APIではなくRPAを使うべき理由
• 専門家が語る、REST APIオンリーの限界とGraphQLを使うべき理由

特別編集ブックレット

• 自動化を導入しても業務が効率化しない理由

ビジネスの変化

　ビジネス全体で利用できる新しいAPIを開発するプログラムに着手するには、IT部門と事業部門の連携に対する考え方を改めなければならない。アプリケーション開発チームは、特定の業務機能向けにソフトウェアを作成することには慣れているかもしれない。だがAPIファーストのアプローチでは、構築するコードの再利用法をチームで考える必要がある。

　2016年以前、Legal & Generalのソフトウェアプロジェクトはポイントツーポイント接続を利用していたとターナー氏は話す。「いったん構築すれば終わりという考え方だった。事業部門とIT部門はこの姿勢を改め、その考え方をやめる必要があった」

　リゲッター氏は、DWPがひらめきを得た瞬間はスコットランド政府向けのプロジェクトに着手したときだったと語った。そのプロジェクトは英国歳入関税局（HMRC）向けに以前開発したマイクロサービスと多くの類似点があった。「HMRC向けに構築したサービスは再利用できなかった。1つのAPIで5つのことを実行していたためだ」

　開発したマイクロサービスの粒度がもう少し細かければ再利用しやすかったのではないかとチームは考えた。次のプロジェクトはHMRCのマイクロサービスと類似点があるため、チームはより粒度が細かいAPIを開発することにした。「このプロジェクトでは、マイクロサービスを個別のAPIに分けた」（リゲッター氏）

　パネリストは、APIファーストのアプローチを用いてからチームが生産性のメリットを感じ始めたと語った。AstraZenecaのマラム氏によると、チームがAPIファーストのアプローチで構築した最初のプロジェクトでは、従来のポイントツーポイントの統合よりも実際に作業量が減ったが、APIの真の価値は2つ目のプロジェクトで現れたという。「2つ目のプロジェクトでは、再利用可能な（ソフトウェアの）ブロックを組み立てた。そのため、新規開発が必要だったのはプロジェクト全体のほぼ半分程度だった」と同氏は話す。

　農業や環境関連の製品メーカーYara Internationalは、APIの導入に着手した企業の一例だ。同社は、IT部門と事業部門の距離を近づけてソフトウェアを迅速に開発するという広大な構想の一環として、MuleSoftのAPI管理ソフトウェア「Anypoint Platform」を使い始めた。

　Yara InternationalでAPIと統合部門の責任者を務めるパトリック・デ・ザラツィン氏は、API管理の使用動機を説明した。「当社には、プロジェクトについて話し合い、その後1年にわたって計画を進める余裕などない。構想があるときは、誰かが既にそれに取り組んでいる可能性について考えることにしている」

　3年前、Yara InternationalにIT変革が起きた。これによりIT部門と事業部門の距離が近づき「Yara APIエコノミー」という構想が始まった。デ・ザラツィン氏は次のように説明する。「統合にシフトレフト（訳注：プロセスを前倒しで実施すること）という理念を求めた。プログラマーが、より多くのことを系統立って行えるようにしたかった」

　このアプローチにより、同氏が「バイモーダルモデル」と呼ぶものをプログラマーが扱えるようになったという。この「シフトレフト」アプローチにより、プログラマーが独自の方法で問題を解決し、誰もがメリットを得られる方法で考え方を公開することが可能になる。

　ソフトウェア開発者は、公開済みAPIを通じて再利用可能なコードを記述するメリットを理解するのに苦労しているとMuleSoftの創設者であるロス・メイソン氏は考えている。同氏の経験によると、開発者は自身が構築するソフトウェアと、企業が求める結果を結び付けることに難しさを感じているという。

　「開発者は価値についてあまり考えていない。つまり、設計の対象外である無用のITプロジェクトを提供したり、組織内の1つ以上の構成要素に価値を加えるITプロジェクトを提供したりすることは考えていない。当社は、構築するソフトウェアが提供する価値について開発者が考えるようサポートしなければならない」（メイソン氏）

　メイソン氏の他、本誌が話を聞いた人々は多くの点で、IT部門が単にビジネスニーズを提供することから離れる必要性を説いていた。むしろ、ソフトウェア開発者は、公開済みAPIによって何度も再利用可能なサービスを提供しなければならない。それによって、企業が新しいデジタル製品をこれまで以上に迅速に市場投入することが可能になる。