【授業レポート】システム開発（2年） 第39週目
〜ユースケース完成＆ミニ発表会：安定して動くシステムを「見せる」〜
第39週目は、これまで設計・実装・結合・エラーハンドリングを重ねてきた成果をまとめ、
ユースケース単位で完成したアプリを発表するミニ発表会を行いました。
テーマは「安定して動くことを証明する」。
機能の多さではなく、設計どおりに・エラーに強く・分かりやすく動くかが評価の軸です。
■ 先生の導入：「今日は“動くかどうか”ではなく“安心して使えるか”」
田中先生：「今日は新機能を足す日ではありません。
“想定どおりに動き、想定外でも壊れないか”を、他人に見せて確認する日です。」
先生は評価観点として、次の4点を提示しました。
- ユースケースの流れが明確か
- 正常系・異常系の両方を説明できているか
- エラーメッセージがユーザー視点になっているか
- ログや設計と実装の対応が取れているか
■ 実習①：最終調整タイム（30分）
発表前の最終確認として、各班は以下をチェック。
- 主要ユースケースが最初から最後まで動くか
- 異常入力（数字以外、存在しないID等）で落ちないか
- 例外時にスタックトレースがUIに出ていないか
- ログに「失敗の理由」が残っているか
生徒A：「発表直前にエラーメッセージを直したら、一気に印象が良くなった！」
■ 実習②：ミニ発表会（班ごと・5分）
各班が次の流れで発表を行いました。
発表構成（共通）
- ユースケースの説明（1分）
- 例：「図書を借りる／返す」
- デモ（2分）
- 正常系の操作
- 異常系デモ（1分）
- エラー入力や業務ルール違反時の挙動
- 工夫点の説明（1分）
- エラーハンドリング、設計上の配慮など
■ 発表の一例（図書館システム）
正常系デモ
- 本IDを入力 → 貸出成功
- UI表示：「◯◯ を貸し出しました」
異常系デモ
- 同じ本を再度借りる
- UI表示：「貸出不可：すでに貸出中です」
- ログ確認：「BookNotAvailableError / book_id=3」
先生のコメント：「
ユーザー向け表示とログの役割分担が明確で、とても実務的ですね。」
■ 相互フィードバック（ピアレビュー）
発表ごとに、他班から次の観点でコメント。
- 分かりやすかった点
- 実際に使うときに安心できる点
- もう一段良くなりそうな点
生徒B：「異常系をちゃんと見せてくれる発表は信頼感が高い」
生徒C：「ログの内容まで説明してくれたのが勉強になった」
■ 先生からの全体講評
よかった点
- 多くの班が「例外＝悪」ではなく「制御すべきもの」として扱えている
- UI・Service・DAOの役割分担が明確
- 想定外入力でもアプリが止まらない設計ができている
改善ポイント
- メッセージの表現がまだ技術寄りな部分がある
- ログの粒度（情報量）が多すぎ／少なすぎな班が混在
- ユースケース外の操作へのガードが甘い箇所あり
田中先生：「
“使う人の立場で不安がないか”を最後にもう一度見直すと、完成度が一段上がります。」
■ ふり返りワーク：自分たちのシステムを評価する
各班で以下を記入。
- 一番うまく設計できた点
- 一番苦労した点
- バグが減った決定的な工夫
- 次に改善したいポイント（設計／実装／UI）
生徒D：「最初に設計図を書いたおかげで、後半の修正が楽だった」
生徒E：「エラー処理を後回しにしなくてよかったと心から思った」
■ 先生のまとめのひとこと
「今日の発表で、皆さんは
“動くプログラム”ではなく
“安心して使えるシステム”を作れていました。
これは設計・実装・改善を順番に積み重ねてきた成果です。
次は、これを他人に引き継げる形にしていきましょう。」
■ 宿題（次回に向けて）
- 今日の発表を踏まえた 最終改善点リスト（5項目以上）
- 主要ユースケースの 最終版フロー図＋シーケンス図
- アプリ全体の README（使い方・エラー時の挙動・注意点） を作成
■ 来週の予告：ドキュメント仕上げ＆引き継ぎ設計
次週は、完成したシステムを
「他の人が使える・直せる・引き継げる」形にするためのドキュメント整備を行います。
README、設計書、運用メモをまとめ、開発を“終わらせる力”を学びます。
第39週目は、これまでの学びが一つの形になった達成感のある授業でした。
生徒たちは「動く」だけでなく「信頼される」システムを作る視点を身につけ、
次のフェーズへ自信を持って進もうとしています。