トップ ／ コラム ／ 入れ替え時期の判断基準

業務システムは何年で作り直すのか｜入れ替え時期の判断基準

「このシステムはもう10年使っているから、そろそろ作り直しでは」と言われることがあります。けれども年数だけでは、入れ替えが必要かどうかは決まりません。

10年動いていて誰も困っていないシステムもあります。逆に、3年でもう手が出せなくなっているシステムもあります。差が出るのは使った年数ではなく、別のところです。

この記事では、入れ替えの引き金になるもの、年数が目安にならない理由、直す・足す・作り直すの選び分け、そして自社で判断するための進め方を整理します。

「何年もったか」ではなく「何が動いたか」で決まる

業務システムは、机や機械と違って、使っているだけでは減りません。昨日動いていたプログラムは、今日も同じように動きます。それなのに「使えなくなる」のは、システムそのものが古びたからではなく、周りが動いたからです。

周りというのは、たとえばこういうものです。

• OS・ブラウザ・データベースなど、土台になっているソフトのサポート期限
• 制度や法令、団体の規程
• 業務量や会員数、利用する人数
• そのシステムを直せる人がいるかどうか
• つながっている外部サービス（決済・メール・地図・認証など）の仕様

このどれかが動いたときに、システムは「もう続けられない」状態になります。つまり入れ替えの判断は、システムの年齢を数えることではなく、外側で何が動いたかを確かめることです。

入れ替えの引き金になるのは、だいたいこの5つ

これまでご相談をいただいた中で、入れ替えのきっかけになっていたのは次の5つでした。

この5つは、性質が二つに分かれます。サポート終了・制度変更・外部サービスの仕様変更は、外から期限がやってきます。日付が決まっているので、先送りができません。一方、業務量の増加と「直せる人がいない」は期限がありません。困っているのに期限がないので、何年も先送りになりやすいところです。

サポート終了の対処は OS・ソフトのサポート終了で業務システムを更新するときの進め方 と Windowsのアップデートに業務システムが対応していないときの対処法 に、制度変更で直す場所が出てくる話は 理事会・総会の資料づくりを軽くする方法 に、直せる相手がいなくなったときの手順は 開発会社と連絡が取れなくなったときの対処法 にまとめています。

年数の目安が当てにならない理由

同じ5年使ったシステムでも、次に手を入れられるかどうかは大きく変わります。差が出るのは、作ったときの中身です。

• 使っている技術が、今も広く使われているものか。それとも、その会社だけの独自の作りか
• 設計資料と仕様の記録が残っているか。残っていても、その後の改修が反映されているか
• ソースコードと管理者権限が自社の手元にあるか

広く使われている技術で作られていて、資料と権限がそろっているシステムは、10年たっても部分的な改修で続けられることがあります。逆に、独自の作りで資料がないシステムは、3年でも誰も手を出せなくなります。年数ではなく、この状態を見てください。

自社のシステムについて、次の5つを確かめると、入れ替えが近いかどうかが見えてきます。

1. 土台のソフト（OS・データベース・ブラウザ）のサポートが、いつまで続くか
2. 設計資料と仕様の記録が残っているか。改修の履歴が追えるか
3. ソースコードと管理者権限が自社にあるか
4. 改修を頼める相手がいるか。頼んだら見積もりが出てくるか
5. 今の業務と画面が、どのくらいずれているか（画面にない作業をExcelや紙で補っていないか）

3番が「ない」の場合は、入れ替えの前に受け取るものの整理が必要です。引き継ぎチェックリスト（25項目） に、何を受け取るべきかをまとめています。4番が「いない」の場合は、保守の体制から決め直すことになります（業務システムの保守・運用は誰がやるのか）。

まだ使えるのに作り直しを勧められたときの見分け方

「古いので全部作り直しましょう」という提案を受けることがあります。これが妥当かどうかは、理由が外側の条件に結びついているかで見分けられます。次の3つを聞いてみてください。

• どの機能が、なぜ今のままでは続けられないのか（サポート期限なのか、制度なのか、処理の限界なのか）
• 直す・足すでは済まない理由は何か
• 作り直した後、同じことは何年後に起きるのか。そのとき何をすればよいのか

3つとも具体的に返ってくるなら、根拠のある提案です。「古いから」「サポートされていない技術だから」だけで、どの機能がどう困るのかが出てこないときは、範囲をしぼれる余地が残っています。

日本眼科医会の会員管理システムでは、大手ベンダーから前のシステムと同じ規模の刷新提案が出ていました。pegは機能一覧の比較から入らず、事務局の業務のヒアリングから始めて、今の業務で必要な範囲を先に決めました。そのうえで試作画面（モック）で仕様を固め、バックエンドに着手する前に仕様を確定させています。期間は、他社の見積もりが実装9か月＋テスト3か月だったのに対し、実装5か月＋テスト2か月の7か月でした（導入事例／進め方の詳細）。

直す・足す・作り直す・そのまま使うの4つ

入れ替えか現状維持かの二択ではありません。実際には4つの選択肢があり、機能ごとに別の答えになることもあります。

「そのまま使う」を選択肢に入れておくことが大事だと考えています。方針を決めないまま時間が過ぎるのと、期限を確認したうえで今年は動かないと決めるのは、別のことです。後者なら、来年また同じ材料で判断できます。

作り直しを選んだときにいちばん時間を取られるのは、開発ではなくデータの整理です。表記のゆれ、重複、退会者や退職者の扱い、過去年度をどこまで持っていくか。どれも正解を知っているのは発注側です（業務システムの入れ替えでデータ移行が詰まる5つのこと）。古いシステムからの置き換えで費用を抑える進め方は 老朽化した業務システムの置き換え費用を抑える進め方 にまとめています。

入れ替え時期を自社で判断する5ステップ

開発会社に相談する前に、自社だけで進められるところまで整理しておくと、相談が短く済みます。

1. いま動いている土台を一覧にする。OS、データベース、ブラウザ、つないでいる外部サービス、業務で使っているソフト
2. その一覧に、サポート期限の日付を入れる。日付が調べられないものは「不明」と書く。期限がないものは「期限なし」と書く
3. 「期限なし」の中から、実際に困っている業務を具体的に書き出す。誰が、月に何時間、どの作業に使っているかまで書く
4. 機能ごとに、直す・足す・作り直す・そのまま使うのどれで解けそうかを仮に当てる。この時点では仮でかまわない
5. いちばん早い期限から逆算して、着手する時期を決める。データ整理の期間を、開発の期間とは別に足しておく

pegのやり方

pegは、年数を理由に入れ替えをお勧めすることはしません。確かめるのは外側の条件です。

• 期限のある引き金から順に決めます。 土台のソフトのサポート期限、制度の改定予定、つないでいる外部サービスの告知を一覧にして、日付が決まっているものから着手の時期を逆算します
• 機能一覧の比較から入りません。 まず業務のヒアリングから始めます。日本眼科医会では、事務局の業務を伺うところから始めて、必要な範囲を先に決めました
• 試作画面（モック）で仕様を固めてから、バックエンドに入ります。 入れ替え後の画面を先に見ていただけるので、今の業務がどう変わるかを作る前に確認できます
• 制度で決まっている判定は、システム側に入れておきます。 ドローン操縦士協会では、実技10時間未満は修了不可、要件を満たさない講師は記録できない、という判定を画面に組み込みました。こうしておくと、制度が変わったときに直す場所が決まります（導入事例）
• 次の入れ替えのときに、他社でも引き継げる形にします。 プログラム・設計資料・管理者権限は納品物として契約に明記します。全案件を必ず2名以上で担当し、引き継ぎ資料は常に最新にしています
• データの整理・突き合わせは、発注側に担っていただくことがあります。 誰がどこまでやるかを着手前に決めます
• 確立された技術と標準の型で作ります。 未知の技術は受託しません。次に手を入れる人が困らないことを優先しています

「まだ入れ替えなくてよいのではないか」という結論になることもあります。そのときはそうお伝えします。

よくあるご質問