アプリ開発の手法としては 「ウォーターフォール開発」「アジャイル開発」 という2つの開発手法がある。
ウォーターフォール開発は、業務システムなどの大規模なシステム開発で使われることが多い手法です。 すべての要求に対し、『企画→計画→設計→実装→テスト』の各工程を段階的に終わらせていくのが最大の特徴です。 初めに要件定義を行って全体の機能設計を固めるため、余裕を持たせた進行計画を立てて動き出すケースが多く、 予算が立てやすい・チームメンバーのアサイン計画が立てやすいといった特徴があります。 開発の途中で要件の変更や設計の不備が見つかってしまうと、相当な対応が必要な状況が発生することもあります。
アジャイル開発はリリースまでの期間が短く、開発途中の仕様変更・要件変更にも柔軟に対応できる新しい開発手法です。 『計画→設計→実装→テスト』といった開発工程を機能単位の小さいサイクルで繰り返すのが大きな特徴です。 アジャイル開発は優先度の高い重要な機能から着手できるので、素早くサービスインしてから徐々に機能を追加していくことができます。 仕様・要件ごとにスケジュールを設定するため、全体的なスケジュールのコントロールが難しい傾向にあります。
ウォーターフォール開発ではアプリやサービスの開発は以下の手順で行われます。 なおアジャイル開発はこれら(1~6)が機能単位で行われます。
- 企画
- 要件定義
- 基本設計(外部設計)
- 詳細設計(内部設計)
- 開発(実装)
- テスト(単体テスト,結合テスト,統合テスト)
- デプロイ(リリース)
- 保守運営
どんなアプリやサービスを開発するのかを企画します。 具体的には企画の段階で以下のようなことを考えまとめます。
- アプリ・サービス開発の目的と内容
- 数値をあげた具体的な目標、達成までの手段
- アプリ・サービスをリリースするまでのスケジュール
- 収支計画
さまざまな課題の中で、アプリで解決できる課題を選んでいきます。 現状、どのような課題があり、アプリでどのように解決できるかといったことを整理していきます。 アプリ開発の目的や内容を明確にすることで、アプリに搭載すべき機能や最適な設計といったことから、リリース日までを明確に設定にできるようになります。
アプリの目標を明確にし、目標を達成するまでの手段を決めていきます。 「売り上げを〇％アップしたい」などのように、目標を数値化することが重要です。 数値化することによって、行動計画の立案が容易になり、達成度がわかりやすくなります。 また、目標を達成するためにターゲットにどのように訴求していくかをいうことも決めておくとよいです。
アプリ開発からリリースに至るまでのスケジュールを明確にしておきます。 リリース日が決まっていないと、より良いものを求めすぎて開発期間が延び、最適なタイミングでリリースできなくなってしまう可能性もあります。 スケジュールを立てる際には、開発期間だけではなく、アプリが正常に作動するかを確認するテスト期間や、修正が発生した際の修正期間もあらかじめ組み込んでおくことが重要です。
10万円以下で開発できるアプリもあれば、高機能を追及していけば開発費用が数千万円に上るものもあります。 せっかくアプリ開発をしても、赤字を出してしまってはそのプロジェクトは成功とは言えません。 企画書には、おおよその収支計画を記載しておきます。 そのうえで、アプリ開発にかけられる予算を割り出し、その予算内でアプリ開発を企画していきます。
要件定義で決めるべきことには、次のような項目があります。 システムのバグ修正などの品質管理に関することや、使用するフレームワーク、サーバー構成に関する取り決めなどもここで話し合っておくとよいでしょう。
- システム化の目的
- システムの概要、構成
- 実装する機能（機能要件）
- 求める性能やセキュリティ（非機能要件）
- 導入・移行計画
- スケジュール
- 人員の体制
基本設計は「要件定義の結果（WHAT）を「HOW」に落とし込む」作業と言えます。 基本設計はエンドユーザにとっては「機能の説明書」のような役割を果たします。 具体的には以下のような設計を行います。
- 画面設計 ・・・ 開発するWebアプリにどのような画面・パーツ・デザインを搭載するかを設計します
- 方式設計 ・・・ 開発するWebアプリに必要となるインフラ・フレームワーク・プログラミング言語や、セキュリティ方針・コーディング方針などを決めます
- 機能設計 ・・・ 開発するWebアプリの要件定義で決定した機能を実現するために必要な条件や動作などをリストアップします。同時に、バックグラウンドでの処理も決定します
- データベース設計 ・・・ データベースのスキーマの定義やER図、CRUD図などを作成します
また設計にあたって作成する文書や図は以下のようなものがあります。
| 図・文書 | 説明 |
|---|---|
| 機能一覧表 | 開発する機能を一覧にまとめます。新規アプリケーション開発の場合は外部設計のベースとなります |
| 業務フロー図 | 要件定義フェーズで確定していない場合は外部設計として作成します |
| 画面設計書 | ユーザーが操作する各画面の構成、及び画面遷移図を設計します |
| 帳票設計書 | 帳簿、伝票などの出力項目、レイアウト、出力タイミングなどを設計します |
| インターフェース設計書 | アプリケーションが外部とインターフェースする部分を設計します |
| データベース設計書 | データを格納するテーブルを定義します。一般的にはER図を用います |
| 外部ファイル設計書 | 入出力するファイルのフォーマットを定義します |
| ハードウェアインターフェース設計書 | ハードウェアの制御方法を記載します |
| 他アプリケーションとの関連図 | 他アプリケーションとの関連、接続方法を記載します |
| セキュリティ設計 | 要件定義のセキュリティ要件に対する具体的な対応内容を記載します |
多くのアプリケーションでは、外部設計での主な作業は画面設計です。 全体の画面遷移、及び各画面の設計を行います。 次のようなものを設計します。
- ワイヤーフレーム(画面レイアウト) ・・・ webページのレイアウトを決める設計図
- 画面一覧表 ・・・ 各画面にどういう機能や文があるかをまとめて一覧にしたもの
- ディレクトリマップ ・・・ webサイトを構成するすべてのwebページの情報をまとめて、一覧にしたもの
- 画面遷移図(サイトマップ) ・・・ システムの画面遷移を図で表したもの など
アプリやサービスにどのような機能が必要なのかをまとめていく工程です。 次のようなものを設計します。
- 機能一覧表 ・・・必要な条件や動作などをリストアップしたもの
- ユースケース図 ・・・ システムで何ができるかを「利用者目線で」表現する図
開発するWebアプリに必要となるインフラ・フレームワーク・プログラミング言語や、セキュリティ方針・コーディング方針などを決めます。
データベースの設計を行います。 次のようななものを設計します。
- テーブル定義書 ・・・ テーブルを作成するための定義書
- ER図 ・・・ 実体と関係という概念を用いてデータ構造を図にしたもの
- CRUD図 ・・・ 「Create」「Read」「Update」「Delete」の操作がどのテーブルに対して行われているかを画面(機能やユースケース)ごとに記載したもの
詳しくは https://gist.github.com/teslasand0987/9ea1d88c141d602eed804b9a947a4edb
詳細設計とは、基本設計で決定した内容を基に、ユーザーからは見えないシステム内部の動作・機能を設計して、実際にプログラミングできる内容に詳しく落とし込む工程です。 具体的には以下のような設計を行います。
- モジュール設計 ・・・ Webアプリの機能実装に必要なモジュールの選定や分割を細かく設計します
- データ設計 ・・・ Webアプリのデータを保存するデータベースの選定・データ処理の流れ・データの保存場所などの細かい設計を行います
- プログラム設計 ・・・ 設計した内容を実装できるように、プログラミング可能なレベルまで詳しく設計します。具体的には、実装内容・手順をドキュメントに直した設計書の作成等を行います
また設計にあたって作成する文書や図は以下のようなものがあります。
| 図・文書 | 説明 |
|---|---|
| DFD図 | 「システムの機能」と「システムで扱うデータ」の流れを表現する図 |
| クラス図 | システムの静的な構造・関係性を視覚的に表現するための図 |
| モジュール構造図 | モジュール化が用いられたシステムを構成するモジュールがどのように分割されて、各モジュールがどのような処理を行うかを示した設計図 |
| アクティビティ図 | 「システム実行時における一連の処理の流れや状態遷移をあらわす図(フローチャート) |
| シーケンス図 | オブジェクト間のやりとりを時系列にそってあらわす図 |
設計が完了したあとは開発作業に入って実際にプログラミングをしていく工程です。
Gitを用いた分散型開発の場合は基本的に以下の繰り返しで開発を進めていきます。
- タスクごとにブランチを作成
- 何らかの機能や改修を実装
- 単体テストや結合テストを実装
- github上でプルリクエスト作成
- レビューを受け修正
- マージ7. 1に戻る
設計された内容を取りこぼし無く実装出来ているのかをテストしていきます。 開発中のアプリをどういった方法でテストするか、どんなテストツールを使用するかを設計します。
実装されたコードが設計書に記載された通りにきちんと動くのか検証するテストです。 画面上に見える部分と裏側のデータ双方で、細かい部分の洗い出しが必要となります。
結合テストとは、モジュール間の結合状態などについて確認するテストのことです。
全てのモジュールを結合した最終テストのことです。
