目次
はじめに：VCL資産を“捨てずに”Web化したい
多くの企業で稼働している Delphi 製デスクトップアプリ（VCL）。
「Web化したいが、Java/JavaScriptでゼロから書き直す予算も時間もない」——この課題は非常に現実的です。
そこで、既存の Object Pascal コードを極力再利用しながら Web アプリへ移行する現実的な解法として、
TMS WEB Core に注目が集まります。
本記事では、金融計算アプリをモデルケースに、移行の進め方と設計の勘所をまとめます。
なぜ全面書き換えがつらいのか（失敗しやすい理由）
-
1) “全部同時に変える”と検証が破綻しやすい
UI/操作フロー/配布方式/権限/出力などを一度に刷新すると、テスト範囲が爆発し、品質もスケジュールも守りにくくなります。 -
2) VCL資産の価値は、UIより“業務ロジック”にある
長年積み上げた計算・判定・バリデーションは組織の知見そのもの。ここを捨てるほど手戻りが増えます。 -
3) Webはデスクトップと前提が違う
ローカルファイル操作やダイアログ、ウィンドウ制御などは、そのまま移せません。Web流儀への置き換えが必要です。
全体を書き直す必要はない：「ロジック」と「UI」を分ける
Web移行の最大の障壁は「再開発」への恐れです。
しかし、TMS WEB Core を用いると、複雑な計算ロジックやデータモデルはDelphi（Object Pascal）のユニットとして再利用しやすくなります。
移行の戦略：モノリシックなVCLから“ロジック”を切り離す
- UI（フォーム）に詰まった計算処理を、計算専用ユニットへ移す（例：uCalculators 等）
- 入力チェック（バリデーション）もUI依存を避けてユニット化する
- データモデル（DTO/構造体）を整理し、画面と分離する
メリット：移行の工数とリスクを同時に下げられる
- ロジックは“コピペに近い感覚”で移行でき、バグ混入を抑えやすい
- UIだけをWeb用に最適化すればよく、設計の見通しが良くなる
何が流用でき、何を作り直すべきか（切り分けの目安）
流用しやすい（価値が高い）
- ビジネスロジック：金融計算、判定、集計、丸め処理、手数料・利率計算など
- データモデル：計算入力・計算結果の構造（DTO）、ドメインモデル
- バリデーション：入力チェック、業務ルール、整合性チェック
作り直し中心（Web前提で置き換え）
- UI：画面レイアウト、操作感、一覧/検索/フィルタなどのUX
- UI近接処理：イベントに密結合した処理（OnClickにロジックが混在等）
- デスクトップ固有：保存ダイアログ、ローカルパス前提、ウィンドウ制御、印刷前提
ポイントは「全部移植しない」こと。
ロジックを守り、UIをWebで最適化——これが最も手堅い移行方針です。
デスクトップ特有の機能はどうする？（ファイル操作・出力の置き換え）
VCL と Web では作法が異なります。典型例が TSaveDialog のような「ファイル保存ダイアログ」です。
Webには同等の仕組みがないため、Webの前提に合わせた設計へ置き換える必要があります。
解決策：ブラウザのダウンロード機能へ寄せる
- CSV/JSONなどのデータをメモリ上で生成し、ブラウザ経由でダウンロードさせる
- PDF/Excelなどの帳票は、サーバー生成 or 生成済みファイル配布の方式へ整理する
重要なのは「デスクトップの操作を再現」ではなく、ユーザーが目的を達成できるWeb流儀へ落とし込むことです。
そして、その置き換えロジックはPascal中心で実装しやすい点が、TMS WEB Coreの強みになり得ます。
ただの移植ではない：Bootstrapで“Webらしい”UIへ刷新
単にWebで動くだけではなく、見た目も今風にしたい——これは移行案件では自然な要求です。
ただし「VCLの見た目をそのまま再現」しようとすると、Webの強み（レスポンシブ、統一デザイン、部品再利用）が活きません。
デザインの適用：Bootstrapで一気にモダン化
- CSSフレームワーク Bootstrap を適用し、モダンなUIの土台を作る
- ボタン/フォームなどにクラスを付与し、Web標準の見た目と挙動へ寄せる
実装の勘所：まず“動く”→ 次に“整える”
最初から完璧なUIを狙うより、①機能を成立させる → ②Bootstrapで整えるの順が手戻りを減らします。
「移植感」を消すのは、完成直前ではなく段階的にUXを改善する方が現場で受け入れられやすい傾向があります。
（画像を入れるなら）「移行前（VCL画面）」と「移行後（Web画面）」を並べると、効果が一目で伝わります。
参考：金融計算アプリの分割イメージ（ユニット構成例）
移行をスムーズにするために、責務を分けた“最小構造”を用意します。
例えば、次のように分割すると、流用と改善を両立しやすくなります。
| 役割 | 例 | 目的 |
|---|---|---|
| UI（画面） | メインフォーム/入力フォーム | Web UX 前提で再設計（見た目・動線） |
| 計算ロジック | uCalculators 等 | VCL資産を流用しやすい中核 |
| モデル/DTO | 入力・結果の構造 | UIとロジックの橋渡し |
| バリデーション | 入力チェックユニット | 業務ルールをUIから分離 |
| エクスポート | CSV/JSON/PDF等 | Web前提（DL/配布）へ置き換え |
この構造にしておくと、「ロジックは守る」「UIは変える」が実装レベルでやりやすくなります。
TMS WEB Core が“移行”に向く理由
DelphiチームがWeb移行でつまずきやすいのは、「Webのために別言語・別スタックを丸ごと覚える」負荷です。
TMS WEB Core は、Object Pascal（Delphi）を主軸にWebアプリを構築できるため、
JavaScript中心の開発に比べて既存チームの知識を活かしやすい選択肢になります。
- 既存資産（Pascalコード）を活かしやすい：ロジック移行の心理的・工数的コストを下げる
- 段階移行と相性が良い：機能単位でWeb化し、適用範囲を広げやすい
- “Webの置き換え”を設計しやすい：保存/出力/状態管理などのポイントを整理して実装に落とし込みやすい
- UI改善を後追いできる：まず動くものを作り、Bootstrap等で段階的に整える
もちろん、HTML/CSSやWebの基本的な考え方は必要ですが、React/Vue等を前提にしなくても DelphiチームでWeb移行を進めやすい点は大きなメリットです。
失敗しない評価（PoC）の進め方
PoCで重要なのは「作れるか」だけでなく、運用に耐えるかを確認することです。
-
ステップ1：対象を1機能に絞る
例：計算画面、参照画面、レポート出力など（価値が見えやすい箇所から） -
ステップ2：KPIを決める
例：開発工数、手戻り回数、問い合わせ数、更新手順の簡素化、操作性の評価 -
ステップ3：置き換えポイントを先に設計
保存/出力、状態管理、認証・権限など、Webで前提が変わる箇所は先に決める -
ステップ4：併存期間も含めて評価
デスクトップとWebが共存する期間の利用フロー、データ整合、運用手順を確認する
まとめ：最もリスクの少ない移行パスと次の一手
Delphi/VCL資産のWeb化は、単純な移植ではなく、「業務ロジックを守り、UIはWebで最適化する」発想が近道です。
いきなり全面刷新に踏み込むのではなく、機能単位の段階移行で進めることで、リスクと工数を抑えやすくなります。
- 計算ロジックは流用し、品質と工数のリスクを下げる
- UIはWebで刷新し、UXと運用性（配布・更新）を改善する
- 保存/出力などのデスクトップ前提は、Web流儀へ置き換える
当ブログでは今後も、さまざまな知見やリサーチ結果を実務にどう結びつけるかという観点で発信してまいります。
ぜひブックマークのうえ、最新記事をお見逃しなく！