要件定義の進め方やポイントをわかりやすく解説

新たなシステムを開発するときや既存システムを刷新するときに、日本では開発会社（＝ベンダー）にシステム開発を発注することが多いです。

発注者とベンダーの2者で1つのプロジェクトを推進することになるので、システム開発のプロジェクトを成功させるには、「要件定義」が重要になります。

では具体的に要件定義はプロジェクトの中のどこに位置し、また他の工程にどのように影響していくのでしょうか。

本記事では、要件定義の進め方やポイント、他の工程との関係などについて解説していきます。

要件定義とは？

要件定義とは、システム発注者の要望を踏まえて、ベンダー側のでシステム開発の概要、目的、必要な機能、開発技術、必要な予算・人員、スケジュールなどを定義づけることを指します。

要件定義はシステム開発における最上流工程に位置しており、プロジェクトは要件定義で定めた内容を元に進んでいくため、重要な工程と言われています。

要件定義の重要性と注意点

要件定義では、発注者とベンダーで綿密にコミュニケーションを取り、要件定義を固めていく必要があります。

要件定義を曖昧なままにプロジェクトを進めることで、

• 想定していたシステムと全く違うシステムが出来上がる
• システムを利用する人に使われない機能が搭載される
• 開発スケジュールやリリースが大幅に遅延する
• 予算が大幅に超過してしまう

などのリスクが伴います。これらを避けるためにも、特に外部ベンダーを利用し、システム開発を行う場合は、業界への理解があるベンダーを探したり、業界内での暗黙のルールや仕組みなども理解してもらえるよう慎重に要件定義を進めることが大切だと言えます。

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

要件定義と似た言葉に、要求定義があります。要件定義と要求定義は別物です。要件定義はプロジェクト開発における最上流工程とご説明しましたが、要求定義は要件定義よりも前に実施されます。

明確な違いとしては、要求定義を行うのはベンダーではなく、システムを発注する企業で定めます。現場業務を整理した上で、事前に「システムで何を実現したいのか？」を定めます。

システム発注者側で要求定義書を作成し、ベンダーに対して提出する流れになります。要求定義書には、解決してほしい課題、導入の目的、欲しいシステムの機能などが記載されていますが、あくまでも希望であり、要求定義書で記載される機能やシステムが全て実現する訳ではありません。

この要求定義を元に、ベンダーが要件定義で具体的な内容を詰めていきます。

関連記事　要求定義とは？要件定義との違いや重要性、進め方のポイントを解説

要件定義のステップ

要件定義は、プロジェクトの工程としては一工程です。しかし、要件定義の中でも作業は細分化されます。要件定義の進め方には明確なルールがないため、ベンダーやプロジェクトによって異なります。本記事では、要件定義の大枠の流れをご紹介していきます。

1.要求定義の整理
2.課題と目標の明確化
3.システムの全体像の明確化
4.機能要件定義
5.非機能要件定義
6.プロジェクト内容の決定
7.要件定義書作成

それでは、各作業について解説していきます。

1.要求定義の整理

要求定義は、システム発注者側がシステムに関する要求をまとめるものということを先述しました。そして、要件定義は要求定義を元に進めていきます。要件定義は要求定義の内容を満たす必要があるということです。

そのため、要件定義の最初に要求定義の内容を再度整理する必要があります。システム発注者が必ずしもシステムに詳しいとは限らないため、要求定義の内容が実現が難しい場合や、予算やスケジュールを考慮すると機能を取捨選択する必要がある可能性があります。

また要求定義に不慣れな場合、内容がまっていないケースもあるため、発注者側とベンダー側で認識の擦り合わせを行う必要があります。システム発注者の意図を汲み取りながら要件定義に落とし込んでいきます。

2.課題と目標の明確化

要求定義の内容がまとまったら、今回のシステム開発でどのような業務課題を解決し、最終的に何を目標とするのかを明確にします。

課題と目標は要求定義にも含まれていますが、あくまでもシステム発注者側の観点で作られたものです。開発側目線から見ると現実的でなかったり、より効率的な課題解決方法がある場合もあるので、システム発注者に確認を取りつつ再構築していきます。

3.システム全体像の明確化

システムで解決したい課題と目標が決まったら、システム全体の構成や内容を決めていきます。

システム開発と一言に言っても、ユーザーが利用するデバイスの種類や環境によって、その実現方法は様々です。

この時点ではまだ設計やコードの詳しい部分には触れず、システムの全体のロジックを整理していく程度です。具体的には、ビジネスプロセス図や業務フロー図、システム化業務フローなどのフローチャートで図式化していく場合が多いでしょう。

4.機能要件定義

機能要件定義とは、システム発注者から求められているシステム機能を定義することです。機能要件定義で定める内容は、システム導入後の業務効率に直結する部分でもあります。つまり、システムのコア部分の定義とも言えます。

詳細については設計の工程で行いますが、要件定義の時点でざっくりとシステムに搭載すべき機能を整理しておく必要があります。なぜなら、機能要件定義はプロジェクトの予算、メンバー、スケジュール等に大きく影響するからです。また、予算やスケジュールに合わせて、必要な機能に優先順位を付けることも必要です。

だからこそ、要件定義の段階で全体像を正確に見定めるためには、システム設計やプログラミングのスキルも必要になります。

5.非機能要件定義

非機能要件定義とは、機能以外の性能、ユーザビリティ、拡張性、保守・運用、移行性、セキュリティなどを定義することです。

画面のレイアウトやウイルス対策ソフトの決定なども非機能要件定義に含まれます。例えば、検索結果の表示速度や、業務処理速度、システムトラブル時の処理速度などシステムの質に大きく関わる部分であり、実際にシステムを利用するユーザーの満足度にも直結します。そのため、機能要件定義と同等に非機能要件をしっかり定義することも重要です。

またビジネスモデルが変化しやすい時代だからこそビジネスモデルの変化を見据えたシステム拡張性を考慮した設計にしておく必要性も考えられます。

6.プロジェクト内容の決定

プロジェクト内容とは、予算、スケジュール、メンバーなどを指します。この段階で、設計、開発、テストなどでどのくらいの人月が必要か、どのようなスケジュールでプロジェクトが進行するのかなどを把握している必要があります。

要件定義の段階で、実作業の内容も大まかにはイメージできている必要があるということです。イメージが定まっていることで、適切なプロジェクト内容になります。

逆に曖昧なままプロジェクト内容を決めると、リソースが枯渇します。一般的に、IT業界は全体的にリソースが枯渇しているため、余裕をもって多めに人員を割くことは難しいからです。つまり、想定外の作業が増えるとリソースを足らず、スケジュールの遅延や予算超過となってしまうのです。

そうならないためにも、要件定義の担当者はしっかりとプロジェクトをイメージし、根拠を持ってリソースを確保しなければいけません。

7.要件定義書作成

ここまでに決めてきた内容を踏まえ、最終的に要件定義書に落とし込みます。この段階ですでに資料は作成していますが、最終的にプロジェクトメンバーやシステム発注者と認識を合わせるために共有する資料を作成します。

要件定義書に既定のフォーマットはないので、記載内容の縛りはありません。しかし、どのプロジェクトでも概ね以下のような内容を記載します。

【要件定義書の記載項目】
・システム開発の目的
・システムの導入環境
・現状の問題点
・システムの全体像
・システムの機能要件
・システムの非機能要件
・工数
・予算
・スケジュール
・メンバー
・開発者と発注者の今後の連絡方法、頻度
・セキュリティ対策の方法

要件定義に必要な要素

要件定義を行うために必要な要素は複数ありますが、中でも代表的なものを挙げていきます。

豊富なIT知識とスキル

要件定義の担当者には幅広いIT知識とスキルが求められます。ユーザーの要求に対して、システムでどのような設計をし、実現していくのか、可能な限り具体的にイメージできるとより良いです。具体的なイメージがあればトラブルが発生しにくい要件定義ができるでしょう。

要件定義の担当者は直接手を動かして設計やプログラミングをしない場合も多いですが、プログラミングの一定スキルを保有していた方が良いため、担当者の開発実績等も考慮して、ベンダー選定を行うと良いでしょう。

業界・業務への理解

要件定義において実はかなり重要になるのが発注者の業界に対する知識や業務への理解です。

ユーザーが普段何気なく行う業務作業には、業界内の暗黙のルールや業界特有の定義付けなどがされているケースが多いです。システム発注者と密なコミュニケーションを取り、業務を正しく理解することで、ユーザーはどのような業務処理を望んでいるのか、どのような処理ができると利便性が高いのか、といったことがわかります。

システムベンダーへ開発を依頼する際には、業界での実績やノウハウを持っているかも重要なベンダー選定のポイントになるでしょう。

要件定義以降の開発の流れ

要件定義については以上の通りですが、要件定義以降の開発の流れについてもご紹介しておきます。まず開発全体の流れとしては、以下の図のようになっています。

それぞれの工程について、簡単にご紹介しておきます。

設計

要件定義の次にシステムの設計を行います。設計は、基本設計と詳細設計の2つに分けられます。厳密には、プロジェクトによって別の呼び方をする場合もあります。

基本設計

基本設計は要件定義で定めた要求事項をシステム的にどのように実現できるのかを明確にしていく作業です。

具体的には、システム上で利用する機能の一覧、業務フロー、画面レイアウト、スケジュールなどのシステム全体の概要を大まかに考えていく工程です。基本設計は外部設計と呼ばれることもあり、目に見える部分を設計していく作業です。

詳細設計

詳細設計は、基本設計をより細かく詰めたものです。具体的には、データ処理の流れや、プログラムの構造やソースコード、どのようなロジックを使用するのかまで詳細に記載していくことが多いです。

詳細設計は内部設計と呼ばれることもあり、システムの内側の処理などを考える作業です。詳細設計書が作りこまれていると、後のプログラミング工程は詳細設計書に従って作業していくだけなので楽になります。

プログラミング

主に詳細設計書に従ってプログラミングしていきます。詳細設計書が作りこまれているとプログラミングの工程はスムーズに進むことが多いですが、詳細設計書の通りにうまくいかない場合もあります。その場合、プログラミング担当者が試行錯誤することになります。

テスト

プログラミングが終わったらテストの工程ですが、テストは4つに分けられます。

単体テスト

まずは各機能ごとの単体テストを行います。一つ一つの機能に不具合があると結合させたときに不具合が生じるので、まずは単体テストで一つ一つの機能に問題がないかを確認します。

結合テスト

結合テストは、単体テストでテストした機能を結合して行うテストです。機能一つ一つでは問題がなくても、機能を組み合わせると不具合が生じる場合もあります。

総合テスト

結合テストが完了したら、システム全体で総合テストを行います。総合テストの段階では、まだ開発環境の状態で実施します。

受け入れテスト

総合テストが終わったら、本番環境に移行し、受け入れテストを実施します。本番環境とは、システム発注者が実際にシステムを使用する環境のことです。受け入れテストで問題ないことが確認できれば、最終的にシステムをリリースします。

まとめ〜要件定義はプロジェクトの要

要件定義はプロジェクトにおける最上流工程の1つで、システム開発において最重要と言っても過言ではありません。

発注者とベンダーで密なコミュニケーションをとりながら、発注者の要求定義に沿った要件定義を作ることができれば、プロジェクトがうまく進行し、最適なシステムも作り上げることができるでしょう。

要件定義の重要性や進め方を学び、システム開発を成功に導きましょう。