開発ローカル情報とは、インフラジスティックスが日々お客様と対話する中でよく耳にする、開発現場の小さな領域に限定したトピックを掘り下げて共有する特集です。
5月は、「アプリケーションのモダナイゼーション」について、よく聞くお悩みをまとめました。特に多いのが、デスクトップアプリからWebアプリへの移行に関するご相談です。
私たちがまずご提案しているのは、システム全体を一度に移行するのではなく、「まずUI（画面）をモダン技術でプロトタイピングし、移行可否とスコープを見極める」という段階的アプローチです。
モダナイゼーションの背景
よく聞くアプリケーションモダナイゼーションの背景は「サポート切れへの対応」が多いですが、リストアップするとこのようなケースがあります。
- OSやサーバの老朽化: 利用しているWindows Server 保終了、サーバ老朽化(10年サイクル)による再構築
- 開発環境の変化: .NET Core / .NET6 以降への対応や、 C# の バージョン互換性への対応、Visual Studioのテンプレート更新に伴う影響など。
- 利用環境の変化: 業務環境がオフィスだけでなくテレワークや外回りに対応するためにモバイル/タブレットでのシステムを利用できる環境も必要となった。
- 開発効率の向上/内製化: 開発工数/費用の削減のため、一部(バックエンド実装など)を内製化する。
現場から聞こえる検討課題
アプリケーションモダナイゼーションを検討されている方々から、"検討段階"ならではのリアルな課題もよくお聞きします。
「移行戦略」
モダナイゼーションプロジェクト自体はまだ正式には始まっていない。3年後のローンチを目指していて、いまは準備段階。
一気に全てを移行するのは現実的ではないので、当面は旧アプリケーションと新アプリケーションをハイブリッドで併存させようと考えている。段階的なリニューアルとなり、既存の業務フローを止めずに移行する必要がある。併存にあたって、どこから手をつければいいかまだ全容が見えていない。
「ツール環境とスキルギャップ」
これまで、Visual Studio でWindows Forms や WPF の開発をしてきた。ビジュアルベースでの開発に慣れているし、Webへのモダナイゼーションになると React/Angular/Blazor などレスポンシブ設計などを含めた知識が必要になってくる。開発だけでなくUI設計もしなければならないので、現在の開発チームのスキルでは手を出しにくく感じる。できればUI設計の部分は外注したいが、予算が足りない。
「どこで何が動かなくなるか」
Windows Formで使っていたUIコンポーネントもWebにはそのまま持っていけない。内部ロジックもイベントの仕組みも異なる。今までのコードが動かなくなるだけでなくて、意図した通りではに挙動が増える可能性があり、その範囲を検知しにくい。
課題は3つに分類できる
よくお聞きする懸念事項を分類すると、大きく3つに整理ができます。
- UIの専門知識: デスクトップからWebの移行をするにあたりUIは全面的に見直す必要があるが、専任者がいない
- 技術的課題: 従来の.NETやVisual Studioによる開発中心だった組織がWebシステム開発移行するにあたり、最新技術のキャッチアップが必要
- 組織・運用制約: すでに運用されている業務システムのモダナイゼーションは、ユーザー側との合意形成が必要
UIはモダナイゼーションの重要な起点
課題整理をする中で見えてくるのは、「アプリケーションモダナイゼーションとは、UIの再設計が重要な要素の1つである」ということです。特にデスクトップからWebのアプリケーションモダナイゼーションは、UIだけではなく、ViewModelやデータバインディングの構造自体が大きく異なるため、単純な変換やラッピングでは再現できません。
レイアウト設計は固定サイズ、ピクセルベースではなくレスポンシブ、フレックス設計が前提となりますし、操作対象はマウス・キーボードのみではなくマルチデバイスによるタッチ操作も加わります。
たとえば、まとめるとこのような違いがあります。
| 項目 | デスクトップ (WinForms/WPF) |
Web (React/Blazor 等) |
|---|---|---|
| UI描画 | OSの描画エンジンに依存（GDI等） | HTML/CSS/DOMベース |
| 状態管理 | アプリ内で全保持（常時接続想定） | ステートレス通信 + 状態管理の明示が必要 |
| イベント処理 | 同期処理が前提（Click → 即処理） | 非同期通信（API経由）や非同期描画が前提 |
| レイアウト設計 | 固定サイズ、ピクセルベースが中心 | レスポンシブ、フレックス設計が前提 |
| 操作対象 | マウス・キーボード前提 | マルチデバイス（スマホ/タブレット/タッチ）対応が求められる |
また、Web UIではUXの設計がUIと密接に結びつくため、状態管理（ステート管理）の設計もUIモックの時点で意識する必要があります。ReactのuseStateやBlazorのStateHasChangedのように、UI描画と状態の設計が分離されていないことも多いため、UIの粒度がそのままロジック設計に直結します。
UIをまず作ってしまうことで、機能設計や移行スコープも明確になりますが、逆に言えば「UIがある程度設計されていないと移行計画自体が立てにくい」とも言えます。
まず「画面」を作ってから検討しよう
とはいえ、スキルやコンポーネントもゼロから作るのはコストがかかりすぎる。そこで私たちがおすすめしているのが「画面先行のモダナイゼーション検討」です。
具体的な手順は下記の通りです。
- 主要パターンをピックアップして、まずはモックアップとして最低限必要な画面数を決める。(10-20がおすすめ)
- ビジュアル開発ツールを利用して、コードを書かずに「システムが動く状態」へ最速で到達する。(3ヶ月程度がおすすめ)
- 実際の画面を見ながら関係者間で合意形成・認識合わせをする。(開発チーム、ユーザー)
- 必要なデータ項目や操作フローを具体的に検討する。
- 検討をする上でAPI構造やデータストラクチャなどの技術要件を詰める。
画面先行で移行検討するメリット
アプリケーションモダナイゼーションは技術要件から画面の再設計まで考慮することが多く、全てを詳細に検討し続けてもプロジェクトが進捗しないこともしばしば。
まずは「どうしても再設計は必要となる」画面を先行開発することで、検討項目をより具体的に・的確にすることが可能です。
| メリット | 内容 |
|---|---|
| 🎯合意形成が早くなる | 実際の画面を見て話せるため、スプレッドシート等による画面設計書、仕様説明書よりも認識齟齬が減る。 |
| 💰コスト試算が現実的に | 作るべきもの・移すべきものが具体化される。 |
| 🔁 段階移行が可能 | UIから先に刷新し、裏の処理は後回しでも進められる |
| 👩💻 使いやすさ向上 | UI再設計の中で、ユーザビリティも同時に改善できる |
ポイント: 実際に動く「画面先行検討」が大事！
ビジュアル先行開発を効果的に進めるため、単なる画像やデザインツール上での「静的で・紙芝居」の検討ではなく「実際に"動く"実装レベルの」画面で検討・評価することが重要です。
「紙芝居」的な静的モックアップではこのような懸念があります。
- 画面ごとの機能や入力要素の把握が曖昧になり工数見積もりがズレやすい。
- 実際の入力やデータの流れを体験できず、UIの課題に気づきにくい。
- 開発側と利用側の認識齟齬が発生しやすい。
データバインディングや簡易なAPIレスポンスを含む「実装レベルの動的モックアップ」を最速で作り、モックアップをベースに検討や議論をすることで合意形成の内容がより具体的になりますし、動的モックアップを起点に移行計画やAPI設計にも反映させられます。
こうした「UI起点」のアプローチを採用することで、「開発リソースを浪費せず」「技術的手戻りも最小限に抑えた」アプリケーションモダナイゼーションを現実的に検討できるのです。
画面先行のモダナイゼーション検討に「App Builder」
デスクトップからWebアプリケーションへの移行計画を立てる際、画面先行で検討できるツールとしておすすめしたいのが「App Builder」です。Visual Studio のようなビジュアル先行の開発スタイルを活かしながら、UIやモダンWeb技術に関する詳細な知識を持たずとも「動的なモックアップをまず動かす」ことができます。
より詳しい「画面先行型モダナイゼーション」については続きの記事で説明しています。
📗「WPF/Windows FormからWebアプリへ！Visual Studioに慣れた C#開発者 へ最適なApp Builder！」
【続きの記事で解説していること】
- WPF/Winfows Formsのノウハウや体勢を活かしてWeb化を推進する方法
- App Builderを活用したWeb移行の実践イメージ
- WebアプリをVisual Studioで開発するプロセスの紹介
