<\/HEAD>
ArcGISの新しいバージョンがリリースされるたびに、私は他のどの質問よりも特に一つの質問をよく受けます。 正確な言葉は変わることがありますが、いつも「どうやってすべてのユーザーをArcGIS DesktopからArcGIS Proに移行するのか？」という趣旨のものです。 <\/SPAN> <\/SPAN><\/P> <\/SPAN><\/P>私のEsriでの役割の大きな部分は、お客様がArcGISプラットフォームを実装および構成するのを支援することであり、それは最新バージョンへのアップグレードや最新製品のインストールにも及びます。ですので、この質問を受けたとき、多くの場合、デスクトップユーザー向けの技術的な移行パスについて話すことを期待されています。しかし、そのような単純なパスは <\/SPAN>ユーザーがArcMapからArcGIS Proへ1対1で置き換えることを前提としており、これはしばしば根本的な問題への最良の対応方法ではありません。<\/SPAN><\/SPAN> <\/SPAN><\/P> <\/SPAN><\/P>移行の必要性ではなく、私はこれをモダナイゼーション（近代化）の機会と考えることが好きです。 <\/SPAN><\/SPAN>Migration <\/SPAN>は一般的に技術に焦点を当てています。アップグレード、パッチ、最新製品のインストール。Modernization <\/SPAN>はアップグレードや新製品を含むこともありますが、それはあくまで手段に過ぎません。本質的には <\/SPAN>新しいパターンへの移行、パラダイムシフトについてです。ArcMapとArcGIS Proに関する私たちの会話では、そのパターンはWeb GISです。デスクトップからサーバーへ、そしてWebへ、最終的には <\/SPAN>Distributed GISへと進むにつれて、以前は利用できなかった新しい選択肢が現れます。ArcGIS Proやその他すべてのWeb GISネイティブアプリケーションは、新しく強力な機能を提供し、それらはGISの使い方を変えることで初めて活用できます。<\/SPAN><\/SPAN> <\/SPAN><\/P>
モダナイゼーションに取り組む際、私はほぼ必ず3つの簡単な質問から始めます:<\/span> <\/span>
<\/p>
- ユーザーは誰ですか？<\/span> <\/span>
- 彼らが重視する位置情報は何ですか？<\/span> <\/span>
- 彼らが求めている答えは何ですか？<\/span> <\/span>
<\/ul><\/p>ArcGISを使用しているすべての人は、問題を解決したり、質問したり、 <\/span>答えを得ようとしています spatial data を使って。その問題や質問、答えはワークフローとしてまとまり、そのワークフローこそが技術ではなく私たちが注目すべきものです。 <\/span> <\/span>これらの質問に答えた後、既存のワークフローを見直し、それぞれのワークフローについて3つのオプションのいずれかを使ってどのようにモダナイズするか推奨します。 <\/span> <\/span>
- Desktop to Pro Workflow Transition: —オーブ・ザ・ボック(OOB)功能のみを使い�年にわずかない} 0px; padding: 0px; background-color: inherit;"> <\/SPAN>ArcGIS Desktopでのo<\/SPAN><\/SPAN>あなたの直感では、ワークフローをProに移行するか、Pro用のプラグインを作成する必要があると思うでしょう。しかし、Web GISを活用するEsri <\/SPAN><\/SPAN>Appsの広大なエコシステムにより、デスクトップのワークフローに対して、Esri <\/SPAN><\/SPAN>が完全にサポートし維持しているOOBアプリを使用して適切な（望ましい場合もある）代替手段を見つけることがよくあります。S<\/SPAN><\/SPAN>時にはこのような変更はアーキテクチャやデータの調整を必要とするため、GIS管理者にとっては小さな変更ではないかもしれませんが、適切に行われればユーザーにとって非常に簡単な移行を提供できます。 <\/SPAN> <\/SPAN><\/LI>DesktopからCustom <\/SPAN>Technology <\/SPAN><\/SPAN>への移行<\/SPAN>: <\/SPAN>過去10年間で、カスタマイズがあらゆる問題に対するデフォルトのアプローチであったものから、コストよりもCOTSを優先する方向へ大きく変わってきました。しかしここ数年で振り子はその中間地点に落ち着き、まずは設定が依然として良いルールである一方で、必要な場合のカスタマイズはもはや否定されなくなりました。ArcGISで利用可能なDeveloper tools<\/SPAN> <\/SPAN>によって、このカスタム技術は多様な形態を取ることができます。新しいカスタムアプリ、ツール、またはプラグインの構築方法を決める際にはユーザーベースについて考えてください。そのワークフローのユーザーが他に何をしているかも考慮しましょう。これが彼らの唯一のワークフローですか？もしそうなら、メンテナンスが簡単で迅速に構築できるJavaScriptアプリが最適かもしれません。複数のワークフローがあり、そのほとんどがモバイルアプリに移行する予定ですか？それならAppStudio<\/SPAN> <\/SPAN>で構築することが理にかなっており、そのユーザーのデバイス切り替えの必要性を制限できます。あるいは99%のワークフローがArcGIS Proのデスクトップ内に留まる場合は、カスタムProプラグインへの投資が価値あるものかもしれません。すべては文脈次第です。 <\/SPAN><\/SPAN> <\/SPAN><\/SPAN><\/LI><\/OL> <\/SPAN><\/P>GISを近代化し、ユーザーがWeb GISへのパラダイムシフトを行う際には、これらのステップを念頭に置いて彼らが選択肢を理解できるよう支援してください。そして、新しいツールや製品のエコシステム全体が彼らのミッション達成を助けるために利用可能であることを伝えましょう。<\/SPAN> <\/SPAN><\/P><\/BODY><\/HTML>
