要件定義の進め方｜誰がやる？どこまで決める？発注側向けに解説
初めてシステム開発を頼むとき、最初に迷いやすいのが「要件定義の進め方」です。何を、誰が、どこまで決めればいいのか。先に答えを書くと、次のとおりです。
何を作るかを決めるのは発注側です。業務を一番よく知っているからです
業務の聞き取りや文書にまとめる作業は、開発会社が支援する形もあります（分担は案件ごとに決めます）
相談の時点で全部を決めておく必要はありません。決めきれない部分は、試作品などで確かめながら詰めていけます
この記事では、発注側と開発会社の役割分担、要件定義の5つのステップ、どこまで決めればいいかを順番に解説します。
要件定義とは（発注側が知っておけば十分なこと）
要件定義とは、これから作るシステムで「何ができればいいか」を決めて、発注側と開発会社で合意する工程です。一般には企画の後、設計の前に行う、開発の初期の工程です。
決める内容は、発注側から見ると、大きく次の3つに分けて考えるとわかりやすくなります（IPAのガイドでは、より細かく分類しています）。
種類 | 何を決めるか | 例 |
業務要件 | システムを使って、どんな業務をどう変えたいか | 紙の申込書をやめて、受付から集計までを1つの画面で済ませたい |
機能要件 | システムにどんな機能が必要か | 申込の登録、一覧の表示、月ごとの集計、CSVの出力 |
非機能要件 | 速さ・安全性・使える時間などの条件 | 画面が3秒以内に開く、平日の業務時間に必要な稼働率を保つ、担当者ごとに見られる範囲を分ける |
発注側が言葉の定義まで覚える必要はありません。「業務の困りごと」と「こうなったら助かる」を話せれば、残りは開発会社が整理します。
要件定義は誰がやる？発注側と開発会社の役割分担
IPA（情報処理推進機構）のガイドでは、要件を決める責任は発注側（ユーザー）にあるとされています。何を作るかは、業務を知っている発注側にしか決められないからです。
ただし「責任を持つ」は「全部を自分で書く」という意味ではありません。分担は案件ごとに決めます。開発会社が聞き取りや文書化を支援する場合は、たとえば次のような形になります。
段階 | 発注側がやること | 開発会社がやること |
目的の確認 | なぜシステムが必要かを話す | 目的を言葉にして、ずれがないか確かめる |
今の業務の聞き取り | 普段の仕事の流れ・使っている書類を見せる | 質問して流れを図や表にまとめる |
困りごとの整理 | 困っている場面を挙げ、優先順位を決める | 困りごとを機能の候補に置き換える |
機能・画面の案 | 案を見て、合う・合わないを答える | 画面や操作の流れの案を作る |
合意 | 内容を確認して承認する | 要件定義書にまとめる |
アビココでは、業務を聞き取って文書にまとめる作業は、開発会社側が受け持つ仕事だと考えています。誰が何を書くかは、最初に開発会社と確認しておきましょう。
ただし、丸投げはうまくいきません。発注側には、次の3つをお願いすることになります。
決める人を立てる：社内で最終的に判断する人と、開発会社とやりとりする窓口を決めておく
現場の時間を確保する：実際に使う担当者が、聞き取りや確認に参加できるようにする
優先順位と範囲を決める：何を先に作り、何を今回は作らないかを決める。合意した後の変更は、費用や期間に響きます
要件定義書を誰が書くかについては、要件定義の失敗事例と原因でも触れています。
要件定義の進め方5ステップ
要件定義は、一般的に次の5つのステップで進みます。進め方は開発会社によって違うため、一例として見てください。
ステップ1：目的を確認する
まず「なぜシステムを作るのか」をはっきりさせます。たとえば「月末の集計に丸2日かかっているのを減らしたい」のように、困りごとと目標をセットで話します。
ステップ2：今の業務を聞き取る
開発会社が、今の仕事の流れを聞き取ります。誰が、いつ、何を見て、何を入力しているかを順番に確かめます。
ステップ3：困りごとを整理して優先順位をつける
聞き取った内容から、困りごとを洗い出します。すべてを一度に解決しようとせず、「これがないと困る」「あると助かる」に分けます。
ステップ4：機能と画面の案を作る
開発会社が、必要な機能と画面の流れを案にします。発注側は、案を見て「この順番だと現場が迷う」など、気づいたことを伝えます。
ステップ5：要件定義書にまとめて合意する
確認した内容を、開発会社が要件定義書にまとめます。発注側は内容を確認し、承認します。ここで合意した内容が、見積もりや開発の基準になります。
画面の案だけでは判断しづらいときは、試作品を作って確かめる方法もあります。必須の工程ではありませんが、この記事の後半で紹介します。
設計・開発・テストまでを含めた全体の流れは、システム開発の流れで解説しています。
要件定義はどこまで決める？
「要件定義はどこまで決めればいいのか」という疑問には、3つの段階に分けて考えるのがおすすめです。
段階 | 決めること | 例 |
依頼する前に決めること | 目的・予算の目安・使い始めたい時期 | 集計の手間を減らしたい／年度内に使い始めたい |
開発会社と一緒に決めること | 必要な機能・使う人・扱うデータ | 入力するのは受付担当、見るのは管理者／扱うのは申込データ |
試作品を見ながら詰めやすいこと | 画面の細かい動き・表示の仕方・項目の並び | ボタンの位置／一覧に出す項目の順番 |
「今回は作らないもの」を決めておくことも大切です。範囲がはっきりすると、見積もりもぶれにくくなります。
最初の相談を始めるには、目的と予算と時期があれば十分です。見積もりや要件の合意に進む段階では、対象範囲・使う人・データ・ほかのシステムとの連携・安全性の条件なども開発会社と一緒に確認します。
画面の動きや表示の仕方は、文書だけでは判断しにくいことがあります。試作品の段階で詰めておくと、認識のずれに早く気づける場合があります。なお、正式な開発に入った後の変更は、費用や期間に響くことがあります。
最終的な要件定義書には、主に次のような項目が入ります。まとめるのは開発会社です。
システムの目的と、対象にする業務
今回作る範囲と、作らない範囲
機能の一覧
画面の一覧と操作の流れ
扱うデータ
速さ・安全性などの条件（非機能要件）
最初の相談で手元にあると話が早いもの
開発会社への最初の相談では、次のようなものがあると話が早く進みます。
今使っているExcelや紙の書類（見本で十分です）
困っている場面のメモ（「月末に◯◯が終わらない」など）
その業務に関わる人（誰が入力して、誰が見るか）
予算の目安と、使い始めたい時期
すべてそろっていなくても大丈夫です。足りない部分は、開発会社がヒアリングで聞き取ります。相談の時点で資料を完璧に用意する必要はありません。
文書だけで決めきれない部分は、動くもので確かめる
文書で合意していても、完成後にイメージとの違いが見つかる場合があります。言葉だけでは、使い心地までは共有しきれないことがあるためです。
そこで役立つのが、プロトタイプ（試作品）を作って確かめる進め方です。
画面を実際に触りながら、必要な機能を考えられる
現場の担当者にも見せて、使えるかを判断してもらえる
認識のずれに早く気づける場合がある
一方で、試作品を作る手間や、試作品の印象に引っ張られるといった注意点もあります。
プロトタイプを使った進め方の詳細は、プロトタイプ開発とはで解説しています。
アビココの「てにとる」の場合
アビココ株式会社が提供する「てにとる」は、この「動くもので確かめる」進め方を、契約の前から行うサービスです。打ち合わせ→プロトタイプ作成→お客様による確認→修正、を繰り返し、本番に近いプロトタイプで確かめ、ご納得いただいてから正式契約に進みます。お客様の本番データを使う場合は、事前に秘密保持契約を結びます。
「要件定義をどこまで準備すればいいか分からない」という段階からご相談いただけます。
よくある質問
Q. 要件定義はどこまで決める必要がありますか？
最初の相談の時点では、目的・予算の目安・使い始めたい時期があれば十分です。見積もりや要件の合意までに、対象範囲・機能・使う人・データ・安全性の条件などを開発会社と一緒に決めます。画面の細かい動きや表示の仕方は、試作品を見ながら詰めることもできます。
Q. 要件定義は発注側と開発会社のどちらがやるのですか？
何を作るかを決めるのは発注側です。一方で、業務の聞き取りや、内容を要件定義書にまとめる作業は、開発会社が支援する形もあります。分担は案件ごとに決めます。発注側は、質問に答えて案を判断するほか、決める人を立て、優先順位と範囲を決める役割を持ちます。
Q. 発注側にITの専門知識は必要ですか？
専門知識はなくても進められます。必要なのは、自分たちの業務の流れと困りごとを話せることです。専門用語への置き換えや、技術的な選択肢の説明は開発会社が行います。ただし、必要な安全性や止まっても困らない時間など、業務に関わる条件は発注側も確認して決めます。
Q. 要件定義書は発注側にも読める形で作ってもらえますか？
読みやすい形で作ってもらえるかは、相談の時点で確認しておきましょう。専門用語ばかりで判断できない場合は、画面のイメージや具体例を添えてもらうよう依頼できます。動く試作品で確認できれば、文書だけより判断しやすくなります。
まとめ
要件定義の進め方のポイントは、次の3つです。
何を作るかに責任を持つのは発注側。聞き取りと文書化は、開発会社が支援する形もある（分担は案件ごと）。決める人と優先順位は発注側で用意する
最初の相談は、目的・予算の目安・時期があれば始められる
決めきれない部分は、試作品などで確かめながら詰める
「全部決めてからでないと相談できない」と考える必要はありません。困りごとが言える段階で、開発会社に相談してみてください。
開発会社の選び方や見積もり依頼のコツは、システム開発会社の選び方で解説しています。
要件定義から相談できる「てにとる」
アビココ株式会社の「てにとる」は、契約の前に、実際に動くプロトタイプで確認できる受託開発サービスです。本番に近いプロトタイプが完成するまでは、原則無料で進められます。
要件が固まっていない段階から相談できる
打ち合わせと試作を繰り返し、現場で使えるかを確かめられる
ご納得いただいてから正式契約に進む
参考文献
IPA（独立行政法人情報処理推進機構）「ユーザのための要件定義ガイド 第2版」 https://www.ipa.go.jp/archive/publish/tn20191220.html
コメント