「いい感じに作って」では作れない――学生のための要件定義入門

こんにちは黒パグです🐾

「文化祭で使うWebサイト、いい感じに作っておいて」

先生から、こんな依頼を受けたとします。

皆さんなら、何から始めるでしょうか。

パソコンを開く。デザインを探す。生成AIに相談する。とりあえずトップページを作ってみる。

どれも間違いではありません。しかし、そのまま作り始めると、かなりの確率で途中から困ります。

誰が見るサイトなのか。スマートフォンでも使うのか。掲載する企画はいくつあるのか。地図は必要なのか。公開日はいつなのか。当日の更新は誰がするのか。

何も決まっていないからです。

「いい感じ」の中身は人によって違う

「いい感じに作って」という言葉は便利です。

しかし、依頼した人の「いい感じ」と、作る人の「いい感じ」が同じとは限りません。

先生は、来場者が迷わない案内サイトを想像しているかもしれません。作る学生は、写真が大きく動く格好いいサイトを想像しているかもしれません。実行委員は、企画の変更を簡単に反映できるサイトを求めているかもしれません。

誰も嘘はついていません。

それぞれが別の完成形を想像しているだけです。

依頼書を読んだ乾亮太は、短く言いました。

「これでは、まだ作れない」

プログラミング技術が足りないからではありません。作るべきものが決まっていないからです。

ここで必要になるのが、要件定義です。

要件定義とは何か

要件定義と聞くと、難しい会議や分厚い資料を想像する人もいるでしょう。

最初は、そこまで難しく考えなくても大丈夫です。

要件定義とは、何を作るのか、なぜ必要なのか、誰が使うのか、どこまで作るのかを関係者で確認し、合意していく作業です。

もう少し実務に近い言い方をすると、全員の頭の中にある「たぶんこういうもの」を外へ出し、その違いを見つける仕事です。

条件をきれいに書くだけではありません。

曖昧な点を見つける。意見が対立している場所を見つける。必要なものと、今回は作らないものを分ける。そして、どの状態になれば完成なのかを決める。

乾は、先生へ質問を返します。

「誰が使いますか」

「その人は、何ができれば困らなくなりますか」

「公開はいつですか」

「絶対に必要な機能は何ですか」

質問された側は、少し面倒に感じるかもしれません。

しかし、作り終わってから「思っていたものと違う」と言われるより、作る前に確認したほうが安く済みます。

時間も、人手も、お金も、学生の体力も有限です。

文化祭サイトの要件を整理してみる

先生と実行委員へ確認した結果、次のことが分かりました。

サイトの目的は、文化祭へ来た人が企画の内容と場所を確認できるようにすることです。主な利用者は、生徒、保護者、一般の来場者です。スマートフォンから見る人が多いため、小さな画面でも読みやすくする必要があります。

公開期限は文化祭の一週間前。

必ず掲載するものは、企画一覧、開催時刻、校内地図、注意事項です。一方、オンライン決済、来場予約、各企画へのコメント機能は今回は作りません。

ここまで決まると、最初の「いい感じに作って」より、作るものがかなり見えるようになります。

確認したいのは、主に次の六つです。

1. 何のために作るのか
2. 誰が使うのか
3. 絶対に必要なものは何か
4. 期限、予算、環境などの制約は何か
5. どうなれば完成なのか
6. 今回は何を作らないのか

特に重要なのが、六番目です。

できそうな機能を次々に追加すると、時間も作業量も増えていきます。全部を入れようとして公開日に間に合わなければ、誰にも使ってもらえません。

乾は、提案されたコメント機能を見て言いました。

「それは本当に、今回必要？」

便利そうだから作る。技術的に面白そうだから入れる。生成AIが提案したから採用する。

それだけでは、追加する理由になりません。

「作らないこと」を決めるのも、要件定義の一部です。

要求・要件・仕様は少し違う

ここで、よく似た三つの言葉を簡単に整理します。

「来場者が校内で迷わないようにしたい」

これは、利用者や依頼者が実現したい要求です。

「スマートフォンで校内地図と企画の場所を確認できるようにする」

これは、要求を満たすために必要な要件です。

「画面下部に地図ボタンを固定し、押すと校内地図を表示する」

これは、実際にどう作るかを具体化した仕様です。

現場や組織によって、言葉の使い分けは少し異なります。それでも、「何に困っているのか」「何を満たす必要があるのか」「どう実現するのか」を分けて考える習慣は役に立ちます。

いきなり仕様から考えると、本来の目的を見失うことがあります。

高性能な検索機能を作っても、来場者が知りたいのが「体育館はどこか」だけなら、もっと簡単な方法で解決できるかもしれません。

生成AIに頼むときも同じ

生成AIへ「文化祭サイトをいい感じに作って」と頼めば、それらしいものは出てくるでしょう。

しかし、それが必要なものと一致する保証はありません。

AIは、依頼者の頭の中を読むことができません。足りない条件を推測して埋めることはありますが、その推測が正しいとは限りません。

目的、利用者、必要な機能、制約、完成条件、対象外。この六つを渡せば、AIへの指示も具体的になります。

ただし、要件定義とプロンプト作成は同じものではありません。

プロンプトは、AIへ指示を渡す方法です。要件定義は、その前に人間同士で目的や条件を確認し、何を作るべきか決める仕事です。

決まっていない要件を、長いプロンプトで隠すことはできません。

最初に全部決めれば終わり、ではない

要件定義は、一度書いたら二度と変えてはいけないものではありません。

文化祭の企画が中止になることもあります。直前に使用教室が変わることもあります。実際に画面を作ってみたら、文字が小さくて読みにくいと分かることもあります。

条件が変われば、要件も見直します。

ただし、何となく変更するのではありません。

何が変わったのか。どこへ影響するのか。期限内に対応できるのか。何かを追加する代わりに、何を後回しにするのか。

それを関係者でもう一度確認します。

要件定義は、未来を完璧に予言する作業ではありません。

変更が起きたときに、どこへ戻って話し合えばよいかを残す作業でもあります。

要件定義は、本当に学校で学ぶものなのか

要件定義は、IT企業へ入ってから覚える特殊な仕事に見えるかもしれません。

しかし、実際には高校、高専、専門学校、大学、社会人向けのデジタル教育で扱われています。

文部科学省の高等学校情報科に関する資料には、「情報システムの要求分析と定義」が学習内容として示されています。

大学では、ソフトウェア工学の講義の一部として学ぶ例があります。さらに実践型の授業では、学生が顧客から話を聞き、要求を整理し、システム化する範囲を合意し、試作品を見せて修正するところまで経験します。

IPAの社会人向け実践教育でも、企業の課題を見つけ、要求や要件を定義し、解決策を検討して検証するPBLが行われています。

要件定義は、用語を暗記するだけでは身につきにくい分野です。

曖昧な依頼を受ける。質問する。相手と自分の認識が違うことに気づく。優先順位を決める。試作品を見せて、また修正する。

その経験を通して、少しずつ理解していくものです。

明日から使える六つの質問

何かを頼まれたとき、すぐに作り始める前に、次の六つを確認してみてください。

1. 何のために作るのか
2. 誰が使うのか
3. 絶対に必要なものは何か
4. どのような制約があるのか
5. どうなれば完成なのか
6. 今回は何を作らないのか

すべてに完璧な答えが出なくても構いません。

「まだ決まっていない」と分かることにも価値があります。

分からないまま作り始める場合と、未決定の場所を把握して進める場合では、その後の対応が変わるからです。

乾は最後に、最初の依頼文を書き換えました。

「文化祭へ来る人が、スマートフォンで企画の場所と開催時刻を確認できるWebサイトを、文化祭の一週間前までに公開する」

最初の「いい感じ」は消えました。

代わりに、誰のために、何を、いつまでに作るのかが残りました。

要件定義とは、難しい言葉を並べる仕事ではありません。

「そういう意味だと思わなかった」を、作り始める前に一つずつ減らしていく仕事です。

先生・講師向け付属資料

「いい感じに作ってください」から始める要件定義ミニ演習

ここからは、この記事を授業や研修で使う先生、講師向けの補助資料です。

対象は、高校の情報科、高専、専門学校、大学の初年次教育、生成AI講座、職業訓練などを想定しています。

この演習だけで要件定義の全工程を習得することはできません。目的は、学習者に「曖昧な依頼をそのまま作り始める危険」と「質問によって認識を合わせる必要性」を体験してもらうことです。

学習目標

演習終了時に、学習者が次のことを説明できる状態を目指します。

曖昧な依頼から、確認すべき項目を見つけられる
目的、利用者、必須条件、制約、完成条件、対象外を整理できる
要求、要件、仕様の違いを簡単な例で説明できる
要件は最初から完全に決まるとは限らないと理解できる
生成AIへの指示と要件定義を区別できる

推奨時間

短縮版は45分、標準版は90分です。

45分の場合は、質問、整理、発表までを行います。90分の場合は、簡単な画面案や紙のプロトタイプを作り、依頼者からの追加変更にも対応させます。

準備するもの

模造紙、付箋、ホワイトボード、または共同編集できる文書
六つの確認項目を書いたワークシート
文化祭Webサイトの依頼カード
後から追加する変更条件カード

プログラミング環境は必須ではありません。要件定義の導入では、実装技術の差が演習結果へ影響しないよう、紙やスライドで進めても構いません。

演習の進め方

1．曖昧な依頼を渡す

最初に、次の一文だけを提示します。

文化祭で使うWebサイトを、いい感じに作ってください。

この時点では、詳しい条件を説明しません。

学習者から質問が出る前に、教員側が答えを追加しないことが重要です。学習者がすぐデザインや実装の相談を始めても、しばらく観察します。

2．質問を作らせる

班ごとに、依頼者へ確認したいことを考えさせます。

質問が止まった場合は、乾亮太のナビゲーションとして、次の言葉を提示します。

乾「誰が使うか、確認した？」
乾「その人は、何ができれば困らなくなる？」
乾「完成したと、誰がどう判断する？」
乾「今回は作らなくていいものは？」

教員は正解を教えるのではなく、質問が不足している場所へ注意を向けさせます。

3．教員が依頼者役になる

教員は、聞かれた質問にだけ答えます。

回答例は次の通りです。

主な利用者は生徒、保護者、一般来場者
スマートフォンで見る人が多い
公開日は文化祭の一週間前
企画一覧、開催時刻、校内地図、注意事項は必要
予算はない
更新担当者は実行委員の生徒
コメント機能やオンライン決済は不要
個人の顔写真や氏名は原則として掲載しない

質問されなかった条件は、教員から積極的に教えません。

これにより、「確認しなかった条件は、存在しないのではなく、見えていないだけ」という状態を体験させます。

4．六つの項目へ整理する

回答を次の六項目へ分類させます。

目的
利用者
必須条件
制約
完成条件
対象外

分類が難しい条件があっても構いません。実務でも、一つの情報が複数の項目に関係することがあります。

分類そのものより、なぜそこへ置いたのかを説明させることが重要です。

5．班ごとに発表する

各班に、最終的な依頼文と要件を発表させます。

同じ依頼から始めても、班によって内容が異なるはずです。その差を失敗として扱わず、どの質問と判断によって差が生まれたのかを比較します。

教員は、次の観点から確認します。

利用者が具体的になっているか
必須機能と便利そうな機能を区別できているか
期限や利用環境などの制約を確認しているか
完成を判断できる条件があるか
対象外が明記されているか
依頼者が一度も求めていない仕様を勝手に追加していないか

90分版の追加演習

各班が要件を発表した後、次の変更条件を一つ渡します。

文化祭当日は、校内の一部で通信が不安定になることが分かりました。

または、

公開三日前に、一つの企画で教室変更が発生しました。

または、

先生から、来場者の顔が写った写真を掲載しないよう指示がありました。

班ごとに、どの要件が影響を受けるか、何を変更するか、期限内に対応できるかを検討させます。

ここでの目的は、最初の要件定義を完璧に作り直すことではありません。

変更が発生したときに、影響する場所を確認し、関係者と再び合意する必要があると理解させることです。

生成AIを使う場合

生成AIを利用できる授業では、最初に次の指示を入力させてもよいでしょう。

文化祭のWebサイトを、いい感じに作ってください。

次に、六つの確認項目を整理した指示を入力し、出力の違いを比較します。

ただし、評価対象を「どちらのプロンプトが上手か」だけにしないでください。

AIが不足情報をどのように推測したか。その推測は誰が決めたものか。依頼者へ確認せず採用してよいのか。生成結果が要件を満たしていると、どう確認するのか。

そこまで考えさせることで、単なるプロンプト作成演習ではなく、要件定義の授業になります。

評価の目安

初学者向けでは、用語の暗記量より、質問と判断の根拠を評価します。

目的と利用者を確認できた
必須条件と任意の希望を分けられた
制約と対象外を一つ以上示した
完成条件を第三者が確認できる形で書いた
自分たちの推測と依頼者から確認した事実を分けた
変更による影響を説明できた

すべてを満たす必要はありません。

最初の演習で「自分たちは、ほとんど質問せずに作ろうとしていた」と気づければ、導入授業として大きな成果です。

教えるときの注意点

要件定義には、組織や開発手法によって異なる用語や進め方があります。要求、要件、要求定義、要件定義を厳密にどう区別するかも、現場によって完全には統一されていません。

初学者へ一つの定義を絶対的な正解として覚えさせるより、授業内で採用する定義を示したうえで、別の用法もあると伝えるほうが安全です。

また、「最初にすべて決めれば変更してはいけない」と教えないよう注意してください。

要件定義の目的は、変化をなくすことではありません。曖昧さと対立を見えるようにし、変更が起きたときに影響を確認できる状態を作ることです。

乾なら、おそらく最後にこう言います。

「質問が多いことは、理解していない証拠じゃない」

少し間を置いて、もう一言。

「確認しないまま作るほうが、怖い」

免責事項・著作権について

本記事は、要件定義に関する初学者向けの教育・情報提供を目的としたものです。特定の開発手法、契約、業務、システム設計について、完全性、正確性、適合性または成果を保証するものではありません。実際の開発や契約では、所属組織の規程、契約条件、利用サービスの規約、関係法令を確認し、必要に応じて専門家へご相談ください。本記事を参考にしたことによって生じた損害やトラブルについて、筆者は法令上認められる範囲で責任を負いかねます。

記事中の学校、授業、依頼内容、登場人物による説明は、学習用に構成した例です。実在する個人、学校、団体、企業または案件とは関係ありません。また、要求・要件・仕様などの用語は、組織、規格、契約および開発手法によって定義や使い方が異なる場合があります。

本記事の文章、構成、スライド、独自の図解、キャラクター設定その他の創作的表現について、適用される法令上認められる権利は筆者または正当な権利者に帰属します。引用した資料、名称、商標、サービス名などの権利は、それぞれの権利者に帰属します。記事中の画像には生成AIを使用したものが含まれます。生成AIを利用した部分については、各サービスの利用規約および適用法令に従って取り扱います。

私的利用および授業内での参照を除き、本文、図解、スライド、画像またはキャラクターを、許可なく転載、再配布、販売、改変して公開すること、教材や生成AIの学習用データ等へ転用することはご遠慮ください。授業資料への収録、組織内研修での配布、二次利用または商用利用を希望される場合は、事前に筆者へご相談ください。

※本記事は法的助言を提供するものではありません。

#要件定義 #IT初心者 #プログラミング学習 #情報教育 #高校情報 #大学生 #専門学校 #先生向け #授業づくり #生成AI #AI活用 #Web制作