アプリ開発の基本的な流れと工程を紹介　ウォーターフォール開発とアジャイル開発の違いは？

現在、アプリの開発を企画中という方、ちょうど上司から言及されたばかりという新規事業担当者・Webサービス担当者の方も多いのではないでしょうか。

しかし、“アプリ開発”と一口に言っても、具体的に何から進めればいいのか「アプリ開発に携わるのは初めて」という人には難しいことばかり。「作りたいアプリのイメージは決まっているけど、実際どのようにアプリ開発が進むのかわからない」という声をよく耳にします。

インターネットでアプリ開発について検索しても、企画の仕方や開発者向けの情報が出るばかりでアプリ開発の全体像を紹介した記事がなかなか見つからないのも現実です。

そこで本記事では、アプリ開発の基本的な流れ・工程からウォーターフォール開発とアジャイル開発の違いまで徹底解説。アプリ開発に携わるうえで知っておきたい基礎知識を紹介していきますので、ぜひ参考にしてください。

➡︎【資料ダウンロード】DX推進に欠かせない「アジャイル手法」の教科書

アプリ開発には2つの開発手法がある

アプリ開発の全容を知るうえで、まずはじめに理解しておきたいのが、「ウォーターフォール開発」「アジャイル開発」という2つの開発手法があること。

開発の進め方自体が違うので、基本的な流れや工程が大きく異なります。まずは、この2つの手法の特徴をしっかりと把握しておきましょう！

➡︎【資料ダウンロード】DX推進に欠かせない「アジャイル手法」の教科書

アプリ開発手法①　ウォーターフォール開発

ウォーターフォール開発は、業務システムなどの大規模なシステム開発で使われることが多い手法です。すべての要求に対し、『企画→計画→設計→実装→テスト』の各工程を段階的に終わらせていくのが最大の特徴。

はじめに要件定義を行って全体の機能設計を固めるため、余裕を持たせた進行計画を立てて動き出すケースが多く、予算が立てやすい・チームメンバーのアサイン計画が立てやすいといった特徴があります。一方で、定められたスケジュールと予算に対して費用対効果が求められ、またその効果においてはリリース後にしか確認が得られず、事前に綿密な顧客ニーズの調査と計画が不可欠となります。つまり、最初の段階で完璧な要件定義と設計を行うことが必要であり、ウォーターフォール開発で成功を収めるための秘訣といえます。

もしも開発の途中で要件の変更や設計の不備が見つかってしまうと、”どんでん返し”に近いレベルの対応が発生することも……。再び見積もりからスタートすることになり、結果として予算が増えたり納期が遅れる原因になります。

なお、ウォーターフォール開発の場合、開発を委託する制作会社と請負契約を結ぶのがベスト。請負契約は受注側が成果物に対して責任を負う契約形態です。

➡︎【資料ダウンロード】アプリ開発を失敗しないためのチェックリスト

アプリ開発手法②　アジャイル開発

アジャイル開発はリリースまでの期間が短く、開発途中の仕様変更・要件変更にも柔軟に対応できる新しい開発手法。『計画→設計→実装→テスト』といった開発工程を機能単位の小さいサイクルで繰り返すのが大きな特徴。

旧来のウォーターフォール開発は初めにプロジェクトの要件定義や設計を細部まで煮詰める必要がありましたが、アジャイル開発は優先度の高い重要な機能から着手できるので、素早くサービスインしてから徐々に機能を追加していくことができます。その間、ユーザーのフィードバックが得られるため、徐々に機能改善を取り入れることでよりニーズに応えられるサービスが提供でき、または少ない投資額や早い段階で軌道修正を行うリスクヘッジが可能となります。

「プロジェクトに変化はつきもの」という前提で、クライアントとのコミュニケーションを重要視して開発を進めるため、プロダクトの価値を最大化できる手法としてDX（デジタルトランスフォーメーション）推進の観点からも注目されています。

ただし、どんな機能を追加するのかあらかじめ決まっているケースばかりではないため、発注段階では最終的な費用の総額を試算することが非常に困難です。また、仕様・要件ごとにスケジュールを設定するため、全体的なスケジュールのコントロールが難しい傾向にあります。

➡︎【資料ダウンロード】アプリ開発を失敗しないためのチェックリスト

アジャイル開発の場合は、開発会社とラボ契約を結ぶのがオススメ。ラボ契約は人材を期間で契約する形態なので、アジャイル開発との相性が抜群です。

★アジャイル開発について詳しくはこちら：

➡︎【資料ダウンロード】DX推進に欠かせない「アジャイル手法」の教科書

ウォーターフォール開発の流れ・工程

ウォーターフォール開発の全体的な作業の流れを解説していきます。それぞれの工程ごとにポイントを挙げて解説するので、ぜひ参考にしてください。

まずは企画からスタートし、要件定義を行います。ここでしっかりと“何を作りたいか”を固めて、外部設計や内部設計などの“どうやって作るか”という部分を決めましょう。

設計が済んだら、実装とテストを経て納品という流れになります。デザインは外部設計の前後、または同時に行われることが多いです。

工程①　企画：情熱を全力で伝えよう

企画書の中にアプリの仕様やデザインを詳細に書くこともできますが、コンテンツやアプリをおもしろくする仕組みやUIに関してはその道のプロ（制作会社のディレクターなど）に依頼した方がうまくいくケースが多いです。

むしろアプリ開発を発注する側がより注力しなければならないのは「自社のビジネスについて」「アプリを作る目的やビジョン」「ユーザーに提供したい体験」の3つを深く考えること。

制作会社との間で正しくアプリ開発の意図や完成イメージを共有できていれば、その後のフェーズでの認識齟齬を抑えることができます。ご自身の言葉で情熱を持って伝えれば難しい専門用語でなくてもきちんと伝わるでしょう。

★成功するアプリ開発の企画書を作るためのポイントについて詳しくはこちら：

工程②　要件定義：手間と時間を惜しまずに詳細を煮詰めよう

要件定義は、“何を作るか”を決める重要なフェーズ。ここで決まった項目を満たしていることが、納品できる状態かどうかの判断基準になります。要件定義で決めたことは、必ずテキストベースにまとめて記録を残しておくようにしましょう。

また、要件定義ではわかりやすい機能ばかり注目されがちですが、セキュリティやサービスの提供速度など非機能要件についてもしっかりと制作会社に確認しておきましょう。

後々の考慮漏れや認識齟齬による開発修正はコストが高く（遅い段階であればあるほど、コストは増加します）、トラブルの火種になる恐れもあります。

上層部に限らず、オペレーションに関わる全てのステークホルダーの方々を巻き込み、特に暗黙のルールとして存在する言語化されていない要件も含め、適切なヒアリングを実施することでリスクを防ぎましょう。

★ソリューションアーキテクトが実践する失敗しない要件定義について詳しくはこちら：

工程③　外部設計：いつまでも議論できてしまうことを自覚しよう

ワイヤーフレームやデザインなど、外部設計は目に見える形で成果物ができるフェーズ。そのため、このタイミングで新たなアイデアが出てきたり、上層部から意見・要望が飛び出すこともしばしば。最も期限が後ろ倒しにされやすい延長しがちなフェーズでもあります。

最良を追求するのは当たり前のことですが、どこかで区切りをつけて次のフェーズへのGOサインを出さないと先に進まなくなってしまいます。見た目の話なので議論がつきにくいということもあらかじめ理解しておくといいでしょう。

要件整理のための議論なのか、またはデザイン性を追及するための議論なのかで、目的に応じて資料を使い分けることも重要です。例えば、機能要件を重視した画面設計レビューの際は、デザインについて極力触れないよう、機能に特化したシンプルなワイヤーフレームを活用することで、より論点に着目した議論が可能となります。

工程④　内部設計・実装：積極的にコミュニケーションをとろう

要件定義や外部設計を基に制作会社側で作業を進められるため、内部設計・実装は進捗や成果が見えにくいフェーズ。

つい「制作会社に任せておけば大丈夫だろう」と思ってしまいがちですが、進捗や成果をしっかり確認しておくことが肝心です。定期的に制作会社とミーティングを設け、タスクの消化率をその都度報告してもらいましょう。また、進捗率の定義を予め認識を合わせることも重要であり、何を以てして何%なのかを先方の意見も踏まえて合意を取りましょう。

部分的でも構わないので、可能であればシステムが正しく動作するか確認しておくことが望ましいです。例えば、設計段階まではスムーズに進んだとしても、未把握のリスクにより製造が滞っていたり、機能部分の実装のみ進めてしまい予定されていたデザイン周りが疎かになってしまうなど、計画と実態が異なるケースは多々あります。そのような要因から、タスク進捗率90%からの残り10%の進みが非常に遅いというのは、アプリ開発業界あるあるなので気をつけましょう。

工程⑤　テスト：しっかり計画を立て、予算と期間を確保しよう

テストは、実装した成果物が正確に動作するかテスト仕様書を基に検証するフェーズ。ここでバグを抑えてリスクを回避することが肝心なのですが、成果物として既に完成形が見えてしまっていることもあってどうしても予算や期間を削られがちです。

しかし、テストの工程を削ったことが原因で、のちのち思わぬトラブルに発展してしまうことも。リリース後に致命的なバグが発生したり、セキュリティが脆弱で情報漏洩につながってしまい企業ブランドが失われた…なんてことになってしまいかねません。

また、プロジェクトを中止に追い込む可能性のあるリスク要因は特に、関係者全員で共有し認識しておくことが重要です。事前把握により適切なリスク管理ができれば、最優先でテストを計画することで対策も取りやすくなります。

その他、アプリが接続するサーバーや外部システムなどが存在する場合、検証環境構築が必要になるので、関係者の巻き込みとそれらの行程もスケジュールに考慮する必要があります。アプリが完成しているのにテストができないというケースは珍しくありません。

しっかりとした計画を立てることで適切なリスクヘッジを行い、健全な予算と期間をテストフェーズに割り当てることがプロジェクトの命運を決めるといえましょう。

工程⑥　納品：プロダクトだけではなくドキュメントも確認しよう

テストが無事に終わればいよいよ納品です。要件や設計通りにアプリが実装されているか確認するのはもちろんですが、各フェーズの成果物もしっかり確認しましょう。

アプリを公開するにあたり、App Store や Google Play へのストア申請が必要になります。それぞれの審査は厳しく、ケースによっては数回やり取りが発生し得るため、リリースフェーズはある程度期間に余裕を持たせて計画を立てましょう。

また、よくある誤りとして、例えば、iPhoneアプリを「App Storeの審査が通る前に納品完了」にしてしまうことです。審査に通らないと設計や実装レベルの改修が必要になる可能性があるので、納品基準に「iPhoneアプリがリリースできる状態になること」といった一文を加えておきましょう。

➡︎【資料ダウンロード】DX推進に欠かせない「アジャイル手法」の教科書

アジャイル開発の流れ・工程

続いて、アジャイル開発の全体的な作業の流れを解説していきます。

アジャイル開発にも要件定義・設計・実装・テストといった工程は存在しますが、最初にすべての要件を決めてスタートするウォーターフォール開発とは大きく異なります。

決まった期間内に実装できそうな量を決めて機能ごとに開発していくのがアジャイル開発の特徴。開発サイクルを繰り返して、少しずつアプリを完成形に近づけていくイメージです。

各フェーズごとの注意点はウォーターフォール開発とほほ同じですが、特にアジャイル開発において気をつけるべきポイントにフォーカスして紹介します。

ポイント①　チームビルディングが成功の鍵を握る

アジャイル開発では、チーム環境を整えることが肝心。アジャイルの「レフトウィング」とも呼ばれており、アジャイル開発の成功に必要な要因の1つです。

チームメンバーが当事者意識を持ち、各々と密な連携を行なうことが重要になります。また日々のコミュニケーションは不可欠であり、常に改善点や反省点を共有し合えるチームになることで組織的な改善を継続的に実現することができます。

例えば、アジャイル開発では毎日朝会を行ったり、イテレーション（反復期間）ごとに振り返りの場を設ける慣習があります。もし開発チームから誘われた場合は、積極的に参加するといいでしょう。受発注の関係ではなく、あなた自身も含めた開発チームにすることが大切です。

★イテレーションについて詳しくはこちら：

ポイント②　無駄な開発を避け、必要不可欠な機能を考える

開発過程で調整を繰り返すアジャイル開発といっても「とりあえず実装してみて、後から考えよう」と安易に見切り発車してしまうことはおすすめできません。

製品が市場ニーズを満たせているか迅速に確認するためにも、最もバリュー期待値の高い機能や最低限必要な機能から優先的に開発を進めることが重要になります。製品（またはサービス）知見者を巻き込み、イテレーション毎に要件の優先度を整理することで、より角度が高く区切りの良いリリースサイクル計画が立てられます。その結果、要件が膨れ上がり、いつまでも終わらないような開発を防ぐことができます。

実装に進む前に「本当にユーザーが必要とする機能なのか」をしっかりと考え抜いたうえで、必要不可欠な機能だけを要件に残すようにしましょう。

★PoC(概念実証)について詳しくはこちら：

ポイント③　今後のことを想定し、最低限の資料を残す

機能ごとに開発サイクルを繰り返すアジャイル開発では、チーム内でのディスカッションや製造プロセス自体が優先されてしまい、議事録を残したり、仕様を資料に起こすプロセスが疎かになりがちです。例えば、「今回はアジャイル開発なのでドキュメントはありません。ホワイトボードと付箋しかないです」などと開発チームが言っていたら要注意です。

リリース後も徐々に機能やサービスをブラッシュアップしながら運用していくことを考えると、長いスパンでの開発が想定され、初期のチーム体制が維持されるとは限りません。メンバー同士やチーム間での引き継ぎを行う必要が発生した場合、資料が残っていなかったり、保管場所が管理されていなければ、引き継ぎは困難を極めるでしょう。

不必要な部分まで無駄に資料を残す必要はありませんが、あらかじめドキュメント作成のタスクを設定しておきましょう。モデル図など現在のシステムを表す重要な資料は必ず製作してもらい、チームがいつでもアクセスできるよう適切なツールを用いることで属人化を防ぎましょう。

ポイント④　運用開始後の方向性を共有することも肝心

柔軟な対応が可能なアジャイル開発とはいえ、機能の要件が出てくるたびに暫定対応をしているとシステム全体の設計が悪くなってしまいます。柔軟に対応することと暫定的に対応することでは、まったく意味が異なることをしっかりと理解しておきましょう。

事前に制作会社との間で、アプリで実現したいことや運用後の方向性についてしっかりと要件を共有しておくことが大切です。また一方通行なコミュニケーションにならないよう、書面に起こし、双方で合意を取った形で進めましょう。きちんと未来を想定してシステムを設計していれば、自然と柔軟な対応ができるようになり、システム全体の設計もより良いものになるでしょう。

ポイント⑤　チーム内の相互理解が高まればスケジュール管理が容易に

開発の流れをチーム全体に浸透させることやチーム内での相互理解を高めることが必要になるので、アジャイル開発のチームの立ち上げには多少の時間を要します。そのため、開発初期段階は予測よりもスケジュールが大幅にズレてしまうことも……。

しかし、開発を進めていくうちに相互理解がさらに進み、徐々にスケジュールが立てやすくなっていくのもアジャイル開発の特徴。最終的には「決められた期間内にどれくらいの量を実装できるか」を高い確度で予想することもできるようになるでしょう。

開発がしばらく進んでいる状況にも関わらず、計画と実績にズレが発生し続けるようであれば、チームマネジメントがうまくいっているか今一度確認してみてください。

★アジャイル開発について詳しくはこちら：

➡︎【資料ダウンロード】アジャイルな組織文化形成のための手引き書

アプリ開発を依頼するときに気をつけたい3つの注意点

これまで紹介してきたことに加えて、アプリ開発初心者が陥りやすい3つの注意点を紹介します。

注意点①　見積もり書では金額以外の項目も確認しよう

見積もり書は、単に金額だけを確認するための書類ではありません。見積もり書（またはこれに関する契約書）に記載されている見積もりの前提条件や契約事項を把握しておくことも肝心です。

自社にとって不利になる契約事項が盛り込まれていないか、対応デバイスやOSに認識齟齬はないか、納品の基準は何か……。曖昧なポイントを明示的に示していただき、あとあとになって困らないように、あらかじめしっかり確認しておきましょう。

注意点②　稟議や承認プロセスも開発チームと共有しよう

企業の新規事業担当者が矢面に立って開発チームとやりとりをするのが一般的ですが、要件定義やデザインコンセプト・ワイヤーフレームの最終決定者（承認者）は担当者よりも上のポジションの方が担うケースが一般的と言えます。

そのため、依頼側の稟議の有無やその承認プロセスを開発チームと共有しておかないと、予想していなかったところで時間がかかってしまうこともあります。

上司の承認がなかなか得られなかったために遅延が発生したり、開発フェーズで大きな仕様変更やデザイン変更が発生することも十分にありえるので注意しましょう。

注意点③　他部署のルールや自社のコンプライアンスを理解しよう

よくあるミスとして、他部署との連携漏れ、または自社ルールやコンプライアンスの確認漏れなどが典型的な例として挙げられます。アプリ開発を進めている部署内では既成事実として話が進んでいても、さらに強力な社内ルールがあとから見つかると話が根本からズレてしまいます。

アプリが完成後に自社のプライバシーポリシーに抵触することが発覚したため仕様を変更せざるをえなくなった…というようなことにならないように事前の調査や手配を怠らないようにしましょう。

➡︎【資料ダウンロード】DX推進に欠かせない「アジャイル手法」の教科書

まとめ：困ったら気軽に開発ベンダーに相談しよう

ここまで、アプリ開発の基本的な流れや各工程の概要・注意点を紹介してきましたがいかがでしたか？

アプリ開発が初めてという人にもわかりやすいようにかなり簡単にまとめましたが、記載しきれなかった注意点はまだまだたくさんあります。

アプリ開発を企画から完成まで導くことは、決して簡単なものではありません。費用面から大掛かりなプロジェクトになることも多いので、悩んでいることや疑問点があったらまずは開発会社に気軽に相談しましょう。

サービス・プロダクト開発を検討している企業ご担当者様へ

モンスターラボは、約20年にわたるサービス・プロダクト開発実績から得られたデジタル領域の知見や技術力を活かし、デジタルプロダクト開発事業を展開しています。

先端テクノロジーに対応した高度なIT人材があらゆるプラットフォーム上での開発を支援します。アジャイル開発とDevOpsによる柔軟な開発進行や、国内外のリソースを活用したスケーラブルな開発体制の構築も可能です。 また、リリース後の保守運用や品質向上支援まで伴走可能です。

モンスターラボが提供するサポートの詳しい概要は以下リンクをご確認ください。

➡︎モンスターラボのサービス概要はこちら

案件の相談はこちら