受発注のシステムを新しく作ることになり、開発会社から「クラウドで構築します」と言われた。初期費用は思ったより安いけれど、月額のインフラ利用料が別に乗っている。社内では「5年でいくらか」を聞かれるのに、月額は使った分だけ変わると説明されて総額が出せない。システム開発をクラウドで作るときに発注側が戸惑うのは、技術の中身ではなくお金の払い方が変わることです。この記事では、費用の形がどう変わるか、契約で何が増えるかに絞って整理します。AWSやAzureの機能の話は出てきません。
この記事のポイント
- 初期費用が減るかわりに月額が終わりなく続く形に変わる
- 総額は途中で逆転するので比べる年数を先に決める
- クラウドの契約名義が開発会社だと乗り換えで動かせなくなる
- やめるときのデータ取り出しは形式・期間・費用まで聞く
目次
システム開発をクラウドで作ると費用はこう変わる
先に結論を書くと、クラウドにすると安くなるとは限りません。変わるのは金額そのものではなく、いつ・どういう形で払うかです。ここを取り違えたまま稟議に出すと、あとで「聞いていた金額と違う」という話になります。
なお、クラウドにはIaaS・PaaS・SaaSといった区分がありますが、発注側が押さえるべきは借りる範囲が違うという一点だけです。サーバーだけ借りるのか、動かす土台まで借りるのか、完成品を使わせてもらうのか。区分の名前を覚える必要はありません。
初期費用が減って月額がずっと続く
自社でサーバーを買って置く場合、最初にまとまった金額を払い、あとは保守費用を払っていきます。買った機器は自社のものなので、5年なり6年なり使い切る前提で考えます。
クラウドは、この最初のまとまった支払いがほとんど無くなります。かわりに、使っているあいだは毎月払い続けます。サービスを止めない限り、支払いに終わりがありません。
私の感覚では、ここで発注側が安心してしまうことが多いところです。見積書の初期費用の欄が小さいと、全体も安く見えます。でも実際には、支払いの総量が減ったのではなく、後ろにずれただけということが少なくありません。
もうひとつ性質が違うのは、使わなくなったときです。自社で買った機器は使わなくなっても手元に残りますが、クラウドは止めれば費用も止まります。これは有利にも不利にも働きます。試しに作ってみて合わなければ畳める一方、長く使う前提のシステムでは、払い終わりが来ないという形になります。
総額は途中で逆転するので比べる年数を決める
初期が軽い分、使う年数が長くなるほど月額の累計が効いてきます。どこかの時点で、自社で持ったほうが安かった、という地点が来ます。
だから比べるときは、必ず「何年使うつもりか」を先に決めます。3年で比べるのと7年で比べるのとでは、答えが逆になることがあるからです。年数を決めずに初期費用だけを並べた比較表は、判断材料になりません。
現場でよく見るのは、開発会社が出した比較表が初期費用だけで作られているケースです。悪意があるわけではなく、月額は使い方次第で決まらないから書きにくい、という事情もあります。だからこそ発注側から「5年で比べたいので、想定の月額を入れた総額を出してください」と頼む必要があります。頼めば出してもらえます。
| 項目 | 自社で持つ場合 | クラウドの場合 |
|---|---|---|
| 最初の支払い | 機器と構築でまとまった額 | 構築費のみ。機器の購入なし |
| 毎月の支払い | 保守費が中心で変動は小さい | 利用料。使用量で上下する |
| 比較の勘所 | 使う年数が長いほど有利 | 使う年数が短いほど有利 |
| 利用者が増えたとき | 機器の増設に時間と費用 | 設定変更で対応。月額が上がる |
| 使わなくなったとき | 資産が残る | 止めれば費用も止まる |
何年使うつもりかは、システムの寿命の話でもあります。システム開発のライフサイクルと更改の考え方で、企画から廃止までを何年で区切るかを整理しているので、年数の置き方に迷ったらそちらが使えます。
会計と社内稟議の通し方が変わる
費用の形が変わると、社内での通し方も変わります。機器を買う場合は資産として計上して何年かに分けて費用にしていきますが、クラウドの利用料は毎月の経費として出ていきます。
実際の会計処理は契約の形や内容で変わるので、ここは必ず税理士か経理部門に確認してください。この記事で断定はできません。ただ、発注側として先に決めておきたいのは、その費用を年度予算に一度で乗せるのか、毎年の運用費として毎年乗せ続けるのか、という社内の置き場所です。
ここを決めずに進めると、初年度は通ったのに翌年の予算で毎月の利用料が宙に浮く、ということが起きます。稟議を書く前に、経理と情報システムで置き場所を合わせておくと後が楽です。
もうひとつ、稟議の書き方で効くのが期間の示し方です。初期費用だけを書いた稟議は金額が小さく見えて通りやすい反面、翌年以降に毎年説明が必要になります。最初から5年分の総額を並べて出しておくと、その年だけ苦労して以降は追加の説明が要りません。どちらが自社で通しやすいかは社風によりますが、後者のほうが後から揉めにくいと感じています。
利用料が動くので予算が読みにくい
クラウドの利用料は使った分だけの課金なので、月によって変わります。繁忙期に処理が増えれば上がりますし、利用者が増えても上がります。
予算を出すために聞くべきなのは、何で課金されるのかです。保存しているデータの量なのか、外に出ていく通信の量なのか、動かしている時間なのか、使う人の数なのか。課金の物差しが分かれば、自社の業務量から上がり方の見当がつきます。
あわせて、一定額を超えたら知らせが来るようにしてもらいます。設定できるのが普通なので、「上限のアラートは設定できますか」と聞いて、できるなら誰宛に飛ばすかまで決めておきます。気づかないうちに増えているのが、いちばん困る形です。
読みにくさは、裏返せば柔軟さでもあります。利用者が増えたときに機器を買い足す必要がなく、設定の変更で対応できるのはクラウドの利点です。事業の伸び方が読めない時期や、まず小さく始めたい場合には、この性質が効きます。予算の読みにくさと引き換えに何を得ているのかを、社内に説明できるようにしておくと通しやすくなります。
クラウドでのシステム開発で発注前に確認すること
費用の形が分かったら、次は契約です。ここはクラウドで作るときだけ増える確認事項で、上位に出てくる解説記事ではほとんど触れられていません。
契約が作って終わりから使い続けるに変わる
これまでの発注は、作ってもらって、検収して、あとは保守契約という形でした。クラウドを使うと、そこにクラウド利用の契約がもう一本ぶら下がります。
確認するのは3つです。まず契約の名義が自社なのか開発会社なのか。次に、利用料が値上がりするときの通知の決まり。最後に、そのサービスが終了したときにどうするか。
名義はとくに大事です。クラウドの契約が開発会社の名義になっていると、開発会社を替えるときに環境ごと動かせません。移すのではなく、作り直しに近い作業になります。契約時点では気にならない項目ですが、数年後に効いてきます。自社名義にできないか、少なくとも移管できる取り決めがあるかを、発注前に聞いておいてください。
やめるときにデータをどう取り出すか
始める話をしているときに終わる話をするのは気が引けますが、ここを聞いておくかどうかで数年後の自由度が変わります。
聞くのは形式・期間・費用の3点です。「エクスポートできます」という返事だけでは足りません。どういう形式で出せるのか、依頼してから何日で出てくるのか、その作業に費用がかかるのか。CSVで出せるのか、それとも独自の形式でしか出ないのかによって、次のシステムへの移しやすさがまるで違います。
この構造は特定のクラウドに限った話ではなく、ベンダーロックインの起きる原因と避け方で扱っている仕組みと同じです。契約前の一言で回避できることが多いので、聞くこと自体を忘れないようにします。
障害のとき誰がどこまで責任を持つか
自社でサーバーを持っているときは、何かあれば開発会社か保守会社に連絡すれば済みました。クラウドになると、自社・開発会社・クラウド事業者の三者になります。
クラウド事業者側の大規模な障害は、開発会社の責任ではありません。そこを責めても解決しません。ただ、決めておけることはあります。障害に気づいたとき誰にどう連絡するのか、復旧の見通しを誰が自社に伝えるのか、復旧までのあいだ業務をどう回すのか。
この取り決めがないと、障害の当日に「うちの責任ではない」というやりとりで時間が溶けます。窓口を開発会社に一本化しておくのが、発注側としては現実的です。
あわせて、どこまで止まる可能性があるのかも聞いておきます。クラウド事業者は稼働率の目標を公表していることが多く、その水準で自社の業務が回るかどうかは発注側にしか判断できません。止まって困る時間帯と、止まったときに手作業で何時間しのげるかを先に出しておくと、この会話が具体的になります。
見積もりで確認する項目
ここまでを踏まえて、見積書を見ます。見るのは金額の大小ではなく、分かれ方です。
初期費用と月額が分かれているか。月額に何が含まれていて、何が含まれていないか。利用者やデータが増えたときに、どの単価でいくら増えるのか。この3つが読み取れない見積もりは、5年分の数字が作れません。「クラウド利用料一式」と書かれていたら、内訳を出してもらいます。
前提条件や範囲の書かれ方を項目単位で点検したいときは、システム開発見積もりチェックシート（危険サインを見抜く60項目）が使えます。月額が続く形の見積もりでは、含まれない範囲の書かれ方がとくに効いてきます。
なお、ここまでは新しく作る場合の話です。すでに動いているシステムをクラウドに移す場合は、載せ替えられるかどうかの判断が先に来るので、前提が変わります。その場合は既存システムをクラウドに載せ替える条件と費用のほうが近い内容です。
- Q. クラウドで作ると結局は安くなるのですか
- A. 使う年数によります。初期費用が軽い分、短い期間で使うなら有利ですが、長く使うほど月額の累計が効いてきて、どこかで逆転します。安くなるかどうかを聞く前に、何年使うつもりかを決めてください。年数が決まれば、初期費用と月額から総額を出して比べられます。年数を決めずに初期費用だけを比べると、必ず判断を誤ります。
- Q. 月額が変動すると言われました。稟議の数字はどう出せばいいですか
- A. 何で課金されるのかを聞いて、自社の業務量から見当を付けます。データ量なのか通信量なのか稼働時間なのか利用者数なのかで、増え方が違います。そのうえで、通常時と繁忙期の2つの想定で出すのが現実的です。開発会社に「一番使う月でいくらになる想定か」を聞けば、上限側の数字は出してもらえます。
- Q. クラウドの契約は自社名義と開発会社名義のどちらがよいですか
- A. 原則は自社名義です。開発会社名義だと、会社を替えるときに環境ごと動かせず、作り直しに近い作業になります。ただし運用を任せる前提だと開発会社名義のほうが手続きは楽なので、その場合は「契約を自社に移管できる」ことを書面で決めておいてください。名義そのものより、移せるかどうかが要点です。
