「アプリを作るといくらですか」は、一つの数字で答えられません。ベンダーがはぐらかしているからではなく、もっと根本的な理由からです。価格を決めるのは画面の数ではなく、意思決定の数だからです。
画面数が同じ二つのアプリでも、費用は何倍も変わり得ます。決済の流れがすでに定型かどうか、旧システムからのデータ移行が要るかどうか、そしてこれまで人が判断していた例外がいくつあり、それを規則として書き下ろす必要があるかによります。
価格を構成する六つの要素
| 要素 | 含まれる作業 | 軽視されやすい理由 |
|---|---|---|
| 分析と業務の可視化 | 業務プロセスを仕様に翻訳する | 会議に見えるが、以降の費用すべてを決める |
| 画面設計 | 画面遷移、レイアウト、部品 | 設計のやり直しはコードのやり直しよりはるかに安い |
| 開発 | 画面側とサーバー側の機能実装 | 最も目立つが、最も高いとは限らない |
| 外部連携 | 決済、配送、会計、既存システム | 途中で判明し、予算を変えることが多い |
| テストと修正 | 公開前に穴を見つけて塞ぐ | 納期に押されて削られ、結果的に二度払う |
| データ移行と研修 | 旧データの移行と現場の準備 | 最も忘れられるが、定着を左右する |
多くの費用を節約する一言： 上の要素ごとに見積もりを分解して出してもらってください。分解できるベンダーは仕事を考え抜いていることが多く、できないベンダーは推測しています。その推測は後日、追加請求としてあなたに戻ってきます。
見積もりが三倍から十倍も違う理由
見積もり間の大きな差は、ほぼ必ず四つの源から生じます。単に「一方が高くて一方が安い」からではありません。
- 範囲が静かに違う。 一方はテスト、移行、研修を含み、他方は開発だけを数えている。
- カスタマイズの度合い。 ゼロから作るのと、既存を調整するのは別の仕事です。
- 誰が作業するか。 経験の厚いチームは時間単価が高くても、手戻りが少ないため機能あたりでは安くなることがあります。
- 所有の形。 利用権ではなくコードの完全な所有を求めれば、価格は変わります。
三つの道筋、三つの費用構造
見積もりを求める前に、自分がどの道筋を本当に必要としているのかを決めてください。本来ごく一般的な要件に対して最も高い道筋を選んでしまい、予算が消えることがよくあります。
| 道筋 | 妥当な場面 | 費用構造 |
|---|---|---|
| 既製システムを買う | 要件が標準的で時間がない | 一括払い、その後はサーバーと保守 |
| セミカスタム | 既製がほぼ合うが調整が要る | システム価格に調整費用を加算 |
| フルカスタム | 業務が独特で競争優位そのもの | 初期は最も高く、長期では最も柔軟 |
具体的な目安として、実績のある既製システムは範囲によって幅が大きく開きます。MDHのカタログでは、プラグインや軽量なシステムが数十万から100万ルピア、本番運用可能なオムニチャネルCRM基盤が750万ルピア前後、自社ブランドのモバイルアプリが1,000万ルピア前後、そして人事モジュールを含む完全なPOSは範囲がはるかに広いため5,000万ルピア前後です。
これらの数字は基準点として役立ちます。 受け取ったカスタム見積もりが、要件を満たす既製システムの価格を大きく上回るなら、その既製品では具体的に何ができないのかを尋ねてください。
公開後に現れる費用
予算から最も抜け落ちやすい部分であり、多くのシステムが一年後に放置される理由でもあります。
単純な原則： 年間保守を案件金額の一定割合として予算化し、範囲を細かく取り決め、障害時の応答時間を定めてください。保守予算のないシステムは、放置されるのを待っているだけのシステムです。
成果を削らずに費用を削る方法
- 機能を削り、品質は削らない。 実際に使われる少数の機能を出すほうが、半端な多機能より優れています。
- 作る前に業務を整える。 紙の上で消した例外は、そのまま発生しなかった費用です。
- 強みでない領域は既製品を使う。 自社で勤怠モジュールを作って勝った事業はありません。
- 支払いは暦の日付ではなく、検証可能な達成に紐づけて分割する。
- 大きな契約の前に、実データでの試用を求める。 修正がまだ安いうちに問題が表に出ます。
