ArcObjects を使用して GIS アプリケーションを開発している方はたくさんいるかと思います。しかし、Esri は ArcGIS Online などの Web GIS 製品に力を入れており、なおかつ、ArcMap から ArcGIS Pro への移行に伴い、近い将来、ArcObjects のサポートが終了すると言われています。本日はその ArcObjects からの移行について考えてみようと思います。かなり深いテーマであり、本エントリーですべてを網羅できるほど単純な話ではないのは承知なのですが、本件について頭を悩ませている方の参考になれば幸いです。
対象読者
- ArcObjects を使用している開発者の方
- ArcObjects の代替製品を探している方
ArcMap、 ArcGIS Pro とは
Esri が販売している GIS デスクトップアプリケーションです。それぞれの違いについて以下のエントリーに書いていますので、興味のある方はぜひ読んでみてください。
ArcObjects とは
簡単に言うと、GIS アプリケーションを開発するためのライブラリでしょうか。
Esri の方向性
Esri はプラットフォームとしての ArcGIS の使用を推奨しており、ArcObjects を使用してアプリをスクラッチで開発するというのは時代に合っていないと考えていると個人的には感じています。少し説明しづらいのですが、プラットフォームとしての ArcGIS とは以下に詳細が記載されています。ただ、これを読んでもなかなかピンとこないかと思います。簡単に言うと「Web GIS を利用してデータを共有」「C/S アプリの開発はもうやめて Web GIS を使用」「できるだけアプリの開発はせずに、ArcGIS の既製品を利用」していこうといった感じだと思います。ビジネスのやり方としてはすごく時代に合っていると思います。
ArcObjects の代わりとなる製品
単刀直入に言うと代替となる製品はありませんし、現時点でそれを開発をしているという情報もありません。あえて言うなら以下が候補になりうるかと思いますが、今まで ArcObjects で作っていたものをすべて作り直さなければいけません。
ArcGIS Pro SDK
以下エントリーで紹介しているのですが、ArcGIS Pro SDK を使えば ArcGIS Pro の UI をカスタマイズしたり、アドイン機能を開発することができます。
ArcGIS Pro SDK のメリット
- ArcGIS Pro をベースにしてアドインを作るだけなので、基本機能は ArcGIS Pro のものを利用することができ、開発工数を減らすことができる。
思いつくのはこのくらいでしょうか。
ArcGIS Pro SDK のデメリット
- 高価な ArcGIS Pro を必ず買わなければいけないので費用がかさむ。
- ArcGIS Pro ありきなので、ArcGIS Pro が起動していることが前提。そのため、ArcObjects だったらできていたような処理を実現することが難しくなる（タスクでの夜間処理など）
- ArcGIS Pro の上にのっかっているアドイン開発なので、ArcGIS Pro を完全に制御することはできない（自由度が低い）。
- ArcGIS Pro での何気ない操作が ArcGIS Pro SDK 上でイベントとして走ってしまうことがある（制御が難しい）。
ArcObjects の代替と考えるのは難しいかと思います。
ArcGIS Runtime SDK
こちらも以下エントリーで紹介しているのですが、Windows 及び iOS、Android プラットフォーム上で動作するネイティブ GIS アプリケーションの開発キットです。
ArcGIS Runtime SDK のメリット
- クロスプラットフォームでデスクトップアプリとしても開発できるし、スマホアプリとしても開発できる。
メリットとしてはこの辺なのでしょうか。ArcGIS Pro SDK とは異なり、アプリの制御は自分の好きなようにできます。
ArcGIS Runtime SDK のデメリット
- Web クライアント的な立ち位置なので、ArcObjects ほど何でもできるというわけではない。特に高頻度で様々なデータを編集するようなアプリの開発には向いていない。
- 機能とは関係ないですが、ライセンス形態が複雑すぎて理解することが困難。
こちらも ArcObjects の代替と考えるのは難しいかと思います。
番外：ArcPy
ArcObjects で夜間バッチなどを走らせている場合、上記二つの SDK ではなく、ArcPy を使ってください、と米国Esriもたしか言っていた気がします。
どうやって ArcObjects の代わりとなるアプリを開発すればいいのか
仕様が満たせるのであれば、ArcGIS Pro SDK か ArcGIS Runtime SDK のどちらか適した方で開発すればいいかと思います。ただ、それが難しい場合（ArcGIS Pro SDK も ArcGIS Runtime SDK も単独では ArcObjects の代わりとして使えない場合）、業務や用途に合わせてこれら二つの SDK を使って複数のアプリケーションを開発する必要があるかと思います。ただ、個人的にはこれはあまり現実的ではないかと思います。まず、コストの問題です。ただでさえ ArcGIS Pro は高いのにさらに ArcGIS Runtime SDK 分のコストをかけるというのは難しいかと思います。また、二つの SDK を習得する学習コストや複数のアプリを保守する必要がでてくるので、そこも大きな負担になってくるかと思います。
なぜ ArcObjects の代替となる製品がないのか？
上述したように、Esri はプラットフォームとしての ArcGIS の使用を推奨しており、ArcObjects でアプリを開発するという手法は時代に合わなくなってきていると考えているからだと思います。基本的には Web GIS を中心にできるだけ開発をせずに ArcGIS の既製品を使いましょうというスタンスですね。
ArcGIS の既製品とは何か？
ArcGIS にはデスクトップ製品や開発用の SDK 以外にも様々な製品があります。例えば以下のような製品は ArcGIS のライセンスさえ持っていれば無料で使用することができたはずです。ArcGIS Online や ArcGIS Enterprise などの Web GIS を中心にこういった ArcGIS 製品をできるだけ使用して、開発をできるだけ少なくしていきましょうという方向性になっていますね。
Esri の方針は日本の市場に合っているのか？
個人的には合っているとは思いません。Web GIS はまだまだ日本で浸透しているとはいえず、色々な会社さんでスタンドアロン、C/S アプリの開発が行われているのが現状です。日本ではシステムを導入する際、どうしても開発することが前提になってしまうことが多いので、これがプラットフォームとしての ArcGIS の普及が遅れている大きな要因の一つかと思います。また、日本だとシステムを刷新する際も業務フローは意地でも変えず（システムに合わせて業務を変えることはしない）、システムを業務に合わせる傾向にあると思います。そのため、ArcObjects が使われていたのだと思うのですが、プラットフォームとしての ArcGIS を使うためにはシステムに合わせて業務を変える必要が出てくると思います。こういった日本のシステム導入の傾向には Esri の方針は明らかにマッチしていないのではと感じます。
どうして Web GIS がなかなか浸透していないのか？
多くの会社さんが Web GIS に移行したいと考えているかもしれませんが、様々な問題がありそれを実行することができません。
- セキュリティ上の理由で ArcGIS Online は使用できない。
- ArcGIS Enterprise は非常に高価なので導入できない。
※ArcGIS Online と ArcGIS Enterprise が Web GIS にあたります。
典型的なものとしては上記でしょうか。特に小さな自治体さんなんかに当てはまると思いますが、こうなると Web GIS は使うことができませんね（プラットフォームとしての ArcGIS の使用は難しい）。ですので、こういった自治体さんは ArcObjects で開発したようなスタンドアロンの GIS ソフト を導入せざるを得ません。そのため、開発会社さんもそういった需要に答える必要があり、Web GIS の導入が進まないと考えられます。
ただ、プラットフォームとしての ArcGIS が悪いわけではないかと思います。むしろ、要件にはまればすごく便利だと思います。それが日本での需要にマッチしているかどうかはまた別の話だと思いますが。
ArcGIS ユーザーが他の GIS エンジンに逃げる？
私の知る限りですが、すでにそういう動きをしている会社さんはあります。特に小さな自治体さんなんかを顧客に持つ開発会社さんには「プラットフォームとしての ArcGIS 」はメリットよりデメリットの方が大きいかと思います。 ArcGIS Pro SDK や ArcGIS Runtime SDK では仕様を満たすことが難しいし、コスト的に採用できない。また、これらの SDK で開発するにしても今まで ArcObjects で作ったソフトを作り直ししなければならないのだったらこのタイミングで別の GIS エンジンに乗り換えるというのは自然な流れかと思います。
結局どうすればいいのか？
ArcObjects から移行するにあたって、色々なデメリットがあっても ArcGIS を使い続けたいという方は多いかと思います。そういった方向けに個人的に思う ArcObjects の代替パターンを記載します。
ArcObjects 代替パターン
| 仕様 | ArcGIS Pro SDK | ArcGIS Runtime SDK |
|---|---|---|
| 編集機能がある場合（ポイント、ライン、ポリゴンすべて） | ○ | × |
| 編集機能がある場合（アノテーション） | ○ | × |
| 編集機能がある場合（ポイントのみ） | ○ | ○ |
| 参照機能のみの場合※1 | ○ | ○ |
| 高度な印刷機能がある場合※2 | ○ | × |
| ラスターを編集（幾何補正など）する場合 | ○ | × |
| モバイルアプリの場合 | × | ○ |
| アプリを完全に制御したい場合 | × | ○ |
| 図面作成をしたい場合 | ○ | × |
| C/S にしたい場合 | ○ | × |
※1. 仕様次第ですが、高度な分析機能がなければ ArcGIS Runtime SDK で十分かと思います。
※2. テンプレートを使用したり、図面の印刷をする場合など
仕様やコストを考慮しながら決めるものなので、上記の表が絶対というわけではありませんが、参考程度に見ていただければと思います。また、ArcObjects で高度なアプリケーション（様々な編集、分析機能を有しているアプリケーション）を開発している場合、どちらの SDK も不十分となってしまうかもしれません。その場合は、以下二つの選択肢しかないかと思います。
- 別の GIS エンジンを使用
- アプリの仕様を変更する
まとめ
取り留めの無い話になってしまったかもしれませんが、いかがでしたでしょうか。本件は非常に複雑で、本エントリーですべてを書き切ることは難しいですし、有識者の方からしたら考慮が足りない部分もあるかもしれません。しかし、ArcObjects からの移行に関しては ESRIジャパンさんから具体的なアナウンスがないですし、困っている方がたくさんいらっしゃるかと思います。本エントリーだけでは不十分かと思いますが、そういった方への参考になれば幸いです。もし、何か気になること、知りたいことがありましたらコメントを残していただければと思います。
