📅
アプリ開発を発注する手順
アプリ開発を外注する際の大まかな流れを事前に把握しておくとスムーズです。
おおよその流れを見てみましょう。
アプリ開発の期間
アプリの開発期間は、アプリの種類と開発形態によって以下のように変動します。
＜アプリの種類と平均開発期間＞
・シンプルなアプリ・ショッピングアプリ：1～3カ月ほど
・ゲームアプリやメッセージ・通話アプリ・位置情報アプリ：6カ月〜1年ほどかかることも
＜開発形態と平均開発期間＞
・アプリを一から作り上げる「フルスクラッチ型」*：6ヶ月〜1年以上
・既存のシステムを組み合わせて作る「クラウド型」**：3ヶ月ほど
用語解説
*フルスクラッチ型：搭載したい機能をフルに搭載できる。その分長い開発期間が必要です。
**クラウド型：既存システムを生かす。オリジナルの機能は付けられません。
アプリ開発を発注する際の流れ
アプリを制作するとき、大半の方が開発会社に外注しますので、
ここでは、アプリ開発を外注した場合のスケジュールを見ていきましょう。
依頼する前の大枠の流れは以下の通りです。
- 外注先を決める
- ヒアリングを受ける
- 見積もり・提案を受ける
- 企画を詰める
- 要件定義
- 設計・デザイン
- 開発・実装
- テスト
- 納品
それでは各詳細を見ていきましょう。
1. 外注先を決める
アプリ開発を外注する場合、はじめに行うことは依頼する開発会社を選定することです。
会社選定の際に、まず確認したいポイントが開発会社の実績。
一口にアプリ開発会社といっても、開発能力や開発環境は会社ごとに大きな差があります。
ホームページなどから過去の実績を確認することで、おおまかな能力を測れるでしょう。
過去の実績については、制作したい種類のアプリの開発経験の有無もチェックしてください。
会社によって強みや特徴が異なるからです。
また、アプリ開発にかかる費用をできるだけ抑えたいという方も多いでしょう。
しかし、料金の安さだけで依頼することは危険です。
クオリティが低かったり、欲しい機能がつけられなかったりといったトラブルに注意しましょう。
2. ヒアリングを受ける
依頼するアプリ開発会社の決定後、まず行われるのが開発会社とのヒアリングです。
・どのようなアプリを導入するのか、
・導入によってどのような成果を期待しているのか
などを開発会社とすり合わせていきます。
＜ヒアリング時に確認される事項の例＞ ※会社によって異なります。
・アプリを作る目的・予算・納期（開発にかかる期間）
・実装したい機能
・アプリのデザイン
特に重要なのがアプリを作る目的です。
目的によって開発するアプリのデザインや実装する機能が大きく異なります。
そのため、事前に自社の中でアプリを開発する目的やゴールを明確にしておきましょう。
実績と経験が豊富な開発会社でも目的・ゴールが見えなければ最適な提案はできません。
3. 見積もり・提案を受ける
開発会社が開発費用の見積もりや開発案を提示してくれます。
一般的に、複数の案を提出されることが多いでしょう。
そのため、より目的を達成できるであろう提案を選ぶ必要があります。
提案を受ける際に、重要なのがRFP（提案依頼書）*の作成です。
発注企業から、正確な情報を共有し、より良い提案をしてもらうための資料と考えてください。
＜用語解説＞
*RFP(提案依頼書)：
システム開発に必要な要件や、実現したい業務を示す書類のことです。
仕様をマップや工程表のようにしたものになります。
＜RFPを作るタイミング・メリット＞
・提案の前に作成することがおすすめです！
・RFPを作成することで、言った言わないのトラブルを避けられます。
・開発期間・納期に関しても明確に伝えることが可能になります。
・伝え忘れや伝え漏れも防げます。
＜RFPがあるのか・ないのかわからない場合＞
アイミツCLOUDで依頼する際、「RFPの有無」が問われる項目があるのですが、
提案依頼書を作成したことがなければ「RFPはない」となります。
以前のものに追加して作り直したい時など既にRFPをお持ちなら「ある」になります。
「これはRFP？いや違う？」と迷ったら「ない」として依頼して質問をしましょう！
ちなみに類似語にRFI(情報提供依頼書)があります。
こちらは受注者様に広く情報収集を依頼する書類となり、RFPを作る前段階で使用されます。
4. 企画を詰める
現状の自社の課題を洗い出し、企画を立てていきます。
目的やターゲット層、ユーザーとってもらいたい行動、コンセプトを設定します。
課題を明確にすることで、アプリに取り入れるべき要素が見えてきますし、
開発会社もよりニーズに合致した提案がしやすくなります。
また、搭載することによって自社の課題解決に繋がる機能を考えましょう。
例／
課題：新規顧客のリピート率が上がらない…
解決策：プッシュ通知機能などで積極的にユーザーに情報を提供していく
なお、アプリは数多くの機能を搭載すればいいというものではありません。
機能を過度に搭載すると容量が大きくなり使い勝手が悪くなる可能性もあります。
企画段階で、搭載する機能の優先順位をつけましょう。
5. 要件定義
本格的なアプリ開発に入っていきます。まず、行うことは要件定義*です。
<用語解説＞
要件定義：どのような機能や性能を持たせるか、どのようなシステムにするかを定めます。
概要、目標などに基づいて、どんなシステムを作ったら良いかを決定する作業です。
例／
ECアプリの場合：
・決済機能はどのような仕様にするか
・ポイントは付与するのか
・送料はどのように設定するかと
など１つ１つの機能・性能を決定していきます。
通常、発注者がアプリ開発会社からヒアリングを受けて要件定義を行うのが一般的です。
この要件定義をアウトプットしたものを「要件定義書」と言います。
要件定義書は、アプリ開発における設計図のようなものです。
設計図がなければものが作れないのと同様、
要件定義書がないまま開発を進めてしまうと、意図と異なるものが出来上がる可能性があります。
6. 設計・デザイン
要件定義が完了したあとは、アプリの設計を決めます。
アプリの設計は、大きく以下の２つに分類できます。
＜基本設計＞
操作画面のレイアウトやデザイン、操作方法などの設計
画面設計において、大切なのはUI（ユーザーインターフェース）*です。
数多くのアプリがある中では、たとえ高機能であっても使いにくいアプリは選ばれません。
ユーザーが見やすい・直感的に使いやすいデザインやレイアウトを意識しましょう。
＜詳細設計＞
アプリのシステム部分の詳細の設計
要件定義で決められたアプリの動作をどのように実現させるかを設計していく工程です。
プログラミング言語やデータ処理方法などを設定していきます。
＜用語解説＞
UI*：User Interface＝ユーザーインターフェースの略称です。
Interfaceは、「接点、接触面」という意味を持ち、
レイアウト・画像・フォント等のデザイン、ボタンの操作性など
ユーザーが目にするもの・操作するもの全般を示します。
7. 開発・実装
開発・実装段階では、要件定義・設計に基づいて、
プログラミング言語やシステムを駆使してコーディング作業を行います。
コーディングは専門知識が必要なため、外注する場合は開発会社が行っていきます。
素人目には進捗状況を確認することが難しい部分ですが、任せきりにせず、
定期的に進捗状況を共有するミーティングを行いましょう。
また、部分的でも構いませんのでシステムが正しく動作するか確認できると良いですね。
※最近は、コーディングなしでアプリを作るツールもありますが、開発できる種類が限られます。
何の制約を受けずにアプリを開発したい場合はコーディング作業は必須です。
8. テスト
最終段階では、ユーザーが実際にアプリを使用する状況と同様の設定でテストを行います。
・設定したOSでアプリが起動するか
・システムが想定通り動作するか
・アプリの機能や性能が要件定義や設計段階で設定した基準を満たしているか
など、検証しなければならないポイントは多数あります。
テストは開発の最終段階で行われるのですが、万一この段階で不具合が発覚した場合は、
リリース日を後ろ倒しさせないために早急な修正する必要となってしまいます。
そのため余裕を持ってテストに入ること・環境を事前に整えておくことが必要でしょう。
いくら高品質でユーザーにとって有益なアプリでも、
不具合だらけではアプリ・企業に対する印象を悪くさせてしまいます。
どれだけリリースを急いでいても絶対にテストは行いましょう。
9. 納品
テストを無事クリアすると、アプリが納品されます。
アプリのほかに、仕様書やソースコード、テスト結果報告書などが納品されますが、
ここで注意すべき点として、納品後の「アプリの保守・運用について」が挙げられるでしょう。
「ソースコード納品」*と「バイナリ納品」**の2種類があり、
納品方法によって保守運用について大きく異なるのでご注意ください。
＜用語解説＞
ソースコード納品*：
ソースコード、つまりアプリのプログラムコードを納品してもらう方法です。
保守・運用は自社で行うことが一般的ですが、自社で保守・運用するには
納品の際にコーディングや開発に使ったシステムなどの詳細情報を確認しなければなりません。
対応できる人材がいない場合、別途保守・運用を依頼する、人材を採用する必要があります。
バイナリ納品**：
アプリの著作権を開発会社が持つ納品形態です。
納品された側が気をつける・準備しておくことはあまりありません。
いかがでしたでしょうか。
少しでも参考になる情報がありましたら幸いです！