スマートＦ開発における現状の課題と、今後の計画～WinFormsからBlazorへ～

はじめに

はじめまして。ネクスタの畠山です。
ネクスタは「スマートF」という生産管理SaaSの開発・販売を行っています。
私はスマートＦの開発にCTO室として関わっています。

CTO室のミッションの中に”中長期的な課題解決のコンセプト作り”があり、その中の課題のひとつにエンジニア採用があります。

外のエンジニアから見て「ネクスタってどんな会社なのか？」「生産管理SaaSって具体的に何なのか？」「内部の技術的な話」あたりが分かりやすくなるように本ブログを通して情報発信していきたいと思っております。よろしくお願いします。

今回は、目下、弊社で推進しているWinFormsからBlazorへの移行にあたっての背景や解決したい課題について発信させていただきます。

WinFormsを採用した背景

ネクスタは当初、受託開発の会社として、何百という製造業のシステム開発をおこなってきました。
そんな中あるとき、代表の永原が製造業全体を変えるべく、あらゆる会社の生産管理をワンパッケージで網羅するSaaSモデルへの転換を決断し、大きく戦略が変わりました。

当初は秩序らしい秩序もない、いわゆる「カウボーイプログラミング」でした。
「とにかく早く作る」
「納得いかない品質でもまずは世に出してみる」
みたいな意思決定でした。

開発言語やデータベースエンジンも「その時いたエンジニアが得意なスキルセット」で作った結果「WinForms」「ASP.NET」「SQLServer」「AWS EC2」という全体構成になりました。

WinFormsへの率直な感想

私個人が入社したのは2023年の7月なのですが、入社した当社はこの全体構成でもアリ だと思っていました。

私が過去に携わった製鉄所リフレッシュプロジェクトでも「大量データ」「操作性」においてはHTML5での実現リスクがあったので必要に応じてC#のWinFormsを使う方針でしたし、歴史のある工場系の基幹システムはCから始まりC++からC#、という流れが割と多いです。スマートFも工場に導入するシステムなのでWinFormsが全く向いていないとは思いませんでした。

エンジニア採用の観点からも「生産管理システムや在庫管理システムをC系統の言語でやってきた人」というペルソナはスマートFとの相性が良いと考えました。実際に採用をやってみて、C系統の言語で工場系のシステムをやっていた人は一定数いたのでこの仮説は当たっていたと思います。

WinFormsの課題

この仮説のもと、プロダクト推進や採用活動を行ってきた中で大きく2つのリスクが顕在化してきました。それは

1. スプリント開発との相性

2. 開発エンジニアのやる気

です。

スプリント開発との相性

ネクスタの開発チームはアジャイル開発をしていてスプリントを週1で設けています。
ここ1年でチーム人数が3倍増えたこともあってか、週1の機能リリース時に追加される機能が増えました。これ自体は喜ばしいことなのですが、反面、リリースに不具合が紛れることも増えました。

じゃあリリース頻度を増やして小出しにすればいいのでは、と思う矢先、WinFormsのようなネイティブアプリは「アプリケーションの配布」が課題になります。要は、機能追加をする度に再インストールしないといけないわけで「リリースを小出しにする＝クライアントの再インストールの手間が増える」となります。

スマートFは今後も積極的に機能追加をしていく方針なので、早いタイミングで配布コストのかからないウェブ化に舵切りするべきと考えました。

開発エンジニアのやる気

WinFormsからウェブ化への舵切りを検討していた最中、社内のエンジニアに「WinFormsでの開発を続けたいか」とアンケートをしてみました。

結果、7割近くがネガティブな回答でした。「廃れゆく技術だから」という理由が一番多かったです。将来のエンジニア組織を考えた際に、WinFormsでの開発を継続することはエンゲージメントの観点でも良くないと考えました。

移行先をBlazorに決めた理由

上記のようにWinFormsからの移行は決定したものの、ウェブへの移行先はReactやVueといった、採用実績もエンジニア母数も多いアーキテクチャを選べばよいのでは、という話もあがりました。
その上でなぜ Blazor を選んだのか、というと大きく2つの理由があります。

1. チーム設計コンセプト

2. 技術的な課題へのアプローチ

チーム設計コンセプト

スマートF開発チームは「フロントエンド」「バックエンド」と開発対象でチームを分けるのではなく「在庫」や「生産」「出荷」といった機能単位でチームを分けています。

クライアントのビジネスロジックが複雑なので、チームごとに専門性を持たせて設計しつつ開発する、というチーム設計です。ここに「フロントエンド」「バックエンド」というレイヤーまで入れてしまうとチーム規模に対してエンジニアに求めるスキルセットが多くなってしまいます。

また、Blazorならハンディターミナルでの「モビリティ」にもMAUIでクロスプラットフォーム対応できるので今のWindowsCEでの開発スキルセットをそのまま活かせる点もメリットです。

技術的な課題へのアプローチ

個人的にはこれが一番の課題であり、現在進行形で悩みながらも推進しているところです。
それはSmartFの特性である「データ量が多い」ということです。

これはもしかすると生産管理システム全般の特性なのかもしれません。過去に私が携わった製鉄所リフレッシュの性能要件でも「大量データ」というシステム特性がありました。
スマートFは工場への導入が多く、工場のインターネット回線速度は、正直なところあまり早くないことが多いです。弊社でのデモ時にはスムーズに動いていても、実際にクライアント構内で動かすと応答性が芳しくないということがたびたび起こっています。

インターネット回線速度が保証されていない状況下でいかに性能を発揮できるか、というのがスマートFの大きな課題の１つだと捉えています。今のプロダクトの状況下で一番噛み合うアーキテクチャを考えた結果 SignalR での Blazor Server でやってみようと考えました。

もし、WinFormsからReactに移行したとすると、Reactもデータ取得がAPI経由になるため同様の課題が生じます。一方Blazor Server ならサーバサイドレンダリングなのでインターネットを介しての通信量は少なくて済むのではないか、という仮説です。
SignalRでの接続管理はデメリットもありますが、B to Bビジネスなのでユーザ数やスパイクを予測しやすい点も相性がよいと考えています。

とはいえ、画面に大量にデータを表示する設計にしてしまったら台無しなので、そこはちょうどいい塩梅を模索していければと考えています。Blazorでコンポーネント化しておけば、未来にWebAssemblyに移行する選択肢が取れるという点もリスクテイクになると考えています。

さいごに

初回ということで、ざっくばらんに弊社で進めているWinFormsからBlazorへの移行の話をさせていただきました。
今回のようなプロダクトの意思決定の話や、また、時には皆さまの役に立つような開発知識なども交えて発信していけたらと思いますのでよろしくお願いします。

---

執筆者プロフィール
株式会社ネクスタ　CTO室　室長
畠山圭佑
新卒で入社した独立系の中小受託開発会社で、C# エンジニアとしてのキャリアをスタート。船舶や製鉄、金融系などの大規模システム開発プロジェクトでPLを数多く務める。その後、パーソルキャリア株式会社のダイレクトリクルーティング刷新プロジェクトのサブリーダーを務め、ネクスタへジョイン。