システムは作ったあとにお金がかかる ── 運用・保守の中身を項目ごとに

開発の見積書には、作るところまでしか書いてありません。ところが実際には、リリースした日から毎月お金が出ていきます。そして1年目の総額で見ると、その部分が決して小さくありません。

この記事では、リリース後に何にいくらかかるのかを項目ごとに並べます。開発会社に聞く前に、何を聞けばいいかが分かる状態にするのが目的です。

出ていく費用は、4つに分かれる

分類	中身	金額の目安（小さい業務システムの場合）
インフラ	サーバー、データベース、ファイル保管、ドメイン	月5,000円〜3万円
外部サービス	決済、メール配信、SMS、地図、認証など	月0円〜（多くは従量課金）
保守	ライブラリ・OSの更新、障害対応、監視	委託する場合は契約による
改善	使ってみて出た要望への対応、機能追加	都度見積もり、または月額に内包

このうち、上の2つは誰に頼んでも同じ実費です。開発会社が立て替えて請求する場合もあれば、自社で直接契約する場合もありますが、金額そのものは使ったぶんだけです。判断が要るのは下の2つ、保守と改善のほうです。

「保守費」は何に使われているのか

機能を追加しなければ何もしなくていい、と思われがちですが、そうではありません。使っているソフトウェアのほうが勝手に古くなっていくからです。

具体的には、こういうことが起きます。使っているライブラリに脆弱性が見つかって更新が必要になる。動かしている基盤のバージョンのサポートが終わる。SSL証明書の期限が来る。連携している外部サービスの仕様が変わる。ブラウザの更新で、これまで動いていた表示が崩れる。

どれも「機能追加」ではないので、発注側からは何も起きていないように見えます。しかし放置すると、半年から1年ほどで、ある日突然動かなくなるか、セキュリティ上の問題を抱えたまま使い続けることになります。保守費というのは、主にこの部分の費用です。

だから保守を契約するときに確認するのは、金額より対応範囲です。ライブラリの更新は入っているか。障害が起きたときの連絡先と、いつまでに反応するかの取り決めはあるか。動かなくなっていないかを誰かが見ているのか。ここが書かれていない保守契約は、実質的には「何かあったら連絡してください」と同じです。契約書のどこを見るかはシステム開発の契約書で、発注側が読むべき5つの場所にまとめました。

改善の費用は、あらかじめ枠を取る

使い始めると、必ず要望が出ます。これは失敗ではなく、むしろ正常です。実際に業務で使ってみないと分からないことがあるから、先に小さく作ったわけです。

問題は、その要望に対応する枠が用意されていないことです。開発費を全部使い切ってリリースすると、直したいことが出てきたときに、また稟議から始めることになります。そして「予算がないので来期に」となり、使われなくなります。

私たちが初期費用を抑えて、リリース後12ヶ月の改善契約とセットにしているのはこのためです。初期に全部作り込むより、使ってから直すほうが、同じ金額でも実際に使われるものになります。金額の考え方はMVP開発の費用は、何で決まるのかに、1年目の総額での比較は社内システムは内製か外注かに書いています。

誰が運用するか、3つのパターン

作った会社がそのまま見る。 一番スムーズです。仕様を知っている人がそのまま対応するので、説明が要りません。デメリットは、その会社に依存することです。だからこそ、あとで抜けられる状態にしておくことが効きます。

社内に引き取る。 社内にエンジニアがいる場合の選択肢です。ランニングが実費だけになるので安くなりますが、その人が辞めたときに止まります。引き取るなら、一人ではなく二人が分かる状態にしておいてください。

別の会社に引き継ぐ。 開発会社との関係が終わったとき、あるいは保守費が見合わなくなったときの選択肢です。引き継げるかどうかは、次の項目で決まります。

引き取れる状態を、最初に作っておく

将来どのパターンを選ぶにしても、移れる状態にしておくと選択肢が残ります。必要なのは3つです。

ソースコードの置き場所。 自社のGitHubなどのアカウントにあるか、少なくとも自社に読み取り権限があること。開発会社のアカウントの中だけにあると、関係が切れた時点で取り出せません。

契約の名義。 サーバー、ドメイン、外部サービスの契約が自社名義か。開発会社名義だと、乗り換えのたびに移管の手続きが要りますし、相手が応じなければ止まります。ドメインは特に注意してください。

最低限の手順書。 分厚い設計書は要りません。どこに何が置いてあるか、どうやって更新するか、障害時に誰に連絡するか。A4で数枚あれば、次の担当者が動けます。

この3つは、契約してからだと頼みにくくなります。提案を受けている段階で「将来社内に引き取る可能性があります」と伝えておくと、自然に整います。

ニカゲツの場合

私たちは、2ヶ月の開発とリリース後12ヶ月の改善契約をセットにしています。初期50万円（税別）＋月額20万円で、1年目の合計が290万円（税別）という形です。この月額には、前述の保守にあたる部分と、毎月の改善の稼働が含まれています。

12ヶ月のあとどうするかは、その時点で決めていただければと思っています。続けていただくのが一番ありがたいのですが、社内で回せるようになったからそちらに移す、という結論でも構いません。そのためにコードと名義は最初から自社側に置ける形にしています。

料金の内訳は料金のページに、含まれるもの・含まれないものを分けて書いています。

見積もりをもらったら、この一文を足して聞く

最後に、実際に使える聞き方をひとつ。見積書を受け取ったら、こう聞いてみてください。

「この見積もりで作ったものを、1年間動かし続けるのに、ほかにいくらかかりますか」

すぐに項目が出てくる会社は、リリース後のことを考えて設計しています。出てこない場合は、作って引き渡すところまでが仕事だと考えている可能性があります。どちらが良い悪いではなく、自社がどちらを求めているかを確認する質問です。