クライアント／サーバシステムのWeb化
クライアント端末依存からの脱却。主要レガシーシステム（Delphi／PowerBuilder／Oracle Forms／Access）のWeb化。
「PCごとの環境設定や更新配布に追われる」「社外から利用できない」といった運用課題をWeb化によって解決します。既存の業務プロセスやデータ構造を尊重し、現場に混乱を与えない安全な移行ルートをご提案します。
Challengesこの移行で問題になりやすいこと
言語を問わず、C/S型システムが直面する構造的な課題。
開発言語の違いにかかわらず、クライアント／サーバー構成の業務システムは共通の運用課題を抱えています。端末個別のインストールを前提としているため、業務変更や機能改修のたびに全端末への配布・検証作業が発生し、ビジネスの変化に迅速に対応できない構造を生み出しています。
端末ごとのインストールと版数管理
改修のたびに全端末へ配布が必要で、版数がずれた端末が残ります。「あの人のPCだけ動かない」が慢性化している状態です。
社外・他拠点から使えない
社内ネットワークにいないと動かないため、在宅勤務や拠点間での利用に対応できません。この一点が刷新のきっかけになることが増えています。
画面に業務ロジックが書き込まれている
フォームのイベント処理の中に計算とデータ更新が書かれている状態です。言語だけ置き換えても、この構造は残ります。
動く端末が減っていく
OSやランタイムのサポートが切れ、新しいPCでは動かない。古いPCを予備で確保している、という運用になっている場合もあります。
Method現行言語ごとの勘所
4つの言語それぞれにおける、資産棚卸しの重点確認項目。
直面する課題の根底は共通していても、コードの構造や解析のアプローチは言語ごとに大きく異なります。当社では初期の棚卸し段階から各技術スタックの固有仕様を踏まえ、潜在的な移行リスクを正確に洗い出します。
| 現行言語 | この言語で特に確認すること | 移行先の例 |
|---|---|---|
| Delphi | VCLコンポーネントへの依存範囲、サードパーティ製コンポーネントの代替有無、データモジュールに集まっているDBアクセス処理の切り分け | Java ／ C#.NET ／ Web |
| PowerBuilder | DataWindowが持つ業務ルール（検証・集計・表示制御）の洗い出し。ここに業務仕様が凝縮されていることが多く、画面定義としてだけ扱うと落とします | Java ／ C#.NET ／ Web |
| Oracle Forms ／ Reports | フォームトリガーとPL/SQLの分担、DB側に置かれた業務ロジックの範囲、帳票（Reports）の再現要件 | Java ／ React・Vue.js ／ REST API |
| Access ／ FileMaker | 同時利用時の整合性の取り方、ファイル分散の有無、マクロとVBAに書かれた処理。部門ごとに派生ファイルが増えていることが多く、まず名寄せから | Web ／ .NET ／ RDB |
いずれの言語も、画面定義の中に業務ルールが置かれている点が共通しています。そのため棚卸しでは、ソースコードだけでなく画面定義とDB側の処理まで含めて読み解きます。
AccessAccessからの移行 — 移行先の選び方
Accessシステムの移行先には、大きく分けて「ノーコード／SaaSへの載せ替え」と「専用Webシステムとしての再構築」という2つのアプローチが存在します。どちらを選択するかによって、導入スピードや初期コストだけでなく、将来的な機能拡張性や業務適合度が大きく異なります。
| 観点 | ノーコード・SaaSへ移す | 自社専用のWebシステムにする |
|---|---|---|
| データの置き場所 | サービス提供事業者の環境に置かれます | 自社の環境に保持します。分析にも二次利用にも、そのまま使える形で残ります |
| 業務に合わせた作り込み | ツールが用意した機能の範囲内で構成します。現行の業務ルールをそのまま再現できない箇所は、運用側で吸収することになります | 現行の業務仕様に合わせて設計します。現行の業務の進め方に合わせて移行します |
| データの集計・分析 | 標準機能で用意された範囲での集計になります | ご要件に合わせて範囲を設計できます。他システムのデータと突き合わせた分析も設計に含められます |
| 生成AIとの連携 | サービス側が対応している範囲に依存します | 前提として設計できます。業務データをAIで扱える構造にしたうえで移行します |
| 費用のかたち | 月額の利用料が継続して発生します | 初期構築が中心で、保守は範囲を決めてお取り決めします |
| 将来の作り替え | サービスの仕様変更・提供終了の影響を受けます | 資産が自社に残ります。次の刷新も自社の判断で進められます |
業務が定型で、標準機能の範囲で十分に回る場合は、前者が早く安く収まることもございます。一方で、現行の業務ルールを保ったまま移したい、基幹システムと連携している、データを分析や生成AIに活かしていきたい——こうしたご要望がある場合は、自社専用のWebシステムとして作り直す方法をご提案しております。
Access1本からでもご相談いただけます
対象が1システムであれば、範囲が限られているぶん、現行の棚卸しからお見積りのご提示まで短期間で進められます。まず1本を移してから、他の業務へ広げていく進め方も承っております。
Approach移行方式の選択肢
Web化の適用範囲は、実際の業務フローと利用頻度に応じて段階的に定めます。
システム全体を一括で刷新する必要はありません。外出先からアクセスする営業・現場向け機能だけを先行してWeb化し、社内専用の定型業務は既存環境を維持するなど、業務特性に応じた優先順位付けとスコープ分割により、リスクとコストを抑えた確実な移行を実現します。
| 方式 | 内容 | 適する場合 |
|---|---|---|
| 全面Web化 | 全機能をWebアプリケーションへ再構成する | 端末管理の負荷を根本的に下げたい場合。社外・他拠点からの利用が要件にある場合 |
| 段階的Web化 | 利用頻度の高い機能から順にWebへ移し、並行稼働させる | 一度に切り替えるリスクを避けたい場合。予算を分けて確保したい場合 |
| デスクトップのまま刷新 | 構成は保ったまま、言語と実行環境だけを新しくする | 社内限定の利用で、端末数が限られている場合。まず動く形を早く作りたい場合 |
| リビルド | 業務要件から作り直す | 現行の作りが業務の実態と合わなくなっている場合。移行ではなく新規開発として扱います |
段階的Web化の場合、並行稼働の期間にデータをどちらで持つかを先に決めておく必要があります。ここを曖昧にしたまま進めると、両方に書き込まれる状態が生まれます。
Cautionこの工程で見落とされやすい点
| 見落とされやすい点 | 内容 |
|---|---|
| 画面定義を「見た目」としてだけ扱うこと | PowerBuilderのDataWindow、Oracle Formsのトリガー、Accessのマクロには業務ルールが書かれています。画面を作り直す際に、この制約を拾い直す必要があります |
| サードパーティ製部品の代替確認を後回しにすること | 代替のない部品が実装段階で出てくると、設計に戻る手戻りになります。棚卸しの段階で洗い出します |
| 帳票の再現範囲を決めずに進めること | 印刷レイアウトは業務側の受入基準に直結します。要件として早めに確定させたほうが手戻りが小さくなります |
| Excel連携を仕様から外すこと | 出力したExcelを別の業務で使っている場合、その形式まで含めて移行対象です |
| 同時利用の想定が変わることを見落とすこと | Web化すると同時アクセス数が増えます。排他制御の設計を現行のまま持ち込まないようにします |
Scope対応可能な範囲
守秘義務の観点から個別実績の公開を控えておりますが、当社が対応可能な業務範囲を以下に明記しております。
C/S（クライアント／サーバー）構成の業務システムにおいて、現行コードの解析・資産棚卸しから、新環境での設計・実装、さらにはデータ移行や新旧データ突合検証に至るまで、一気通貫で責任を持ってお引き受けいたします。
| 作業範囲 | 内容 |
|---|---|
| 現行資産の棚卸し | ソース・画面定義・DB側処理・帳票の一覧化と、使用状況の確認 |
| 現行業務仕様の文書化 | 画面定義とDBに置かれた業務ルールを含めて文書化します |
| 移行方式の決定 | 全面Web化／段階的Web化／デスクトップ刷新の切り分け |
| 新環境での実装 | Java ／ C#.NET ／ React・Vue.js など、保守体制に合わせた構成で |
| データ移行と突合 | 移行前後の全件突合を前提に進めます |
| 総合テストと受入支援 | お客様の受入基準に沿ってご支援します |
Team Structure誰が担当し、誰が責任を持つか
システム移行の実現性評価や適用範囲の決定は、コミュニケーションが成否を分ける工程です。当社ではこの根幹となるフェーズを日本法人の責任者が直接担当し、品質・納期に対するガバナンスと説明責任を徹底いたします。
| 項目 | 内容 |
|---|---|
| 現行資産の解析 | 技術者が実際に読み解き、現行の業務仕様として文書化します。運用されている方への確認と、実データとの突合も併せて行います |
| 要件の確定・設計の承認 | 日本法人（株式会社DEHA SOLUTIONS）が担当します。窓口は日本側で一本化しており、仕様のやり取りで齟齬が出ない体制です |
| 実装・テスト | 要件が確定したあとの工程を、協力会社 DEHA VIETNAM（ハノイ・200名以上）が担います。CMMI Development & Services レベル3の評定を受けたプロセスと三層QAのもとで進めます。協力会社 DEHA VIETNAM は ISO/IEC 27001:2022 の認証を取得しています |
| 責任の所在 | 契約の当事者は当社（日本法人）です。請負契約では成果物の完成について、準委任契約では業務の適切な遂行について、当社が責任を負います |
まずは無料レガシー簡易診断からご相談いただけます
移行をご判断いただく前の段階でも構いません。資産一覧をお送りいただくだけで、概算と移行リスクの見取り図をお返しします。ソースコードのご提供は不要です。その先の現行調査（As-Is分析）は、稼働中のシステムを変更しない読み取り専用の解析で、作業範囲とお見積りを着手前に確定いたします。
無料レガシー簡易診断を申し込む 現行調査（As-Is分析）についてFAQよくあるご質問
作った担当者がもう社内にいないのですが。
そのような状態からのご相談も承っております。ソースコードと画面定義から現在の業務仕様を取り出して文書化する工程からご一緒しますので、社内に読める方がいらっしゃらない前提で進められます。
全面的にWeb化する必要がありますか。
いいえ。利用頻度の高い機能から順に移す段階的な進め方もご提案できます。社内限定の利用であれば、構成は保ったまま言語と実行環境だけを新しくする選択肢もあります。
部門ごとにファイルが分かれてしまっているのですが。
Access や FileMaker でよくご相談いただく状態です。まず何がどこにあるかを一覧化し、同じ業務項目の名寄せを行う工程から始めます。
見た目は今のままにできますか。
操作に慣れた画面をなるべく保つ方針でご提案することが多いです。ただしWebでは実現しにくい操作もありますので、棚卸しの段階で代替案とあわせてご相談いたします。
費用の考え方・体制・品質保証について
費用の構成要素、プロジェクト体制と責任の所在、品質保証の仕組み、そして刷新を任せる相手を選ぶ観点については、モダナイゼーションのページにまとめております。C/SシステムのWeb化に限らず共通してご確認いただける内容です。
モダナイゼーション全体のご案内へレガシー刷新の進め方（全体） ／ 業務ロジック可視化・設計書復元 ／ 移行後の運用保守・AI活用 ／ レガシー刷新の導入事例
現行資産の棚卸しからご相談いただけます
設計書が残っていない、あるいは社内にコードを読み解ける有識者が不在といった状況でも問題ございません。まずはソースコード解析等を通じて現状を可視化し、安全な次の一手を共に検討します。