アプリの範囲は、この五行を書いて送れば伝わる

会社ごとに別のアプリを計算している

「フリマアプリみたいなものを」。相談がこの一行で届くと、受け取った側はそれぞれ違うアプリを思い描く。出品と一覧の画面までを想像する会社もあれば、チャットと本人確認、通報対応まで当然入ると読む会社もある。計算したアプリが違うのだから、返ってくる金額も違う。数社に相見積もりを取った人は、まずその開きに驚く。受託側が水増ししているわけではない。

範囲を分ける場所は五つしかない。画面がいくつあるか、どのストアに出すか、ログイン・決済・プッシュ通知が入るか、サーバーが要るか、運営者向けの画面をどこまで作るか。この五行を埋めて送れば、返ってきた見積もりがようやく同じ土台に並ぶ。

まず画面を数える

利用者がアプリを開いて目的を果たすまでに通る画面を、一つずつ書き出す。オンボーディング、会員登録、ホーム、一覧、詳細、投稿、マイページ、設定。ここで抜けやすいのが状態画面だ。中身がまだ一件もないときの画面、エラーが出たときの画面、検索結果がゼロのときの画面。ここまで書くと「シンプルなアプリ」でも一覧はすぐ長くなる。画面数はデザインと開発の両方に掛かるので、この一覧の長さがそのまま期間と費用の骨格になる。

絵の腕は要らない。紙に四角を描いて矢印でつなげば足りる。きれいに整えるのはデザイナーの仕事で、発注側の仕事は抜けた画面がないかを確かめることだ。この一覧が受託側との共通言語になり、後から「これは範囲外だった」ともめる場面も減る。

どのストアに、いつから

iOSとAndroidの両方に出すなら、作り方から分かれる。それぞれネイティブで作れば同じアプリを二本作るのに近く、作業量が一気に増える。クロスプラットフォームのフレームワークは一本のコードで両ストアを覆うが、カメラや通知のように端末に近い機能はプラットフォームごとに手を入れ直すことになる。WebViewはWebサイトをアプリの殻に載せる方式で、三つの中では一番軽い。ただしAppleの審査はサイトを包んだだけのアプリをリジェクトすることがあるので、コンテンツ中心のサービスでもアプリでしかできない機能を一つ載せるかを先に考えておく。

聞くことは二つだ。どのストアに出すのか、最初から両方に出すのか。初期の利用者が片方に寄っているなら、一つのプラットフォームから始めて範囲を大きく削るのも十分に筋が通る。

ログイン・決済・プッシュに付いてくるもの

機能一覧に一行で書かれる項目が、実際には塊のまま入ってくる。ログインはボタンではなくアカウント体系だ。登録があればパスワード再設定が要るし、退会も要る。ソーシャルログインを一つ足すたびに、連携の作業が一式ずつ増える。決済も決済画面を作って終わらない。手前に決済代行との契約があり、後ろにキャンセルと返金の流れ、決済が失敗したときの処理が付く。プッシュ通知は送る側の仕組みと受け取る側の設定画面が一組で、広告目的の配信なら受信同意の手続きまで付いてくる。

データが端末の外に出た瞬間

五つの軸でいちばん大きく範囲を分けるのはサーバーだ。アカウントができる、複数の端末で同じデータを見る、利用者どうしが互いの投稿を読む。そのどれかが起きた時点で、サーバーとデータベースが範囲に入る。データがその人の端末の中だけにとどまるアプリなら、この軸は丸ごと空にできる。

目に見えない画面

お知らせを載せ、通報を処理し、会員を管理し、簡単な集計を見る画面。利用者が触ることはないが、サービスを回すには誰かが使う。初版でどこまで作り、どの作業を当面は手作業でしのぐか。それを決めるのも範囲算定の一部だ。

五行がまだ埋まっていなくても

「こういうアプリを作りたい」の一行だけでも相談になります。Weple のアプリ開発は、上の五つの軸を発注側と一緒に埋めて範囲の文書を先に作り、その文書を基準に期間と費用をお出しします。ほかで受け取った見積書があるなら、どの軸で金額が開いたのかを一緒に開いて見ます。項目ごとの基準は料金案内に載せています。