タブレット向けアプリ品質チェックリスト

Posted by 山崎富美 Developer Relations Team

[この記事は Android Developers に掲載された "Tablet App Quality Checklist" という記事を元に翻訳・再構成しています。詳しくは元記事をご覧ください。-山崎]

アプリを Google Play に公開する前に、そのアプリが魅力的な機能と直感的で優れたデザインの UI を通じ、タブレット ユーザーの基本的な期待に応えているのかを確かめることが大切です。

タブレット端末は、Android 搭載製品の一角として成長しつつあり、新たなユーザー エンゲージメントと収益を生みます。このドキュメントは、タブレット ユーザーを対象にしたアプリの成否を大きく左右する品質や機能セット、UI といった重要な側面に重点的に取り組む上で役立つはずです。それぞれの重要な分野についてチェックリスト項目を設け、細分化された作業内容やベスト プラクティスを記載しています。

これ以降で示すチェックリストの作業項目には便宜的に番号を付けていますが、取り組む順番は問いません。また、ご自分のアプリにとって適切と思われる範囲で対応してください。ユーザーにできる限り最高のアプリを提供するという観点から、チェックリストの推奨事項にはできるだけ従うようにしてください。

チェックリスト内には、各作業で扱っているトピックに取り組む際に役立つ参考資料へのリンクを貼っていますのでぜひご参照ください。

チェックリスト コア アプリ品質のテスト レイアウトを最適化する 余っている画面領域を活用する タブレット画面用のアセットを使用する フォント サイズとタッチ ターゲットを調整する ホーム画面ウィジェットのサイズを調整する アプリの全機能セットを提供する ハードウェア機能を要求しない タブレット画面構成を宣言する Google Play のベスト プラクティスに従う テスト テスト環境を整える

1. コア アプリ品質のテスト

優れたタブレット アプリを提供するための第一歩は、アプリの対象となる全端末と全フォーム ファクターにおいて、コア アプリ品質条件を満たしているかを確認することです。すべての条件については、Core App Quality Checklist（コア アプリ品質チェックリスト）を参照してください。

タブレット端末使用時のアプリ品質について、コア アプリ品質とタブレット アプリ品質の両面で評価するには、適切なハードウェアまたはエミュレーターを利用したテスト環境を整える必要があります。詳しくは、テスト環境を整えるのセクションを参照してください。

参考資料: Core App Quality Guidelines（コア アプリ品質ガイドライン） — すべての対象端末において、Android アプリが必ず満たさなければならないコア品質条件の一覧。

2. 大画面に合わせてレイアウトを最適化する

Android では、さまざまな種類の端末の画面サイズやフォーム ファクター上で動作するアプリの開発を容易に行うことができます。その幅広い適合性は、すべての対象端末に配布できる単一アプリの設計ができるという点で、開発者にとって有利に働きます。しかし、（特にタブレット ユーザーに対して）それぞれの画面構成に最適なユーザー エクスペリエンスを提供するには、対象の端末の画面構成ごとに、レイアウトや各種 UI コンポーネントを最適化する必要があります。タブレットでは、UI の最適化によって広い画面を活用できるというメリットを生かして、例えば新機能の提供や、新しいコンテンツの表示、その他のさまざまな方法によるエクスペリエンスの強化ができ、ユーザーのエンゲージメントを高めます。

携帯端末向けのアプリをすでに開発していて、それを新たにタブレットにも提供したいときは、まず、レイアウトやフォント、スペーシングを微調整することから始めます。場合によっては（7 インチのタブレットや、広々としたレイアウトのゲーム アプリなど）、これらを微調整するだけで見た目が整います。それ以外、例えばもっと大きなサイズのタブレットなどの場合は、UI の一部を設計し直すことで、「拡大されただけの UI」を効率の良いマルチペイン UI にしたり、ナビゲーションを行いやすくしたり、追加コンテンツへと変えたりすることができます。

「拡大されただけの UI」を解消する: タブレットの場合、単一ペイン レイアウトにすると不自然な余白が生じたり、一行が長くなりすぎたりします。パディングを使用して UI 要素の幅を狭くすると共に、マルチペイン レイアウトの使用も検討しましょう。

推奨事項は下記の通りです。

• 必要に応じて large（大）および xlarge（特大）画面用のカスタムレイアウトを用意します。また、画面の最小寸法あるいは幅・高さの最小値に基づいてロードされるようなレイアウトを提供してもよいでしょう。
• 大きめの画面については最低でもフォントサイズやマージン、間隔などの寸法をカスタマイズし、画面の使い方とコンテンツの読みやすさを改善します。
• UI コントロールの位置を調整し、ユーザーがタブレットを手に持っているときに操作しやすい位置に配置します（横置きのときはサイドに配置するなど）。
• UI 要素のパディングは通常、タブレットでは携帯端末の場合よりも大きくします。48dp 単位（グリッドは 16dp）にすることをお勧めします。
• テキスト形式のコンテンツは、画面の端にぴったり沿った状態にならないよう適切にパディングを使用します。画面の端近辺では最低でも 16dp のパディングを使用してください。

特に、レイアウトが画面全体に「広がって」表示されないように注意します:

• テキストの行は長くなりすぎないようにし、1 行あたり半角文字で最大 100 文字とし、1 行あたり50～75 文字に収めるのがベストです。
• ListViews やメニューには画面の幅全体を使用しないでください。
• パディングを使用してオンスクリーン要素の幅を管理したり、タブレット向けにマルチペイン UI に切り替えたり（次の項目を参照）します。

参考資料: Metrics and Grids（尺度とグリッド） — 画面上のタッチ ターゲットおよびその他UI要素の配置やサイズ変更方法を説明した Android デザイン用ドキュメント。 Devices and Displays（端末とディスプレイ） — 各種端末とディスプレイについての Android デザイン用ドキュメント。 Supporting Multiple Screens（複数の画面に対応する） — 複数の画面サイズでの表示を最適化するための UI 管理について詳しく説明した開発者向けドキュメント。 Configuration examples（構成例） — 特定の画面サイズについて、レイアウトやその他リソースを宣言する方法の例。

3. タブレット上の余っている画面領域を活用する

タブレット画面では、マルチペイン レイアウトにすることで見た目のバランスがよくなると同時に、実用性も読みさすさも向上します。

タブレット端末は携帯端末にくらべ、特に横向きにした場合、アプリで使える画面領域が大幅に増えます。中でも 10 インチのタブレットは特に画面領域が大きくなりますが、7 インチのタブレットでもコンテンツの表示やユーザーのために使えるスペースが増えます。

タブレット上で動作するときのアプリの UI を検討するときは、タブレット上の余っている画面領域を十分に活用しましょう。推奨事項は下記の通りです。

• 追加のコンテンツを盛り込んだり、既存のコンテンツを別な形で扱ったりする方法を探ります。
• タブレット画面では マルチペイン レイアウト（Multi-pane Layout）を使い、複数の単一ビューを 1 つの複合ビューにまとめます。こうすることで、増えた画面領域をより効率よく使用でき、ユーザーもアプリを操作しやすくなります。
• 画面の向きが変わったときに複合ビューのパネルをどのように再配置するのかを考慮します。

複合ビューは、携帯端末用 UI（上）の複数の単一ビューを 1 つにまとめ、より充実した効率の良いタブレット用 UI にします（下）。

• 1 つの画面は Activity サブクラスとして実装されますが、個々のコンテンツ パネルを Fragment サブクラスとして実装することを検討します。こうすることで、さまざまなフォーム ファクター全体で、またコンテンツを共有するすべての画面にわたって最大限にコードを再利用できます。
• どの画面サイズでマルチペインUIを使用するかを決め、それぞれのレイアウトを適切な画面サイズ バケット（large/xlarge など）、あるいは最小画面幅（sw600dp/sw720 など）で提供します。

参考資料: Multi-pane Layouts（マルチペイン レイアウト） — マルチペイン UI の使用に関する Android デザイン ガイド。ナビゲーションを平面的にし、より多くのコンテンツをタブレット UI に盛り込む方法の例などが記されている。 Planning for Multiple Touchscreen Sizes（複数のタッチスクリーン サイズを計画する） — タブレットやその他端末向けに、直感的で効果的なナビゲーションのデザイン方法を段階的に説明する Android トレーニング クラス。 Designing for Multiple Screens（複数の画面を設計する） — タブレットやその他端末向けに、直感的で効果的なナビゲーションのデザイン方法を段階的に説明する Android トレーニング クラス。

4. タブレット画面用に設計されているアイコンなどのアセットを使用する

アプリの見た目をよくするには、タブレット画面で使用されるピクセル密度用に作られているアイコンなどのビットマップ アセットを使用するようにします。具体的には、タブレットが通常サポートしている範囲のすべてのピクセル密度それぞれに対し、代替ビットマップ ドローワブルのセットを作成する必要があります。

表1. アイコンタイプ別の未加工のアセット サイズ

密度	ランチャー	アクションバー	小型/コンテキストタイプ	通知
mdpi	48x48px	32x32px	16x16px	24x24px
hdpi	72x72px	48x48px	24x24px	36x36px
tvdpi	(hdpi を使用)	(hdpi を使用)	(hdpi を使用)	(hdpi を使用)
xhdpi	96x96px	64x64px	32x32px	48x48px

その他の検討事項:

• アクションバーや通知、ランチャーのアイコンは、アイコンのデザイン ガイドラインに従ってデザインし、タブレット上でも携帯端末と同じ物理サイズにします。
• ピクセル密度固有の リソース修飾子（resource qualifiers）を使用して、適切な代替リソース セットがロードされるようにします。

参考資料: Iconography（アイコンについて） — さまざまなタイプのアイコンの使用方法を説明した Android デザイン用ドキュメント。 Providing Resources（リソースを提供する） — 端末画面の特定の領域に対して、レイアウトとドローワブル リソース セットを提供する方法を説明した開発者向けドキュメント。 Supporting Multiple Screens（複数の画面に対応する） — 複数の画面サイズでの表示を最適化するための UI 管理について詳しく説明した開発者向けドキュメント。 Supporting Different Screens（さまざまな画面に対応する） — 各種画面サイズ・密度に合わせてユーザー エクスペリエンスを最適化するプロセスを詳しく学べる Android トレーニング クラス。

5. タブレット画面用にフォント サイズとタッチ ターゲットを調整する

タブレット上で使いやすいアプリにするには、アプリの対象としているすべての画面構成に合わせて、タブレット UI のフォント サイズとタッチ ターゲットを調整するための時間はしっかり取りましょう。フォントサイズの調整は、スタイル設定可能な属性（styleable attributes）または寸法のリソース（dimension resources）で行うことができます。また、タッチ ターゲットは前述したようにレイアウトとビットマップ ドローワブルで調整可能です。

推奨事項は下記の通りです。

• テキストは、タブレットの画面サイズやピクセル密度で表示したときに大きすぎたり、小さすぎたりしないようにしましょう。ラベルは、該当する UI 要素に合わせて適正なサイズにし、またラベルやタイトルなどの各種要素が不適切な位置で改行されないようにします。
• オンスクリーン要素については、タッチ ターゲットの推奨サイズは 48dp（最低でも 32dp）ですので、タブレット UI 用にいくつかの調整が必要かもしれません。ほとんどのユーザーを対象とした実装方法については、尺度とグリッド（Metrics and Grids）をお読みください。一部のユーザーのニーズに対応するには、大きめのタッチ ターゲットを使用するのが適切な場合があります。
• 比較的小さなアイコンについては、TouchDelegate を使用するか、または透明ボタン内でアイコンをセンタリングすることで、タッチ可能な領域をできるだけ 48dp よりも大きくします。

参考資料: Metrics and Grids（尺度とグリッド） — 画面上のタッチ ターゲットとその他 UI 要素の配置やサイズ変更方法を説明した Android デザイン用ドキュメント。 Typography（書体） — アプリにおける書体の使用方法の概要を説明した Android デザイン用ドキュメント。 Supporting Multiple Screens（複数の画面に対応する） — 複数の画面サイズでの表示を最適化するための UI 管理について詳しく説明した開発者向けドキュメント。 Supporting Different Densities（さまざまな密度に対応する） — 端末画面の特定の領域に対して、レイアウトとドローワブル リソース セットを提供する方法を説明した Android トレーニング クラス。

6. タブレット画面用にホーム画面ウィジェットのサイズを調整する

アプリにホーム画面ウィジェットがある場合、タブレット画面での優れたユーザー エクスペリエンスを提供するため、下記に示す事項を検討してみてください。

• ウィジェットのデフォルトの高さ・幅は、タブレット画面と最小/最大リサイズ高さ・幅に合わせて適切に設定します。
• ウィジェットは 420dp 以上のサイズに変更できるようにし、垂直または正方形ウィジェットの場合はホーム画面の 5 行以上、水平または正方形ウィジェットの場合は 5 列以上にまたがるようにします。
• 9 パッチ画像が正しくレンダリングされるようにします。
• デフォルトのシステム マージンを使用します。
• アプリの targetSdkVersion を 14 以上に設定します（可能な場合）。

参考資料: Adding the AppWidgetProviderInfo Metadata（AppWidgetProviderInfo メタデータを追加する） — ウィジェットの高さ・幅の寸法を設定する方法を説明した API ガイド。 App Widget Design Guidelines（アプリ ウィジェット デザイン ガイドライン） — ウィジェットのサイズの設計、管理のためのベスト プラクティスとテクニックを紹介した API ガイド。

7. アプリの全機能セットをタブレット ユーザーに提供する

タブレット ユーザーが、あなたのアプリの売りとなる機能をきちんと体験できるようにします。推奨事項は下記の通りです。

• アプリは少なくとも携帯端末と同じ機能セットをタブレットにも提供するようにします。
• 例外的なケースとして、ほとんどのタブレットにおいてハードウェア的に対応していない、あるいはユース ケース上対応していない一部の機能については、省くか他のものに置き換えても構いません。下記に例を示します。
  • 携帯端末では電話機能を使用しているが現在のタブレットでは電話機能を使用できない場合は、この機能を省くか、関連する機能に置き換えても構いません。
  • 多くのタブレットには GPS センサーが搭載されていますが、一般的なユーザーは、タブレットを持ってランニングをすることはまずありません。携帯端末向けアプリで、端末を身につけてランニングしたときに GPS で追跡し距離などを記録する機能を提供しているとしましょう。タブレットではそういったユース ケースの需要がないと思われるため、この機能をタブレット向けに提供する必要はないと考えられます。
• タブレット UI から機能や性能を省くことになる場合は、ユーザーがそれらにアクセスできないようにするか、いわゆる「グレースフル デグラデーション」として代替機能を提供するようにします（ハードウェア機能については次のセクションも参照してください）。

8. タブレットに搭載されていない可能性があるハードウェア機能を要求しない

携帯端末とタブレットとでは一般的にセンサーやカメラ、電話機能など、各種機能のハードウェア サポートが異なっています。例えば、多くのタブレットは Wi-Fi 構成で利用できますが、電話機能には対応していません。

顧客ベース全体に対応する 1 つの APK を配布するためにも、タブレットでは一般的ではないハードウェア機能を要求するようなものがアプリに組み込まれていないことを確かめてください。

• アプリのマニフェストには、android:required=”false” 属性で宣言されている場合を除き、タブレットで使用できない可能性のあるハードウェア機能や能力に対しては <uses-feature> 要素を含めないでください。例えば、アプリが次のような機能を要求しないようにします。
  • android.hardware.telephony
  • android.hardware.camera （バックカメラを参照）または
  • android.hardware.camera.front
• 同様に、アプリのマニフェストには、タブレットでは適切でない可能性がある機能要件を暗示（imply feature requirements）する <permission> 要素は一切含めないでください。ただし、android:required=”false” 属性で宣言されている当該 <uses-feature> 要素を伴っている場合はこの限りではありません。

いずれの場合でも、アプリが使用するハードウェア機能が利用できないときもアプリは正常に動作し、必要に応じてグレースフル デグラデーションや代替機能を提供できなければなりません。例えば端末が GPS 未対応の場合は、アプリがユーザーに現在位置を手動で設定できるようにします。アプリは、必要なハードウェア性能についてランタイム チェックを実施し、適宜、処理を実施するようにします。

参考資料: Permissions that Imply Feature Requirements（機能要件を暗示するパーミッション）— アプリのマニフェストで宣言した場合、望まないフィルタリングの原因となる可能性があるパーミッションのリスト。 <uses-feature> — マニフェスト要素 <uses-feature> の解説と参考ドキュメント。 Testing the features required by your application（アプリケーションが要求する機能をテストする） — アプリが要求するハードウェアとソフトウェア要件（明示的または暗示的要件）のセットを決定する方法を解説。

9. 対応しているタブレット画面構成を宣言する

幅広い種類のタブレットにアプリを配布できるようにするには、アプリが対応しているすべての画面サイズをマニフェストにて宣言します。

• 必要に応じて、適切な属性を使い <supports-screens> 要素を宣言します。
• マニフェスト内でアプリが <compatible-screens> 要素を宣言している場合は、その要素には、必ずアプリが対応しているタブレット画面のサイズ/ピクセル密度のすべての組み合わせを指定する属性が含まれていなければなりません。できれば、アプリでこの要素を使用するのは避けるようにしてください。

参考資料: <supports-screens> — マニフェスト要素 <supports-screens> に関する解説と参考ドキュメント。 Declaring Screen Size Support（画面サイズ対応を宣言する） — 複数の画面サイズでの表示を最適化するためのUI管理について詳しく説明した開発者向けドキュメント。

10. Google Play への公開に関するベスト プラクティスに従う

• アプリは、すべての画面サイズ（携帯端末とタブレット）に対して 1 つの APK として公開し、Google Play への掲載は 1 つにします。その理由は、次の通りです。
  • ユーザーが検索やブラウズ操作、プロモーションからアプリを見つけやすい
  • ユーザーが新しい端末を入手したとき、アプリを復元しやすい
  • レーティングやダウンロード統計がすべての端末での合計になる
  • タブレット用アプリを別物として公開すると、ブランドとしてのレーティングが弱まる
• 必要であれば複数の APK サポート（Multiple APK Support）を使いアプリを配布する選択肢もありますが、ほとんどの場合は 1 つの APK ですべての端末に対応することを強くお勧めします。
• • 製品詳細のページにて、次のような方法でアプリのタブレット向け機能を目立たせます。
  • アプリがタブレット上で動作しているときのスクリーンショットを最低 1 枚は載せましょう。できれば横向きと縦向きそれぞれのスクリーンショットを 1 枚ずつ載せてください。こういったスクリーンショットを載せることで、アプリがタブレット向けにデザインされていることをユーザーに明確に示せると同時に、あなたがタブレット アプリをデザインする上で力を入れた点をアピールできます。
  • アプリの説明にタブレット対応であることを明記します。
  • アプリのリリース ノートや更新情報に、タブレット対応であることを盛り込みます。
  • アプリのプロモーション動画に、アプリがタブレット上で動作している様子を加えます。
• アプリがきちんとタブレット端末へ配布されていることを確認します。Developer Console にて、アプリの対応端末リストをチェックし、対象のタブレット端末からアプリがフィルタリングされていないことを確かめます。
• タブレット ユーザーにアプリの存在をアピールしましょう。タブレットでのアプリ使用を紹介するマーケティングや広告キャンペーンを企画します。

参考資料: Publishing Checklist（公開のためのチェックリスト） — アプリの公開、テスト、Google Play での提供開始に向けてアプリを準備する際の推奨事項。 Google Play Android Developer Console — アプリを Android ユーザーに公開するためのツール コンソール。

タブレット用テスト環境を整える

タブレット上でのアプリ品質（コア アプリ、タブレット アプリ両方の品質）を評価するには、適切なハードウェアまたはエミュレーターによるテスト環境を用意する必要があります。

テスト環境には、現在ユーザーに普及している主要なフォーム ファクター、ハードウェア/ソフトウェアの組み合わせのハードウェア実機をいくつか用意するのが理想的です。市場に出ているすべての端末をテストする必要はなく、1 つのフォーム ファクターにつき 1～2 台程度で、いくつかの代表的な端末を集中的にテストします。下の表に、テストに使う端末の概要を示しています。

テスト用に実機を入手できない場合は、代表的なフォーム ファクターとハードウェア/ソフトウェアの組み合わせのエミュレートした端末（emulated devices (AVDs)）を準備します。使用するエミュレーターの推奨構成については、下表を参照してください。

基本的なテスト以上のテストを実施する場合は、テスト環境の端末やフォーム ファクターの数を増やす、他のハードウェア/ソフトウェアの組み合わせを使う、などが考えられます。例えば、中型サイズのタブレットや、ハードウェア/ソフトウェアの機能が多い（または少ない）タブレットなどを使用するのもよいでしょう。また、テストの項目数を増やしたり、複雑化したり、品質条件を増やしたりしても構いません。

表 1. 代表的なタブレット テスト環境には、下表の各行の端末（代表的なチップセット、プラットフォーム バージョン、ハードウェア機能構成を備えたもの）を 1～2 台準備するのがよいでしょう。

タイプ	サイズ	密度	バージョン	AVD スキン
7 インチ タブレット	large または -sw600	hdpi, tvdpi	Android 4.0+	WXGA800-7in
10 インチ タブレット	xlarge または -sw800	mdpi, hdpi	Android 3.2+	WXGA800

このチェックリストは Creative Commons Attributes 2.5（クリエイティブ・コモンズ 表示 2.5）ライセンスで公開しています。詳しい内容と制限事項については、コンテンツのライセンス（Content License）をご参照ください。