障害も依頼もなかった月、保守は何をしているのか｜保険で終わらせない稼働時間の使い方

保守を外注している側から見て、いちばん納得しにくいのは「何も起きなかった月」の請求です。保守契約の落とし穴や保守されているかの確かめ方は発注側の確認方法としてまとめていますが、この記事では受けている側が実際に何をしているかを書きます。

障害も依頼もなかった月に、実際にやっていること

何をどこまでやるかは契約の内容によって変わります。サーバーまで含めて預かっている場合と、アプリケーションの改修だけを請けている場合とでは、平常時の作業量がまったく違います。自社の契約がどちらに近いのかは、見積もりの内訳ではなく、実際に毎月どの作業に時間が使われているかで確かめるほうが早く分かります。

保守契約の内容によって幅はありますが、何も起きていない月に共通してやっているのは次の作業です。

バックアップ

バックアップは、取得されていることと、戻せることの両方が必要です。取得の設定が入っていても、実際に復元できるかを確かめていなければ、いざというときに使えません。何も起きていない月は、この確認に時間を使える貴重な期間になります。

サーバー内のライブラリのアップデート

サーバーやアプリケーションが使っているライブラリの更新も、平常時にしかできない作業です。障害対応や改修依頼が立て込んでいる月に無理に入れると、問題が起きたときに原因の切り分けが難しくなります。更新を止めたままにするとどうなるかはセキュリティアップデートを放置するとどうなるかに書いたとおりで、放置した分は後からまとめて重くなります。

保守費が「保険」のままだと、コストとして捻出しづらい

保守は、どうしても何か起こったときのための保険という要素が強い契約です。そして保険であるがゆえに、多くの会社にとっては捻出しづらい費用になります。何も起きなければ、払っている実感だけが残るためです。

この構造は、発注側が値切りたくなる理由でもあり、開発会社側が保守を軽く扱ってしまう理由にもなります。放っておくと、費用は下がり、作業も減り、いざというときに動けない契約だけが残ります。

そしてこの構造を放置すると、次に来るのは値下げの相談です。何もしていないように見える契約の費用は、真っ先に見直しの対象になります。保守費の値上げを提示されたときの話と表裏の関係で、作業の中身が見えていない契約ほど、金額だけが議題になりやすくなります。

余った稼働時間を、小さな改修に充てる

そこでFUNBREWでは、保守にかかる月の稼働時間を先に定めたうえで、その時間に満たない場合は小さな改修などを提案して補填する方法を取っています。

先に月の稼働時間を決めておく

月にどれだけの時間を保守に充てるかを決めておくと、使った時間と余った時間が見えるようになります。何も起きなかった月に何が残っているのかが、発注側からも把握できる状態になります。

満たない分は改修の提案で埋める

余った時間は、そのまま消えるのではなく、小さな改修や改善の提案に充てます。大きな開発ではなく、業務で少し不便になっている部分を直す程度のものが中心です。この考え方をもう少し体系的に整理したものが保守費用を開発投資に変える「充填型保守」で、この記事はその実際の運用面にあたります。

結果として、障害がなかった月も何かが前に進みます。保守費を払い続ける理由が、保険としての安心だけでなく、実際に手が入ったという事実で説明できるようになります。

バックアップについては、取得の頻度とどこまで戻せるかを合わせて確認しておくと安心です。毎日取得していても、戻せるのが前日の状態までであれば、その1日分は失われます。どこまで許容できるかは業務によって違うため、開発会社が決めるより先に、発注側で線を決めておくほうが話が早く進みます。

発注側から確認できること

保守が実際に動いているかどうかは、次の三点で確かめられます。

• バックアップは取得だけでなく、復元できることまで確認されているか
• ライブラリやサーバーの更新が、いつ・どこまで行われているか
• 月に確保されている稼働時間と、実際に使われた時間が分かる形になっているか

三点目が分かる状態になっていれば、余った時間の使い道を相談できます。何をどう報告してもらうかは月次報告書の読み方にまとめています。

保守の内容が今のシステムに合っているか分からない場合は、お問い合わせからご相談ください。契約内容と実際の作業の対応関係を整理するところからお手伝いできます。