この記事の結論
要件定義は、作るシステムに「何ができればいいか」を、発注する側と開発会社で決める工程です。開発会社は作り方を考えられますが、業務の中身と優先順位を決められるのは発注する側だけです。今の業務の流れ、困っていること、なくてはならない機能と後回しでよい機能の3つを用意しておくと、要件定義は短く、確かなものになります。
要件定義とは
システム開発は、大まかに「何を作るか決める」「設計する」「作る」「確かめる」の順に進みます。最初の「何を作るか決める」工程が、要件定義です。
ここで決めるのは、作り方ではなく、できること・守ることです。
| 決めること | 例 |
|---|---|
| 業務の流れ | 問い合わせを受けてから、見積もり、受注、請求までの流れ |
| 機能 | 案件を登録する、担当者を割り当てる、請求書を出す |
| 画面と帳票 | 一覧の画面、入力の画面、出力する書類 |
| 使う人と権限 | 誰が見られて、誰が直せるか |
| 守ること | 動く時間帯、データの保管、止まったときの扱い |
発注する側にしか決められないこと
開発会社は、作り方や技術の選び方については専門家です。ただ、次のことは発注する側にしか決められません。
- 業務の中身。 例外の扱い、現場だけが知っている手順
- 優先順位。 最初に必要な機能と、後回しでよい機能
- 判断する人。 迷ったときに誰が決めるか
ここを開発会社に任せきりにすると、できあがってから「現場の使い方と合わない」「一番ほしかった機能が後回しになっていた」ということが起きます。
要件定義の前に、用意しておく3つのこと
完璧な資料は要りません。次の3つがあれば、要件定義の打ち合わせは大きく短くなります。
- 今の業務の流れ。 誰が、何を受けて、何をして、誰に渡すか。手書きの図や箇条書きで構いません
- 困っていること。 「二重入力が多い」「誰が対応中か分からない」など、具体的な場面で書く
- なくてはならない機能と、あればうれしい機能の区別。 全部を最初に作ろうとしないことが、予算と期間を守る近道です
今使っているExcelや紙の帳票があれば、それも一緒に渡します。項目の並びや、現場が書き足している欄から、業務の実態が見えます。
「こういう画面がほしい」から話すより、「今、この作業でこう困っている」から話すほうが、よい要件になります。画面の形は、困りごとが分かれば開発会社から提案できます。
私たちが自社の仕組みで最初に決めたこと
私たちが自社サイトのコラムの仕組みを作ったときも、作り方より先に、守ることを決めました。
- 下書きの記事は、本番のサイトに出さない
- スマホで、日本語が変なところで改行されない
- 公開する前に、決まった点検を毎回通す
この3つが決まっていたので、作り方は後からいくつも選べました。業務システムでも同じで、「これだけは守る」を先に決めておくと、途中で迷いにくくなります。
守ることは、確かめ方とセットで書いておくと、要件として使えるものになります。私たちの場合は、次のように決めています。
| 守ること | 確かめ方 |
|---|---|
| 下書きを本番に出さない | 公開の手順の中で、下書きの印がついた記事を外す |
| スマホで変な改行をしない | 本番に出す前に、手元で表示とフォームの動き・改行を自動で点検する |
| パスワードや鍵を漏らさない | ソースコードやチャットに書かず、決まった保管場所にだけ置く |
業務システムでも、「お客様の情報を誰が見られるか」「止まったら誰に連絡するか」のような守ることを、確かめ方まで含めて要件に入れておくと、作った後の点検や保守の契約にもそのまま使えます。
私たちは、多業種に対応した予約管理システムを自社プロダクトとして、企画から運用まで開発しています。技術責任者は、業務システムの要件定義から開発、保守運用までを経験しています。作る側として要件を整理するときも、最初に確かめるのはこの「守ること」です。
契約の形にも気をつける
この段階では、何を作るかがまだ決まっていません。そのため、IPA（情報処理推進機構）のモデル契約書では、要件定義を、できあがりを約束する形（請負）ではなく、作業に対して支払う形（準委任）で結ぶことを想定しています。2020年12月に公開された第二版でも、要件定義は「要件定義作成支援業務（準委任型）」として扱われています（IPA：情報システム・モデル取引・契約書（第二版）、2026-10-02 確認。契約書のファイルは2025年4月に更新）。
この工程と、その後の開発を分けて契約すると、要件が固まってから開発の見積もりを取れるので、金額の根拠がはっきりします。見積もりの読み方は、業務システムの見積もりの読み方。金額を比べる前に確かめることにまとめています。
よくある失敗
- 決める人がいない。 現場の意見がまとまらず、要件が固まらないまま開発が始まる
- 全部を最初に入れる。 あればうれしい機能まで入れて、予算と期間が膨らむ
- 決めたことを書き残さない。 打ち合わせで決めたことが、後から「言った・言わない」になる
- 現場の人が参加しない。 管理する人だけで決めて、実際に使う人の手順と合わない
よくある質問
要件定義は、発注する側でどこまで書く必要がありますか？
要件定義だけを頼めますか？
要件定義の期間は、何で決まりますか？
困りごとを書き出すところから始める
専門的な資料を作ることが目的ではありません。まずは、今の業務で困っている場面を、3つ書き出してみてください。それが、開発会社との最初の打ち合わせで一番役に立つ資料になります。
システムにするか迷っている段階なら、Excelでの業務管理が限界になったときの、7つのサインも参考にしてください。
ご相談
業務システムについて、いまの状況をお聞かせください。
「何から手をつければいいか分からない」という段階からで構いません。返信は担当者が直接お送りします。
