「350万円かけてアプリをリリースしました。あとはマーケティングを頑張るだけですね」
こう話していた担当者から、2か月も経たないうちに連絡が入ることがあります。「開発会社からまた請求書が届いたんですが、これは何の費用ですか？」
こういった状況は珍しくありません。最初の開発を「一度きりの費用」として計画していたところに、リリース後も継続的に費用が発生して戸惑うケースです。この記事では、その費用がどこから来るのか、そして発注前に何を確認しておくべきかを整理します。
リリースは終わりではなく始まりである
ソフトウェアを建物に例えることがありますが、この比喩がかえって誤解を生むこともあります。建物は建てれば構造が変わることはありません。しかしソフトウェアは違います。リリース後も環境が変わり続け、サービスはその変化に対応し続けなければなりません。
なぜソフトウェアには継続的な管理が必要なのか
一つ目は、サービスが動作するインフラ環境が変わり続けるからです。クラウドサービスのプラットフォームが更新されたり、サーバーOSにセキュリティ上の問題が見つかったりすれば、対応が必要になります。
二つ目は、サービスが依存する外部要素が独自のタイミングで変更されるからです。PayPayや地図API、決済モジュールなどの外部連携サービスは、それぞれが独自にバージョンアップやポリシー変更を行います。変更があれば、連携部分のコードを修正しなければなりません。
三つ目は、ユーザーが使うデバイスやブラウザが更新され続けるからです。AppleがiOSの新バージョンをリリースしたり、ChromeやSafariが特定の動作仕様を変更したりすると、それまで正常に動いていた画面や機能に予期しない問題が生じることがあります。
この三点だけを見ても、「作ったら終わり」が成り立たない理由は明確です。ソフトウェアは生きているシステムです。
リリース後に発生するコストの種類
リリース後に継続的に発生するコストを項目ごとに整理します。
サーバー・インフラ費用
サービスを運用するにはサーバーが必要です。AWS、GCP、Azureなどのクラウドインフラを使う場合、利用量に応じた月額費用が発生します。ユーザーが少ない初期は費用も抑えられますが、トラフィックが増えるにつれてサーバースペックを上げる必要が生じ、費用も増加します。データベース、ファイルストレージ、メール送信サービスなど、構成要素が増えると費用の項目も多岐にわたります。
これは開発会社のマージンではなく、実際に使用しているインフラに対する利用料です。多くの担当者が、リリース後に初めてこの費用の存在を認識します。
セキュリティパッチ
ソフトウェアには継続的に新たな脆弱性が発見されます。サービスが使用するオープンソースライブラリ、サーバーOS、フレームワークなど、すべての構成要素が対象です。脆弱性が見つかれば、悪用される前にパッチを適用する必要があります。個人情報を扱うサービスであれば、これは義務といえます。
セキュリティパッチの適用は小さな作業に見えることが多いですが、適用後に既存機能との競合や予期しない動作が発生する場合があるため、検証作業が伴います。
OS・ブラウザ・デバイスのアップデート対応
AppleとGoogleは年に一度以上、主要なOSアップデートをリリースします。ChromeやSafariなどのブラウザもウェブ機能の仕様を定期的に変更します。これらの変更が、それまで正常に動いていたアプリに互換性の問題を引き起こすことがあります。
App StoreやGoogle Playを通じて配信しているアプリは、ストアのポリシー変更への対応も重要です。プライバシーポリシーの表示方式、データ収集に関する要件、決済ポリシーなどは、近年だけでも複数回変更されています。これらに対応しなければ、アプリがストアから削除されるリスクがあります。
外部API・ライブラリの変更対応
ソーシャルログイン、決済、地図、分析ツールなど、サービスが連携している外部サービスはそれぞれ独自のアップデートサイクルを持ちます。APIのバージョンが上がったり、認証方式が変わったりすると、連携コードを修正する必要があります。対応しなければ、その機能が突然使えなくなります。
オープンソースライブラリも同様です。ライブラリのメンテナーがセキュリティ修正や仕様変更を含む新バージョンをリリースした場合、サービス内で使用しているバージョンも更新する必要があります。
ユーザーからのバグ報告・改善要望
リリース後は、実際のユーザーが開発中に想定していなかった操作をすることで、潜在的なバグが表面化します。ワークフロー上の問題点も実際の利用を通じて明らかになります。また、ユーザーからの要望や管理側からの細かな修正依頼も継続的に発生します。
個々の作業は小さく見えますが、積み重なると相当な工数になります。サービスを運用するとは、こうした対応を継続的に行うことでもあります。
保守費用の目安を把握する方法
具体的な金額は、サービスの複雑さ、ユーザー規模、技術スタック、外部連携の数などによって大きく異なります。ただし、業界で一般的に使われる目安はあります。
初期開発費用に対する割合
保守費用を初期開発費用の年間一定割合として見積もる方法が広く使われています。シンプルなサービスは割合が低く、連携が多く技術的複雑度が高いサービスほど高くなります。これはあくまで参考値ですが、予算計画の出発点として活用できます。
費用を押し上げる要因
- 外部連携サービスの数（多いほど変更対応の頻度が上がる）
- リアルタイム機能の有無（チャット、位置情報追跡などは安定性維持の負荷が高い）
- 個人情報・金融データの取り扱い（セキュリティ対応の水準と頻度が上がる）
- ユーザー規模（トラフィックが多いほどインフラ費用と障害対応の負担が増す）
- 対応プラットフォーム数（iOS・Android・Webそれぞれへの対応が必要になる）
初期開発費用の目安については、アプリ開発費用完全ガイドで詳しく解説しています。
見積もり段階で確認しておくべきこと
開発会社から見積もりを受け取る際、以下の点は契約前に明確にしておくことが重要です。
1. 運用費用が開発費用と分けて記載されているか
初期開発費用だけが記載された見積書は、全体像の一部に過ぎません。サーバー費用、ドメイン・SSL証明書の更新費用、ストア登録費用、保守サポート費用などがどのように構成されるかを合わせて確認する必要があります。「月次運用費」が別項目で記載されているかどうかを確認するといいでしょう。
2. 無償瑕疵対応期間はどれくらいか
リリース直後に発見されたバグの修正は、通常一定期間は開発会社が無償で対応します。その期間がどれくらいで、無償対応の範囲はどこまでなのかを事前に合意しておくことが大切です。範囲が曖昧だと、後々トラブルのもとになります。
3. 保守契約の形態はどうなっているか
保守契約には大きく二つの方式があります。月額固定で一定範囲の作業を含む方式と、作業が発生するたびに別途費用を算定する方式です。どちらにも一長一短があり、サービスの性質によって適切な方式が異なります。重要なのは、どちらの方式であれ最初に明確に合意しておくことです。
MVP開発から運用フェーズまでの全体プロセスについては、スタートアップMVP外注完全ガイドも参考になります。
インテグラビットが取り組んでいること
Cokeeでは、インテグラビットのサービスを通じて、見積もり段階からこの点を明確にすることを重視してきました。
インテグラビットの見積書では、初期開発費用と月次運用費用を別項目として分けて記載しています。初期開発が完了した後にどの程度の費用が継続的に発生するかを、見積もり段階であらかじめ示すことが目的です。「知らなかった」という状況をできる限り防ぐためです。
もちろん運用費用は、実際にシステム構成が固まってからでないと正確には出せません。見積もり段階では想定レンジとして表記し、開発を進めながら具体化していく運用にしています。
この記事を読んでいる担当者や経営者の方にお伝えしたいのは、一点だけです。開発費用はリリースで終わりません。そのことを最初から予算計画に織り込んでおくことが、現実的な事業判断の出発点になります。
リリース後の運用費用を含めた総所有コストの試算について、30分の無料相談で一緒に検討することができます。