保守を引き継いだ最初の1ヶ月に何をしているか｜修正より先に環境を作る理由

保守を他社から引き継いだあと、開発会社は最初の1ヶ月で何をしているのか。「何かあったら対応します」という契約の裏側で、実際には準備の作業が走っています。この記事では、その順番と理由を書きます。最後に、そもそも開発会社に保守を頼むべきかどうかの線引きにも触れます——依頼しない方がよい場合もあるためです。

引き継いだ直後にやること

順番があります。どちらも、障害対応や機能改修そのものではありません。

1. 調査結果をドキュメントにする

引き継ぎの前後で行った調査の結果を、文書の形にして残します。どこに何があり、どの処理がどこから呼ばれ、どこを触ると何に影響するのか。引き継ぎ案件では、この情報が社内にもほとんど残っていないのが普通です（システム引き継ぎで用意する資料は何か）。

頭の中にあるだけでは保守になりません。担当者が変わっても、時間が空いても、同じ判断ができる状態にしておく必要があります。特に、触る機会の少ない保守ほど、後から自分たちで読み返すことになります。

2. 検証環境を構築する

そしてもうひとつが、検証環境の構築です。これは保守の前提条件だと考えています。

小さくテストできる環境がないと、開発会社としては保守のしようがありません。本番しか無い状態では、修正の確認が本番でしか行えません。それは保守ではなく、賭けになります。テスト環境が無い状態を引き継いだ実例と、そこから整えるまでにかかった時間はテスト環境がないシステムを引き継いだらに書きました。

なぜ、修正より先に環境なのか

直せる状態を作らないと、直せない

発注側から見ると、引き継いだ初月から不具合を直してほしいと思われるかもしれません。しかし、確認する手段が無いまま本番を触るのは、直すというより壊す可能性を上げる行為です。急いで対応した結果、別の場所が動かなくなれば、引き継ぎそのものが失敗として扱われます。

最初の期間に環境を整えるのは、その後のすべての作業の速度と安全性を決めるためです。ここを飛ばすと、以降の対応が毎回慎重になり、結果として遅くなります。

この期間に、必ず調査が伴う

ドキュメント化も検証環境の構築も、実際にはシステムを読み解く作業とセットで進みます。作り直した方が早いと判断するケースがあるのも、この段階です（手を入れるより作り直した方が早いと判断するとき）。引き継いでみて初めて分かることは、どうしても出てきます。

アプリケーションを触らない保守なら、依頼先は開発会社でなくてよい

ここは、自社の仕事を減らす話になりますが正直に書きます。

「サーバーのリソースだけ見る」という要件

保守のご依頼の中には、サーバーのリソースだけ監視してほしいという要件もあり得ます。ディスクやメモリの使用量を見て、閾値を超えたら知らせる、という範囲の仕事です。

こうした要件自体は成立します。ただし、アプリケーションを触らないのであれば、開発会社に依頼するメリットは薄いでしょう。開発会社の価値は、コードを読んで直せることにあります。その部分を使わない契約であれば、監視を専門とするサービスの方が適していることが多いはずです。

開発会社に頼む意味が出るのはどこからか

逆に言えば、次のような要件があるなら開発会社に依頼する意味があります。

• 不具合が出たときに、原因を特定して直してほしい
• 法改正や業務の変化に合わせて、少しずつ手を入れたい
• サーバーやプログラムのバージョンアップを含めて任せたい（中小企業のシステムセキュリティはどこまでやるか）

なお、最低限の監視だけの保守を続けた場合に何が起きるかは、保守契約はどう終わるのかに書きました。触る機会が無いと、いざというときの対応が遅くなります。

まとめ

保守を引き継いだ直後にまずやるのは、調査結果のドキュメント化と検証環境の構築です。小さくテストできる環境がなければ、修正の確認が本番でしかできず、それは保守と呼べる状態ではありません。修正より先に環境を作るのは、その後の作業の速度と安全性を決めるためです。

そして、依頼する側として知っておいていただきたいことがひとつあります。アプリケーションを触らない保守なら、開発会社に依頼するメリットは薄いということです。開発会社の価値はコードを読んで直せることにあるので、その部分を使わない契約なら、他に適した依頼先があります。

どこまでを保守に含めるべきかの整理からご相談いただけます。お問い合わせよりご連絡ください。