システム開発における要件定義の進め方7ステップ｜注意点やポイントを解説

要件定義とはどのようなシステムを開発するかをまとめること

要件定義とは、システム開発における発注（クライアント）側のリクエストを、開発者としての観点からまとめて文書化する工程のことです。

開発するシステムの目的や機能の検討以外にも、スケジュールや予算、人員確保など、事前に想定しておくべきことを要件定義工程で検討します。システム開発に着手する前に、各項目を定義づけてまとめることが重要です。

要件定義はシステム開発の成功を左右する根幹となる工程

要件定義は開発の完遂を方向づける重要度が最も高いプロセスであり、システム開発の成功を左右する根幹となる工程です。

要件定義を取りこぼすことなく決定することで、開発途中での仕様変更を最小限に抑え、時間とコストを圧迫せずに余裕を持って納期を迎えられます。

発注側が誤解している事例で多いのが、要求定義を渡した後は受注側に任せきりで問題ないと思い込んでいるケースです。要件が曖昧な場合や細かなすり合わせをおこなわない場合、受注側にきちんと要望が伝わらない可能性があります。

要件定義の手違いによって、無駄なコストと時間が発生しないよう、細部のすり合わせまでしっかり取り組むことが重要です。

要件定義と似ている用語をチェック

システム用語には似た言葉が多く存在しますが、曖昧なまま進めると担当者間での認識相違により重大なトラブルにつながることもあります。なんとなくで進めるのではなく、用語の意味の違いをしっかりチェックしておくことが大切です。

要件定義と意味が混同しがちな用語には、以下の3つがあります。

各用語の違いを下記で解説します。

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

要件定義と似ている用語に「要求定義」があります。要求定義とは、要件定義に入る前にクライアントからどのようなシステムを作りたいのか要望を聞き出し、整理する作業のことです。要求定義は要件定義工程の一部と考えて問題ありません。

要求定義をしっかりおこなうことで、的確な要件定義を定めることが可能です。クライアントの要望をただ聞き出すだけではなく、開発者が細かく説明できるレベルまで落とし込む必要があります。

「要件定義」と「基本設計」の違い

要件定義と似ている用語に「基本設計」が挙げられます。基本設計とは、要件定義のひとつ後の開発工程であり、システムの大枠を設計することです。要件定義の内容に基づき、機能ごとにどういった開発を進めていくのかを決定します。

「システム要件定義」と「ソフトウェア要件定義」の違い

要件定義と似ている用語の3つ目は「ソフトウェア要件定義」です。要件定義はソフトウェア要件定義と比較して「システム要件定義」と表現されることがあります。

システムの要件定義はクライアントからの要望を聞き出して内容を固める作業です。ソフトウェア要件定義は、コンピュータによって処理される「ソフトウェア」に求められる事項を開発者側の視点で定義する作業を指します。

ソフトウェアは詳細に検討する必要のある重要な部分です。ユーザーが操作をおこなうために利用する「ユーザーインタフェース」や情報を蓄積するための「データべース」など、さまざまな要素から構成されています。

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

要件定義を漏れなくしっかり固めるためには、以下の7つの手順に沿って進めることが大切です。

下記で詳しく解説します。

1. 実現したいシステム要件をヒアリングする（要求定義）

要件定義のはじめには、まずクライアントの要望を聞き出す要求定義をおこないます。開発側は、クライアントが要望するニーズだけではなく、専門知識を活かして潜在的な開発ニーズを聞き出すことも大事です。

発注側は受け身ではなく、共同で進めている意識が重要となります。

2. クライアントから聞き出した要求定義の内容を整理する

要件定義の2つ目のステップでは、システムを開発することでどのような業務課題をクリアできるのか、クライアントの要求を整理します。

現状課題の洗い出しや、システムでの実現可能性をよく検討することが大切です。開発側がクライアント目線で細かく要件を説明できるレベルまで、細かくすり合わせしましょう。

3. 開発するシステムの全体構造を明確化する

要件定義の3つ目のステップでは、開発するシステムの全体構造を明確化します。解決したい課題と目的に沿って、システム全体の構造を決める段階です。

機能の細かい内容などはまだ決めずに、一般的にはビジネスプロセス図や業務フロー図、システム化業務フローなどのフローチャートで全体の構成を図式化します。

4. 機能要件を決定する

システム全体の構成や内容が決定したら、要件定義の4つ目のステップで機能要件の検討に移ります。機能要件とは、システム開発においてクライアントから要求される機能のことです。

業務効率化や業務課題に直結するため、業務を具体的にどのように改善するのかが内容に含まれます。

細かい機能の内容は後の設計工程で決めるため不要ですが、大まかにどのような機能を実装するべきかを要件定義工程でまとめておくことが大切です。

5. 非機能要件を決定する

要件定義の5つ目のステップでは、非機能要件を決定します。非機能要件とは「機能以外」のユーザビリティ、性能、拡張性、セキュリティなどの品質的に関連するもの全般です。

たとえば、処理速度や表示速度など、ユーザーにとってストレスを感じやすい部分や、近年高まっているマルウェアなどの脅威が関係します。非機能要件の検討では、画面のレイアウトやウイルス対策ソフトも考慮することが重要です。

機能要件定義と同様に、非機能要件も要件定義工程の段階でしっかり定義しましょう。

6. 工数の見積もりやスケジュール設定をおこなう

要件定義の6つ目のステップでは、工数の見積もりやスケジュール設定をおこないます。ステップ1〜5にてシステムの全体構成や機能・非機能要件が決まれば、ある程度の工数や開発にかかる期間が算出できるでしょう。

要件定義後の工程も含め、全体のスケジュールや見積もり作業をおこなうことも重要です。

7. 要件定義書を作成する

これまでの工程において要件定義に必要な情報の洗い出し、整理が完了したら、最後に書面に書き起こして要件定義書を作成する作業に移ります。

要件定義書に記載する主な項目は以下のとおりです。

• どのような業務課題を解決するかの「システム開発の目的」
• 業務における現状の問題
• システムの全体像
• 開発したシステムを導入する環境
• 機能要件の内容
• 非機能要件の内容
• 工数や見積もり結果
• 全体スケジュールやシステムのリリース日
• 開発メンバー
• 開発側と発注側における連絡方法や連絡頻度
• セキュリティの対策方法

要件定義は最終的にクライアント（発注者）に確認してもらうことが一般的です。ITリテラシーのないクライアントにもわかるような内容の記述を意識することや、わかりやすく説明できるよう準備しておくといいでしょう。

要件定義における発注（クライアント）側の注意点

要件定義における発注（クライアント）側の注意点には、次の3つが挙げられます。

下記で詳しく解説します。

システムについての価値判断を統一する

要件定義における発注側の注意点の1つ目は、システムについての価値判断を統一することです。発注側は、システム化する目的やどこまでの業務範囲をシステム化するのかなど、社内における主義主張を統一しておく必要があります。

要件定義工程では、受注側から機能要件と非機能要件の提言を受けたうえで、発注側にて見極めをつける局面が生じることもあるでしょう。

社内における主義主張は要件定義における判断のバロメーターとなるため、担当者によって主張がブレないよう認識を統一することが重要です。

解決するべき問題を事前に明確化する

要件定義における発注側の注意点2つ目は、解決するべき問題を事前に明確化することが挙げられます。現状課題を洗い出すための情報収集活動は多大な労力がかかってしまうため、業務フローと業務要件の整理は要件定義より前にしておくのがベストです。

自社の課題や、課題解決のためにシステムに搭載したい機能などを記載した「提案依頼書（Request for Proposal）」を作成する方法もあります。

現場におけるシステムの必要性を正確に把握する

要件定義における発注側の注意点3つ目には、現場におけるシステムの必要性を正確に把握することが挙げられます。現場の現状調査やデータ分析にもとづいて、現状を正確に把握しましょう。

実務的な問題点や課題を感じているのは現場担当者です。システム開発部門だけで判断するのではなく、実務担当者へヒアリングやアンケートを実施する必要があります。

現場のニーズを事細かに汲み取ることによって、要件定義で受注側に伝える際に情報が歪曲しないでしょう。

要件定義における受注（開発）側の注意点

要件定義における受注（開発）側の注意点には、以下の4つがあります。

下記で詳しく解説します。

潜在的な要望を聞き出して提案することを意識する

要件定義における受注側の注意点として、潜在的な要望を聞き出して提案することを意識しましょう。発注側はシステムの専門家でない場合が多いため、自分自身で理解することが可能である領域でしかシステム要件の要望を思い付かない可能性が高いです。

現行システムの仕様や仕組みなどは、受注側で事前に調査しておく必要があります。事前調査では、発注者へのヒアリングで知りたいことを聞いて潜在的な要望をさぐり出すことが大切です。

発注側における本来の要望をさぐり出すためには、要望を聞くだけではなく、開発者目線から要望を導き出すスタンスで要件定義することを意識しましょう。

要望を叶えるだけではなく常に最適解を模索する

要件定義における受注側の注意点の2つ目は、発注者の要望を叶えるだけではなく常に最適解を模索することが挙げられます。発注者は、実現したい機能があっても最適解の方法で機能の要望を出せるわけではありません。

開発者だからこそできる提案を交えながらクライアントの要望を聞き出し、双方合意のうえでシステム開発を進められるようにすることが大切です。

要領を得たドキュメントの作成を意識する

要件定義における受注側の注意点3つ目には、要領を得たドキュメントの作成を意識することが挙げられます。要件定義書やワイヤーフレームなどを作成する際に関係者間の認識相違が起きないよう、発注者が要望するシステムの的を得た資料を作成することが大切です。

発注側と受注側が限られた時間のなかで要件定義を進めるために、意見調整をおこなう日程管理も重要となります。

幅広いITスキルや知識を習得する

要件定義における受注側の注意点4つ目は、幅広いITスキルや知識を習得することです。システム開発はクライアントの業務課題を解決することが目的であるため、開発者側が受け身の体制で要望を聞いて開発するだけではうまくいかないでしょう。

開発者目線での専門知識を活かした十分な提案をおこなう必要があるため、システム開発の経験を十分に積む必要があります。適切な要件定義をおこなうには、自らシステムを設計できるくらいのスキルがあるといいです。

要件定義で失敗しないための進め方とポイント

要件定義で失敗しないためのポイントを3つ紹介します。

下記で詳しく解説します。

システム開発で実現したい機能を明らかにする

要件定義で失敗しないための進め方のポイントとして、システム開発で実現したい機能を明らかにすることが挙げられます。システム開発が必要な理由や、システムを導入する目的を誰の目にも明らかにしておくことが大切です。

搭載するべき機能を明らかにしておくことで、システム開発の優先順位が決まりやすいでしょう。

発注側と受注側で認識相違がないよう細かくすり合わせする

要件定義で失敗しないための進め方のポイントとして、発注側と受注側で認識相違がないよう細かくすり合わせることも大切です。

開発途中や開発後に思っていたのと違ったと後悔することは避けなければなりません。システム開発に求める目的や指針を共有することで、お互いの意見に食い違いが起きないように話し合いましょう。

スケジュールやロードマップを共有する

要件定義で失敗しないための進め方として、スケジュールやロードマップを作成することもポイントです。システム要件や機能に基づいて、あらゆるプロセスやタスクにスケジュールを作成し、スタートアップ後の体制を整えておきましょう。

他にも、リリース後のシステムは想定されていない使われ方がされてしまうことも考慮する必要があります。要件定義の段階からシステムエラーが発生した際の対応策も検討し、ロードマップに組込みましょう。

要件定義後のシステム開発の進め方

要件定義工程が終わったら、要件定義書が土台となりその後の開発が進みます。要件定義後の各開発工程は以下のとおりわかれています。

システム開発の工程は以下の記事で詳しくまとめています。

まとめ

システム開発において要件定義は重要な役割を果たし、以降の開発工程にも大きな影響を与えます。本記事では、システム開発における要件定義工程の進め方や注意点などを紹介しました。

システム開発会社の選定でお困りの場合は『比較ビズ』に相談してみてはいかがでしょうか？

『比較ビズ』では、必要事項を入力する2分程度で、システム開発に対応できる業者を探せます。複数の業者に無料で相談できるのも嬉しいポイントのため、ぜひ利用してみてください。

監修者のコメント

株式会社GeNEE

代表取締役 日向野卓也

東京工業大学環境・社会理工学院卒業。慶應義塾大学大学院経営管理研究科修了。MBA（経営学修士）取得。国内最大手SIerの株式会社NTTデータで大手法人領域（大手流通企業、大手小売企業）の事業開発、事業企画等の業務に従事。米国スタンフォード大学への研修留学を経て、システム/モバイルアプリ開発会社の株式会社GeNEEを創業。

詳しく見る

プロジェクトが進行し、後工程に移るにつれて、仕様変更に伴うコスト・リスクは大きくなります。そのため、要件定義を含む上流工程において、受発注者間で仕様を明確化し、合意形成を図ることが肝要です。基幹システムの刷新、複雑な業務フローをシステム化するケースでは、業界または会社固有の業務フローが存在することが多く、受注者側の現状把握や業務理解にも相当の稼働がかかります。

発注者側は「要求定義」の段階から、As-Is（現状）とTo-Be（将来的な理想の姿）を具体的に描写し、改善点が受注者側にも明確に伝わるよう、既存システムの設計書類／業務フロー図等を事前に整理しておくとプロジェクトが円滑に進むはずです。受注者側は発注者側の要望を確認する際に、必ずその背景・理由も確認すると良いでしょう。仕様を決定する際に、何が必要で何が不要か判断する必要があるためです。

また、受注者側は要件定義にて要件を整理する中で、開発スコープとして「実装しないこと」（「要求定義」の内、対処外とする項目）についても明確化し、曖昧さをなくすことも重要なポイントです。受発注者間での認識を可能な限り合わせて、ゴールを共有した上で以降の工程に進めるようにしましょう。

執筆者

比較ビズ編集部では、BtoB向けに様々な業種の発注に役立つ情報を発信。「発注先の選び方を知りたい」「外注する際の費用相場を知りたい」といった疑問を編集部のメンバーが分かりやすく解説しています。