システムの要件定義とは　進め方や必要な準備をわかりやすく解説

システム要件定義とは

　システムの要件定義とは、システム開発を行う上で実施すべき業務内容をあらかじめ想定し、わかりやすく文書化するプロセスです。

　実際にシステム開発プロジェクトを進めていく上で、目的や内容はもちろん、スケジュールや開発予算、開発に関わるメンバーなど、想定しておくべきことはたくさんあります。

　こうした各要素をあらかじめ具体的に想定し、文書化しておけば、プロジェクトを計画通りに進められる可能性が高まります。計画通りにプロジェクトが推進できれば、事業を成功に導くことができます。

　つまり、要件定義の成否によって、プロジェクトを計画通りに進めることができるかどうか、事業を成功させることができるかどうかが決まるということです。

　要件定義の担当者は、システム開発プロジェクトの経験を十分に積んでいる方になるのが一般的です。

　開発内容のイメージを掴めていない方が要件定義を行うと、想定外の作業などが多発し、計画通りにプロジェクトが進まずシステム開発が失敗する恐れがあります。

要件定義と要求定義の違いとその関係

　要件定義とよく似た言葉に、要求定義があります。

　要求定義とは、ユーザーが出したシステム化の要望（要求）を整理することです。要求を整理してから、システム化の要件定義をはじめることによって、ユーザーが求めるシステムや事業結果との乖離を少なくすることができます。

　つまり、要求定義は、システム要件定義のはじめのステップと位置付けることができます。

システム要件定義とソフトウェア要件定義の違いとその関係

　また、システムの要件定義とソフトウェアの要件定義は何が違うのか、という疑問も多くあります。

　ソフトウェア要件定義とは、開発するシステムの内、ソフトウェアに関する要件を定義する部分を指します。

　近年開発されている情報システムのうち、特に詳細な要件を詰める必要がある部分がソフトウェアです。ソフトウェアには、ユーザーが操作を行うために利用するユーザーインタフェースや情報を蓄積するためのデータべースなど、様々な構成要素があります。

　つまり、システム要件定義の中で、もっとも重要な工程がソフトウェア要件定義と言えるでしょう。

• 要件定義実践編：ホームページのリニューアルのコツ

要件定義書を作成するまでの基本的な進め方

　システム要件定義の基本的な進め方は、システム開発プロジェクトを推進する上で必要なことを丁寧に押さえながら、文書として書き出していくだけです。

　具体的には、次のようなステップで行います。

1. 解決したい課題と目標を明確にする
2. システムの全体的な構成を明確にする
3. 機能要件を定義する
4. 非機能要件を定義する
5. 予算とスケジュール、プロジェクトメンバーとコミュニケーション方法を定義する
6. 要件定義書を作成する

　本セクションでは、各ステップにおいて、どのような項目を検討しておく必要があるかについて説明します。

手順①解決したい課題と目標を明確にする

　システム開発プロジェクトの発生に当たり、通常は解決したい業務課題があるはずです。

　そのシステムが何のために作られようとしているのか、どのような課題を解決するために開発されるのかを明確にしておくことで、システム開発プロジェクトを進めるに当たって、目的から大きく乖離することを防げます。

　また目標が共有されていると、開発途中で開発内容を調整・変更していく場合にも、その意思決定をする際の合意形成の役に立ちます。

手順②システムの全体的な構成を明確にする

　次に、システムの全体的な構成を明確にしましょう。

　「システム」という言葉には、様々な意味が同居しています。ウェブサーバー上で動作するウェブシステムもあれば、パソコンの上で動作するクライアントシステムもありますし、特定のデバイス上で動作する組み込みシステムもあります。

　システム全体の構成として、どのような役割の構成要素（ユーザーが利用するパソコン、アプリケーションを動作させるウェブサーバーなど）が登場するか、要件定義の段階で詰めておく必要があります。

　この工程で漏れたシステム構成要素があった場合には、要件外の見積として計上されます。

　ハードウェアの調達を含む要件漏れの場合には、大きな出費になることが想定されるため、全体の構成についての検討を十分に行い、要件定義漏れを未然に防ぐ必要があります。

手順③機能要件を定義する

　システム全体の構成が明確になったら、詳細な部分を詰めていきましょう。

　システムの要件定義は「機能要件」と「非機能要件」の2種類に大別され、それぞれに分けて定義するのが一般的です。

• 機能要件：システムの機能に関する要件
• 非機能要件：可用性、性能、拡張性、運用・保守性、セキュリティなど機能以外の要件

　まずは機能要件の定義からご説明します。

機能要件の定義1　現行の業務フローを明確にし、あるべき業務フローを作成する

　機能要件は、業務効率に直結するもののため、業務を具体的にどのように改善するかという内容が含まれます。

　そのため、最初に現行の業務フローを明確にしつつ、システム開発により変更された後のあるべき姿を描いた新しい業務モデルを作成します。

　なお、現行の業務モデルのことを、AsIsモデル（アズイズモデル）、システム開発による変更後の業務モデルのことをToBeモデル（トゥービーモデル）と呼ぶことがあります。

　この2つの業務モデルを考えることによって、システム開発の効果を想定することが容易になります。

　業務の流れを想定する上で、要件定義の後工程として行われる設計行程では、現行の業務モデルをフロー図に書き出すことをよく行います。

　業務フロー図を作成することで、どこに問題があるかを考える際に役に立つためです。

　要件定義段階では、上記で挙げた業務フローの詳細まで詰め切れる状態が理想ですが、最低限、要所を押さえたラフとして文書・図表を組み合わせて想定しておくと良いでしょう。

機能要件の定義2　扱う概念や情報（データ）の構成や流れの整理を行う

　業務フローが明確になったら、今度は業務フローの中に存在する「概念」について整理を行います。

　「概念」とは、扱う情報（データ）を抽象化したもので、主にデータベースの構造（スキーマ）を定義するために利用されます。

　こちらも設計の行程で実施する内容ではありますが、概念を整理するために利用される図表としては、ER図（ERD、Entity Relationship Diagram）があります。

　ER図を作成するためのツールも多くありますので、実装に利用する言語やフレームワーク、データべースの種類によって使い分けることが一般的です。

　また、概念の構成が明確になったら、業務の流れとは別にデータの流れを定義することもあります。

　「どのような画面で操作をした時に、どのようなデータが、どのような流れで処理されて、保存されるか」のようにデータの流れを描いた図のことをデータフロー図（DFD、Data Flow Diagram）と呼びます。

　設計の段階では、上記の図表を詳細まで詰め切って、実際に実装に利用できるレベルまで煮詰めていきますが、要件定義段階では要所を押さえて、どのようなシステムを開発すればプロジェクトが成功できるのかが理解できるものになっていれば良いと思います。

機能要件の定義3　ユーザーとシステムとの関わり方を定義する

　ユーザーとシステムとの接点のことをユーザーインタフェース（UI）と呼びます。

　例えば、情報システムにおけるUIとは、主にシステムの画面やデバイスのことです。

　設計行程では、これらの画面内にどのような要素が存在するか、どのようなレイアウトをしているか、どのようなカタチのデバイスにするかなどを定義する画面設計やデバイスの設計を行います。

　私たちが普段行っているウェブシステム開発における画面設計を行うためのツールとしては、ヌーラボ社のCacooや、Adobe社のXdなどのツールを利用することが一般的ですが、昔ながらの方法としてMicrosoft社のExcel（エクセル）を利用する方法もあります。

　要件定義の段階では、どのような画面が存在するかを想定した上で、画面の一覧を作成し、各画面を開発するために必要な工数を見積もります。

　また、各画面やデバイスがどういうシチュエーションで利用されるか（ユースケース）を定義することも大切です。ユースケースの定義には、UMLを構成する図表のひとつ「ユースケース図」などが利用されます。

　設計段階ではユースケース図などを描くことを通して、ユーザーがシステムとどのように関わるかの詳細を詰めていきますが、要件定義では、その前段階として、大枠の使われ方が想定できる状態になっていれば大丈夫です。

　また、ユーザーが直接利用することが前提になっていない「UIが存在しないシステム」もあるため、ユーザーだけではなく、システムと関係するあらゆる要素とどのような関わり合いがあるかを煮詰めていくことが必要になります。

手順④非機能要件を定義する

　前項まで詰めてきた内容は一般的には「機能要件」と呼ばれ、業務を具体的にどのように改善するかという内容が含まれています。

　しかし、システム要件は機能要件だけではなく、「非機能要件」と呼ばれている要件が存在します。

　可用性、性能、拡張性、運用・保守性、セキュリティなど、確かに存在はするけれども機能ではない数々の要件が非機能要件に当たります。

　こうした非機能要件も、事前に詰めておかなければならない大切な要素です。

　例えば、非機能要件のひとつである「性能」要件が漏れた結果、処理量が多くなりすぎて、永遠にタスクが溜まり続け、最後にはマシンがクラッシュした…といったケースがあります。

　「可用性」要件が漏れたことで、マシン性能が低すぎて高負荷に耐えられずサーバーがクラッシュしてしまった…ケースもないわけではありません。

　最近では通信回線の安定やマシンの高性能化により、問題にはなりにくくはなりましたが、過去にはこのような問題が多く散見されるような状況があったようです。

　機能要件だけではなく、非機能要件にも着目して、想像力を働かせて、システム開発上の問題発見に努めましょう。

　非機能要件を定義するために、具体的にどこに着目すればいいかは、RASIS（Reliability・Availability・Serviceability・Integrity・Security）というフレームワークを用いると比較的見つかりやすくなります。

　下記に具体的な着目ポイントの例をあげているので、よければ活用してみてください。

手順⑤予算・スケジュール・プロジェクトメンバーとコミュニケーション方法を定義する

　最後に、システム開発プロジェクト全体における予算とスケジュール、メンバー構成やコミュニケーションの取り方などを定義します。

　予算は、ここまでで詰めてきたシステム要件を基に、その要件を実現するシステムを開発するために必要なハードウェアの調達金額や作業工数を算出し、その作業工数に対して、技術的難易度や対応する人材の単価を考慮した金額を設定します。

　予算を算出するためには、プロジェクトメンバーとして何名アサインするか、誰をアサインするかなども要件定義段階で決めていかなければいけません。

　その際、誰が窓口になるかなど、プロジェクト推進上必要な事項についても、極力盛り込んでおくとプロジェクトの推進がスムーズになります。

　人ベースで要件を詰めておくと、「この人がプロジェクトメンバーとして参加していないから、今回のシステム開発は難しい」といったケースを事前に回避することが可能です。

　また、工数を算出したら、それを基に日程計画に落とせば、スケジュールを作成できます。

　要件定義段階でのスケジュールは、大枠だけを定義した「ラフスケジュール」にとどめ、要件定義が完全に完了した段階で詳細見積と合わせて詳細スケジュールを作成することが一般的です。

手順⑥要件定義書を作成する

　①～⑤の内容を順番に並べて要件定義書を作成します。

　要件定義書には、システムの内容からシステム開発プロジェクトの推進に必要な情報、予算まで様々な情報を盛り込まれる想定です。

　要件定義書を読むことで、どのようなシステム開発プロジェクトになるのかの概要が一望できる状態になっていれば理想的ですが、要件定義書作成のスケジュール感によっては、内容が粗いものになる場合もあります。

　冒頭にも述べた通り、要件定義書の品質がシステム開発プロジェクト全体の成否にかかわるため、できる限り正確な内容の要件定義書の作成を心がけましょう。

　ここではウェブシステムを開発する場合を例にとって、要件定義書の目次のサンプルを以下に示します。

　このような目次を設定したあと、各項目について深堀りし、一つの冊子としてまとめれば完成です。

システムの要件定義をスムーズに進めるための事前準備

　システムの要件定義で、目を光らせなければならない要素は多岐にわたります。

　進め方をおさえていても、いざ始めるとスムーズに話が進まなかったり、漏れに気づかずに進めてしまったりするケースはあります。

　そうしたリスクの可能性を低くするために大切になるのが、事前の準備です。どんなことが必要なのか、ここで詳しく説明します。

担当者にITスキルを身につけてもらう

　まずは、システム要件定義を実際に行う担当者に、一定レベルのITスキルを身に着けてもらうことが重要です。

　システムがどのような動きをするのか、どのようなことができるのかなど、開発予定のシステムがどのようにして顧客の業務課題を解決するかを理解できている必要があります。

　システム開発の経験を十分に積み、システムを設計できるくらいのスキルは必要でしょう。

　もし、担当させたい人のITスキル不足が感じられる場合、可能であれば、実際の開発現場を一度体験させるのがベターです。

　一度システム開発プロジェクトを経験してしまえば、どのような開発プロセスを経て開発が進んでいくかや、どのような成果物が作られるかを知ることができます。

　または、システム開発を行っている会社に、どのようにしてシステム開発を進めていくかを聞いてみるのも良いでしょう。

顧客の業務を深く理解する

　システムの要件定義を行うときは、顧客との会話を通して、業務課題解決のための具体的な内容を議論することになります。

　ですので、担当者はもちろん、開発の決定権を持つ責任者も、事前に顧客の業務を深く理解しておかなければいけません。

　顧客の業種が製造業なら、工場内に設置された設備のことや、加工技術のことなど、様々な業務知識が必要になりますし、行程管理や資材管理など、生産管理に関する知識も必要になるでしょう。

　顧客の業種が流通卸売小売業なら、店舗やECサイトでの販売手法を理解する必要がありますし、受発注業務や電子商取引など、販売管理に関する業務知識が必要になるかもしれません。

　ITスキルと合わせて、顧客の業務知識を深めることが、システムの要件定義を進めていく上では必要不可欠です。

　業務知識を深めるためには、国家資格の中小企業診断士の資格の学習が入り口としては効果的です。テキストも本屋で安価に手に入ります。

　または、顧客企業と仲良くなり、業務のことを教えてもらえる状況を作るのも有効です。活きた現場の声が聴けるため、もっとも効率的な学びにつながります。

　顧客とのコミュニケーションを営業に任せきりにせず、開発現場のエンジニア自身が率先して親交を深めていくことが大切です。

要件定義漏れを防ぐためのフレームワークを把握する

　要件定義に必要なITスキルと業務知識を身に着ければ、トラブルが発生しないかと言えばそうでもありません。

　要件定義漏れが発生することによって、開発途中での追加要件による追加予算が発生し、当初予算を大幅に超過してしまうことに加えて、大幅なスケジュール遅延が発生する状況などがこれまでもよく起こっていました。

　これら要件定義漏れを防ぐためには、「そのシステムがどのようなケースに至ると問題が発生するか」を先回りして考え、未然に問題発生を防ぐ必要があります。

　そこでおすすめなのが、非機能要件のRASISのような、要件漏れ防止に役立つフレームワークの種類を把握しておくことです。

　現場で役に立つフレームワークをいくつかご紹介します。

システム要件定義を終えたあとは

　要件定義を終えてからがシステム開発プロジェクトの本番です。設計、実装、テスト、リリースと、より具体的なシステム開発実務が控えています。

　要件定義により定義された開発要件も、実際には設計の行程が進むにつれて、想定外の事象が発覚するたびに、練り直されて、スケジュールと予算の再検討につながることもよく発生します。

　一方、設計が進むにつれて、より良い方策が見つかることもよくあります。

　その場合は、素直に修正を受け入れたほうが良いことが多いため、開発プロジェクト全体を長期化させすぎないように心がけながら、ある程度は柔軟な姿勢で要件変更を受け入れられる状況を作りつつ、システム開発プロジェクトを進めていけると良いでしょう。

十分なコミュニケーションがベース　要所を押さえた要件定義を

　ITベンダーと顧客の間でコミュニケーションを絶やさずに、その時その時で最適な方策を相互共有しながら、開発プロジェクトを進めることができれば、必ず最適なシステム開発プロジェクトの結果を得られるはずです。

　十分なコミュニケーションをベースに、構え過ぎず、要所を押さえた要件定義を行い、有意義なシステム開発へとつなげていただければ幸いです。

• 【実践編】ホームページのリニューアルのポイント　進め方と注意点を紹介