近年、スマートフォンの普及に伴い、SNSやショッピング、ゲームなど、様々なアプリが私たちの生活の一部になっています。

DX（デジタルトランスフォーメーション）プロジェクトにおいても、企業によるモバイルアプリ開発のニーズは増加傾向にあります。しかし、事業者側ではアプリ開発の知見がない場合も多いため、良いサービスを創っていくには開発者側のノウハウを伝えていくことも大切です。

本記事では、アプリ開発の具体的な手順や各フェーズでのポイント、さらに「本質的に良いサービスをつくるために必要な考え方」について開発者側目線で詳しく解説します。

※ウォーターフォールモデルでの開発フェーズの概要を2022年版として、iOSアプリ開発案件を発注するクライアントから案件の依頼の流れという前提で『見積』→『契約成立』→『要件定義』→『設計』→『実装』→『テスト』→『検収作業』を想定しています。

#1 見積フェーズ

まずは発注側に、企画書や画面イメージ、参考になる他アプリ等を提出していただき、見積金額を提示します。曖昧な仕様での見積もりを避けたい場合は、RFP（提案依頼書）があると尚良いです。発注側へ「RFPを作成して頂くほうがスムーズに進みます」と伝えてみると良いかもしれません。

もちろん、精度の高い見積もりのためにはヒアリングとしてQ&Aを繰り返すことが重要です。細かなヒアリングの前に、まずは簡単に確認したいことを整理します。

見積り時に確認したいこと

・対応するiOSバージョン
・iPadはiOSの互換モードで十分か、それともiPadアプリとして専用のUIでリリースしたいか
・企画書や画面イメージはすでにあるか
・参考になる他のアプリはあるか
・デザインを担当するのは発注側かこちら側か
・サーバー側を発注側が担当する可能性があるか

次に、さらに詳しくヒアリングしつつ、見積書に明記するべきことを整理します。

見積もり有効期限を明示する

提出する見積もりが概算であれ、見積書には有効期限を明示しましょう。打ち合わせを重ねていくうちに、明らかになっていなかった仕様が出てくることもあるので、見積書に有効期限を明示し、概算見積もりから再度詳細な見積もりを出すことを了承してもらうことが良いでしょう。

動作確認をする端末やOSのバージョンを明示する

動作確認をする端末やOSのバージョンを見積書に明記しておくことで、あらかじめやるべきことの線引をすることができます。新しいiOSや端末が出た場合は、別途見積をしましょう。あくまでも、管理をしやすくするために明示するのであって、記載された端末やバージョンだけの動作確認をすれば良い、ということではないので注意しましょう。

補足：毎年9月には新しいiOSと端末が発表されるのは規定路線ですので、例えば、10月にリリースするアプリが、最新のiOSや端末に対応していないということは避けたいところです。見積もり時には新しいiOSや端末については触れることができないならば、それは別途見積もりを行い、追加発注していただくことを前提にすることが重要でしょう。

納品条件を明示する

どういった形で納品するのかという条件も明記することが重要です。納品条件はクライアントによって様々です。主に以下の３つのパターンが考えられます。

・検証/検収が終わり、GitHubなどのバージョン管理システムへのpushまで
・AppStoreへのリリースまで
・AppStoreへのリリースから保守運用まで

リジェクト時の対応を明示する

Appleへアプリの審査を出した後にリジェクトされた場合、作業に再見積が発生するかどうかを想定しておくとよいでしょう。その場合、開発側の不適際なのか、発注者の要求だったのか等で切り分けることになります。

また、あらかじめリジェクト事例を別途提示することができればリジェクトされるリスクを減らすことにもなります。

見積もり自体の方法

私の経験上、見積で算出する数値は、機能ごとの工数とし、その工数を金額に変換したものを提示しますが、見積する工数については見積ポーカーと2点見積を複合したやり方で見積を行います。それらのメリットを詳しく知りたい場合は【PDF】ゲーム開発 プロジェクトマネジメント講座 – SQUARE ENIXを参照してください。

その他見積もり時に気をつけること

まず、発注側が知りたいことは、開発の規模感や他社と比較するための概算見積もりです。ただ、見積もりとして技術的に難しい場合、大きな工数や金額を見積もり時に出してしまうと話が進まなくなってしまうこともあるでしょう。そうならないためには、見積書には技術的に課題があるポイントや開発する上でのリスクを明示し、説明することで工数・金額の数字の妥当性を理解してもらいましょう。

また、この段階で仕様認識の齟齬もなくすようにしましょう。事前に齟齬を無くしたものが優れた見積書であり、プロジェクトのスタートダッシュだと私は考えています。

#2 要件定義フェーズ

要件を整理する

発注側とコミュニケーションをしながらリリースしようとするiOSアプリの目的やそのための要求を詰めていくフェーズです。打ち合わせを行い、要求を優先度順にまとめる等、ドキュメント作成作業の間、技術的に課題がある部分を洗い出すためのプロトタイプ作成を進めておくことも重要です。
ソフトウェア開発において、『安定した品質』『リリース日という納期』『機能の多さ』の全てを同時に満たすことはとても難しいことです。継続的に育てていく必要があります。そのためにも要求の優先順位を整理しておき、本当に達成すべきことを重点的に考えられるようにしましょう。

要求の実現方式の検討

複数の方法で設計と実装が出来る場合、発注者に方式検討のメリットやデメリット、それらの方法を選んだ場合の制限を提示しましょう。方式検討はメリットやデメリットをわかりやすくした表にすることが有効です。トラブル時に、なぜこの方法を選んだのか、なぜ他の方法を選ばなかったのかということをすぐに振り返ることもできます。

画面ごとの要件決め

発注側と開発側で画面イメージやワイヤーフレームを詳細にしていく際には、必ずAppleのヒューマンインタフェースガイドラインを参照するようにしてください。これは使いやすいアプリのためのドキュメントでもあり、ガイドラインに沿っていない等のリジェクトを防ぐために有効です。

#3 設計フェーズ

内部設計や開発指針をドキュメントとする

例えば、データベースとしてSQLiteを使う場合、テーブル定義書は必ず残すべきでしょう。さらに、なぜSQLiteを選択し、他を選択しなかったのかを明記すると良いでしょう。同様に、なぜ特定のOSSを採用したのか、他に検討した手段との違いは何かを明示することも重要です。

そのような技術的決定については、ADR（アーキテクチャ・デシジョン・レコード）と呼ばれるパターンがあります。
（参考：ソフトウェアアーキテクチャの基礎 – O’Reilly Japan＞

開発指針については、iOSアプリをどのように作っていくのかをあらかじめ決め、同様にADRとすることが良いでしょう。

まずはプレゼンテーションとドメインの分離（PDS）を大前提にし、その中で細かなMVP（Model-View-Preesnter）方式やMVVM（Model-View-ViewModel）方式などを選定するはずです。

また、要件定義フェーズで決まりきらなかった内容や後回しになった事を設計と並行して決めることになる可能性もあります。異常系の動作仕様のような優先順位が低く、時間的余裕もない場合は、要件定義フェーズではなく設計時に決めても良いでしょう。実装フェーズに入ってからでも問題ない場合が多いのではないかと思います。

#4 実装フェーズ

実装フェーズでは、プログラミングを進めていきたいところではありますが、前のフローで決めきれなかった異常系の処理や、曖昧な仕様の正常系の処理等の対応をすることも少なくないです。
その場合、イレギュラーな動作や発注側で判断がしにくいことが多いため、文章やデザインだけで対話するのではなく、実際に動くアプリを目で見てもらって進めていくことをお勧めします。アプリがまだ動く状態にないのであれば、類似アプリの挙動を参考にしても良いでしょう。

UIの提案

私たち開発者は、最新のアプリやトレンドに敏感なため、一般的に有名なアプリと同じようなことが簡単にできる場合があるということも知っています。そのため、UIの改善が必要だと感じたときには、クライアントに提案してみることを忘れてはいけません。
もちろん、その提案が却下されることもあるでしょう。しかし、そういったチャレンジをして自分たちで考えて良いアプリにしていくというセンスは、鍛えなければ備わることはないのです。

テストコード

テストコードは、自分たちのコードを自動でテストできるようにすることで、実装の考慮漏れをなくすだけでなく、仕様でカバーしている内容を表現することもできます。
また、プロダクションコードの使い勝手をテストコード視点で操作できるため、自分たちの設計の勝手を確認し、より良いものに変えていくことができます。
中には、意味の薄いテストコードを作ってしまうこともあります。しかし、それを恐れずにチャレンジをしていかなければ、そのセンスも磨くことはできないでしょう。

CI

CIは、実装したテストコードを定期的に動かす仕組みとして今は当たり前になっています。可能であれば、実装フェーズより前の要件定義フェーズのうちにCIの準備をしておくのが良いでしょう。

CIでは定期的または任意のタイミングでのテストコードの実行や、SwiftFormatにより、すでにpushされたコードのフォーマットをルールに従って変更することができます。
SwiftFormatをローカル環境で実行するのも重要なことですが、ローカル環境でビルド時に行う場合、その都度時間がかかってしまいます。
自分が変更したコードのみgitの差分によりSwiftFormatを実行するなど工夫はいくらでもありますが、CIが自動でSwiftFormatを行い、Pull Requestを出してくれるようにすることのほうが圧倒的に楽でしょう。

特に現在はソースコードをホスティングしているGitHub上のGitHub Actionsが簡単かつ気軽に実行できるようになっており、GitHub Actionsが動作するLinux上でもアプリとしてビルドせずにSwiftFormatやSwiftLintを実行することは可能です。つまり、その他のCIサービス、例えばBitriseやCircleCiなどでmacOSとして実行するのとは別にCIを動かすことも当たり前になっています。

CD

CIサーバによるCDは、ビルドしたアプリを提供してくれるようにする仕組みとして今では必須の仕組みでしょう。
かつては発注側に確認してもらうために、ローカル環境でアプリをビルドし、それを実行してもらっていました。それが、CIサーバ上で行えるだけでも手間がかからなくなり、さらには任意のタイミングで誰でもアプリをビルドしてアップロードできるようになりました。

CDのセットアップもできれば要件定義フェーズで仕組みを導入するのが良いでしょう。

継続的に作業をしてくれるCI/CDは、強力な開発メンバーが一人増えたような頼もしさを感じられるようになることが理想です。

#5 テストフェーズ

経験上、よくある手動テストとして、ネットワーク状態を意図的に悪くしてテストすることも忘れてはいけません。通信異常時の表示、キャンセルの有無など、手動で確認ができます。

おわりに

ここで紹介したものはあくまで一例です。今回は、ウォーターフォール型開発をするパターンで書いてみましたが、他にもアジャイル型開発や顧客の内製化チームと共同で開発する場合など、開発のスタイルによって進め方も変わってきます。
しかし、どのような場合であれ、相互に確認し思い込みを排除していくことが大切です。なぜなら、モノづくりの多くの失敗のもとは思い込みが発端になることが多いからです。そうならないためには、細かくヒアリングを行い、ディスカッションを重ね、さらに動くアプリで確認し、理想に近づけていくことが、アプリ開発を生業とするもののあるべき姿と言えるのではないのでしょうか。

アルサーガパートナーズでは、ユーザー目線に沿った提案で、お客様のビジネスを成功に導くDX戦略をコンサルティングから開発、運用まで提供しています。これまで当社が伴走させて頂いたネイティブアプリ開発の一部をご紹介します。

アルサーガパートナーズのネイティブアプリ開発事例

株式会社サンシャインシティ「My Sunshine City」

サンシャインシティ社が提供する「My Sunshine City」は、施設で働くワーカーや利用者一人ひとりが欲しい情報・サービスをスマホ一つで手軽に受け取ることができる情報配信アプリです。アプリを通してサンシャインシティの魅力を知っていただき、「私がくらす街」として愛着を持っていただきたいという想いからこのサービスは誕生しました。

既存のオフィシャルサイトとの自動連携による作業効率化や、ユーザーの属性や趣味嗜好等に応じてお知らせやクーポンの配信をするセグメント情報配信機能を実装することで、ユーザーの求めている情報をダイレクトにお届けすることが可能となりました。

アルサーガパートナーズは、このサービスにおいて、戦略コンサルティング、アプリ開発、システム開発、保守・運用までを提供しています。

「My Sunshine City」を詳しく見る：https://www.arsaga.jp/work/my-sunshine-city/
ご相談・お問い合わせはメールフォーム https://www.arsaga.jp/contact/ からお気軽にどうぞ。

（文：@yimajo）