C#のみで開発している SmartFプロダクトの今までと今後

2026/09/19のC# kaigi で登壇した際の資料になります

Transcript

1. C# Kaigi 2026 C#のみで開発している SmartFプロダクトの今までと今後 株式会社ネクスタ 畠山 圭佑 2026.09.19
2. 本日お話しすること 1. はじめに 2. あらまし 3. 今後の展望 4. 最後に P.2
3. 01 はじめに P.3
4. 自己と会社紹介 P.4
5. SmartFというプロダクトの紹介 P.5
6. SmartFというプロダクトの紹介 営業支援 システム (HubSpot) 工程管理システム 受発注 システム 在庫管理システム(奉行) 会計システム(freee) P.6
7. SmartFというプロダクトの紹介 営業支援 システム 生産管理 (HubSpot) 販売管理・SFAまで あらゆる業務領域 受発注 システム 工程管理システム 300+ 400社 機能を自由に 組み合わせて導入 規模も業種も バラバラ 在庫管理システム(奉行) ノンカスタマイズで導入 会計システム(freee) P.7
8. SmartFというプロダクトの紹介 営業支援 システム 生産管理 (HubSpot) 販売管理・SFAまで あらゆる業務領域 受発注 システム 工程管理システム 300+ 400社 機能を自由に 組み合わせて導入 規模も業種も バラバラ 在庫管理システム(奉行) ノンカスタマイズで導入 会計システム(freee) P.8
9. これをC#で作っています P.9
10. 02 あらまし P.10
11. 時系列 2023夏 2024.4 2024.8 2025.4 2026.9 QAとして入社 CTO室 組織づくりも 下期の組織計画 Windowsネイティ ブアプリからウェブ 化を決定 AIの台頭 今日 P.11
12. WinFormsは技術としては合っているが継続開発との相性が良くない 製造業との相性はよい（大量データの描画、レガシーな業界） 組織拡大における 課題 × 人を増やせない （WinForms人材） SQLを速くしても × APIのトラフィックが重い 増やすとバグが増える × （月120変更に対してバグ3件） × DB設計を 巻き直す余力がない 継続的な機能追加をしていくなら、サーバーレンダリングでのウェブ化 P.12
13. BlazorServerでのウェブ化に決めた理由 一定の成果はあるが、高みへの道のりは遠い 人を増やせない （WinForms人材） 新しい技術の宣伝により 母集団形成を実現 AIの台頭により 組織拡大の方向性が見直しに × 増やすとバグが増える （月120変更・バグ3件） 細かいリリースとE2E自動化の 仕組構築が可能 新機能開発と移行では効果が 出ず。今後に期待 × SQLを速くしても APIのトラフィックが重い ユーザ待機時間は改善 描画がネイティブに及ばず × DB設計を 巻き直す余力がない AWS上の高速インフラに閉じる ことで一定の収束 × 15秒 → 5秒前後 今後の改善に備えて リファクタリングは継続 P.13
14. 03 今後の展望 P.14
15. よりよりプロダクトにしていくための過程 2026.9 2027.3 2027.9 2028.1 2028.1 ~ 今時点 ウェブ版への 完全移行 .NET 10への 完全移行 データベースエンジ ンの刷新 AI駆動開発の 本格開始 P.15
16. 今時点 OSアップデートが困難 アプリケーション配布のみ WebAPI_4.8のデプロイは行わない アプリケーション配布用のデプロイとDBスキーマ適用は引き続き行 う EC2 instance contents アプリケーション配布 WebAPI_4.8 ALB ユーザ DB0~6サ ーバ API用のALBにBlazor用の EC2もぶら下げる WebAPI_4.8 → .NET 8 ALB Blazor.App Blazor.Appは今まで通り ◼ ◼ GitHub Pms  Win32NT  WebAPI_4.8  Blazor.App Nexta.SmartF  Blazor.App  Blazor.Api 冗長化を見据えたCDにしたい ビルドPC この単位で冗長化可能 バリデーション対応もこの単位で可能 開発者 P.16
17. 今時点 HTTPS(port:443) API公開用 ALB HTTP(port:80) WebAPI_4.8 (port:443/80) HTTP(port:80) HTTPS(port:443) アプリケーシ ョン用ALB HTTP(port:80) Blazor.App (port:80) localhost Blazor.Api (port:8080) HTTP(port:8080) API Gateway API公開用 ALB localhost WebAPI_4.8 (port:8081) P.17
18. 今時点 Winforms 共通ライブラリ IIS SmartF CSV自動出力 PMS.Lib.WebAccessor ↓ .NET Standard化 帳票自動出力 PMS.Lib Windows CE HT .NET Framework 4.8 WebAPI 切り出す ウェブアプリ Blazor Server PMS.Lib.App .NET 8 WebAPI P.18
19. 今時点 Winforms 共通ライブラリ IIS SmartF CSV自動出力 PMS.Lib.WebAccessor ↓ .NET Standard化 帳票自動出力 もっとプロダクト開発に多くの時間を使えるようにしたい PMS.Lib そのためには技術負債を解消し、 Windows CE .NET Framework 4.8 ビジネス拡大に追従していけるようなバックエンド構築が肝要 WebAPI HT 切り出す Blazor Webアプリ PMS.Lib.App .NET 8 WebAPI P.19
20. ウェブ版への完全移行 ウェブアプリ 共通ライブラリ Blazor Server PMS.Lib.WebAccessor ↓ .NET Standard化 MAUI Blazor Blazor WebAssembly IIS PMS.Lib .NET Framework 4.8 WebAPI 切り出す PMS.Lib.App .NET 8 WebAPI P.20
21. .NET 10 への完全移行 .NET Aspire でのコンテナデプロイ ウェブアプリ Blazor Server MAUI Blazor .NET 10 WebAPI Blazor WebAssembly P.21
22. データベースエンジンの刷新 400社、データの分布が本当に全部違う 品番が極端に多い 工程が深く入れ子 単純な構造を大量に データベースのスケーリング 医薬系バリデーション対応 ランニングコスト etc… P.22
23. データベースエンジンの刷新 現在はSQLServerを使っているが、よりよいプロダクトを目指して再評価をしている 評価観点 SQL Server TiDB ClickHouse AWS Aurora PostgreSQL コスト × 〇 ◎ 〇 性能（OLTP / 点更新・処理） ◎ 〇 × ◎ 性能（OLAP / 大規模集計） 〇 ◎ ◎ 〇 スケーラビリティ・可用性 〇 ◎ 〇 〇 DDL・一斉更新（ダウンタイム抑制） △ ◎ × 〇 カラムの頻繁な追加・多カラム対応 △ ◎ 〇 〇 AI活用 (Vector / RAG) 〇 〇 〇 ◎ P.23
24. AI駆動開発 人を増やす、ではなく、一人あたりの生産量を上げていく 壁① 壁② コンテキストサイズ 再現性 小さなスポット実装なら精度は出る。 プロダクト全体の規模になると情報が落ちる プロンプトの巧拙は、エンジニア個人が持つ コンテキストに依存して揺れる 打ち手：ソースコードと XML ドキュメントを常に一致させる 仕様変更 → ソース変更 → XML ドキュメント → テスト生成・検証 先輩たちが手でやってきたことを、AI にやらせる XML ドキュメントは C# の言語機能。型とコンパイラが、AI の出力を人のレビュー前に落とす P.24
25. 04 最後に P.25
26. 要件が分からないプロダクトを、考えながら作る その方法論に、C#は適切解だった ご清聴ありがとうございました P.26