「Visual Basic（VB）はなぜC#のように進化しないのか？」――現場から頻繁に届く問いに、感情ではなく事実と実務で答えます。本記事は、VBの技術的・市場的背景を整理しつつ、モバイルやクラウド対応が求められる今後に備えた“現実解”を提示します。移行を前提にしない選択肢も含め、意思決定と実行のためのチェックリストやロードマップまで一気通貫で解説します。
Visual Basic が C# のように進化しない理由と、現場で効く対処策
VBは長い歴史と学習コストの低さから、社内業務やデスクトップ開発の現場で長く重宝されてきました。一方で、.NETの進化はここ数年、C#を中心に加速しており、最新SDK・テンプレート・クラウド／モバイルのファーストクラスサポートはC#が前提で進みます。これは「VBが劣っている」からではなく、言語仕様・コンパイラ・IDEの三点セットで継続投資するコストに対して、ユーザー規模やエコシステム（学習資料・OSS・求人・事例）がC#へ集中しているためです。
| 観点 | 現状 | 現実的な対処策 |
|---|---|---|
| 技術的背景 | .NETの新機能はC#で最初に設計・提供されやすい。VBで同等機能を届けるには追加の言語・コンパイラ・IDE対応が必要。 | VBは安定維持を前提に、重大バグ修正とプラットフォーム追従に期待する。先端機能はC#側で採用。 |
| 市場・人材 | サンプル、ドキュメント、NuGet、求人、コミュニティがC#に集中。 | 新規開発・採用・教育はC#軸で計画。VB人材には短期C#リスキリングを提供。 |
| デスクトップ用途 | WinForms/WPFのVBは引き続き実用。ツールやデザイナはC#優先で更新。 | 既存資産の保守・追加はVBで継続可。UIや新規機能は段階的にC#へ。 |
| モバイル | .NET MAUI等の公式テンプレートはC#前提。 | C#に切替、またはVBのドメイン層をライブラリ化し、C#のUIプロジェクトから再利用。 |
| クラウド | 最新のAzure SDK・IaC・サーバーレスはC#の例・テンプレートが豊富。 | クラウド面はC#で主導。VBからは共通ライブラリやREST経由で連携。 |
なぜ「VBだけ遅い（止まっている）」ように見えるのか
根本要因は投資配分です。言語機能を前に進めるには、仕様策定、コンパイラ実装、IDE統合、テンプレート・ドキュメント整備というフルスタックの追加コストが必要です。C#はユーザー数・OSS・求人・コミュニティ規模が大きく、効果（影響度）に対して投資効率が高い。一方のVBは既存資産の保守需要が主で、新規開発の牽引力は相対的に小さいため、“安定運用＋互換性重視”の方針が組織合理性として選ばれやすいのです。
また、.NETの新領域（クロスプラットフォームUI、WebAssembly、クラウドのIaC/Functions、AI統合など）は、言語設計の実験が必要で、ここでもC#が先行実装の実験場になりやすい構造があります。結果として、VBは“延命”ではなく安定軸の担い手という立ち位置に落ち着いています。
なぜVBでモバイル開発が難しいのか：技術とテンプレートの事情
- テンプレート非提供：.NET MAUIや関連ツールチェーンはC#前提のテンプレートが中心。VBプロジェクトを直接生成してスムーズに動かす導線が乏しい。
- 周辺エコシステム：ドキュメント、サンプル、プラグインの多くがC#で提供され、問題解決の検索性もC#が圧倒的に高い。
- サポート面：UIフレームワークやデザイナ、ホットリロード等の開発体験は、C#で先に成熟しやすい。
とはいえ、VBの資産をすべて捨てる必要はありません。VBでドメイン層（ビジネスロジック）をClass Library化し、C#のMAUI/Blazor Hybridから参照すれば、資産継承と新規UIを両立できます。言語が違っても、.NETの共通ILとNuGetが橋渡しをしてくれます。
VB開発者は今後どう動くべきか：3つの戦略
戦略A：VB継続（保守重視）
対象は、社内向けWinForms/WPF、長期安定運用が最優先の業務システム。新規要件が限定的で、ユーザーがWindows前提の場合に合理的です。
- 最新のLTS（例：.NET 8 LTS相当）でビルドラインを整備し、長期の安定性を確保。
- 外部SDK連携が必要な箇所は、C#の薄いラッパーライブラリで吸収し、VB側は業務ロジックに集中。
- セキュリティ更新と依存パッケージ更新を四半期ごとに定期運用。
戦略B：段階的C#移行（ハイブリッド）
現実的で最も採用例が多い選択。移行コストを分割し、リスクを限定します。
- 新規機能はC#で実装、既存画面はVBで維持。
- ドメイン層から順に共有ライブラリ化してC#へ移す（Strangler Figパターン）。
- UIは最後に刷新（MAUI/Blazor/React + WebAPI等）。
戦略C：他スタックへ全面移行
モバイル・マルチプラットフォームを最優先する場合、Flutter/React Native/Swift/Kotlinなど、.NET以外を含む選択肢を比較検討。VB資産はAPI化して連携し、徐々に置換していきます。
意思決定フレームワーク：案件別の最適解を選ぶ
| 評価軸 | 重み | 質問 | VB継続なら◎ | C#移行なら◎ |
|---|---|---|---|---|
| UI要件 | 高 | モバイル/クロスプラットフォームが必要？ | 不要 | 必要 |
| 寿命 | 中 | あと何年運用する？ | 2〜3年で終息 | 5年以上継続 |
| 人材 | 高 | C#人材の採用・教育は容易？ | 困難 | 容易 |
| 非機能要件 | 中 | 最新SDK/AI/クラウド統合が必要？ | 限定的 | 必要 |
移行ロードマップ：90日で土台、12ヶ月で定常化
フェーズ0（〜30日）：棚卸しと境界設定
- 依存関係を可視化（プロジェクト、NuGet、COM、外部API）。
- 変更頻度の高い領域を特定（バグ票・改修履歴・アクセスログ）。
- 境界づけ：UI層／ドメイン層／インフラ層の切り分けを合意。
フェーズ1（〜60日）：自動テストとビルド基盤
- VBで既存機能の回帰を守る振る舞いテストを整備（UIは最小、ドメインを優先）。
- CIでVB・C#の両ビルドを一括実行、成果物の署名・リリースを自動化。
フェーズ2（〜90日）：共通ライブラリ化
- ドメイン層を.NET Standard/.NETライブラリに抽出し、VBとC#双方から参照可能に。
- 外部SDK呼び出しはC#ラッパー経由に寄せる。
フェーズ3（〜6ヶ月）：新規はC#、置換は優先度順
- 新規要件はC#（WebAPI/MAUI/ASP.NET Core/Blazor）。
- 頻繁に改修するVB画面から順にC#へ移行。
フェーズ4（〜12ヶ月）：UI刷新と終端処理
- UIをモダン化（MAUI/Blazor Hybrid/PWA）。
- 残存VBは保守フェーズとして縮退運用。最小コストで安定化。
VB→C# コンバージョン：実務の勘所
完全自動変換は困難ですが、オープンソースのコードコンバーターを併用し、変換しやすい領域から段階的に進めます。ポイントは「テストが先」「変換は小さく刻む」「設計を改善しながら進める」。
サンプル：VBからC#への最小変換
VB（ビジネスロジック例）
' VB
Public Class TaxService
Public Function Calc(net As Decimal, rate As Decimal) As Decimal
If rate < 0D Then Throw New ArgumentOutOfRangeException(NameOf(rate))
Return Math.Round(net * rate, 2, MidpointRounding.AwayFromZero)
End Function
End Class
C#（等価ロジック）
// C#
public sealed class TaxService
{
public decimal Calc(decimal net, decimal rate)
{
if (rate < 0m) throw new ArgumentOutOfRangeException(nameof(rate));
return Math.Round(net * rate, 2, MidpointRounding.AwayFromZero);
}
}
変換の勘所：
- 例外型・丸め・境界条件は振る舞いテストで担保。
- Option Strict/Infer相当の厳格化をC#側で徹底して不具合混入を防止。
VBを使い続ける場合のベストプラクティス
- LTS版の.NET上でビルド（長期サポートとセキュリティ修正を享受）。
- NuGetパッケージの再利用：C#製でも問題なく参照可能。UIやサンプルはC#中心でも、公開APIが安定していれば活用できる。
- C#ラッパーの利用：新SDKやSource GeneratorなどVBから直接使いづらい箇所は、C#で薄いFacadeを作りVBで呼び出す。
- 静的解析：Roslyn Analyzer/Styleルールで品質を管理。命名・例外・非同期・Disposeを定型化。
- テスト自動化：UIよりもドメインテストに投資。仕様変更に強い。
モバイル/クラウドを取り込む現実解：ハイブリッド構成
| 構成 | 概要 | メリット | 留意点 |
|---|---|---|---|
| VB（ドメイン）＋C#（MAUI） | VBのドメイン層をClass Library化し、C#のMAUIから参照。 | 資産継承、新UI/ストア配信、段階移行。 | UIとプラットフォーム機能はC#側で習熟が必要。 |
| VB（既存）＋C#（WebAPI/Blazor） | 新機能をWeb/APIで提供し、VBクライアントからも利用。 | ゼロダウンタイム移行、PWA/マルチ端末対応。 | 認証・CORS・APIバージョニングの設計が鍵。 |
| VB（保守）＋他スタック（Flutter/React Native） | モバイルは別スタック。VB資産はAPI越しに利用。 | UI/UXの自由度、採用市場が広い。 | チーム分断を避けるためAPI契約とモノレポ運用を整備。 |
学習と組織づくり：90日リスキリングプラン
| 期間 | 到達目標 | 教材/演習の例 | 評価方法 |
|---|---|---|---|
| 0〜30日 | C#構文・async/await・LINQ基礎 | 既存VB機能をC#クラスで再実装 | 単体テスト100ケース/バグゼロ |
| 31〜60日 | ASP.NET Core/DI/Logging | 小さなWebAPIを作成しVBから呼ぶ | スループット/エラーハンドリング評価 |
| 61〜90日 | .NET MAUI/Blazor基礎 | VBライブラリを参照するモバイル/ブラウザUI | UXレビュー/指標化（TTFB・CLS等） |
よくある誤解への回答
- 「VBは遅い」：.NETは共通ILを生成し、JIT/AOTも共通です。設計とアルゴリズムの差が支配的で、言語そのものの速度差は本質ではありません。
- 「VBはすぐ動かなくなる」：長期サポート版（LTS）を選び、OS/フレームワークの互換性ガイドに沿えば、保守に必要な期間は十分確保できます。
- 「全部書き直さないと未来がない」：段階移行とハイブリッドで費用対効果の高い置換が可能。すべての画面を一度に変える必要はありません。
コストとリスク：経営に刺さる数値化の型
| 項目 | 見積もりの観点 | 低/中/高の目安 | 削減テクニック |
|---|---|---|---|
| 変換コスト | コード行数×複雑度（循環的複雑度・依存の深さ） | UI中心は高、ドメイン中心は中 | 自動変換＋手修正、テスト先行 |
| 学習コスト | チームのC#経験・プラットフォーム経験 | 経験者多いと低 | ペアプロ、演習ベースのリスキリング |
| 運用リスク | CI/CD・監視の有無、ロールバック可否 | 仕組みがないと高 | Feature Flag、Blue/Green |
| ユーザー影響 | UI変更の大きさ、業務プロセス変更 | 大規模刷新は高 | 段階公開、並行稼働 |
実装パターン集：VB資産を最大活用する
パターン1：C#ラッパーでSDK/AIを呼ぶ
最新SDKやAI連携（例えばEmbeddingや推論クライアント等）がC#前提のとき、C#でFacadeを作り、VBからは単純なメソッド呼び出しに抽象化します。例：
// C# Facade（擬似例）
public interface IEmbeddingClient
{
float[] Embed(string text);
}
public sealed class EmbeddingClient : IEmbeddingClient
{
public float[] Embed(string text) => /* SDK呼び出し */;
}
// VB側から
' Dim client As IEmbeddingClient = New EmbeddingClient()
' Dim vec = client.Embed("vb to c#") パターン2：共通契約（DTO）で言語境界を薄くする
DTOはレコード/イミュータブルに寄せ、シリアライズ互換を担保。REST/メッセージング越しに将来の置換を容易にします。
パターン3：テストダブルで既存外部依存を固定
変換中は本番APIを叩かず、テストダブルで振る舞い固定。移行速度が上がり、バグ原因を限定できます。
セキュリティと運用：レガシーを安全に進化させる
- 署名と実行ポリシー：成果物の署名、SmartScreen/Defenderとの整合。
- シークレット管理：構成はUser Secrets/Key Vault等に分離。コードベースから排除。
- 監視・トレース：構造化ログと分散トレーシングで、VB/C#を跨いだ観測性を確保。
社内説得のための一枚資料（要点）
- 事実：.NETの新機能はC#中心に前進。VBは安定維持が基本方針。
- 価値：VB資産は依然有用。C#と併用すれば投資対効果が高い。
- 道筋：テスト先行→共通ライブラリ化→新規はC#→UI刷新の順で、12ヶ月で定常化。
チェックリスト：今日から着手できること
- ビルドをLTSに統一し、CIで定期ビルドとセキュリティスキャンを自動化。
- VBプロジェクトで最も変更頻度の高いクラスを10本選び、単体テストを追加。
- 新規要件の技術選定にC#（WebAPI/MAUI/Blazor）を標準化。
- 外部SDK呼び出しはC#ラッパー方針で統一。
- 3ヶ月のC#リスキリング計画を策定し、評価指標（テスト数・レビュー通過率）を定義。
まとめ：VBとC#は対立軸ではなく、役割分担で最大化する
VBがC#と同じ速度で進化しないのは、技術的劣位ではなく「投資配分」と「エコシステム規模」の帰結です。だからこそ、戦略は単純です。保守が主の既存資産はVBで安定運用し、新規機能・モバイル・クラウドはC#を第一選択にする。そして両者は共通ライブラリ化・API連携・C#ラッパーで橋渡しすれば良い。段階移行とハイブリッドを軸に、テストと自動化でリスクを制御すれば、無理のないコストで「いま必要な進化」を手に入れられます。
付録：FAQ（現場で実際に聞かれる質問）
Q. VBプロジェクトを最新の.NETで動かすべき？
A. はい。LTSを選び、依存NuGetを最新安定版へ。レガシーAPIやCOM依存は早期に代替策を検討。
Q. VBとC#が混在すると複雑にならない？
A. 境界（レイヤ）を明確にし、共通契約・例外・ログ規約を統一すれば、むしろ保守性が上がります。
Q. どの領域からC#化するのが効果的？
A. 変更頻度が高く、不具合が多いドメインロジック→外部連携→UIの順。テストの網羅度が高い領域は先行しやすい。
Q. 変換ツールは使うべき？
A. はい。ただし万能ではないので、テストで担保しつつ「変換→手修正→テスト」の小刻みサイクルを回してください。
Q. 採用市場はC#に偏っている？
A. はい。新規人材の参入経路、学習資料、OSSはC#が豊富。長期的にはC#経験者を中心にチーム設計するのが現実的です。
実務テンプレート：プロジェクト合意文案
// 目的：VB資産の価値を活かしつつ、モバイル・クラウド対応のC#基盤へ段階移行する
// 範囲：既存VBの保守継続、新規開発はC#、共有ライブラリで両言語を統合
// 成果物：テストスイート、CI/CD、C# WebAPI/MAUI、VB残存資産の安定運用手順
// 期間：12ヶ月（90日で基盤構築、以降段階リリース）
// KPI：テストカバレッジ＋20%、平均Lead Time -30%、障害復旧時間 -40%
最後に：意思決定の指針
- 短期の正解：VBは安定運用、C#は新機能。
- 中期の正解：ハイブリッドで共存し、変える価値の高い部分から置換。
- 長期の正解：人材ポートフォリオをC#中心に再編成し、継続的に選択肢を増やす。
「VBは終わり」ではありません。役割を見極め、正しく使えば、投資対効果が高く、チームの生産性と安全性を両立できます。重要なのは、「変えるべきところを見極めて、変え方を間違えない」ことです。
コメント