.NETを習得するための実践プロジェクト15選｜初心者から上級者まで

.NETを本当に習得するには、C#の文法やASP.NET Coreの基本を読むだけでは不十分です。.NETは、Webアプリケーション、Web API、認証、データベース、Blazorによるフロントエンド、.NET MAUIによるモバイルアプリ、クラウド連携、マイクロサービスまで含む広いエコシステムです。そのため、効率よく学ぶには、実際に手を動かして段階的にプロジェクトを作ることが重要です。

本記事では、初心者から上級者まで取り組める.NET実践プロジェクトを15個紹介します。最初はTo-Doリストや社員管理システムのようなCRUD中心のアプリから始め、次に認証、ECサイト、在庫管理、CMS、リアルタイム通信、モバイルアプリ、LMS、マイクロサービス、SaaS、ERPミニシステムへ進む構成です。これらを順番に作ることで、単なる知識ではなく、実務で使える.NETスキルを身につけられます。

1. タスク管理アプリ（To-Do List）

タスク管理アプリは、.NET初心者が最初に作るべき実践プロジェクトです。機能はシンプルですが、ASP.NET Coreの基本構造、Entity Framework Coreによるデータ操作、フォーム入力、一覧表示、編集、削除、検索、ページネーションなど、Webアプリ開発の基礎を一通り学べます。

このプロジェクトの目的は、単にタスクを追加・削除できる画面を作ることではありません。Controller、Service、Repository、Model、DTOなどをどのように分けるかを意識しながら作ることで、後の大規模プロジェクトにも応用できる設計力が身につきます。

1.1 ASP.NET Coreによる基本CRUD

CRUDとは、Create、Read、Update、Deleteの略で、ほぼすべての業務アプリに存在する基本操作です。To-Doリストでは、タスクの作成、一覧表示、詳細表示、編集、削除、完了状態の更新などを実装します。これにより、ASP.NET Coreにおけるリクエスト処理、ルーティング、モデルバインディング、レスポンス返却の流れを理解できます。

実装時には、すべての処理をControllerに直接書かないことが重要です。最初は小さなアプリでも、Controllerにロジックを詰め込むとすぐに読みにくくなります。Service層を作り、Controllerは入力を受け取り、Serviceに処理を委譲する構成にすると、実務に近い形で学習できます。

1.2 Entity Framework Core

Entity Framework Coreは、.NETでよく使われるORMです。SQLを直接書かなくても、C#のクラスを通じてデータベースを操作できます。To-Doリストでは、TaskItemというEntityを作成し、Id、Title、Description、DueDate、IsCompleted、CreatedAtなどのプロパティを持たせるとよいでしょう。

EF Coreを使う際は、DbContext、DbSet、Migration、LINQ、SaveChangesの役割を理解することが重要です。To-Doリストのような小さなプロジェクトでも、migrationを作成し、データベースを更新し、初期データを投入する流れを練習しておくと、社員管理やECサイトのような複雑なシステムに進みやすくなります。

1.3 データバリデーション

データバリデーションは、ユーザーが入力した値を検証する処理です。To-Doリストでは、タイトルが空でないか、文字数が長すぎないか、期限日が不正でないか、完了状態が正しく送信されているかなどを確認します。入力チェックを行わないと、データベースに不正な値が保存され、後から不具合の原因になります。

ASP.NET Coreでは、Data Annotationsを使ってRequired、StringLength、MaxLengthなどのルールを簡単に定義できます。より複雑な条件が必要な場合は、カスタムバリデーションやFluentValidationを使う方法もあります。クライアント側のバリデーションはUX向上に役立ちますが、最終的な検証は必ずサーバー側で行うべきです。

1.4 Repository Pattern

Repository Patternは、データアクセス処理を分離するための設計パターンです。ControllerやServiceが直接DbContextを扱うのではなく、TaskRepositoryのようなクラスを通してデータ取得、追加、更新、削除を行います。これにより、データアクセスの責務が明確になります。

小さなTo-Doアプリでは少し大げさに感じるかもしれませんが、実務ではデータアクセスの分離が保守性に直結します。Repositoryを使うことで、テスト時にデータアクセスをモック化しやすくなり、将来的にデータベースやクエリの実装を変更する際も影響範囲を小さくできます。

1.5 Paginationと検索

Paginationは、一覧データを複数ページに分けて表示する仕組みです。タスクが数件しかない場合は不要に見えますが、実務では数百件、数千件のデータを扱うことが多いため、早い段階で学んでおく価値があります。pageNumber、pageSize、totalCountを使ってページ制御を実装するとよいでしょう。

検索機能では、タイトル、説明文、完了状態、期限日などでタスクを絞り込めるようにします。検索とPaginationを組み合わせることで、LINQによる動的クエリの作り方を学べます。このスキルは、商品一覧、社員一覧、注文一覧など、ほぼすべての業務システムで使います。

1.6 実運用を想定したデプロイ

プロジェクトはローカルで動くだけでは不十分です。Azure App Service、VPS、Docker、Render、Railwayなどにデプロイして、実際にアクセスできる状態にすることで、環境変数、connection string、production設定、ログ、migration実行などを学べます。

ポートフォリオとして公開する場合は、READMEも重要です。セットアップ手順、使用技術、機能一覧、スクリーンショット、デモURL、今後の改善点を整理しておくと、採用担当者や他の開発者に伝わりやすくなります。小さなTo-Doアプリでも、完成度を高めれば十分に学習価値があります。

2. 社員管理システム

社員管理システムは、To-Doリストより一段階実務に近い.NETプロジェクトです。社員、部署、役職、ユーザー、権限、勤怠、レポートなど、複数のデータが関係するため、データベース設計と業務ロジックの学習に適しています。

このプロジェクトでは、単なるCRUDだけでなく、部署ごとの社員管理、権限による操作制限、管理者向けDashboard、データ集計などを実装できます。企業向けアプリケーションに近い構成を学べるため、ポートフォリオとしても価値があります。

2.1 データベース設計

社員管理システムでは、最初にデータベース設計をしっかり行う必要があります。Employees、Departments、Positions、Users、Roles、Attendance、Salaryなどのテーブルを考え、それぞれの関係を整理します。たとえば、1つの部署には複数の社員が所属し、社員は1つの役職を持つ、といった関係です。

設計前にER図を作ると、データ構造が明確になります。ER図を描かずに実装を始めると、後から外部キーや関係性を修正することになりやすいです。業務アプリではデータベース設計がアプリ全体の品質を左右するため、早い段階で練習しておくべきです。

2.2 部署管理

部署管理では、部署の作成、編集、削除、一覧表示、所属社員数の表示などを実装します。単純なマスターデータ管理に見えますが、社員との関連があるため、削除処理には注意が必要です。社員が所属している部署をそのまま削除すると、データ整合性が崩れる可能性があります。

実務では、部署を物理削除するのではなく、無効化する設計がよく使われます。たとえば、IsActiveやDeletedAtを持たせて、過去のデータは保持しながら新規利用だけを停止する方法です。これにより、社員の履歴や過去のレポートを壊さずに運用できます。

2.3 社員プロフィール管理

社員プロフィール管理では、氏名、メールアドレス、電話番号、住所、入社日、部署、役職、雇用形態、ステータスなどを管理します。詳細画面では、社員の基本情報に加えて、所属履歴や更新履歴を表示できると実務的です。

社員情報は個人情報を含むため、誰でも閲覧・編集できる設計にしてはいけません。管理者、人事担当者、部署マネージャー、一般社員など、役割ごとにアクセスできる範囲を制御する必要があります。この点で、認可設計の練習にもなります。

2.4 ユーザー権限管理

ユーザー権限管理では、Role-based Authorizationを実装します。Adminは全機能を操作でき、HRは社員情報を編集でき、Managerは自部署の社員だけ閲覧でき、Employeeは自分の情報だけ見られる、といった設計が考えられます。

重要なのは、UIでボタンを非表示にするだけでは不十分という点です。ユーザーが直接APIを呼び出す可能性があるため、サーバー側でも必ず権限チェックを行います。ASP.NET CoreのAuthorize属性やPolicy-based Authorizationを使うと、実務に近い権限管理を学べます。

2.5 データレポート

社員管理システムでは、部署別社員数、入社月別人数、退職率、役職別構成、契約更新予定などのレポートを作成できます。これにより、LINQによる集計、グルーピング、フィルタリング、期間指定の処理を学べます。

レポート機能は、単にデータを表示するだけでなく、意思決定を助けるための機能です。管理者が一目で状況を理解できるように、表、グラフ、KPIカードを組み合わせるとよいでしょう。ExcelやPDFへのエクスポートを追加すると、さらに実務的なプロジェクトになります。

2.6 管理Dashboard

管理Dashboardでは、社員数、部署数、新入社員数、退職予定、契約更新アラートなどをまとめて表示します。Dashboardは、システム全体の状態を一目で把握するための画面です。

Dashboardを作ることで、APIの集計処理、キャッシュ、グラフ表示、レスポンス最適化を学べます。Blazorと組み合わせれば、C#でインタラクティブな管理画面を構築する練習にもなります。

3. 商品管理API

商品管理APIは、.NETバックエンド開発を学ぶうえで非常に重要なプロジェクトです。画面よりもAPI設計に集中できるため、RESTful API、DTO、Validation、Error handling、Swagger、Versioning、Loggingなどを体系的に学べます。

このプロジェクトは、後でECサイト、在庫管理、モバイルアプリ、Blazor frontendと連携できます。つまり、単独の練習だけでなく、他のプロジェクトの基盤として再利用できる点でも価値があります。

3.1 RESTful APIの構築

RESTful APIでは、商品というリソースに対してGET、POST、PUT、DELETEなどのHTTPメソッドを使います。たとえば、商品一覧取得、商品詳細取得、商品作成、商品更新、商品削除といったエンドポイントを設計します。

実装時には、HTTP status codeを正しく使うことが重要です。作成成功なら201 Created、存在しない商品なら404 Not Found、入力エラーなら400 Bad Request、認証エラーなら401 Unauthorizedを返すようにします。こうした基本を守ることで、使いやすいAPIになります。

3.2 Swagger/OpenAPI

Swagger/OpenAPIは、API仕様を自動生成し、ブラウザ上で確認・テストできる仕組みです。ASP.NET CoreではSwashbuckleなどを使うことで、簡単にSwagger UIを追加できます。

Swaggerを導入すると、フロントエンド開発者やQA担当者がAPIの仕様を理解しやすくなります。request body、response schema、status code、認証の有無を明確に記述すれば、実務レベルのAPIドキュメントになります。

3.3 高度なCRUD

高度なCRUDでは、単純な追加・更新・削除に加えて、検索、フィルタ、ソート、ページネーション、画像URL管理、在庫状態、公開/非公開ステータスなどを扱います。商品APIでは、名前、カテゴリ、価格帯、ブランド、在庫数で絞り込めるようにすると実用性が高まります。

また、EntityをそのままAPIのrequest/responseに使うのは避けるべきです。CreateProductRequest、UpdateProductRequest、ProductResponseのようにDTOを分けることで、入力値を制御しやすくなり、不要なフィールドを外部に公開せずに済みます。

3.4 API Versioning

API Versioningは、既存のクライアントを壊さずにAPIを進化させるための仕組みです。たとえば、v1では基本情報だけを返し、v2ではカテゴリ名やブランド情報を追加する、といった変更ができます。

バージョン管理を導入しないと、API変更のたびに既存のフロントエンドやモバイルアプリが壊れる可能性があります。学習プロジェクトでも、/api/v1/productsのようにURLでバージョンを管理すると、実務に近い設計を練習できます。

3.5 Error handling

Error handlingでは、例外や入力エラーを統一された形式で返すことが重要です。エラーごとにresponse形式がバラバラだと、フロントエンド側で処理しづらくなります。message、errorCode、details、traceIdを含む共通形式を作るとよいでしょう。

ASP.NET Coreでは、middlewareを使ってグローバル例外処理を実装できます。予期しないエラーが発生した場合でも、内部例外をそのまま返さず、ログに記録し、ユーザーには安全なエラーメッセージを返す設計が必要です。

3.6 LoggingとMonitoring

Loggingは、APIがどのように使われ、どこで問題が起きたかを把握するために必要です。商品作成、更新、削除、例外発生、処理時間の長いリクエストなどをログに残すと、運用時の調査がしやすくなります。

Monitoringでは、リクエスト数、エラー率、レスポンスタイム、データベース負荷などを追跡します。学習段階では簡易的なログでも十分ですが、将来的にはApplication Insights、OpenTelemetry、Prometheusなどの監視ツールを学ぶと実務に近づきます。

4. ユーザー認証システム

ユーザー認証システムは、実務の.NET開発で非常に重要なテーマです。ほぼすべてのWebアプリやAPIでは、ログイン、登録、権限管理、トークン管理、パスワードリセットなどが必要になります。

このプロジェクトでは、ASP.NET Identity、JWT Authentication、Role-based Authorization、Refresh Token、Social Login、Security Best Practicesを学びます。セキュリティに関わるため、単に動けばよいのではなく、安全な設計を意識することが重要です。

4.1 ASP.NET Identity

ASP.NET Identityは、ASP.NET Coreでユーザー管理を行うための標準的な仕組みです。ユーザー登録、ログイン、パスワードハッシュ、ロール管理、メール確認、パスワードリセットなど、多くの機能を提供します。

Identityを学ぶことで、ユーザー情報をどのように保存し、どのように認証状態を管理するかを理解できます。UserManager、SignInManager、RoleManagerの役割を理解すると、認証機能を安全に拡張しやすくなります。

4.2 JWT Authentication

JWT Authenticationは、Web APIやSPA、モバイルアプリでよく使われる認証方式です。ユーザーがログインすると、サーバーはaccess tokenを発行し、クライアントはAPI呼び出し時にAuthorization headerへtokenを付けて送信します。

JWTを実装する際は、署名キー、有効期限、issuer、audience、tokenの保存方法を理解する必要があります。access tokenの有効期限を短くし、refresh tokenと組み合わせることで、セキュリティと利便性のバランスを取れます。

4.3 Role-based Authorization

Role-based Authorizationは、ユーザーの役割に応じてアクセスできる機能を制限する仕組みです。Admin、Manager、Userなどのロールを定義し、管理画面やAPIにアクセス制御を設定します。

重要なのは、画面側だけでなくサーバー側でも権限を検証することです。ボタンを非表示にするだけでは不十分で、API側でAuthorize属性やPolicyを使って保護する必要があります。

4.4 Refresh Token

Refresh Tokenは、access tokenの期限が切れたときに新しいaccess tokenを発行するために使います。access tokenを長期間有効にすると漏洩時のリスクが高いため、短命のaccess tokenと長めのrefresh tokenを組み合わせる設計が一般的です。

Refresh Tokenを実装する場合は、データベースに保存し、有効期限、失効状態、発行元デバイスなどを管理します。ログアウト時や不正利用が疑われる場合には、refresh tokenを無効化できるようにしておく必要があります。

4.5 Social Login

Social Loginは、Google、Microsoft、GitHub、Facebookなどの外部アカウントでログインできる機能です。ユーザーは新しくパスワードを作らずに登録できるため、UXが向上します。

実装時には、外部プロバイダーから取得したメールアドレスを既存ユーザーと紐づける処理が必要です。また、外部ログインに成功したからといって、アプリ内での権限を自動的に信頼しすぎないようにする必要があります。

4.6 Security Best Practices

Security Best Practicesでは、HTTPSの利用、パスワードハッシュ、入力値検証、CORS設定、token保護、ログイン試行回数制限、機密情報の非表示などを実装します。認証システムは攻撃対象になりやすいため、慎重な設計が必要です。

また、エラーメッセージにも注意が必要です。「このメールアドレスは存在しません」と具体的に返すと、ユーザー列挙攻撃に使われる可能性があります。実務では、セキュリティとユーザー体験のバランスを考える必要があります。

5. ECサイト

ECサイトは、.NETで実践力を伸ばすための代表的なプロジェクトです。商品一覧、カテゴリ、カート、注文、支払い、在庫、クーポン、ユーザー管理など、多くの実務的な機能を含みます。

このプロジェクトを通じて、単純なCRUDを超えた業務ロジックを学べます。価格計算、在庫チェック、注文状態、支払い状態、キャンセル処理など、実際のシステムに近い問題を扱うため、ポートフォリオとしても強力です。

5.1 商品カテゴリ

商品カテゴリは、ECサイトの商品を整理するための基本機能です。Category、SubCategory、Brand、ProductなどのEntityを設計し、ユーザーが商品を探しやすい構造を作ります。

カテゴリ設計では、階層構造を持たせるかどうかを考える必要があります。小規模ECなら1階層でも十分ですが、大規模になると親カテゴリと子カテゴリを持つ構造が必要になります。

5.2 カート

カート機能では、ユーザーが購入予定の商品を一時的に保存します。ログイン前のユーザーにはsessionやlocal storageを使い、ログイン後のユーザーにはデータベースに保存する設計が考えられます。

カートでは、数量変更、商品削除、合計金額計算、在庫確認が必要です。特に、カートに入れた時点の在庫と購入時点の在庫が変わる可能性があるため、注文確定前に必ず再チェックする必要があります。

5.3 支払い

支払い機能では、Stripe、PayPal、または模擬決済システムを使って決済フローを学べます。重要なのは、支払いボタンを作ることではなく、支払い状態を正しく管理することです。

注文は、未払い、支払い済み、失敗、キャンセル、返金などの状態を持つべきです。支払い結果はclientからの通知だけでなく、サーバー側でWebhookや決済プロバイダーの確認を通じて検証する必要があります。

5.4 注文管理

注文管理では、注文作成、注文詳細、注文状態更新、キャンセル、配送状態管理などを実装します。Order、OrderItem、Payment、ShippingAddress、OrderStatusHistoryなどのテーブルが必要になります。

注文状態は明確に定義することが重要です。たとえば、Pending、Paid、Processing、Shipping、Completed、Canceledなどの状態を持たせ、無効な状態遷移を防ぐことで、業務ロジックの整合性を保てます。

5.5 クーポン・プロモーション

クーポンやプロモーションは、ECサイトをより実務的にする機能です。割引率、固定金額割引、送料無料、利用期限、最低購入金額、利用回数制限などを設定できます。

この機能では、条件判定のロジックが複雑になりやすいです。そのため、割引計算はServiceに分離し、unit testを書くとよいでしょう。価格に関わる処理はバグの影響が大きいため、慎重に実装する必要があります。

5.6 パフォーマンス最適化

ECサイトでは、商品一覧や検索結果の表示速度が重要です。ページ読み込みが遅いと、ユーザーが離脱する可能性があります。Pagination、index、caching、画像最適化、不要なデータ取得の削減が必要です。

バックエンドでは、N+1問題、JOINの最適化、SQL実行計画、キャッシュ戦略を確認します。特に商品一覧では、詳細情報をすべて返すのではなく、一覧表示に必要な最小限のデータだけを返す設計が効果的です。

6. 在庫管理システム

在庫管理システムは、業務アプリ開発の学習に非常に適したプロジェクトです。入庫、出庫、在庫数、倉庫、商品、在庫アラート、履歴管理などを扱うため、データ整合性とトランザクションの重要性を学べます。

このプロジェクトでは、単なるCRUDではなく、数値の変動と履歴を正しく管理する必要があります。在庫数が間違うと業務に大きな影響が出るため、実務に近い緊張感で設計できます。

6.1 入出庫管理

入出庫管理では、商品が倉庫に入る処理と、倉庫から出る処理を記録します。入庫すると在庫数が増え、出庫すると在庫数が減ります。これらの操作は必ず履歴として保存するべきです。

単にProductテーブルのQuantityを更新するだけでは、後から原因を追跡できません。StockTransactionやInventoryMovementのようなテーブルを作り、いつ、誰が、どの商品を、何個動かしたかを記録する設計が実務的です。

6.2 在庫追跡

在庫追跡では、現在の在庫数だけでなく、倉庫別、ロット別、商品別の在庫状況を確認できるようにします。小規模な学習プロジェクトでは商品ごとの在庫数だけでも十分ですが、拡張を考えるなら複数倉庫にも対応できます。

在庫数は複数ユーザーが同時に操作する可能性があるため、Concurrencyに注意が必要です。EF Coreのconcurrency tokenやtransactionを使い、同時更新による在庫不整合を防ぐ設計を学べます。

6.3 統計レポート

在庫管理の統計レポートでは、在庫切れ商品、低在庫商品、入出庫数の推移、在庫金額、売れ筋商品などを表示します。これにより、LINQによる集計やグルーピングを学べます。

レポートには日付範囲、カテゴリ、倉庫、商品名によるフィルタを付けると実務的です。ExcelやPDFへの出力を追加すれば、業務システムらしい完成度になります。

6.4 バーコードスキャン

バーコードスキャンを追加すると、在庫管理システムの実用性が大きく上がります。バーコードを入力またはカメラで読み取り、該当商品を検索し、入出庫処理に進めるようにできます。

最初はバーコード文字列を手入力するだけでも十分です。後からJavaScriptライブラリや外部デバイスと連携すれば、より現場に近い操作体験を作れます。

6.5 データ同期

データ同期は、複数拠点や複数端末で在庫データを扱う場合に必要になります。たとえば、倉庫Aと倉庫Bで同じ商品を管理する場合、データ更新のタイミングや競合を考える必要があります。

学習プロジェクトでは、まずサーバー中心の同期で十分です。上級者は、queue、background job、offline sync、event-driven architectureを試すことで、より高度なシステム設計を学べます。

6.6 低在庫アラート

低在庫アラートは、在庫数が設定したしきい値を下回ったときに通知する機能です。商品ごとにMinimumStockを設定し、現在在庫がそれ以下になった場合に警告を表示します。

アラートはDashboard上に表示するだけでなく、メールやTeams通知として送ることもできます。Background jobを使って定期的に在庫をチェックすれば、より実務に近い運用が可能になります。

7. ASP.NET CoreによるBlog CMS

Blog CMSは、コンテンツ管理システムを作るプロジェクトです。記事、カテゴリ、タグ、SEO metadata、画像アップロード、コメント、公開状態、キャッシュなどを扱うため、Webアプリ開発の多くの要素を学べます.

CMSは、単なる記事CRUDではありません。管理画面、公開画面、SEO、メディア管理、認可、キャッシュなどを組み合わせることで、実用的なWebサービスに近づきます。

7.1 記事管理

記事管理では、タイトル、本文、概要、slug、サムネイル、著者、公開日、更新日、公開状態を管理します。Draft、Published、Archivedなどの状態を持たせると、実際のCMSに近くなります。

記事編集画面では、Markdownまたはリッチテキストエディタを導入すると実用性が上がります。記事の保存、プレビュー、公開予約などを実装すれば、より完成度の高いCMSになります。

7.2 カテゴリとタグ

カテゴリとタグは、記事を整理するために使います。カテゴリは大きな分類、タグは細かなキーワードとして扱うと分かりやすいです。たとえば、カテゴリが「.NET」、タグが「ASP.NET Core」「Blazor」「Web API」のような構成です。

データベース設計では、記事とタグの関係はmany-to-manyになります。EF Coreで中間テーブルを扱う練習にもなるため、データモデリングの学習に向いています。

7.3 SEO metadata

SEO metadataでは、SEO title、meta description、slug、canonical URL、OGP画像などを管理します。CMSを実用的にするには、検索エンジンやSNS共有を意識したメタ情報が必要です。

slugは記事URLに使われるため、重複チェックが重要です。また、SEO titleやmeta descriptionには文字数の目安を設けると、管理画面の品質が上がります。

7.4 画像アップロード

画像アップロードでは、記事サムネイルや本文中の画像を管理します。ファイル形式、サイズ、保存場所、ファイル名、セキュリティチェックを考える必要があります。

最初はローカル保存で十分ですが、実務ではAzure Blob StorageやS3のようなクラウドストレージを使うことが多いです。画像のリサイズや圧縮を追加すると、Webパフォーマンスの学習にもなります。

7.5 コメント機能

コメント機能では、読者が記事に対してコメントを投稿できます。管理者が承認するまで公開しないmoderation機能を入れると、実務的な設計になります。

コメントはユーザー入力を扱うため、XSS対策が重要です。HTMLをそのまま表示せず、必要に応じてsanitizeするか、プレーンテキストとして扱うのが安全です。

7.6 コンテンツキャッシュ

Blog CMSでは、公開済み記事やカテゴリ一覧は頻繁に変わらないため、キャッシュが有効です。MemoryCacheを使って記事一覧や人気記事をキャッシュすれば、データベース負荷を減らせます。

キャッシュを導入する際は、記事更新時にキャッシュを削除または更新する仕組みが必要です。古い記事が表示され続けると問題になるため、キャッシュの有効期限と更新戦略を設計しましょう。

8. オンライン予約システム

オンライン予約システムは、時間管理と業務ロジックを学ぶのに適した.NETプロジェクトです。美容室、クリニック、スクール、相談サービス、会議室予約など、多くの用途に応用できます。

このプロジェクトでは、予約枠、顧客、担当者、通知、決済、スケジュール競合などを扱います。特に、同じ時間帯に複数の予約が入らないようにするロジックが重要です。

8.1 予約管理

予約管理では、顧客、サービス、担当者、開始時刻、終了時刻、ステータス、メモなどを保存します。ユーザーは空いている時間を選択し、予約を作成します。

予約には、Pending、Confirmed、Canceled、Completedなどの状態を持たせると実務的です。状態遷移を明確にすることで、キャンセル処理や変更処理を安全に実装できます。

8.2 リアルタイム予約

リアルタイム予約では、他のユーザーが予約した時間帯をすぐに反映します。SignalRを使えば、予約状況の変更を画面に即時通知できます。

ただし、画面に表示されている空き枠だけを信頼してはいけません。最終的な予約作成時には、サーバー側で必ず時間帯の重複を再チェックする必要があります。

8.3 メール通知

メール通知では、予約完了、予約変更、キャンセル、前日リマインドなどを送信します。ユーザーにとって重要な情報を自動で送れるため、予約システムの実用性が高まります。

メール送信は、request処理の中で直接行うより、background jobとして実行する方が安全です。メール送信に時間がかかっても、ユーザーの予約操作が遅くならないように設計できます。

8.4 予約競合の処理

予約競合は、同じ担当者や同じ部屋に対して、重複した時間帯の予約が入る問題です。これを防ぐには、開始時刻と終了時刻の重なりを正しく判定する必要があります。

重なり判定には境界条件が多くあります。新しい予約が既存予約の中に入る場合、既存予約をまたぐ場合、終了時刻が開始時刻と同じ場合などをテストすることで、堅牢なロジックを作れます。

8.5 オンライン決済

オンライン決済を追加すると、予約時に前払いまたはデポジットを受け取れます。StripeやPayPalを使ってもよいですし、学習用に模擬決済を実装しても構いません。

予約状態と決済状態は分けて管理するべきです。予約は作成済みでも支払いが未完了の場合がありますし、支払い成功後に予約を確定する設計もあります。

8.6 顧客管理

顧客管理では、名前、メールアドレス、電話番号、予約履歴、メモ、利用回数などを管理します。これにより、単なる予約システムから、顧客対応システムへ発展できます。

顧客ごとの履歴を見ることで、過去の予約やキャンセル傾向を把握できます。将来的には、リピーター分析やメールマーケティングにも応用できます。

9. データ分析Dashboard

データ分析Dashboardは、データを可視化し、意思決定に使える形へ変換するプロジェクトです。売上、ユーザー数、注文数、在庫、学習進捗、KPIなどをグラフや表で表示します。

このプロジェクトでは、LINQによる集計、API設計、キャッシュ、グラフ表示、Excel/PDF出力などを学べます。管理画面やSaaSでは非常によく使われる機能です。

9.1 Data visualization

Data visualizationは、数値データをグラフやチャートで分かりやすく表現することです。折れ線グラフ、棒グラフ、円グラフ、KPIカードなどを使い、ユーザーが一目で状況を理解できるようにします。

.NET backendでは、グラフ表示用のデータをJSONで返すAPIを作成できます。BlazorやJavaScript chart libraryと組み合わせれば、インタラクティブなDashboardを構築できます。

9.2 グラフ統合

グラフ統合では、Chart.js、ApexCharts、Syncfusion、Telerikなどのライブラリを使えます。Blazor向けコンポーネントを使う方法もあれば、JS InteropでJavaScriptライブラリを呼び出す方法もあります。

重要なのは、グラフ表示ロジックとデータ取得ロジックを分離することです。APIはグラフに依存しすぎず、label、value、seriesなどの汎用的な形式でデータを返すと再利用しやすくなります。

9.3 リアルタイムレポート

リアルタイムレポートでは、データが更新されたときにDashboardも自動で更新されます。SignalRを使えば、新しい注文、問い合わせ、チャット、在庫変動などを即時反映できます。

ただし、すべてをリアルタイムにする必要はありません。5分ごとの更新で十分な場合もあります。要件に応じてSignalR、polling、cache refreshを使い分けることが重要です。

9.4 KPI tracking

KPI trackingでは、重要指標を継続的に追跡します。売上、注文数、顧客数、CVR、在庫切れ件数、学習完了率など、プロジェクトの目的に応じたKPIを設定します。

KPIは定義が曖昧だと意味がありません。たとえば「売上」が税込みか税抜きか、キャンセルを含むかどうかを明確にする必要があります。実務では、指標の定義も設計の一部です。

9.5 Excel/PDF出力

Excel/PDF出力は、Dashboardの情報を外部共有や会議資料に使うために便利です。.NETでは、Excel生成やPDF生成のライブラリを使ってレポートを出力できます。

出力時には、権限チェックが重要です。画面で見られないデータをexportできてしまうと、情報漏洩につながります。API側で権限を確認し、必要なデータだけを出力しましょう。

9.6 データキャッシュ

Dashboardは集計処理が多く、毎回データベースに重いクエリを投げるとパフォーマンスが低下します。MemoryCacheやRedisを使って集計結果を一定時間保存すると、レスポンスを改善できます。

キャッシュには有効期限と更新ルールが必要です。リアルタイム性が重要なKPIは短めに、過去データのように変わらない情報は長めにキャッシュするなど、データの性質に応じて設計します。

10. リアルタイムチャットアプリ

リアルタイムチャットアプリは、SignalRを学ぶために最適な.NETプロジェクトです。ユーザー間のメッセージ送受信、プライベートチャット、グループチャット、通知、履歴保存などを実装できます。

このプロジェクトでは、通常のHTTP request-responseとは異なるリアルタイム通信の考え方を学べます。リアルタイム性が必要なDashboard、通知、共同編集、ゲームロビーなどにも応用できます。

10.1 SignalRの基本

SignalRは、ASP.NET Coreでリアルタイム通信を実現するためのライブラリです。サーバーからクライアントへ即時にメッセージを送信できるため、チャットアプリに適しています。

まずはChatHubを作り、ユーザーが接続し、メッセージを送信し、全員に配信される仕組みを作ります。Hub、connectionId、Clients.All、Clients.Userなどの基本を理解することが重要です。

10.2 Private chat

Private chatでは、特定のユーザー同士だけがメッセージを送受信できます。ユーザーIDとconnectionIdを紐づけ、送信先のユーザーにだけメッセージを送ります。

実務では、1人のユーザーが複数デバイスや複数タブで接続している場合があります。そのため、1ユーザーに複数のconnectionIdが存在することを考慮する必要があります。

10.3 Group chat

Group chatでは、複数ユーザーが同じルームに参加し、メッセージを共有します。SignalRのGroup機能を使えば、特定のグループに属するクライアントだけへメッセージを送信できます。

グループ参加時には、ユーザーがそのルームに参加する権限を持っているか確認する必要があります。権限チェックを行わないと、関係ないユーザーがグループメッセージを受信する危険があります。

10.4 リアルタイム通知

チャット以外にも、リアルタイム通知は多くのアプリで使えます。新しいメッセージ、タスク割り当て、注文作成、予約確定、承認依頼などを即時通知できます。

通知はSignalRで送るだけでなく、データベースにも保存するべきです。ユーザーがオフラインだった場合でも、再ログイン後に未読通知を確認できるようにするためです。

10.5 メッセージ履歴保存

チャットアプリでは、過去のメッセージを保存する必要があります。MessagesテーブルにsenderId、receiverId、roomId、content、createdAt、readAtなどを保存します。

履歴表示では、すべてのメッセージを一度に読み込むのではなく、Paginationやinfinite scrollを使います。大量のメッセージがある場合でも、必要な分だけ取得することでパフォーマンスを保てます。

10.6 接続最適化

リアルタイムアプリでは、接続管理が重要です。ユーザーの接続、切断、再接続、複数タブ、ネットワーク不安定時の動作を考える必要があります。

また、メッセージの送信頻度を制限しないと、スパムや過剰通信でサーバー負荷が上がる可能性があります。rate limitingや入力制御を導入すると、より安全なリアルタイムアプリになります。

11. .NET MAUIによるモバイルアプリ

.NET MAUIは、C#と.NETでAndroid、iOS、Windows、macOS向けのアプリを作れるクロスプラットフォームフレームワークです。Webだけでなくモバイルアプリにも挑戦したい.NET学習者に適しています。

このプロジェクトでは、UI設計、MVVM、API連携、ローカル保存、Push Notification、Android/iOSへの展開を学べます。ASP.NET Core APIと組み合わせることで、フルスタックな.NETポートフォリオを作れます。

11.1 UI設計

.NET MAUIでは、XAMLまたはC#でUIを作成します。ボタン、入力欄、リスト、ナビゲーション、タブ、カードなど、モバイル向けの画面部品を設計します。

Webアプリの画面をそのままモバイルに移植するのではなく、タップ操作、画面サイズ、片手操作、読みやすさを考慮する必要があります。モバイルUIでは、情報を絞り、操作をシンプルにすることが重要です。

11.2 MVVM Pattern

MVVMは、.NET MAUIでよく使われる設計パターンです。Viewは画面、ViewModelは状態と操作、Modelはデータを担当します。これにより、UIとロジックを分離できます。

MVVMを使うと、データバインディング、Command、ObservableCollectionなどを活用できます。最初は少し難しく感じるかもしれませんが、MAUIアプリを保守しやすくするためには非常に重要な考え方です。

11.3 API Integration

モバイルアプリは、バックエンドAPIと連携してデータを取得・更新します。ASP.NET Core Web APIを作成し、MAUIアプリからHttpClientでアクセスする構成が実践的です。

モバイル環境では、通信が不安定になることがあります。そのため、timeout、retry、offline handling、エラーメッセージを丁寧に設計する必要があります。

11.4 Local Storage

Local Storageは、アプリ内にデータを保存する仕組みです。設定値、ログイン状態、キャッシュ、オフラインデータなどを保存できます。.NET MAUIではPreferences、SecureStorage、SQLiteなどを使えます。

機密情報はSecureStorageに保存するべきです。大量のデータやオフライン対応が必要な場合はSQLiteを使うとよいでしょう。ローカル保存とサーバー同期を組み合わせると、実用的なモバイルアプリになります。

11.5 Push Notification

Push Notificationは、アプリを開いていないユーザーにも通知を送る機能です。予約リマインド、チャット通知、タスク期限、学習通知などに利用できます。

実装には、Firebase Cloud MessagingやApple Push Notification serviceとの連携が必要です。バックエンド側では、デバイストークン管理、通知履歴、通知設定を扱うとより実務的です。

11.6 Android/iOSへの展開

.NET MAUIアプリは、AndroidとiOSに展開できます。AndroidではAPKやAABを作成し、iOSでは証明書やApp Store Connectの設定が必要になります。

デプロイ作業はWebアプリより複雑ですが、実務では非常に価値のある経験です。特に、バックエンドAPI、モバイルUI、認証、Push Notificationまで含むプロジェクトは、強力なポートフォリオになります。

12. 学習管理システム（LMS）

LMSは、オンライン学習を管理するためのシステムです。コース、受講者、講師、レッスン、テスト、成績、進捗、レポートなどを扱います。中級以上の.NET学習者に適した実践プロジェクトです。

このプロジェクトでは、複数のユーザーロール、コンテンツ管理、テスト機能、進捗管理、レポート作成などを学べます。教育系サービスや社内研修システムにも応用できるため、実務性が高いです。

12.1 コース管理

コース管理では、コース名、説明、講師、カテゴリ、価格、公開状態、レッスン一覧などを管理します。1つのコースには複数のレッスンやモジュールを持たせることができます。

コースにはDraft、Published、Archivedなどの状態を持たせると、管理しやすくなります。講師が作成中のコースを保存し、準備ができたら公開する流れを作ると実務的です。

12.2 受講者管理

受講者管理では、ユーザーがどのコースに登録しているか、どこまで学習したか、どのテストを受けたかを管理します。受講者とコースはmany-to-manyの関係になります。

受講履歴を保存することで、受講者ごとの進捗や成績を表示できます。管理者や講師は、学習が止まっている受講者を見つけ、フォローアップすることもできます。

12.3 オンラインテスト

オンラインテストでは、選択式問題、複数回答問題、短文回答などを作成できます。各問題には選択肢、正解、配点、説明を持たせるとよいでしょう。

テスト機能はデータ構造がやや複雑ですが、非常に学習効果があります。Questions、Answers、StudentSubmissions、Scoresなどのテーブルを設計し、回答と採点の流れを実装します。

12.4 自動採点

自動採点では、受講者の回答と正解を比較し、点数を計算します。選択式問題であれば比較的簡単に実装できますが、複数回答や部分点を扱うと難易度が上がります。

採点ロジックはServiceに分離するのが望ましいです。将来的に問題形式が増えても、採点処理を拡張しやすくなります。Strategy Patternを使う練習にもなります。

12.5 学習進捗管理

学習進捗管理では、受講者がどのレッスンを完了したか、どのテストに合格したかを記録します。進捗率を計算し、ダッシュボードに表示すると学習者のモチベーション向上につながります。

進捗は、レッスン完了、動画視聴、課題提出、テスト合格など複数の条件で更新できます。シンプルに始めるなら、レッスン完了状態だけを保存し、後から機能を拡張するとよいでしょう。

12.6 結果レポート

結果レポートでは、受講者別の成績、コース別の完了率、テスト平均点、未完了者一覧などを表示します。講師や管理者が学習状況を把握するために重要です。

レポートには期間、コース、受講者グループでのフィルタを付けると実務的です。ExcelやPDF出力を追加すれば、企業研修システムのような完成度になります。

13. .NETによるMicroservices

Microservicesは、システムを複数の小さなサービスに分割するアーキテクチャです。.NETでは、ASP.NET Core Web API、Docker、Message Queue、API Gateway、Distributed Loggingなどを組み合わせて構築できます。

このプロジェクトは上級者向けです。まだCRUDやAPI設計に慣れていない段階で始めると難しすぎるため、まずはモノリスで業務システムを作れるようになってから挑戦するのがおすすめです。

13.1 Microservicesアーキテクチャ設計

Microservicesでは、サービスごとに責務を分けます。たとえば、ECシステムならProduct Service、Order Service、Payment Service、User Service、Notification Serviceのように分割できます。

難しいのは、どこでサービスを分けるかです。細かく分けすぎると運用が複雑になり、粗く分けすぎると独立性が低くなります。まずは明確な境界を持つ数個のサービスから始めるのが現実的です。

13.2 API Gateway

API Gatewayは、クライアントと複数サービスの間に立つ入口です。クライアントは各サービスを直接呼び出すのではなく、Gatewayにアクセスし、Gatewayが適切なサービスへルーティングします。

.NETでは、YARPやOcelotを使ってAPI Gatewayを学べます。認証、ルーティング、rate limiting、loggingをGatewayに集約すると、クライアント側の複雑さを減らせます。

13.3 Service Discovery

Service Discoveryは、各サービスが互いの場所を見つけるための仕組みです。コンテナ環境ではサービスのIPやインスタンス数が変わるため、固定URLだけに依存するのは危険です。

学習段階ではDocker Composeのservice nameでも十分です。より高度に学ぶなら、Consul、Kubernetes Service、Daprなどを調べると、クラウドネイティブな考え方に近づけます。

13.4 Message Queue

Message Queueは、サービス間の非同期通信に使います。たとえば、注文作成後にOrder ServiceがOrderCreatedイベントを発行し、Notification Serviceがそれを受け取ってメールを送信します。

RabbitMQ、Azure Service Bus、Kafkaなどが代表的です。Queueを使うとサービス間の依存を減らせますが、retry、dead-letter queue、重複処理への対応も必要になります。

13.5 Distributed Logging

Microservicesでは、1つのリクエストが複数サービスを通過します。そのため、どこでエラーが起きたかを追跡するためにDistributed Loggingが必要です。

correlationIdやtraceIdを使い、複数サービスのログをつなげると調査しやすくなります。OpenTelemetryや集中ログ基盤を学ぶと、実務に近い監視設計を理解できます。

13.6 Dockerによるコンテナ化

Dockerは、各サービスを独立したコンテナとして実行するために使います。Microservicesでは、サービスごとにDockerfileを作り、Docker Composeでまとめて起動する構成が学習しやすいです。

Docker化することで、環境差異を減らし、開発・テスト・デプロイを安定させられます。将来的にはKubernetesやクラウドコンテナサービスに進むための基礎にもなります。

14. SaaS Multi-tenantシステム

SaaS Multi-tenantシステムは、複数の企業や顧客が同じアプリケーションを利用しながら、それぞれのデータを分離する仕組みです。B2B SaaSを作りたい人にとって、非常に重要なプロジェクトです。

このプロジェクトでは、tenant管理、データ分離、subscription、billing、権限、scalabilityを学べます。高度ですが、完成すれば非常に強いポートフォリオになります。

14.1 Multi-tenancy Architecture

Multi-tenancy Architectureには、shared database shared schema、shared database separate schema、database per tenantなどの方式があります。最初は、すべてのテーブルにTenantIdを持たせるshared database方式が学習しやすいです。

この方式は実装が比較的簡単ですが、すべてのクエリでTenantIdを正しく使う必要があります。1箇所でも漏れると、別tenantのデータが見えてしまうため、慎重な設計が必要です。

14.2 Tenant Isolation

Tenant Isolationは、tenantごとのデータを確実に分離することです。ユーザーがA社のtenantに所属しているなら、B社のデータにはアクセスできないようにします。

Middlewareでtenantを判定し、TenantContextとしてアプリ全体で利用する設計が考えられます。RepositoryやDbContextで自動的にTenantIdを付与・フィルタする仕組みを作ると安全性が高まります。

14.3 Subscription Management

Subscription Managementでは、tenantごとの契約プランを管理します。Free、Pro、Enterpriseなどのプランを用意し、利用可能な機能、ユーザー数、データ容量などを制限できます。

この機能を実装すると、SaaSらしいビジネスロジックを学べます。プラン変更、期限切れ、トライアル、利用制限などを扱うことで、実際のSaaS開発に近い経験が得られます。

14.4 Billing System

Billing Systemでは、請求、支払い、請求書、決済履歴を管理します。Stripeなどの決済サービスを使うか、学習用に模擬billingを作る方法があります。

重要なのは、支払い状態とsubscription状態を正しく同期することです。決済成功、失敗、キャンセル、返金などのイベントを処理し、tenantの利用状態に反映する必要があります。

14.5 Security Considerations

SaaS Multi-tenantでは、通常のアプリ以上にセキュリティが重要です。tenant間のデータ漏洩は重大な問題になるため、認証、認可、TenantIdの検証を徹底する必要があります。

また、audit logも重要です。誰が、いつ、どのtenantで、どのデータを変更したかを記録すれば、不正操作や事故が起きたときに調査できます。

14.6 Scalability Design

SaaSはtenant数やユーザー数が増えることを前提に設計する必要があります。キャッシュ、database index、background job、queue、stateless APIなどを使い、拡張しやすい構成を考えます。

最初から完璧な分散システムにする必要はありません。まずはmodular monolithとして作り、負荷が増えた部分を後から分離できる構成にしておくのが現実的です。

15. ERP Mini

ERP Miniは、企業管理システムを小規模に再現する上級プロジェクトです。CRM、HRM、在庫、財務、Dashboardなど複数の業務モジュールを統合します。

このプロジェクトでは、複数モジュールの設計、共通認証、権限管理、データ連携、レポート、拡張可能なアーキテクチャを学べます。完成すれば、.NET開発者としての総合力を示せます。

15.1 顧客管理（CRM）

CRMモジュールでは、顧客、連絡先、商談、活動履歴、ステータスを管理します。営業活動や顧客対応を記録できるため、ERP Miniの中でもビジネス価値が分かりやすい機能です。

顧客ごとの履歴や商談ステージを管理すると、単なる顧客一覧ではなく、営業支援ツールに近づきます。検索、フィルタ、担当者別表示を追加すると実用性が高まります。

15.2 人事管理（HRM）

HRMモジュールでは、社員、部署、役職、雇用状態、契約情報を管理します。社員管理システムで学んだ内容をERPの一部として統合できます。

ERPでは、HRMが権限管理や承認フローと関係することがあります。たとえば、部署マネージャーだけが自部署の申請を承認できる、といったロジックを追加できます。

15.3 在庫管理

在庫管理モジュールでは、商品、入庫、出庫、在庫数、低在庫アラートを扱います。CRMや注文管理と連携させれば、販売と在庫をつなげることができます。

在庫データは正確性が重要です。入出庫履歴を必ず保存し、現在数だけでなく過去の変動も追跡できるようにすると、実務的な設計になります。

15.4 財務管理

財務管理では、売上、支出、請求、支払い、キャッシュフローを管理します。最初は簡易的な収支管理でも十分ですが、ERPらしさを出すために取引履歴とレポートを作るとよいでしょう。

金額を扱う処理では、decimal型を使い、丸め処理や通貨を意識する必要があります。財務データはミスの影響が大きいため、validationとaudit logも重要です。

15.5 経営Dashboard

経営Dashboardでは、CRM、HRM、在庫、財務のデータを集約して表示します。売上、顧客数、社員数、在庫アラート、支出、利益などをKPIとして表示できます。

複数モジュールのデータをまとめるため、API設計とクエリ最適化が重要です。DashboardはERP Miniの価値を分かりやすく示す画面になるため、見やすいUIを意識しましょう。

15.6 拡張可能なシステムアーキテクチャ

ERP Miniでは、最初からMicroservicesにするより、modular monolithとして設計する方が現実的です。1つのアプリケーション内で、CRM、HRM、Inventory、Financeなどのモジュールを明確に分けます。

各モジュールは、独自のService、DTO、Repository、Validationを持つようにします。こうすることで、将来的に必要なモジュールだけを別サービスへ切り出すことも可能になります。

おわりに

.NETを習得するには、実践プロジェクトを通じて段階的に学ぶことが最も効果的です。最初はTo-Doリスト、社員管理、商品APIのような基礎プロジェクトから始め、ASP.NET Core、Entity Framework Core、CRUD、Validation、REST APIの土台を固めることが重要です。

次に、認証システム、ECサイト、在庫管理、Blog CMS、予約システム、Dashboard、チャットアプリなどに進むことで、実務でよく使われる機能を幅広く学べます。JWT、Identity、SignalR、Caching、Payment、Reporting、Exportなど、現場で必要になる技術も自然に習得できます。

上級者は、.NET MAUI、LMS、Microservices、SaaS Multi-tenant、ERP Miniに挑戦するとよいでしょう。これらのプロジェクトでは、モバイル開発、分散システム、マルチテナント設計、Docker、Message Queue、拡張可能なアーキテクチャなど、より高度なテーマを学べます。

重要なのは、単に「動くもの」を作るだけで終わらせないことです。README、設計説明、ER図、APIドキュメント、デプロイURL、テスト、ログ、認証、エラーハンドリングまで整えることで、学習プロジェクトは実務に近いポートフォリオになります。特にProduct API、Authentication System、E-commerce、Dashboard、MicroservicesまたはSaaS Multi-tenantを丁寧に作れば、backend、database、security、API design、frontend integration、system architectureを幅広く示せます。