---
title: 要求要件実装テスト_ホットケーキ研修_石黒友季子_20260523
tags:  #新卒研修 #文系向け #要求定義 #要件定義  
author: [smile_yukiko_it](https://docswell.com/user/smile_yukiko_it)
site: [Docswell](https://www.docswell.com/)
thumbnail: https://bcdn.docswell.com/page/YJ6WMZ31JV.jpg?width=480
description: 楽しく要求定義を学びましょう！
published: May 23, 26
canonical: https://docswell.com/s/smile_yukiko_it/5PRW46-2026-05-23-173210
---
# Page. 1

![Page Image](https://bcdn.docswell.com/page/YJ6WMZ31JV.jpg)

つくる前と、つくった後。
要求定義 → 要件定義
実装 → テスト
ホットケーキで学ぶ、ソフトウェア開発の流れ
文系もOK
理系は原理原則
石黒友季子 ｜ 新卒IT研修
APIあり・なし付き


# Page. 2

![Page Image](https://bcdn.docswell.com/page/GJ5MZWLLJ4.jpg)

今日のゴール
うさうさ先生
4つの工程の役割を言える
要求定義・要件定義・実装・テスト。それぞれ「何のため？」を自分の言葉で説明できる。
「要求」と「要件」の違いが言える
似ているこの2つ。どう違うのかを、ホットケーキで説明できるようにする。
APIあり・なしのイメージを持つ
「粉から手作り」と「ミックスを使う」の違いとして、実装の選択肢がわかる。
わからない用語が出たら、その場で手をあげてOKです。


# Page. 3

![Page Image](https://bcdn.docswell.com/page/9E29RQL37R.jpg)

うさうさ先生
開発は、この4ステップ
①
②
③
④
要求定義
要件定義
実装
テスト
お客さんの
「食べたい」
レシピ（仕様）
に翻訳
実際に
焼く
味見・
検品
ポイント 前半（①②）で「何を作るか」を決め、後半（③④）で「作って確かめる」。順番に
意味があります。


# Page. 4

![Page Image](https://bcdn.docswell.com/page/D7Y4DWQ8EM.jpg)

うさうさ先生
なぜ、この順番なの？
いきなり焼き始めると…
何を作るか決めずに実装
→ 「あれ、何枚焼くんだっけ？」と作り直し
お客さんの「食べたい」を聞かずに完成
だから
手を動かす前に
「何を・なぜ」を
先に固める。
→ 「これじゃない…」とまるごとやり直し
テストを後回し
→ 焦げに気づかず提供してしまう
早い段階のひと手間が、あとの大きな手戻
りを防ぎます。


# Page. 5

![Page Image](https://bcdn.docswell.com/page/VENY69K9J8.jpg)

1
うさうさ先生
要求定義
文系向け
お客さんの「食べたい」
お客さんが「どうなりたい／何をしたいか」を
引き出すこと。
この時点では、作り方はまだ決めません。
理系向け（原理原則）
問題空間の定義。
ステークホルダーのニーズ・目的・制約を抽出
する。
扱うのは What / Why（How はまだ）。
例：「ふわふわで甘い、あったかいおやつが食
べたい」
出力は曖昧さを含む“生の要求”。後段で精緻化
。
→ 枚数も大きさもまだ未定。これが“要求”。
ゴール＝「解くべき問題」に合意すること。
ひとこと 要求 ＝「〜したい」という願い。


# Page. 6

![Page Image](https://bcdn.docswell.com/page/Y79PL2V3E3.jpg)

2
うさうさ先生
要件定義
文系向け
レシピ＝仕様に翻訳
理系向け（原理原則）
要求を「作れる形」に翻訳し、具体的に決める
こと。
解空間への写像。
＝レシピ（仕様書）づくり。
良い要件の3条件：
要求を 機能要件／非機能要件 に分解する。
・検証可能（testable）
例：直径12cm × 2枚／はちみつ添え／
提供15分以内／アレルギー表示あり
→ 作る基準がハッキリした。これが“要件”。
・一意（曖昧でない）
・追跡可能（traceable）
受け入れ条件（完成基準）も定義する。
ひとこと 要件 ＝ 検証できる「作る、お約束のことだよ！」。


# Page. 7

![Page Image](https://bcdn.docswell.com/page/G78DX5PL7D.jpg)

うさうさ先生
「要求」と「要件」はどう違う？
要求 (Needs)
要件 (Spec)
主語
お客さん
作る人（私たち）
中身
したいこと・願い
作るもの・基準
例
甘いおやつが食べたい
12cm×2枚・はちみつ
あってOK
ダメ（一意に）
曖昧さ
要求
→（翻訳）→
要件
「要件定義」は、この“翻訳作業”そのもの。


# Page. 8

![Page Image](https://bcdn.docswell.com/page/L7LM8Y1QJR.jpg)

3
うさうさ先生
実装
文系向け
決めたレシピどおりに作る
理系向け（原理原則）
仕様（レシピ）どおりに、実際に作ること。
仕様（抽象）→ 実行可能な形式（具象）への変
換。
APIなし ＝ 粉から手作り
原則：関心の分離・再利用・単一責任。
小麦粉・卵・牛乳を計って混ぜて焼く。自由度
は高いが手間も大きい。
API＝外部機能との「契約（インターフェース
）」。
APIあり ＝ ミックスを使う
内部実装を隠蔽し、入出力の約束だけを使う。
誰かが用意した“混ぜるだけ”の部品を使う。速
くて安定。
自作 vs API：制御性 ⇄ 開発速度・保守 のトレー
ドオフ。
ひとこと 実装 ＝ レシピを形にする。部品（API）を使うと速い。


# Page. 9

![Page Image](https://bcdn.docswell.com/page/4EMY6N5KEW.jpg)

うさうさ先生
API ってなに？
リクエスト
たとえると…ホットケーキミックス
袋の裏の「卵と牛乳を入れて混ぜて焼く」だけ
守れば、中の配合を知らなくても同じ味になる
。
API
の窓口
あなた
（プログラム）
レスポンス
決まった形で頼むと、決まった形で結果が返る。中身は知らな
くてOK（ブラックボックス）。
きちんと言うと
Application Programming Interface。機能を呼び出
すための「窓口／約束」。決まった形で頼むと
、決まった形で結果が返る。
ひとこと
API ＝ 中身を知らなくても使える「お
願いの窓口」。


# Page. 10

![Page Image](https://bcdn.docswell.com/page/PER9PD36J9.jpg)

4
うさうさ先生
テスト
文系向け
味見・検品
焼けたホットケーキを確かめること。
理系向け（原理原則）
2種類の確認がある（V字モデル）。
Verification（検証）：
仕様どおり？（検証）
ちゃんと 12cm × 2枚、はちみつ添え？
願いどおり？（妥当性）
お客さんの「ふわふわで甘い」を満たせた？
仕様どおり正しく作ったか。
Validation（妥当性確認）：
そもそも正しいものを作ったか。
要求⇄受け入れ／要件⇄結合・システム が対応
。
ひとこと テスト ＝「正しく作った？」と「正しいもの作った？」の二重チェック。


# Page. 11

![Page Image](https://bcdn.docswell.com/page/P7XQ314DEX.jpg)

うさうさ先生
ひとことまとめ
①要求
「〜したい」という願い
演習：うさうさホットケーキ店
②要件
検証できる「作る約束」
お客さんの一言から、1枚の紙に書き出そう
：
③実装
形にする（APIで時短）
1. 要求（お客さんは何をしたい？）
2. 要件（どんな基準で作る？）
3. 実装方針（API使う？粉から？）
④テスト
二重チェック
制限時間10分・ペアでどうぞ
4. テスト観点（何を確かめる？）


# Page. 12

![Page Image](https://bcdn.docswell.com/page/37K9Y2ZD7D.jpg)

「面白きこともなき世を面白く」
わからない言葉は、いったん“ホットケーキ”に
置き換えて考えてOK。
手を動かす前に、まず「何を・なぜ」から。
石黒友季子
｜ 新卒IT研修