ソフトウェア保守費用：誰も予算に入れないもの

ソフトウェア保守費用は、成功したはずのプロジェクトを十八か月後に気まずい話し合いへと変えてしまう数字です。開発そのものは予算が組まれ、承認され、無事に納品されました。ところが本番稼働のあとに起きることは「サポート」という一言でまとめられ、誰かが勘で置いた金額があてがわれます。そしてその金額は、ほとんどの場合あまりにも小さすぎました。

理由は不注意ではなく、構造にあります。開発には値段をつけられる範囲があります。保守には範囲がありません。まだ起きていない出来事によって中身が決まるからです。脆弱性が見つかるライブラリ、取引先が変更するアプリケーション連携の仕様、誰も想定しなかった状況に行き当たる利用者。そういったものが保守の中身を決めていきます。

誰もが口にする経験則は年あたり開発費の 15 から 20 パーセントであり、正解に近すぎることこそが危険なところです。 安心できる程度には当たり、外れるときは決まった方向に外れます。欠陥が噴き出す初年度を過小に見積もり、規制上の義務を負うシステムや外部連携の多いシステムでは完全に破綻します。そうしたシステムでは、作業を生み出しているのが自分たちのコードではなく、外の世界で起きる出来事だからです。

ソフトウェア保守費用が実際に含むもの

はっきり性質の違う五つの区分があり、これらを混同することこそが誤った数字を生みます。

是正の作業。 欠陥を直すことです。前半に集中します。不具合の大半は実運用の最初の数か月で表に出るためで、割合ルールがいちばんうまく説明できるのもこの区分だけです。ただし一件あたりの重さは事前には分からず、小さな修正のつもりが設計の見直しにまで及ぶこともあります。

適応の作業。 自分では制御できない変化に追いつくことです。依存ライブラリがセキュリティ修正を出します。決済事業者が連携仕様の旧版を廃止します。ブラウザが挙動を変えます。どれも機能を増やしませんが、どれも義務であり、実施しないという選択肢は存在しません。

予防の作業。 追い込まれる前に上げておくことです。省いても費用は消えず、先送りされたうえに膨らみます。ありふれたフレームワークの更新が三か月がかりの案件に化けるのは、たいていこの筋道をたどった結果です。

運用そのもの。 ホスティング、監視、バックアップ、証明書、そしてそれらに目を配る人の時間です。別勘定にされることが多く、それ自体は構いません。誰かがきちんと数えてさえいれば問題にはなりません。

小さな変更。 実際の利用者が入ったあと、稼働中のシステムが絶え間なく生み出す調整の流れです。一件ずつ見れば取るに足りませんが、合計すればほとんどの年でいちばん大きな区分になります。依頼はどれも十分で終わりそうに見えて、確認と反映と連絡まで数えれば半日が消えていきます。

世間が保守と呼んでいるのは最初のひとつだけです。予算が足りなくなる理由は、残りの四つのほうにあります。

割合ルールが誤解を招く理由

見るべき量を取り違えているからです。保守の工数は、動く部品がいくつあるか、そして外の世界がそれをどれだけの速さで変えてくるかに従います。開発にたまたまいくら掛かったかには従いません。

同じ金額で作った二つのシステムが、三倍も違うことがあります。依存関係が二つだけで規制の影響も受けない自己完結した業務アプリは、動かし続けるのが安く済みます。外部サービスを六つつなぎ、個人データを扱い、業種ごとの規則に従うシステムはそうはいきません。その連携のひとつひとつが、自分では予定を組めない作業の発生源だからです。

割合ルールはさらに、初年度には存在しない定常状態を前提にしています。実際に使われれば欠陥は見つかりますし、公開後の最初の六か月は、落ち着くまでのあいだ年平均をはるかに上回るのが普通です。

より確かな見積もりは、動く部品を数えるところから始まります。連携の数、遵守すべき規制上の義務、問い合わせを生む利用者の規模を数え、それらが現実に食う時間に値段をつけてください。受託ソフトウェア開発の費用 についての記事では、同じ計算の開発側を扱っています。

チームが忘れる費目

依存ライブラリの更新。 任意ではありません。修正の当たっていないライブラリこそシステムが侵入される経路だからです。しかも工数は本当に読めません。上流の開発者が何をするかに左右されるためです。

外部連携仕様の変更。 取引先が旧版を廃止し、期限を通告してきます。時期を決めたのは自分たちではなく、断ることもできません。

証明書とドメインの更新。 些細な作業です。週末にひとつ期限が切れて、サイトが止まるまでは。

監視と、それに対する応答。 反応する人がいなければ通知には何の価値もありません。そして、その待機できる状態は、何も壊れなかった月でも現実に発生する費用です。

引き継ぎ。 人は辞めます。次の担当者がそのシステムを理解するまでに掛かる費用は保守費用であり、書き残されたものが少ないほど大きくなります。

データの増加。 保存費用は上がり、速かった問い合わせは遅くなり、その対処のための作業は自分たちの成功が決めた時期にやってきます。データベース性能 の記事で、それが実際にどう現れるかを扱っています。

英国での費用の目安

受託システムを保守する場合の、おおまかな年間費用の幅です。社内の要員ではなく外部の事業者に任せる前提で示します。

これらにホスティングとライセンスは含まれていません。別途請求され、幅もきわめて大きいためです。さらに、システムがそれなりの状態にあることも前提としています。誰も文書を残さず、試験もなく、理解している人がひとりしかいないものを引き受けると、費用は上がり、どんな契約でも消せない危険が付いてきます。文書と試験がない分だけ、変更のたびに現状を読み解く時間が先に必要になるからです。

どう契約を組み立てるか

時間数を決めた定額契約は、作業量がおおむね読めるときに向いています。買っているのは即応できる状態であり、支払いの大半は実のところそこに対して払っています。使い切らなかった時間は無駄ではありません。代わりの選択肢は、頼れる相手が誰もいないという状態だからです。

実績時間での精算は変更の少ないシステムに合いますが、応答の速さは事業者の他の約束が許す範囲になります。それが引き換えに受け入れる条件です。

固定額の保守契約は危険を事業者側に移し、事業者はその危険を料金に織り込みます。予測できることのほうが利幅より価値を持つ、止められない基幹システムには理にかなった選び方です。

どれを選ぶにせよ、必要になる前に、何が保守で何が新機能かを決めておいてください。この境目こそ、保守の関係でこじれる原因のほとんどすべてです。そして最初に決めておくことには費用が掛かりません。

Mecanik はソフトウェア開発 の一環として、自分たちが作ったものだけでなく、作っていないシステムの保守も引き受けています。引き継ぎの最初の一か月はたいてい文書化に充てます。運用の履歴、既知の不具合、外部連携の一覧を書き起こす作業がここに入ります。そこで作られた文書が、その後の毎月の費用を決めてしまうからです。

あわせて読みたい: 固定価格契約か、実績時間か？ 、使える見積もりが集まる提案依頼書の書き方 、ソースコードエスクロー：本当に必要なのは誰か 、そしてMVP開発：範囲と費用と期間 。

よくある質問

ソフトウェアの保守費用は年間どれくらいですか？ よく使われる経験則は年あたり開発費の 15 から 20 パーセントですが、欠陥が噴き出す初年度を過小に見積もり、連携が多いシステムや規制上の義務を負うシステムでは完全に成り立たなくなります。英国でのおおまかな幅は、小規模な社内ツールで £6,000 から £15,000、規制対象や高トラフィックの基盤では £60,000 以上で、いずれもホスティングは含みません。

ソフトウェア保守には実際に何が含まれますか？ 五つの区分です。欠陥を直す是正の作業、依存ライブラリや外部連携仕様の変更に追いつく適応の作業、追い込まれる前に上げておく予防の作業、ホスティングや監視といった運用そのもの、そして稼働中のシステムが絶え間なく生む小さな変更の流れです。多くの人が保守と呼ぶのは最初のひとつだけです。

開発費に対する割合というルールは、なぜ当てにならないのですか？ 見るべき量を取り違えているからです。保守の工数は、動く部品の数と外の世界がそれを変える速さに従うのであって、開発費には従いません。同じ金額で作った二つのシステムでも、連携の数、規制の影響、問い合わせの量によって三倍の差がつくことがあります。

チームが予算に入れ忘れる保守費用は何ですか？ 依存ライブラリの更新、自分では選べない期限付きで通告される外部連携仕様の廃止、証明書とドメインの更新、監視の通知の裏側にある人の待機、人が辞めるときの引き継ぎ、そしてデータ増加が保存費用と問い合わせ速度に与える影響です。

定額契約と、必要なときに払う方式のどちらがよいですか？ 時間数を決めた定額契約は作業量が読める場合に向き、即応できる状態を買うものです。支払いの大半は実のところそこに対して払っています。実績時間での精算は変更の少ないシステムに向きますが、応答の速さは事業者の他の約束次第になります。どちらを選ぶにせよ、必要になる前に、何が保守で何が新機能かを決めておいてください。