ビジョンを実際のアプリに落とし込むまでの9つのステップとは

誰しも「こんなものを作りたい」と思ってもアイデアが形にならないまま終わってしまった経験があるかと思います。自分の描いているビジョンを実際にアプリとして形にするための9ステップを紹介しているので、起業を考えている人はぜひご覧ください。

テックアカデミーマガジンは受講者数No.1のプログラミングスクール「テックアカデミー」が運営。初心者向けにプロが解説した記事を公開中。現役エンジニアの方はこちらをご覧ください。 ※ アンケートモニター提供元：GMOリサーチ株式会社　調査期間：2021年8月12日～8月16日　調査対象：2020年8月以降にプログラミングスクールを受講した18～80歳の男女1,000名　調査手法：インターネット調査

本稿は、Codementorのブログ記事を了解を得て日本語翻訳し掲載した記事になります。本記事は、Android OSアプリ開発者のAbinash Neupane 氏によって投稿されました。

あなたにも朝起きたときに、大ヒットして億万長者になれるような創造的なアイデアを思いついたことがあるでしょうか。未来を変えることができるようなアイデアを思くことは誰にでもあります。その中の多くのアイデアは空想に終わりますが、中には私たちの生活を大きく変えるような可能性を秘めたものもあります。

ビジョンを実際のアプリとして実現し、未来を変えるためのステップを見てみましょう！

ほとんどのアイデアが単なる「アイデア」で終わってしまうのは、適切なガイドがないためです。

アプリ開発を大量のコードを書くだけの作業だと思っている人もいますが、コードを書くことはアプリ開発の中の1つのステップにすぎません。良いアプリを開発するには、その他にも大切なステップがあります。これら9つのステップを紹介していきます。

1. 最初のステップ

最初のステップはビジョンを広げるのに役立ちます。最初のステップの前に、アプリのアイデアを考える必要があります。アイデアは整理されたものでなくても、ぼんやりとしたビジョンでも構いません。

最初のステップでは、アプリを開発する目的やゴールを定め、ゴールを達成するための計画を詳細に立てます。また、すでに似たようなアプリが世の中に存在していないか、調べておきます。

initiation-phase-android-development-620x252

下の画像はプロジェクトの計画の一例で、プロジェクトに必要となるすべてのタスク、段階、マイルストーン（プロジェクトの進捗管理のための各節目）を設定したものです。

プロジェクトによっては、チームのメンバー全員が最初のゴール、目的、価格などを把握できるように、長期的な製品ライフサイクルを見据えて「プロジェクト計画書」を作成することもあります。

app-wireframing-620x397

アプリについてのアイデアをデバイスのスクリーン上に描いておくのもいいでしょう。

また、スケッチを描くのもビジョンを明確にするのに役立ちます。アプリの主な機能、およそのレイアウトや構造などを、スケッチに描いておけば、アプリのコンセプトを視覚的につかめます。

[PR] プログラミングで挫折しない学習方法を動画で公開中

2. 要件工学（RE：Requiment Engineering）

requirements-620x213

アプリについて明確なビジョンやゴールを設定したら、次は要件工学です。

このステップでは、アプリのゴールを拡張します。アプリによって実現できることや、ユーザーにとってのメリットを定義します。

また、ターゲットとなるユーザーを設定することで、価格戦略や市場戦略に役立てましょう。プロジェクトが予算内に収まるかどうかもチェックします。アプリの開発が実行可能かどうか話し合うのもいいでしょう。

要件工学で使える「5W」の問いは多数あります。

アプリのゴールは何か？（What）
このアプリはなぜ他とはちがうのか？（Why）
誰がこのアプリを使うのか？（Who）
ユーザーはいつアプリを使うか？（When）
ユーザーがアプリから得られる最大のメリットは何だろう？（What）
ユーザーはどんな場面でアプリを使うのか？（Where）

収益

profit-from-app-620x348

アプリを開発するときには、収益を図る方法を考えておくことも必要です。例えば次のような方法があります。

有料アプリ
In-App Purchase（iOSにおいてアプリ内課金を可能とするAppleの組込みテクノロジー）
Admob（アプリの収益を高めるためのGoogleの広告サービス）
iAd（iOSのアプリ内に実装できる広告）

マイルストーン（プロジェクトの進捗管理のための各節目）

マイルストーンを設定するメリットは、タスク、開発にかかる時間などの管理が容易になることです。

スケジュール管理を時間軸ベースで把握するのに役立ちます。平均すると、AndroidやiOSのアプリ開発には約18週間（約4ヵ月半）かかります。

ワイヤーフレームとストーリーボード

app-wireframes-620x405

次のステップは、アプリの動作性を示すために、ワイヤーフレーム（レイアウト）やストーリーボード（ユーザーの利用体験を漫画のような一連の画像で表現したもの）を作成することです。最初のビジョンをよりクリアーに表現できます。

ワイヤーフレームでは開発するアプリの、モックアップやプロトタイプを作成します。モックアップやプロトタイプを作成できるアプリには、Balsamiq、Moqups、HotGlooなどがあります。

3. 技術的な指標の分析

statistics-and-analytics-620x267

次の技術的な指標について分析をします。

スケーラビリティ（拡張性）：アプリの潜在的な成長可能性
アベイラビリティ（可用性）：ダウンタイム（故障や停止などでシステムを使えない時間）を考慮した、システムの利用可能率
メンテナビリティ（保守性）：保守管理のしやすさ
モジュラーアプローチ
パフォーマンス
ポータビリティ（移植性）：例えば、AndroidやWindows PhoneなどのOSに対応したマルチプラットフォームであること
ユーザビリティ：エンドユーザーを中心に考えた開発
バージョン管理

このステップにおいては、アプリを開発するために必要なテクノロジーについて話し合います。例えば、アプリに必要なバックエンドの処理を行う技術、データベースの決定などです。SQLiteのようなデータベースを使えば、起動中のアプリを閉じても、データを失うおそれはありません。

次のようなテーマについても話し合います。

アプリのデータを格納する必要はあるか？あるとしたら、どのように格納するか？
どのようなタイプのデータベースを利用するか？
アプリは静的なのか動的なのか？
アプリに求められるセキュリティ要件は？
アプリのセキュリティの欠陥にはどのように対処するか？
サードパーティーの製品を統合するか？するとしたら何を選ぶか？
将来的にアプリの開発をさらに進めるかどうか？

分析を終えたら、次のような項目を含んだ「プロジェクト文書」を作成しましょう。

導入
問題の提示
目的
方法
予算とスケジュール
リファレンス（仕様や機能の解説）

project-documentation-620x557

4.デザイン

Rendered Look and Feel - User Experience Concept

デザインのステップでは、ワイヤーフレームを、クリーンで魅力的なユーザーインターフェース（UI）に作り変えることで、グラフィカルユーザインタフェース（GUI）を作成します。

UXデザイナーはインタラクティビティの高いデザイン要素を設計できますし、アプリの外観や使いやすさに関することはUIデザイナーに頼むこともできます。

message-app-ui-620x464

アプリストアで目立たせるためには、使いやすく高品質なデザインのユーザーインターフェースにするべきです。デザインは、ブランド戦略を考慮したものにしましょう。また、モバイル端末のスクリーンサイズの違いに応じた解像度で設計します。

5. 開発

male-illustration-engineer-620x331

この開発のステップは、主にプログラマーが分担します。開発に使うテクノロジーは、ステップ3の分析であらかじめ定めておきます。また、ステップ4で考えたデザインを取り入れて、実際のアプリへと実現します。

また、開発と並行してテストも実施して、バグやエラーの早期発見と解決に努めましょう。プログラマーは、アプリのバックエンドの処理を定めるソースコードの記述と管理も行うことになります。

OS（プラットフォーム）ごとにそれぞれソフトウェア開発キット（SDK）があります。また、アプリをどのOS（プラットフォーム）向けに開発するかによって、ネイティブ言語が決まります。

最後に、ステップ2の要件工学（RE）で作成した要件を基準にして結果を評価します。また、ステップ4のデザインの基準からも評価します。例えば、アプリケーションが実際にAndroid 2.3以降のバージョンのOSをサポートできているかを確認します。

6. テスト

why-is-testing-necessary-620x247

ここまで来たらアプリの基本は完成です！このステップでは、ターゲットとなるユーザーに試用してもらいます。このテストは、モバイルアプリの開発プロセスの中でも特に重要なものです。

テストにおいては、アプリの機能性、ユーザビリティ、整合性（コンシステンシー）などを試して、もし問題があればアプリを公開する前に修正します。

テストの手法にはいろいろなタイプがあります。例えば、Android Studioで提供されているテストツールなどを利用できます。ここではテストの一般的な手法について述べます。

自動テスト

自動テストはアプリの開発中に行われます。自動テストは、アプリがデバイス上で動くかどうか、またコードが機能するかどうかを確かめることが目的です。

単体テスト（ユニットテスト）や統合テスト（インテグレーションテスト）も、自動テストの一部です。

ユーザ受け入れテスト（UATテスト：User Acceptance Testing）

alphabetatestingphase

ユーザ受け入れテストとは、開発したアプリをユーザーが利用できるか試すプロセスです。ターゲットとなるユーザーの何人かに実際にアプリを試用してもらいます。

アプリがこのユーザー受け入れテストに合格したら、今までの設計が現実的に機能していると確かめられたことになります。ユーザー受け入れテストはアルファテストとベータテストから構成されます。それぞれ見ていきましょう。

アルファテスト（Alpha Testing）

アルファテストは、アプリの開発に関係したユーザーにアプリを試用してもらうことで行います。つまりこの場合のユーザーとは、アプリに使われているテクノロジーや、アプリの機能をあらかじめ知っている人物です。

ベータテスト（Beta Testing）

ベータテストは、アプリに使われているテクノロジーを知らない、いわば実際のユーザーにアプリを試用してもらうことで行います。ベータテストを実施する意味は、アプリが現実の利用環境で上手く機能するかを試すことです。

7. アプリの公開

google-play-store-3-620x387

ここまで上手く行ったら、次のステップはいよいよアプリの公開です！このステップでは、アプリを各OSのストアに公開します。AndroidアプリはGoogle Play、iOSアプリはApp Storeの各ストアへアップロードします。

Google Playにアプリを公開するには、25米ドルの登録料が必要ですが、登録後はデベロッパーアカウントでアプリをいくつでも公開できます。App StoreにiOSアプリを公開するには、Apple Developer Program への参加料金として99米ドル支払う必要があります。

8. 保守管理（メンテナンス）

アプリをストアに公開してユーザーがアプリを使い始めたら、次はアプリの保守管理（メンテナンス）を継続的に行います。ユーザーのニーズと期待に応えられるような保守管理をしましょう。

ユーザーからのフィードバックは、ユーザーがどのようにアプリを使っているかをよく理解するために大切なもので、アプリ解析ツールのソフトウェアが役に立ちます。ダウンロード数だけでなく、どんなユーザーがいつ、どこで、どのようにアプリを使っているかが分かります。

feat-hed-mobile

ユーザーのアクセス経路
アクティブユーザー率（Activation percentage：利用頻度が高いユーザーの率）
リテンション率（Retention percentage：ユーザーの再訪率）
リファラル（Referral：ユーザーがアプリにアクセスするきっかけとなったリンク元）の有無

などを知ることができます。アプリ解析ツールは、ステップ6のテストの段階から導入するのがいいでしょう。

人気のある解析ソフトウェアです。※（）は主な対応OS、開発環境、言語など

Apsalar (iOS、Android)
Flurry (iOS、Android、Windows Phone、Blackberry、Java ME)
Mixpanel (iOS、Android)
Google Mobile Analytics：Googleモバイルアナリティクス (iOS、 Android)
Localytics：ロカリティクス (iOS、Android、Windows Phone、Blackberry、HTML5)
Countly (iOS、Android、Windows Phone、Blackberry)

アプリのパフォーマンスを追跡することで、必要があれば修正を加えることができます。

また追加のサポートが必要かどうか通知してくれるサービスもあります。解析によって、アプリの評価やユーザーのフィードバックもモニタリングできます。

9. マーケティング

featimg_mobile-app-marketing-620x280

アプリの開発が完了したら、アプリを効果的に市場に売り出しましょう。アプリの開発と同時並行して段階に応じて、広告やマーケティングを行いましょう。広告とマーケティングの2つがこのステップの要です。

あなたの開発したアプリを、ストアにあるその他無数のアプリから目立たせることが重要です。アプリのダウンロード数を増やす方法には、Googleアドセンスなどがあります。他のアプリ内の広告で、あなたの開発したアプリを宣伝することができます。

結論

今回はライフサイクルを考慮したアプリ開発の主なステップを紹介しました。

これらの9つのステップについて正しい知識を備えれば、アプリの開発に成功できます。また、必要であればいつでもその道のエキスパートにアドバイスを求めるといいでしょう。

[お知らせ]TechAcademyでは初心者でも最短4週間でエンジニアになれるオンラインブートキャンプを開催しています。アプリ開発からWebサービスの開発、UI/UXデザインなどアイデアを形にしたいと思っている方は、ぜひご覧ください。

React Nativeとネイティブアプリでの開発の違いとは

本稿は、Course Reportのブログ記事を了解を得て日本語翻訳し掲載した記事になります。本記事は、TurnToTechのAditya Naraya...

スマートフォンアプリ開発

【Webサイトをアプリに変換！】誰でも簡単に「Joren」でアプリが作れる！

自分で持っているWebサイトをアプリにできるサービス「Joren」が登場しています。 WebサイトのURLを入力することで、スマホアプリを簡単に作成できる...

スマートフォンアプリ開発

【プログラミング要らず！】初心者でも使える！スマホアプリが開発できるおすすめツール11選

自分でプログラミングしなくてもスマホアプリを開発できてしまうツールがあることをご存知でしょうか。今回紹介するツールを使えば手軽にスマホアプリ開発をするこ...

スマートフォンアプリ開発

マネタイズ手法を徹底比較！モバイルアプリ市場の現在とこれからのトレンド

本稿は、Smashing Magazineのブログ記事を了解を得て日本語翻訳し掲載した記事になります。本記事は、instinctools EE Labs...

スマートフォンアプリ開発

ASOの施策にも役立つ！App StoreとGoogle Playを徹底比較

本稿は、Eminesoftのブログ記事を了解を得て日本語翻訳し掲載した記事になります。本記事は、Eminesoftの編集長でありマーケターのEllina...

スマートフォンアプリ開発

あわせてよく読まれている記事

マネタイズ手法を徹底比較！モバイルアプリ市場の現在とこれからのトレンド

本稿は、Smashing Magazineのブログ記事を了解を得て日本語翻訳し掲載した記事になります。本記事は、instinctools EE Labssのビジネス開発マネジャーのStacy Golmack氏によって投稿されました。モバイルアプリの市場は、ジャックの豆の木よりも急速に成長しています。業界の規模は大きく、毎日成長し、終わりは見えません。予測通り、iOS/Androidエンジニアの人口は急増し、市場に出回っているモバイルアプリの数も増え続けています。世界規模で見ても、モバイルアプリ業界の収益は急増しています。ハイブリッド型の収益モデル（アプリ内広告やアプリ内購入など）は、ビジネスの世界で急速に普及しています。多くの調査は、アプリ内広告が今後のモバイル成長の鍵となることを示しています。この記事では、以下の疑問について明らかにします。統計データと専門家の意見に裏付けされた、包括的な答えを導いています。平均的に、モバイルアプリはどれくらいの収益を生み出しますか？実際に平均収入は増えますか？今日、モバイルアプリ業界が直面している最大の課題は何ですか？今日、市場で最も一般的な収益モデルは何ですか？その中で、今後も成長が予測できるモデルは？どのモデルが生き残るでしょうか？モバイルアプリ市場には成長の見込みがあります App Annieが2015年に報告したレポートによると、モバイルアプリケーション業界は総年間収益が4.4兆円を突破し、5.5兆円まで増加すると予測されています。また、Statistaによると、年間総収入は2020年までに20兆円を超えると予測されています。リサーチ主体によって数字は多少異なりますが、全体像として、市場は決して飽和状態にはないということが示されています。 Forresterのレポートを参照したApp Annieの予測によると、2016年末までにスマートフォンを所有する人は、世界人口のわずか46％です。つまり今話題のモバイル革命は始まったばかりであることを示しています。消費者は企業よりも急速に進化しています。今日、モバイルインターネットは多くのユーザーにとって必要不可欠なものとなっています。アプリの人気に関しては、アグリゲータのアプリが、最上位に移行する可能性が高いです。アグリゲータとは、多数のオンラインリソースからコンテンツを引用して、それらをインターフェース上に見やすくまとめるツールです。コンテンツは、速報ニュースからユーザーの関心のあるニッチな分野に至るまで多岐にわたります。アグリゲータは、多数のWebサイトにアクセスしたり、多数のアプリをインストールする時間や余裕がないユーザーを対象としています。有名なアグリゲーターアプリは、Flipboard、News360、Feedly、IFTTTなどです。アグリゲータのアプリが、ショッピング体験を便利にするものである場合、ユーザーのお気に入りになる傾向があります。たとえば、Facebookはメッセンジャー（Messenger）によってこれを行いました。ユーザーは自分のニュースフィード広告を読んで、たとえばUberの配車を依頼できるのです。金持ちプラットフォーム、貧乏プラットフォームモバイルアプリの2大巨人、AndroidとiOSは、世界のスマートフォン市場を支配しています。 Gartnerの調査によると、2016年の第3四半期には、世界中で販売されているスマートフォンの87.8％がAndroidでした。この数字は、前年比で3.1％の増加です。一方、iOSの市場シェアは11.5％で、2015年比で2.5％の減少です。これらの成長は他の市場プレイヤーの地位を大幅に低下させました。スマートフォンデバイス市場の0.4％を占めていたWindowsは、モバイルプラットフォームの競争では3位となり、シェアは年率2.5％で減少しています。アップルとGoogleは、最大で最も人気の高いアプリストアを持っています。今のところ、アプリケーションやエンジニアの数において、他の競合他社がこれらのストアに対抗できる見込みはありません。 InMobiは、アプリの55％は、収益が10万円未満であると推定しています。さらに、世界中のアプリの3分の1が、製品の合計ダウンロード数が10,000に達していません。収益の格差はAndroidエンジニアの間で顕著であるのに対して、iOSデベロッパーの間ではより収益分配のバランスが取れています。2016年以降、iOSエンジニアの25％以上は毎月の収益が50万円を超えています。一方、Androidエンジニアで同様の収益を達成したのはわずか16％です。モバイルOSごとの月間平均収入を推定した興味深い統計があります。Forbesは、iOSは月平均で40万円を稼ぎ、2位のAndroidは12万円、3位のWindows Phoneは6万円程度を稼ぐと推定しています。しかし、Statistaの調べによると、この推定に反して2016年は、Windows Phoneアプリでは125万円、iOSアプリでは約90万円、Androidでは約50万円の月間平均収入が得られています。また、エンジニアの約75％は、Androidを最も好んでいます。彼らは、Androidベースの製品を開発することで収入を増やすことを考えています。 [PR] プログラミングで挫折しない学習方法を動画で公開中モバイルアプリの概観高性能のモバイルCPUは、強力なグラフィック、高品質なディスプレイ、高速インターネット接続を備えることにより、スマートフォンをゲーム機に変えました。 App Annieのレポートによると、モバイルゲームは2011年にはモバイルアプリの収益全体の50％未満を占め、2015年にはモバイルアプリの市場収益の85％を生み出しました。この数字は、世界規模では約3.7兆円に相当します。しかし、ユーザーが他のカテゴリのアプリに費やす時間も急激に増加しています。ゲームアプリ以外のアプリは、アプリ使用時間において、ゲームアプリを追い抜いています。 Flurry Analytics Blogによると、2015年後半までにモバイルアプリの市場には、次のような変化が起きました。カスタマイズアプリ（ランチャー、アイコン、壁紙、ロック画面、デバイスカスタマイズアプリなど）が1位になり、セッションの使用率は332％上昇しました。新聞や雑誌のモバイル版アプリが2位で、135％の成長となりました。生産性向上ツールとアプリは使用率において3位で、125％の成長となりました。ライフスタイルとショッピングのソリューション関連のアプリは81％の成長で、4位となりました。メッセンジャー、ソーシャルアプリ、旅行、スポーツ、健康、フィットネス関連のアプリは、53％から54％に増加しました。ゲームは、ユーザーの使用時間が1％減少した唯一の例外です。収益モデル現在、収益モデルには主に6つのタイプがあります。ダイレクトセールス（直販）ユーザーが有料アプリをまだ購入していない場合、スクリーンショット、説明、動画を、画面上にプレビューします。これらを利用することで、ユーザーにアプリの購入を促し、製品のデモンストレーションを行うことができます。しかし、ダイレクトセールスによってユーザーに購入を決心させるのは困難です。このことは、収益性が最も高いアプリのリストに、有料アプリは入っていないという統計結果にも示されています。有料アプリは人気を失っている唯一のアプリですが、一部のケースではまだその価値が証明されています。たとえば、Minecraft Pocket Editionは、Google Playストアで最も利益を上げている有料アプリです。 2011年に正式にリリースされたMinecraftは、サンドボックスのビデオゲームで、ダウンロードごとに840円で販売されいます。フリーミアム（Freemium）フリーミアム（Freemium）の収益モデル（「無料」と「プレミアム」の組み合わせ）では、ユーザーは無償で基本機能を利用でき、1回限りまたはそれ以降は有料でプレミアム機能を利用できます。そのため、この収益モデルを利用するアプリは、可能な限り多くのダウンロード数を確保することに重点を置いています。フリーミアムモデルはその潜在的な搾取メカニズムについて強く批判されていますが、慎重に利用すれば優れた効果を発揮します。その例はClash of Clansです。サブスクリプション（月額課金）サブスクリプションの収益モデルは、フリーミアムと似ています。違いは、ユーザーは特定の機能だけでなく、アクセスするすべてのコンテンツについて料金を支払うことです。この収益モデルは、顧客ロイヤリティを高く保つことができれば、予測可能で長期的な収益フローを生み出します。この収益モデルを利用した優れたアプリの例は、認知心理学者が脳を訓練するために設計した、50以上の練習問題のあるLumosityです。 Lumosityは、月額（11.99ドル(約1,200円)）と年額（59.99ドル(約6,000円)）の定期購読のオプションを提供しています。 Lumosityは93,000人以上のユーザーから5つ星の平均評価を得ており、購読アプリ部門における驚異的な成功例といえます。アプリ内課金アプリ内課金は、モバイルゲーム、購入商品について料金を請求する商品カタログアプリで、特に一般的です。この収益モデルは柔軟性が高く、ゲームアプリの中にはユーザーに購入を促すものもあります。 2016年2月現在、Tech Timesによると、モバイルゲームのユーザーの約1.9％がアプリ内購入を行い、この数字は着実に増加しています。例として、ユーザーが特定の商品やサービスを購入できるソーシャルアプリであるMeetMeがあります。 MeetMeでは、料金を支払ってプロフィールのビューを増やすことができます。このアプリの開発者は、明確な収益モデルを持っていることで、相当な収入を得ることに成功しています。クラウドファンディングクラウドファンディングは、比較的新しい収益モデルです。アプリの開発者は、KickstarterやIndiegogoなど人気のあるオンライン上のプラットフォームで、アプリのアイデアを提示し、出資を募ります。興味深いプロジェクトであれば、当初募集した額より数倍高い資金を集めることもできます。スタートアップのShadowは理想的な例です。このプロジェクトでは、3,784人の支持者から82,577ドル(約900万円)の資金を集めています。 Shadowは、報酬とプロジェクトに対する独占権も提示して、睡眠と夢を記録するソフトウェアのクラウドファンディングに挑戦しました。 Shadow会員専用のカードを渡された人は、基本的にアプリを無料で利用できますが、利用価格が8ドルに上昇したときには、これを約2万ドルで売却できます。スポンサーシップスポンサーシップは、新しい収益モデルです。ユーザーは、報酬の見返りとして広告スポンサーになります。報酬は開発者にも分配されます。この収益モデルはまだ黎明期にあるため、マーケティング戦略を磨く必要があります。 RunKeeperは、4,500万人以上のユーザーからなるコミュニティを持ち、スポンサーシップを利用したビジネスモデルの素晴らしい例です。ユーザーは、一定の距離をランニングするか自転車で走ると、報酬を受け取ります。広告主がユーザーに支払います。開発者は、迷惑な広告を掲載していないことについて高く評価されるでしょう。広告による収益化これは最も一般的な収益モデルであり、詳しく検討する必要があります。人気の理由は明らかです。ユーザーには無料アプリをダウンロードしたいという需要があり、ダウンロード数が増加するほど開発者の収益も増加します。 IHS Markitのレポートによると、2020年までに、アプリ内広告は年間5.8兆円の市場規模に達すると予想されています。これはモバイルデバイス上の全広告収入の約63％に相当します。他のセクターと同様に、広告ベースのアプリを開発している少数の主要な開発者が、収益の大部分を生み出しています。他の大多数の開発者は、残りの取り分を分け合わなければなりません。 Klick Healthによると、首位はFacebookで、Facebookのアプリには全モバイル広告の44.3％が表示されています。ランキングにおける他の企業は、Alibaba、Google、Tencent、Twitter、Pandora、Yahooです。最高額の広告収入を得ている企業は、しばしば主要な広告スポンサーになります。この傾向は特にモバイルゲームのアプリにおいて顕著です。 Rovio、Gameloft、Disneyなどの最大のベンダーは、比較的人気の低い数百のインディーゲーム製品内で、自社のゲーム製品を宣伝しています。まとめすでに見たように、モバイルアプリ市場の急速な成長はすぐには止まらないと予測できます。競争は激化しているにもかかわらず、開発者は新しい収益モデルを活用して、ユーザーにとってより面白くより便利なソリューションを創造しています。少なくとも2つの新しい収益モデルは効果が高いことが明らかになり、ここ数年で人気が高まっています。上記の収益モデルはどれも効率的です。開発者や発行者は、ケースに応じてこれらの収益モデルを導入することに熟練しています。たとえば、購読モデルは特定のニッチでのみ機能しますが、最も収益性の高いモデルです。また、潜在的に悪意があると批判されているフリーミアムの収益モデルは、慎重に使用すれば優れた効果を発揮します。Clash of Clansがその完璧な例です。有料アプリは、急速に人気を失っている唯一のアプリですが、一部のケースではまだその価値が証明されています。ハイブリッド型の収益モデル（アプリ内広告やアプリ内購入など）は、ビジネス界で特に人気を集めています。多くの調査によって、アプリ内広告は今後のモバイル成長の鍵となることが示されています。今日、iOSとAndroidは主要なモバイルOSであり、大手のモバイルアプリストアを保有しています。時が経てば、モバイルアプリ市場がどのように発展するか明らかになるでしょう。市場の動向からは、市場は将来的にも、より高い収益を生み出し続けると予測できます。今話題のモバイルアプリ革命は始まったばかりです。 TechAcademyでは初心者でも最短4週間でオリジナルアプリが作れるiPhoneアプリ開発オンラインブートキャンプ、Androidアプリ開発オンラインブートキャンプを開催しています。期間中は現役エンジニアのメンターが毎日学習をサポートするので、独学よりも効率的に学ぶことができます。

スマートフォンアプリ開発

要件定義書の作成手順を学ぶ！アイデアを形にするプロセスとは

本稿は、Smashing magazineのブログ記事を許可を得て日本語翻訳し掲載した記事になります。本記事は、モバイルアプリ開発の会社のCEO Eduard Khorkov氏によって投稿されました。なぜ要件定義書を書くのでしょうか。仮にあなたがモバイルアプリをプロデュースしたいと思っていながら、プログラミングスキルがないとします。そのためあなたは、アプリを作成することができる開発者を見つけ、その人にアイデアを説明します。最初に開発者にアプリを見せてもらったとき、意外にもあなたが望んでいたものと違うのに気付きます。なぜでしょうか。それはアイデアを説明するときに充分な説明がされていなかったからです。このような事態を防ぐため、アイデアを形式化してはっきりした姿にする必要があります。そのための一番の方法は要件定義書を書き、開発者と共有することです。要件定義書は開発プロセスの結果をあなたがどのように見ているかを示し、それによってあなたと開発者は同じ認識を持つことができます。この記事では要件定義書を作成するための最も一般的な方法を説明します。モバイルアプリケーションの要件定義書を書くための基本的な手順と、良い要件定義書はどのようなものなのかを学びます。どのように要件定義書作成に着手するか入念に作成された要件定義書は、不明確な点を排除し、開発者が何をするべきかをはっきりとさせます。さらにその文書は作業の範囲を明確にし、開発者は必要な時間と労力を見積もることができます。どのように文書を作成するのでしょうか。以下は、要件定義書を作成する際に守るTIPSです。 1. 総括的なアイデアを説明するアイデアに関する適切な説明は1つの文でまとめることができます。その文章にはアプリケーションの中心となる機能が書かれており、読んだ人はアプリケーションの内容をすぐに理解することができます。例えば、カロリー・トラッキングを行うモバイルアプリケーションの場合なら「カロリー消費量を統計分析して体重を気にする人を支援するアプリ」という風にすることができます。 2. 順番を考えるナビゲーションの基本パターンを学び、そのアプリケーションについてユーザーが実際に体験する順番通りに説明します。アイデアの要素が完成したら、オンボーディング画面やユーザー登録などアプリケーションの最初の手順を説明します。続いてアプリケーションのホーム画面などの部分に進みます。文書を読んだ人は、実際にユーザーがどのように操作を進めるかということを理解することができます。プライバシーポリシーや「パスワードを忘れたとき」などの基本的な機能や画面のことを忘れないようにしましょう。 3. 既存のアプリケーションを調査する App StoreとGoogle Playの既存アプリケーションを調べて、アプリの説明の際に参照してください。アプリAとアプリBの「パスワードを忘れたとき」機能が好きな場合は、それを文書内で説明します。 4. 細かい部分は省くアプリケーションの機能に焦点を合わせ、ボタンの色などの詳細は省略します。ほとんどのユーザーは細かい所を気にしません。ユーザーにとって関心があるのはそのアプリケーションが問題を解決するのに役立つかどうかです。要件文書を作成するときは、ユーザーがアプリで何ができるかということに集中して書いてください。 5. 機能の優先順位を決めるどの機能が他より重要かを伝えることで開発者は最初に何に焦点を当てるべきかを知ることができます。「Must（必須）」、「Should（推奨）」・「Could（可能）」・「Won’t（先送り）」のMoSCoWメソッドに従います。 6. テキストをワイヤーフレームで補うアプリケーション画面のワイヤーフレームを作成し、テキストに添付します。4つ以上のワイヤーフレーム画面がある場合、マップを作ると効果的です。この記事の後半でスクリーンマップについて説明します。要件定義書のフォーマット要件を記述する方法が分かったら、ドキュメントの適切なフォーマットを選びましょう。モバイルアプリの要件を記述するための基本的なフォーマットとして機能仕様書（FSD）・ユーザーストーリー・ワイヤーフレームなどがあります。機能仕様書（FSD） FSDはおそらく、ソフトウェア開発業界においてデフォルトのフォーマットです。製品が何をするべきか、どのようにするべきかを取り扱う標準的な項目リストで構成されています。簡単な電卓アプリケーションを例として、その機能をFSDで説明してみましょう。アプリケーション画面には基本的な算術計算ボタン(加算・減算・乗算・除算)と結果ボタン(「＝」で示されている)が追加されたデジタルキーボードが表示されます。数字ボタンをタップすると、その内容が画面内のディスプレイ部分に表示されます。新しい桁の数字は右側に追加されていきます。算術計算ボタンをタップすると、現在ディスプレイ部分に表示されている数字がメモリに与えられます。また、次の数値入力のためにディスプレイ部分はクリアされます。結果ボタンをタップすると、それまでの操作に従ってメモリ内の数値と表示されている数値が結合されます。結果の数値がディスプレイ部分に表示されます。このように機能仕様書のフォーマットでは、開発とビジネスの両方で使用されるため製品の詳細な説明が書かれています。そのため皆が同じ認識を持つことができます。 FSDを作成する人は、ソフトウェア開発の経験が豊富で構築しているモバイルや他のプラットフォームの仕様を知っている必要があります。また、要求される詳細レベルが高いため、完成させるのにはかなりの時間がかかります。ユーザーストーリーユーザーストーリーはFSDほど正式なものではありませんが、強力なフォーマットです。ユーザーがアプリでできることをリストにし、ユーザー観点から記述します。この文書ではユーザーがなぜそれをしたいのかを簡単に説明します。電卓の例で、いくつかの機能を追加しユーザーストーリーで説明してみましょう。ユーザーとして、非常に小さい数値や非常に大きな数値を取り扱うために10進数から指数関数に（またはその逆も）数値の表記を変更できるようにしたいと思っています。ユーザーとして、同僚と共有するために計算の履歴をPDFファイルで出力したいと考えます。この形式は技術的な要件の概要だけでなく、優れた投資対効果検討書も生み出します。そのため、ビジネスにとって重要でない機能が特定されている場合はその機能を取り除くか、将来のリリースに先送りにするかを決めることができます。ユーザーストーリーのフォーマットを利用すると、1つのストーリーから複数のサブストーリーに分割して詳細を定義することができます。例えば、PDFエクスポートのストーリーから以下のように分割することができます。ユーザーとして、画面の右上にある共有ボタンをタップしてオプション（PDF・テキスト・画像で共有）を表示させたいと思っています。共有オプションを選択したときに、iOSのDate Pickerを使用して共有される計算のタイムフレームを選択したいです。ユーザーストーリーは簡単で柔軟性があるため、最も便利で一般的なフォーマットのひとつになっています。スケッチとワイヤーフレームアプリケーションの要件を説明する他の方法は、スケッチあるいはワイヤーフレームでそれらを視覚化することです。 iOSの開発では、開発期間の約70％がインターフェイスの実装に費やされるため、すべての画面を目の前に置いておくことで何をするべきであるのかという作業の範囲が分かるようになります。モバイルアプリケーション用の適切なワイヤーフレームセットを作成するためには、画面を相互にリンクする方法・各画面に表示できる状態・プッシュ通知から開いたときにどのように動作するかというユーザー体験の基本を知っておく必要があります。フォーマットを融合させる適切に融合することでそれぞれのフォーマットの強みを生かすことができます。私たちの経験では、ユーザーストーリーとワイヤーフレームを混合させることが最も理にかなっています。ユーザーストーリーはアプリケーションの機能を説明し投資対効果検討書を規定しますが、ワイヤーフレームはこれらの機能がアプリケーションの画面にどのように表示されるかを示します。さらにユーザーストーリーとワイヤーフレームを混合させるのはFSD作成よりも時間がかからない上に、その相互作用の詳細と説明はすべてまとめられた状態になります。まず、アプリケーションのワイヤーフレームをスケッチすることから始めましょう。ワイヤーフレームが完成したら各画面に2つ以上のユーザーストーリーを追加し、ユーザーがその画面上で何ができるか説明します。私たちはこの方法がモバイルアプリケーションの開発に最も適していることを発見しました。 [PR] プログラミングで挫折しない学習方法を動画で公開中練習してみましょう What I Eatアプリケーションを例として取り上げます。アプリケーションを一から開発しているというシチュエーションで要件定義書を作成してみましょう。まず、スティーブ・ブランクのXYZパターン「ZによってXがYするのを支援する」を使ってアイデアを形にしてみます。そのアプリケーションの前提はユーザーが一日に食べるものとカロリー摂取量をコントロールできるようにすることです。XYZメソッドで置き換えると「What I Eatアプリケーションは、簡単な食事履歴の機能によって体重を気にする人がカロリー消費をトラッキングするのに役立ちます」となります。前述の通り、ユーザーストーリーとワイヤーフレームを融合させるのが一番効果的です。次にWhat I Eatアプリのユーザーストーリーを各画面ごとに記述します。まずアプリケーションの開始・ホーム画面から始めましょう。ユーザーとして、アプリを開いてすぐに今日の食事の記録と消費カロリーを見たい。今食べた食事とそのカロリーを、すぐに追加したい。アプリ内のカレンダーにアクセスして、それまでの履歴を表示したい。あいまいさを回避するために、この画面のワイヤーフレームを作成します。ホーム画面に「新しい食事を追加」機能を入れることはできませんでした。代わりに、この機能を行う別の画面に移動するためのボタンを付けます。ここで、この新しい画面についてのユーザーストーリーをまとめます。今食べた食事の名前を入力したい。そのカロリーも入力したい。ホーム画面にはカレンダーを開くボタンがあります。色々なカレンダーアプリがあるので、まずそれらのデザインをチェックするといいでしょう。iPhoneのデフォルトカレンダーアプリがお気に入りなので、ここではそれを参考にします。ユーザーとして、今日の日付をすぐに選択したい。日付を選択すると、iPhoneのカレンダーアプリのようにその日の食事のリストが表示されるようにする。次の月、または前の月に切り替えられるようにする。 iPhoneカレンダーのユーザーインターフェイスをワイヤーフレームに配置します。最後に、アプリにいくつかの設定を追加する必要があります。食事記録のためのiCloudバックアップの有効・無効を切り替えたい。カロリー摂取量をトラッキングするリマインダーの有効・無効を切り替えたい。これで、ほぼ完了です。最後のステップではワイヤーフレームとユーザーストーリーをひとつのドキュメントにまとめ、各ワイヤーフレームとそれぞれのストーリーを配置します。さらに、それぞれの画面がどのように繋がっているかを視覚化するマップを描くこともできます。マップを作成している際に設定画面に移動するボタンがないことに気付いたため、ホーム画面に追加します。まとめここでは、ユーザーストーリーとワイヤーフレームを含むPDFと、それを補完するスクリーンマップを作成しました。これらによってアプリケーションに必要とされている機能が詳細に説明できます。これで要件定義書を開発者に送ることができる状態になります。今度は、開発者の作成したアプリケーションはあなたの思っていたものになるでしょう。一般的に言えば、要件定義書を書くことはあなたのビジョンを他のチームに伝えることです。上記の方法だけに限定せず、自由に試みて一番いい解決方法を見つけてください。 TechAcademyでは初心者でも最短4週間でオリジナルWebサイトを公開できるWebデザインオンラインブートキャンプを開催しています。現役のWebデザイナーがパーソナルメンターとして受講生に1人ずつつき、マンツーマンのメンタリングで学習をサポートし、最短4週間でオリジナルWebサイトを開発することが可能です。独学に限界を感じている場合はご検討ください。

Webデザイン

事例から学ぶ！HubSpotがサイト改善に成功したUX戦略とは

本稿は、UXPinのブログ記事を了解を得て日本語翻訳し掲載した記事になります。本記事は、UXPinのコンテンツ・ストラテジストであるJerry Cao氏によって投稿されました。 UXデザイナーのAustin Knight氏率いるチームが、Hubspotのサイトをリニューアルしたプロジェクトについて書かれています。 HubSpot（ハブスポット）のサイトは、世界の90カ国以上にわたり1万8000以上の企業にサービスを提供し、月間400万人以上のユーザーがアクセスしています。 HubSpotにとって、サイトこそ経営の要となるものでした。HubSpotが非公開会社から、多様な製品を提供する世界規模の公開会社へと発展するには、サイトのリニューアルが不可欠でした。サイトリニューアルのプロジェクトは、プロジェクト開始から一ヵ月半後に開かれる、HubSpotの年次イベント「INBOUND」で新しい製品ラインがリリースされるまでに、急いで完成させる必要がありました。 UXデザイナーのAustin Knight氏がこのプロジェクトを率いて、3つのチーム（ビジュアルデザイナー、デベロッパー、マーケティングマネジャー）が加わりました。またKnight氏はこの他に、製品のポジショニング戦略（product positioning）、コピーライティング、技術開発を担当する外部の6つのチームとも協力しました。この記事では、UXデザイナーが、過密なスケジュールのプロジェクトにおいて、リサーチ、共同作業、ユーザーに焦点を当てた「Lean UX」という手法を応用しながら、どのように良い結果を生み出せたのかを事例として紹介します。画像：HubSpotのリニューアルされたサイト次の3つのステップは、実際のプロジェクトをベースとしてUXPinが作成したベストプラクティスです。ステップ1：入念なリサーチ、継続的なテスト HubSpotのプロジェクトは、まず最初に、Knight氏が「Lean UX」という手法をチームに紹介することから始まりました。「Lean UX」とはJeff Gothelf氏によって提唱されている手法で、継続的な「学習ループ」（構築 – 評価 – 学習のループ）を用いてデザインプロセスを軽量化することによって、ビジネス戦略を整えるためのものです。このプロジェクトでは、ステップ1は、分析とユーザー調査を行い、手早く予測の検証を行うことでした。分析＆ヒートマップ多くのケースにおいては、デザインチームはマーケティング部門にデータ分析を依頼するのが一般的ですが、今回のプロジェクトでは、Knight氏は自らデータ分析を始めました。HubSpot、Googleアナリティクス、Mixpanelから膨大なデータにアクセスできました。主な課題は、これらの膨大なデータを分析して、意味のあるパターンを見つけ出すことでした。 Knight氏はまず、多くのユーザーの行動を分析した結果、次のような傾向が見られることに気づきました。サイト上でPRICING（価格表）に最初にアクセスする（ユーザーは製品のメリットよりも価格を優先していることがわかります。）サイト上でFAQ（問い合わせ）に最初にアクセスする（ユーザーの疑問が解決されていないことがわかります。）サイト上でサイト内検索を最初に利用する（主に製品について不明な点を検索しているので、ユーザーが必要な情報をサイトで得られていないことがわかります。）この分析から、HubSpotのサイトは完成度は高いものの、重要な情報が欠けているために、コンバージョン率が低下していることが判明したのです。 Knight氏はまた、2万5000人のユーザーを対象に、ヒートマップとスクロールマップによる分析を行い、合計46万7308のデータを集めました。数年分のデータを集めることができたため、問題（例として、ユーザーの25%しかサイトのページをスクロールしていないことなど）が生じた原因を理解するのに役立ちました。セッションの記録最後に、セッションの記録によって、定量分析と定性分析を行いました。セッションの記録は、生きた、匿名性のある、未だ分析されていないデータです。実際のユーザーの行動がそのまま反映されたデータなので、分析結果も信頼できます。セッションの記録は、デザインプロジェクト全体を通して行い、ユーザーへのインタビューやユーザビリティテストの結果を検証するのに役立てます。定性分析定量分析は何（What）を分析するのには役立ちますが、なぜ（Why）を知ることはできません。ユーザーエクスペリエンスに期待されることや、行動に隠された動機を知るためには、デザイナーはユーザーと利害関係者にインタビューを行う必要があります。 1. ユーザーへのインタビュー HubSpotのサイトの利用者の10%は、ログインや情報検索をしているユーザ―であるため、サイトのリニューアルにあたっては、これらの特定のグループを無視することはできません。データの分析結果を検証するためだけではなく、新しいサイトでどのようなコンテンツを提供するべきかのアイデアのヒントを得るために、Knight氏はユーザーへのインタビューを行いました。ユーザーへのインタビューのプロセスを徹底して考えたことで、的を絞って意見を集めることができました。 2. 利害関係者へのインタビューこのプロジェクトによってHubSpotのサイトの外観が根本的に変わることになるため、Knight氏はまた、HubSpotの会社の取締役、製品、マーケティング、セールス、カスタマーサポートのチームにもインタビューを行いました。次にKnight氏は、ユーザーへのインタビューから得られた意見、カスタマーサポートの記録、HubSpotのサイトのリニューアルの不要な原案、Twitterのツイート、電子メール、さらにはKnight氏自身の講演イベントでの参加者との会話などの結果を総合的に勘案にしました。「プロジェクトで取り組んだのは、『データを参考とした、人間を中心に考えたデザイン』だ。」とKnight氏は述べています。また、「デザイナーは可能なときにはいつでも、自分自身でデータを解釈して、デザインに関する決定を行う必要があります。近年、定量的なデータと定性的なデータを活用することで、デザイナーたちがますます力を発揮できるようになりました。一般的に、単なる意見や誰かの「好み」に基づいて決定することもなくなり、それ以上のことが可能になっているのです。今日のデザイナーが真に力を発揮するには、明示的なデータと黙示的なデータの両方を活用して、デザインのソリューションを導くことが大切です。」とも述べています。多変量テストによって、小さな変更を試す最後に、Knight氏はリサーチの結果を基にして、多変量テスト（Multivariate Testing：レイアウトデザインの候補の中から、最適なデザインを選ぶための手法）を行うために、デザインにいくつか変更を追加しました。多変量テストは、特定のデザイン要素を決定、却下することで、サイト全体のリニューアルに進む前に、チーム全体として戦略的な決定を行うのに役立ちます。ステップ2：実際のデザインを設計する Knight氏は、「全体の設計→テスト→学習→イテレーション→最適なソリューションの選択」という構造化されたプロセスの手法を用いました。簡単なプロトタイピング多変量テストによって、レイアウトのデザイン候補をチームで3つに絞り、さらにプロトタイプを作成しました。主な方向性が定まったところで、Knight氏は最初の段階でイテレーションを繰り返して行い、次に外観のデザインに取り組むという手法を取りました。実際には、ユーザー望む方向性や意見を反映することに多くの時間を費やしたことを考えれば、プロトタイプでも最終的な完成製品に近いものでした。 Knight氏は次のように述べています。「紙のプロトタイプ、ワイヤーフレーム、外観のデザインの段階に至るまで、テストはユーザーと共に行っています。」「プロジェクトのすべての段階において、ユーザーの声が反映されています。デザイナーとしては、ユーザーの声は耳に痛いこともあるかもしれません。ユーザーの意見にすべて従うのではなくて、方向性を見出すために活用するのがいいと思います。」モックアップ外観のデザインの段階において、Knight氏は特にビジュアルデザイナーと一緒に仕事を行いました。また、Knight氏はデベロッパーとは、プロジェクトの各段階ごとにデザインについてディスカッションを行っていたのも特筆すべきことです。開発側は、プロトタイプを作成する段階で集中的にコーディングを行う一方、全体を通してイテレーションを行うことで、チーム全体としてプロジェクトの進行段階が揃うようにしています。外観のデザインこうしてチームは、現代的で、美しく、鮮やかな色、HD画質の画像、型にはまらないグリッドデザインを活かしたサイトが完成しました。このグリッドデザインは、リニューアルしたサイトには「生き生きとしたデザイン」が必要だという観点から生まれたものです。グリッドデザインをベースとして、多くのデバイスに対応したマルチプラットフォームで、コンテンツの変更や削除も容易です。また重要なコンテンツは、ユーザーや利害関係者の提案に応じて、アップデートしやすくなっています。画像処理画像の枠のデザインも、型にはまらないグリッドデザインです。プロジェクトのチームは、まずサイトのレイアウトに完璧に収まる画像を選びました。マウスをホバーしていない状態（off-hover）では焦点のぼやけた画像の一部が表示され、マウスをホバーさせた状態（on-hover）では画像が右のグリッドの領域まで広がり、画像全体と追加の情報が表示されるような設計になっています。この画像処理によって、識別しやすいデザイン要素が生まれ、ユーザーのアクセスを大幅に増加させるインタラクションが実現しました。またチームは、ユーザーへのインタビューから、個々のユーザー向けに動的なコンテンツを提供することが、サイトリニューアルの成功に大切な要因であるとわかっていたので、これも開発しました。互換性とWebアクセシビリティ最後に、HubSpotのサイトのユーザーの16%はモバイル端末からアクセスしていること、アメリカの人口の19%はWebアクセシビリティのニーズがあることを考えると、コーディング作業に加えて、互換性とWebアクセシビリティを考慮するのも重要なことでした。プロジェクトの各作業の段階は同時並行で進めていたので、モバイル端末向け、デスクトップ端末向けの各サイト設計も同時並行で進めました。 [PR] プログラミングで挫折しない学習方法を動画で公開中ステップ3：コーディングとテスト次のステップでは、HubSpot社のCMSを利用して、きれいなコードを設計するのが目標となりました。すべてのデバイスにおいてコードの互換性が保たれるように、Knight氏は、ビジュアルデザイナー、エンジニアと共に、QAテスト（品質保証テスト）を定期的に実施しました。各種デバイスや、Chrome、Safari、Firefox、Internet Explorer、Edge、Opera、Yandexなど各種ブラウザの多数のバージョンの解像度ごとに、Webサイトが正しく機能するかチェックするテストも行いました。さらに、BrowserStack（多数のブラウザ環境下における作動を再現するためのエミュレータ）を使い、実際のデバイス環境下におけるWebサイトの作動の再現も行いました。設計を改良するときには、ユーザーのプラットフォームごとの割合はすでに把握できていたため、利用者数やクリティカリティ（Criticality：システムエラーなどにおいて主要な要因を分析するための指標）を考えながら、優先順位を決めて効率的に進めることができました。ステップ4：テストの継続とイテレーションリニューアルしたHubSpotのWebサイトは、予定通り、年次イベント「INBOUND」の舞台において、同社の共同設立者たちによって、Webサイトのサポート対象である新製品や新機能の紹介とともに初公開されました。新製品のリリースは、大成功を収めました。しかし、チームとしては引き続き「Lean UX」の手法をプロジェクトで実践するため、栄光に浸っている暇はありませんでした。早速、チームはGoogleアナリティクスとHubSpotのサイトからデータを集計して、次の指標に注意を向けました。コンバージョン率（Conversion rate：目標の達成率）送信率（Submission rate：ユーザーがフォームにデータ入力して送信する率）離脱率（Drop-off rate）目標達成数（Goal completion）ナビゲーションサマリーにおける、参照元ページと移動先ページ検索クエリ（Search Queries）チームは、直帰率（Bounce rate：ユーザーが1ページだけ見てサイトを去る率）、ページ滞在時間など重要業績評価指標（KPI：Key Performance Indicators）として役に立つ指標のみを分析しました。さらにデザインの改良を重ねるために、チームはヒートマップを使って2万5000という膨大なセッションを分析し、追加のユーザビリティテストも行いました。結果：データが示すUXの成功今回のプロジェクトは、Knight氏とチームが「Lean UX」の手法を全て取り入れた初の試みでしたが、データ分析と設計を上手く組み合わせて、迅速にビジネスの成果につなげることができました。またリニューアルしたのHubSpotのWebサイトも、今回のプロジェクトのプロセスと同じくらい、柔軟性の高い設計に仕上がったので、今後のイテレーションも容易に行うことができると思います。デザインのリニューアルや、ユーザーやビジネス上のニーズに応じた修正にも、幅広く対応できるでしょう。秘密保持契約（NDA）のためすべては公開できませんが、Webサイト公開後のビジネス上の成果を、次にいくつかご紹介します。ユーザーのコールトゥアクション（CTA：Call To Action）への反応率の増加ユーザーのナビゲーション要素への反応率の増加製品のトライアル版契約数の増加同社の製品チームにおけるストレスの緩和今では、HubSpot社は「Lean UX」の手法を絶賛する支持者となっています。 Knight氏は、「私たちのチームは、プロジェクトの共同作業を効率的に進めることができた。」、「すべてのプロセスにユーザーの声を反映した結果、チームが誇りに思えるような、インパクトのあるWebサイトを構築できた。」と述べています。 [お知らせ]TechAcademyでは初心者でも最短4週間でオリジナルWebサイトを公開できるWebデザインオンラインブートキャンプを開催しています。

Webデザイン

ほとんどのデザイナーが気付いていない「UXの4つの間違い」とは

本稿は、Webdesigner Depotのブログ記事を了解を得て日本語翻訳し掲載した記事になります。本記事は、HooktoWin.comの共同設立者であるAndrew McDermott氏によって投稿されました。デザイナーは不可能を可能にすることを期待されます。信じられないほど複雑なプロセスを、シンプルで美しいものに作り変えるよう求められることも、何度もあるかもしれません。そして成功したときには、ロックスターになったような気分を味わえるでしょう。しかし、こうした大きな期待に応えられなかったときには、ひどく落ち込むかもしれません。デザイナーには完璧主義者の人が多く、自分自身が自分に対する最悪の批評家であることもよくあります。間違いを自分の責任と見なして、全てを台無しにしてしまったかのように思うこともあります。それでも、落胆するような状況において間違いを受け入れることで、これを成長と学びの機会とすることができるはずです。もし本当のことをお伝えするとしたら…… デザイナーが気づいていない真実：間違いのほとんどは、デザイナーの責任ではありません。辛い現実：いずれにしても、デザイナーは責任を負うことになります。デザイナーに不足しているのは、人についての知識新規の仕事やプロジェクトにおける、デザイナーの目標設定の仕方が、間違いの原因というわけではありません。ほとんどの場合、実際はその逆です。デザイナーは、多くの人が気にしないような細部のデザインまで、こだわりを持って熱心に取り組みます。神は細部に宿ることを知っているからです。問題となるのは、人についての知識が不足しがちなことです。これは、デザイナーが学校で教えられないことですが、仕事に大きな影響を与えます。もしデザイナーが正規の（または非正規の）教育を受けていれば、その過程で自分独自のデザインを究めることを求められます。また、デザインの原則、デザインと配色の関係、色彩なども学びます。しかし、これだけでは十分ではありません。デザインや美術について教育を受けることはあっても、人について深く学ぶ機会はありません。こうした理解不足は、デザインに影響し、ひいては予期しないUXの間違いの原因となります。デザイナーに不足しているのは、人についての知識なのです。 UXの間違い1：ユーザーが実際以上に多くを知っていると思い込むことデザイナーは合理的な人々です。インターフェースの設計に多くの時間を費やすため、デザインがWeb上でどのように機能するかを直感的に理解しています。「これは常識だ！」とデザイナー自身が思っていても、実際はそうではないこともあります。デザイナーにとっての常識が、ユーザーにも通用するとは限りません。デザイナーは設計に多くの時間を費やしているために、よく知っているだけなのです。また、デザイナーがプロフェッショナルであるのに対して、ユーザーが同等の専門性を備えていないこともあります。こうした理由から、ユーザーに対して次のように仮定するのは、間違いです。適切な質問を選ぶことができる設定の操作について理解しているアイコン、マーク、ロゴの意味を知っているコンテンツに意識を集中し続けることができる Webサイトで提供している指示をよく読んでそれに従う必要とするコンテンツの見つけ方を知っている問題の核心が見えてきたでしょうか？デザイナーがこのように仮定すること自体は合理的ですが、問題を引き起こすおそれがあります。なぜなら、こうした仮定は現実に基づいたものではないからです。利用方法が全く分からないユーザーもいますユーザーの中には設定の操作が初めてという人もいますあなたの設計したサイトを、乱雑で混乱するようなデザインだと思うユーザーもいます関心が他に向いているマルチタスク型のユーザーは、コンテンツに集中するほど時間がありません指示に従うのを拒むユーザーもいますほとんどのユーザーは、見ているコンテンツについて詳しく知っていませんこうした場面でデザイナーに求められる仕事は、「迷える羊の群れを、頭数を減らして束ねる」ことです。条件に合うユーザーだけを選び抜き、意図したプロセス通りに彼らがサイトを利用できるような設計にします。その他の条件に合わないユーザーは、除外します。 UXの間違い2：ユーザーのためのデザイン「ユーザーのためのデザイン」は、ここ数年で繰り返し提言されているアドバイスで、頭にたたき込まれているデザイナーも多いかもしれません。デザイナーは、ユーザーのニーズをよく理解して、ユーザーを中心にデザインするよう教えられています。しかし、このアドバイスには見落としている点があります。「なぜ？」と不思議に思うかもしれません。見境なく教え込まれているアドバイスですから。その見落としている点とは、必ずしも全てのユーザーがターゲット・オーディエンス（Target audience：広告やマーケティングにおいて、目標とする顧客）と一致するとは限らないことです。サイトを利用しているユーザーが、「求めているユーザー」像と一致しないことがあるのです。例として、Googleを考えてみましょう。 Googleは、そのエネルギーや注意の大半をユーザーに向けています。Googleにとってのユーザーとは、検索者です。検索者により良いユーザー体験を提供するために、多くの時間と巨額の資金を投資しているのです。しかし、検索者がGoogleの唯一のユーザーでしょうか？実は、その他にもGoogleのユーザーは存在しています。広告主：Googleは広告主が自らの命令に従うことをよく知っています。Googleは、広告主やサイト運営者に対してポリシーを公開しています。もし彼らがGoogleのポリシーに違反して、好き勝手に利用するとしたら、広告掲載やサイトは強制停止されます。ボット（クローラ）：Googleは、ボットなどによってサイト上で「通常以上のトラフィックが検出」された場合に、これをブロックします。検索している主体が人間でも、誤検知（False positive）によりブロックされてしまうこともよくあります。詐欺者：Googleは詐欺サイトもブロックしています。例えば、偽のダウンロードボタンをクリックすると、ランサムウェア（ransomeware）がコンピュータにインストールされるよう仕組んであるサイトなどです。検索者：Googleの検索エンジンの利用者です。このユーザーたちこそGoogleに利益をもたらしています。彼らが広告をクリックしたり、アプリケーションを利用したり、ソフトウェアをダウンロードすることで、Googleに収益が発生する仕組みになっています。 Googleは、自らの目標や利益に反するユーザーに対しては、ユーザーエクスペリエンスの提供を拒否しているのです。 Googleは、ほとんど全てのユーザーに提供されていますが、Googleのユーザーリストに載っていない人々（ボット）は締め出されます。広告主が検索者にスパムを送信するとしたら、広告掲載を強制停止されます。Googleは、自らの目標や利益に反するユーザーに対しては、提供を拒否しているのです。「ユーザーのためのデザイン」は、デザイナーがターゲット・オーディエンスだけに意識を向けるという前提があってこそ有益なアドバイスになることは、十分理解できるかと思います。しかし、多くのデザイナーがユーザーについて見落としている重要な点は他にもあります。それは次の「UXの間違い3」で述べるとしましょう。 [PR] プログラミングで挫折しない学習方法を動画で公開中UXの間違い3：フリクションが不十分であること Webデザインにおける「フリクション（friction）」とは、Webサイト（のレイアウトに使われている要素）の利用を阻害することを意味します。一般にデザイナーたちは、フリクションを悪いものだと考えています。Webサイトを上手く設計しなければ、意図した通りにユーザーが行動しないおそれもあります。こうしたイメージから、デザイナーはフリクションを恐れがちです。しかし、全てのWebサイトにはフリクションが必要です。もし音楽を聴いていて、うるさいと感じたらどうしますか？おそらく音量を下げますね？同じことがフリクションにも当てはまります。ユーザーは音楽に、フリクションは音量調節のダイヤルに、それぞれ例えることができます。望ましいユーザーだけをWebサイトに集めるために、いわばフリクションというダイヤルで、音量を上げたり下げたり調整するのです。フリクションを活用しているWebサイトの例を、次にいくつかご紹介します。 Craigslist（クレイグズリスト）：Craigslistは、同じ広告を50回連続で投稿されたりするのを嫌がります。そのため、Ghostingという技術によってフリクションを生み出しています。ユーザーがスパムを送信したり、広告を過度に多数回投稿した場合には、広告はブロックされて誰にも見えないように非表示になります。 Google：Googleはユーザーに自らのポリシーを尊重してもらいたいようです。もしサイトを悪用したり、検索結果を利用してWebスクレイピング（Web scraping）を行えば、「通常と異なる」ユーザーとして検出されます。さらに警告を無視するとブロックされます。 Quora：Q&Aのサイトです。利用ガイドラインはシンプルで、「Be nice, be respectful.（マナーと節度をもって利用すること）」というポリシーを掲げています。このポリシーを無視するユーザーには警告を与え、ブロックまたは利用禁止にします。フリクションを利用することで、他のユーザーにとって安全なサイトであることを保証しているのです。Quoraのサイトのシステムは、ユーザー体験の質を最大限に高めるようにデザインされています。デザイナーにとってフリクションは、問題となるかもしれません。しかしそれはデザイナーが、フリクションというダイヤルを調整する方法を知らなかったり、またはフリクションが存在すること自体知らないからです。デザイナーのフリクションに対する理解が不足していると、フリクションに過剰反応してしまったり、皮肉なことに望ましくないユーザーにWebサイトを悪用されることも起こり得ます。では、フリクションを具体的に実装するとしたら、どのようになるのでしょうか？例を見てみましょう。問い合わせフォームに、キャプチャを3～4つほど複数設けて、人間であることを判別する利用に至るまでのステップ数を必要以上に増やすことで、ユーザーをふるいにかける文字で埋め尽くされたページ、またはデザイン要素がぎっしりと並んだページにする入力フォームを必要以上に多く設置することで、ユーザーを疲労させ、興味を失わせる（逆に入力フォームを十分に設置しないとしたら、全てのユーザーのアクセスを容易にすることになります。）コンテンツと関連性の低いストックフォトや画像を使うことで、ユーザーがコンテンツの意味を理解する妨げとするユーザーに個人情報や支払い情報の入力を求める一方で、サイト運営者の顔写真や個人情報などは可能な限り非公開にしておくフリクションは重要な設計であり、その形やサイズは様々ですが、多くのデザイナーが理解に苦戦するのは確かです。 UXの間違い4：上司の指示にいつも忠実であることこの間違いを回避するには勇気を要します。それに加えて、さらに重要なことですが、目標を明確に理解していることも必要です。現在デザインしている要素は、どのような完成形が望ましいのか、開発しているWebサイトの目標は何なのかなどです。目標に関するこうした質問にクリアで決定的な答えを出しておくことは、必須ですその理由は、あなたの上司、会社の役員会、クライアント、関係責任者から、目標に反する要求をされることがあるからです。相手の要求通りに進めたら良い結果は生まれないと、経験から予測できることもあるかもしれません。当初の目標に反して進めた結果、失敗プロジェクトとなるおそれもあります。もっとも、「指示通りに仕事をこなしてさえいれば、彼らは報酬を支払ってくれるから構わない。」という考えで、上司に協調するのは簡単ですが。自分の意見を声に出して伝えることが非常に重要です上司が自分自身のために行動しない場合には、あなたが上司に代わって行動することが重要です。もし上司が、彼ら自身の利益を損なうような指示を出してきたら、あなたの意見を声に出して伝えましょう。悪いニュースを伝えるべき場面です。上司に彼ら自身が犯そうとしている間違いを理解してもらうためです。もし自分の意見を声に出して伝えないことが習慣化したら、平凡なポートフォリオしか生まれないほとんどのデザイナーは自分の意見をはっきりと伝えることはありません。仕事を失ったり、キャリアに傷が付くのを恐れているからです。しかし、そのことが逆にこうした事態を招く原因となります。この間違いに対処する手立てが何もない場合にはデザイナーとしてチームに参加したときに、計画やデザインがすでに決定されていた場合にはどうするべきでしょうか？まずチームの他のメンバーと話し合いを持ちましょう。そして自分の意見をサポートする根拠（例えば、リサーチ、レポート、データなど）を十分に用意した上で、プロジェクトの責任者に意見を伝えましょう。最初は不可能に思えるかもしれませんが、実際には行うことは可能です。小さなステップから始めて、段階を追ってゆっくりと進めてみましょう。あなたはデザイナーとしてプロフェッショナルです。デザインツールを活用すれば、他の人が見逃してしまうようなUXの間違いを見つけることもできると思います。間違いを正すことで、複雑なプロセスを、シンプルで美しいものへと作り変えることができるでしょう。 [お知らせ]TechAcademyでは初心者でもUI/UXデザインができるようになるUI/UXデザインオンラインブートキャンプを開催しています。現役UI/UXデザイナーのサポートで学びたい場合はご参加ください。

アプリデザイン

【チケット売買アプリを事例に！】Googleへのアプリインデックスは努力に値するのか

本稿は、Smashing Magazineのブログ記事を了解を得て日本語翻訳し掲載した記事になります。本記事は、Vivid Seats（チケット売買サービス）のSEOディレクターであるBryson Meunier氏によって投稿されました。 Googleの検索結果にアプリが表示されるように、App indexingを実装することにリソースを投資するのは、アプリのトラフィックの観点から効果的でしょうか。この記事では、私の会社での活用事例を通して「App indexingを実装することは努力に値するのか」についてその答えを考えます。結果は驚くべきものです。近年、App indexingはSEOにおいて最もホットな話題の1つですが、それにはいくつかの理由があります。 Googleは約2年以上も前から、アプリをインデックスするこの技術をすべての開発者のために公開しています。しかし、実際にApp indexingを実装しているアプリは全体の約30％であり、Webサイトが追加的なトラフィックをアプリにもたらすことができる潜在的な可能性は大きいとしている調査もあります。さらにGoogleは、WebサイトがApp Indexingを利用していることと、アプリがApp IndexingのAPIを実装していることついて、検索順位を上げる要因として考慮するとしています。そのため、App IndexingをWebサイトに実装することは、検索のトラフィックを増やすのに効果的だと思われます。しかし、私の会社で実践してみたところ、効果はありませんでした。 App Indexingを実装したとき、たしかにGoogle検索経由のアプリのトラフックは増加しましたが、Web検索からのトラフィックと比べると微々たるもので、ほとんど努力に値しませんでした。私の会社における活用例と、それが全体のトラフィックへもたらした影響について、詳細をまとめています。目次 App Indexingとは実装した背景実際に行った解決策結果結論 App Indexingとは App Indexingとは、関連する検索結果と一緒に、アプリがGoogle 検索に表示されるようにする仕組みのことです。あなたのアプリで（1） HTTP URL をサポートし、（2）App Indexing SDK を追加すると、GoogleがそのWebページをクロールしてインデックス登録します。その結果、ユーザーは関連するキーワードで検索したときにその検索結果から、アプリをインストール、実行できるようになります。ユーザーがアプリをインストール済みの場合、関連する検索結果の中に、「アプリを実行する」ボタンが表示されます。検索者がアプリをインストールしていない場合には、関連する検索結果の中に、「インストール」ボタンが表示されます。理論的には、この仕組みは素晴らしいものです。ユーザーはWebサイトやアプリを好むかどうかにかかわらず、ソースが明らかで信頼できるコンテンツを見つけることができます。また、アプリの開発者やマーケティング担当者にとっても、アプリストア以外で、新規ユーザーに紹介することができるため、潜在的に利用者数やダウンロード数を増やす可能性を秘めているといえるのです。しかし、「理論的に」優れていることは、必ずしもApp Indexingが実際にトラフィックを増やす効果があることを意味しません。「どのように」また「なぜ」App Indexingを実装するかについて、私は多くの情報を調べましたが、App Indexingがトラフィックの観点からメリットがあるという実例は、見つけることができませんでした（Googleは他にもいくつかのメリットを強調していますが）。そのためマーケティング担当者、開発者が、アプリをインデックスさせることによってトラフィックを実際にどれだけ増やすことができるか把握できるように、自分の会社Vivid Seatsのアプリで試してみました。 Vivid Seatsの事例を考えるにあたり考慮すべき点があります。Bloombergによると、Vivid Seatsは、StubHubとTicketmasterに次いで世界第3位の、最大級のチケット市場です。そのため、元々トラフィックが多いのです。私たちのケースほど多くのトラフィックがないWebサイトや、同等の規模のWebサイトを持っていないアプリの場合は、私たちの結果とは異なるものになる可能性もあります。また、今回のVivid Seatsの事例は、Androidのみを対象としたものです。ベータ版のApp IndexingのiOSについては、まだGoogleのSearch Consoleを利用していないため、iOSアプリの場合にもインデックスや検索順位について同様の結果となるかは不明です。 [PR] プログラミングで挫折しない学習方法を動画で公開中実装した背景 Vivid Seatsは2015年9月から、Androidアプリがインデックスされています。当初、Webページと関連付けたアプリのURIをGoogleの検索結果に見つけるのは困難でした。 2016年2月に入っても、インデックスされたアプリのURIは約18で、そして「URI フォーマットはサポートされていません。」というエラー表示つきの35,000以上のページが見つかります。このエラー表示の原因は、当初のWebサイトのものとは異なるURIをアプリケーションに関連付けたため、Googleは関連付けたページを見つけることが難しかったということもあるかもしれません。実際に行った解決策最初に、この問題に関するGoogleのヘルプセクションの指示通り、関連付けるアプリのURIを示す「rel=”alternate”」を含むlink要素をWebページに追加しました。例えば、Vivid Seatsのアデル（Adele）のチケットページ――「http://www.vividseats.com/concerts/adele-tickets.html」――の場合には、次の「rel=”alternate”」を含むlink要素を追加することになりますが、これは関連付けるアプリのURIを示すものであり、モバイル端末のユーザーエージェントに動的に配信されるのです。 <link rel="alternate" href="android-app://com.vividseats.android/vividseats/performer/15313"> アデル（Adele）のチケットページのモバイルビュー（画像：Fawaad Ahmad）この問題の解決策としてGoogleはヘルプセクションでこのソリューションを推奨していたため、最初はこれで解決するだろうと思っていました。しかし、残念ながら実装して数週間が経過しても、GoogleによってインデックスされたアプリのURIの数は増えませんでした。また、Googleのクローラは私たちのWebサイトの多くのページは関連付けされたアプリビューをすでに持っていると判断したためか（その時点では実際にはそうではなかったのですが）、クロールエラーも続きました。そこで私たちは4月に、iOSアプリにおいてユニバーサルリンク、AndroidアプリにおいてHTTP URLをサポートしました。これによりエラーの数を、最多時の約40,000から、現在の約85まで減らすことができました。その結果、インデックスされたアプリのURIの数は、2月の時点における18から、現在の約35,000にまで増えました。これを実現するために、Firebase App Indexingのドキュメントで説明されている手順を実行しました。まずWebサイトの各タイプのリンクが、Androidアプリと対応する、ビューとURIを持っていることを確かめました。これを行うため、以前はアプリには含まれていなかったページタイプ用のテンプレートを設計し、Androidアプリでそれらを構築しました。各ページの固有の情報は、RESTful APIのエンドポイントから動的に提供されるため、テンプレートを設計してコード化するだけで済み、個々のページをコード化する必要はありません。私たちのWebサイトはSSLを実装していなかったため、GoogleのDigital Asset Linksによる要求に従い、Search ConsoleでWebサイトの所有権を確認しました。インテントフィルタをAndroidのマニフェストファイルに追加しました。 getIntent( )を呼び出し、onCreate( )のコードを実行して、アプリをPlayストアにデプロイしました。結果予想通り、インデックスされたアプリURIの数は、12月の18から、9月には約40,000まで指数関数的に増加しました。全体的に見ると、クリック数は919％増加しました。ブランド名を含まないクエリ（例：”Packersのチケット”など、Vivid Seatsというブランド名を含まないその他情報へのクエリ）からのクリック数は、5,500％増加しました。またこれも予想通りですが、インプレッション数の増加（具体的には、ブランド名を含まないクエリによる増加）の結果として、クリック率（CTR）は低下しました。アプリのトラフィック（Search Consoleで「クリック」と定義されています）の数は、インデックスされたアプリのURIが増加した結果、Webサイトのトラフィックに比例して指数関数的に増加しましたが、アプリのトラフィックには現在のところ効果は見られません。約40,000のアプリのURIが追加的にインデックスされても、現在、検索からのトラフィックの99.82％がWebページに送られており、アプリのURIに送られるのはわずか0.23％です。数があまりにも小さい理由はいくつか考えられます。今回の調査では実証はしていませんが、AndroidのモバイルトラフィックはiOSのモバイルトラフィックよりも、割合が低いという可能性もあります。また私たちの場合、インデックスされたアプリのページは、インデックスされたWebページよりも数が少ないです――実際に3倍以上の差があります。今回アプリのURIが多くインデックスされたことによって、トラフィックは指数関数的に増加したため、今後、最終的にGoogleがアプリのURIをすべてインデックスしたときには、トラフィックがもっと増える可能性もあるかもしれません。しかし最大の理由は、アプリのリスティング広告とWebのリスティング広告では、クリック率（CTR）が大幅に異なることだと思われます。ブランド名（Vivid Seats）は、Webにおけるクリック率では全体の約40％を占めていて、通常は平均掲載順位も1位なのですが、アプリにおけるクリック率では1％にも満たないのです。このことは、アプリのボタンはGoogle検索結果の中でナビゲーションとしては目立つものの、ほとんどの人はまだWebサイト上からクリックすることをより好むという傾向を示しています。最後の理由については、App Indexingはまだ新しいテクノロジーであり、検索者がまだレイアウトに慣れていないことが原因かもしれません。将来的にはこの傾向は逆転することも予想できます。しかし現状としては、アプリのページをインデックスさせようと考えているすべての人はこの点を理解しておくことが重要です。検索結果に表示される大きくてカラフルなボタンが、クリック率とトラフィックを増加させる効果があると考えるのは魅力的なことですが、私たちの調査からはこれを実証する結果は得られませんでした。実際の結果はその逆でした。次の表に示すように、アプリのコンテンツにおけるクリック率は、Webにおける場合の半分以下です。 Androidアプリのページは、クリック率は1.55％で平均掲載順位は5.1です。一方、Webコンテンツは、クリック率は4.67％で平均掲載順位は7.6です。アプリの一般的なクリック率（1.75%）は、Webのクリック率（4.69 ％）よりも低くなっていますが、その内訳としてナビゲーションの（ブランド名の）検索語句によるもの（1.13％）は、その他情報のコンテンツによるもの（6.16％）よりクリック率が低いことが判明しました。この内訳の関係はWebコンテンツのクリック率では、逆転しています。ブランド名によるクエリからのトラフィックは、アプリのトラフィックの約56％を占めていて、Webのトラフィックでは約40％を占めています。クエリの種類をさらに詳しく調べるために、2つのタイプに分類しました。第1に、ブランド名のクエリ（vivid seats）またはブランド名を含まないその他の情報のクエリ（Packerのチケット）を含むナビゲーションクエリ、第2に、検索者がWebサイト（www.vividseats.com）またはアプリ（vivid seatsのアプリをダウンロード）を探していることを示すクエリです。検索者がWebサイトまたはアプリを探していることを示すクエリでない場合には、そのクエリにブランド名が含まれているかどうかを確認し、Webサイトやアプリの嗜好について「特定されていません」と記録しました。アプリ名を特定した検索トラフィックは、アプリのトラフィックでは約4％であるのに対して、Webのトラフィックでは1％未満です。クエリの大多数は、検索者がアプリやWebサイトを特定しないで行った検索によるものであり、Webにおいて約99%、アプリにおいて約96%を占めています。検索からアプリへのトラフィックにおいては、今のところ効果が見られません。しかし、ほとんどの開発者がアプリのコンテンツをインデックスさせる本当の理由は、ダウンロードを促進することにあります。幸いなことに、Search Consoleを使用すると、検索からインストールされている状況を確認できます。これはSearch

Webマーケティング

【ゼロから作る！】初心者から始めるAndroidアプリ開発の開発手順とは

Androidアプリの開発手順をゼロから紹介していきます。今回の記事では、アプリを作ったことがないという未経験者でも分かりやすく2人のキャラクターが登場しながらAndroidアプリ開発について解説しています。「Androidアプリを作る上で必要なもの」「Androidアプリを作ってリリースしてみたい」などそれぞれシチュエーションに分けて細かく紹介していきます。では、Androidアプリの開発手順を実際に見ていきましょう！目次 Androidアプリ開発をする上で必要なもの実際にAndroidアプリを作ってみるアプリをリリースしてみるアプリで収益を得る大石ゆかり田島メンターってなんでiPhoneとAndroid、両方のスマホ持ってるんですかー？田島悠介なんでって両方のアプリを勉強するためだよ！大石ゆかりえ、でも同じアプリ入れてるじゃないですかっ！田島悠介実はね、iPhoneとAndroidで同じアプリでも違うデザインになっていたりするんだよ！大石ゆかりへぇ〜そうなんですね。どっちも同じように作ってると思ってました！田島悠介実は結構違うんだよね！ちなみにiPhoneとAndroid、それぞれ持ってる人の割合って何%くらいか知ってる？大石ゆかりんー、私の周り見てもみんなiPhoneだからほとんどiPhoneなんじゃないですかー？田島悠介たしかに日本人でiPhone使ってる人は多いよね！でも世界ではスマホを使ってる人の71.9%くらいがAndroidって言われているんだよ！（2021年1月statcounter調べ：Mobile Operating System Market Share Worldwide | StatCounter Global Stats）大石ゆかりえ、そうなんですかー！初めて知りました！田島悠介アプリを海外の人に使ってもらおうと思ったらAndroidから作る方が良いかもね！せっかくだからAndroidアプリの作り方を一通り説明しようか？大石ゆかりぜひ！知っておきたいです！(Androidアプリ作れたら海外で働く夢も叶うかも♪) Androidアプリ開発をする上で必要なもの PC(Mac/Windows/Linuxのいずれか) Android Studio JavaやKotlinなどのAndroid開発言語 Androidアプリの開発を進めるためには上の3つが必要です。 PC MacやWindowsなどのOSに関わらず、メモリは16GBほど搭載しておくと、開発する際にストレスなく動作させることが可能です。もちろん、CPU性能も影響します。開発環境 Android StudioではなくEclipseという環境でアプリ開発することも可能ですが、Android Studioで作る場合が一般的です。 Android Studioに関しては次の記事を参考にしていただくと分かりやすいです。「AndroidStudio」を使ったアプリ開発環境の構築方法 | TechAcademyマガジン言語 Java Javaは世界中の基幹システムで使われているプログラミング言語です。 Androidアプリ開発でも利用しますが、業務システムでもよく利用されるため、Javaを習得することで幅広い業務のシステム開発を行うことが可能になります。 Javaについては、次の記事を参考にしていただくと分かりやすいです。今さら聞けない！Javaとは【初心者向け】 | TechAcademyマガジン Kotlin KotlinはJava言語と100%の互換性を保ちつつ、より簡潔にソースコードを書けるよう、現代的な言語仕様が多く取り入れられています。 2010年に開発が始まり、2017年にはAndroid開発用言語として正式サポートされた新しい言語のため、書きやすい文法であるよう工夫されています。 Kotlinについては、次の記事を参考にしていただくと分かりやすいです。 Androidアプリ開発に使うメリットを解説！Kotlinとは【初心者向け】 | TechAcademyマガジン Dart（Flutter2） Dart言語を利用してAndroid開発をを行う際、Flutter2というフレームワークを利用します。 Flutter2を利用することで、「iOS」「Android」などのスマホアプリ、「Windows 10」「macOS」「Linux」などのデスクトップアプリ、「Google Chrome」「Safari」「Microsoft　Edge」など、ブラウザアプリを1つのソースコードですべて開発可能です。 https://flutter.dev/ JavaScript（React Native） JavaScriptを利用するReact Nativeでは、React.jsというフロントエンドフレームワークを利用してスマホアプリの開発が可能です。基本的にはフロントエンドプログラミングの技術を利用しているため、フロントエンドエンジニアがスマホアプリを開発する際、低い学習コストで開発が可能です。 React.jsもReact NativeもFacebookがサポートしています。 React Native · A framework for building native apps using React また、中にはツールを使ってアプリ開発できるものもありますが、プログラミングをして自分の力で作りたいという人は「Java」というプログラミング言語を理解する必要があるでしょう。 C#（Unity） C#を利用して開発するUnityでは、ゲームの開発を行うことが可能です。 Unityで開発したゲームは、AndroidやiPhoneなどのスマホアプリだけでなく、PlayStationやNintendoSwitchやXboxなどの家庭用ゲーム機用や、WindowsやMacやLinuxなどのPC向けゲームなどでリリースすることが可能です。 Unityについては、次の記事を参考にしていただくと分かりやすいです。今さら聞けない！ゲーム開発で人気のUnityとは | TechAcademyマガジン C#（.net） Xamarin という機能を利用して、iOS、Android、Windows向けアプリケーションを実装可能です。 Xamarinという名称は、今後、MAUI という名称に変更される予定です。 Xamarin とは – Xamarin | Microsoft Docs ノーコードノーコードとは、コードを書かずに実装が可能なツールを言います。実際プログラミング言語を学ばなくてもある一定レベルのアプリを作成することが可能です。スマホアプリを実装可能なノーコードツールはたくさんありますが、代表的なものとしてGoogleが買収したAppSheetなどがあります。 Make an App with No-Code. Start building today for free.

Androidアプリ開発

記事を検索

ニュース

インタビュー

テクノロジー

キャリア

お問い合わせ

ビジョンを実際のアプリに落とし込むまでの9つのステップとは

目次

1. 最初のステップ

2. 要件工学（RE：Requiment Engineering）