社内で「アプリを作ろう」という話が出た。ただ、開発会社に相談する前に、そもそもアプリとシステムは何が違うのかがはっきりしない。調べても言葉の定義が並ぶばかりで、自社がどちらを頼めばいいのか分からない。そんな方に向けた記事です。
先に結論を書きます。この2つを分けるのは言葉の定義ではなく、誰がどこで使うかです。社内の担当者が業務を回すために使うのか、社外の顧客に使ってもらうのか。ここが決まれば、必要なものも費用の出方も自然に決まります。この記事では、違いを整理したうえで、発注前に決めておくべき3点を説明します。
この記事のポイント
- 分ける基準は言葉の定義ではなく「誰がどこで使うか」
- スマホアプリにすると審査とストア対応が加わり、期間が伸びる
- アプリは公開後も継続して費用がかかる
- 「アプリを作りたい」の多くは、Webで足りる
目次
システム開発とアプリの違いはどこにあるか
まず、言葉の整理から入ります。ここは軽く押さえるだけで十分です。
言葉の定義では判断できない
一般的な説明では、システムは業務全体を回す仕組み、アプリは特定の目的に絞ったソフトウェア、と分けられます。間違ってはいませんが、この説明で自社の発注内容が決まることはありません。
というのも、実際の案件では両方が混ざるからです。在庫管理システムにスマホから在庫を確認する画面を足す、という要望はよくあります。これはシステムなのかアプリなのか。言葉で切り分けようとすると止まります。
開発会社に「これはシステム開発ですか、アプリ開発ですか」と聞いても、たいてい「どちらとも言えます」と返ってきます。相手が曖昧なのではなく、その区別で見積もりが変わるわけではないからです。金額を決めるのは、作る機能の数と、その機能がどれだけ複雑かのほうです。
実務では、次の3つで考えるほうが早く決まります。
誰が、どこで、どのくらいの頻度で使うか
この3つが決まると、作るものの形はほぼ決まります。
| 条件 | 社内の業務システム寄り | スマホアプリ寄り |
|---|---|---|
| 誰が使うか | 自社の従業員。教育できる | 社外の顧客。説明なしで使える必要がある |
| どこで使うか | 社内のPC。ネットワークが安定している | 外出先。電波が不安定な場面もある |
| 使う頻度 | 毎日、長時間 | ときどき、短時間 |
| 重視されるもの | 正確さ、他システムとの連携 | 使いやすさ、起動の速さ |
右の列に当てはまるなら、見た目と操作感に費用をかける必要があります。左の列なら、そこよりも業務の正確さや既存システムとのつなぎ込みに費用がかかります。同じ金額でも、何に使われるかが変わるということです。
混ざる場合もあります。倉庫の担当者がスマホで在庫を入力するようなケースは、使う人は社内なのに使う場所は現場です。この場合は、業務の正確さを優先しつつ、片手で操作できる作りにする、という組み合わせになります。どちらか一方に寄せる必要はありません。
スマホアプリにすると期間が伸びる
発注側が見落としやすいのが、スマホアプリ特有の工程です。作り終えてすぐ公開できるわけではありません。
App StoreとGoogle Playには、それぞれ公開前の審査があります。基準を満たしていないと差し戻され、直して再申請することになります。初回はここで数日から数週間かかることを前提に日程を組んでください。
また、iPhone向けとAndroid向けの両方を作るなら、単純に対象が2つになります。片方だけで始めて、様子を見てからもう片方を作るという進め方もあります。稼働開始日が決まっているなら、この判断は早めにしておくほうが安全です。
どちらを先にするかは、使う人の端末で決めてください。社内の従業員に配る端末が決まっているなら、その片方だけで十分です。社外の顧客向けなら、既存の顧客がどちらを多く使っているかを調べてから決めます。感覚で「両方作っておこう」と決めると、費用が倍近くになります。
公開したあとも費用がかかり続ける
もうひとつ、業務システムとの大きな違いがここです。スマホアプリは、公開したあとも手を入れ続ける必要があります。
- 年単位でストアへの登録を維持する費用がかかる
- OSが新しくなると、動作確認と修正が必要になる
- 審査の基準が変わると、それに合わせた対応が求められる
- 使わなくなっても、公開を止める手続きが要る
社内のPCで動く業務システムなら、環境が変わらない限りそのまま使い続けられます。アプリは、こちらが何もしなくても外側が変わっていくという前提で予算を組んでください。金額は各ストアの公式ページで最新の条件を確認してください。
実務でよくあるのが、公開して2年ほど経ったころに「OSが上がって動かなくなった」と連絡が来るケースです。作ったときの契約に保守が含まれていないと、その時点で改めて見積もりを取ることになります。契約の段階で、公開後にどこまで面倒を見てもらえるのかを確認しておいてください。
システム開発とアプリの違いで発注前に決めること
ここからは、開発会社に相談する前に自社で決めておくことです。
その1：使う人を1人に絞って書く
「社員が使います」では足りません。誰が、どんな場面で使うのかを1人に絞って書いてください。
たとえば「倉庫で棚卸しをする担当者が、手袋をしたまま片手で数量を入力する」と書けば、必要なものが一気に決まります。手袋で使えるということは画面のボタンは大きくなりますし、片手ということは操作が縦方向に並びます。PCの前に座って両手で入力する前提とは、まったく違うものになります。
この1文が書けていれば、開発会社との初回の相談が具体的に進みます。逆にここが曖昧なままだと、提案が一般論になり、比較しても差が分かりません。
書けないときは、実際にその作業をしている人に30分だけ話を聞いてください。机の上で考えるより早く、しかも具体的に出てきます。「いまはどうやっているんですか」と聞けば、たいてい答えが返ってきます。
その2：本当にスマホアプリが要るかを確認する
実務でよくあるのが、「アプリを作りたい」という要望が、実はWebサイトで足りるケースです。
スマホから使いたいだけなら、スマホの画面に合わせたWebで実現できます。ブラウザで開くので、ストアの審査も要りませんし、公開後の対応も軽くなります。修正したいときも、その場で反映できます。
ストアに出すアプリが必要になるのは、次のような条件がある場合です。
- 通知を送りたい（アプリを開いていない人にも届けたい）
- カメラやGPSなど、端末の機能を細かく使いたい
- 電波がない場所でも使いたい
- ホーム画面にアイコンを置いて、毎日使ってもらいたい
どれにも当てはまらないなら、まずWebで作って様子を見るほうが早く安く始められます。Webで作る場合の進め方はWebアプリ開発の記事で扱っています。
「アプリのほうが本格的に見える」という理由で選ぶこともありますが、使う人からするとどちらでも同じです。ホーム画面にWebのアイコンを置くこともできるので、見た目の差も小さくなっています。判断は、上の4条件に当てはまるかどうかだけで足ります。
その3：既存システムとつなぐかを決める
3つ目は、いま使っているシステムとデータをやり取りするかどうかです。ここは費用に直結します。
つなぐ場合、相手側の仕様を調べる作業が発生します。既存システムを入れた会社が別なら、その会社とのやり取りも必要です。この調整は、想像よりも時間がかかります。
逆に、独立して動かしてよいなら話は単純です。まずは独立で作り、あとから連携を足すという順番も選べます。判断するときは「毎日手作業で転記する量がどのくらいあるか」を見てください。転記が少ないなら、最初は独立で構いません。
連携すると決めた場合は、相手側の会社に協力してもらえるかを先に確認してください。仕様書を出してもらえない、問い合わせに時間がかかる、といった状況だと、こちらの日程が相手次第になります。これは開発会社ではどうにもできない部分なので、発注側が動く必要があります。
連携の要否を含めた要件の抜けは、要件定義書レビューシートで観点を確認できます。
小さく始めて広げる順番
3つを決めた結果、どちらとも言い切れない場合もあります。そのときは、範囲を狭めて始めるのが確実です。
順番としては、まず一番困っている業務ひとつをWebで作り、実際に使ってもらいます。そこで出てきた要望を見てから、スマホアプリにするか、他の業務へ広げるかを決めます。最初から全部を設計しようとすると、決まらないまま時間だけが過ぎます。
この進め方には、もうひとつ利点があります。実際に動くものを使うと、社内から出てくる要望の精度が上がることです。企画書の段階で集めた要望と、使ったあとに出てくる要望は、内容がかなり違います。前者は「あったらいいもの」が並び、後者は「ないと困るもの」が出てきます。
予算の相談も、この順番なら通しやすくなります。最初から大きな金額を稟議に上げるより、小さく始めた実績を添えて追加を出すほうが、社内の合意を得やすいためです。
費用と体制はどう変わるか
3つが決まると、必要な体制も見えてきます。
| 社内の業務システム | 社外向けのアプリ | |
|---|---|---|
| 開発会社側で厚くなる役割 | 業務を聞き取る担当、既存システムに詳しい人 | デザイナー、使い勝手を設計する人 |
| 発注側に必要な人 | その業務を毎日やっている担当者 | 顧客の行動を知っている担当者 |
| 公開後にかかるもの | 保守と、業務が変わったときの改修 | OS対応、ストア対応、継続的な改善 |
発注側に必要な人が違う点に注意してください。業務システムなら現場の担当者を出さないと要件が決まりませんし、顧客向けアプリなら顧客のことを知っている人が要ります。ここを情シスだけで進めると、あとで作り直しになります。金額の目安はアプリ開発費用の相場の記事にまとめています。
体制の話は、提案を受け取ったときにも効きます。顧客向けアプリなのに提案の体制図にデザイナーが入っていない、あるいは業務システムなのに業務を聞き取る担当がいない。こういう提案は、出てくるものが想定と違うことが多いです。
システム開発とアプリの違いについてよくある質問
- Q. アプリのほうが安く作れますか。
- 一概には言えません。機能を絞ったアプリは安く作れますが、iPhoneとAndroidの両方に対応し、公開後も維持していくなら、総額では業務システムより高くつくこともあります。初期費用だけでなく、数年分で比べてください。
- Q. どちらか決められないまま相談してもいいですか。
- 構いません。ただし「誰がどこで使うか」だけは決めていってください。それさえあれば、開発会社の側でどちらが向いているかを提案できます。逆にそこが決まっていないと、提案も一般論になります。
- Q. 業務システムをスマホから使うことはできますか。
- できます。スマホの画面に合わせたWebで作れば、ブラウザから使えます。ストアに出す必要はありません。まずはこの形で始めて、足りなければアプリ化を検討する順番が安全です。
- Q. 開発会社は分けたほうがいいですか。
- 連携する必要があるなら、まとめて頼むほうが調整の手間が減ります。独立して動かすなら分けても構いません。ただし2社に分けると、問題が起きたときにどちらの責任か分かりにくくなる点は覚えておいてください。
