システム開発2年の第33週は、システム設計の出発点となる要求定義に取り組みました。
ここでいう要求定義は、機能を考え始める前に、誰が何に困り、何を達成したいのかを整理する作業です。
今回は、関係者の洗い出しから優先順位付けまでを班で進めました。
題材は、学校の図書館システムの改良や部活動の予約アプリです。
目的から設計を始める
田中先生：「どんなにコードが上手でも、解くべき問題が曖昧だと良いシステムにはなりません。まずはユーザーと利害関係者（ステークホルダー）を想定して、『何を達成したいか』を言葉で固めましょう。」
先生は、「誰が」「何を」「なぜ」「いつ」「どのくらい」という問いを黒板に並べました。
この問いに順番に答えると、作り手の思いつきではなく、利用者の目的を起点に要求を整理できます。
授業で進めた要求定義の流れ
| 段階 | 確かめる問い | 作成したもの |
|---|---|---|
| 関係者の整理 | 誰が利用し、誰が運用に関わるか | ステークホルダーマップ |
| 要望の整理 | 誰が、何のために何をしたいか | ユーザーストーリー |
| 完了条件の整理 | 何ができれば完成と判断できるか | 受け入れ条件 |
| 利用場面の整理 | どのような状況で困っているか | ペルソナ |
| 優先順位の整理 | 今回の範囲で何を先に作るか | MoSCoW法による分類 |
ステークホルダーマップで関係者を洗い出す
ステークホルダーは、システムを利用する人だけでなく、その運用や判断に関わる人や組織も含む関係者です。
班ごとに題材を選び、関係する人をステークホルダーマップへ書き出しました。
- 生徒A：「利用するのは生徒だけど、先生や図書委員も関わるんだね」
- 生徒B：「管理者は更新や承認の手間が無いか気にするはず」
図書館システムを例にすると、生徒は本を探す立場、図書委員は貸出状況を確認する立場、管理者は情報を更新する立場です。
同じシステムでも立場によって求めることが異なるため、先に関係者を並べると、要望の違いや優先順位を話し合いやすくなります。
ユーザーストーリーで目的を一文にする
ユーザーストーリーは、利用者の立場、望む行動、その目的を短い一文にしたものです。
授業では次の形を使いました。
「私は（誰として）〜したい。そうすれば〜できる。」
授業で扱った例
- 「私は図書委員として、貸出状況を一目で確認したい。そうすれば返却遅れの通知を早く出せる。」
- 「私は新入生として、人気本の在庫を簡単に調べたい。そうすれば借りたい本を見つけやすい。」
生徒Cからは「この形式だと、何のためにその機能がいるかがクリアになる」という声がありました。
「在庫検索を作る」だけで終わらず、誰のどの行動を助ける機能なのかまで書く点が、この形式の狙いです。
受け入れ条件で完成の判断をそろえる
受け入れ条件は、ユーザーストーリーを満たしたと判断するための具体的な条件です。
曖昧な「使いやすくする」を、実際に確認できる状態へ置き換えます。
図書館システムの例
- 検索欄にタイトルの一部を入力すると、該当する本が10件以内で表示される。
- 在庫が0の本は、色だけに頼らず「貸出不可」と文字で表示される。
- 管理者はCSV形式で貸出履歴をダウンロードできる。
生徒Dは「条件を書くと、テスト項目も同時に見えてくる」と気づきました。
たとえば「貸出不可」と表示されることを条件にすれば、実装後に表示の有無を確認できます。
インタビューとペルソナで利用場面を具体化する
次の実習では、班の一人が利用者役、もう一人が聞き手となり、仮想インタビューを行いました。
要望だけでなく、一日の行動や困っている場面を質問し、その内容をペルソナとして一枚に整理しました。
- 年齢
- 役割
- 一日の行動
- 困っていること
- 望む改善
ペルソナは、班が想定する代表的な利用者像です。
生徒Eからは「ペルソナを作ると、仕様の優先順位が決めやすい」という感想が出ました。
MoSCoW法で今回の開発範囲を決める
最後に、班で挙げた要望をMoSCoW法で分類しました。
授業では、Must、Should、Could、Won’tの四つに分け、必ず必要な機能と後回しにできる機能を整理しました。
- Must：今回、必ず必要なもの
- Should：できれば今回対応したいもの
- Could：余裕があれば対応するもの
- Won’t：今回は対応しないもの
生徒Fは「全部やりたくなるけど、優先度を決めるのがプロジェクト成功の鍵だと分かった」と振り返りました。
やりたいことを削るための分類ではなく、限られた範囲で何から形にするかを班で合意するための作業です。
次回へ持ち越す成果物
先生は、要求定義を「設計の地図作り」と表現しました。
今回まとめた目的と条件は、次回のUML設計やデータ設計で、何を図に表すべきかを考える土台になります。
宿題
- 各班のステークホルダーマップ、ユーザーストーリー3件、受け入れ条件3項目を文書にして提出する。
- 自分が考えるペルソナ1人のプロフィールをA4一枚程度にまとめる。
- 代表者は、班の要求定義を2分で説明できるよう準備する。
次週は、今回固めた要求をもとに、クラス図でシステムの構造を、シーケンス図で処理の流れを表します。
続きは第34週のUML設計の授業レポートで紹介しています。
第33週の学び
今回の授業では、関係者を挙げ、目的を一文にし、完成条件と優先順位を決めるところまで進みました。
作り始める前に「誰の何を解決するか」を共有することが、設計へ進むための準備になります。
この記事に関連する株式会社greedenの取り組み
株式会社greedenは、課題や目的の整理から要件定義、設計、実装、運用まで、Webシステム開発を一気通貫で支援します。
授業で学んだ「誰の何を解決するか」を、現場で使える仕様へつなげたいときにご相談ください。