突然の指示、突然のBlazor
エンジニア人生には、時々「え、明日からそれ使うの？」という急展開がある。今回、まさにそれが起きた。
私は普段、C#でWPFアプリケーションをゴリゴリ作ってきた。UIはXAMLで、バックエンドはMVVMで、非同期処理もTaskとCancellationTokenで丁寧に設計する。設計書もちゃんと書いて、レビューして、テスト仕様書まで仕上げる。そんなWPFエンジニア生活に慣れきっていた。
そんなある日の朝会。プロジェクトマネージャーが軽く言った。
「次の案件、フロントはBlazorでやるから、WPFメンバーも対応よろしく」
…え？ Blazor？
正直その時点で、私は「名前は聞いたことある」レベルだった。
「Web系？C#でフロント？」くらいのイメージ。
朝会が終わった瞬間、ググりまくった。
なぜBlazorを使うのか？（最初の疑問）
調べ始めると、どうやら会社の上層部はこう考えていたらしい。
- ■ WPFで作ってきたロジックをWebに再利用したい
→ WPFもBlazorもC#ベースなので、ビジネスロジック層のコードが流用できる。 - ■ クライアントPCへのインストール不要にしたい
→ 今までのWPFアプリは、PCごとにセットアップが必要だった。Blazorならブラウザがあれば動く。 - ■ 今後のクラウド展開に向けた布石
→ Azure上でホストすれば、世界中どこでも動く。営業的にも「Web対応してます！」と胸を張れる。
WPFエンジニアとしての最初の不安
だけど、正直怖かった。
「HTMLもCSSもほぼ書いたことない」「JavaScript？業務で触ったことゼロ」
そんな自分が、いきなりWebフロント開発？
しかも、UIの作り方も、イベントの捉え方も、通信の流れも、全部違いそう…。
特に心配だったのは次の３つ。
- UI設計：XAML脳で、HTML＆CSSが未知数
- デバッグ：WPFみたいにデバッガでサクッと止められるの？
- パフォーマンス：WebAssemblyとかBlazor Serverとか、何がどう違うの？
でも、希望もあった：C#資産が活かせる！
ただ、一つだけ希望が見えたのは「C#でフロントが作れる」という点。
これはWPFエンジニアにとってはかなりデカい。
XAMLのData Bindingとか、MVVMパターンの思想は、BlazorのComponent化と似ているところがあるっぽい。
そして、非同期処理もWPFで使ってきたasync/awaitがそのまま使える。
さらに、サービス層やロジック層のクラスがC#なら、少し手を入れればBlazor側でも使えるという話も。
勉強方法：何から手を付けるべきか？
とりあえず、最初にやったことはこれ。
- 【ステップ1】
Microsoft公式ドキュメントで「Blazor入門」を読む。
→ https://learn.microsoft.com/ja-jp/aspnet/core/blazor/ - 【ステップ2】
YouTubeで「Blazor 初心者向け ハンズオン」を探す。
→ 実際のUI作りながら学ぶ系の動画が一番入りやすかった。 - 【ステップ3】
GitHubでBlazorのサンプルプロジェクトをクローンして動かす。
→ 「Blazor WebAssembly」と「Blazor Server」の違いを体感。 - 【ステップ4】
既存のWPFアプリケーションのロジック部分だけ取り出して、Consoleアプリで動かしてみる。
→ 「どこまでWebで使いまわせるのか」をチェック。
会社導入の裏事情（聞いた噂）
実は今回のBlazor採用、どうやら営業サイドからの要望が強かったらしい。
「最近の顧客、Web化を強く求めてるよね」
「インストール型アプリは、セキュリティ審査が厳しくなってきてる」
「クラウド連携ができないと、他社に負けるかも」
こうしたプレッシャーの中で、WPFメンバーにも「Blazorを覚えてもらうしかない」という流れになった。
まさにトップダウンの決定。
だけど、これもエンジニア人生でよくある「会社都合で新技術キャッチアップするタイミング」だ
WPFエンジニアのBlazor実戦奮闘記 ～最初の壁と突破口～
Blazorの学習を始めて数日。チュートリアルアプリはなんとなく作れるようになった。
でも、実際の業務レベルで開発に入るとなった瞬間、想像以上の壁が立ちはだかった。
■ 壁①：UI設計の文化が違いすぎる！
まず最初にぶち当たったのが「UI設計」の考え方の違い。
WPFでは、XAMLでレイアウトを組んで、Grid や StackPanel でレイアウト調整して、DataBindingとCommandでイベント駆動するのが当たり前だった。
ところがBlazorになると、
HTMLタグベース。
レイアウトはdiv、section、article、Flexbox、Grid、しかもCSS必須。
イベントバインディングも、ボタンなら@onclickとか、完全に別世界。
さらにCSS！
WPF時代は、デザイナーさんが作ってくれるXAMLスタイルに頼ってきたので、自分ではCSSの知識ゼロ。
「marginとpaddingってどう違うの？」レベル。
社内でもWPFエンジニア勢が集まってSlackで叫びまくった。
「StackPanelどこ？！」
「DataTemplateってどうやるの？」
「MVVMは…どこ行った？」
■ 壁②：状態管理がわけわからん！
次にハマったのがState管理。
WPFでは、ViewModelのプロパティが変わったら、INotifyPropertyChangedでUIが自動更新される世界。
ところがBlazorでは、
「ページ間をまたいだ状態保持」
「非同期イベント後の再描画制御（StateHasChanged）」
「ScopedサービスでのDI管理」
…などなど、いきなり新しい概念が大量に出てくる。
特にハマったのはこの２つ：
- ページ間でのデータ共有
→ 「あれ？別ページに移動したら、データ消えたんだけど！？」 - 非同期イベント後のUI更新
→ 「awaitした後、UIが更新されない？なんで？？」
この辺りは本気でMicrosoftのドキュメントを読み込んだ。
特に助かったのは以下。
■ 壁③：HTTP通信が当たり前すぎる世界
WPF時代は、基本的にローカルDBやファイルIOで完結していた。
ところがBlazor開発では、APIとの通信が前提になる。
つまり、HttpClientでREST API呼び出しが日常。
JSONのパース、非同期通信、エラーハンドリング…全部Web標準。
最初の一週間、私はひたすらSwaggerと格闘していた。
「エンドポイントどこ？」
「POSTボディの型、これで合ってる？」
「CORSエラーって何？？？」
■ でも、少しずつ見えてきた希望の光
そんな感じで右往左往していたものの、数週間が経過する頃には、少しずつ光が見えてきた。
理由はこれ。
- ① C#で書ける安心感
→async/await、LINQ、Task、全部使える。 - ② WPF時代の設計思想が生きる
→ コンポーネント単位の分割は、まさにMVVMの「View」と「ViewModel」の分離に似てる。 - ③ サーバーサイドとの連携が簡単
→ ASP.NET Coreとの親和性がめちゃくちゃ高い。
そして何より、
「WPFエンジニアがBlazorに移行できれば、フルスタックへの道が開ける」
これが社内でも囁かれ始めた。
「これまでデスクトップしかできなかった人が、Webフロントもできるようになれば、キャリアの幅が広がるよね」
「フルスタックって言えるようになるじゃん」
そんな前向きな空気が少しずつ生まれてきた。
■ 実際にやってよかった学習法（この時期編）
この時期特に効果があった学習法はこれ：
- 【実プロジェクトでの小タスク担当】
→ 「簡単なページ作成」や「小さなAPI連携」から入る。 - 【ペアプログラミング】
→ Blazor経験者（少ないけど…）と組んで、一緒に画面作り。 - 【Microsoft Learn モジュール】
→ 無料の「Blazor WebAssembly Fundamentals」コースが神レベルでわかりやすかった。 - 【HTML/CSS基礎動画】
→ ドットインストールの「HTML/CSS入門」やYouTubeでのCSS Flexboxチュートリアル。
Blazorでつかんだ小さな成功体験と気づき ～「あ、できるかも！」と思えた瞬間～
Blazorの勉強と格闘の日々が続いた。
最初の頃は正直「これ、挫折するんじゃないか…」って何度も思った。
でも、あるタイミングから空気が変わり始めた。
それは、初めて「自分で作ったBlazor画面」が、ちゃんと動いたとき。
■ 初めての「成功体験」：検索フォームの作成
プロジェクト内で与えられた最初の実タスクは「検索画面」の作成だった。
要件はシンプル。
- テキストボックスにキーワード入力
- 「検索」ボタンを押す
- サーバー側APIにキーワードを投げる
- 結果をリスト表示する
WPFで言えば、TextBox、Button、ListViewの組み合わせ。
…が、Blazorでは全部違う。
最初はこんなことに悩んだ。
- HTMLでどうレイアウトするの？
- @code ブロックってどこまで何書いていいの？
- API呼び出しは HttpClient で合ってる？
- 画面更新タイミングはいつ？
でも、試行錯誤の末、完成した。
■ Blazorで作った初めてのコード断片（当時のメモより）
<input @bind="SearchKeyword" placeholder="キーワードを入力" />
<button @onclick="OnSearch">検索</button>
@if (Results != null)
{
<ul>
@foreach (var item in Results)
{
<li>@item.Name</li>
}
</ul>
}
@code {
private string SearchKeyword;
private List<SearchResultItem> Results;
private async Task OnSearch()
{
Results = await Http.GetFromJsonAsync<List<SearchResultItem>>($"api/search?keyword={SearchKeyword}");
}
}
動いた瞬間、めちゃくちゃ嬉しかった。
■ 「できた！」の先にあった気づき
この小さな成功体験をきっかけに、いろんな気づきが生まれてきた。
① WPFエンジニアの強みは「UIの状態管理力」
MVVMで磨いた「UIの状態とデータの関係をきちんと設計する力」は、Blazorでもそのまま活かせる。
特に「ユーザー操作に合わせて画面をどう切り替えるか」「バインド元データはどこに持つか」
…この辺りの考え方は、Blazorでも同じだった。
② 非同期処理の知識が超役立つ
WPFで非同期APIコールに慣れていたおかげで、async/awaitの使い方、エラーハンドリング、キャンセルトークンなどの扱いはすぐに応用できた。
③ フロントエンドの「設計力」が問われる世界
Blazorでは、コンポーネント単位の再利用性や状態管理の分離が求められる。
これってまさに「WPFのUserControl設計」や「ViewModel設計」とそっくり。
このあたりから、「自分が今までやってきたことは無駄じゃない」って思えるようになった。
■ 社内でのポジションも少し変わってきた
この時期から、社内の空気も変化してきた。
Blazor案件が増えるにつれ、WPFメンバーの中でも「先に習得した人」がミニリーダー的な存在になっていった。
自分も自然と、後輩や他メンバーから「Blazorでこれどうやるの？」って聞かれる側に。
SlackでのBlazor質問チャンネルにも、回答側で参加できるようになってきた。
正直、ちょっと嬉しかった。
「自分、成長してるかも…」
■ 「WPFエンジニアならでは」のBlazor学習法（この頃の実体験）
- 既存WPFアプリのロジックをBlazorに移植する小課題を作る
→ 例：「データグリッド表示機能」「検索条件バインド処理」など。 - BlazorのライフサイクルをWPFのLoadedイベントに置き換えて考える
→ 「OnInitializedAsync」→「Loaded」
→ 「OnParametersSetAsync」→「プロパティ変更後の反映」 - Razor構文を「XAML + C#コードビハインド」に置き換えて頭で理解
→ .razorファイル ＝ XAML + CodeBehind 的に考えるとすんなり入った。 - HTML / CSSは「レイアウトのXAML化」と割り切ってパターンで覚える
→ FlexboxとかGridレイアウトは、WPFのGridとStackPanelをイメージして慣れていった。
■ 少しずつ見えてきた「Blazorの楽しさ」
そして、なによりも大きかったのは…
「自分の書いたUIが、インストールなしで、ブラウザ上でサクッと動く」という感動。
社内の別チームにURL渡すだけで、
「え、これ、動いてるじゃん！」
「もうインストール不要？」
「なんか未来感あるね！」
そんな声がもらえた。
これまで、.exeファイル渡して、
「.NETランタイム入ってますか？」
「バージョン違いで動きません」
とかやってた日々が、少しずつ変わっていった。
WPFエンジニアがBlazorに挑戦して得たもの、そしてこれから
数ヶ月前、突然降ってわいた「Blazorやって！」指令。
最初は不安と混乱だらけだった。
けど、今振り返ると、それは自分にとって**「キャリアの転機」**だった。
■ 会社全体としてのBlazor導入のメリットが見えてきた
プロジェクトが進むにつれ、社内でもBlazorの導入効果が目に見えて出てきた。
【メリット①：開発コストの削減】
従来のWPFアプリ開発では、
- UI開発はXAML担当
- ロジック開発はC#担当
- 配布作業はインフラチーム
- バージョン管理、インストーラ作成、ユーザーごとのPCセットアップ…
など、各工程でコストがかかっていた。
Blazorに切り替えたことで、
- クライアント側はブラウザのみ
- デプロイはサーバー上の1箇所だけ
- ユーザーごとのPCセットアップ作業ゼロ
- バージョンアップはサーバー側で即反映
これだけで、年間数百万円規模のコスト削減が見えてきた。
【メリット②：ビジネススピードの加速】
営業サイドからはこんな声が出るように。
「今まで提案できなかったお客様にも、Webベースってだけで商談が通りやすくなった」
「テレワークユーザーでもすぐ使ってもらえる」
「新しいSaaS型サービスとして売り出せる」
クラウド展開も視野に入ることで、会社全体のビジネスモデルが「プロダクト提供型」から「サービス提供型」へと進化しつつある。
これって、まさにBlazor導入がきっかけだった。
【メリット③：技術者のスキル拡張】
WPFチームのメンバーも、一人また一人とBlazorに対応できるようになり、
- 「フロントエンドもできます！」
- 「APIとの通信もOK！」
- 「クラウド側の設定もわかります！」
という、フルスタック寄りな技術者が社内で育ってきた。
■ 自分自身のキャリアに起きた変化
このBlazor案件を通じて、自分にも確実な変化があった。
【変化①：フロントエンド開発への苦手意識が消えた】
「HTMLとかCSSとか…わけわからん」
そんな感覚が、今はもうない。
もちろんまだプロのWebデザイナーには敵わないけど、自分で簡単なUIならサクッと作れるようになった。
「必要に応じて学べばいい」というマインドに変わった。
【変化②：クラウドサービスへの関心が高まった】
Blazorを使うことで、自然とAzureやAWS、API Gateway、Web API設計などの知識もついてきた。
「次はAzure Functionsとか勉強してみたいな」
「SignalR使ってリアルタイム通知とかやってみたい」
そんなふうに、技術への好奇心が広がっていった。
【変化③：コミュニケーションの幅が広がった】
フロントエンド、バックエンド、インフラ、営業サイド…
色んな部署の人たちと、**「同じ言葉で会話できるようになった」**のも大きな収穫だった。
特に営業チームやPMとの会話で、
「これ、Webなら即対応できますよ」
「次回リリースでバグ修正すぐ反映できます」
こんな風に提案できるようになったのは、エンジニアとして大きな武器になった。
■ 今後伸ばしていきたいスキル
Blazor案件を経験した今、次に自分が伸ばしたいと思っているのは次の3つ。
- 本格的なHTML / CSS / JavaScriptスキル
→ Blazorだけではどうしてもカバーしきれない細かいUI調整や、JS interopの部分で苦戦する場面がある。 - Web API設計力
→ フロントエンドとバックエンドのつなぎ目設計は、エンジニアとしてこれから必須スキル。 - クラウドサービス（Azure/AWS）の基礎知識
→ 今後の案件ではクラウドホスティングが当たり前になるため、デプロイ、ストレージ、セキュリティあたりを抑えたい。
■ 最後に：これからBlazorに挑戦するWPFエンジニアへ
もし今この記事を読んでいて、
- 「WPFしかやってこなかったけど、大丈夫かな…」
- 「Web開発、未経験なんだけど…」
- 「Blazorって難しそう…」
そんな不安がある人がいたら、声を大にして言いたい。
「大丈夫。WPFでやってきたことは、必ずBlazorで活きる！」
確かに最初はつまずく。HTMLやCSSに混乱する。状態管理で頭を抱える。
だけど、一つ一つ乗り越えれば、きっとWebフロント開発も楽しくなる。
むしろ、これからの時代、
「デスクトップもWebも両方できるエンジニア」
はめちゃくちゃ市場価値が高い。
自分もまだまだ学びの途中だけど、Blazorを通じて一つ確信したことがある。
「変化を恐れず、技術に貪欲でいることが、エンジニア人生を面白くする。」
そんな気持ちで、次の案件も楽しみながら取り組んでいこうと思う。
コメント