事業拡大期に基幹システムのリプレイスを検討し始めるタイミングの見極め

会計システム、販売管理システム、生産管理システムといった基幹システムは、多くの会社で創業間もない時期、あるいは事業がまだ小規模だった頃に導入され、それ以来大きく手を入れられないまま使われ続けています。社員数が100人を超え、事業がさらに拡大していく局面になると、この基幹システムが徐々に事業の足かせになり始める瞬間が訪れます。しかし厄介なのは、「足かせになり始めた」ことに気づくタイミングと、実際にリプレイスを検討し始めるべきタイミングとの間に、しばしば大きなギャップが存在することです。多くの会社は、限界が誰の目にも明らかになってから、つまり業務が実際に立ち行かなくなってから、ようやく重い腰を上げてリプレイスの検討を始めます。

このガイドが扱うのは、「リプレイスすべきかどうかの最終決断」そのものではありません。当メディアには基幹システムのリプレイス費用はなぜ高い？内訳の読み方やリプレイス時のデータ移行で失敗しないためにといった、リプレイスを決めた後の実務を扱うコラムが既にあります。本ガイドが焦点を当てるのは、その手前にある、より難しい問い――「まだ動いているシステムを、いつ、どのような兆候をもって『そろそろ検討を始めるべき時期だ』と社内で言語化し、複数人の情シスチームとして経営層への提起を準備し始めるか」という、検討開始の見極めです。

なぜ基幹システムのリプレイス検討は先延ばしにされやすいのか

基幹システムのリプレイスは、他のシステム刷新と比べて特に先延ばしにされやすいテーマです。その理由をまず整理しておきます。

第一に、基幹システムは「動いてさえいれば」業務が回ってしまうという性質があります。UIが古い、操作が煩雑、特定の作業に手間がかかるといった不満は現場から日常的に上がっていても、それらは「我慢すればなんとかなる」レベルの不満として扱われがちです。サーバーが完全に停止する、データが失われるといった致命的な障害が起きない限り、経営層に「今すぐ手を打たなければならない」という危機感は生まれにくいという構造があります。

第二に、リプレイスの検討自体に相応の工数がかかることです。現行システムの仕様を洗い出し、代替となる候補を比較し、概算費用を試算する――この一連の検討作業だけでも、通常業務と並行して進めるには重い負荷になります。ひとり情シスの時代であれば、この検討作業に着手する余力そのものが物理的に確保できなかったという会社も少なくないはずです。

第三に、リプレイスという言葉自体が持つ心理的な重さです。基幹システムの入れ替えは、費用規模も大きく、業務への影響範囲も広いため、「失敗できない一大プロジェクト」という印象が先に立ちます。この重さが、「まだ早いのではないか」「もう少し様子を見よう」という先送りの判断を後押ししてしまいます。

こうした構造がある以上、「限界が来たら動く」という受け身の姿勢では、動き出すタイミングが常に遅れます。むしろ、限界が来る前の段階で兆候を捉え、チームとして先回りして検討を始める姿勢が必要になります。

さらに、100-300人という規模特有の事情も先延ばしを助長します。この規模の会社は、事業自体は拡大局面にあることが多く、経営層の関心は新規事業や採用、営業体制の強化といった「攻め」の投資に向きがちです。基幹システムのリプレイスのような「守り」の投資は、目に見える売上増加に直結しないため、優先順位付けの議論の中で後回しにされやすい傾向があります。情シスチームがこの構造を理解しないまま「システムが古いので入れ替えたい」とだけ訴えても、経営層の優先順位を動かすことは難しく、結果としてさらに先送りされてしまいます。だからこそ、次に述べる兆候を、経営に伝わる言葉で可視化していく作業が欠かせません。

検討を始めるべき7つの兆候

基幹システムのリプレイス検討を始めるべきタイミングを判断するために、次の7つの兆候を定期的にチェックすることをお勧めします。1つだけでは決定的とは言えませんが、複数が重なってきたら、検討着手のサインと捉えてください。

これらの兆候のうち、①と⑤は特に注意が必要です。EOLや技術者の高齢化は、ある日突然発生する問題ではなく、事前に予測可能な時限爆弾のような性質を持っています。つまり、「まだ壊れていないから大丈夫」という判断基準そのものが、この2つの兆候には当てはまりません。EOLの到来や、保守を担ってきたベンダー担当者の引退時期が明確に見えている場合は、他の兆候がまだ顕在化していなくても、検討を前倒しで始めるべきです。

7つの兆候は、それぞれ独立してチェックするだけでなく、組み合わせて眺めることで見えてくる危険信号もあります。例えば「④改修のたびに費用が跳ね上がる」と「⑤対応できる技術者が減っている」が同時に進行している場合、これは需給の両側から価格が押し上げられている状態であり、放置すればするほど改修費用は高騰し続ける可能性が高いと考えられます。同様に、「②事業拡大にデータ量・処理量が追いつかない」状態のまま新規事業が立ち上がると、「③新しい業務要件に対応できない」という兆候が一気に顕在化するリスクも高まります。単発の兆候だけでなく、兆候同士の相互作用にも注意を払うことで、より早い段階でのリスク察知につながります。

チームで兆候をチェックする際は、7つの項目を単純なチェックリストとして四半期に1回程度見直す運用にすることをお勧めします。誰か1人が主観で判断するのではなく、チームメンバー全員が同じチェックリストに目を通し、それぞれの気づきをすり合わせることで、見落としを減らせます。特に、日常的にヘルプデスク対応をしているメンバーと、インフラ・契約面を主に見ているメンバーとでは、気づきやすい兆候の種類が異なることが多いため、複数人の視点を組み合わせることに大きな意味があります。

「まだ大丈夫」という感覚のズレを可視化する

多くの会社で見過ごされがちなのが、経営層と現場、あるいは情シスチーム内のメンバー同士でも、「まだ大丈夫」という感覚に大きなズレがあることです。日常的にシステムを操作している現場のメンバーは、細かい不便さを日々実感していますが、その情報が経営層まで正確に届いていないケースが少なくありません。逆に、情シスチームは技術的な老朽化を強く懸念していても、それが数字として可視化されていなければ、経営層を説得する材料になりません。

このズレを埋めるためには、感覚論ではなく、次のような客観的な指標を定期的に記録し、チーム内および経営層と共有する仕組みを作ることが有効です。

• システム関連の問い合わせ・障害件数の推移: 月ごとの件数を記録し、増加傾向にあるかを追う
• 改修見積もりの推移: 同程度の規模の改修依頼に対する見積もり金額が、年々どう変化しているかを記録する
• 保守対応にかかる工数: 情シスチームがそのシステムの保守・トラブル対応に費やしている時間を、他システムと比較できる形で記録する
• 業務停止時間の累計: システム起因の業務停止が、年間どれだけ発生しているかを記録する

これらの指標は、単発で見ても説得力がありませんが、半年〜1年単位で継続的に記録し、傾向として示すことで初めて力を持ちます。100-300人規模でチーム体制の情シスを組んでいる場合、この記録を続けること自体を、誰か1人の担当業務として明確に位置づけておくことをお勧めします。属人的な感覚だけに頼らず、チームの共有資産として指標を積み上げていく姿勢が、後の経営層への提起を大きく後押しします。

指標を記録する際のフォーマットについても、簡単に触れておきます。凝った分析ツールを導入する必要はなく、スプレッドシートに月次で数値を入力していく程度で十分機能します。重要なのは、指標そのものの精緻さよりも、「継続して記録し続けること」です。記録が3ヶ月分しかない状態では傾向を語ることはできませんが、1年、2年と積み重ねることで、単発の感覚論では説得力を持たなかった主張が、明確な根拠を持つようになります。ひとり情シスの時代には後回しにされがちだったこの地道な記録作業こそ、複数人体制になった今、チームの誰かが責任を持って継続できる体制を作るべき業務です。

また、指標を経営層に共有する際は、数字を羅列するだけでなく、「このまま放置した場合に想定される最悪のシナリオ」も併せて示すことをお勧めします。例えば、障害による業務停止時間が年々増加している場合、「このペースで増え続けると、来期には月あたり〇時間の業務停止が発生し、対応する人件費・機会損失は〇円規模になる」といった形で、未来を見据えた説明に落とし込むと、経営層にとって判断材料としての解像度が格段に上がります。

チームで検討を始める際の進め方

検討着手の兆候が複数見えてきたら、実際にチームとしてリプレイス検討をどう始めるかを考えます。ひとり情シスの時代であれば、担当者が独断で情報収集を始めることもできましたが、複数人体制になった今は、チーム内での役割分担と合意形成が必要になります。

1. 現状把握担当を決める: 現行システムの仕様、契約状況、ベンダーとの関係性を整理する担当をチーム内で決める
2. 市場調査担当を決める: 代替となりうるパッケージ製品やクラウドサービス、あるいはフルスクラッチ開発の選択肢について、概算の情報を集める担当を決める
3. 社内ヒアリング担当を決める: 実際にシステムを使っている各部署から、不満点・要望・業務フローの実態をヒアリングする担当を決める
4. 定期的な情報共有の場を設ける: 週次または隔週で、それぞれの担当が集めた情報をチーム内で共有し、認識をすり合わせる
5. 経営層への提起タイミングを見極める: チーム内での検討がある程度形になった段階で、いつ、どのような形で経営層に一次報告を行うかを決める

この5つのステップのうち、特に3番目の社内ヒアリングは、複数人体制だからこそ丁寧に実施できる部分です。ひとり情シスの時代は、日々の運用対応に追われ、腰を据えたヒアリングの時間を確保しづらいという制約がありました。チームが複数人になったことで、1人がヒアリングに専念できる余裕が生まれるのであれば、それは基幹システムの検討着手において大きなアドバンテージになります。

役割分担を決める際、担当領域が重ならないようにすることも大切ですが、それ以上に重要なのが、それぞれの担当が集めた情報を「誰が最終的に統合し、経営層向けの資料に落とし込むか」を明確にしておくことです。情報収集だけがバラバラに進み、統合の責任者が曖昧なままだと、いざ経営層への提起というタイミングになって、誰も資料をまとめられないという事態に陥りかねません。検討フェーズの初期段階で、進行管理と最終資料の取りまとめ役を1人決めておくことをお勧めします。この役割は、必ずしもチームの中で最も経験の長いメンバーである必要はなく、資料作成や進行管理を得意とするメンバーに任せるのも一つの方法です。

さらに、市場調査担当が集める情報の粒度についても、あらかじめチーム内で目線を揃えておくと後の作業がスムーズです。この段階ではまだ正式な見積もり依頼をかける段階ではないため、各ベンダーの公開情報やIR資料、業界レポートなどから得られる概算の情報で十分です。特定のベンダーに肩入れした情報収集にならないよう、複数の選択肢を並列に比較できる形で情報を整理することを意識してください。

経営層への「検討開始」の提起は、決断の提起とは切り分ける

ここで強調しておきたいのが、経営層への提起は「リプレイスを実行するかどうかの決断」を求めるものではなく、「本格的な検討フェーズに入ることの合意」を求めるものであるべきだという点です。この切り分けが曖昧なまま提起してしまうと、経営層は「まだ情報が少ないのに、なぜ今すぐ大きな決断を求められるのか」と難色を示しやすくなります。

「最初に経営会議で基幹システムの話を切り出したとき、いきなり『リプレイスすべきです』という結論から入ってしまい、『まだ動いているのに、なぜそんなに急ぐのか』という反応をもらいました。次に持っていったときは、『リプレイスすべきかどうかを判断するための調査に、今期このくらいの工数を使わせてほしい』という、検討フェーズへの合意を求める形に変えたところ、すんなり通りました。決断を急がず、まず調査の許可を取るという段階を踏むべきだったと反省しています」

この教訓が示すように、検討開始の提起は「調査・比較検討にかける工数と、おおまかな検討期間の承認を得る」ことを目的にするのが現実的です。この段階で提示すべき情報は、詳細な見積もりや実行計画ではなく、前述の7つの兆候のうちどれが自社に当てはまっているか、そしてそれを裏付ける客観的な指標の推移で十分です。

検討開始の合意が得られたら準備すべきこと

経営層から検討フェーズへの合意が得られたら、次の段階に進む準備を始めます。ここでもチーム体制の利点を活かし、並行して複数の作業を進めることができます。

「業務フローの可視化」は特に重要な準備です。基幹システムのリプレイスを検討する過程では、しばしば「これはシステムの制約でこうなっているのか、それとも会社の業務慣習としてこうなっているのか」の区別がつかなくなります。この切り分けを事前に整理しておくことで、後の要件定義段階での議論が格段にスムーズになります。

これらの準備作業は、いずれも本格的な要件定義や見積もり取得の前段階に位置する「地ならし」の作業です。この段階を丁寧に済ませておくことで、実際に開発会社への相談や見積もり依頼に進んだ際、要件の伝達がスムーズになり、認識のズレによる手戻りを減らせます。逆に、この地ならしを飛ばしていきなり複数社に相見積もりを依頼してしまうと、各社への説明のたびに情報が後出しで追加され、比較検討の土台が揃わないまま話が進んでしまうことになりかねません。

準備段階で作成した資料は、後の要件定義フェーズでそのまま活用できる形式で残しておくことも意識してください。検討フェーズと要件定義フェーズを別々のタイミングで別のメンバーが担当することも珍しくないため、資料が特定の担当者の頭の中にしか整理されていない状態は避けるべきです。ドキュメントの形式や置き場所をチーム内であらかじめ統一し、検討の過程で得られた知見が、後工程に円滑に引き継がれる状態を維持しておくことが、長期にわたるプロジェクトを成功させる基盤になります。

なお、契約形態や開発会社との関係性の見直しも、この準備段階で並行して検討しておくとよいテーマです。長年にわたり同じベンダーに保守を依頼してきた場合、そのベンダーが今後のリプレイスにおいてもパートナーとして適切かどうかを、この機会に見極める必要があります。ベンダーとの関係性を1社に依存させず複数の選択肢を持つ体制づくりについては、開発会社が1社依存になっている状態からの脱却、チーム体制での進め方で詳しく扱っています。

リプレイス以外の選択肢も並行して視野に入れる

検討フェーズに入ったからといって、必ずしも結論が「フルリプレイス」である必要はありません。基幹システムの限界に対処する選択肢は、複数存在します。

• 部分的な改修・拡張: システム全体を入れ替えず、限界を迎えている一部の機能だけを改修・拡張する
• 周辺システムとの連携強化: 基幹システム本体には手を入れず、周辺にクラウドサービスや連携ツールを追加することで、不足している機能を補う
• 段階的な移行: 一度にすべてを入れ替えるのではなく、業務領域ごとに段階的に新システムへ移行していく
• フルリプレイス: 基幹システム全体を新しいシステムに刷新する

検討フェーズの目的は、これらの選択肢のうちどれが最も現実的かを見極めることでもあります。特に100-300人規模の会社では、フルリプレイスによる業務停止リスクを避けたいという事情から、段階的な移行や部分的な改修を選ぶ会社も少なくありません。この選択肢の比較検討自体が、チームとして時間をかけて進めるべき本格的な作業であり、拙速に「全部入れ替える」という結論に飛びつかないことが重要です。

選択肢を比較する際に見落とされがちなのが、社内の人材リソースという制約です。フルリプレイスは費用面のインパクトが大きい一方、プロジェクト期間そのものは段階的移行より短く収まる傾向があります。逆に段階的移行は、費用の単年度負担を抑えられる代わりに、プロジェクトマネジメントに関わる情シスチームの工数を長期間にわたって拘束します。100-300人規模でチームがまだ2〜3人程度の体制である場合、通常のヘルプデスク業務や日々の運用対応と並行してプロジェクトを進める必要があるため、「どれだけの期間、どれだけの工数をこのプロジェクトに割けるか」という現実的なリソース制約を、選択肢の比較検討に必ず組み込んでください。理想的な選択肢であっても、実行するチームの体力が追いつかなければ、プロジェクトは途中で停滞し、かえって現場に混乱をもたらします。

4つの選択肢を比較する際は、それぞれを「解決できる兆候」と「解決できない兆候」に照らし合わせて整理すると、判断の解像度が上がります。例えば、部分的な改修・拡張は「④改修費用の高騰」や「⑦属人的な運用」といった局所的な課題には効果がありますが、「①EOLが迫っている」「②データ量の増加に処理性能が追いつかない」といった、システムの根幹に関わる兆候には対処しきれないことが多くあります。逆に、周辺システムとの連携強化は「⑥他システムとの連携の限界」には直接的に効果がありますが、システム内部の老朽化そのものは解消しません。自社が抱えている兆候のうち、どれが最も深刻で、どの選択肢がそれに対応できるのかを、チームでマトリクス状に整理してみることをお勧めします。

段階的移行を選ぶ場合に注意すべきこと

4つの選択肢の中でも、100-300人規模の会社が現実的な落としどころとして選びやすいのが「段階的な移行」です。一度にすべての業務領域を切り替えるのではなく、影響範囲の小さい業務から順に新システムへ移していく方式で、業務停止のリスクを分散できる利点があります。一方で、この方式には特有の注意点もあります。

まず、新旧システムが一定期間並行稼働する状態が生じるため、その間はデータの二重管理や、システム間の連携をどう保つかという課題が発生します。どちらのシステムが「正」のデータを持つのかを業務領域ごとに明確に定義しておかないと、現場が混乱し、データの不整合が生まれる原因になります。

次に、段階的移行は、フルリプレイスに比べて全体の移行完了までの期間が長期化しやすいという特性があります。長期化するプロジェクトは、途中でメンバーの異動や退職が発生するリスクも相応に高まります。プロジェクトの進行状況や意思決定の経緯を、特定の個人の記憶に頼らず、常にドキュメントとして残しておく運用を、プロジェクトの初期段階から徹底しておくことが欠かせません。

検討フェーズで陥りやすい落とし穴

検討フェーズを進める中で、チームが陥りやすい落とし穴もいくつか存在します。事前に把握しておくことで、無駄な手戻りを避けられます。

1つ目は、検討開始のきっかけが特定の1人の強い危機感だけに依存してしまうことです。チームの誰か1人が老朽化に強い問題意識を持っていても、他のメンバーがその危機感を共有できていなければ、検討は形式的なものにとどまり、実質的な進展を生みません。検討着手の初期段階で、なぜ今このテーマに取り組むのかという背景を、チーム全員が同じ解像度で理解できるよう、丁寧にすり合わせる時間を設けることをお勧めします。

2つ目は、検討が長期化する中で、当初の目的が曖昧になっていくことです。「基幹システムのリプレイスを検討する」という大きな目的だけを掲げて走り出すと、途中で個別の技術的な議論に時間を取られ、そもそも何を解決したかったのかという原点を見失いがちです。7つの兆候のうち、自社にとって特に深刻なものは何かを検討開始の時点で明文化しておき、定期的にその原点に立ち返る習慣を持つとよいでしょう。

3つ目は、他部署や現場からの情報収集を、情シスチームだけの視点でフィルタリングしてしまうことです。ヒアリングで得られた現場の声を、情シス側の技術的な判断基準だけで取捨選択してしまうと、実際に業務を回している現場の実情とずれた検討結果になりかねません。ヒアリング結果は、可能な限り生の声に近い形で記録し、判断材料として残しておくことをお勧めします。

まとめ: 「まだ動いている」うちに検討を始める

基幹システムのリプレイスは、実際に業務が立ち行かなくなってから動き出すのでは遅すぎます。EOLの到来、事業拡大によるデータ量の増加、改修費用の高騰、対応できる技術者の減少といった兆候は、多くの場合、致命的な障害が起きるよりずっと前から、静かに、しかし確実に現れ始めています。

100-300人規模でチーム体制の情シスが確立してきたタイミングは、こうした兆候を継続的に観測し、感覚論ではなく客観的な指標として蓄積していく体制を初めて構築できる機会でもあります。検討開始の提起は、決断を求めるものではなく調査の許可を求めるものだと切り分け、経営層との合意形成を段階的に進めてください。「まだ動いているから大丈夫」ではなく、「まだ動いているうちに検討を始める」という姿勢の転換こそが、事業拡大期における基幹システムとの向き合い方の核心です。

最後に強調しておきたいのは、この検討開始の見極めは一度きりの判断ではなく、継続的な観察の結果として自然にたどり着くべきものだという点です。7つの兆候のチェック、客観的指標の記録、チーム内での定期的な情報共有――これらを地道に積み重ねていく先に、「そろそろ本格的に動くべきタイミングだ」という結論が、チーム全員にとって納得感のある形で見えてきます。ひとりで抱え込んでいた頃には難しかったこの継続的な観察体制を築けることこそ、複数人体制に移行した情シスチームが持つ、最も大きな強みの一つです。