SDK と API による ArcGIS の拡張
ArcGIS システムは通常、十分に理解されている既存のソフトウェア コンポーネントの安定した基盤の上に構築されます。 これらのコンポーネントは、さまざまな方法でデプロイし、ワークフローと要件をサポートするように構成できます。多くのシステムでは、既存のアプリケーション、サービス、ツール、機能のみで要件を満たすことができます。 要件や設計基準の関係で、ソフトウェアやワークフローのカスタマイズが必要になる場合もあります。ArcGIS プラットフォームには、これらの目標を達成するために役立つさまざまなソフトウェア開発キット (SDK)、スクリプトおよび自動化エンジン、アプリケーション開発インターフェイス (API) が用意されています。 Esri Developer サイトでは、これらの API と SDK の一部に関する包括的なドキュメントとガイダンス、および他の REST API と、基本的な ArcGIS コンポーネントの機能についてのドキュメントを閲覧できます。
一部のプロジェクトやチームは、ソフトウェア開発やカスタマイズの役割を明確にしたうえで設計プロセスを開始するのに対して、他の設計プロセスでは、要件のレビューや設計プロセスの後の手順を通じてカスタマイズの必要性を強調することもあります。 いずれの場合も、ArcGIS をどこでどのように拡張するかを決定するには、明確な方針が重要です。
アプリケーションのカスタマイズに関する決定基準
カスタム ソフトウェアの開発をプロジェクトに追加するという決定には、さまざまな影響、利点、および考慮事項があります。 ArcGIS システムでの開発の役割は広い範囲にわたり、重要な選択肢が全体にわたって存在するスペクトラムとして捉えるのが適切です。これは、主に既製品のシステムを使用し、ポップアップ構成、Arcade スクリプト、その他の技法によって簡単に構成するものから、Python 対応のワークフローでデータの移動やジオプロセシングを行うもの、Arcade、CSS、HTML をインターフェイスに追加できる拡張性のあるローコード アプリ、そして完全にカスタマイズされたシステムで、注意深く設計されたフロントエンドとカスタム Web サービスを持ち、データとプロセスの大幅な自動化を行うものまで広範にわたります。
この範囲はさまざまな方法で分類できます。その 1 つは、3 つの主要な手法に分けることです。
- ビジネス ニーズに応じたアプリを構成します。 ArcGIS には構成可能なアプリが数多く用意されており、基本的なワークフローから高度なワークフローまでをサポートし、ブラウザー ベースで簡単に構成できます。 これらのアプリを使用すると、必要な労力と継続的なコストが最も少なくなりますが、サポートできる構成が限られる場合があります。 このカテゴリのアプリには、Instant Apps、Story Maps、Dashboards、Field Maps、Survey 123 があります。
- ローコードのアプリ ビルダーを使用します。 Esri は、ArcGIS Experience Builder、StoryMaps、Dashboards、ArcGIS Hub、Enterprise Sites、ArcGIS Instant apps など、ローコードの開発環境を含む、さまざまなアプリ ビルダーを提供しています。 これらのアプリはすべて、ある程度のカスタム HTML および CSS の構成と、Arcade のさまざまな実装やプロファイルが可能で、機能の迅速な変更や調整が可能であることを維持しながら、完全にカスタマイズされたアプリケーションのルック アンド フィールを持つ、注意深くカスタマイズされたブランドと合致するアプリケーションを構築するために使用できます。 Experience Builder では、カスタム ウィジェットも作成できます。これらのウィジェットは開発してから、複数の異なるアプリケーションにわたって使用可能です。
- ArcGIS SDK を使用してアプリを完全にカスタマイズします。 Esri は、各種のプログラミング環境と言語向けの SDK を構築しています。これらの SDK は、ArcGIS レイヤー、UI 操作、セキュアな認証、および複雑なマッピング機能を含む、マップおよびデータ ドリブン アプリケーションの構築を強力にサポートしています。 これらの部品を自分でコーディングする必要がないため、組織で利用可能な ArcGIS の機能を活用してビジネスに特化したアプリを構築でき、アプリの開発と保守の負担を軽減できます。 Esri Developer サイトでは、利用可能な SDK の選択に関する包括的な情報と、一般的なワークフロー、機能の説明、およびサンプル コードを閲覧できます。 Esri は一連のアプリ コンポーネントも提供しており、標準化された UI の手法で Web を簡単に開発できます。
構成から完全な開発までのいずれの段階においても、唯一絶対の最良の選択肢があるわけではありません。どの方法を選択するかは、開発を行うチームの能力、カスタマイズに対する組織のアーキテクチャー哲学、この部分で行われる決定が長期的にどのような影響を及ぼすかの理解に基づいて決定する必要があります。
ソフトウェア開発の一般的な動機と要因
カスタマイズとソフトウェア開発のオプションは多岐にわたるため、これらのオプションのいずれかを使用する動機のいくつかを理解することも重要です。それぞれの動機は、どのようなカスタマイズや拡張の手法が適切かについての、異なる意思決定基準の組に寄与する可能性があります。
- 機能と統合。この動機は主に、既存のアプリやワークフローに特定の機能がない、または既存のアプリが存在しない別のシステムとの統合をサポートする必要があることが理由です。 もう 1 つの動機は、複数の機能セットを 1 つの統一インターフェイスに組み入れるのが望まれていることです。
- パフォーマンスと拡張性。 既存のサービス、インターフェイス、またはワークフローのパフォーマンスが要件を満たさない場合、カスタマイズされたオプションによって、目的のサービス レベルを達成する新しいオプションを導入できる、または時間を大幅に節約してユーザーの満足度を向上させるプロセスへのショートカットが可能になることがあります。
- 設計。 既存の ArcGIS アプリがサポートしているスタイル設定とテーマを超えてアプリケーションをブランドイメージに合わせたカスタマイズが必要な場合、カスタム アプリケーションを使用することで、組織の特定のインターフェイスまたは設計の目標を達成できる可能性があります。 Esri Calcite Design System は、適切に設計され、使いやすいユーザビリティの高いインターフェイスを実現するための共通の基盤の 1 つです。
- オーディエンスとユーザー エクスペリエンス。 使いやすさは、ほとんどのアプリケーション設計作業において重要な成功の鍵であり、それぞれのユーザー グループが求める機能の違いを理解することは重要です。 ガイド付きワークフローは、経験豊富なユーザーでも、アプリを開いてからできるだけすばやく目的を達成する手助けになります。
- 組織の文化と能力。 組織によっては、アプリケーションの設計プロセスについて特定の方法での開発を優先する、または選ぶ傾向があるかもしれません。 リーダーシップ、プロジェクト管理、技術チームは、カスタマイズ オプションについて決定を下す際の優先事項、経験の積み重ね、または関連する経験を持っている場合があり、これらを使用して新しい機会に関する意思決定の参考にすることがあります。 組織でカスタマイズ、その作業の保守、および高度に構成されたアプリに必要なかなりの量の保守を行う能力があるのかを慎重に検討することで、アプリケーションの将来の成功を見据えた意図的な選択が可能になります。
- コスト。 アプリケーションを構築するプロセスには必ずコストが発生します。そして、カスタマイズするほうが高コストと決めつけるべきではありません。目的に適したアプリは、構成されたアプリケーションの有効期間、必要な機能、および予想される変更によっては、構成されたアプリケーションよりも長く使用でき、より長期的な成功をもたらす可能性があります。 コストに関する検討では、初期の構築コストだけでなく、継続的な保守や、決定によって生じるリスクも考慮に入れる必要があります。
- 有効期間。 アプリは永遠に使用するものとして設計すべきではありません。健全な周期で置き換えを行い、他のオプションや手法を検討することで、アプリケーションの新しいオプションが見逃されず、より優れたオプションが存在するときには、既存のアプリをいつまでも使い続けないことが可能になります。 カスタム アプリケーションの更新は、新しいバージョンの SDK を取り込むだけで済む場合もあります。ただし、最初のアプリ開発のタイミングと、それを構築するために使用される SDK のライフ サイクルによっては、他の更新がより重要になるか、より大きな投資につながる可能性があります。
SDK と API の操作に関するベスト プラクティス
ソフトウェア開発がアプリケーションの作成またはシステムの構築において役割を果たす場合、ほとんどのシナリオにいくつかのベスト プラクティスを適用できます。
- チームが使い慣れたツールを使用する - 組織や、共同作業者のチームは、特定の言語、ソフトウェア開発手法、またはアプリケーションの構築方法に関する経験を持っている場合があり、ほとんどのシナリオでこれらの既存のパターンに従うことが有益です。 これにより、既存のスキルを活用し、過去の経験から学ぶとともに、単なる新しさを理由に新しい技術の採用をチームに求めないことで、効率性を実現できます。
- 最新のリリースを使用して常に最新の状態を維持する - 基本的なソフトウェア コンポーネントと同様に、ArcGIS SDK と API は定期的に更新され、新機能が組み入れられるとともに、セキュリティーの強化やパフォーマンスの向上が行われているため、ベスト プラクティスとして、常にこれらの製品の最新リリースを使用します。 Esri は、リリースごとに新機能、および互換性に影響する変更を慎重に文書化し、可能な限り少ない中断で、開発者が常に最新のリリースを利用できるようにします。
- アーキテクチャーの柱を念頭に置いて開発する - このセクションで説明するアーキテクチャーの柱は、ソフトウェア開発主導のシステムでも、既製品のシステムでも同じように適用されます。 新しいアプリケーションや機能を開発する際には、セキュリティー、パフォーマンス、拡張性、および可観測性の重要性を考慮し、完成したアプリケーションをチームが意図したライフサイクルを通じてサポートし、効果的に運用できるようにします。
サマリー
既存のインターフェイスをカスタマイズする、または ArcGIS Maps SDK を使用して新しいアプリケーションを構築して ArcGIS を拡張することは、上記のいくつかの目標を達成するための有効な選択肢となります。 エンタープライズ システムの設計プロセスでは、当該ソリューションに対する拡張やカスタマイズの妥当性を慎重に検討することで、システムの将来的な導入やコストに大きな影響を与える可能性があります。 判断に迷う場合は、組織の能力と準備状況を踏まえ、既存の運用経験やカスタム ソリューション (または多くの場合、両方の組み合わせ) のどちらがより適しているかを検討してください。