古い社内システム、直して使うか、作り直すか

いま企業が置かれている状況

10年以上使ってきた社内システムを持つ企業は、たいてい同じ状況に置かれています。システムはいまも動いています。大きな障害もありません。ただ、小さな依頼ひとつに2週間かかり、その依頼に対応できる人が社内にひとりしかいません。

この状態が危ういのは、問題が少しずつ悪くなるからです。突然止まるシステムには、すぐに予算がつきます。しかし少しずつ遅くなり、少しずつ手間が増えるシステムは、毎年「今年もなんとか乗り切った」で過ぎていきます。そうして見送った年が積み重なると、三つのことが同時に押し寄せます。

ひとつめ、システムを知る担当者が退職します。文書化されていない業務ルールが、その人とともに失われます。ふたつめ、基盤となる技術のセキュリティサポートが終了します。サポートが切れた言語やデータベースのバージョンは、脆弱性が見つかっても修正が出ません。みっつめ、新しい要求を載せられなくなります。モバイル対応、外部サービスとの連携、データ分析といった要求が「それは今のシステムではできません」と返され続けます。

三つが一度に押し寄せた時点では、選択肢は全面的な作り直ししか残りません。そして全面的な作り直しは、もっとも高くつき、もっとも危険な選択肢です。

刷新を検討すべき五つのサイン

次の項目のうち三つ以上に当てはまるなら、刷新の検討を始める時期です。

1. 変更のコストが非対称です。 画面に項目をひとつ追加するのに数日かかります。利用者から見て些細な要求と大きな要求の開発期間があまり変わらないなら、構造がすでに変更に耐えられない状態です。

2. 保守できる人がひとりです。 特定の人しか手を入れられないシステムは、その人の休暇や退職がそのまま事業のリスクになります。これは人事の問題ではなく、構造の問題です。

3. 基盤技術のサポートが終了しています。 使用中の言語ランタイム、フレームワーク、データベースの公式サポート終了日を確認してください。すでに過ぎているなら、セキュリティ事故は時間の問題です。

4. データを取り出して使えません。 経営判断に必要な数値を出すのに担当者が自らクエリを書く必要があったり、複数の画面を開いて手作業で合計しなければならないなら、システムがデータを閉じ込めています。

5. 迂回の業務が増えています。 現場がシステムの代わりにExcelで管理する領域が広がっているなら、システムが実際の業務を反映できていないということです。この迂回の業務はどこにも記録されないため、システムだけを見ていては問題が見えません。

維持のコストを計算してみてください

刷新の議論が進まない理由は、たいてい「いまも動いているのになぜお金を使うのか」です。この問いに答えるには、維持する側にもコストが発生している事実を数値で示す必要があります。次の四項目を合計してください。

前の三項目は、すでに支出されているのにどの勘定にも計上されないコストです。四つめの項目は、まだ発生していないものの、確率的に積み上がっていくコストです。

以下は計算の方法を示すための仮の例であり、実際の値は各企業の条件によって変わります。年間の変更依頼が30件、1件あたりの平均の待ちが10日、待ちによる1日あたりの機会費用を15万 KRW と置くと、遅れのコストだけで年4,500万 KRW です。さらに二つの部署がそれぞれ週5時間をExcelでの二重管理に使っているなら、時間あたり総人件費25,000 KRW として年1,300万 KRW が加わります。

合計が年5,800万 KRW なら、3年で1億7千万 KRW です。刷新の費用と比べられる数字が、この時点で初めて手に入ります。維持は無料ではなく、請求書の来ない支出です。

全面的な作り直しが危険な理由

刷新を決めると、まず思い浮かぶのが全面的な作り直しです。古いものを止め、新しいものを作り、ある日いっせいに切り替えるやり方です。直感的ではありますが、三つのリスクを抱えています。

効果がプロジェクトの終了時点までゼロです。 12か月の作り直しであれば、11か月のあいだ組織は費用だけを払い、改善を何も実感できません。この期間に経営環境が変われば、プロジェクトは中止の圧力を受けます。

要件が途中で古くなります。 着手の時点でまとめた要件は、1年後の現場の要求とは違っています。その差を反映すれば日程が延び、反映しなければ古いシステムが完成します。

切り替えの時点にリスクが集中します。 すべての機能を一度に変えるため、切り替えの当日に問題が起きると戻す手立てがありません。そして問題はほぼ必ず起きます。既存のシステムには、誰も覚えていない例外のルールが必ず残っているからです。

段階的に移すという代替案

全面的な入れ替えの代わりに、既存システムを残したまま機能の単位で移していく方法があります。順序は次のとおりです。

第1段階 — 境界を引く

現在のシステムを機能のかたまりに分けます。受注、在庫、精算、人事のように業務の単位で分けますが、データを誰が所有しているかを基準に線を引いてください。複数のかたまりが同じテーブルを直接書き換えているなら、その箇所が後でもっとも大きな障害になります。

境界を引くときは、組織図ではなくデータの流れに従ってください。部署が分かれていても同じデータを一緒に書き換えているなら、それはひとつのかたまりです。逆にひとつの部署の中でもデータが完全に分かれているなら、分けられます。

第2段階 — 読み取りから分離する

もっとも安全な最初の課題は照会の機能です。ダッシュボード、統計、レポートのようにデータを読むだけの機能は、新しいシステムで作っても既存のシステムに影響を与えません。失敗しても既存の画面がそのまま残っているので戻しやすく、現場はすぐに改善を実感できます。

この段階には、もうひとつ副次的な効果があります。照会の機能を作っていると、既存データの問題が表に出てきます。重複した取引先、形式の崩れた日付、コードの値が空の行が、ここで見つかります。書き込みの機能を移す前にこれらの問題を知れることが重要です。

第3段階 — 書き込み機能の移行

照会で検証が終わったら、入力・修正の機能を移します。このときしばらくは二つのシステムが同じデータを扱うことになるため、どちらか一方を正本として決めてください。 両方から同時に書き換えられるようにしておくと不一致が生じ、その不一致を探すのに移行そのものより多くの時間がかかります。

移す順序は、利用の頻度が低く影響の範囲が狭い機能から取るのが安全です。ただし誰も使っていない機能から移すと検証になりませんので、実際に使われているが、一日ほど止まっても差し支えない機能が、もっともよい出発点になります。

第4段階 — 既存システムの縮小

移し終えた機能は、既存のシステムから取り除いてください。 残しておくと現場の一部が古い画面を使い続け、結局二つのシステムを永久に維持することになります。この段階を先送りすることが、段階的な移行が失敗するもっとも多い理由です。

取り除くのが難しければ、少なくともアクセスを遮断して読み取り専用にしてください。そして、いつ完全に停止するかを日付で決めておいてください。日付のない整理の計画は実行されません。

どちらを選ぶか

全面的な作り直しがつねに間違いというわけではありません。範囲が小さく、業務ルールが文書として残っていて、数時間の停止が許されるなら、一度に変えるほうが速く安く済みます。判断の基準はシステムの古さではなく、ルールがどこに記録されているかです。

データ移行で実際に問題になること

日程が延びる原因は、たいてい機能の開発ではなくデータです。古いシステムには次のような状態が積み重なっています。

• 同じ取引先が表記だけ違う形で複数登録されている
• 日付・電話番号・事業者番号の形式が時期によって異なる
• 必須項目なのに空になっている行がある
• すでに存在しないコードの値を参照するデータが残っている
• 削除の印だけがついて実際には残っている行が混ざっている

これらの問題は、移行の段階で見つかると必ず日程を押します。着手の前にあらかじめ調査し、整理する範囲と捨てる範囲を先に決めてください。 すべての過去データを完全に整理しようとすると、移行そのものが終わりません。直近の数年分だけを整理し、残りは照会専用として保管するほうが現実的な場合が多いものです。

セキュリティとアクセス権限を設計し直す機会

刷新は、セキュリティの体系を整理できる数少ない機会でもあります。古いシステムはたいてい権限の区分がゆるく、担当者の多くが必要以上のデータを見られる状態で運用されています。移行の過程で次の項目をあわせて決めてください。

アクセス権限の最小化。 役割ごとに必要なデータだけが見えるよう区分してください。既存システムの権限の構造をそのまま移すと、古い問題も一緒に移ります。

個人情報の保存場所と保管期間。 どの個人情報がどこに保存され、いつ破棄されるのかを整理してください。クラウドへ移す場合は、データが保存される国もあわせて確認する必要があります。

処理履歴の保存。 誰がいつ何を変更したのかを残してください。古いシステムにこの記録がないために、問題が起きたとき原因を追えないことが少なくありません。

経営層を説得する方法

刷新の予算は、たいてい技術の論理では通りません。「構造が古い」「技術サポートが終わった」という説明は、決裁者に緊急性として伝わりません。次の三つに置き換えて示してください。

いま漏れている金額。 先に計算した遅れ・迂回・エラーのコストの合計です。刷新しなくてもすでに支出されている、という点が要です。

できずにいること。 この1年間、「現在のシステムでは不可能」を理由に差し戻された要求を一覧にしてください。その中に売上や顧客の離脱につながる項目があれば、前に置いてください。機会の損失は、維持のコストより強い根拠になります。

最悪の場合。 唯一の担当者が退職した場合、あるいはサポートの終了した構成要素で事故が起きた場合に、復旧にかかる期間と費用を算定してください。確率が低くても規模が大きければ、意思決定を動かします。

三つを示したうえで、段階的な移行の最初の段階だけ承認を求めてください。全体の予算を一度に求めると検討の期間が長くなり、そのあいだに状況はさらに悪くなります。

日程と人員をどう見積もるか

段階的な移行でしばしば狂うのが日程です。三つを先に織り込んでください。

現場の時間を日程に入れてください。 移行のプロジェクトでもっとも不足する資源は、開発者ではなく業務ルールを知る現場の担当者です。彼らは本業をしながら参加するため、確保できる時間を先に合意しておかないと、検証のたびに日程が押します。

並行運用の期間を計算に含めてください。 機能を移した後もしばらくは二つのシステムを同時に運用する必要があります。この期間は運用の負担がむしろ増えます。これを日程と予算に反映しないと、最後の段階で人手が足りなくなります。

データ整理の期間を別に取ってください。 前述の整合性の問題は開発と並行して進められますが、別の時間と担当者が必要です。開発の日程の中に埋めてしまうと必ず押します。

外部の会社と進めるときに確認すること

社内の人員だけで移行を進めるのが難しい場合は少なくありません。外部の会社を検討するなら、次を契約の前に確認してください。

成果物に文書が含まれるか。 コードだけを受け取ると、数年後に同じ問題が繰り返されます。業務ルールの定義書、データ構造の説明、運用手順書が成果物に含まれている必要があります。

移行後の引き継ぎの方法が決まっているか。 構築が終わった後は社内の人員が運用できなければなりません。引き継ぎの期間と教育の範囲を契約に明記してください。

段階ごとに分けて契約できるか。 全体を一度に契約すると、途中で方向を変えるのが難しくなります。最初の段階を実施してみてから以降を決める構造が、双方にとって安全です。

自社データに対する権限が明確か。 開発の過程で実際のデータを使うなら、どのデータがどこへ移動し、終了後にどう破棄されるのかを文書で定めてください。

着手の前に用意すること

方法にかかわらず、着手の前に次の三つを確保してください。

現行の業務ルールの文書化。 コードの中にしかないルールは、移行の過程で必ず抜け落ちます。完全な仕様でなくて構いませんので、例外の処理と承認の条件だけは文章で残してください。

データ整合性の点検。 先に整理した項目を基準に現在の状態を調査し、整理する範囲を決めてください。

戻す計画。 各段階について「問題が起きたらどう戻すか」を決めておいてください。戻せない段階は、それ自体が大きすぎる段階であり、もっと細かく分けるべきだというサインです。

まとめ

古いシステムのコストは、障害ではなく遅れと依存というかたちで現れます。だから気づくのが遅れます。

• 変更のコスト、人への集中、技術サポートの終了、データへのアクセス、迂回の業務という五つを点検してください。
• 維持のコストを、遅れ・迂回・エラー・リスクの四項目で計算し、刷新の費用と比べられる数字にしてください。
• ルールがコードの中にしか残っていないなら、全面的な作り直しは危険です。
• 照会の機能から移し、移した機能は必ず既存のシステムから取り除いてください。
• データの整合性は着手の前に調査し、整理する範囲をあらかじめ決めてください。
• アクセス権限と個人情報の保管方針を、この機会にあわせて設計し直してください。

刷新するかどうかより大切なのは、判断を先送りしないことです。五つのサインのうち三つに当てはまるなら、今年のうちに検討を始めるほうが、来年に全面的な作り直しをするより安く済みます。