オンプレからWeb化を考える企業にとって、最初から大きな開発を決める必要はありません。まずは現行業務・帳票・データ・連携・保守状況を整理し、延命、部分改善、パッケージ活用、周辺開発、スクラッチ再構築のどれが現実的かを見極めることが重要です。
マクティズムでは、作り直しありきではなく、Web化すべき業務と、オンプレで残す業務を切り分けることを重視して進め方を整理します。
この記事では、社内サーバーで動いている基幹システムをWeb化（ブラウザで使える形にする）際の判断基準を整理します。Web化の依頼が来ているが何を基準に判断すべきか分からないという担当者と、Web化で拠点間の利便性を上げたい経営層に向けた内容です。
この記事で分かること
- 基幹システム見直しで確認すべきポイント
- 延命・部分改善で済むケース
- パッケージ活用や周辺開発を検討すべきケース
- スクラッチ再構築を検討すべきケース
- 相談前に準備しておく情報
まず結論｜すぐに作り直す前に現状を整理する
基幹システムは、受注・出荷・在庫・請求・生産・会計連携など、複数の業務にまたがります。そのため、表面上の不具合だけを見て判断すると、後から帳票、データ移行、外部連携、現場運用で想定外の問題が出ることがあります。
まず必要なのは、現行システムの全体像を把握することです。特に、どの業務が止まると困るのか、どの帳票が実際に使われているのか、どのExcel・Access・CSV運用が周辺に残っているのかを確認するだけでも、再構築の方向性はかなり明確になります。
Web化の目的は「ブラウザで開けること」ではない
Web化を検討するきっかけは、拠点からのアクセス、リモートワーク対応、専用ソフトのインストール不要化などさまざまですが、ブラウザで動くこと自体は手段であって目的ではありません。「営業が出先から在庫を確認できるようにしたい」「拠点ごとにインストール作業をなくしたい」など、Web化によって解決したい業務上の課題を具体的にしておくと、どこまでWeb化すべきかの線引きが明確になります。
すべてをWeb化する必要はない——業務ごとに切り分ける
基幹システムのすべての機能をWebに移す必要はありません。参照や照会が中心の業務はWeb化の恩恵が大きく、大量入力や帳票印刷が中心の業務はデスクトップアプリのほうが操作性で勝る場合があります。業務単位でWeb化すべきかどうかを判断し、中核の入力業務は現行のまま残して照会系だけを先にWeb化する、という混在構成も十分に合理的な選択です。
このテーマでよく起きる問題
このテーマでよく起きる問題は、技術的な問題に見えて、実際には業務整理の不足から起きていることが多いです。たとえば、同じ機能でも部署ごとに運用が違う、帳票は同じ名称でも用途が違う、CSVの出力タイミングが担当者依存になっている、といったケースです。
この状態でパッケージを入れたり、スクラッチで作り直したりすると、開発途中で追加要件が増え、費用と期間が膨らみやすくなります。
よくある失敗は、すべてをWebに移した結果、日常的に使う入力画面の操作性が落ちて現場の生産性が下がるケースです。特に、タブキーだけで項目を移動する高速入力、ファンクションキーの多用、連続帳票への印刷といった操作はWebブラウザの標準的な挙動と相性が悪く、操作感を維持するために追加の開発工数がかかります。
また、オフラインでの使用を考慮しないまま設計し、ネットワーク障害時に業務が完全に止まるという問題も起きています。通信が途切れる環境で使う可能性がある業務には、ローカルでの一時保存や同期の仕組みを検討する必要があります。
セキュリティの面では、社外からアクセスできるようになることのリスクと対策を、利便性とセットで設計することが不可欠です。便利になる分だけ、認証強化やアクセス制御の要件が増えます。
自社で確認できるチェックポイント
Web化の判断を行う前に、次の点を確認しておくと、対象範囲が具体的になります。
- 現在のシステムで実際に困っている業務を1つずつ書き出す
- 画面・帳票・CSV・バッチ・Excel補完作業を棚卸しする
- 利用部署、利用人数、締め処理、止められない業務を確認する
- サーバー保守期限、OS、DB、ネットワーク、バックアップを確認する
- 現行システムを残す部分、直す部分、作り直す部分を分ける
- パッケージで足りる業務と、周辺開発が必要な業務を分ける
- 初期費用だけでなく、保守・追加改修・移行リスクも比較する
Web化ならではの棚卸しポイント
基本のチェックリストに加えて、Web化で解決したい課題の具体名、社外や拠点からアクセスが必要な業務の一覧、大量入力や帳票印刷がある業務の一覧、現在の画面で操作性に依存している特殊な操作（ショートカットキー・バーコード読取など）の有無、そしてネットワーク環境（拠点間の回線速度）を確認してください。Web化してよい業務と残すべき業務の切り分けは、この棚卸しの精度で決まります。
Web化の方式にも種類があります。既存システムの画面をそのままブラウザで表示する画面転送型、画面を一から作り直すフルリビルド型、既存のデータベースに新しいWeb画面をかぶせるフロントエンド刷新型。費用と操作性の配分が方式ごとに異なるため、目的と予算に合った方式を選ぶ必要があります。
Web化と同時にUIのデザインを一新する場合は、現場への影響が大きくなるため、変更管理の観点でも計画が必要です。操作性の改善と混乱防止のバランスを取るために、主要画面のモックアップを事前に現場に見せてフィードバックを得る工程を挟んでください。
延命・部分改善で対応できるケース
Web化は必ずしも全面的に行う必要はありません。次のような場合は、部分的な対応が最適です。
- 対象業務が限定されている
- 帳票やCSV連携の一部改善で足りる
- データベース改善やバックアップ自動化で安定運用できる
- 利用者が限られており、現場への影響が小さい
- 将来の全面刷新までの橋渡しとして改善したい
たとえば、営業の在庫照会や出荷状況の確認だけをWebで見られる参照画面を追加するなら、数百万円規模で実現でき、既存システムへの影響も最小限です。このような「照会系だけWeb化」は、投資対効果が分かりやすく、現場からの評価も得やすい第一歩です。
ただし、部分的なWeb化であっても、セキュリティ要件と認証の仕組みは手を抜けません。社外アクセスを許可する以上、通信の暗号化・多要素認証・アクセスログの記録は最低限の備えです。
費用の目安は、照会系のWeb化なら数百万円・3〜6か月、入力を含む主要業務のWeb化で1,000万〜3,000万円・半年〜1年、全面リビルドでは再構築に近い投資と期間になります。操作性の維持に拘るほど費用は増えるため、どこまでの操作感を求めるかが費用の分かれ目です。
パッケージ活用・周辺開発・スクラッチ再構築を検討すべきケース
次のような状況であれば、Web化単独ではなく再構築とあわせて検討すべきです。
- 保守期限が近く、現行環境を長く使えない
- 開発会社がなく、改修や障害対応が難しい
- Access・Excel・古いDBではデータ量や運用に限界がある
- パッケージ標準機能が業務に合わない
- 周辺システムや帳票が増え、全体像が分からない
- 今後も機能追加や外部連携が増える見込みがある
パッケージ活用が向くケース
クラウド型SaaSパッケージへの移行は、結果的にWeb化も含めた刷新になります。業務が標準的でパッケージに合うなら、Web化を別に検討するより一体で進めるほうが効率的です。
周辺開発で補うケース
基幹本体はそのまま残し、Web画面をフロントエンドとして周辺に追加する構成は、段階的なWeb化の典型です。必要な業務から順にWeb画面を足していく進め方で、投資を分散できます。
スクラッチ再構築が向くケース
基幹全体をWebアプリケーションとしてスクラッチ再構築する場合、操作性の設計自由度は最も高くなりますが、投資も最大です。業務の全体設計と一体で進めることが前提になります。
マクティズムの見解
マクティズムの見解として、オンプレ基幹システムをWeb化するときの判断基準では「何を作るか」より先に「何を残すか、何を直すか、何を作り直すか」を決めることが重要です。
特に、Web化すべき業務と、オンプレで残す業務を切り分けることを意識しないまま進めると、パッケージを入れても周辺Excelが残ったり、スクラッチで作っても現場が使いにくかったりします。相談段階では、資料が完全にそろっていなくても問題ありません。画面、帳票、運用メモ、担当者の記憶を集めるところから始めるべきです。
Web化の相談では「全部Webにしたい」と「操作性は今と同じにしたい」の両方を求められることがよくあります。この二つは多くの場合トレードオフの関係にあり、正直にそのことをお伝えしたうえで、どの業務でどちらを優先するかを一緒に決めていくのが私たちの進め方です。万能な答えはなくても、納得できる落としどころは必ず見つかります。
相談前に準備しておく情報
Web化の相談では、解決したい課題、Web化したい業務の候補、拠点とネットワーク環境、操作性で譲れない点が分かると、初回から方式と範囲の話ができます。現行画面のスクリーンショットがあると、操作性の議論が具体的になります。
実務では、現行調査でWeb化に向く業務と向かない業務を仕分け、開発前診断で方式と費用帯を比較したうえで、段階的なWeb化のロードマップをおすすめしています。
Web化の効果は、場所を選ばず仕事ができるという利便性だけでなく、端末管理やバージョンアップの負荷軽減という情報システム部門へのメリットも大きい領域です。この副次効果まで含めて投資を評価すると、稟議の説得力が増します。
業務に合ったWeb化が実現すると、出先・拠点・リモートからのアクセスという当たり前の期待に応えられるようになり、システムが「オフィスに縛られる道具」から「どこでも使える基盤」に変わります。正しく切り分けた投資は、働き方の自由度を広げる資産になります。
検討は、目的の具体化、業務ごとの向き不向きの仕分け、方式の選定、セキュリティ要件の設計、段階的な実施計画、の順で進めてください。すべてを一度にWebにする必要はありません。効果の見えるところから始めましょう。
Web化の副産物として、ブラウザのアクセスログからシステムの利用状況が把握しやすくなる点も見逃せません。どの画面がよく使われ、どの画面が使われていないかを定量的に知ることは、次の改善の優先順位を決める貴重な材料になります。
Web化は、画面の作り直しを意味する分だけ、業務の見直しの好機でもあります。使われていない項目や不要な画面遷移を整理し、新しいWeb画面をすっきり設計すれば、操作効率は今以上に上がる可能性があります。技術の変更を、業務改善のきっかけとして活かしてください。
なお、Web化後もPCでの利用が主なら、スマホ対応を急ぐ必要はありません。PC画面のWeb化とモバイル対応は別の課題として切り離し、順に取り組む方が各段階の品質を保てます。
Web化は目的を正しく設定した分だけ、確実に効果を返してくれる投資です。
必要な業務から、必要な分だけ。その見極めがWeb化の投資効率を最大にします。
一歩目を正しく踏めば、Web化は着実に業務の自由度を広げてくれます。
Web化の先にある「どこでも仕事ができる」という未来は、正しい切り分けから始まります。
よくある質問
要件がまとまっていなくても相談できますか？
はい。分かる範囲の業務内容、現在困っていること、使っている画面や帳票から整理できます。完璧な資料よりも、現状の困りごとを早めに共有することが大切です。Web化の場合、解決したい課題とWeb化したい業務の候補が分かれば十分に相談を始められます。
すぐに全面再構築する必要がありますか？
いいえ。延命・部分改善で足りる場合もあります。まずは残す部分、直す部分、作り直す部分を切り分けます。はい。照会系だけの部分Web化は最も投資対効果の高い選択肢の一つです。
パッケージとスクラッチのどちらがよいか判断できますか？
はい。業務が標準機能に合うか、帳票や例外処理をどう扱うか、将来の保守性まで含めて比較します。操作性と利便性のバランスを業務ごとに判断し、最適な方式を一緒に選びます。
500万円〜1,000万円規模の部分改善から相談できますか？
はい。データベース改善、帳票・連携、バックアップ自動化など、段階的な改善から始められる場合があります。はい。数百万円規模の照会Web化から段階的に進められます。
相談後にしつこい営業はありますか？
ありません。現状を確認したうえで、必要な進め方を整理します。無理に大きな開発を勧めることはありません。現行の画面と業務の流れをお聞かせください。向き不向きの仕分けから始めます。
