「そろそろ基幹システムを何とかしないと」。システム刷新の検討を始めたものの、見積もりを取るにも要件が整理できない。ベンダーに聞いても大規模提案ばかりで現実味がない。そんな状況に心当たりはありませんか？この記事では、基幹システム刷新の初期段階で「まず何をすべきか」を、現場目線で具体的にお伝えします。いきなりベンダーに声をかけてはいけない理由※なぜベンダーへの相談が失敗を招くのか、その背景については「なぜ基幹システムの刷新は頓挫するのか」で詳しく解説しています。基幹システムの刷新を考え始めると、つい「とりあえず見積もりを」とベンダーに連絡したくなります。しかし、これは避けるべきです。理由はシンプルで、自社の現状が整理できていない段階では、ベンダーも「安全マージン」を大きく取った提案しかできないからです。結果として、数千万〜数億円の見積もりが届き、社内で「やっぱり無理だ」と頓挫するパターンが非常に多い。まずやるべきは、ベンダーに説明できるレベルまで「現状」と「困っていること」を言語化すること。これだけで、見積もりの精度も選択肢の幅も大きく変わります。最初の一歩は「システム台帳」の棚卸し刷新検討の出発点は、今あるシステムの全体像を把握することです。意外に思われるかもしれませんが、多くの企業で「何がどこで動いているか」が正確に把握されていません。最低限、以下の項目を一覧化してください。システム名と主な用途導入時期と最終改修時期利用部署と主な担当者開発・保守ベンダー名月額・年額の保守費用サーバーの場所（オンプレミス／クラウド）Excelで十分です。完璧を目指さず、まず「分かる範囲」で作ることが重要です。抜け漏れは後から埋めればいい。この台帳が、以降のすべての議論の土台になります。「誰が何を知っているか」を可視化するシステムの棚卸しと同時に進めたいのが、属人化の把握です。基幹システム周りでは「この処理は○○さんしか分からない」という状況が必ずと言っていいほど存在します。具体的には、以下を整理してください。各システム・業務の「詳しい人」は誰かその人が退職・異動した場合のリスク度合いドキュメント（設計書・手順書）の有無と鮮度これを可視化するだけで、刷新の優先順位が見えてきます。「あの人が辞めたら業務が止まる」という領域こそ、最初に手を付けるべき箇所です。属人化解消と刷新は、セットで考えると効率的です。「刷新」の定義を社内で揃える「基幹システム刷新」という言葉は、人によってイメージが大きく異なります。経営層は「ERPパッケージへの全面移行」を想像し、現場は「今の使い勝手を維持したまま新しくしてほしい」と思っている。情シスは「まず老朽化したサーバーを何とかしたい」と考えている。このズレを放置したまま進めると、後で必ず揉めます。検討初期の段階で、以下を明確にしておきましょう。刷新の目的は何か（コスト削減？業務効率化？リスク回避？）全面刷新か、部分的な改修・移行か予算感と投資回収の考え方関係者で認識を揃える会議を、必ず初期段階で設けてください。スモールスタートで「成功体験」を作る基幹システムの刷新は大きなプロジェクトになりがちですが、最初から全体を動かそうとすると失敗リスクが跳ね上がります。おすすめは、まず小さな領域で「成功体験」を作ることです。例えば、特定の帳票出力機能だけを新しい仕組みに移行する属人化している1つの業務のドキュメント整備から始める老朽化した1台のサーバーだけをクラウド移行するこうした小さな成功は、社内の信頼獲得と予算確保につながります。「全部やらないと意味がない」という考えは捨ててください。現実的に進められる範囲から始め、徐々に広げていくアプローチが、中堅企業の刷新には向いています。まとめ基幹システムの刷新は、いきなりベンダーに相談するのではなく、まず自社の現状整理から始めてください。システム台帳の作成、属人化の可視化、社内での目的・範囲の認識合わせ。この3つができていれば、その後の検討がスムーズに進みます。全面刷新にこだわらず、小さく始めて成功体験を積み重ねるアプローチが、現実的な一歩になります。チェックリストの整備が完了したら、次は現行調査から要件定義までの順序を正しく設計することが重要です。「基幹システム刷新の進め方｜現行調査・要件定義の正しい順序」で具体的なステップを確認してください。まず現状の業務・システムの実態を整理することが、改善の第一歩です。 当社ではAIを活用してシステムの仕様を解析・可視化する「システム現行調査（AI仕様解析）」を提供しています。 システム現行調査（AI仕様解析）についてはこちらhttps://likebird.jp/lp/genkou-chosa