要件定義とは何をすることか — 発注前に整理したい5つのこと

「システムを作りたいが、何から手を付ければよいかわからない」という声はよく聞かれます。開発会社に相談すると、最初に「要件を整理しましょう」と言われることが多いのですが、要件定義という言葉自体が分かりにくいと感じる方も少なくありません。要件定義は、開発会社に丸投げする工程ではなく、発注側が主役になる工程です。この記事では、要件定義で何をするのかを説明したうえで、発注前に整理しておきたい5つのことを順に取り上げます。

要件定義とは「何を作るか」を合意する工程

要件定義とは、システムで「何を実現するか」を整理し、発注側と開発側で合意する工程です。ここで決めるのは技術的な作り方ではなく、業務上の要求です。

要件は大きく2種類に分けられます。

要件定義が曖昧なまま開発に入ると、後の工程で「思っていたものと違う」というずれが起きやすくなります。修正は、工程が進むほど費用と時間がかかります。要件定義に時間をかけることは、遠回りに見えて、結果的に全体の手戻りを減らす近道です。開発費用との関係は費用の決まり方の記事でも触れています。

整理したいこと1・2：目的と成功条件、現状業務の流れ

まず押さえたいのは「何のために作るのか」と「今はどうしているのか」です。この2つが言葉になっていれば、開発会社との会話は一気に具体的になります。

1. 目的と成功条件

最初に言葉にしたいのは「なぜ作るのか」と「何が達成できたら成功か」です。目的が曖昧だと、機能の取捨選択ができず、要望が際限なく膨らみます。

想定例：「受注管理をシステム化したい」という目的を、次のように具体化します。

• 現状の課題：受注内容を電話とメールで受け、担当者が表計算ソフトに転記している
• 目的：転記作業をなくし、受注状況を全員が同じ画面で確認できるようにする
• 成功条件：転記による入力ミスが減り、受注状況の確認に担当者への問い合わせが不要になる

成功条件は、後で「できたかどうか」を判断できる形にしておくのがポイントです。数値目標を置く場合も、現状を測ってから決めると現実的になります。

2. 現状業務の流れ

次に、いま業務がどう回っているかを書き出します。システムは業務の一部を置き換えるものなので、現状が分からないと、どこを置き換えるべきかが決まりません。

書き出す項目は次のとおりです。

• 誰が（部署・役割）
• 何をきっかけに（電話、メール、来店、定期処理）
• 何を使って（紙、表計算ソフト、既存システム）
• 何をして（入力、確認、承認、出力）
• 次に誰へ渡すか

「例外的な流れ」も忘れずに含めてください。キャンセル、修正、返品といった例外処理は、通常の流れより設計が難しく、抜けると後から大きな追加になりがちです。

整理したいこと3・4：利用者と権限、扱うデータ

次に決めるのは「誰が使うか」と「何を保存するか」です。この2つは画面の数とデータベースの構造に直結するため、見積りの金額にも大きく影響します。

3. 利用者と権限

システムを「誰が使うのか」を洗い出し、それぞれに「何ができてよいか」を決めます。権限の設計は、後から変えると影響範囲が広いため、早めに整理しておきたい項目です。

想定例：小規模な販売業の受注管理システムでは、次のような整理になります。

外部の利用者が含まれるかどうかで、セキュリティの考え方が大きく変わります。社内だけで使うのか、取引先や一般の顧客も使うのかは、必ず明確にしておきましょう。

4. 扱うデータ

システムが扱う「情報のかたまり」を整理します。顧客、商品、受注、請求といった単位で、それぞれどんな項目を持つかを書き出してください。

• 項目名と形式（文字、数値、日付、選択肢）
• 必須かどうか
• 誰が、いつ入力するか
• どのくらいの件数を想定するか
• 既存データからの移行が必要か

とくに既存データの移行は見落とされやすい項目です。表計算ソフトで管理してきたデータは、表記ゆれや空欄が多く、そのままでは取り込めないことがあります。データの整理を誰が行うかも、あらかじめ決めておくと安心です。取引先の連絡先など機密性の高い情報を含む場合は、閲覧できる範囲についても検討が必要です。

整理したいこと5：やらないこと

意外に重要なのが「今回は対象にしないこと」を明記することです。範囲を絞ることで、見積の精度が上がり、最初の稼働までの道筋が明確になります。

想定例：受注管理システムの初期段階で「やらないこと」を決めた例です。

• 会計ソフトとの自動連携は対象外とし、CSV出力で対応する
• スマートフォン専用の画面は作らず、パソコンでの利用を前提にする
• 在庫管理は対象外とし、既存の方法を続ける
• 過去データの移行は直近の受注分のみとし、それ以前は参照用に残す

「やらないこと」は「将来もやらない」という意味ではありません。第一段階の範囲を明確にし、次の段階の候補として残しておくことで、開発側も拡張を見越した設計を検討できます。逆に、範囲が曖昧なまま進めると、開発の途中で「これも含まれると思っていた」という認識のずれが起き、費用や納期の見直しが必要になります。

基本設計・詳細設計へのつながり

要件定義で整理した内容は、次の工程である基本設計・詳細設計の土台になります。基本設計では、要件をもとに画面の構成、データの構造、他システムとの連携方法を決めます。詳細設計では、それをプログラムに落とし込める粒度まで細かくします。

要件定義の段階で「なぜそれが必要か」が共有されていれば、設計の判断に迷ったとき、開発側が目的に立ち返って提案できます。また、要件定義で決めた成功条件は、完成後の検収で「できたかどうか」を確認する基準にもなります。要件定義は、開発会社に渡す資料を作る作業ではなく、目的を共有する対話の出発点だと考えてください。業務効率化システム開発のような業務システムでは、この対話の質が完成後の使いやすさを左右します。

箇条書きのメモでも、整理されていれば足りる

要件定義は、システムで何を実現するかを整理し、合意する工程です。発注前に「目的と成功条件」「現状業務の流れ」「利用者と権限」「扱うデータ」「やらないこと」の5つを言葉にしておくと、打ち合わせが具体的になり、見積の精度も上がります。完璧な資料は必要ありません。箇条書きのメモでも、整理されていれば十分に価値があります。整理の進め方に迷う場合は、お問い合わせから現状の業務についてご相談ください。