要求要件実装テスト_ホットケーキ研修_石黒友季子_20260523

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

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

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

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

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

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

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

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

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

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

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

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