転エンサービスへ

用語解説前編

「何を・どう作るか」を決める言葉

納品物の名前は「工程（フェーズ）ごと」にだいたい決まっています。覚えるべきは名前そのものより、「それを見れば自分は何が分かるのか／何を確認すべきか」です。

用語解説前編のまんが：専門用語に戸惑う依頼者が、意味を確認して安心するまでの4コマ — まんがで予習：わからない言葉は「これ何ですか？」と聞いてOK。

①要件定義フェーズ（何を作るか決める）

エンジニアが言う名前	ざっくり何のこと	発注者が見るべきポイント／注意
要件定義書Requirements	「何を・なぜ作るか」を文章でまとめた“作るものの土台”。	自分のやりたいことが正しく書かれているか。ここが全ての基準になるので最優先で確認。
機能要件 / 非機能要件	機能要件＝「何ができるか」（例：会員登録できる）。非機能要件＝「どのくらい速い・安全・落ちないか」など品質面。	「動けばいい」だけでなく、速度・セキュリティ・同時利用人数なども“要件”だと知っておく。
ユースケース / ユーザーストーリー	「誰が・どんな場面で・どう使うか」を物語のように書いたもの。	自分の利用シーンが抜けていないか確認。

②設計フェーズ（どう作るか決める）

エンジニアが言う名前	ざっくり何のこと	発注者が見るべきポイント／注意
基本設計書（外部設計）	利用者から見える部分（画面・操作・機能）の設計。	見た目・操作の方針がここで固まる。イメージと違えばこの段階で言う。
詳細設計書（内部設計）	プログラム内部の作りの設計。エンジニア向けで専門的。	中身は理解しきれなくてOK。「設計レビュー済み」の記録が後の証拠になる。
ワイヤーフレーム / モックアップ / プロトタイプ	画面の“下書き”。ワイヤー＝線画の骨組み、モックアップ＝見た目を作り込んだ完成イメージ図、プロトタイプ＝実際に触れる試作。	完成後の手直しは高くつく。この“絵”の段階で納得いくまで確認するのが最大の節約。
画面遷移図	画面から画面へどうつながるかの“地図”。	操作の流れに迷子がないか確認。
ER図 / テーブル定義書 / DB設計書ER / DB	データの保管設計（どんな情報をどう貯めるか）。ER＝情報同士の関係図。	詳細は不要。「必要な情報項目が漏れていないか」だけ意識。
API仕様書API	システム同士の“連絡ルール書”。外部サービス連携時に出てくる。	連携先（決済・地図・LINE等）が要件通りか確認。
システム構成図 / インフラ構成図	どんなサーバー・部品で動かすかの全体図。	クラウド利用料など運用コストに関わる点を確認。