ArcGIS には、ノーコード / ローコードで地図アプリを作成できる「アプリ ビルダー」が複数あり、プログラミング知識がなくてもブラウザー上で簡単にアプリを作成・公開できます。しかし、初めての方は「どのアプリ ビルダーを選んだらいいのか?」と迷ってしまうかもしれません。そんな方にまずお伝えしたいのが、アプリ ビルダーを選ぶ前にアプリの「レイアウト」を決めるということです。
本シリーズ (全 2 回) では、Web アプリにおける UI (画面の見た目) と UX (使いやすさや体験の質) の視点から最適なアプリ ビルダーの選び方を解説します。パート 1 となる本記事では、アプリ ビルダー選びの基本ポイントを整理した上で、UI や UX のデザインの原則に基づいた「理想のレイアウト」の考え方をご紹介します。続くパート 2 では、実際の目的に合わせてどのビルダーを選ぶべきかを詳しく見ていきましょう。
本シリーズは、以下のブログ記事を参考に執筆しました (原文は英語)。
・米国 Esri: App Builders | What App Builder is Right for You?
・Esri Canada: Choosing the right ArcGIS app builder: A UX & UI design perspective, Part 1 / Choosing the right ArcGIS app builder: A UX & UI design perspective, Part 2
目次
アプリ ビルダー選びの 4 つの基本ポイント
本題の「レイアウト」に入る前に、まずは自分にぴったりのビルダーを絞り込むための 4 つの基本ポイントを整理しておきましょう。
- 目的 (データ)
「何のためにアプリを作るのか」というゴールを明確にします。扱うデータの内容によって、最適な見せ方は変化します。
- 地図で場所を直感的に伝えたい (地図中心)
- 複雑なデータを分析・比較したい (対話的な操作)
- 刻々と変わる状況を監視したい (リアルタイム モニタリング)
- 背景にある物語を伝えたい (ストーリー テリング)
- ユーザー層 (誰が、どこで使うのか)
アプリを使う「ユーザー」を具体的にイメージしましょう。ターゲットによって、必要な機能やデザインは異なります。
- 専門知識の有無: GIS の専門家向けか、一般の利用者向けか
- 利用デバイス: オフィスで PC を使うのか、現場でスマホからアクセスするのか
- 言語やアクセシビリティ: 複数の言語対応や、誰にでも使いやすい配慮が必要か
- レイアウト (操作を迷わせない構成か)
「目的」と「ターゲット」が決まれば、自ずと最適なレイアウトの形が見えてきます。この後の章で詳しく解説しますが、この「レイアウト」こそが、ユーザーの使い勝手 (UX) を左右する非常に重要な要素です。
- アプリ作成者のスキルと時間
皆さんがアプリ作成にかけられる「時間」と「スキル」も大切なポイントです。
- ArcGIS Instant Apps : とにかく早く、シンプルに作りたい / 初心者の方
- ArcGIS Experience Builder : デザインや機能にこだわりたい / より高度なカスタマイズを求める方
地図アプリの「5 つのデザイン パターン」
ここからは、具体的なレイアウトの決め方について深堀していきましょう。その前段階として、まずは地図アプリにおける一般的なデザイン パターンと原則をご紹介します。「どういった視点でレイアウトを決めるべきなのか」を判断する上で非常に役立ちます。今回参考にするのは、米国 Esri 社の ユーザー インターフェース エンジニアのマネージャーである Michael Gaigg 氏が公開している Web サイト「Map UI Patterns」および Esri 社が運営する出版会社 Esri Press から出版されている書籍「Designing Map Interfaces: Patterns for Building Effective Map Apps」です (どちらも原文は英語)。地図アプリの UI/UX 設計における実践的な手法が「パターン」として整理されています。その第 2 章「適切なレイアウトの選択」で提唱されている、5 つの代表的なデザイン パターンを見ていきましょう。
Full Map (全体的なマップ)

- 特徴: 画面の大部分が地図。直感的に場所を探すのに最適。
- 用途の例: 「今すぐ近くの避難所を探したい!」という緊急時や、「このエリアにはどんな公園があるんだろう?」と自由に地図を動かして探索してほしい時。
Partial Map (部分的なマップ)

- 特徴: 地図の横に編集や検索ウィジェットがある。作業効率を重視。
- 用途の例:「左側のリストで条件に合うカフェを絞り込み、右側の地図で場所を確認する」といった、特定の操作 (目的) をスムーズに完了させたい時。
Reference Map (参照マップ)

- 特徴: グラフや数字が主役。地図は場所の補足が目的。
- 用途の例: 売上データや統計情報のダッシュボードで、「どの地域の数字か」をパッと見て直感的に理解するための、小さな補助マップを示したい時。
Embedded Map (埋め込みマップ)

- 特徴: Web ページの中に地図が溶け込んでいる構成。地図は視覚的な補足。
- 用途の例: 観光案内やニュース記事を読み進める中で、写真や文章のすぐ横に「あ、この場所の話なんだ」と自然に位置関係を示したい時。
No Map (マップなし)

- 特徴: 地図を表示せず、テキストやグラフ中心。地理情報が不要な業務で操作性と明瞭さを重視。
- 用途の例: 現場でのアンケート調査や統計ダッシュボード(数値やグラフ中心) など、あえて地図を出さないことで、迷わず正確にデータを入力・管理してほしい時。
レイアウト設計で押さえるべき「6 つのポイント」
アプリのレイアウトを決めるときは、「ユーザーが画面の前でどのような操作をするか」を細かく想像することが重要です。設計のヒントとして、以下のポイントを確認してみましょう。
- 最初に何を表示すべきか?
アプリを開いた瞬間に、まず何が見えるべきかを考えます。例えば、地図の内容を理解するための「凡例」、すぐに使いたい「検索ツール」、あるいはアプリの説明や背景情報が書かれた「テキスト」などが挙げられます。
- 常に表示すべきウィジェットは何か?
フィルターやルート検索、レイヤーの切り替えなど、そのアプリのメインとなる操作が明確な場合は、関連するウィジェットを常に表示させておくことで、ユーザーの迷いを減らせます。
- 複数のウィジェットを同時に使う必要があるか?
「データをコピーしながら別のツールを参照する」といったワークフローがある場合、それぞれのウィジェットを同時に開いておけるレイアウトが必要です。
- ウィジェット同士の距離は適切か?
ユーザーがアプリ内で複数のウィジェットを頻繁に行き来する場合、ウィジェット同士を近くに配置しましょう。これは、「対象物が近く、大きいほど、素早く正確に操作できる」という「フィッツの法則」に基づいたデザインの基本です。
- ウィジェットは地図の上に重ねるか、横に配置するか?
フィルターやデータ編集など、地図を見ながら操作するワークフローが中心なら、ウィジェットが地図を隠さないよう「地図の横 (サイドバー)」に配置するのがおすすめです。
- そのウィジェット、本当に必要ですか?
「便利そうだから」とウィジェットを詰め込みすぎると、本当に必要なツールが見つかりにくくなります (これをキッチンシンク アプリといいます。)。Web サイトのユーザビリティの第一人者である Jakob Nielsen 氏が提唱した「ユーザビリティ 10 原則 (原文は英語)」のひとつ「最小限で美しいデザイン」によると、不要な情報や機能を詰め込みすぎると、ユーザーの操作性が下がるとされています。そのため、アプリ内にはユーザーが本当に必要としているウィジェットだけを配置することが重要です。
まずは紙にスケッチしてみましょう
ここまで考えたレイアウトを実際の形にするために、いきなりビルダーを触り始めるのではなく、まずは紙にスケッチを描いてみることをおすすめします。手書きで複数のアイデアを書き出し、それを実際のユーザーに見せてフィードバックをもらってみてください。この「スケッチとテスト」のプロセスを通じてワークフローを整理し、デザインを最適化しておくことが、ユーザーにとって最も使いやすいアプリを完成させる鍵となります。
次回予告
本記事では、UI/UX デザインの原則に触れながら、地図アプリの価値を最大化する「レイアウト」の考え方をご紹介しました。理想の画面構成は見えてきたでしょうか?
次回のパート 2 では、今回学んだレイアウトやデザイン パターンを実際に形にするために、「どのアプリ ビルダーを選べばいいのか」を解説します。ArcGIS の各ビルダーが持つカスタマイズ性や機能の特徴を、UI/UX の視点からさらに深掘りしていきます。
