2018年現在、スマホアプリは企業のIT戦略やマーケティングチャネル・サービスのユーザー体験向上や課金収益などを目的に、多くの企業で当たり前のように開発されるようになりました。

新規事業担当者やWebサービス担当者の皆さんも、アプリ開発について企画していたり上司から言及されたりしているのではないでしょうか。

でも、スマホアプリ開発といっても具体的に何をやればいいのか、初めて携わる人にとっては難しいものがあると思います。作りたいものは決まっているけど、実際にどのようにしアプリ開発が進むかわからない、といった声をよく聞きます。

Webでスマホアプリ開発の流れ(フロー)について検索しても、企画の仕方や開発者向けの情報ばかりで、スマホアプリ開発の全体像や基本的な流れ(フロー)を紹介した記事はなかなか見つかりません。

そこで、この記事ではまずスマホアプリ開発の全体像と基本的な流れ(フロー)を紹介します。次に、各工程の概要と気をつけるべきことを紹介し、スマホアプリ開発に携わる上で知っておきたい最低限の知識をお伝えします。

まずおさえておきたい2つの開発手法

スマホアプリ開発の全体像と基本的な流れは、開発の進め方によって異なります。開発の進め方は「ウォーターフォール型」と「アジャイル型」の2つに分けることができます。まずはこの2つの特徴をおさえましょう!

ウォーターフォール型:決まった仕様・予算・納期にオススメ

ウォーターフォール型の開発は、業務システム開発や大規模なシステム開発で使われている手法です。

ウォーターフォールという言葉が表すように、全ての要求に対して要件定義や設計・開発や検証を段階的に終わらせていく手法です。

”何を作るか”が最初に決まっているため見通しが立てやすく、予算や納期のコントロールがしやすいのが特徴です。

予算や納期をコントロールしやすいことは発注側にとって嬉しいことですが、ウォーターフォール型の開発が成功するためには、最初に完璧な要件定義と設計を行う必要があります。

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

アジャイル型:不確実な仕様・柔軟な対応・細かな改善に強い

アジャイル型の開発は、主にアメリカや日本のスタートアップで使われている手法で、Webサービス開発やスマホアプリ開発に向いています。

アジャイル型もウォーターフォール型と同様に、要件定義や設計・開発や検証を行いますが、これらは機能(ユーザーストーリー)単位で行います。

ウォーターフォール型が1回の大きなサイクルを回す開発手法だとしたら、アジャイル型は小さなサイクルを何回も回す開発手法と言えます。

そのため、仕様の変更について柔軟に対応することができ、細かく改善しながらプロダクトを開発していくことができます。

一方で、仕様の変更やプロダクトの改善を許容する手法なため、発注する段階では予算が不確実だったり、納期も余裕を持った提示をされるなど、コントロールしづらい場合があります。

どちらを選べばいいのか?

ウォーターフォール型は、業務システム開発や大規模なサービスの開発、仕様が固まっている(変更する可能性が低い)プロダクト、予算や納期が決まっていて変更が難しいプロジェクトにオススメです。

アジャイル型は、仕様があまり決まっていない(変更が多く発生しそうな)ものや、ユーザーファーストで細かなユーザーテストを基に改善を重ねていきたい方針のプロジェクトにオススメです。

なお、ウォーターフォール型の開発であれば受注側とは請負契約を、アジャイル型の開発であればラボ契約を結ぶことをオススメします。

請負契約は受注側が成果物に対して責任を負う契約形態ですが、ラボ契約は人材を期間で契約する形態でありアジャイル型の開発と相性が良いことで知られています。

では、ウォーターフォール型とアジャイル型のそれぞれについて、スマホアプリ開発の全体像と基本的な流れ(フロー)、各工程の概要と気をつけるべきことを紹介します。

ウォーターフォール型のスマホアプリ開発

ウォーターフォール型開発の全体像と基本的な流れは以下の図のようになっています。

まずは企画からスタートし要件定義を行います。ここで何を作りたいかが決まるので、その後は外部設計や内部設計といったどうやって作るかを決める作業に入ります。

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

企画:情熱を全力で伝えよう

企画書にアプリの詳細な仕様やデザインを頑張って書く方がいますが、UIやコンテンツ・アプリを面白くする仕組みはその道のプロ(ディレクターなど受注側)に任せた方が良いです。

発注側の皆さんに力を入れて伝えていただきたいのは「自社のビジネスについて」「アプリを作る目的やビジョン」「ユーザーに提供したい体験」の3つです。

これを受注側としっかり(情熱を持ってあなたの言葉で)共有することで、その後のフェーズでの認識齟齬を抑えることができます。

要件定義:手間と時間を惜しまず詳細に決めましょう

何を作るかを決める大事なフェーズです。

ここで決まった項目を満たしていることが、納品できるか否かの判断基準になります。

要件定義で決めたことは、必ずドキュメントに落としておきましょう。

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

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

外部設計はワイヤーフレームやデザインなど、目に見ることができ発注側にもわかりやすい成果物ができるフェーズです。

発注側にとって楽しく、新たなアイデアが出やすく、口を挟みやすいです。

そのため、最も期限が後ろ倒しになる、延長されやすいフェーズでもあります。

最善のものを求めることも良いですが、どこかで一区切りし次のフェーズへのGOサインを出す必要があります。

このサインを出すのは発注側の皆さんであることを自覚しておきましょう。

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

このフェーズは、要件定義や外部設計を基に受注側で進められるため、進捗や成果が見えにくいです。

そのため「受注側に任せて何もしないでおこう」と思いがちですが、進捗や成果は確認しましょう。

定期的にミーティングを設け、タスクの消化率を報告してもらいましょう。

できればシステムが動くかを部分的にでも確認することが望ましいです。これは小話ですが、タスク進捗率90%のときの、残り10%の進みの遅さは業界では有名です。気をつけましょう。

テスト:予算や期間を削られやすいフェーズですが…

さて、要件定義や外部設計の期間が延長され、実装がスケジュールよりも遅れました。

でも納期を変更することはできません。こうなったとき削られやすいのはテストです。

テストフェーズでは実装の成果物がちゃんと動くかどうかをテスト仕様書を基に検証します。

このフェーズでバグを抑えリスクを回避することが重要なのですが、成果物が既に見えてしまっている以上、どうしても削られがちです。

しかし、削ったがためにアプリをリリースした後に致命的なバグが発生した、セキュリティが脆弱で情報漏洩につながってしまい企業ブランドが失われた、なんてことになるかもしれません。

納期をズラしてでも、テストはしっかり予算と期間をとりましょう。

納品:プロダクトだけではなくドキュメントも確認しましょう

テストが無事終われば納品です。

要件や設計通りにアプリが実装されているかを確認するのはもちろんですが、各フェーズの成果物も確認しましょう。

また、たまに見受けられるのはiPhoneアプリを「Appleの審査が通る前に納品完了」してしまうことです。

審査に通らないと設計や実装レベルの改修が必要になる可能性があるため、納品基準には「iPhoneアプリがリリースできる状態になること」といったことを加えておきましょう。

アジャイル型のスマホアプリ開発

アジャイル型開発の全体像と基本的な流れは以下の図のようになっています。

要件定義や設計・実装やテストはアジャイル型でもありますが、最初に全ての要件を決めるのではなく、決まった期間で実装ができそうな量だけを決めていきます。

開発サイクルを繰り返して少しずつアプリを成長させていくイメージです。

各フェーズでの気をつけたい点はウォーターフォール型と大体同じなので、ここではアジャイル型開発の気をつけたい点を紹介します。

チームビルディングやアジャイルの習慣に積極的に参加しよう

アジャイル型の開発ではチーム環境を整えることが大事です。

これはアジャイルの「レフトウィング」とも呼ばれており、アジャイル型開発の成功に必要な要因の1つです。

例えばアジャイル開発では、毎日朝会を行ったり、イテレーション(反復期間)ごとに振り返りの場を設けています。

もし開発チームから誘われたら積極的に参加し、発注側と受注側の関係ではなく、あなたも含めた開発チームになるようにしましょう。

アジャイルだから企画や仕様は深く考えなくていい、ではない

アジャイルだからといって「とりあえず実装してみて、後から考えよう」と考えることはオススメしません。

いくら仕様変更に強いといっても、無駄な開発をしてもいいというわけではありません。

思いつきの機能をそのまま実装していては要件が膨れ上がり、いつまでも終わらない開発になってしまいます。

実装に進む前に、この機能は本当にユーザーが必要とするのかを考え抜いた上で、本当に必要な機能だけを要件にしましょう。

アジャイルだからドキュメントは書かなくていい、ではない

「アジャイル開発なのでドキュメントはありません。ホワイトボードと付箋しかないです。」と開発チームが言っていたら危険です。

上記で「発注側と受注側の関係ではなく、あなたも含めた開発チーム」と書きましたが、いつまでも今の開発チームを使うとは限らず、別のチームに引き継ぎを行う必要があるかもしれません。

そのときに何もドキュメントがないと、引き継ぎは困難を極めます。

無駄なドキュメントを書く必要はありませんが、モデル図など現在のシステムを表すドキュメントは必ず作ってもらうようにしましょう。

アジャイルだからシステム設計は暫定対応でいい、ではない

柔軟な対応と暫定対応は異なります。

アジャイル型だからと言って、機能の要件が出てくるたびに暫定対応をしていては、システム全体の設計が悪くなってしまいます。

そうならないためにも、ある程度のアプリの未来や方向性は共有しておきましょう。

システムを設計する際、未来を想定してシステムを設計することで、柔軟な対応ができるようになりシステムの設計が良くなります。

アジャイルだから計画通りに進まなくても仕方がない、ではない

アジャイル型の開発では、チームの立ち上がりに多少の時間がかかります。

アジャイルをチームに浸透させる時間や相互理解が必要なためです。

そのため、初期は予想していたスケジュールよりも大幅にズレることもあります。

ただし、開発を進めていくうちに相互理解が進むと、徐々にスケジュールを立てやすくなり、最終的には決められた期間でどれくらいの量が実装できるかを高い確度で予想することができます。

なので、開発が進んでしばらく経っても計画とズレるようであれば、チームマネジメントがうまくいっているかを確認した方がよいでしょう。

番外編:3つの落とし穴に気をつけよう

ここまで、スマホアプリ開発の全体像と基本的な流れ、各工程の概要と気をつけるべきことを紹介しました。

上記の他にも、スマホアプリ開発初心者の皆さんが陥りやすい3つの落とし穴があるので紹介します。

見積もり書の金額しか確認しない

見積もり書は金額だけを確認するものではありません。

見積もり書(またはこれに関する契約書)に書いてある見積もりの前提条件や契約事項を確認しましょう。

自分が不利になる契約事項が書いていないか、対応デバイスやOSに認識齟齬はないか、納品物はなにか、等あとから困らないようにしっかりと確認しておきましょう。

稟議や承認プロセスを把握・共有していない

あなたが主に前面に立って開発チームとやりとりをするかと思いますが、要件定義やデザインコンセプト・ワイヤーフレームの最終決定(承認)者は、多分あなたではなくあなたの上司だと思います。

それを開発チームとも共有しておかないと、予想していなかったところで時間がかかったり、上司の承認を得なかったために開発フェーズで大きな仕様変更やデザイン変更が発生することが十分にありえます。

他部署のルールや自社のコンプライアンスを理解していない

よく忘れられがちなこととして、他部署との連携やルール、自社のコンプライアンスにアプリが沿っているかを確認することがあげられます。

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

まとめ:困ったら一人で悩まず、専門家に相談しよう

以上が、スマホアプリ開発の全体像と基本的な流れ、各工程の概要と気をつけるべきことの紹介でした。

かなり簡単にまとめたつもりですが、それでも量が多くなってしまいました。

本当はもっと気をつけてほしい点があります。

スマホアプリ開発は決して簡単なものではありません。もしスマホアプリ開発で困ったことや疑問点があったら、一人で悩まずに専門家に相談しましょう。

Related Post

11月弊社セミナー3回目開催のお知らせ

イベント

10月弊社セミナー2回目開催のお知らせ

イベント

ITプロダクト品質を保証する新サービス「テスター・ラボ」を開始いたしました

ニュース