モバイル ソフトウェア開発ライフ サイクル
モバイル アプリの構築は、Visual Studio を起動して何かを手早く作成し、ちょっとしたテストを行って App Store に公開すれば済んでしまうほど簡単になります。すべてが半日で終わります。 さもなければ、事前のデザインを正確に行い、ユーザビリティをテストし、何千ものデバイスで QA テストを行い、ベータ ライフサイクルを十分に経て、何通りもの方法で配置することになるでしょう。
このドキュメントでは、次のようなモバイル アプリケーションの構築について基本的な考察を行います。
- プロセス - ソフトウェア開発のプロセスは、ソフトウェア開発ライフサイクル (SDLC) と呼ばれます。 モバイル アプリケーション開発に関して、SDLC のすべてのフェーズ (開始、設計、開発、安定化、展開、メンテナンス) について検討します。
- 考慮事項 - モバイル アプリケーションを構築する際には、特に従来の Web アプリケーションやデスクトップ アプリケーションと比較すると、多数の考慮事項があります。 ここでは、こうした考慮事項と、そのモバイル開発に与える影響を考察します。
このドキュメントの目的は、アプリケーション開発の初心者と上級者の両者に向けて、モバイル アプリ開発に関する基本的な質問に回答することです。 ソフトウェア開発ライフサイクル (SDLC) の間に出会うほとんどの概念について、包括的なアプローチで概要を説明します。 ただし、このドキュメントが適していない場合もあります。アプリケーションの構築をすぐに始めたい場合は、まず「モバイル開発の概要」のガイドを読んでから、このドキュメントに戻ることをお勧めします。
モバイル開発ソフトウェアのライフサイクル
モバイル開発のライフサイクルは、Web アプリケーションやデスクトップ アプリケーションの SDLC とは多くの部分が異なります。 同様に、プロセスには主に 5 つの部分があります。
- 開始 - すべてのアプリはアイデアから始まります。 通常、そのアイデアは改善され、アプリケーションの強固な基礎になります。
- デザイン - デザイン フェーズは、全般的なレイアウト、しくみなどのアプリのユーザー エクスペリエンス (UX) を定義し、その UX をグラフィック デザイナーの支援を受けて適切なユーザー インターフェイス (UI) へと調整する作業で構成されます。
- 開発 - 通常、最もリソースが必要なフェーズです。実際のアプリケーション構築が行われます。
- 安定化 - 開発が十分に進んだら、通常 QA はアプリケーションのテストを開始し、バグが修正されます。 多くの場合、アプリケーションは制限されたベータ フェーズに進みます。ベータ フェーズの場合、アプリケーションを使用し、フィードバックを返し、変更の通知を受ける機会がより多くのユーザーに与えられます。
- デプロイ
多くの場合、これらの多くの部分は重なっています。たとえば、UI の仕上げ中に開発も進行中であることも一般的で、UI デザインについて通知することもあります。 また、アプリケーションが安定化フェーズに進んでときでも、同時に新しい機能が新しいバージョンに追加されることがあります。
さらに、アジャイル、スパイラル、ウォーターフォールなど、任意の数の SDLC 方法論でこれらのフェーズを使用できます。
以下のセクションで、これらの各フェーズについて詳しく説明します。
インセプション
モバイル デバイスはあらゆる場所とレベルで利用されるので、ほぼすべての人がモバイル アプリについてアイデアを持っていると考えられます。 モバイル デバイスによって、コンピューティング、Web、さらには企業のインフラストラクチャを利用するまったく新しい方法が始まりました。
開始段階は、アプリのアイデアを定義し、改善する段階です。 アプリの作成を成功させるには、いくつかの基本的な質問に答えを出すことが重要です。 パブリック アプリ ストアのいずれかでアプリを公開する前に、考慮する必要がある事項を次に示します。
- 競争力 - 既に同様のアプリはありますか。 その場合、このアプリケーションと他のアプリケーションはどのような違いがありますか。
企業に配信されるアプリの場合:
- インフラストラクチャの統合 - このアプリと統合される、またはこのアプリで拡張される既存のインフラストラクチャは何ですか。
さらに、アプリはモバイル フォーム ファクターの文脈で評価する必要があります。
- 価値 - このアプリはユーザーにどのような価値をもたらしますか。 どのように使用しますか?
- フォーム/モビリティ - このアプリはモバイル フォーム ファクターでどのように機能しますか。 位置情報の認識、カメラなどのモバイル テクノロジを使用してどのように価値を追加しますか。
アプリの機能を設計する際には、アクターとユース ケースを定義することが役立つ場合があります。 アクターとはアプリケーション内のロールです。多くの場合はユーザーです。 通常、ユース ケースはアクションまたはインテントです。
たとえば、タスク追跡アプリケーションには、ユーザーとフレンドという 2 つのアクターがいる可能性があります。 ユーザーはタスクを作成し、フレンドとタスクを共有することがあります。 この場合、タスクの作成とタスクの共有は 2 つの別のユース ケースです。ユース ケースとアクターを合わせることで、構築する必要がある画面や、開発する必要があるビジネス エンティティやロジックがわかります。
適切な数のユース ケースとアクターを把握すると、アプリケーションのデザインをはるかに簡単に始められます。 また、アプリの内容や必要な処理ではなく、アプリの作成方法に集中して開発できるようになります。
モバイル アプリケーションのデザイン
アプリの特徴と機能が決まったら、次の手順はユーザー エクスペリエンス (UX) の解決を試みることです。
UX デザイン
通常 UX は、多くのデザイン ツールキットのいずれかを使用したワイヤフレームまたはモックアップで行います。 UX モックアップを使用すると、実際の UI デザインを心配することなく UX をデザインできます。
UX モックアップを作成するときは、アプリが対象とする多様なプラットフォームのインターフェイス ガイドラインを考慮することが重要です。 各プラットフォームで "使い慣れた感覚" のアプリになるようにします。 各プラットフォームの公式デザイン ガイドラインは次のとおりです。
- Apple - Human Interface Guidelines (ヒューマン デザイン ガイドライン)
- Android - Design Guidelines (デザイン ガイドライン)
- UWP – UWP Design basics (UWP デザインの基本)
たとえば、各アプリには、アプリケーションのセクション間を切り替える操作のメタファーがあります。 iOS は、画面の下部にあるタブ バーを使用し、Android は画面の上部にあるタブ バーを使用し、UWP はピボットまたはタブ ビューを使用します。
また、ハードウェア自体にも UX を決定する要素があります。 たとえば、iOS デバイスには物理的な戻るボタンがないため、ナビゲーション コントローラーのメタファーを導入します。
さらに、フォーム ファクターも UX の決定に影響があります。 タブレットにははるかに広いスペースがあるため、より多くの情報を表示できます。 多くの場合、スマートフォンで複数の画面が必要な機能は、タブレットでは 1 つの画面に収まります。
また、さまざまなフォーム ファクターがあるため、多くの場合、中サイズのフォーム ファクター (スマートフォンとタブレットの間くらい) を対象とすることがあります。
ユーザー インターフェイス (UI) デザイン
UX が決まったら、次の手順は UI デザインの作成です。 通常、UX は白黒だけのモックアップですが、UI デザイン フェーズでは、色やグラフィックなどが導入され、仕上げられます。 適切な UI デザインに時間をかけることは重要であり、一般的に人気が高いアプリはプロフェッショナルなデザインです。
UX の場合と同様に、各プラットフォームには独自のデザイン言語があることを理解することが重要です。また、適切なデザインのアプリケーションの外観は、プラットフォームによって異なる可能性があります。
開発
通常、開発フェーズはごく早期に始まります。 実際、概念/インスピレーション フェーズでアイデアがある程度成熟すると、多くの場合、機能と仮定を検証し、作業範囲の理解を助ける、動作するプロトタイプが開発されます。
以降、このチュートリアルでは、主に開発フェーズについて説明します。
安定化
安定化は、アプリのバグを解決するプロセスです。 "このボタンをクリックするとクラッシュする" などの機能の観点からだけではなく、ユーザビリティとパフォーマンスも含まれます。 コストが高くなる前に軌道を修正できるため、開発プロセスのごく早期から安定化を開始することをお勧めします。 通常、アプリケーションにはプロトタイプ、アルファ、ベータ、およびリリース候補の各段階があります。 人によって各段階の定義は異なりますが、一般的に次のパターンに従います。
- プロトタイプ - アプリはまだ概念実証フェーズでコア機能しかないか、アプリケーションの一部のみが動作しています。 大きなバグが存在します。
- アルファ - コア機能は全般的にコードが完成しています (ビルト済みですが、完全にテストされていません)。 大きなバグはまだ存在し、コア以外の機能はまだ存在しない場合があります。
- ベータ - ほとんどの機能が完成し、少なくとも軽微なテストとバグ修正を行っています。 大きな既知の問題が存在する場合があります。
- リリース候補 - すべての機能が完成し、テスト済みです。 新しいバグがなければ、アプリはリリース候補になります。
アプリケーションのテスト開始が早すぎるということはありません。 たとえば、プロトタイプ段階で大きな問題が見つかった場合、それに合わせてアプリの UX を変更することもできます。 アルファ段階でパフォーマンスの問題が見つかった場合、間違った前提に基づいて大量のコードを構築してしまうよりもかなり前に、アーキテクチャを変更することができます。
通常、アプリケーションがライフサイクルの中でさらに進むにつれて、より多くのユーザーが試し、テストし、フィードバックを提供することができます。たとえば、プロトタイプ アプリケーションは主要な利害関係者のみが表示または使用可能にすることができます。一方、リリース候補アプリケーションは、早期アクセスにサインアップする顧客に配布される場合があります。
比較的少数のデバイスを対象にしたテストと配置の場合、通常、開発機からの直接配置で十分です。 ただし、対象者が広がるにつれて、これは急速に複雑な作業になります。 そのため、テスト配置の選択肢は多数あります。テスト プールにユーザーを招待し、Web でビルドをリリースする機能があり、ユーザーがフィードバックを送信できるツールが用意されているため、このプロセスが簡単になります。
テストと配置には、App Center を使用して、アプリを継続的に構築、テスト、リリース、および監視することができます。
Distribution
アプリケーションの安定化が完了したら、次は配布です。 プラットフォームに応じて、さまざまな配布の選択肢があります。
iOS
Xamarin.iOS および Objective-C アプリの配布方法は、次のようにまったく同じです。
- Apple App Store - Apple の App Store は、iTunes 経由で Mac OS X にビルトされる、世界中で使用できるオンライン アプリケーション リポジトリです。 現時点で、アプリケーションの配布方法として最も人気があります。また、開発者はほとんど労力をかけずに市場に参入し、自作のアプリをオンラインで配布できます。
- 社内配置 - 社内配置は、App Store で一般公開されない、企業アプリの社内配布を目的としています。
- アドホック配置 - アドホック配置は、主に開発およびテスト目的です。適切にプロビジョニングされた少数のデバイスに配置することができます。 Xcode または Visual Studio for Mac を通してデバイスに配置する場合は、アドホック配置と呼ばれます。
Android
すべての Android アプリケーションは、配布前に署名済みである必要があります。 開発者は、秘密キーで保護された独自の証明書を使用してアプリケーションに署名します。 この証明書は、アプリケーション開発者と、開発者がビルドしてリリースしたアプリケーションとを関連付ける信頼性のチェーンとして機能します。 Android の開発証明書は、一般的に認められた証明機関が署名できますが、ほとんどの開発者はこのようなサービスを利用せず、証明書に自己署名します。 証明書の主な目的は、さまざまな開発者とアプリケーションを区別することです。 Android はこの情報を使用して、Android OS 内で実行されるアプリケーションとコンポーネント間のアクセス許可の委任を支援します。
他の人気のあるモバイル プラットフォームとは異なり、Android はアプリ配布の門戸が広く開かれています。 デバイスは 1 つの認証アプリ ストアに限定されていません。 誰でも自由にアプリ ストアを作成できます。ほとんどの Android フォンは、このようなサード パーティ ストアからのアプリのインストールを許可しています。
そのため、開発者は、自作アプリケーション用により大規模で複雑な配布チャネルを利用できます。 Google Play は Google の公式アプリ ストアですが、他にも多くのストアがあります。 人気のあるストアをいくつか紹介します。
UWP
UWP アプリケーションは、Microsoft ストアを介してユーザーに配布されます。 開発者は自作アプリを提出して承認を受けます。アプリは承認後にストアに表示されます。 Windows アプリを公開する方法の詳細については、UWP の公開に関するドキュメントを参照してください。
モバイル開発に関する考慮事項
モバイル アプリケーションの開発と従来の Web/デスクトップ開発とは、プロセスまたはアーキテクチャの観点からは基本的に違いませんが、いくつか注意が必要な事項があります。
一般的な考慮事項
マルチタスキング
モバイル デバイス上のマルチタスク (同時に複数のアプリケーションを実行すること) には大きな課題が 2 つあります。 まず、画面スペースが限られていると、複数のアプリケーションを同時に表示することは困難です。 そのため、モバイル デバイスでは、一度にフォアグラウンドに表示できるのは 1 つのアプリのみです。 2 つ目の課題は、複数のアプリケーションを開き、複数のタスクを実行すると、バッテリ電源が短時間で消費される可能性があることです。
プラットフォームによってマルチタスクの処理方法は異なるので、ここでは簡単に説明します。
フォーム ファクター
一般的に、モバイル デバイスはスマートフォンとタブレットという 2 つのカテゴリに分けられますが、その間にまたがるデバイスがいくつかあります。 このようなフォーム ファクター向けの開発は全般的にとてもよく似ていますが、アプリケーションのデザインは大きく異なる可能性があります。 スマートフォンの画面スペースは非常に限定されており、タブレットのスペースの方が大きいのですが、それでもほとんどのラップトップよりも小さな画面スペースです。 そのため、モバイル プラットフォームの UI コントロールは、小さなフォーム ファクターで効果的になるように特別にデザインされています。
デバイスとオペレーティング システムの断片化
ソフトウェア開発ライフサイクル全体で、さまざまなデバイスを考慮に入れることが重要です。
- 概念化と計画 - ハードウェアと機能はデバイス間で異なり、特定の機能に依存するアプリケーションが一部のデバイスで正しく動作しない可能性がある点に留意してください。 たとえば、カメラがないデバイスがあるため、ビデオ メッセージング アプリケーションを構築する場合、一部のデバイスでビデオの再生はできても、撮影はできない可能性があります。
- デザイン - アプリケーションのユーザー エクスペリエンス (UX) を設計するときは、各デバイスのさまざまな画面縦横比とサイズに注意します。 さらに、アプリケーションのユーザー インターフェイス (UI) を設計する場合は、さまざまな画面解像度を考慮します。
- 開発 - コードから機能を使用するときは、その機能の存在を最初にテストすることをお勧めします。 たとえば、カメラなどのデバイス機能を使用する前に、まず OS にその機能が存在することを必ず確認します。 次に、機能/デバイスを初期化するときは、そのデバイスについて OS から現在サポートされている機能を要求し、その構成設定を使用するようにします。
- テスト - 実際のデバイスで、早期に、また何度もアプリケーションをテストすることは非常に重要です。 同じハードウェア仕様のデバイスでも、動作が大きく異なる可能性があります。
限られたリソース
モバイル デバイスは常に強力に進化していますが、それでもデスクトップ コンピューターやノートブック コンピューターに比べると機能が制限されているモバイル デバイスです。 たとえば、一般的に、デスクトップ開発者はメモリ容量を心配しません。物理メモリと仮想メモリはどちらも豊富にある環境で使用されます。一方、モバイル デバイスでは、高品質の画像を少数読み込むだけで、すぐに使用可能なメモリをすべて消費する可能性があります。
さらに、ゲームやテキスト認識などのプロセッサを多様するアプリケーションは、モバイル CPU に大きな負荷がかかり、デバイスのパフォーマンスが低下する可能性があります。
このような点を考慮すると、適切にコーディングし、実際のデバイスに早期に何度も配置し、応答を検証することが重要です。
iOS に関する考慮事項
マルチタスキング
iOS では、マルチタスクは非常に厳格に制御されています。また、別のアプリケーションがフォアグラウンドに表示されたときに準拠する必要があるルールと動作が複数あります。準拠しないと、アプリケーションは iOS から停止されます。
デバイス固有のリソース
1 つのフォーム ファクター内でも、モデルによってハードウェアが大きく異なる可能性があります。 たとえば、背面カメラがあるデバイス、前面カメラがあるデバイス、カメラがないデバイスがあります。
一部の古いデバイス (iPhone 3G 以前) ではマルチタスキングを許可していません。
デバイス モデルによってこのような違いがあるため、機能を使用する前に、機能の存在を確認することが重要です。
OS 固有の制約
アプリケーションが応答し、安全であることを確認するために、iOS ではアプリケーションが従う必要があるルールを多数課しています。 マルチタスキングに関するルールに加え、特定の時間内にアプリが返す必要があるイベント メソッドも多数あります。この時間内に返さないと、アプリケーションは iOS から停止されます。
また、アプリはサンドボックスと呼ばれる環境内で実行される点にも注意してください。サンドボックスは、アプリがアクセスできる対象が制限されるセキュリティ制約が課せられる環境です。 たとえば、アプリは独自のディレクトリからの読み書きが可能ですが、別のアプリ ディレクトリに書き込もうとすると、アプリは停止されます。
Android に関する考慮事項
マルチタスキング
Android のマルチタスキングには 2 つのコンポーネントがあります。1 つ目はアクティビティ ライフサイクルです。 Android アプリケーションの各画面はアクティビティで表されます。また、アプリケーションがバックグラウンドに配置されるとき、またはフォアグラウンドに表示されるときに発生する一連のイベントがあります。 応答し、適切に動作するアプリケーションを作成するために、アプリケーションはこのライフサイクルに従う必要があります。 詳細については、「Activity Lifecycle」(アクティビティのライフサイクル) ガイドを参照してください。
Android のマルチタスキングの 2 つ目のコンポーネントは、サービスの使用です。 サービスは、アプリケーションとは独立して存在し、長時間実行されるプロセスです。また、アプリケーションがバックグラウンドで動作しているときにプロセスを実行するために使用されます。 詳細については、「Creating Services」(サービスの作成) ガイドを参照してください。
多数のデバイスと多数のフォーム ファクター
Google では、Android OS を実行できるデバイスに制限を課すことはありません。 このようにオープンなパラダイムなので、さまざまなハードウェア、画面解像度や縦横比、デバイスの特徴、機能が搭載されたさまざまなデバイスで製品環境が構成されています。
Android デバイスは過度に断片化されているため、ほとんどの開発者は、人気の高い 5 台か 6 台を選択してデザイン、テストに使用し、優先しています。
セキュリティに関する考慮事項
Android OS のアプリケーションはいずれも、制限されたアクセス許可を持つ個別の分離された ID で実行されます。 既定でアプリケーションができることはほとんどありません。 たとえば、特別なアクセス許可がなければ、アプリケーションはテキスト メッセージの送信、電話の状態の特定、さらにはインターネットへのアクセスを実行することもできません。 アプリケーションからこのような機能にアクセスするには、アプリケーション マニフェスト ファイルで、使用したいアクセス許可と、インストールされるタイミングを指定する必要があります。OS はこのようなアクセス許可を読み取り、アプリケーションからそれらのアクセス許可が要求されていることをユーザーに通知し、ユーザーがインストールを続行するか取り消すかを選択できるようにします。 これは、Android 配布モデルでは重要な手順です。というのも、開かれたアプリケーション ストア モデルであり、たとえば iOS のような方法でアプリケーションが管理されていないためです。 アプリケーションのアクセス許可一覧については、Android ドキュメントの「Manifest Permissions」(マニフェストのアクセス許可) 参考記事を参照してください。
Windows に関する考慮事項
マルチタスキング
UWP のマルチタスキングには 2 つの部分があります。ページとアプリケーションのライフサイクルと、バックグラウンド プロセスです。 アプリケーションの各画面は、ページ クラスのインスタンスであり、アクティブまたは非アクティブになる処理に関連するイベントがあります (また、非アクティブ状態または "廃棄済み" を処理する特殊なルールがあります)。
2 つ目の部分は、アプリケーションがフォアグラウンドで実行中でない場合でも、タスクを処理するバックグラウンド エージェントを提供しています。
デバイスの機能
UWP ハードウェアは比較的均質ですが、オプションのコンポーネントもあるので、コーディング時には特殊な配慮も必要です。 オプションのハードウェア機能には、カメラ、コンパス、ジャイロスコープなどがあります。 特殊な配慮が必要な低メモリ (256 MB) の特殊なクラスもあります。または開発者は低メモリのサポートを除外することができます。
セキュリティに関する考慮事項
UWP のセキュリティに関する重要な考慮事項については、「セキュリティ」のドキュメントを参照してください。
まとめ
このガイドでは、モバイル開発に関連する SDLC の概要について説明しました。 また、モバイル アプリケーションの構築に関する全般的な考慮事項の概要を説明し、デザイン、テスト、配置などのプラットフォーム固有の考慮事項をいくつか考察しました。