最終演習課題 社員管理システム 保有資格管理機能の追加
この演習の位置づけ
Section titled “この演習の位置づけ”これは、研修の総まとめとなる 最終演習課題 です。
これまでの章では、手順に沿って社員一覧・検索・登録・編集・削除を作ってきました。 この最終演習では、手順書はありません。 渡されるのは、人事部から届いた 開発依頼書(要求仕様書) です。
あなたの仕事は、依頼を受けた開発担当者 として依頼書を読み、必要な テーブルを自分で設計 し (画面イメージは依頼元から提示されます)、 完成済みの Web 版 社員管理アプリに 保有資格管理機能 を追加することです。
この演習でいちばん大切なこと
評価の最優先は「手順を踏んだか」ではなく、 「依頼書(要求仕様)を満たす、動くものを納められたか」 です。 きれいなコードより前に、まず「要件を満たして動く」ことを目指してください。
また、この演習は 実務(OJT)を意識 した進め方をします。
- 先に やることを見積もり、リリース計画を立ててから着手する
- 納期(提出時刻 = リリース時刻) を守る
- 間に合わない機能は、中途半端に出さず 外して、動くものを納める
新しい文法を大量に覚える章ではありません。 これまで学んだ C# / SQL / DB 設計 / MVC / Repository / ViewModel を組み合わせて、 小さな業務機能を 自力で 追加できることを確かめる演習です。
開発依頼書(要求仕様書)を読む ↓狙うレベルを決め、やることを見積もる(リリース計画) ↓設計を考える(テーブル・クラス。画面は支給) … チームで相談可 ↓上司レビューを経て、講師の最終スキーマと見比べ、使う設計を確定する(工程 3) ↓ ※基本は最終スキーマ。どうしても自設計で行きたいチームはそのままでも可 ↓個人で実装する ↓受け入れ確認(要件を満たしているか) ↓リリース(納品) ↓ミニ発表・ふりかえり(リリース後)この演習でできるようになること
Section titled “この演習でできるようになること”この演習を終えると、次のことができるようになります。
- 開発依頼書(要求仕様書)を読み、必要なデータ構造を 自分で考えられる
- 社員と資格の 多対多 の関係を説明できる
- 中間テーブルの役割を説明できる
- ER 図でテーブル間の関係を表現できる
- 簡易的なクラス図で Model / Repository / Controller / ViewModel の関係を整理できる
- 既存の社員管理アプリに、新しいテーブルと画面を追加できる
- 要件を「満たしたかどうか」で自分の成果を確認できる
- 限られた時間の中で、やることを 見積もり、納期に合わせて出すものを決められる
- 自分が設計・実装した内容を説明できる
この演習は、次の状態を前提とします。
- 第 30 章までの Web 版 社員管理アプリが完成している
MvcEmployeeAppプロジェクトが手元で動作するTrainingDBのemployees/departmentsテーブルが使える- 社員一覧・検索・登録・編集・削除が動作する
- SQLServer に接続できる
- Git で提出できる
実装は、この MvcEmployeeApp を引き続き育てる 形で行います(新しいプロジェクトは作りません)。
実務を意識した進め方(リリース演習)
Section titled “実務を意識した進め方(リリース演習)”この演習は「リリース演習」として進めます。 実際の開発と同じように、納期に向けて、出せるものを計画して出す 流れを体験します。
仕様充足が最優先
Section titled “仕様充足が最優先”評価の中心は 依頼書(要求仕様)を満たしているか です。 凝った作り込みより先に、自分が狙ったレベルが動くこと を優先してください。
先に「リリース計画」を立てる
Section titled “先に「リリース計画」を立てる”実装に入る前に、リリース計画.txt を作り、次を書いてコミットします。
- 取り組む要件の番号(どの要件まで納めるか)
- そのための作業の見積もり(おおよその順番と時間配分)
- 今回は外す機能(時間内に入らないと判断したもの)
なぜ先に計画するのか
実務では「全部やる」と決めて間に合わないより、 「ここまでを確実に納める」と決めて確実に出す方が信頼されます。 見積もりは外れて構いません。外れたら計画を更新する のも実務の一部です。
納期(提出時刻 = リリース時刻)を守る
Section titled “納期(提出時刻 = リリース時刻)を守る”提出時刻は リリース時刻 とみなします。 チームの タイムキーパーが納期を管理 します(チームの役割分担は第 17 章を参照)。
フィーチャーフリーズ
Section titled “フィーチャーフリーズ”納期が近づいたら フィーチャーフリーズ を行います。
- 間に合わない機能は 中途半端なまま出さない
- 動かない機能を残すより、動くところまでを確実に納める
- 外した機能は
リリース計画.txtに「今回は外した」と書く
個人とチームの切り替え
Section titled “個人とチームの切り替え”| 段階 | 進め方 |
|---|---|
| 要件を読む・見積もる | 個人で読む → チームで相談可 |
| 設計を考える(テーブル・クラス。画面は支給) | チーム相談可 |
| 仕様確定・クラス設計 | チーム(講師が最終スキーマを比較用に提示) |
| 実装する | 個人(相談は可) |
| 動作確認・受け入れ確認 | 個人(質問・相談は可) |
| リリース(提出) | 個人 |
| ミニ発表(リリース後) | 個人 |
重要:チームで進める工程のルール(全員の理解と合意で進める)
工程 1〜3(要件理解・設計・仕様確定)は チームで進める 工程です。 ここでいう「チームで進める」とは、手分けして誰か 1 人が決める・1 人だけが分かっていればよい、という意味ではありません。 メンバー全員が内容を理解し、全員の合意(総意)で決めて 進めてください。
- 設計や要件の理解は、このあとの 実装(工程 4)で全員が個人で必要 になります。今わからないまま進むと後で全員が困ります。
- 「決まったこと」だけでなく 「なぜそう決めたか」も全員が説明できる 状態にしてください。
- 一部の人だけが先に手を動かして進めるのではなく、分からない人がいたらその場で止めて、全員がそろってから次へ。
- 上司レビューでは、メンバーの誰に質問しても説明できるか を確認することがあります(代表者 1 人が答えれば合格、ではありません)。
重要:個人作業のルール(相談は OK、役割分担は NG)
設計方針の相談まではチームで行って構いません。実装に使う設計が固まった後の 実装と提出は個人 で行います。
これは試験ではないので、わからないところを相談したり、教え合ったりするのは大歓迎 です。 ただし、作業を役割分担するのは NG です(「あなたは追加機能、私は削除機能」のような分担はしない)。 全員が、すべての作業(設計の理解・テーブル作成・表示・追加・削除…)を自分の手で 行ってください。 相談して理解したことも、最後は自分のコードとして自分で書く ── これが「全員ができるようになる」ための原則です。 他の人の考え方を参考にするのは構いませんが、ソースコードをそのままコピーして提出することは認めません。
進め方の全体像(6 つの工程)
Section titled “進め方の全体像(6 つの工程)”この演習は、実際の開発と同じように 工程(フェーズ)に区切り、各工程の終わりに「上司レビュー」を受けて 進めます。 ここでの上司レビューは、講師・サブ講師 が担当します。
各工程は、上司レビューに合格(承認)してから次の工程へ進みます。これには 2 つのねらいがあります。
- 間違った設計のまま先に進むのを防ぐ(特に設計工程。土台が崩れたまま実装すると手戻りが大きい)
- 設計を確かなものにして実装に入る(設計工程のレビューと、講師が示す最終スキーマとの比較を経て、各チームが自信を持って実装設計を確定する)
| 工程 | 作業の単位 | 上司レビューで見られること(合格の目安) | 合格したら |
|---|---|---|---|
| 1. 要件定義の理解 | チーム | 要件 R1〜R8 を正しく理解している。リリース計画.txt の見積もりが現実的 | 工程 2 へ |
| 2. 設計(データ設計レビュー)★最重要 | チーム | ER 図・テーブル設計が 多対多 + 中間テーブル になっている。重複防止(R5)を DB 制約で 考えている | 工程 3 へ |
| 3. 仕様確定とクラス設計 | チーム | 最終スキーマ(講師が提示)と自設計を 比較・まとめ し(基本は最終スキーマに合わせる。希望チームは自設計のままでも可)、使う設計を確定して対応する クラス設計(クラス図/メモ) を用意した | 工程 4 へ |
| 4. 実装 | 個人 | (軽いゲート)確定した設計どおりにテーブル・クラスを作り始めている | 工程 5 へ |
| 5. 受け入れ確認 | 個人 | 狙ったレベルの要件を満たして動く | 工程 6 へ |
| 6. リリース(提出) | 個人 | 狙ったレベルが動く状態でリリース=納品した(演習の到達点) | 工程 7 へ |
| 7. ミニ発表(リリース後) | 個人 | 設計と実装を説明できる | 完了 |
ミニ発表はリリースの後に行います
工程 1〜6(設計・実装・リリース)を終えて納品したあと、工程 7 のミニ発表 を行います (本演習では最終日の午後にリリース → 続けて発表。日程は講師の指示に従ってください)。
進め方のルール
このあとは 工程ごとに節を分けて 説明します。各工程は 「この工程のゴール → やること → 上司レビュー(合格の目安)」 の順に書いてあります。 ひとつの工程を完了(上司レビューに合格)させてから、次の工程に進んでください。
設計は一度、自分(チーム)で考えてから
工程 2 の設計は、答えを教わる前に 自分たちで考える ことがいちばんの学びです。 工程 3 で講師が最終スキーマを提示します。それと見比べてから実装に入ります。基本は最終スキーマに合わせます が、どうしても自分たちの設計で進めたいチームは、工程 2 を通った設計ならそのままでも構いません。
工程 1〜3 はチーム、工程 4 以降は個人
設計・仕様確定まではチーム単位でゲートを通ります。チームの工程は 「誰か 1 人が分かればよい」ではなく、メンバー全員が理解し、全員の合意で進める(詳細は上の「個人とチームの切り替え」の重要注記)。 実装からは個人作業になり、各自の成果物として、自分のペースでリリースまで進めて構いません (個人ごとに上司レビューを待つ必要はありません。困ったら相談してください)。
対応レベル(自分のスキルで目標を決める)
Section titled “対応レベル(自分のスキルで目標を決める)”依頼元は R1〜R8 のすべてを希望しています。とはいえ、限られた時間では全員が同じところまで作れるとは限りません。 そこで、自分のスキルと時間に合わせて、どのレベルまでを目標にするか を決めて取り組みます(目標は工程 1 の「リリース計画」で宣言します)。
| レベル | 到達目標(動くシステム) | 主な要件 | 学びの核 |
|---|---|---|---|
| 共通 | 設計資料(ER 図・簡易クラス図)を作る | R1〜R8 | 多対多・中間テーブルの設計 |
| A 基本(まず全員ここを目指す) | 社員詳細画面で、その社員の保有資格を 一覧表示 できる | R1・R2・R3・R4・R6 | 中間テーブル＋JOIN で表示 |
| B 標準 | 社員に資格を追加・社員から資格を削除 できる(資格マスタの編集ではない) | R7・R8 | フォーム→Insert/Delete＋PRG |
| C 発展 | 重複登録を防ぐ(DB 制約) ＋ Bootstrap でごく簡単に画面を整える ＋ 作り込み | R5 ＋ 発展課題 | UNIQUE 制約・例外処理・Bootstrap・付録 M/N |
- まずは 共通(設計)＋レベル A を確実に。動く状態を保ったまま、余裕に応じて B → C と積み上げます。
- 評価でいちばん大事なのは 「狙ったレベルが確実に動くこと(仕様充足)」 です。間に合わないときは、無理に上を狙わず、下のレベルを確実に 納めてください(フィーチャーフリーズ)。
レベル C の「ごく簡単なデザイン」について
レベル C では、機能だけでなく Bootstrap で画面の見た目を少し整える ところまで踏み込みます。 凝ったデザインは不要です。
table/btn/form-control/alertなどの クラスを少し足すだけ で十分です (使い方は 付録 K「最低限の HTML」K-5 を参照)。仕様(機能)が先、デザインは後 の順番を守りましょう。
レベル C まで満たせた人へ:独自機能の追加も OK
要求仕様(R1〜R8)を満たしたうえでなら、自分で考えた独自の機能を追加 してもかまいません (例:資格の分野別の集計、取得状況のサマリー表示、レベル別の絞り込みなど)。 ただし 仕様充足が最優先 です。独自機能のせいで仕様がおろそかにならないよう、 取り組む前に
リリース計画.txtに追記してから着手しましょう。
各工程で仕上げる成果物(必須課題の一覧)
Section titled “各工程で仕上げる成果物(必須課題の一覧)”依頼を満たすための成果物を、対応レベル(上の表)・仕上げる工程・対応する要件 とあわせて示します。 共通(設計)＋レベル A を先に確実に仕上げ、時間に応じて B → C へ積み上げてください。
| 課題 | 内容 | レベル | 仕上げる工程 | 対応する要件 |
|---|---|---|---|---|
| 課題 1 | 設計資料を作る(ER 図=工程 2 / スキーマ比較メモ・簡易クラス図=工程 3) | 共通 | 工程 2・3 | R1〜R8 |
| 課題 2 | 確定した設計どおりにテーブルを作り、サンプルデータを入れる | A | 工程 4 | R2〜R4 |
| 課題 3 | 社員詳細画面を追加し、社員の基本情報を表示する | A | 工程 4 | R6 |
| 課題 4 | 社員詳細画面に、その社員の保有資格一覧を表示する | A | 工程 4 | R1・R6 |
| 課題 5 | 社員詳細画面から資格を追加する | B | 工程 4 | R3・R4・R7 |
| 課題 6 | 社員詳細画面から保有資格を削除する | B | 工程 4 | R8 |
| 課題 7 | 同じ社員に同じ資格を重複登録できないようにする | C | 工程 4 | R5 |
課題 1 の ER 図は、3 つのテーブルの関係が分かれば十分です。 クラス図は、厳密な UML でなくて構いません。
工程表(進行の目安)
Section titled “工程表(進行の目安)”進行の 目安 です(本来は自分たちで立てる工程ですが、今回は目安を示します。実際の時刻は当日の進み具合で調整してかまいません)。 作業できる時間は 各日 10:30〜12:00 / 13:00〜17:30 を想定しています。
1 日目 ― 設計〜実装の立ち上げ
| 時刻 | マイルストーン | 対応 |
|---|---|---|
| 10:30 | 開始(開発依頼書の読み合わせ) | 工程 1 |
| 11:00 | 読み合わせ完了(R1〜R8 の理解) | 工程 1 |
| 12:00 | 設計方針を決定/リリース計画.txt をサーバ登録 | 工程 1 |
| 14:00 | ER 図・DB スキーマ設計 完了 | 工程 2 |
| 15:00 | DB スキーマ 講師レビュー通過・最終スキーマと比較して実装設計を確定 | 工程 2→3 |
| 16:00 | クラス設計 完了 → 実装開始 | 工程 3→4 |
| 17:30 | 実テーブル作成・Model 実装・Repository 枠組み／当日の進捗をサーバへ提出 | 工程 4 |
2 日目 ― 実装メイン
| 時刻 | マイルストーン | 対応 |
|---|---|---|
| 11:00 | 状況確認・リリース範囲(狙うレベル)の確認 | 工程 4 |
| 14:00 | レベル A 実装完了(保有資格の一覧表示) | 工程 4 / A |
| 16:00 | レベル B 実装完了(追加・削除) | 工程 4 / B |
| 17:30 | レベル C・発展に着手(余裕があれば)/ 翌日午後に最終調整／当日の進捗をサーバへ提出 | 工程 4 / C |
3 日目(午前は作業なし／13:00〜)― 仕上げ・納品・発表
| 時刻 | マイルストーン | 対応 |
|---|---|---|
| 13:00 | 実装再開(最終仕上げ・遅れの取り戻し・レベル C / 発展) | 工程 4 |
| 14:30 | フィーチャーフリーズ | 工程 4→5 |
| 15:00 | 受け入れ確認 → リリース・納品 | 工程 5→6 |
| 15:00〜 | ミニ発表会 | 工程 7 |
各日の終わりに進捗を提出
1 日目・2 日目の作業終了時(17:30 目安)に、その時点の進捗一式をサーバへ提出 してください。 提出するもの:
MvcEmployeeAppプロジェクト と、設計資料・リリース計画.txt・スキーマ比較メモなどのドキュメント類。 これは 中間バックアップと進捗確認 のための提出で、最終的なリリース(納品)は 3 日目です。 提出方法は工程 6「リリース」と同じ(Git、または講師の指示でサーバへフォルダコピー＋提出メモ.txt)。
工程 1 要件定義の理解(チーム)
Section titled “工程 1 要件定義の理解(チーム)”この工程のゴール
要件 R1〜R8 の意味をチーム全員が説明でき、
リリース計画.txt(どこまで納めるかの見積もり)を作ってコミットした状態。
まず、開発の依頼書(要求仕様書) を読み、何を求められているのか を正しくつかみます。 実務では、こうした依頼書を受け取って開発を始めます。依頼元が何に困っていて、何を求めているか を読み取りましょう。
開発依頼書(要求仕様書)
Section titled “開発依頼書(要求仕様書)”読み方
これは、ある部署から情報システム部門に届いた 開発依頼書 という想定です。 「依頼を受けた開発担当者」になったつもりで読んでください。
社内システム開発依頼書
| 項目 | 内容 |
|---|---|
| 文書番号 | REQ-0042 |
| 発行元 | 人事部 |
| 宛先 | 情報システム部 開発担当 各位 |
| 件名 | 社員管理システムへの「保有資格管理機能」追加のご依頼 |
| 確認窓口 | 講師・サブ講師(本演習における依頼元の窓口) |
| 希望時期 | 別途調整。着手時に「リリース計画」で見積もること |
いつもお世話になっております。人事部です。 現在運用中の 社員管理システム について、下記のとおり機能追加をお願いいたします。 ご不明点や仕様の確認は、確認窓口までお問い合わせください。
背景(なぜ必要か)
Section titled “背景(なぜ必要か)”現在の社員管理システムでは、社員の基本情報を管理できます。 しかし、社員がどのような資格を保有しているかは管理できません。
配属や教育計画、資格取得状況の把握に利用したいため、 社員ごとに保有資格を確認・登録できる機能を追加してほしい、というのが今回の依頼です。
次の要求を満たしてください。管理しやすいように番号(R1〜R8)を振っています。
| 要件番号 | 要求内容 |
|---|---|
| R1 | 社員ごとに保有資格を確認できること |
| R2 | 資格には「資格名」「実施団体」「分野」「レベル」を持たせること |
| R3 | 社員が資格を取得した日付を記録できること |
| R4 | 証書番号(認定番号)がある資格については、その番号を記録できること |
| R5 | 同じ社員に同じ資格を重複登録できないこと |
| R6 | 社員詳細画面から、その社員の保有資格を確認できること |
| R7 | 社員詳細画面から、資格を追加できること |
| R8 | 誤って登録した保有資格を削除できること |
依頼元からの補足:
- 資格の一覧(資格マスタ)の初期データは、SQL で事前登録してよい
- 資格マスタ自体の管理画面(資格の追加・編集)は 必須ではない
扱う資格の例(業務イメージ)
Section titled “扱う資格の例(業務イメージ)”要求 R2 で持たせる項目のイメージです。 これは「どんなデータを扱うか」の例であり、テーブルの作り方を示すものではありません。
| 資格名 | 実施団体 | 分野 | レベル |
|---|---|---|---|
| Oracle Master Silver SQL | Oracle | Database | Silver |
| 基本情報技術者試験 | IPA | 国家資格 | (なし) |
| Azure Fundamentals | Microsoft | Cloud | Fundamentals |
| Java Silver | Oracle | Programming | Silver |
参考:希望する画面イメージ
Section titled “参考:希望する画面イメージ”本依頼では、希望する画面のイメージを下記に示します。レイアウトはこのイメージに沿って作成してください。 ここでは どう作るか ではなく 何が見えるべきか を示します。
社員一覧画面(既存に 1 つ追加)
Section titled “社員一覧画面(既存に 1 つ追加)”既存の社員一覧に、社員ごとの 「詳細」 への入り口を 1 つ足します。
社員一覧
社員ID 氏名 部署 … 操作1001 山田 二郎 総務 … [詳細] [編集] [削除][詳細] を選ぶと、その社員の 社員詳細画面 に移動します。
社員詳細画面(新規)
Section titled “社員詳細画面(新規)”社員の基本情報と、保有資格の一覧、資格を追加するフォームを表示します。
社員詳細
社員ID：1001氏名：山田 二郎部署：総務… 基本情報 …
保有資格一覧 資格名・実施団体・分野・レベルに、取得日・証書番号などを添えて並べる / [削除] …(この社員が持っている資格を並べる)…
資格を追加 資格：[ 選択 ▼ ] 取得日：[ ] 証書番号：[ ] [追加]画面はこの依頼書のイメージどおりに作れば OK です。だから、設計の力は「どんなテーブルが必要か(データ設計)」に集中 しましょう。
ヒント
「保有資格一覧」に資格名や実施団体を表示するには、 社員の保有資格と、資格そのものの情報を 結びつけて 取り出す必要があります。 どの SQL を使えばよいか、第 28〜29 章で社員と部署を結びつけたときを思い出しましょう。 この「結びつけ」が必要になること自体が、テーブル設計のヒント にもなります。
リリース計画を立てる
Section titled “リリース計画を立てる”要求を理解したら、実装に入る前に リリース計画.txt を作ります
(書く内容は、上の「実務を意識した進め方 → 先に『リリース計画』を立てる」を参照)。
このとき、自分が狙うレベル(A / B / C) と、どの要件まで納めるかを、チームで現実的に見積もってください
(レベルの定義は、冒頭の 「進め方の全体像 → 対応レベル」 を参照)。
上司レビュー(合格の目安)
- 要求(R1〜R8)を正しく理解している
- 狙うレベルを決め、
リリース計画.txtの見積もりが現実的である合格したら 工程 2「設計」 へ進みます。
工程 2 設計(チーム)★最重要
Section titled “工程 2 設計(チーム)★最重要”この工程のゴール
社員と資格の 多対多 を 中間テーブル で表す設計ができ、重複防止(R5)を DB 制約 で実現する方針を含めた データ設計(ER 図・テーブル設計案)をチームで用意した状態(クラス設計は工程 3 で行います)。
ここからは、要件を満たすために どんなテーブルが必要か を自分(チーム)で考えます(画面は工程 1 で支給済みなので、設計の力はデータ=テーブルに集中 してください)。 答えは載せません。 考えるための観点とヒントだけを示します。
設計の出発点:社員と資格の関係
Section titled “設計の出発点:社員と資格の関係”1 人の社員は、複数の資格を持つことがあります。 また、1 つの資格を、複数の社員が持つこともあります。
社員A → Oracle Master Silver SQL、基本情報技術者試験 を持っている社員B → Oracle Master Silver SQL、Java Silver を持っている社員C → 基本情報技術者試験 を持っているこのように、社員と資格は 多対多 の関係になります。
社員(employees) 資格 多 ←─────→ 多ヒント:多対多は 1 つの列では表せない
「社員テーブルに資格 ID の列を 1 つ足す」だけでは、 1 人の社員に資格を 1 つしか登録できません。 列を
資格ID1資格ID2資格ID3…と増やす方法も、 資格が増えると足りなくなり、空欄だらけになって検索・集計もしにくくなります。多対多を扱うときの定石は何だったか、SQL 研修や第 16 章を思い出してみましょう。
設計検討:自分(チーム)で決めること
Section titled “設計検討:自分(チーム)で決めること”上司レビュー(工程 2)までに、次を考えてください。
- 必要なテーブルは何か
- それぞれのテーブルに、どんな列が必要か
- 各テーブルの 主キー は何か
- 外部キー はどこに必要か
- 「資格を取得した日付(R3)」は、どのテーブルに置くべきか
- 「証書番号(R4)」は、どのテーブルに置くべきか(同じ資格でも人ごとに違う番号、という点に注目)
- 「同じ社員に同じ資格を二重登録させない(R5)」を、DB の仕組みでどう実現するか
ヒント:R5(重複させない)は、アプリだけで守らない
「追加する前にプログラムでチェックする」だけでなく、 DB 側の制約でも二重登録を防ぐ ことを考えてみましょう。 どんな制約が使えたか、第 16 章のテーブル定義を振り返ってみてください。
チームで作る設計成果物
Section titled “チームで作る設計成果物”上司レビューまでに、次を用意します。完璧な正解でなくて構いません。
- ER 図(テーブルどうしの関係)
- テーブル設計案(テーブル名・列・主キー・外部キー)
この工程は データ設計(テーブル)に集中 します。クラスの設計は、テーブルが確定する工程 3 で 行います(クラスはテーブルに合わせて作るため、先にスキーマを固めるほうが効率的です)。 (画面は工程 1 で支給済みのため、画面の設計は不要です。支給した画面に どのデータが必要になるか を考えるのに使ってください。)
上司レビュー(合格の目安)★最重要
- ER 図・テーブル設計が 多対多 + 中間テーブル になっている
- 重複防止(R5)を DB 制約で 考えている
合格したら 工程 3「仕様確定」 へ進みます。 この設計レビューが最重要です。土台が崩れたまま実装すると手戻りが大きくなります。
工程 3 仕様確定とクラス設計(チーム)
Section titled “工程 3 仕様確定とクラス設計(チーム)”この工程のゴール
講師が用意した 最終スキーマ と自チームの設計を比較し、実装に使う設計を確定(基本は最終スキーマに合わせる。どうしても自設計で進めたいチームはそのままでも可)して、その設計をもとに 実装するクラスの設計(クラス図・クラス設計メモ) を用意した状態。
この工程は 2 つの作業からなります。
1. 最終スキーマと比べて、使う設計を確定する
Section titled “1. 最終スキーマと比べて、使う設計を確定する”工程 2 で自分たちのテーブル設計を考えたら、工程 3 で講師から 最終スキーマ(比較用の参考の正解例) が提示されます。 いきなり写し取るのではなく、次の順で進めてください。
- 比べる:自分たちが設計したスキーマと、最終スキーマを 見比べる
- まとめる:違いを書き出す(例:「中間テーブルの主キーの持たせ方が違った」「証書番号を資格マスタ側に置いてしまっていた」「UNIQUE 制約のかけ方が違った」など)。なぜ違ったか も一言添えると学びになります。これを スキーマ比較メモ として残します
- 決める:比べた結果をもとに、実装に使う設計を確定 します
基本は最終スキーマ。ただし、どうしても自分たちの設計で進めたいチームは OK
基本は、最終スキーマに合わせて実装することをおすすめします (第 28〜30 章や付録 O の名前と揃い、相談や見直しがしやすいためです)。 ただし、どうしても自分たちの設計で進めたい というチームは、それでもかまいません。 工程 2 の上司レビュー(多対多＋中間テーブル＋重複防止 R5)を通った設計であれば、 最終スキーマに無理に合わせず、自分たちの設計のまま実装してよい です(その考えは否定しません)。 どちらにする場合でも、比べて違いを
スキーマ比較メモに書き出す ところまでは必ず行ってください。※ 自分たちの設計のまま進める場合は、以降の実装(テーブル名・列名・クラス名)も その設計に合わせて 読み替えてください。第 28〜30 章や付録 O の名前は 目安 です。
なぜ自分の設計と比べるのか
設計を自分で考えることが学びの中心です。自分の設計と「答えに近い最終スキーマ」の差を自分で見つける ことが、 いちばん力になります。今回は工程 2 を通った設計をそのまま活かしてよいので、 工程 2 の設計には「自分たちのアプリの土台になる」という本当の意味があります(写すためだけの設計ではありません)。
2. クラスを設計する(クラス図・クラス設計メモ)
Section titled “2. クラスを設計する(クラス図・クラス設計メモ)”テーブル構成が確定したら、それをもとに どんなクラスを作るか を設計します (クラスはテーブルに合わせて作るので、スキーマが固まってから設計するのが効率的です)。
この工程はとても大切です(設計したメソッドは「チーム共通の約束」)
工程 4 の実装は個人作業ですが、チーム全員が、ここで設計した同じクラス・同じメソッド を作ります。 どのメソッドまで作るかは狙う対応レベル(A / B / C)で変わりますが、作るメソッドの形(名前・引数・戻り値の型)はチームでそろえます。 つまり、ここで決めたメソッドの形は、チーム全員が従う「約束」 です。
だからこそ、メソッドの 引数と戻り値の型 まで、この工程でしっかり詰めておきましょう。 もし実装中に「あれ? このメソッド、引数が足りない」「戻り値の型が合わない」と気づいたら、 それは 自分だけでなく、同じ設計で実装しているチーム全員に起きている問題 です。 自分の手元だけでこっそり直さず、チームに共有してクラス設計メモを直してください。 1 人が見つけた設計のほころびを直せば、全員の手戻りを防げます。
クラス図でも、箇条書きの「クラス設計メモ」でもかまいません。 次が分かる形にしてください。
- クラス名(と役割。Model / ViewModel / Repository / Controller のどれか)
- プロパティ名(と型)
- メソッド名(と 戻り値の型・引数の型)
第 28〜30 章の作り方にならって、最低限つぎのクラスを設計します。
- Model(資格・保有資格を表すクラス):持つプロパティ
- ViewModel(社員詳細画面に渡す入れ物):画面に必要なデータをまとめる
- Repository(DB アクセス):必要なメソッド(一覧取得・追加・削除 など)
- Controller(アクション):どの URL でどの処理を呼ぶか
クラス設計メモの 書き方の例(中身ではなく形式の見本。第 30 章の EmployeeRepository を例に):
クラス名:EmployeeRepository(Repository / DBアクセス) メソッド: - GetAll() : List<Employee> - GetById(int id) : Employee - Insert(Employee emp) : int … 影響行数や採番IDを返す - Delete(int id) : intヒント
厳密な UML でなくて構いません。上の例のように 「クラス名 → プロパティ(型)→ メソッド(戻り値型・引数型)」 が読み取れれば十分です。 迷ったら、第 28〜30 章の
Employee/EmployeeRepository/EmployeeSearchViewModel/EmployeesControllerがどう分かれていたかを思い出しましょう。
上司レビュー(合格の目安)
- 自チームの設計と最終スキーマを比較し、違いを スキーマ比較メモ にまとめ、実装に使う設計を確定した(基本は最終スキーマに合わせる。どうしても自設計で進めたいチームはそのままでも可)
- 確定した設計に対応する クラス設計(クラス名・プロパティ〔型〕・メソッド〔戻り値型・引数型〕、各層の役割) ができた
合格したら 工程 4「実装」 へ進みます(ここから個人作業です)。
工程 4 実装(個人)
Section titled “工程 4 実装(個人)”この工程のゴール
確定した設計どおりにテーブルとクラスを作り、
リリース計画.txtで決めた範囲の機能が動く状態。
実装に使う設計が固まったら、個人で実装に入ります(相談は OK ですが、作業の役割分担は NG。全員がすべての作業を自分の手で行います → 冒頭「個人とチームの切り替え」参照)。 レベル A の核から作り、動く状態を保ったまま積み上げる と、フィーチャーフリーズの判断がしやすくなります (レベルは冒頭の「進め方の全体像 → 対応レベル」を参照)。
おすすめの順番です(各ステップで、いったん動かして確認しましょう)。レベルの目安も添えます。
- テーブルを作る(レベル A):確定した設計どおりにテーブルを作り、サンプルデータを入れ、SSMS で
SELECTして確認する - 詳細画面を出す(レベル A):社員一覧から社員詳細画面へ移動し、社員の基本情報を表示する
- 保有資格一覧を出す(レベル A):社員詳細画面に、その社員の保有資格を一覧表示する(ここまでがレベル A = 最小の核)
- 追加する(レベル B):資格を選んで追加できるようにする
- 削除する(レベル B):登録済みの保有資格を削除できるようにする(ここまでがレベル B)
- 重複を防ぐ(レベル C):同じ資格を二重登録できないようにする(ここからレベル C。さらに発展課題・独自機能へ)
どこまで実装するかは
リリース計画.txtで決めた 狙うレベル に従います。 時間が足りなければ、無理に上のレベルへ広げず、狙ったレベルまでを確実に 納めてください。
実装時の注意点
Section titled “実装時の注意点”ここは新しい話ではなく、これまでの章で学んだ 守るべきこと の再確認です。
パラメータ化クエリを使う
Section titled “パラメータ化クエリを使う”SQL に値を直接つなげないでください(SQL インジェクション対策・第 24・29 章)。 値は必ずパラメータで渡します。
削除は POST で行う
Section titled “削除は POST で行う”削除は GET ではなく POST で行います(第 25・30 章)。 URL を開いただけでデータが消える状態にしないためです。
追加・削除のあとは Redirect する
Section titled “追加・削除のあとは Redirect する”追加・削除のあとは、社員詳細画面へ Redirect します(PRG パターン・第 30 章)。 再読み込みによる二重送信を防ぐためです。
「なぜ」コメントを入れる
Section titled “「なぜ」コメントを入れる”難しい処理には、「何をしているか」だけでなく 「なぜ必要か」 をコメントします。 最低 3 か所以上、たとえば次のような観点で入れてください(第 7 章のコラム参照)。
| コメントを入れたい観点 | なぜ書くか |
|---|---|
| 中間テーブルを使っている理由 | 社員と資格が多対多だから |
| 二重登録を防ぐ仕組み | 同じ資格を 2 回登録させないため |
| 資格名などを一緒に取り出している箇所 | 一覧に表示するために必要だから |
| 未入力の値を DB にどう保存するか | 取得日・証書番号は空のことがあるため |
| 削除で対象を 1 件に限定している箇所 | 誤って全件消さないため |
| 追加・削除後の Redirect | 再読み込みによる二重送信を防ぐため |
上司レビュー(軽いゲート)
- 確定した設計どおりにテーブル・クラスを作り始めている
工程 4 からは個人作業です。ここを通ったら、受け入れ確認・リリースまで 自分のペースで 進めて構いません (個人ごとに上司レビューを待つ必要はありません。困ったら相談してください)。次は 工程 5「受け入れ確認」 です。
工程 5 受け入れ確認(個人)
Section titled “工程 5 受け入れ確認(個人)”この工程のゴール
自分が 狙ったレベル(A / B / C) の要件を満たして動くことを、チェックリストで確認した状態。
提出前に、狙ったレベルまでの要件を満たしているか を確認します。 これは実務でいう「受け入れテスト」です。自分の狙ったレベルの行まで ○ が付けば、そのレベルは達成 です。
| No | 確認内容 | レベル | 対応する要件 | 結果 |
|---|---|---|---|---|
| 1 | 社員一覧から詳細画面へ移動できる | A | R6 | |
| 2 | 社員詳細画面に社員の基本情報が表示される | A | R6 | |
| 3 | 保有資格一覧が表示される | A | R1 | |
| 4 | 資格を追加できる | B | R7 | |
| 5 | 取得日・証書番号を記録できる | B | R3・R4 | |
| 6 | 追加後、社員詳細画面に戻る | B | R7 | |
| 7 | 追加した資格が一覧に表示される | B | R1 | |
| 8 | 資格を削除できる | B | R8 | |
| 9 | 削除後、社員詳細画面に戻り、一覧から消える | B | R8 | |
| 10 | 同じ資格を二重登録できない | C | R5 | |
| 11 | SQL に値を直接つなげていない(パラメータを使っている) | 共通 | ― | |
| 12 | 削除 SQL で対象を 1 件に限定している | 共通 | ― | |
| 13 | 「なぜ」コメントが 3 か所以上ある | 共通 | ― |
「共通」(No.11〜13)は どのレベルでも守ってほしい 安全・品質の項目です。 すべてに ○ が付かなくても構いません。どこまで満たせたかを正直に書く ことが、リリースの一部です。
上司レビュー(合格の目安)
- 狙ったレベルの要件を満たして動く(満たせない項目は、何が残っているかを正直に書けている)
確認できたら 工程 6「リリース(提出)」 へ進みます。
工程 6 リリース(提出)(個人)
Section titled “工程 6 リリース(提出)(個人)”この工程のゴール
狙ったレベルが動く状態で、ソース・
リリース計画.txt・設計資料・受け入れ結果を提出(リリース=納品)した状態。ここが演習の到達点(納品) です。
提出は リリース として行います。提出するものは次のとおりです。
- Git に提出したソースコード
リリース計画.txt(対応した要件番号・外した機能・最終的にどこまで納めたか)- 設計資料(ER 図・スキーマ比較メモ・簡易クラス図)
- 受け入れ確認の結果(工程 5 のチェックリスト)
- 「なぜ」コメントを入れた箇所の説明
Git が使えないときは、講師の指示でサーバへ
MvcEmployeeAppフォルダをコピーし、 提出先に提出メモ.txt(リリース計画.txtの内容＋詰まった点)を置いて代替します(第 23 章の方式)。
上司レビュー(合格の目安)
- リリースした(狙ったレベルが動く。間に合わなかった機能は
リリース計画.txtに書けている)実装・リリースはここで区切りです。ミニ発表は工程 7(リリースの後)で行います。
工程 7 ミニ発表(リリース後)(個人)
Section titled “工程 7 ミニ発表(リリース後)(個人)”この工程のゴール
リリースした内容について、設計と実装を自分の言葉で説明できた状態。
ミニ発表は、リリース(納品)の後 に行います(本演習では最終日の午後。日程は講師の指示に従ってください)。 1 人 3 分程度で、次を説明してください。
- 作った機能(どの要件まで納めたか)
- 設計で工夫した点(特に中間テーブルを使う理由)
- リリース計画と、実際に出すものをどう決めたか(外した機能があればその理由)
- 実装で苦労したところ
- 入れた「なぜ」コメントの例
- 発展課題に取り組んだ場合は、その内容
上司レビュー(完了)
- 設計と実装を、自分の言葉で説明できた
これで最終演習は完了です。おつかれさまでした。
発展課題(任意・レベル C)
Section titled “発展課題(任意・レベル C)”レベル C まで達した人(要求仕様 R1〜R8 を満たせた人)向けの、上積みの課題です。
取り組むときは リリース計画.txt に追記してください。
- 発展 1:資格を追加・削除したときに完了メッセージを表示する(→ 付録 M を参照)
- 発展 2:証書番号が未登録(空)の保有を、一覧で強調表示する(登録漏れチェック)
- 発展 3:資格名で検索する
- 発展 4:資格別に、その資格を持つ社員一覧を表示する
- 発展 5:資格マスタの一覧・登録・編集・削除を作る
- 発展 6:Repository を DI で受け取る形にする(→ 付録 N を参照。本体を壊さないよう、付録 N の手順に従いコピーで行う)
- 発展 7(デザイン):Bootstrap で画面の見た目を ごく簡単に 整える(
table/btn/form-control/alertなどのクラスを少し足すだけ。凝らなくてよい → 付録 K「最低限の HTML」K-5)。仕様(機能)が先、デザインは後
独自機能の追加も OK
要求仕様(R1〜R8)を満たしたうえでなら、上の一覧にない 自分で考えた独自機能 を追加してもかまいません (例:資格の分野別の集計、取得状況のサマリー、レベル別の絞り込みなど)。 仕様充足が最優先 なので、独自機能で仕様がおろそかにならないよう、着手前に
リリース計画.txtに追記しましょう。
評価の最優先は 要件充足 です。
| 観点 | 評価内容 |
|---|---|
| 要件充足(最優先) | 狙ったレベル(A / B / C)の要件をどこまで満たし、動かせているか |
| 設計理解 | 多対多と中間テーブルの必要性を説明できる |
| ER 図 | テーブル間の関係が表現されている |
| クラス設計 | Model / Repository / Controller / ViewModel の役割が整理されている |
| SQL・安全性 | パラメータ化・POST 削除・重複防止ができている |
| MVC 理解 | Controller / View / ViewModel の役割が崩れていない |
| 納期・リリース運用 | リリース計画を立て、納期に合わせて出すものを決められた |
| 説明力 | ミニ発表で設計と実装を説明できる |
この最終演習では、開発依頼書(要求仕様書)を読み、自分で設計し、 既存の社員管理アプリに保有資格管理機能を追加しました。
これまでの章は手順に沿って作ってきましたが、 実務では 要件を読み、設計し、納期に合わせて出すものを決める ことが求められます。
特に大切なのは、次の点です。
評価の最優先は「要件を満たして動くこと」社員と資格は多対多 → 中間テーブルで表す重複防止は、アプリだけでなく DB の制約でも守る画面に必要な複数のデータは ViewModel にまとめるDB 処理は Repository に分ける追加・削除のあとは Redirect して二重送信を防ぐ間に合わない機能は外し、動くものを確実に納めるこの演習は、C# / SQL / DB 設計 / MVC / Repository / ViewModel を組み合わせた総合演習です。 完成したアプリをもとに、自分がどう設計し、どう実装し、どこまで納めたか を説明できるようにしてください。