【C#/Blazor】実務Webアプリ開発編 (10)ソフトウェア開発の全体像 ～要件定義・設計・実装・テスト・デプロイの流れ～

これまでのシリーズ「Webアプリ開発入門編」（第1〜9回）では、Blazorの基本やTodoアプリを通じてWebアプリ開発の基礎を学んできました。

いよいよ第10回から、実務レベルのアプリ「メンターアプリ」の開発がスタートします。

このシリーズでは、要件定義・設計・実装・テスト・デプロイというソフトウェア開発の全工程を、一つの完成したアプリを題材に体験していきます。

以下のような方に役立つ内容となっています。

完成したメンターアプリのコード・ドキュメント一式はGitHubに置いてありますので、参考にしてください。

ソフトウェア開発の流れ

「コードの書き方はわかってきた。でも、実際のアプリってどうやって作るの？」——プログラミング学習でよくある壁です。

文法やフレームワークの使い方を理解しても、ゼロからアプリを作ろうとすると何から始めればいいかわからなくなる。まずその全体の地図を持っておきましょう。

ソフトウェア開発には一般的に次のような活動があります。これを ソフトウェア開発ライフサイクル（SDLC：Software Development Life Cycle） と呼びます。

これらは単に順番に並んでいるわけではなく、互いに影響し合う活動です。要件があいまいであれば設計はぶれ、設計がぶれれば実装やテストにも影響が及びます。

それぞれの活動が何をするのか、簡単に見ていきましょう。

要件定義：「何を作るか」を決める

「誰が使うのか」「どんな機能が必要か」「逆に対象外にするものは何か」を明確にする活動です。要件があいまいなまま実装を始めると後から大幅な作り直しが発生します。

シリーズを通じて spec.md というドキュメントに要件・設計をまとめていきます

設計：「どう作るか」を決める

システム構成・使用技術の選択・データの構造化・画面レイアウトなど、実装前に「どう作るか」を具体化する活動です。

特にデータ構造やロジックが複雑な部分は、先に設計をしっかり行っておくと、実装がスムーズに行えます。

このシリーズでは、クリーンアーキテクチャとドメイン駆動設計（DDD）を採用します。

詳しくは後続記事で学びますが、変更に強く、テストしやすいコードを実現するための設計方針です。

今回は学習しやすい小さな題材を扱いますが、その中でも「ドメインを中心に設計する」考え方を体験できるよう、この構成を採用しています。

実装：「作る」

設計をもとにコードを書く活動です。

このシリーズでは最も多くの記事を割く部分です。アプリを4層(Domain/Infrastructure/Application/UI)に分けて実装を行います。

テスト：「正しく動くか検証する」

コードが意図どおりに動くかを検証する活動です。単体テスト・統合テスト・E2Eテストなど、確認する範囲に応じてさまざまな手法があります。

テストを自動化すると、変更を重ねても品質を保ち続けるための安全網としても機能します。

このシリーズでは、xUnitによる統合テストとPlaywrightによるE2Eテストを扱います。

デプロイ・運用：「公開して使えるようにする」

アプリをユーザが利用できる状態にして届ける活動です。

スマホアプリやPCアプリではストア・配布サイトへのバイナリ配布が中心になり、Webアプリではサーバーへの配置（デプロイ）が主な手段です。

公開後もアップデートの提供やエラー・クラッシュの監視など、継続的なメンテナンスが続きます。

このシリーズでは、まずローカルでアプリを起動して動作を確認するところから始め、その後Azureへのデプロイも扱います。

開発スタイルによる違い

ソフトウェア開発ライフサイクルにおける各活動をどのくらい重視するかは、開発スタイルによって変わります。いくつか例をみてみましょう。

ウォーターフォール開発

要件定義→設計→実装→テスト→デプロイを順番に進めるスタイルです。

各工程を完了させてから次に進むため、大規模プロジェクトや要件が明確な案件で採用されることが多いです。各工程でドキュメントをしっかり作成するのが特徴です。

一方、開発の途中で要件の変更が起きると手戻りが大きくなりやすいという課題があります。

アジャイル開発

小さな単位で「要件定義→設計→実装→テスト→リリース（デプロイ）」のサイクルを短期間（1〜4週間程度）で繰り返すスタイルです。

動くソフトウェアを早い段階でユーザに届け、フィードバックを得ながら改善を重ねていきます。

変化に強い反面、全体の方向性がぶれないようにチーム内での密なコミュニケーションが求められます。

個人開発

個人や少人数で開発する場合は、上記のような厳密なプロセスを踏まず、必要な部分だけ軽量に行うスタイルが現実的です。

「まず動くものを作り、使いながら改善する」という進め方が中心になります。

ドキュメントも最小限で済ませられますが、ある程度の要件整理や設計メモを残しておくと、後から「なぜこう作ったか」を思い出せて助かります。

このシリーズで扱う「メンターアプリ」は、個人開発のスタイルに近いですが、要件定義・設計も最低限行っていきます。

題材となるメンターアプリ

このシリーズの題材は「メンターアプリ」です。

プロ太（私）がプログラミングメンターとして複数のメンティーをサポートする中で、以下を課題に感じていました。

メンターアプリは、これらを効率的に行える基盤として開発をはじめました。

蓄積した対話データを将来AIと組み合わせることも視野に入れつつ、まずはトピック管理・チャット機能をシンプルに実装します。
（注意：AI機能は将来の拡張として考えていますが、このシリーズでは扱いません）

アプリ概要

「メンターアプリ」は、メンターとメンティーの対話をトピックごとに管理するチャットアプリです。

ユーザロールは以下のようになっています。

ロール	役割
Admin（管理者）	ユーザー管理・メンタリング関係の登録と管理
Mentor（メンター）	担当メンティーとのトピック作成・メッセージ交換
Mentee（メンティー）	担当メンターとのトピック作成・メッセージ交換

主な機能は以下です。

技術スタックは以下です。

このシリーズの全体構成

シリーズ全体の学習の流れを示します。「第10回の今」がどこにいて、これから何を学ぶのかを把握しておきましょう。

注意：以下の構成は現時点の想定です。記事を作りながらブラッシュアップしていくため、内容・順序が変わる可能性があります。

Part	テーマ	内容
I	ソフトウェア開発の全体像	← 今ここ
II	要件定義と設計	「何を作るか」「どう作るか」を決める
III	アーキテクチャ概論	クリーンアーキテクチャ・DDDの考え方を実装前に整理する
IV	ドメイン層の実装	DDDの核心。フレームワーク非依存で書ける
V	永続化とCQRS(コマンド・クエリ責務分離)	データの保存・取得の仕組みを作る
VI	認証の実装	OIDCで外部IdPと連携する
VII	Blazor UI層の実装	設計・実装の成果をUIに繋ぐ
VIII	セキュリティ	完成したアプリの安全性を点検する
IX	テスト	統合テスト・E2Eテスト
X	運用・デプロイ	Azureへ公開して完成

まとめ

ソフトウェア開発は「コードを書く」だけではありません。「要件定義 → 設計 → 実装 → テスト → デプロイ」という流れ全体が、一つのアプリを完成させる営みです。

ウォーターフォール開発、アジャイル開発、個人開発でも、「何を作るか」「どう作るか」を考えることは変わりません。スタイルによってフェーズの重み付けが変わるだけです。

このシリーズの題材「メンターアプリ」は、要件定義から始まり、設計・実装・テスト・デプロイまでを一気通貫で体験できます。

完成形のコードを参照実装として使いながら、実務に近い開発の流れをそのまま学んでいきましょう。

次回は、要件定義を実際に書いていきます。spec.mdの要件定義セクションを教材に、「何を作るか」を具体的に定義していきましょう。