前回は、APIを通じてシステム連携を強化することのメリットや事例を紹介しました。第4回目となる今回は、APIを利用してプログラムを開発、運用したり、開発者へ依頼したりする場合の勘所となる部分を紹介します。特に、プログラム開発自体ではなく、保守や運用までを考慮して説明します。
プログラム開発と保守運用
前回は、「Okta」や「OneLogin」などのIDaaS（Identity as a Service）と呼ばれるようなサービスの利用例を紹介しました。人事システムと連携し、「Dropbox」アカウントを入社時に配布する、退職時に削除するといった手続きを自動化するような連携が代表的です。
このような連携も場合によってはIDaaSの機能だけでは実現できず、プログラム開発を組み合わせるケースがあります。
たとえば、入社した社員のセキュリティー教育やガイドラインへの同意取得を終えてからDropboxアカウントを配布したい、といった要件があるとします。要件定義を終えて、設計段階では次のような4ステップの手続きを検討するとします。
- ステップ1：人事システムから新入社員の情報を取得
- ステップ2：セキュリティー教育のためにeラーニングシステムと連携
- ステップ3：ガイドラインへの同意管理のために電子署名サービスと連携
- ステップ4：Dropboxと連携してDropboxアカウント作成
APIで連携できる場合、CSV形式ファイルを利用してバッチ処理としての連携が必要な場合など、システムによってさまざまなパターンがあります。プログラム開発の一般的な確認事項ですが、これらの連携にどのような制約事項があるか、処理にそれぞれどの程度かかるかなどの確認が必要です。企業規模や業種業態による要件の複雑性にも依存します。社員数1000人規模で入社処理は一度に数十人程度のため処理時間は問題とならない場合もあれば、社員数が数万人で処理時間が重要な課題となる場合もあります。
ここまでは一般的なプログラム開発での課題ですが、特にクラウドのAPIを利用する場合での考慮事項があります。それは、APIが利用できるサポート期限です。
クラウドサービスは日々新しく機能開発されており、一部の機能が新機能に置き換えられ、仕様変更が発生する場合があります。APIの仕様変更があれば構築したプログラムの修正が必要かの確認が必要です。場合によってはプログラムの改修、プログラムではなく利用するワークフローの変更などが必要な場合もあります。
クラウドサービス事業者に対する延長保守契約などでAPI仕様変更を延期できる場合もあります。しかし、クラウドサービス側の仕様変更自体の中止は、クラウドサービス事業者の経済性観点から一般に難しいと考えられます。プログラムを自社開発、または製品を購入して自社運用している場合と大きく異なる点です。
このように、プログラム開発は一度開発して終わりではなく、クラウドサービス側の仕様変更といった外的要因も考慮しながらの継続的な保守運用が求められます。「Development (開発)」と「Operations (運用、保守)」を統合した「DevOps」という言葉で表されるような考え方が昨今提唱されているのは、こういった背景が一因となっています。
開発業務を委託する受託開発の場合では、従来のシステム不具合の修正のような小規模な保守契約だけでなく、一定割合で発生するAPI仕様変更などの外的要因に対する対応も含めた委託を検討する必要があります。
