システム要件定義とは？詳しい進め方や要件定義書のポイントを解説

ITコンサルタントやシステムエンジニアなどの職種は、「システム要件定義」を担うことが多いでしょう。システム要件定義は、新規システムの開発における重要な業務です。この記事では、システム要件定義の進め方やポイント、学習におすすめの本を解説します。

システム要件定義とは

システム要件定義とは、主にITを活用したシステムを開発する際に行う工程です。システムに搭載する機能、必要な性能、運用体制、開発スケジュールなど、システム開発に関する詳細な計画を決定します。したがって、トラブル防止やスムーズな開発を実現するためには、システム要件定義が欠かせません。なお、「要件定義」とだけ言う場合もあります。

上流工程のうち企画プロセスの次に位置する

システム要件定義は、システム開発における「上流工程」に位置します。システム開発の流れは、次の通りです。

1. 企画プロセス（システム企画）
2. 要件定義
3. 基本設計
4. 詳細設計
5. システムの開発・テストなどの「下流工程」へ

企画プロセスとは、開発するシステムの方向性や予算を検討する工程です。IPAが定義した用語であり、上流工程のさらに上層の「超上流工程」とするケースもあります。

システム要件定義書とは

システム要件定義書とは、要件定義にて決定した内容をまとめて記載する書類です。基本的に、システムの開発側が作成します。開発側だけでなく発注側への説明にも使用するため、わかりやすい書き方が求められます。

システム要件定義と似ている用語との違い

IT領域には、システム要件定義と近い「ソフトウェア要件定義」や「業務要件定義」といった用語が多数あります。意味を混同しないよう、システム要件定義と似ている用語との違いを理解しておきましょう。

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

ソフトウェア要件定義とは、名前の通りソフトウェアに関する仕様を決めるプロセスです。対するシステム要件定義は、ソフトウェア要件定義も含む工程となります。そもそもソフトウェアとは、開発するシステム上に存在するプログラムです。ゆえにシステム開発では、必要に応じてソフトウェア、ハードウェア、ネットワーク、運用体制などの定義を行います。

業務要件定義とシステム要件定義の違い

業務要件定義とは、システムのユーザーである発注側が、業務で実現したい目標を決める作業です。また、業務の流れも整理します。一方、システム要件定義とは、業務要件を達成するためのシステムを考案する過程です。双方の総称として、「要件定義」とまとめる場合があります。

システム開発の要“求”定義と要“件”定義の違い

システム開発における要“求”定義とは、発注側がシステムに求める条件を整理する工程です。システムを導入する目的や実装してほしい機能など、一般的に発注側が書面化します。その後、開発者は要求定義を実現するためのシステムを、要”件”定義にて確定させるわけです。ただし、要求定義も含めて要件定義とするケースもあります。

基本設計・システム方式設計とシステム要件定義の違い

基本設計とシステム方式設計は、要件定義の次に行うプロセスです。基本設計とは、要件定義の内容の実現に必要な基礎システムを、さらに細かく決定する作業になります。システム方式設計は、基本設計の中で最初に行う工程です。システム全体の構成や開発言語といった重要な部分を設計します。

システム要件定義を決める際の進め方

システム要件定義は、以下7つの手順で進めていきます。

1. 顧客のヒアリング
2. プロジェクトの課題と目標の決定
3. システム要件の定義
4. 機能要件の確認
5. 非機能要件の6大項目の決定
6. プロジェクト内容や進行のすり合わせ
7. 要件定義書の作成と提案

具体的な流れや内容を解説します。

顧客のヒアリング

はじめに、発注側である顧客の業務要件や要求定義を明確にするために、ヒアリングを複数回行います。発注側の担当者だけでなく、システムを利用する予定のユーザーもヒアリングの対象です。顧客のニーズや業務上の問題点、現状のシステム構成、連携しているクラウドサービスなどの情報を聞き出し、データを集めます。

プロジェクトの課題と目標の決定

収集したデータを分析し、プロジェクトの課題および目標を決めます。分析の注意点として、「この業務のこの問題点をこの機能で解決したい」と自覚しているユーザーは稀です。ユーザーの悩みを的確に分析するためには、幅広いIT知識が不可欠でしょう。

システム要件の定義

発注側の要望および業務要件をシステム要件に落とし込み、予算や技術的に実現できる要望・できない要望を洗い出します。開発するシステムの全体像を決定し、「システムの構成」「システムの概要」「システム導入の目的、解決できる課題」などを定義しましょう。

機能要件の確認

発注側の要望を細かく分け、必要な機能を1つずつ確認します。発注側が要求し、システムに必ず搭載する機能を「機能要件」と呼びます。たとえば、システムで処理できる「データの種類」や「帳票作成の自動化」などの機能です。

非機能要件の6大項目の決定

非機能要件とは、システムのうち機能要件以外の条件です。IPA（情報処理推進機構）は、「非機能要求グレード」として、非機能要件を6つの大項目に分類しています（※1）。なお、「操作性」などの項目は含まれていないため、プロジェクトによっては項目の追加が必要です。

拡張・性能要件

拡張・性能要件では、「システムを拡張できるか」や「処理速度などのシステムの性能」を定義します。将来的なユーザーやトラフィック量の増加など、拡張・性能に関わる部分のヒアリングが不可欠です。

可用性の要件

可用性の要件とは、システムを継続的に稼働させるための条件です。システム障害時の対応と復旧フロー、災害時の対応、冗長化といった要件を定めます。

環境・エコロジー要件

環境・エコロジー要件とは、システムの設置・運用に関係する法令、ハードウェアの設置環境を記す要件です。また、エネルギー消費量など、システム運用による自然環境への影響も算出します。

セキュリティ要件

セキュリティ要件は、情報資産の安全性に関する要件です。具体的なセキュリティ対策や守秘義務などの項目を決定します。

移行性の要件

移行性の要件では、既存システムから新システムへの情報資産の移行について明記します。移行方法や移行スケジュール、サポート体制などの条件をすり合わせます。

保守運用の要件

保守運用の要件では、システムを安定して稼働させるための条件を明確にします。データバックアップの対象および頻度、保守運用の方法といった項目を記載します。

※1参照：IPA「システム構築の上流工程強化（非機能要求グレード）紹介ページ」

プロジェクト内容や進行のすり合わせ

続いて、システム開発プロジェクトの計画を立案します。プロジェクトにかかるコストの見積もり、開発メンバーと具体的なタスク、工数などの内容を決定します。加えて、発注側とのコミュニケーションにおけるツールやコミュニケーションの頻度も決めましょう。

要件定義書の作成と提案

システム要件定義の内容を要件定義書にまとめます。要件定義書には、主に次の項目を記載します。

● 発注側の課題とシステム開発の目的
● システム構成
● 機能要件
● 非機能要件
● スケジュール
● 予算の見積もり
● 開発メンバーと役割
● コミュニケーション手段、進捗報告の頻度

作成した要件定義書は顧客に提案し、承認をもらいます。

システム要件定義書の作成のポイント

システム開発を成功させる上で、システム要件定義書の質は重要です。システム要件定義書を作成する際は、下記5つのポイントが大切になります。

1.成果物サンプルや例を参考にする
2.ミス防止にフレームワークを活用する
3.ユーザーの業務やシステムを理解する
4.わからない箇所をそのままにしない
5.内容が伝わりやすい書き方に統一する

順番に注意点を見ていきましょう。

成果物サンプルや例を参考にする

システム要件定義書は、成果物のサンプルや例を参考にすると作成しやすくなります。社内に過去の成果物がある場合、積極的に活用しましょう。また、インターネット上でも実際の成果物の閲覧が可能です。たとえば経済産業省などの成果物があるので、参考にしてみてください。

■成果物の例
機能要件定義書（案）

ミス防止にフレームワークを活用する

記載内容の抜け漏れなどのミスを防ぐため、以下のようなフレームワークの利用がおすすめです。

● 5W2H：情報を効率的に整理する
● エンタープライズアーキテクチャ（EA）：発注側のニーズを分析する

要件定義の内容に間違いがあると、実際にシステムを開発する下流工程のスケジュールが圧迫されかねません。品質の低下に繋がるため、ミス防止に努めましょう。

ユーザーの業務やシステムを理解する

発注側のユーザーの業務や既存システムの把握は重要です。ユーザーの業務の流れや使用しているシステム、問題点を把握することで、システムに搭載すべき機能を考案しやすくなります。ユーザーのニーズを理解しないままシステム要件定義書を作成しても、何度も修正が必要になるかもしれません。

わからない箇所をそのままにしない

ヒアリングを行う中で、発注側の業界特有の業務フローや課題を目の当たりにする可能性があります。そうした場面では、わからない点を放置したまま要件定義を進めないようにしましょう。開発段階で問題点が発覚すれば、納期遅れに繋がりかねません。わからない点はあいまいにせず、正確に理解できるようヒアリングを重ねましょう。

内容が伝わりやすい書き方に統一する

システム要件定義書へ記載する際は、難しすぎる言葉や専門用語の多用に注意が必要です。わかりづらい内容だと、合意内容の認識に違いが生じる恐れがあります。発注側も閲覧するドキュメントなので、IT業界以外の人にも伝わるように書きましょう。

システム要件定義の業務に役立つスキルや資格

システム要件定義を担当する場合、次の3つのスキルや資格があると役立ちます。

1. システム開発やIT関連の知識・経験
2. コミュニケーション力・マネジメント力
3. 「ITパスポート」「基本情報技術者試験」などのIPA系資格

それぞれの必要性を説明します。

システム開発やIT関連の知識・経験

システム要件定義を進める上で、システム開発やIT関連の知識は必須のスキルと言えます。「発注側のどの要望を実現できるか」「このシステムに必要な非機能要件はどれか」といった判断をするためには、エンジニアとしての高度な知識が必要です。また、プログラミングや保守運用などの実務経験があれば、さらに業務を進めやすいでしょう。

関連記事：フリーランスのコンサルタントは資格が必要？独立時に有利になる4つの資格を解説

関連記事：フリーランスの職務経歴書の書き方は？履歴書とはどう違うの？

コミュニケーション力・マネジメント力

発注側の潜在的なニーズを引き出すためには、論理的かつ柔軟なコミュニケーション能力が求められます。難解なIT用語をわかりやすく伝える際にも役立つでしょう。さらに、開発メンバーのタスクや技術の把握、トラブル時の対応、進捗管理といった場面では、プロジェクトに対するマネジメント力が重要になります。

関連記事：フリーランスのコンサルタントにとって名刺は必要？どのような項目を入れるべき？作成方法は？

「ITパスポート」「基本情報技術者試験」などのIPA系資格

「ITパスポート」「基本情報技術者試験」などのIPA系資格は、勉強する過程で知識を身につけられます。たとえば、ITパスポートの過去の試験では「システム要件定義で明確にするもののうち性能に関する要件はどれか」と出題されました。ITの基礎知識から身につけたい場合、資格勉強を活用して効率的に学習できるでしょう。

関連記事：フリーランスコンサルタントの独立準備は何が必要？貯金は？年収は？

システム要件定義の勉強におすすめの本

システム要件定義についてこれから学びたい人に向けて、おすすめの良書を3つ紹介します。

1. はじめよう! 要件定義 ~ビギナーからベテランまで
2. 図解即戦力 要件定義のセオリーと実践方法がこれ1冊でしっかりわかる教科書
3. 演習で身につく要件定義の実践テクニック

それぞれの内容を簡潔に解説します。

はじめよう! 要件定義 ~ビギナーからベテランまで

「はじめよう! 要件定義」は、初心者向けの指南書です。要件定義の最初から最後までの過程を噛み砕いて解説しています。要件定義における重要なポイントがまとまっているので、まずは全体像を理解したい人に適しています。

図解即戦力 要件定義のセオリーと実践方法がこれ1冊でしっかりわかる教科書

「図解即戦力 要件定義のセオリーと実践方法がこれ1冊でしっかりわかる教科書」は、図による見やすい解説が特徴的です。「はじめよう! 要件定義」と同じく、要件定義について一から学びたい人におすすめできます。

演習で身につく要件定義の実践テクニック

「演習で身につく要件定義の実践テクニック」は、システム開発の演習問題を通し、要件定義を体系的に理解を深められます。中・上級者向けの書籍であり、実務にも応用できる内容が多いと高く評価されています。

システム要件定義に関するよくある質問

最後に、システム要件定義のよくある疑問点をまとめます。

1. システム要件定義書は誰が作る？
2. 機能要件と非機能要件の違いをわかりやすく教えて
3. システム要件定義書のフォーマットはExcelでも良い？
4. システム要件定義書と仕様書は同じ？
5. システム要件定義書を英語で作るケースはある？

1つずつ説明します。

システム要件定義書は誰が作る？

一般的に、システム要件定義書は開発側のシステムエンジニアが作成します。発注側が作るケースは少なく、開発側がヒアリングの内容をもとに定義をすり合わせていきます。

機能要件と非機能要件の違いをわかりやすく教えて

機能要件とは、発注側が要望し、実装する機能です。例として「ドキュメントの検索機能」「ユーザー単位のアクセス制御」などの機能が挙げられます。対する非機能要件は、発注側が望む機能以外の項目です。拡張性やセキュリティといったシステムに欠かせない要素を決定します。

システム要件定義書のフォーマットはExcelでも良い？

社内で許可されていれば、システム要件定義書のフォーマットはExcelでも良いです。PowerPointも可能です。閲覧や共有がしやすいフォーマットであれば問題ありません。

システム要件定義書と仕様書は同じ？

システム要件定義書と仕様書は異なる文書です。システム要件定義書はシステムの条件を記しており、開発が始まる前に作成します。仕様書はシステムの開発段階に作り、エンジニアのためにシステムについてさらに詳しく記載します。

システム要件定義書を英語で作るケースはある？

在籍する企業によりますが、クライアントが海外企業であれば英語でシステム要件定義書を作成する可能性があります。国内向けの企業の場合、英語を用いる可能性は極めて低いです。

システム要件定義とは？まとめ

システム要件定義は、ITシステム開発の成功に不可欠な上流工程であり、機能要件や非機能要件の明確化を通じてプロジェクトの成功を導きます。この過程では、顧客ヒアリングから要件定義書の作成まで、多角的なアプローチが求められます。また、システム要件定義書は、開発と発注双方にとって重要なドキュメントであるため、明瞭で理解しやすい内容が必須です。IT関連の知識やコミュニケーション、マネジメントスキルが要件定義業務を支え、これらのスキルは関連資格や書籍を通じて身に付けることができます。この記事では、システム要件定義の基礎から応用までを包括的に解説し、関連するスキルや知識の向上に役立つ情報を提供しました。

関連記事：フリーランスのコンサルタント向けマッチングエージェントはどのようなサービス？

フリーランスのコンサルタントはTHE CONSULへの登録がお勧め

フリーコンサルタントの登録や案件紹介を行うTHE CONSULは、フリーランスのコンサルタント経験者同士が、利用者目線で徹底的に「こんなサービスがあったらいいな」を考え抜いた、フリーランスのコンサルタント向けマッチングプラットフォームです。

現役コンサルタントがサービス提供しているため、案件の解像度を高めることができ、案件参画後のギャップを最小限に抑えることを実現しています。

また、エンドクライアント様/元請様からの案件に限定した、商流の浅さに拘り、更には他社に出回らない独占案件も豊富に取り扱いしており、登録者の報酬を最大化する仕組みが整っています。

今後フリーランスのコンサルタントとして活動してみたいという方向けに、経験者によるご相談もご用意しております。まずはお気軽にご登録ください。