要件定義の進め方｜発注側が決めておく5つのこと

システム開発の依頼を進めるなかで、「要件定義」という工程で手が止まってしまうケースは少なくありません。

開発会社から「どのような機能が必要ですか」と聞かれても、業務のことは分かっていても、システムとして何をどこまで求めるべきかは判断しづらいものです。

要件定義は、発注側が業務の実態や優先順位を伝え、開発会社が技術面から実現方法を整理し、双方で合意していく工程です。

ここが曖昧なまま設計や開発に進むと、完成したシステムが業務に合わない、追加費用が発生する、稼働時期が後ろにずれるといった事態につながることもあります。

この記事では、要件定義の全体像と進め方を5つのステップで整理したうえで、発注側があらかじめ決めておきたい5つのポイントを具体的に解説します。

初めてシステム開発を依頼する方でも、開発会社との打ち合わせに何を持ち込めばよいかが見えてくる内容になっています。

要件定義とは？発注側が担う役割

要件定義とは、システムで実現したいことを整理し、開発の対象範囲を文書として確定させる工程を指します。

システム開発の工程のなかでは最上流に位置し、この後に基本設計、詳細設計、開発、テストと続いていきます。

要件定義と要求定義の違い

似た言葉が並ぶため混同されやすいものの、それぞれ扱う内容と主体が異なります。

要求定義は「請求書の発行に時間がかかっているため短縮したい」といった、業務側の言葉で語られる希望にあたります。

これに対して要件定義では、その希望を「請求データを取り込み、月次で一括発行できる機能を備える」といった、開発できる形の記述に変換していきます。

要求定義は発注側でなければ書きづらく、要件定義は両者の対話がなければ固まりにくい、という点が大きな違いになります。

ただし、要求を引き出すためのヒアリングを開発会社が代行する形もあるため、発注側だけで文書を完成させなければならないわけではありません。

基本設計以降は開発会社が主導する工程になるため、発注側が主体的に関われる最後の工程が要件定義だと考えると、位置づけを整理しやすくなります。

要件定義が開発の成否を左右する理由

要件定義の内容は、そのまま見積金額、開発期間、完成物の判定基準として扱われることが一般的です。

つまり、ここで決めた範囲が「発注した内容」そのものになるため、後から変更しようとすると設計のやり直しが発生しやすくなります。

一般に、工程が進むほど手戻りの影響範囲は広がるとされています。

完成後に「思っていたものと違う」という結果を避けるうえでも、この工程に時間をかける価値は大きいと考えられます。

システム開発全体の流れを先に把握しておきたい場合は、「【初心者でも安心】システム開発の手順を徹底解説！プロが教える成功する7つの工程」もあわせて確認してみてください。

開発会社に任せきりにできない部分

開発会社は技術と開発手法の専門家ですが、依頼元の業務の細かな事情までは把握しきれない部分が残ります。

そのため、次のような判断は発注側でなければ答えを出しにくくなります。

• どの業務を優先してシステム化するか
• 例外的な処理をシステムで扱うか、運用でカバーするか
• 既存の業務ルールを変更してよいか
• 誰がどの情報を閲覧できるようにするか

これらはいずれも、業務の実態と社内の方針を知っている人でなければ判断しづらい項目といえます。

たとえば「例外処理をシステムで扱うか」という問いひとつをとっても、年に数件しか発生しない処理のために機能を作れば、その分の開発費用と保守の手間が継続的に発生することになります。

一方で運用でカバーする判断をすれば費用は抑えられますが、担当者の負担は残ります。

どちらが適しているかは業務の実態によって変わるため、開発会社が代わりに決めきれる部分ではありません。

要件定義を開発会社に任せきりにしてしまうと、こうした判断が「一般的にはこうする」という無難な形で埋められ、結果として自社に合わないシステムになる可能性も出てきます。

要件定義の進め方5ステップ

要件定義は、いきなり機能の一覧を作るところから始まるわけではありません。現状の整理から順に積み上げていく流れが一般的です。

1. 現状業務の洗い出しと課題の整理

最初に行うのは、現在の業務がどのように回っているかを可視化する作業です。

誰が、どのタイミングで、どのような情報を扱い、次の誰に渡しているのかを、業務の流れに沿って書き出していきます。

このとき、正式な手順書に書かれた流れだけでなく、現場で実際に行われている運用も含めて拾い上げておくと、後の検討がぶれにくくなります。

手作業で作っている集計表、担当者が個人的に管理しているファイル、口頭で引き継がれている確認作業などは、手順書には残っていないこともあります。

洗い出したうえで、時間がかかっている箇所、ミスが起きやすい箇所、特定の人しか対応できない箇所に印をつけていくと、課題の輪郭が見えてきます。

2. システム化の目的とゴールの設定

課題が見えたら、次はシステムで何を達成したいのかを言語化していきます。ここで意識しておきたいのは、目的をできるだけ測れる形にしておくことです。

曖昧な表現	測れる表現
業務を効率化したい	月次処理にかかる作業時間を短縮したい
情報を共有したい	在庫状況を各拠点から確認できるようにしたい
ミスを減らしたい	転記作業をなくし入力を一度で済ませたい

右側の表現に置き換えておくと、機能を検討する際の判断基準として使いやすくなります。

「この機能は目的に貢献するか」という問いに立ち返れるため、要望が膨らんだときの取捨選択も進めやすくなります。

目的が曖昧なまま機能の話に進むと、要望の優先順位を付ける根拠が持ちにくくなります。

3. 業務要件・機能要件の定義

目的が定まったら、それを実現するために必要な機能を具体化していきます。

業務要件は「システム導入後に業務をどう回すか」という運用面の取り決めで、機能要件は「そのためにシステムが備える機能」を指します。

1. システム導入後の業務フローを描く
2. フローのなかでシステムが担う部分を切り分ける
3. 必要な画面と入出力する情報を列挙する
4. データの登録・参照・更新の権限を整理する

この順番で進めると、機能の抜け漏れが起こりにくくなります。

先に機能を挙げてしまうと、思いついた順に並ぶだけになり、業務の流れとして成立しているかを確認しづらくなるためです。

導入後のフローを描いてから必要な機能を切り出すことで、業務がつながっているかどうかを確かめながら機能を決めやすくなります。

また、機能を挙げていくと、予算や期間の枠に収まらないことも出てきます。

そのため、この段階で各機能を「必須」「あると望ましい」「今回は見送る」の3段階に分類しておくと、後の調整が進めやすくなります。

分類の判断に迷う場合は、その機能がなければ業務が止まるかどうかを目安にすると整理しやすくなります。

4. 非機能要件の定義

非機能要件は、機能そのものではなく、システムの品質や運用条件に関する取り決めを指します。

見落とされやすい一方で、後から変更すると構成の見直しが必要になる項目も多く含まれます。

何を検討すればよいかの目安としては、IPA（情報処理推進機構）が公開している「非機能要求グレード」が広く参照されています。

ここでは検討すべき非機能要求が6つの大項目に整理されており、要件定義の叩き台として使いやすい形になっています。

• 可用性：停止が許されない時間帯があるか、復旧までどのくらい待てるか
• 性能・拡張性：同時に何人が使うか、将来の利用者数や拠点の増加を見込むか
• 運用・保守性：障害時の連絡体制と対応時間をどうするか
• 移行性：既存のデータをどこまで、どのような方法で移すか
• セキュリティ：社外からのアクセスを許可するか、誰にどの権限を与えるか
• システム環境・エコロジー：設置場所や消費電力などの制約があるか

これらの項目は技術的な名称が並んでいるものの、中身を見ると業務に関する問いがほとんどを占めています。

たとえば「停止が許されない時間帯があるか」は、業務のどの時間帯に処理が集中しているかを知らなければ答えられません。

つまり、非機能要件の多くは発注側が答えを持っている領域であることが多いです。

なかでも移行性は、既存システムからの切り替えを伴う場合に検討量が大きくなりやすい項目です。

過去データをどこまで引き継ぐか、切り替えの当日に業務を止められるかといった判断は、開発会社だけでは決めきれません。

また、可用性と性能・拡張性は、必要以上に高い水準を求めると構成が大がかりになり、費用に跳ね返ることもあります。

「できるだけ速く」「絶対に止まらないように」といった要望は、要件としては幅が広くなりやすいため、具体的な数値や時間帯に落とし込んでおくことが望まれます。

保守面の考え方については、「システム保守費用の内訳公開｜相場はどのくらい？削減のコツも」で費用構造も含めて解説しています。

5. 要件定義書の作成と合意

整理した内容は、要件定義書という文書にまとめて双方で合意します。

この文書が、以降の設計・開発・テストにおける基準として扱われることになります。

合意にあたっては、社内の関係部署にも内容を確認してもらう工程を挟んでおくと安心です。

打ち合わせに出ていない部署から後になって要望が出てくると、要件の追加として扱われ、費用と期間の再調整が必要になることもあります。

発注側が事前に決めておく5つのこと

ここからは、開発会社との打ち合わせに入る前に、発注側で方針を固めておきたい項目を5つ挙げます。

これらが決まっていない状態で要件定義を始めると、打ち合わせのたびに社内へ持ち帰る時間が発生し、工程が長引く可能性があります。

1. 解決したい課題の優先順位

システム化したい課題が複数ある場合、そのすべてを一度に解決しようとすると、規模も費用も膨らみやすくなります。

そこで、課題に順位を付けておきます。

順位	判断の目安
最優先	解決しなければ導入の意味が薄れる課題
次点	解決すると効果は大きいが今回でなくてもよい課題
将来対応	体制や業務の変化を待ってから判断する課題

この順位が付いていると、予算に収まらない場面でも「どこから削るか」の議論が短時間で済みやすくなります。

反対に順位が曖昧なままだと、削る対象を決める作業自体が新たな検討工程になってしまい、要件定義が長期化する要因にもなりかねません。

順位は完璧である必要はなく、社内で共有された暫定的なものであっても十分に役立ちます。

2. 予算の上限と費用配分の考え方

予算を開発会社に伝えることをためらう方もいますが、上限を共有したほうが提案の精度は上がりやすくなります。

金額の枠が分かっていれば、開発会社はその範囲で実現できる構成を提案でき、範囲外の要望についても代替案を出しやすくなるためです。

• 開発費として使える上限額
• 稼働後の保守費用として毎年確保できる額
• 予算の承認に必要な社内手続きと時期

このうち見落とされやすいのが、2つ目の保守費用です。

システムは納品されて終わりではなく、稼働後も障害対応、法改正への対応、利用者からの改善要望への対応が継続していきます。

開発費の枠だけで検討を進めると、稼働後の運用予算が確保できず、更新が止まってしまうこともあります。

3つ目の社内手続きも、要件定義の期間に影響してきます。

稟議に一定の期間を要する場合、その時間を見込んだうえで打ち合わせの日程を組んでおくと、進行が滞りにくくなるためです。

3. 稼働希望時期と社内スケジュール

いつまでに使い始めたいのかは、要件の範囲を決めるうえで大きな条件になります。

法改正への対応、既存システムの保守期限、繁忙期の前など、動かせない期限がある場合は、その日付を最初に共有しておくとよいでしょう。

期限から逆算して、要件定義、設計、開発、テスト、移行の各工程に割ける期間が見えてくるため、範囲の調整も具体的になります。

一方、明確な期限がないときは、「この時期は業務が立て込むため打ち合わせが難しい」といった社内の繁忙期を伝えておくだけでも役立ちます。

要件定義は発注側の担当者が相応の時間を割く工程であるため、繁忙期と重なると確認が滞りやすくなります。

4. 意思決定者と窓口担当者

要件定義では、さまざまな判断を繰り返し求められます。

そのため、誰が最終的に決めるのかを事前にはっきりさせておくと、進行が安定しやすくなります。

役割	担うこと
意思決定者	費用と範囲に関わる判断を下す
窓口担当者	開発会社との連絡と社内調整を行う
業務担当者	現場の実態と運用上の制約を伝える

この3つの役割は同一人物が兼ねても構いませんが、役割が定まっていない状態は、進行が滞る要因になることもあります。

打ち合わせで出た論点が誰にも引き取られないまま次回に持ち越され、同じ議論を繰り返すことにもなりかねません。

また、複数部署が関わるシステムの場合は、部署間で要望が食い違ったときに調整する役割も決めておくと安心できます。

5. 既存システムやデータの扱い

すでに稼働しているシステムがある場合、それをどう扱うかによって要件の範囲は大きく変わってきます。

• 既存システムを置き換えるのか、並行して使い続けるのか
• 過去のデータをどこまで移行するのか
• 他システムとの連携が必要か
• 現行システムの仕様書やデータ構造の資料が残っているか

特にデータ移行は、範囲によって工数が変わりやすい項目です。

直近1年分だけを移行するのか、過去すべてを引き継ぐのかで、変換作業と検証作業の量が変わってきます。

また、現行システムの資料が残っていない場合は、仕様を調査する工程が別途必要になることもあります。

資料の有無は早い段階で確認しておくと、見積の精度も上がりやすくなります。

既存システムの置き換えを検討している場合は、「システムリプレイスはいつ必要？必要性の判断基準と4つの移行方式」で移行方式ごとの違いも整理しています。

要件定義書に盛り込む項目

要件定義書に決まった書式はありませんが、盛り込まれる項目にはある程度の共通点があります。 ここでは一般的に記載される項目を確認したうえで、そのなかでも特に見落とされやすい部分を整理していきます。

要件定義書の主な構成項目

1. システム化の目的と背景
2. 対象となる業務の範囲
3. 導入後の業務フロー
4. 機能要件の一覧
5. 非機能要件
6. 体制と役割分担
7. スケジュールと前提条件

このうち、見落とされやすいのが7番目の前提条件です。

前提条件には、「発注側がこの時期までに資料を提供する」「この業務ルールは変更しない」といった、成立の土台となる取り決めが記載されます。

ここが書かれていないと、条件が変わった際に責任の所在が曖昧になり、追加費用の扱いをめぐって認識の違いが生じることもあります。

要件定義の期間と費用の考え方

要件定義は、開発とは別に期間と費用が発生する工程です。 どのくらいかかるかは条件によって変わるため、ここでは期間を左右する要素と、費用の扱いにつながる契約の形を整理します。

要件定義にかかる期間の目安

要件定義にかかる期間は、システムの規模と、関係する部署の数によって大きく変わってきます。

対象が1つの業務に限られる場合と、複数部署の業務をまたぐ場合とでは、必要な打ち合わせの回数そのものが変わるためです。

そのため、一律の目安を当てはめるより、対象業務の数と関係部署の数を伝えたうえで、開発会社に類似案件での期間を確認する方法が確実です。

期間が延びる要因としては、次のようなものが挙げられます。

• 関係部署が多く、意見の集約に時間がかかる
• 現行業務が可視化されておらず、洗い出しから始める必要がある
• 社内の承認手続きに一定の期間を要する
• 要望が固まらず、方針が変わる

いずれも開発会社側の事情というより、発注側の準備状況に関わる要因が中心になります。

そのため、前章で挙げた5つの項目をあらかじめ整理しておくことが、期間の短縮にもつながりやすくなります。

要件定義の費用と契約形態

要件定義は開発とは別に費用が設定されることが多い工程です。

開発一式に含まれる場合もありますが、上流工程だけを切り出して契約する形も広く採られています。

この考え方は、IPA（情報処理推進機構）が公開している「情報システム・モデル取引・契約書」でも示されています。

開発工程を1本の契約にまとめるのではなく、工程ごとに契約を分ける多段階契約が基本とされており、何を作るかがまだ確定していない要件定義には準委任契約が、作るものが決まっている内部設計から開発・テストには請負契約が適するとされています。

準委任契約は成果物の完成ではなく作業の遂行に対して報酬を支払う形であるため、要件が固まっていない段階の工程と相性が良いと判断しています。

要件が固まっていない段階で開発まで含めた請負契約を結ぶと、見積の前提が曖昧になり、後から差額の調整が必要になることもあります。上流工程を分けて契約する進め方は、双方にとって範囲を明確にしやすい方法だと考えられます。

要件定義でつまずきやすい場面と対処法

要件定義では、似たような場面で進行が止まることがあります。あらかじめ想定しておくと、対処の判断も早くなります。

部署ごとに要望が食い違う

同じ業務でも、部署によって重視する点は異なることがあります。

営業部門は入力の手軽さを求め、経理部門は正確性を求める、といった形で要望がぶつかることも珍しくありません。

このとき有効になりやすいのが、はじめに設定した「システム化の目的」に立ち返る方法です。

どちらの要望が目的に近いかという基準があれば、部署間の優劣ではなく目的への貢献度で判断しやすくなります。

それでも決まらない場合は、意思決定者が範囲を裁定する場を設けることになります。

「現行と同じ」という要望が出る

現行システムの使い勝手を維持したいという要望はよく出るものですが、この表現のままでは要件として扱われにくいこともあります。

現行システムの仕様がすべて文書化されているとは限らず、開発会社が「同じ」の中身を判断しづらいためです。

対処としては、現行のどの部分を維持したいのかを具体化していきます。

• 画面の並び順や入力の手順を維持したい
• 帳票の様式を維持したい
• 計算のルールを維持したい

このように分解すると、維持すべき部分と見直せる部分が分かれてきます。

現行システムに合わせすぎると、古い業務手順まで引き継いでしまうこともあるため、この機会に見直す範囲を決めておく価値はあります。

長く使われてきたシステムを扱う際の考え方は、「レガシーシステムとは？放置リスクと今からできる脱却の進め方」も参考になります。

判断が保留されたまま次工程に進む

打ち合わせで結論が出なかった項目が、そのまま棚上げされることがあります。

保留のまま設計に進むと、開発会社は何らかの前提を置いて作業を進めるため、後から認識のずれが判明する可能性も出てきます。

対処としては、保留項目に期限を設ける方法が挙げられます。

「次回打ち合わせまでに決める」と決めておくだけでも、放置される項目は減りやすくなります。

要件が固まった後に追加要望が出る

合意後の追加要望は、費用と期間に影響することがあります。

すべてを断る必要はありませんが、追加として扱う基準を最初に決めておくと、その都度の交渉になりにくくなります。

具体的には、合意した要件定義書に記載がない内容は変更管理の対象とし、影響と費用を確認したうえで採否を決める、という進め方が一般的です。

完成後の確認工程で認識のずれが表面化することもあるため、「受け入れテスト（UAT）とは？検収前に確認したい5つのポイントと進め方」で検収時の観点も確認しておくと安心できます。

要件定義を任せられる開発会社の見極め方

要件定義の質は、開発会社の関わり方によっても変わる部分があります。依頼先を検討する段階で、次の点を確認しておくと判断しやすくなります。

業務の内容に踏み込んで質問してくれるか

初回の打ち合わせで、技術的な話に終始するのではなく、業務の流れや現場の事情を尋ねてくる会社は、要件定義の進め方を理解していると考えられます。

依頼側が言語化できていない部分を引き出す質問ができるかどうかが、ひとつの目安になります。

具体的には、次のような質問が出てくるかどうかを見てみてください。

• その作業は月にどのくらいの件数が発生しますか
• 例外的な処理はどの程度の頻度でありますか
• その情報は、最初に誰が入力していますか
• いまの確認作業をなくすと、どこで困りますか

いずれも機能そのものではなく、業務の量と流れを確かめるための質問です。

こうした点が分かってはじめて、作るべき機能の範囲と、システム化せずに運用で対応したほうがよい部分を切り分けられるようになります。

反対に、初回から機能の一覧と概算金額だけが提示される場合は、業務の実態が反映されないまま見積が組まれている可能性も残ります。

曖昧な要望を整理して返してくれるか

「効率化したい」といった漠然とした要望に対し、想定される選択肢とそれぞれの影響を示してくれるかどうかも判断材料になります。

要望をそのまま受け取って見積を出す会社より、前提を確認したうえで範囲を提案する会社のほうが、後の認識のずれは起きにくくなります。

上流工程だけの相談にも応じてくれるか

開発まで一括で契約しなければ相談できない場合、方針が固まる前に発注を決める必要が生じることもあります。

要件定義のみ、あるいは実現性の検証のみといった単位で相談できる体制があるかどうかは、初めての依頼では特に確認しておきたい点になります。

まとめ

要件定義は、システムで実現したいことを整理し、開発の範囲を確定させる工程です。

進め方としては、現状業務の洗い出し、目的の設定、機能要件の定義、非機能要件の定義、要件定義書の合意という5つのステップで進んでいきます。

そのうえで、発注側があらかじめ決めておきたいのが、課題の優先順位、予算の上限、稼働希望時期、意思決定者と窓口、既存システムとデータの扱いという5つの項目です。

これらが整理されているかどうかで、要件定義にかかる期間と、完成したシステムの納得感は大きく変わってきます。

すべてを完璧に固める必要はなく、社内で共有された方針として持っておくだけでも、打ち合わせの進み方は変わってきます。

分からない部分は開発会社と一緒に整理していく前提で、まずは手元で答えられる範囲から書き出してみることをおすすめします。

要件定義から相談できるシステム開発なら株式会社アレグビット

要件定義は、業務の理解と技術の知見の両方がそろって形になっていく工程です。

そのため、「何から整理すればよいか分からない」「要望はあるが機能に落とし込めない」といった段階でのご相談も少なくありません。

株式会社アレグビットでは、AIの活用も含めたシステム開発について、上流工程の段階から無料でご相談いただけます。

• 他社が開発したシステムの改善や機能追加も対応可能です
• 小さなPoCや自動化ツールの導入からでも承ります
• 技術選定や進め方のご相談のみでも歓迎しています

いずれも、開発の発注を前提としないご相談として承っております。

現状の課題を伺いながら、システム化すべき範囲と、運用で対応したほうがよい範囲を一緒に整理していく形も可能です。

要件定義の進め方でお悩みの方は、株式会社アレグビットまでお気軽にお問い合わせください。