Visual Basicのシステム開発の進め方/やり方/流れや方法/手法/工程/手順

Visual Basicのシステム開発は、資産を棚卸しして現状を把握し、移行先を選んで範囲を決め、検証しながら段階的に切り替える流れで進めます。

この流れに沿うと、業務を止めずに保守性を高めやすくなります。全体像については、Visual Basicのシステム開発の完全ガイドもご覧ください。

▼全体ガイドの記事
・Visual Basicのシステム開発の完全ガイド

Visual Basicのシステム開発の全体像

画面、マスタと取引、処理と帳票、外部接続を示したVisual Basicの資産一覧図
画面の外にあるデータや連携先も棚卸しの対象です。

Visual Basicの業務システムには、Visual Basic 6.0、VB.NET、Excel VBA、Access VBAのアプリがあります。

名称が同じでも、実行環境やデータ連携、64ビット対応、Web化の方法は異なります。名前だけで種類を判断しないことが大切です。

VB6・VB.NET・VBAの違い

移行の計画では、まず対象の言語と実行環境を区別し、移行時に確認する違いを整理しておく必要があります。

  • VB6の利用実績:1990年代後半〜2000年代に、管理・受発注、計測・検査、帳票の分野で普及
  • VB6の開発環境:IDEの開発サポートは終了している
  • VB6ランタイム:対応Windowsのサポート期間内に既存アプリを動かす範囲が対象で、64ビットOSでは32ビットのWOW環境が前提になる
  • VB.NET:.NET上の後継系言語だが、VB6とは完全に同じではない
  • VBAと資産確認:Excel・Accessのマクロで、VB6とは配布・権限・版管理の方法が異なる

VB6 IDEとVisual Studio 6.0 IDEの開発サポートは、2008年4月8日に終わっています(出典: Microsoft Learn「Visual Basic 6.0 のサポートに関するお知らせ」)。

VB.NETへ移す場合、ActiveXやOCX、Win32 APIは、自動変換だけで解決しないことがあります。

古いデータアクセス方式や帳票部品も、自動変換だけで解決しない場合があります。

ファイルの種類は拡張子だけで判断せず、実行ファイルやソースに加えて、プロジェクト定義やデータベースまで確認します。

参照部品とタスクスケジューラも対象に入れます。

画面以外の資産を含めたシステムの捉え方

移行前の棚卸しでは、画面のほかに次の資産も確認します。

  • マスタと取引:顧客・商品・仕入先、受発注・入出庫・売上・請求データ
  • 処理と帳票:日次・月次バッチ、納品書・請求書、CSV・EDI連携
  • 外部接続:計測機器、メール、ファイルサーバーとの接続

資産一覧には、利用部署や端末、利用頻度を書き込みます。

入出力先やDB、外部連携先、障害時の手作業も記録します。

画面の一覧だけでは見えない業務は、ヒアリングで把握します。たとえば、月末だけ使う画面や、特定の担当者しか知らない締め処理がそれに当たります。

帳票をExcelで加工して提出する手順も記録しておきます。担当者が退職した後も、業務ルールとデータを引き継げるようにするためです。

ポイント

移行の判断に迷ったら、画面だけでなくデータ、帳票、バッチ、外部連携まで含めて資産を洗い出すことが目安です。VB6・VB.NET・VBAの違いも、その前に区別しておきます。

Visual Basicのシステム開発の進め方と6フェーズ

現状を整理し、移行先と範囲を決めてから開発に入ると、失敗を抑えやすくなります。

作業は要件整理から始まり、方式選定、設計・開発と進みます。その後は、テスト、稼働を経て定着へ至り、フェーズ1から6へ順に進みます。

各段階の成果物と判断基準は、フェーズごとに整理しておきます。

フェーズ1:要件整理と「何を残し、何を変えるか」の決定

まず、現行システムの利用者と業務範囲、画面・帳票・バッチの数、ソース量を調べます。データベースや外部部品、連携先も確認します。利用端末と障害履歴も欠かせません。

仕様書がない場合でも、前提は別の方法で確かめられます。コード解析や画面操作の記録、SQLと設定の確認、担当者への聞き取りを組み合わせると、前提を見える形にできます。

要件整理では、次の条件を明らかにしたうえで移行範囲を決めます。

  • 現行環境:VB6・VB.NET・VBAのどれに当たるか、64ビット化やWeb化が必要か
  • 業務要件:停止できる時間、現行と同じ操作性が必要か、保存する過去データの期間
  • 運用要件:法令や監査に関わる帳票・ログ、移行後の保守担当者

成果物の中心は資産一覧と業務フローです。ほかに、機能とデータ項目の一覧、課題と優先順位、対象外の範囲を残します。

フェーズ2:VB.NET・C#・Web・パッケージの選定

業務と運用の優先事項に合わせて、候補の方式を絞り込みます。

  • VB.NET:Windows画面と複雑な業務ロジックを、短期間で引き継ぐ場合
  • Web再構築:C#を含むWebアプリで、Web・クラウド・複数端末・外部API連携を広げる場合
  • パッケージ・SaaS:受発注や経費精算など標準化しやすい業務の場合

PoCでは、代表画面と複雑な帳票を対象にします。DBアクセスや外部部品、データ移行の一部も含めます。

自動変換率だけで判断せず、ビルドや実行のエラー、手修正の量を見ます。画面操作や帳票の印刷、処理時間、データ照合も確認します。

保守担当者が読めるコードになっているかも確認します。そのうえで、PoCの費用、期間、成果物と、本番で再利用できる範囲を契約書に記載します。

フェーズ3:設計・開発での業務ルールの実装

設計では、見た目だけでなく業務ルールも定義します。権限と承認、採番、締め処理が中心になります。取消と復旧、データ保持期間も含めます。

外部連携の再送方法も決めます。また、VB6では画面イベントにSQLや業務ルールが埋め込まれている場合があるため、ここは特に丁寧に確かめる必要があります。

変換後のソースが動くことを確かめるだけでなく、業務ロジックを役割ごとに整理します。

移行の進め方は、一括移行のほかに、段階移行と新旧連携から選べます。

  • 段階移行:参照系や帳票を先に移し、主要な登録処理を後から移す
  • 新旧連携:基幹データを新基盤に寄せ、既存VB画面とAPI・ファイルでつなぐ

納品物の中心は要件定義書と基本・詳細設計書です。ほかに、DB定義、移行設計書、テスト仕様書を含めます。

運用手順書と障害対応手順書も整え、特定の担当者に頼らず運用できるようにします。

フェーズ4:テストでの現行との差分とデータの照合

テストは単体から受入まで段階を分けて進め、移行リハーサルも行います。画面の表示以外にも、月末・年度末の処理や税計算を検証します。在庫と残高、CSVの文字コード、印刷位置も対象になります。

夜間バッチの動作や、連携先が止まったときの再送、権限外データへのアクセス拒否も、テストの対象に入れます。

受入テストでは、現新比較を行います。

個人情報や機密情報を扱う場合は、セキュリティの条件も一緒に確認します。

  • 現新比較:同じ条件で件数、金額、残高、在庫、エラー件数を照合する
  • アクセス管理:最小権限の付与、認証、管理者権限の分離を見る
  • 運用保護:操作と変更のログ、バックアップからの復旧、脆弱性への対応、環境の分離

セキュリティの確認では、IPA「情報セキュリティ10大脅威 2025 組織編」や個人情報保護委員会のガイドラインを参照します。

委託先のセキュリティ回答書も確かめます。

フェーズ5:稼働での並行運用と切り戻しの設計

稼働前には、データの抽出・変換・投入、バックアップ、照合を確認します。

利用者アカウントの作成や端末の配布も、稼働前の確認に含めます。

問い合わせの窓口も用意しておきます。

特に重要な業務では、旧新の両方を一定期間並行して動かし、日々の件数と金額を照合します。

並行稼働が難しい場合は、最終バックアップを取ったうえで、障害時に旧環境へ戻す条件を決めておきます。

切り替えを判定する際は、次のような業務と運用の基準を定めておきます。

  • 業務処理:受注・発注・売上を登録でき、帳票も正しく出力できる
  • 連携と締め:外部連携が完了し、月次締めの結果が一致する
  • 障害と権限:権限エラーがなく、未解決の重大障害がゼロである

当日は、作業や業務の責任者、ベンダー、インフラ担当者の連絡先と判断権限を明確にしておきます。

時間外の緊急対応についても、方法をあらかじめ共有します。

フェーズ6:定着での保守と現場運用の整備

稼働後も利用者の支援と保守を続けられるよう、体制を整えます。

  • 現場支援:問い合わせ、入力ミス、帳票の再出力、データ訂正、権限申請、障害の一次切り分けを手順にまとめ、キーユーザーが利用者を支援する
  • 定着確認:稼働後1か月、3か月、6か月などの時点で、利用率、処理時間、手作業の削減、問い合わせ件数を見る
  • 保守契約:対応時間、障害優先度、復旧目標、軽微な改修、OS・ミドルウェア更新時の検証、バックアップ確認、ソース・設計書の管理者を取り決める
  • 更新計画:製品ごとのサポート期限の確認

たとえば、Visual Studio 2022はメインストリームサポートが2027年1月、延長サポートが2032年1月までです(出典: Microsoft Learn「Visual Studio 2022 – Microsoft Lifecycle」)。

.NETやデータベース、帳票部品、OSには、それぞれ個別のライフサイクルがあります。そのため、次回の更新時期と担当者も定着計画に含めておきます。

ポイント

進め方で迷ったら、要件整理で「何を残し、何を変えるか」を先に決め、PoCで手修正の量を見極めてから本番の見積もりに進むのが目安です。

Visual Basicのシステム開発にかかる費用相場

小規模から大規模までのVisual Basic移行費用の目安を示す横棒図
規模が大きくなるほど、示される費用レンジも上がります。

開発費を決めるのは、言語名よりも中身です。規模に関わるのは画面や帳票、バッチ、データ量です。さらに、連携や仕様書の有無、方式、テスト範囲も関わります。

見積もりには、並行稼働や教育、保守も含めて考えます。ここで挙げる目安は、2026年に公開された民間の目安や事例で、公的な平均額ではありません。

規模別の費用と期間の目安

公開されているVB移行の費用と期間の目安は、規模によって異なります。

  • 小規模:画面10〜20本、単純帳票中心で300万〜800万円、3〜6か月
  • 中規模:画面30〜50本、業務ロジックや外部連携ありで800万〜2,000万円、6か月〜1年
  • 大規模:画面100本超、複数業務・DB統合で2,000万〜5,000万円以上、1〜2年以上

この目安は、株式会社シースリーインデックス「VB6(Visual Basic 6)移行ガイド 2026年版」に基づいています(出典: 同社資料)。

パッケージやSaaSは、初期費用50万〜300万円に月額費用が加わり、導入は1〜3か月という別のレンジになります。

追加帳票や独自の承認が増えると、この費用感から外れていきます。また、API連携やデータ整備、利用者教育が加わるときも、この目安では収まりにくくなります。

Web・クラウド再構築には、リサーチノート上で1,500万〜6,000万円以上と推定されるレンジもあります。ただし、この数字は、業務の再設計や認証、複数端末対応まで含めた個別要件の試算です。VB固有の公的な相場ではありません。

費用を押し上げる項目の分解

画面の数以外にも、工数を増やす条件があります。調査や連携、データ移行の条件がそれに当たります。

  • 現行資産:仕様書がなく、画面イベント内に複雑なSQLがある
  • 部品と帳票:ActiveX・独自OCXが残っていて、印刷位置を完全に再現する
  • 移行・運用:複数機器やEDI連携、古いデータのクレンジング、長期の並行稼働がある

仕様書がない場合は、調査とリバースエンジニアリングを含めて、公開目安の1.3〜1.5倍になる傾向が紹介されています(出典: 株式会社シースリーインデックス「VB6移行の費用相場」)。

倍率は複雑さによって変わります。そこで、調査費を分けた段階見積もりを取ると、予算の振れを抑えやすくなります。

ポイント

費用を比べるときは、公開目安をそのまま予算にせず、仕様書の有無と連携・帳票の条件を見て、どの要素で金額が上下するかを押さえるのが目安です。

Visual Basicのシステム開発の見積もりを取る際のポイント

プログラム、データ・設定、運用情報の3項目を示す見積もり依頼資料のチェックリスト
この三分類で、開発物から日々の運用まで共有できます。

見積もりは、合計額だけでなく、含まれる作業と追加費用の条件をそろえて比べます。そのために、同じRFPを2〜3社に渡します。調査やPoC、設計はもちろん、移行や教育、保守までを別々に示してもらうと、比べやすくなります。

RFPと資産一覧に載せる最低限の情報

RFPには、対象業務と利用者・拠点数を書きます。稼働時間や画面・帳票・バッチの数も記載します。

DBと外部連携、現行OSも伝えます。部品や保存期間、性能の条件も示します。権限やログ、バックアップについても、RFPに含めます。

希望時期と、業務を止められる時間も示します。全件を数えられない場合は、代表画面と複雑な帳票を提示します。

調査の段階で確定する前提も明記しておきます。依頼資料には、次の資産をそろえます。

  • プログラム:ソース、プロジェクトファイル、実行ファイル
  • データ・設定:DBバックアップ、帳票定義、OCX・DLL、設定ファイル
  • 運用情報:バッチ定義、端末、障害一覧、担当者の手順書

仕様書がないことも伝えたうえで、調査の成果物を確かめます。画面一覧や処理概要が納品に含まれるかを見ます。データ項目や連携一覧、未確認事項も対象です。

ベンダーの実績と見積条件の比べ方

変換率だけで判断せず、発注後に必要になる作業と成果物を比べます。

  • 技術対応:VB6・VB.NET・VBAの範囲、現状調査、自動変換と手修正の分担
  • 移行実績:画面・帳票・バッチ・連携、データ移行と現新比較、PoC費用
  • 品質と引き継ぎ:エラー修正、帳票部品、性能、テストの実績、設計書・ソースの引き渡し、移行後の保守担当者

公開事例では、株式会社ケイケンシステムがVB6.0とCOBOLの生産管理システムを移行しています。具体的には、240画面とバッチ・帳票45機能の規模でした。4か月、30人月でVB.NETへ移行した事例です(出典: 同社「Visual Basic マイグレーション」)。

株式会社第一コンピュータリソースの実績一覧には、28本・3か月、159本・7か月、357本・12か月の移行事例が載っています。

いずれも個別事例です。そのため、自社の価格や納期に直結させず、規模と作業範囲の比較に使います。

安すぎる見積もりの対象外と追加費用

調査やデータ移行、帳票が対象外になっていると、後から費用が増える可能性があります。結合テストや教育、並行稼働、稼働後対応も、対象外かどうかを確かめてください。

見積書では、まず前提と対象の画面・帳票を確認します。そのうえで、移行データの期間やテストの範囲を見ます。利用者の作業と除外項目も必ず押さえます。

追加変更の単価と、納期が遅れる場合の条件も確かめておきます。次の質問で、前提に食い違いがないかを見ます。

  • 調査・部品:仕様書がない場合の調査費とActiveX・独自OCXの扱い
  • 検証・切り戻し:照合帳票、切り戻しの担当者と手順
  • 納品・保守:ソース・設計書の受領、担当退職時の引き継ぎ

前提とリスクを書面で明記する会社を選ぶことで、発注後の認識差を小さくできます。

ポイント

見積もりは、合計額よりも含まれる作業と除外項目をそろえて比べるのが目安です。依頼資料が足りなければ、比較の前に前提を埋めます。

Visual Basicのシステム開発でよくある質問

VB6の稼働や自動変換、移行中の業務継続について、発注前に知っておきたい点をまとめます。

VB6のシステムはすぐに動かなくなりますか?

すぐに動かなくなるとは限りません。ただし、今動いていることと、将来も安全に保守できることは、別々に考える必要があります。

  • サポート環境:IDEの開発サポートは終了している。既存のランタイムは、サポート対象のWindows上で動く場合がある
  • 互換性確認:ランタイムは32ビットで、64ビットOSではWOW環境が前提。OS・ミドルウェア・部品・プリンター・端末の更新のたびに動作を確かめる

VB6からVB.NETへ自動変換すれば開発は終わりますか?

自動変換だけで開発が完了するとは限りません。

  • 手修正の確認:ActiveX・OCX、Win32 API、古いデータアクセス、帳票部品、画面イベント内の業務ロジックを調べる
  • PoCで検証:代表画面と複雑な帳票を変換し、ビルドや実行のエラー、印刷、性能、データ照合を見る

PoCの結果を踏まえ、本番の変換率と工数を見積もります。

仕様書がないVisual Basicのシステムでも移行できますか?

移行できますが、開発前に現行調査とリバースエンジニアリングが必要です。

  • 調査対象:ソース、実行画面、DB定義、ログ、担当者の操作、例外処理を突き合わせて見る
  • 調査成果:画面・処理・データ・連携の関係を設計書にまとめる

調査を省くと、暗黙のルールが後から追加要件になり、費用や納期も変わりやすくなります。

移行期間中に業務を止めない方法はありますか?

旧新の並行稼働、業務ごとの段階移行、休日や締め処理後の切り替えを組み合わせます。旧新で件数と金額を照合し、残高と在庫も合わせて確かめます。切り戻しの条件と期限は、あらかじめ決めておきます。

一括で切り替える場合も、事前に移行リハーサルを行い、バックアップと復旧手順を確かめておきます。

ポイント

移行の不安は、今動くかどうかよりも、保守とテストで何を確かめられるかで判断するのが目安です。自動変換や仕様書の有無を理由に、調査や検証を省かないことが大切です。

Visual Basicのシステム開発の進め方まとめ

Visual Basicの移行では、VB6をVB.NETへ機械的に変換するだけでなく、業務の中身まで捉え直す必要があります。

まず、VB6・VB.NET・VBAを切り分け、画面や帳票、バッチを棚卸しします。DBや外部連携、権限、手作業も一覧にします。そのうえで、残す機能と変える業務を決めます。

判断で押さえる3つの要点

移行先や開発方式は、操作の維持、業務の標準化、停止リスクと運用体制という観点で比べます。

  • 移行先:操作維持はVB.NET、Web展開はC#を含む再構築を比べる
  • 方式検証:標準的な業務はパッケージなど、停止リスクに対しては段階移行も検討する
  • 運用準備:PoCで手修正の量を見極め、保守・教育・設計書・更新計画まで発注範囲に入れる

最初の一歩は資産棚卸しと代表機能の調査

業務を止めずに現実的な移行計画を立てるには、次の順で調査と比較を進めます。

  1. 実行ファイルやソース、DB、帳票、バッチ、外部連携、端末、担当者、障害履歴を一覧にする
  2. 複雑な画面・帳票・DBアクセス・外部連携を各1つ選び、現状調査とPoCを依頼する
  3. 2〜3社から同条件の調査・移行方針・見積もりを取り、業務理解とテスト方法を比べる
  4. 切り戻し、納品物、保守体制も比べ、現行資産を活かす範囲と将来変える範囲を決める

リスクを見える形にして、業務を止めない計画を立てます。古さだけを理由に全面刷新へ進まず、現行資産の活かし方を先に決めます。

活用する資産と変更する範囲を分けておくと、費用と納期を管理しやすくなります。

▼全体ガイドの記事
・Visual Basicのシステム開発の完全ガイド

会社紹介

株式会社riplaでは、お客様の事業・ユーザー・業務に最適化したオーダーメイド型システムを、構想策定・要件定義から開発・改善まで一気通貫で支援。事業会社でIT・DXを経験したプロフェッショナルによる高い要件定義力・システム設計力を活かし、事業成果の最大化に伴走します。

また、当社独自の開発テンプレート「Boxシリーズ」による標準機能の高速開発と、AI駆動開発の独自フレームワーク「GoDD」による独自機能のAI実装を組み合わせることで、低コスト・短期間で開発を実現いたします。

もし、システム開発やプロダクト開発に関するご要望がございましたら、お気軽にお問い合わせください。

・サービス概要資料のURLはこちら >>>
・お問合せページのURLはこちら >>>
・お役立ち資料のURLはこちら >>>

執筆者プロフィール
張田谷凌央
張田谷凌央

株式会社ripla 代表取締役CEOとして、システムパッケージ活用、システム開発、データ分析、生成AI活用、SaaS開発、アプリ開発、EC構築など、幅広い領域で企業のDX推進と事業成長を支援している。事業会社でIT・DXを経験したプロフェッショナルが集う株式会社riplaにおいて、お客様の事業・ユーザー・業務に最適化したオーダーメイド型システムを構想策定・要件定義から開発・改善まで一気通貫で支援し、単なるシステム納品にとどまらず、クライアントと同じ目線で事業成果の最大化に向けた伴走支援を行う。早稲田大学卒業後、ラクスル株式会社、LINEヤフー株式会社にて事業開発やDX推進などに従事した後、株式会社riplaを創業。