要件定義とは？Webアプリの具体例で学ぶ、要求の整理と要件の書き方
「学習記録を登録できるアプリを作ってほしい」と言われたとき、そのままコードを書き始めると、何分まで登録できるのか、誰の記録を表示するのか、といった判断で手が止まります。こうした決め事を依頼者や利用者と確認し、「何ができれば完成と言えるか」をそろえるのが要件定義です。
要件定義書の見出しだけを埋めても、判断が曖昧なままでは実装に進めません。この記事では、依頼内容 → 確認する質問 → 合意した要件 → 確認方法を、学習記録アプリの具体例でつなげます。書き方の見本として、機能一覧と1機能分の詳しい記入例も示します。
本記事は、Schoo「Java入門 中級」第9回「Webアプリケーション設計演習」を学んだあとに理解を深めるステップアップ学習記事です。受講や配布ファイルを前提とせず、初めてWebアプリの要件を整理する方にも読めるように説明します。今回はプログラムの実装ではなく、作る内容の決め方を扱います。
要件定義とは、「何ができればよいか」を関係者でそろえること
| 段階 | 学習記録アプリでの例 |
|---|---|
| 要求：実現したいこと | 学んだことをあとから振り返れるようにしたい。 |
| 要件：満たすべき条件 | ログインした利用者が学習内容と時間を登録し、自分の記録だけを一覧で確認できる。 |
| 設計：実現する方法 | 登録を受け付けるServlet、判断を行うModel、保存するテーブルなどを具体化する。 |
ここでは、希望として出てきた内容を「要求」、確認して合意した条件を「要件」と呼び分けます。現場によって用語や文書の分け方は異なりますが、誰かの希望、未確認の仮定、合意した条件を混ぜないことが重要です。
要件定義は、開発者が一人で正解を決める作業ではありません。利用者が仕事や学習で困っていることを聞き、実現できる範囲や費用・期間も考慮して合意します。画面案を先に描き、話し合いながら要件へ戻って修正する進め方もできます。
「Servletを3個作る」は作り方の案ですが、それだけでは利用者が何をできるのか分かりません。一方、既存のシステムと接続するためにJavaを使う、といった技術上の制約が最初から決まっている場合は、その前提も要件と一緒に記録します。
例題：「学習記録を残したい」という依頼を受けたら
学習した内容と時間を記録できるWebアプリがほしいです。ログインして記録を登録し、自分の記録を一覧で振り返れるようにしたいです。他の人の記録は見せたくありません。
この依頼から「登録」「一覧」「ログイン」は読み取れます。ただし、入力項目、時間の単位や上限、記録がない場合の表示などは、まだ決まっていません。「普通はこうだろう」で埋めると、依頼者と違うものを作ってしまいます。
以下は、依頼者との確認を済ませたという想定の記事用の記入例です。学習時間の1〜480分という範囲は授業資料に沿っていますが、文字数の上限・日付の扱い・一覧の並び順などは説明のために追加した条件です。どのアプリにも同じ数値を使う、という意味ではありません。入力例は2026年9月28日の操作を想定します。
1．目的と「今回は作らないもの」を先に確認する
| 確認項目 | 合意した内容の例 |
|---|---|
| 目的 | 利用者が、いつ・何を・何分学んだかを、自分で振り返れるようにする。 |
| 利用者 | 管理担当者が事前登録した利用者。記録の閲覧・登録にはログインが必要。 |
| 今回の対象 | ログイン、自分の記録一覧、学習記録の登録、入力エラーの案内、ログアウト。 |
| 今回の対象外 | 利用者自身による新規会員登録、記録の編集・削除、他者への共有、集計グラフ。 |
| 前提 | 登録情報はDBに保存する。初期の利用者情報は管理担当者が用意する。 |
対象外を書くのは、便利な機能を否定するためではありません。「今回は登録と一覧を完成させ、編集は次に検討する」と範囲を合わせるためです。なお、機能を対象外にすることと、必要な安全対策を省くことは別です。
2．依頼の曖昧な言葉を、答えられる質問に変える
| 依頼から作る質問 | 回答として確認した内容の例 |
|---|---|
| 「記録する」：何を入力しますか？ | 学習日、カテゴリ、学習内容、学習時間、メモ。メモ以外は必須。 |
| 「時間」：単位と範囲は？ | 分単位。1回の記録は1〜480の整数。0分や小数は受け付けない。 |
| 「自分の記録」：誰の情報で判断しますか？ | ログインしている利用者の記録だけ。他の利用者を指定して登録・閲覧する機能は付けない。 |
| 「一覧」：順番と表示項目は？ | 学習日の新しい順。同じ学習日なら登録の新しい順。学習日・カテゴリ・内容・時間・メモを表示する。 |
| 何も登録していなかったら？ | 「学習記録はまだありません」と表示し、登録画面へ進める。 |
| 入力を間違えたら？ | 項目と理由をエラー画面で知らせ、1件も保存しない。登録画面へ戻って入力し直せる。 |
| あとから直せますか？ | 今回、編集・削除は扱わない。誤登録の修正は次の改善候補として残す。 |
たとえば「エラー処理をする」だけでは、エラー画面を出しつつDBには保存してしまう実装も、文章上は否定できません。表示することだけでなく、保存しないことまで確認しておきます。
図解：画面案を見ながら質問し、決まった条件を書き残す
入力欄を描くだけでも、「メモは空でよい？」「登録後はどこへ移る？」「戻ると入力は残る？」と確認できます。画面で見えた決め事は、口頭だけで終わらせず、要件の記録へ戻します。
3．要件は「誰が・どんな条件で・何をすると・どうなる」で書く
| 曖昧な書き方 | 条件と結果を具体化した書き方 |
|---|---|
| 学習記録を登録できる。 | ログイン済みの利用者が、全入力条件を満たす記録を登録すると、その利用者に紐づく記録が1件保存される。 |
| 不正な時間はエラーにする。 | 学習時間が未入力・整数でない・1〜480の範囲外のいずれかなら、理由をエラー画面に表示し、記録を保存しない。 |
| 利用者ごとに表示する。 | 一覧にはログイン中の利用者の記録だけを表示し、他の利用者の記録は含めない。 |
「分かりやすく」「適切に」「必要に応じて」のような言葉が残ったら、読んだ人が同じ判断をできるかを確認します。すべてを長文にする必要はありません。入力ルールを表へ分け、要件から参照すると整理しやすくなります。
要件定義書の書き方：まずは機能一覧を作る
次のR-01などは、要件を指し示すための記事内の番号です。必須の命名規則ではありませんが、「一覧の要件」「登録の要件」と毎回言い換えるより、設計やテストから参照しやすくなります。
| 要件ID・機能 | 満たす条件 |
|---|---|
| R-01：ログイン | 登録済みの利用者が正しい認証情報でログインできる。不一致ならログイン状態にせず、入力確認を案内する。 |
| R-02：自分の一覧 | ログイン中の利用者の記録だけを、学習日降順・同日の場合は登録の新しい順で表示する。0件なら専用の案内を表示する。 |
| R-03：登録 | 入力条件を満たす学習記録を、ログイン中の利用者に紐づけて1件保存し、登録完了画面を表示する。 |
| R-04：入力エラー | 入力条件を満たさない場合は、項目と理由をエラー画面で知らせる。記録は保存せず、登録画面へ戻れるようにする。 |
| R-05：未ログイン時 | 未ログインでは記録の閲覧・登録を許可しない。URLへの直接アクセスや登録リクエストでもログイン画面へ案内する。 |
| R-06：ログアウト | ログイン状態を終了し、ログイン画面を表示する。その後の記録の閲覧・登録には再ログインを必要とする。 |
この一覧は入口です。たとえばR-03の「入力条件」が未定なら、まだ登録処理を同じ理解で作れません。次に、入力条件と成功・失敗時の結果まで具体化します。
入力項目の記入例：型・単位・必須・範囲を決める
| 項目 | この記事の例で合意したルール |
|---|---|
| 学習日 | 必須。実在する日付で、操作日以前。例：2026-09-28。未来日は受け付けない。 |
| カテゴリ | 必須。「Java」「SQL」「その他」のいずれかを選択する。送信値もこの範囲か確認する。 |
| 学習内容 | 必須。1〜200文字。空文字や空白だけの入力は受け付けない。 |
| 学習時間 | 必須。分単位の整数で、1以上480以下。例：30。0、481、1.5、abcは受け付けない。 |
| メモ | 任意。500文字以内。未入力でも登録できる。一覧で空のメモは「メモはありません」と表示する。 |
| 記録の所有者 | 入力欄にしない。ログイン中の利用者に紐づける。送信された別人の利用者IDを信用しない。 |
200文字・500文字は、この記入例で設けた上限です。実際には保存先の制限や、数える文字の扱いも設計時にそろえます。また、未入力と空白だけの入力を同じ扱いにするかは、項目ごとに確認します。
ここでいう型は、利用者が入力する情報としての「日付」「整数」などです。Servletでは文字列で受け取ってから確認・変換しますが、そのコードを書く前に、受け付ける値を決めておく必要があります。
1機能分を詳しく書くと、ここまで具体化できる
記入例：R-03 学習記録の登録。入力ルールは直前の表を参照します。これは小規模なアプリ向けの書き方の一例であり、どの現場でも必須となる様式ではありません。
| 項目 | 記入例 |
|---|---|
| 目的・利用者 | ログイン済みの利用者が、その日に学んだ内容をあとから振り返れるように残す。 |
| 開始条件 | ログイン済みで、登録画面を開いていること。 |
| 入力 | 学習日、カテゴリ、学習内容、学習時間、任意のメモ。前掲の入力ルールを満たすこと。 |
| きっかけ | 登録画面で「登録」を選ぶ。 |
| 成功時 | 入力した記録を、ログイン中の利用者に紐づけて1件保存する。保存に成功してから登録完了画面を表示する。 |
| 次の操作 | 完了画面の「一覧へ」で自分の一覧へ移動できる。新しい記録が決められた並び順で確認できる。 |
| 入力不備 | R-04に従い、項目と理由をエラー画面に表示する。保存はしない。戻り先は登録画面とする。 |
| 入力の保持 | 今回の版では、エラー画面から戻った登録画面の入力欄は空にする。この操作性を依頼者へ示して合意し、入力保持は改善候補とする。 |
| 途中でログインが切れた場合 | 登録時点で未ログインならR-05を適用し、保存せずログイン画面へ案内する。 |
| 保存に失敗した場合 | 成功と表示しない。保存できなかった旨を案内し、SQLや接続情報などの内部情報は画面へ出さない。 |
| 確認例 | 田中さんでログインし、有効な学習日・Java・例外処理の復習・30分・空のメモを登録する。田中さんの記録が1件増え、一覧に同じ内容と30分が表示される。 |
「エラー時に入力を残す」は、利用者にとって便利でも、実装側が無断で追加・省略することではありません。画面案で操作を見せ、必要性と今回の範囲を確認します。この例のように空へ戻す場合も、その不便さを隠さず説明します。
登録ボタンの連打や通信切断で結果が分からない場合なども、実際の公開では整理が必要です。上の表は登録機能の記入例であって、公開用サービスの全要件を網羅したものではありません。
4．機能要件だけでなく、品質・運用の条件も確認する
機能要件は、登録・一覧表示のように「何ができるか」です。非機能要件は、性能・可用性・安全性・運用など「どのような品質や条件で使えるか」です。分類そのものより、担当者と確認方法が決まっていることが重要です。たとえば安全性の要求を、具体的なアクセス制御の機能へ落とし込むこともあります。
| 曖昧な条件 | 追加で確認し、記録する内容 |
|---|---|
| 速く表示する | 対象画面、データ件数、同時利用者数、利用環境、どこからどこまでの時間を測るか、許容時間。 |
| 安全に使える | 誰がどのデータを扱えるか、通信・認証情報の保護、ログへ残してはいけない情報、確認方法と担当。 |
| データをなくさない | 許容できるデータ損失の範囲、バックアップ頻度・保存期間、復旧担当、実際に復元できるかの確認。 |
| スマートフォンで使える | 対応する端末・ブラウザ、入力とエラー表示を確認する画面、横幅が狭いときの操作条件。 |
「一覧は2秒以内」と数値を付けるだけでも十分ではありません。10件と10万件、1人と100人では条件が違います。まだ条件を合意できない場合は、適当な数値を完成版に書かず、次の未決事項へ分けます。
5．決まっていないことは、未決事項として残す
聞いてもすぐ決まらないことはあります。「たぶん不要」を決定事項にせず、質問・判断する人・期限・影響する要件を残します。次は、実際に公開する範囲を決める前に確認する事項の例です。
| 未決事項 | 確認先・期限・影響 |
|---|---|
| Q-01：記録を何年間保存するか | 依頼者・運用担当とDB設計の確定前に確認する。データ量、削除方針、バックアップへ影響。 |
| Q-02：同時利用者数と許容表示時間 | 依頼者と性能検証の計画前に確認する。検証データと公開環境の選定へ影響。 |
| Q-03：連打や通信切断時の再送をどう扱うか | 依頼者・開発担当と登録処理の設計確定前に確認する。R-03の重複登録対策と画面案内へ影響。 |
実際の管理表では、役割名だけでなく担当者名と具体的な期限日を書きます。未決事項があるから、すべての作業を止めるとは限りません。ただし、登録回数など結果を変える条件が未決のまま、その実装やテストを確定してはいけません。
6．要件を読んで「合格かどうか」を判断できるか確かめる
要件を書いたら、代表的な入力と結果を並べます。ここで答えが決まらなければ、テスト担当へ判断を丸投げせず、要件へ戻って確認します。次は全テストケースではなく、曖昧さを見つけるための確認例です。
| 対応要件・条件 | 準備・操作・期待する結果 |
|---|---|
| R-03：30分で登録 | 他の必須項目を有効にし、メモは空で登録する。ログイン中の利用者の記録が1件増え、学習時間30分で確認できる。 |
| R-03：下限・上限 | 他の項目を有効にして1分と480分を別々に登録する。どちらも1件ずつ保存される。 |
| R-04：0分・481分 | 他の項目を有効にして、各値を別々に送る。理由が表示され、DBの件数は実行前から増えない。 |
| R-02：利用者の分離 | 田中さんと佐藤さんの記録を事前に用意する。田中さんで開いた一覧に、田中さんの記録だけが表示される。 |
| R-02：記録0件 | 記録のない利用者で開く。「学習記録はまだありません」と表示され、登録へ進める。 |
| R-05：未ログインで登録 | ログアウトした状態で登録リクエストを送る。ログイン画面へ案内され、記録が保存されない。 |
「利用者の分離」は、田中さんのデータしか入っていないDBでは見落としが起きます。他の利用者の記録も用意して、表示されないことを確認します。「エラーになる」も、表示だけでなくデータが増えていないことまで確かめます。
要件が変わったら、関連する表と確認例も更新する
たとえば「長時間の研修も記録したいので、上限を480分から720分へ変えたい」という追加要求が来たとします。まず変更理由と影響を確認し、合意したあとで、入力ルール・R-03/R-04の参照内容・画面の案内・テストを更新します。
新しい条件では481分は有効です。古い確認例を残したまま「481分はエラー」とすると、正しい実装を不合格にしてしまいます。要件IDと変更理由を残し、どの版に対する確認なのかをそろえることが、書類を作るだけで終わらせないポイントです。
なお、設計やコードを書く順番を機械的に固定する必要はありません。画面案や試作で気づいた点を要件へ戻し、関係者で再確認します。開発全体の進め方は、JavaのWebアプリは何から作る？要件から画面・処理・クラスを考える手順で扱っています。
確認問題
- 「学習時間を入力できる」とだけ書かれています。実装前に依頼者へ確認したいことを3つ挙げ、この記事の条件を使って要件の文章に書き直してください。
- 「不正な時間ならエラーを表示する」という要件で、0分を登録するとエラー画面は出ますがDBにも1件追加されました。何を書き足し、何を確認する必要がありますか。
- 「自分の記録だけを表示する」を確認するため、田中さんの記録だけを用意しました。どのようなデータを追加し、何が表示されないことを確かめますか。
- 学習時間の上限を480分から720分へ変更することになりました。更新する記録と、変更後に確認する境界付近の値・期待結果を答えてください。
- 依頼者から「一覧は速く表示してほしい」と言われました。勝手に数値を決めずに、何を質問し、決まらない場合はどのように残しますか。
演習後の確認：こちらのページを使って、自分で考えた内容を見直せます。
まとめ
- 要件定義は、依頼の希望を、関係者が合意できる具体的な条件へ整理する作業。
- 目的・対象範囲を決め、画面案と具体的なデータで曖昧な点を質問する。
- 正常時だけでなく、入力不備・未ログイン・保存失敗時の結果も書く。
- 未決事項は担当者・期限・影響とともに残し、勝手に決定事項へ変えない。
- 要件と確認例を対応させ、条件を変えたら両方を更新する。
