SIerの要件定義とは？誰がやるかや進め方、上流工程の経験を積む方法を解説

「要件定義を任されたけれど、どこまで自分が決めればよいのか分からない」「顧客に丸投げされて困っている」と悩んでいるSIerのエンジニアは少なくありません。要件定義は、発注者とSIerが協力して「何を、なぜ、どこまで作るか」を決める工程です。要件を最終的に決めるのは発注者であり、SIerは要求を整理して実現方法を提案する役割を担います。

この記事では、要件定義の基本と役割分担、具体的な進め方、要件定義書の項目、見積もりとの関係、つまずきやすい場面の対処法を解説します。あわせて、SIerで要件定義の経験を積む方法や転職時の考え方も紹介します。

SIerにおける要件定義とは

要件定義の目的は「何を、なぜ、どこまで作るか」を決めること

要件定義とは、システム開発の最初の段階で、顧客の要望をもとにシステムで実現する内容と範囲を決める工程です。設計や開発より前に行うため、上流工程と呼ばれます。要件定義で関係者の認識をそろえるべき点は、主に次の3つです。

• 何を作るか：必要な機能や性能を決めます
• なぜ作るか：導入の目的や解決したい課題を確認します
• どこまで作るか：システム化する業務の範囲を決めます

この3点が決まっていれば、設計やテストで迷ったときに立ち返る基準ができます。反対にこの3点が曖昧なまま進むと、工程が進むほど判断がぶれやすくなり、手戻りの原因になります。

要求定義、要件定義、基本設計の違い

要件定義と混同しやすい工程に、要求定義と基本設計があります。違いは次のとおりです。

工程	決めること	例
要求定義	顧客が実現したいこと	受注処理を早くしたい
要件定義	システムで実現すること	受注データを自動で取り込む機能を用意する
基本設計	どう実現するか	取り込み画面の項目や処理の流れを決める

工程は要求定義、要件定義、基本設計の順に進みます。要求は顧客の希望そのもので、要件はそれを予算や技術の制約に照らして「作るもの」として整理した結果です。基本設計は外部設計とも呼ばれ、要件を画面や帳票などの形に落とし込む工程にあたります。

要件定義書と仕様書の違い

要件定義書と仕様書は、どちらもシステムの内容を記した文書ですが、作る時期と読み手が異なります。要件定義書は、要件定義の工程で作成する文書です。発注者とSIerが合意した「作るべき内容」をまとめたもので、業務部門の担当者や決裁者も読むことを前提に書きます。そのため、専門用語をできるだけ避け、業務の言葉で説明するのが一般的です。

一方の仕様書は、設計の段階で作成する文書で、画面の項目や処理のルールなどを詳しく記載します。主な読み手は開発を担当するエンジニアです。要件定義書が「何を作るか」の合意の記録であるのに対し、仕様書は「どう作るか」の指示書だと考えると区別しやすくなります。

SIerの要件定義は誰がやる？発注者との役割分担

要件を最終的に決めるのは発注者という考え方

要件定義は「SIerがやる仕事」と思われがちですが、要件を最終的に決めるのは発注者であるユーザー企業だという考え方が一般的です。その理由は、業務の内容や課題を最もよく理解しているのが発注者だからです。どの業務をシステム化するのか、どの機能を優先するのかは、事業の方針や予算と切り離せない判断であり、外部のSIerだけでは決めきれません。

経済産業省が公開している情報システムの契約モデルでも、要件定義は発注者が主体となり、ベンダーがそれを支援する工程として整理されています。SIerは要件を「決める」立場ではなく、発注者が判断できるように材料をそろえ、支える立場だと理解しておくとよいでしょう。

SIerが担う役割は要求の整理と実現方法の提案

発注者が要件を決める立場だとすると、SIerは要求を整理し、実現方法を提案する役割を担います。

具体的には、ヒアリングで顧客の要望を聞き取り、背景にある課題を整理したうえで、システムでどう実現するかを提案します。発注者は業務には詳しくても、ITの専門知識を持っているとは限りません。そのため、次のような技術面の判断を伝えることもSIerの大切な仕事です。

• 要望が技術的に実現できるかどうかを示します
• 実現にかかるコストや期間の目安を伝えます
• 想定されるリスクや代わりの方法を提案します

発注者が納得して判断できる情報を出すことが、SIerに求められる専門性です。

SIer社内でのPM、PL、SEの分担

SIerの社内では、要件定義の作業を役職ごとに分担して進めるのが一般的です。

役職	主な役割
PM（プロジェクトマネージャー）	全体の進行管理、発注者との合意形成、予算と体制の管理
PL（プロジェクトリーダー）	担当範囲のとりまとめ、メンバーへの作業の割り振り
SE（システムエンジニア）	ヒアリング、議事録や要件定義書の作成、技術面の調査

ただし、この分担はプロジェクトの規模によって変わります。小規模な案件では、PMがヒアリングから文書作成まで一人で担うこともあります。反対に大規模な案件では、業務領域ごとにチームを分け、複数のPLが並行して要件を詰めていくケースもあります。

「丸投げ」を防ぐには発注者と一緒に要件を固めることが大切

発注者から「プロに任せます」と要件定義を丸投げされることは、SIerの現場では珍しくありません。しかし、SIerだけで要件を決めると、業務上の抜け漏れや認識のずれが起きやすくなります。丸投げを防ぐには、プロジェクトの始めに次の点を発注者と合意しておくことが有効です。

• 発注者側で要件を判断する担当者と決裁者を決めます
• 打ち合わせへの参加者と頻度を決めます
• どの項目を誰が決めるのかを一覧にして共有します

役割分担を文書に残しておけば、後で「任せたはずだ」と言われる事態を防げます。発注者を巻き込むことは、SIerを守るだけでなく、よいシステムを作るためにも必要なことです。

SIerにおける要件定義の進め方

システム導入の背景、目的と関係者を確認する

要件定義の最初の段階では、なぜシステムが必要なのか、誰が関わるのかを確認します。導入の背景や目的は、後の判断すべての基準になります。「業務の手間を減らしたい」のような大まかな表現で終わらせず、「月末の集計作業にかかる時間を半分にしたい」といった具体的な目標まで確認しておくと、要件の優先順位を付けやすくなります。

あわせて、意見を聞くべき関係者を整理します。決裁者、業務部門の責任者、実際にシステムを使う現場の担当者、情報システム部門などが代表的です。関係者の洗い出しが遅れると、終盤になって新しい要望が出てきて手戻りの原因になるため、早めに確認しておくことが大切です。

現行業務と既存システムを把握する

次に、今の業務の流れと既存システムの仕組みを把握します。現状を正しく理解しないまま新しい仕組みを考えると、現場で使われないシステムになるおそれがあるためです。現行業務を把握する方法としては、次のようなものがあります。

• 現場の担当者に一日の作業の流れを聞き取ります
• 業務マニュアルや帳票、画面のキャプチャを確認します
• 既存システムの設計書や運用手順書を読み込みます

集めた情報は業務フロー図などにまとめると、関係者と共有しやすくなります。現状の流れが見えると、「どこに手間がかかっているか」「どこでミスが起きやすいか」といった課題が具体的に見えてきます。

ヒアリングで要求を引き出し、優先順位を付ける

現状を把握したら、ヒアリングで発注者の要求を引き出します。このとき、要望をそのまま受け取るのではなく、5W2H（いつ、どこで、誰が、何を、なぜ、どのように、いくらで）の観点で背景まで確認することが大切です。

集めた要望は、すべてを実現しようとすると予算や期間に収まらないことがほとんどです。そこで、優先順位を付けて整理します。よく使われる方法に、要望を次の4つに分けるMoSCoW分析があります。

• Must：必ず実現する
• Should：できるだけ実現する
• Could：余裕があれば実現する
• Won’t：今回は見送る

判断に迷ったときは、最初に確認した導入目的に照らして考えます。

システム化の範囲を決め、機能要件と非機能要件を定義する

要求を整理したら、システムで対応する範囲と、運用でカバーする範囲を分けます。すべての業務をシステム化する必要はなく、発生頻度の低い例外処理などは手作業で対応したほうがコストを抑えられる場合もあります。範囲を決めたら、要件を次の2種類に分けて定義します。

• 機能要件：データの登録、検索、帳票の出力など、システムが持つべき機能です
• 非機能要件：処理速度、稼働時間、セキュリティなど、機能以外に求められる品質です

機能要件は発注者から要望として出てきやすい一方で、非機能要件は意識されにくい傾向があります。SIerの側から確認項目を示し、機能と同時に決めていくことが大切です。

要件定義書にまとめ、レビューを経て合意する

決めた内容は要件定義書にまとめ、関係者のレビューを受けます。レビューは、発注者だけでなく、SIer社内の設計や開発の担当者にも依頼するのが望ましい進め方です。発注者は業務の視点から内容に誤りがないかを確認し、開発担当者は技術的に実現できるか、記載が曖昧で解釈が分かれる箇所がないかを確認します。

指摘を反映したら、発注者の決裁者から正式な承認を得て、要件定義は完了です。承認の記録を残しておくことで、合意した内容が後から変わったときに、どの時点で何を決めたのかを確認できます。この記録は、後の工程で認識の違いが生じたときの判断材料にもなります。

要件定義書にまとめる主な項目

背景、目的、システム化の範囲

要件定義書の冒頭には、システム導入の背景と目的、システム化の範囲を記載します。背景には、現状の業務で起きている課題や、システムを導入するに至った経緯を書きます。目的には、システムによって何を実現したいのかを、できるだけ具体的な言葉で記載します。数値で表せる目標がある場合は、あわせて書いておくと効果を確認しやすくなります。

システム化の範囲には、対象となる業務や部門、利用者を明記します。あわせて「今回は対象外とする業務」も書いておくと、後で範囲をめぐる認識のずれが起きにくくなります。この項目は、関係者全員が同じ目的を共有するための土台となる部分です。

業務要件と機能要件

業務要件と機能要件は、要件定義書の中心となる項目です。業務要件には、システム導入後の業務の流れを記載します。誰が、いつ、どの作業を行うのかを業務フローとして整理し、現状と比べてどこが改善されるのかを示します。

機能要件には、業務要件を実現するためにシステムが持つべき機能を記載します。機能一覧の形で整理し、それぞれの機能について入力するデータ、処理の内容、出力される結果を書くのが一般的です。

書くときは、業務要件のどの部分をどの機能で実現するのかがつながるように意識します。つながりが見えると、発注者は機能の必要性を理解しやすくなり、不要な機能が紛れ込むことも防げます。

非機能要件（性能、可用性、セキュリティ、移行、運用保守）

非機能要件は、機能以外にシステムに求められる品質を定めた項目です。主な観点は次のとおりです。

観点	決める内容の例
性能	画面の応答時間、同時に利用できる人数
可用性	稼働する時間帯、障害時の復旧目標
セキュリティ	利用者の認証方法、アクセス権限の管理
移行	既存データの移し替えの方法と時期
運用保守	バックアップの方法、問い合わせの対応体制

非機能要件は、発注者から要望として出てきにくいため見落とされやすい項目です。しかし、リリース後に「処理が遅くて使えない」といった問題が起きると、大きな改修が必要になることもあります。早い段階で確認しておくことが大切です。

テンプレートやサンプルを参考にするときの注意点

要件定義書を初めて作成するときは、テンプレートやサンプルを参考にする人も多いでしょう。一般的な記載項目がそろっているため、項目の抜け漏れを防ぐのに役立ちます。ただし、テンプレートの項目をそのまま埋めるだけでは、案件ごとの事情が反映されません。たとえば、社内だけで使う小規模なシステムと、多くの顧客が利用するサービスとでは、重視すべき非機能要件が大きく異なります。

テンプレートを使うときは、まず自分の案件に必要な項目かどうかを判断し、不要な項目は削り、足りない項目は追加します。過去に社内で作成された同じ業界の要件定義書があれば、あわせて参考にすると実務に近い書き方を学べます。

要件定義はどこまで決める？細かさと合意の考え方

細かすぎても粗すぎても問題が起きる

要件定義で「どこまで細かく決めるか」は、多くの担当者が悩むポイントです。細かすぎる場合と粗すぎる場合には、それぞれ次のような問題が起きやすくなります。

状態	起きやすい問題
細かすぎる	要件定義に時間がかかり、開発の開始が遅れる
粗すぎる	設計や開発の段階で解釈が分かれ、手戻りが発生する

適切な粒度の目安は、「設計の担当者が読んだときに、何を作ればよいかを迷わず判断できるか」です。画面の配置やボタンの色のような細部は基本設計で決め、要件定義では実現する機能とその条件を明確にすることに集中すると、時間をかけすぎずに必要な内容を押さえられます。

変更ルールと決定履歴を残しておく

要件は、プロジェクトの途中で変わることがあります。業務の見直しや組織の変更など、発注者側の事情で変更が必要になるのは自然なことです。問題になるのは、変更の扱い方が決まっていない場合です。

そこで、要件定義の段階で次のようなルールを決めておきます。

• 変更の要望をどの窓口で受け付けるかを決めます
• 変更を認めるかどうかを誰が判断するかを決めます
• 費用や納期に影響する場合の扱いを決めます

あわせて、打ち合わせの議事録や決定事項の履歴を残し、発注者と共有しておきます。記録があれば、「言った、言わない」の食い違いが起きたときにも、事実にもとづいて話し合うことができます。

試作画面やプロトタイプで認識をそろえる

要件定義書を丁寧に作っても、文書だけでは完成したシステムをイメージしにくい発注者は少なくありません。その結果、開発が進んでから「思っていたものと違う」と言われることがあります。

こうしたずれを減らすには、早い段階で試作画面やプロトタイプを見てもらう方法が有効です。手書きの画面イメージや簡単なモックアップでもかまいません。実際の画面に近いものを見ることで、発注者は「この項目も必要だった」「この順番のほうが使いやすい」といった具体的な意見を出しやすくなります。プロトタイプで確認した内容は、要件定義書にも反映して記録を残しておきます。

要件定義と見積もりの関係

要件定義と見積もりはどちらが先か

原則として、正確な見積もりは要件定義が終わった後でなければ出せません。作るものの内容や範囲が決まっていなければ、必要な工数を正しく計算できないためです。

しかし実務では、要件が固まる前の段階で、発注者から金額を求められることがよくあります。発注者の多くは、社内で予算を確保するために、早い時期に金額の目安を示す必要があるからです。

つまり、「要件が決まらないと見積もれない」というSIerの事情と、「金額が分からないと予算を取れない」という発注者の事情がぶつかることで、この順番の問題が起きます。どちらかが間違っているわけではないため、双方の事情を踏まえた進め方を考えることが大切です。

概算見積もりと詳細見積もりを段階的に出す

見積もりの順番の問題に対しては、見積もりを段階的に出す進め方が一般的です。

段階	時期	位置づけ
概算見積もり	要件定義の前	予算確保のための目安で、金額に幅を持たせる
詳細見積もり	要件定義の後	決まった要件にもとづく、精度の高い金額

概算見積もりを出すときは、過去の似た案件の実績などを参考に、金額に幅を持たせて提示します。そのうえで、「要件が固まった段階で詳細見積もりを出し直す」ことを発注者に伝え、合意しておくことが大切です。あわせて、どの範囲を含めて算出したのかという前提条件を明記しておくと、後で金額が変わったときにも理由を説明しやすくなります。

要件定義フェーズを分けて契約する考え方

見積もりの精度を高める方法として、要件定義と開発を別の契約に分ける考え方があります。経済産業省の契約モデルでは、要件定義を準委任契約、設計以降の開発を請負契約とするなど、工程ごとに契約を分ける多段階契約が示されています。準委任契約は作業を行うこと自体に対して対価を支払う契約で、請負契約は完成したシステムに対して対価を支払う契約です。

要件定義を独立した契約にすると、要件が固まった後に開発の見積もりを出せるため、金額の根拠が明確になります。発注者にとっても、要件定義の結果を見てから開発を進めるかどうかを判断できるという利点があります。

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

顧客の要望をそのまま要件にしてしまう

経験の浅い担当者に多いのが、顧客の要望をそのまま機能として要件に書いてしまうケースです。たとえば、「Excelに出力する機能がほしい」という要望があったとします。そのまま機能を作ることもできますが、理由を確認すると「出力したデータを手作業で集計している」という課題が見えることがあります。この場合は、システム上で集計まで行える機能を提案したほうが、目的に合った解決策になるかもしれません。

要望を受けたときは、「なぜ必要なのか」「何に使うのか」を確認し、背景にある目的を理解することが大切です。要望と要件を分けて考えることで、発注者にとって本当に役立つシステムに近づけます。

非機能要件の確認が漏れる

要件定義での考慮漏れとして特に多いのが、非機能要件の確認不足です。打ち合わせでは画面や機能の話が中心になりやすく、性能や運用に関する確認が後回しになりがちです。

非機能要件の確認漏れを防ぐには、公的なガイドラインを参考にする方法があります。情報処理推進機構（IPA）が公開している「非機能要求グレード」では、非機能要件を次の6つの大項目に分けて整理しています。

• 可用性
• 性能、拡張性
• 運用、保守性
• 移行性
• セキュリティ
• システム環境、エコロジー

こうした項目を確認の観点として使い、発注者と一つずつ合意していくと漏れを減らせます。

要件漏れが起きたときの責任の考え方

開発の途中や完成後に要件漏れが見つかると、費用を誰が負担するのかをめぐって揉めることがあります。責任の所在は、契約の内容や、その要件をどの段階でどちらが把握できたかによって判断されるため、一律には決まりません。請負契約で、合意した内容どおりに作られていない場合は、SIerが契約不適合責任を問われることがあります。

一方で、発注者から必要な情報が示されていなかった場合には、発注者側の責任とされることもあります。こうした争いを避けるには、役割分担や確認の手順を事前に決め、合意した内容を記録に残しておくことが大切です。明確な記録は、発注者とSIerの双方を守ることにつながります。

要件定義に必要なスキルと、苦手意識があるときの向き合い方

要件定義に求められる主なスキル

要件定義には、技術の知識だけでなく、人と関わる力や考えを整理する力が求められます。主なスキルと、それが必要になる場面は次のとおりです。

スキル	必要になる場面
ヒアリング力	要望の背景にある課題を聞き出すとき
業務理解	顧客の業務の流れや用語を理解するとき
論理的思考力	要望を整理し、要件に落とし込むとき
文書化の力	誰が読んでも同じ意味に取れる要件定義書を作成するとき
調整力	関係者の意見が対立したときに合意をまとめるとき

これらのスキルは、最初から身についている必要はありません。日々の業務や打ち合わせの中で意識して取り組むことで、少しずつ伸ばしていくことができます。

要件定義が苦手と感じやすい人の傾向

要件定義が苦手だと感じる人には、いくつかの共通した傾向があります。

• 要望をそのまま受け取り、背景を確認しないまま進めてしまいます
• 「なるべく早く」「いい感じに」といった曖昧な表現を残したまま文書にしてしまいます
• 分からないことを顧客や先輩に質問できず、一人で抱え込んでしまいます

これらは能力の問題ではなく、経験の中で改善できる習慣です。たとえば、要望を聞いたら必ず「なぜ」を一度確認する、曖昧な言葉は数値や具体例に置き換える、といったことを意識するだけでも、要件の質は変わってきます。「できない」と思い込まず、改善できる点から取り組むことが大切です。

若手がいきなり要件定義を任されたときの進め方

経験が少ないまま、いきなり要件定義を任されて不安を感じる若手エンジニアも少なくありません。このようなときは、一人で抱え込まず、周囲の力を借りながら進めることが大切です。具体的には、次のような方法から始めてみてください。

• 社内の過去の要件定義書を読み、書き方や項目の粒度をつかみます
• 打ち合わせの議事録を担当し、決まったことを整理する練習をします
• 作成途中の文書を早めに先輩やPMに見せ、レビューを依頼します

完成してから見せるのではなく、途中の段階で確認を受けることで、大きな手戻りを防げます。分からないことを早めに質問するのも、要件定義の大切な仕事の一つです。

SIerで要件定義の経験を積むには

下流工程から担当範囲を広げていくのが一般的

SIerでは、多くの場合、プログラミングやテストといった下流工程から経験を積み、詳細設計、基本設計、要件定義へと担当範囲を広げていきます。

下流工程の経験は、要件定義でも役に立ちます。開発やテストを経験していると、要件のどこが曖昧だと実装で困るのか、どの記載が不足するとテストで問題が見つかるのかが分かるためです。こうした経験を持つ人が要件定義を担当すると、後工程の担当者にとって分かりやすい要件定義書を作成できます。

今は下流工程が中心であっても、その経験は上流工程へ進むための土台になります。日々の仕事で、要件定義書や設計書を読む習慣をつけておくとよいでしょう。

会社の立ち位置によって要件定義に関わる機会は変わる

要件定義に関わる機会は、個人の努力だけでなく、所属する会社の立ち位置にも左右されます。SIer業界では、発注者から直接仕事を受ける一次請け（プライム）の企業が要件定義を担い、その後の設計や開発の一部を二次請け、三次請けの企業に発注する多重下請けの構造が見られます。そのため、発注者と直接取引する案件が多い会社ほど、要件定義に関わる機会が増えやすくなります。

また、SESのように客先で作業する働き方では、参画する案件によって担当工程が決まるため、上流工程の経験を積めるかどうかは配属先に左右されやすくなります。自分の会社がどの位置で仕事を受けているかを確認しておくことが大切です。

要件定義の経験を目指して転職するときの考え方

企業選びで確認したいポイント

今の環境では要件定義に関わる機会が少ないと感じる場合は、転職も選択肢の一つです。ただし、求人票に「上流工程あり」と書かれているだけで判断するのは避けたほうがよいでしょう。企業を選ぶときは、次のような点を確認することをおすすめします。

• 要件定義から参画する案件がどのくらいの割合を占めているか
• 入社後、どのような流れで上流工程を任されるようになるか
• 若手が顧客との打ち合わせに参加する機会があるか

これらは求人票だけでは分からないことが多いため、面接の逆質問などで確認します。実際に要件定義を担当している社員の経験年数や経歴を聞くと、入社後の姿を具体的にイメージしやすくなります。

面接で要件定義への意欲と経験を伝える方法

要件定義の経験が少なくても、これまでの仕事の中に評価につながる材料は多くあります。大切なのは、その経験を要件定義につなげて伝えることです。たとえば、次のような経験は要件定義に近い取り組みとして伝えられます。

• 顧客や社内の担当者から仕様を確認し、認識のずれを防いだ経験
• 設計やテストの段階で要件の曖昧な点に気づき、改善を提案した経験
• 議事録や手順書を作成し、関係者の情報共有を助けた経験

伝えるときは、どのような状況で、何を考え、どう行動し、どのような結果になったのかを具体的に話すと説得力が増します。職務経歴書にも同じ観点で記載しておくと、面接での話と一貫性を持たせることができます。

転職エージェントで企業ごとの実情を確認する

求人票だけでは、入社後に実際どの工程を担当できるのかは分かりにくいものです。「上流工程に携われる」と書かれていても、配属先によっては下流工程が中心になることもあります。

こうした実情を確認する方法として、転職エージェントの活用が挙げられます。IT業界に詳しいエージェントは、企業ごとの案件の傾向や、若手が要件定義を担当するまでの流れなど、求人票に載っていない情報を持っていることがあります。

また、自分の経験がどの企業で評価されやすいか、職務経歴書でどの点を強調すべきかといった相談もできます。要件定義の経験を積める環境を効率よく探したい人は、エージェントに相談してみるとよいでしょう。

SIerの要件定義に関するよくある質問と回答

まとめ

要件定義は発注者とSIerが協力して「何を作るか」を決める工程

要件定義は、システム開発の最初に「何を、なぜ、どこまで作るか」を決める工程です。要件を最終的に決めるのは業務を最もよく知る発注者であり、SIerは要求を整理し、実現方法を提案する役割を担います。進めるときは、目的と関係者の確認、現行業務の把握、ヒアリング、範囲と要件の定義、要件定義書のレビューという流れを押さえておきましょう。

また、変更ルールや決定履歴を残すこと、見積もりを段階的に出すこと、プロトタイプで認識をそろえることは、丸投げや要件漏れ、「言った、言わない」といったトラブルを防ぐうえで役立ちます。

日々の業務から経験を積むことが上流工程への近道

要件定義に苦手意識があっても、必要なスキルは経験の中で少しずつ身につけていけます。過去の要件定義書を読む、議事録を担当する、先輩にレビューを依頼するといった行動は、今日からでも始められます。

一方で、要件定義に関わる機会は、会社の立ち位置や案件の商流によっても変わります。今の環境で上流工程に近づく努力を続けながら、それでも機会が得られない場合は、要件定義から参画できる企業への転職を考えるのも一つの方法です。自分に合った環境で着実に経験を積み、発注者から信頼されて要件定義を任される人材を目指していきましょう。