要件定義

📖 もうちょい詳しく

何が新しいの？

要件定義は新しい技術ではなく、ものづくりの世界で昔からある最初の工程です。システム開発では「いきなり作りはじめると、できあがったものが思っていたのと違う」という失敗がとても多いです。そこで、作る前に「何が必要か」をきちんと言葉にしてそろえておこう、という考え方が定着しました。

どうやって動いてるの？

まず、システムを使う人や依頼する人（発注側）から「どんな困りごとを解決したいか」を聞き取ります。それを整理して、「画面でこういう操作ができる」といった機能の中身（機能要件）と、「何秒以内に表示する」「同時に何人使える」といった性能や品質の条件（非機能要件）に分けて書き出します。最後にその内容を関係者みんなで確認し、合意した文書（要件定義書）として残します。

何ができるの？

要件定義をしておくと、後から作る人が「何を作ればいいのか」で迷わなくなります。また、途中で「やっぱりこの機能も」と話が膨らんでも、最初の文書と照らし合わせて判断しやすくなります。完成したシステムが条件を満たしているか確かめる、テストのものさしとしても使えます。

🌱 身近なたとえ

家を建てる前の打ち合わせで例えると分かりやすいです。「部屋はいくつ」「日当たりは」「予算はいくらまで」といった希望を、図面を引く前に施主と建築士でじっくりすり合わせますよね。この希望をまとめる作業が要件定義にあたります。土台を作ってから「やっぱり部屋を増やしたい」となると大変なので、先に決めておくのです。

✅ まず覚えるポイント

• 作りはじめる前に「何が必要か」を固める最初の工程です
• 利用者の困りごとを聞き取るところから始まります
• 機能要件（できること）と非機能要件（性能や品質）に分けて整理します
• 関係者で合意した内容を「要件定義書」という文書に残します
• 後の設計・開発・テストすべての土台になります

🧭 よくある勘違い

要件定義は技術的な設計のこと？

いいえ、要件定義は「何を作るか（What）」を決める工程で、「どう作るか（How）」を決める設計とは別物です。たとえば「会員が予約できる機能がほしい」までが要件で、「どのデータベースを使うか」は設計の話になります。順番としては要件定義のあとに設計が続きます。

一度決めたら変えられない？

そうとは限りません。最初にすべてをきっちり固めるやり方（ウォーターフォール）もあれば、少しずつ作って確かめながら要件を見直していくやり方（アジャイル）もあります。大切なのは「変えるときに関係者で合意し直す」ことで、変更そのものは珍しくありません。

🧩 関連して覚えると楽な言葉

• MVP: 必要最小限の機能だけで素早く作る、最初の小さな完成形のことです
• ウォーターフォール: 要件定義から順番に工程を進めていく開発の進め方です
• アジャイル: 短い区切りで作っては見直す、変化に強い開発の進め方です
• テスト駆動開発: 先にテストを書いてから中身を作る、品質重視のやり方です

🏁 ひとことでまとめ

要件定義は、作りはじめる前に「これを満たせばOK」という条件を関係者でそろえて文書にしておく、開発の出発点となる工程です。