【授業レポート】システム開発（2年） 第33週目 〜要求定義入門：「誰の何を解決するか」を言葉にする〜
第33週目は、2年生として本格的に始まったシステム設計の第一歩――**要求定義（要件整理）**に取り組みました。今回は「作る前に誰の何の問題を解くのか」をチームで深掘りする実践的な回です。
■ 先生の導入：「設計は“目的”がはっきりしていることから始まる」
田中先生：「どんなにコードが上手でも、解くべき問題が曖昧だと良いシステムにはなりません。まずはユーザーと利害関係者（ステークホルダー）を想定して、『何を達成したいか』を言葉で固めましょう。」
先生は黒板に「誰が（Who）／何を（What）／なぜ（Why）／いつ（When）／どのくらい（How much）」という問いを並べ、要求定義の基本フレームを紹介しました。
■ 今日の導入ワーク：ステークホルダーマップを作る
まずの活動はステークホルダーマップ作成。班ごとにプロジェクトの対象（例：学校の図書館システム改良・部活の予約アプリなど）を選び、関係する人物や組織を洗い出しました。
- 生徒A：「利用するのは生徒だけど、先生や図書委員も関わるんだね」
- 生徒B：「管理者は更新や承認の手間が無いか気にするはず」
マップを作ることで、利害の対立や優先度が見え始め、要求の粒度を整えるヒントになりました。
■ 実習①：ユーザーストーリーで“ユーザーの望み”を書く
次に、ユーザーストーリー（短い1文形式）を用いて、ユーザー視点で機能要望を書き出しました。テンプレートはお馴染みの形式：
「私は（誰として）〜したい。そうすれば〜できる。」
例：
- 「私は図書委員として、貸出状況を一目で確認したい。そうすれば返却遅れの通知を早く出せる。」
- 「私は新入生として、人気本の在庫を簡単に調べたい。そうすれば借りたい本を見つけやすい。」
生徒C：「この形式だと、何のためにその機能がいるかがクリアになる」
■ 実習②：受け入れ条件（Acceptance Criteria）を書く
ユーザーストーリーだけでなく、受け入れ条件を明確にする練習も行いました。これは「その機能が完成と見なせる具体的な条件」です。
例（ユーザーストーリーに対する受け入れ条件）
- 検索欄にタイトルの一部を入れると、該当する本が10件以内で表示される。
- 在庫が0の本は「貸出不可」と赤で表示される。
- 管理者はCSVで貸出履歴をダウンロードできる。
生徒D：「条件を書くと、テスト項目も同時に見えてくる！」
■ 実習③：簡易インタビューとペルソナ作成
実際の要件を掘るために、仮想インタビューのロールプレイを班内で実施しました。1人がユーザー役、1人がインタビュアーとなり、ニーズや困りごとを深掘りします。その結果をもとに**ペルソナ（代表ユーザー像）**を1枚にまとめました。
- ペルソナ項目例：年齢・役割・一日の行動・困っていること・望む改善
- 生徒E：「ペルソナを作ると、仕様の優先順位が決めやすい！」
■ ワークのふり返り：機能の優先度付け（MoSCoW）
最後に、洗い出した要望を**MoSCoW法（Must / Should / Could / Won’t）**で分類。これにより「まず絶対に必要な機能」と「後回しにできる機能」がチームで合意されました。
生徒F：「全部やりたくなるけど、優先度を決めるのがプロジェクト成功の鍵だと分かった」
■ 先生のひとこと
「要求定義は設計の地図作りです。丁寧に掘れば掘るほど、後の設計や実装で迷わなくなります。今日の成果は次回のUML設計やデータ設計の基盤になりますよ。」
■ 宿題（次回に向けて）
- 各班でまとめたステークホルダーマップ・ユーザーストーリー3件・受け入れ条件3項目をドキュメント化して提出。
- 自分が考えるペルソナ1人のプロフィールをA4一枚程度で作成。
- 次回（UML設計）で発表するため、代表者は班の要求定義を2分で説明できるよう準備。
■ 来週の予告：UMLで「構造」と「振る舞い」を描く
次週は今日固めた要求をもとに**クラス図（クラスの属性・メソッド）とシーケンス図（処理の流れ）**を描く実習に入ります。要求がしっかりしているとUML設計がスムーズになります—今日の作業を大事にしてください！
ユーザーの課題を言葉にする33週目。生徒たちは「作る理由」をチームで合意する経験を通じて、設計に必要な思考の基礎をしっかり築きました。