アプリ開発について

【チェックリスト】アプリ開発に必要なもの

アプリを開発する前に用意しておくべきものをまとめました。すでにアプリを企画している人は、 以下のものが用意できているかチェックしましょう。

また、これから企画をするという方も、以下を参考にしながら、「アプリの企画ってどこまでやればいいのか ?」 を確認してみてください。

企画にもいくつかの段階があるので、自分でどこまでやるのか ? どこから外部にお任せするのか ? を 検討する際のチェックリストとしてもご活用ください。

 

ビジネスゴールを設定する

ビジネスゴールとは、ビジネス上達成したい目的のことです。何のためにアプリをつくるのか ? を まずは明確にしましょう。

基本中の基本と思われるかもしれませんが、プロジェクトに関わる全てのメンバーが同じ方向を 向けるためにも、企画書に必ず明記しておくべき項目です。

 

ユーザーゴールを設定する

ユーザーゴールとは、そのアプリを通じてユーザーが達成できることです。当然、それを考えるためには、 ターゲットユーザーが誰であるのか ? をまず知る必要があります。そしてユーザーゴールはすなわち、 そのターゲットにどんな価値を提供したいか ? どんな体験をさせたいか ? を考えることですので、 同時にアプリのコアを決めることになります。

実際には、「こんなアプリを作ろう !」とまず発想し、だいたいのアプリの機能などが決まってからユー ザーゴールを考えるという順序になるかもしれません。

しかしいずれにしても、ユーザーゴールのないアプリはあり得ませんので、必ず企画書の中には記載す るようにしましょう。これはアプリに限らず、企画の基本ですね。

 

アプリのコンセプトを決める

ここまでで、どんなアプリにするか、だいたいのイメージは湧きまし たか ?

次はアプリのコンセプトを決めましょう。コンセプトは、「どんなアプリなのか」を一言で表したもの です。コンセプトもユーザーゴールと同じで、考える順序は最後の方になるかもしれません。

ビジネスゴールとユーザーゴールの二つを満たしたものであることが望ましいです。

アプリの具体的な機能を考える

ビジネスゴールとユーザーゴール、コンセプトを決め、大まかなアプリの方向性が見えてきたら、次 は具体的な機能を考えていきます。既存の類似アプリなどを参考にしながら、必要と思われる機 能を書き出していきましょう。

 

アプリの優位性・独自性・強みを把握する

おそらくあなたの作ろうとしているアプリには、類似アプリ・競合アプリがすでに存在しているかも しれません。でもなぜ、それでもそのアプリを作るかというと、きっと何かしらの独自性を発揮で きるからですよね ?

アプリをユーザーに使い続けてもらうことはそう簡単ではありません。何かしらユーザーにダウン ロードする動機、そしてその後も使い続けてもらえるような動機を与えなければなりません。

強みを企画書に記載しておくことで、アプリ開発に関わる全ての人に端的にそのアプリの特徴を伝える ことができます。例えば、開発を外部に依頼する場合、特徴や強みが明確であればあるほど、開発側として も機能の提案などが行いやすくなります。

競合サービスにはどんなものがあって、自分たちのサービスはどう違うのか?は、企画書に記載し社内 外のメンバーに伝えておいた方がよい重要なポイントです。

 

アプリの企画書ができたら、次は設計をしましょう。 ここで言う設計とは、システム的なことではありません。

あなたの頭の中だけにあることを整理し、企画を検証したり、ディレクターや開発会社との認識齟齬 をなくすために行う工程です。

 

ユーザーがアプリでできることを整理する

企画編では、アプリの機能案を出しました。 設計編では、その機能をユーザー視点で詳しく書いてみましょう。

 

ユーザーがアプリで見られる情報を整理する

1 ユーザーストーリーを達成するために必要な情報を考える

ユーザーストーリー ( 誰が、何を、どうする ) の「何を」に当たる部分が、アプリに必要な情報になって いる場合が多いです ( 一部「どうする」の部分にも含まれることがあります )。 被っているものや、別の情報の一部になっている情報は、まとめてしまって構いません。

2「項目」と「要素」の一覧表を書く 上記のように、情報を抽出したら、ユーザーがアプリで見られる情報を一覧表にします ( ケーススタ

ディ参照 )。過不足があっても構いません。 大事なのは、あなたの頭の中にあることを可視化することです。

ユーザーストーリーを決める際に、アプリの画面を想像したと思います。そのときに何が見えましたか ? また、参考にしたアプリには何が書いてありますか ?

 

ユーザーがアプリをどのように使うかを整理する

ユーザーストーリーと情報が決まったら、次はユーザーがアプリをどのように使うかを考えましょう。

 

ユーザーストーリーの流れから画面から考える

ユーザーストーリーの流れを作ることができたら、次は画面をイメージしてみましょう。 画面をイメージするときは、ユーザーストーリー単体で考えずに、流れに沿ってイメージしましょう。

なお、画面イメージはプレゼンテーションツールなどの丸や四角の図形を使った簡単なもので構いません。

 

アプリマップと画面詳細設計書を作ろう

作ってみた画面イメージを並べて、アプリマップ(Web サービスで言うところのサイトマップ)を作って みましょう。これでおおよその画面数がわかります。

また、それぞれの画面について、詳細な仕様も書いてみましょう。

 

ここまで、アプリの企画と設計について見てきました。なんとなく自分のアプリを形にしていくこと ができているでしょうか?

最後は「発注編」。自分で作った企画書や設計資料をもとに、開発会社に見積もりをとったりして、 プロジェクトに適した開発チームを探していくフェーズになります。

とくにアプリを開発するのが初めてという方は、どういう観点で開発会社を選択すれば良いか わからないのではないでしょうか。 ここでは、アプリの開発を外部の開発会社に委託するにあたって知っておきたいポイントをお伝え します。

 

ウォーターフォール型は初期に膨大な時間をかけて、サービスの開発範囲を「全て」定義し、設計し、 実装して、最後にテストを行う形態です。 基本的に途中での仕様変更、後戻りを想定していない開発スタイルのため、修正する場合には 多大が時間・労力・調整が必要です。

ウォーターフォール型は利用ユーザーが明確に分かっていて、業務フローも固定化されて可変 しない場合 ( 勤怠管理等の社内で使う業務システム etc) には予算変更も少なく済むため有効で すが、新規事業等でターゲットユーザーが不明瞭かつビジネス環境も日々変わる不確実性の高い 場合にはあまり適していません。

アジャイル型では、分析、設計、実装、テストを短い期間で並列に行い、そのサイクルを繰り返してい きます。ユーザーにとって価値の高い機能から開発し、短いサイクル (1 週間 ~1 か月程度 ) で動 くソフトウェアを完成させます。文書ではなく、実際に動くソフトウェアを一定のサイクルで開 発していくのが特徴です。

アジャイルでは、途中で当初の仮説を反証するような事実が見つかった場合、ビジネス環境の変 動が起こった場合、新しい有益な情報が入った場合には即座に修正や性格変更を行うのが一般的 です。また、機能の優先順位を途中で変更することになっても、アジャイル開発の場合開発サイク ルが短いために、企画全体への影響が少なくて済みます。

ウォーターフォール型とセットになるのは、「一括請負」という契約 形態です。「一括請負契約」とは、何を作るかをお互いで定義して その青果物の納品・検収 をもってして契約遂行となる形態です。 そのため、初期に成果物を定義できるシステムであれば、予算が あとから追加になりにくいのです。

逆に言うと、日々仕様変更が当たり前の開発スタイル ( 全体仕様を定義できないスタイル ) を 取る「アジャイル」型とはマッチしない契約形態です。

1 か月で何日間、何時間働いたらいくら ? で契約する形態です。 この期間契約には下記 2 つのメリットがあります。

ビジネス上のゴールを一致させられる

期間契約の場合、ビジネスが成功すればするほど新たなシステムの 構築、改善、運用が必要になるため、開発会社側も開発人員を増員したり、 長期での契約が約束されて収益を増大させることができます。

急な仕様変更でも調整が不要

期間での契約になるため、急な仕様変更であっても営業との見積もり調整は必要ではなくなります。 とはいえ、その分契約している時間を無駄に消費しないための開発マネジメントスキルや慣れはある 程度必要です。また、経験不足のチームだと効果が出づらかったりします。

そのため、最初は本当に小さなコア部分のみ切り出して「ウォーターフォール + 請負契約」で行ったり、 海外チームでコストを抑えて行うラボ契約で回すことによって予算を抑えつつ実行するのも良いで しょう。

 

ウォーター フォール型

成果報酬 契約

Web サービス内やアプリ内での売上を受発注者間で分け合う、レ ベニューシェアとも呼ばれるモデルです。

(例)
・売上の○% を報酬として開発企業に支払う ・月額固定で○円を最低限の開発費として支払い、売上が○円を超えた場合は、超過分の○% を支払う

適した開発スタイル診断

開発スタイルや契約形態の種類についてイメージは掴めましたか?

それぞれの特徴とメリット・デメリットをまとめたので、実際に発注する前に、「自分はどちらの開発 スタイルかな?」というのをチェックしてみてください。

見積もり前に開発会社に最低限伝えるべき項目

開発会社にスムーズに、かつより正確な見積もりを出してもらうためにも、必ず以下の項目は伝える ようにしましょう。当然ですが、情報はより詳しい方が、より正確な見積もりが出てきます。

 

見積書の見方をマスター

見積もりの出し方は開発会社や案件の内容、また発注側が出す情報によって変わってきます。

「企画編」「設計編」でやってきたように、機能が決まっていれば、以下のように、機能毎にかかる工数を 元に見積もることができます。一方、機能が決まっていない場合は、開発会社としてもバッファを持っ てざっくり見積もらざるを得ません。できる限り機能レベルまで詰めておく方が良いでしょう。(もち ろん企画も含めて外注される場合は、そこまでやる必要はありません。)

以下では、機能毎に見積もった場合の見積書で確認すべきポイントを記載しています。

Archive List

LEAVE A REPLY

*
*
* (公開されません)

CAPTCHA