「システム要件定義」の具体的な進め方を理解しておこう

経済産業省が提唱する「2025年の崖」（※1）に関連して古いシステムや複雑なシステムを刷新する必要性も取り沙汰される昨今、ITシステムの開発現場において要件定義の必要性を感じたり、指示されたというご担当者も多くいらっしゃるのではないでしょうか。
本記事では状況に応じた正しい要件定義をおこなうために、要件定義のそもそもの考え方や役割といった基本知識から、実際に進める際のポイントまでを詳しく解説します。

※1 参照：経済産業省 デジタルトランスフォーメーションに向けた研究会「DXレポート ～IT システム『2025 年の崖』の克服とDXの本格的な展開～」

システム要件定義の基本的な考え方

「要件定義」とは、業務上のプロジェクトを開始する前の段階において、そのプロジェクトに必要な機能や要求などをわかりやすく網羅してまとめておく作業のことです。
英語では“Requirements Definition”と表され、システム開発の現場や実際の業務上では省略されて「RD」と呼ばれることもあります。

そのうちの「システム要件定義」では、主に情報システムにおいて必要となるものを「要件」として詳細まで定義していくことになります。

以下に、システム要件定義を理解するにあたって主要となる点をご紹介します。

システム開発を進めていくために必要となる要素を整理してまとめる

システム開発のプロジェクトにおいては、前提としてどのような目的でそのシステムを開発するのか、どのような役割をもった要素で構成されるのか、利用者の環境はどういったケースがあるか、そしてどのような機能・可用性・拡張性をもたせるのかといった、様々な要件が必要となります。

システム要件定義では、これらの細かな要素をすべて前もって定義し、わかりやすくまとめておきます。

システム開発プロジェクトへの参加経験を積んだ人物が担当する

システム要件定義をおこなう担当者には、そもそも開発システムに関する知識やスキルが必要です。またシステム開発にあたってどのような工程が踏まれることになるかといったことや、クライアントの求めるシステム仕様など実際的な判断ができる人物が求められます。

そのため、実際に現場でシステム開発・設計の経験を重ねている人物が適しているでしょう。

定義した内容は要件定義書として正しく落とし込む

システム要件定義で策定した内容は、成果物として「要件定義書」にすべて落とし込みます。
詳しくは後述しますが、要件定義書では「システムの概要」「業務要件」「機能要件」「非機能要件」などのカテゴリごとに、さらに事細かに項目を分けて、どの開発担当者や運用担当者が読んでもわかりやすいように記載しておきます。

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

システム要件定義と混同されがちな言葉に、「ソフトウェア要件定義」というものがあります。ソフトウェア要件定義は、システムの中に組み込まれるソフトウェアごとの、細かな要件（ユーザーインタフェースやデータベースなど）を定義しておくものです。

そもそもITシステムというものが複数のハードウェアとソフトウェアで構成されるものであるため、システム要件定義の中に、個々のソフトウェア要件定義も含んでおくというかたちになります。

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

「要求定義」という言葉は、端的にいうと「利用者（ユーザー）側がシステムに求める仕様を想定し、定義する」ということを指します。
システム開発のプロジェクトにおいて、クライアント側がどのような機能を欲しているかを定義したものが要求定義であり、それに基づいて開発者側が具体的にどのようなシステムを開発するかを細かく定義したものが要件定義、という考え方になります。

▼参考：
予約システム＆予約管理システムのメリット･できること｜ChoiceRESERVE

システム要件定義の必要性

システム開発を行うにあたって、何故すぐに具体的な開発に着手するのではなく、まず要件定義をしておくのかという点を解説します。

計画通りに事業を進めるために不可欠

システム開発に関わる担当者が多い場合でも少数精鋭の場合でも、開発の進行具合や成果状況が当初の想定と異なってしまう、というのはよくあることです。
例えば開発途中で想定外の要素が見つかり追加の企画作業や開発作業をおこなう時間が必要となった、別のスキルを持った人材が急遽必要になったが会社にいない、などという失敗経験を持つ開発現場も多くあるのではないでしょうか。

こういった結果となり納期・予算・品質などの面においてトラブルが発生してしまう事態を防ぐために、あらかじめシステム要件定義にて「開発に必要となるすべての要素」を定義しておきます。

システムベースの業務運用について課題を整理し可視化できる

クライアントから求められるシステムを、実際の運用にかなう実際的なシステムとして開発するためには、そのシステムを業務運用した場合に生じる様々な現場レベルの課題までを事細かに想定しておくことが必要になります。
システム要件定義では、これらの業務運用上の課題をしっかり明確化し、分かりやすくまとめておく意味もあります。

複数の担当者が関係する場合でも一環した定義のもとでシステム構築・運用を進められる

ITシステムの開発現場では、要件定義～開発～テストなどのそれぞれの工程において、複数の担当者が役割ごとにプロジェクトに携わっていくことになります。
例えばプロジェクトの開始段階では要件として統一できていた共有情報も、工程が進み担当者が入れ替わることによって伝言ゲームのように情報劣化が生じ、次第に方針がずれてしまうようなことが起こり得ます。

このような事態を避けるために要件定義においては細かな要件までをしっかり定義しておき、かつ読み手が変わっても誤解を生むことのない、一意に解釈できる要件定義書として落とし込んでおきます。

ITシステム構築を外注する場合の合意形成文書ともなる

この点はITシステムの構築を他社へ発注する際の話ですが、あらかじめ作成したシステム要件定義書は、そのまま合意形成文書という意味合いも持ちます。
外注先にとっても、要件定義書にそったシステムを開発することが請け負った職務となり、契約の枠組み・物差しとなります。

業務の状況に応じた新システム構築や再構築にも柔軟に対応できる

システム開発のプロジェクトでは、現場のニーズに応じた新規システムを構築する場合と、既存システムを再構築する場合があります。
再構築の場合には、当該システムに関連する業務の移行内容、運用の移行などといった移行要件を定義する必要も出てきます。
この際にも、元々のシステムの要件定義が存在すれば、その定義内容をもとに、現行機能を棚卸し→移行が必要な部分をひとつひとつ再定義していく、といった柔軟な対応が可能です。

経済産業省が推進するDXにおいても要件定義は重視されている

“企業がビジネス環境の激しい変化に対応し、データとデジタル技術を活⽤して、顧客や社会のニーズを基に、製品やサービス、ビジネスモデルを変⾰するとともに、業務そのものや、組織、プロセス、企業⽂化・⾵⼟を変⾰し、競争上の優位性を確⽴すること”と経済産業省が定義している「DX（デジタルトランスフォーメーション）」においても、要件定義については重要視されています。

参考：経済産業省「産業界のデジタルトランスフォーメーション（DX）」

システム要件定義に必要となるスキル

システム要件定義をおこなう担当者には、開発プロジェクトへの参加経験を積んだ人物が適しているということをご説明しましたが、さらにどのようなスキルが具体的に必要になるかを見ていきましょう。

コミュニケーション力

システム要件定義の策定工程においては、ユーザー側（クライアント）の要求を実際的なレベルまで細かく引き出し、すべての要素を正しく要件に落とし込む必要があるため、そもそもの適切なヒアリングをおこなうためにコミュニケーションスキルが必要となります。
またシステム開発現場においても、開発工程の実状や開発担当者の状況などを細かく把握したうえで要件定義をおこなうために、現場との細かなすり合わせが発生します。

スケジュール・リスク管理

納期や予算などの面で問題なくプロジェクトを推し進めるために、厳密なスケジュール管理・リスク管理をおこなう必要があります。
要件定義では、プロジェクトを全体的な視点で見据えたうえで進行を考慮しなければならないため、ユーザーの要望、実現できるシステムの内容などを総合的に検討・判断しつつ進行できる能力が求められます。

適切に文書化するスキル

システム要件定義の成果物として要件定義書を作成するにあたって、どの担当者が読んでも分かりやすく、一意に理解できるような適切な文書化が必要となります。
システム開発や業務内容に関連する正しい用語・表現への理解はもとより、伝えるべき情報の整理・伝え方やまとめ方の検討力も必要となるでしょう。

システム要件定義で意識すべき「5W2H」

システム要件定義にあたっては、要件定義の起点をどこに置くのか、プロジェクトの各工程でどこまで進んでいるべきなのか、どこの段階の前に何を実施すべきか、といった様々な要素を整理しながら検討する必要が出てきます。

そのためにも、ITシステム構築における“5W2H”をしっかりと押さえておき、要件定義の段階でこれらも含めて明文化（定義）しておくことが大切です。
要件定義の準備段階では、受注側と発注側、両者のニーズを踏まえながら以下にご紹介する“5W2H”を意識しつつ、綿密な打ち合わせをおこなっておきましょう。

Why

今回、「なぜ」ITによるシステム化を行いたいのかを把握・整理します。

What

ITシステムを使って「何を」実現したいのかを把握・整理します。

Where

求められる業務要件を満たすために、「どの部分」をITでシステム化するのかを把握・整理します。

Who

そのITシステムを利用することになるユーザーや、運用者は「誰になるのか」を把握・整理します。

When

そのITシステムによるサービスを「いつから」運用させるのかを把握・整理します。

How

求められる要件を、ITシステムを使って具体的に「どのように」実現するのかを把握・整理します。

How much

そのITシステムの実現のために、「いくらの」予算を組めるのかを把握・整理します。

ステークホルダー（利害関係者）ごとに重要となる指標

システム要件定義を進めるにあたっては、システム開発プロジェクトにおけるそれぞれの利害関係者（ステークホルダー）にとっての、「そのシステムで必要とするもの」を仔細に検討したうえで項目を決定していく必要があります。

以下で、ステークホルダーごとに重視されやすい項目や指標を解説します。

上記はあくまで一例ですが、こういった項目が重視されやすいということを念頭に置き、各ステークホルダーと協力しあって要件定義をまとめていくとよいでしょう。

システム要件定義書の項目

システム要件定義の成果物としてシステム要件定義書をまとめる際には、既定のフォーマットというものは特にはありません。
要件定義した内容を誤解なく一意で読みとれるようにまとめられれば問題はありませんが、ここでは、一般的な開発プロジェクトにおいて要件定義書に記載されることが多い、主要な項目を抜粋してご紹介します。

システムの概要

そのシステムの目的や、システムが必要となった背景、解決したい課題や具体的な解決策などをまとめます。

業務要件

業務要件とは、つまり業務フローのことです。
今回システム化する業務自体がそもそもどのような業務であるかということを、あくまで業務の観点から説明します。
業務要件を記載する際には、「現状（システム化する前）の業務フロー」「システム導入後の業務フロー」両方を、変化がわかりやすいように記載しておきます。

機能要件

今回のシステムに必要となる機能、要求定義で求められている機能をまとめます。
システム全体で実現する処理や内部でのデータフロー、表示される画面の一覧などを記載します。

非機能要件

システムの可用性や拡張性、ユーザビリティやセキュリティ面を定義します。
前述の機能要件は要求定義に基づいており、言い換えれば「クライアントにとってはあって当たり前の機能」となります。
一方で非機能要件は、システムの品質を向上するための要素であり、高品質な非機能要件を提案し定めることができれば、発注者の満足度アップにもつながりやすいでしょう。

実行計画

開発プロジェクトの実行計画を仔細にまとめます。
スケジュール、工程ごとの必要な予算、人員、必要となる機器や開発実行場所などを網羅して記載します。

システム要件定義の進め方の概要

システム要件定義の詳しいステップは後段でご説明しますが、まずは大まかな全体像を把握しておきましょう。
大筋としては、以下のような流れで要件定義を行っていくこととなります。

1. 業務の現状を分析し、ビジネス要件およびシステム化要件を定義する
2. 予算とスケジュールを検討のうえ、取捨選択しながら要件を絞り込む
3. 決定した予算・スケジュール・要件を合意・承認する

それでは、さらに具体的な部分に焦点をあててシステム要件定義の進め方を見ていきましょう。

システム要件定義の具体的な進め方

システム要件定義の進め方について、7つのステップに分けて解説します。

1.要求される要件を定義する

前述のように、要件定義の前段階として、まずシステム発注者側が「どのようなシステムを構築したいのか、そのシステムで何を実現したいのか」といったことを基に「要求定義」がおこなわれます。
この要求定義についてはあくまでシステムの発注者側が整理しまとめるものとなりますが、例えば要求定義に不慣れなクライアントの場合、内容が不完全な要求定義となってしまう可能性も十分考えられます。また、ITシステムのことには疎いという人が要求定義を行う場合もあるため、ITシステムでは実現しにくい要求であったり、予算やスケジュールを考慮した場合に機能を取捨選択しなければならなかったり、といったことも珍しくはありません。

そのため、要求定義を受け取った段階から発注者側とベンダー側双方での認識の擦り合わせをおこないつつ、発注者側の意図を汲み取りながら、要件定義に漏れなく落とし込んでいく必要があります。

2.課題と目標を明確化する

今回開発するシステムでどのような業務課題を解決するのか、最終的にどのようなことを目標とするのかなどを明確化しておきます。

発注者側の要求定義の段階で課題と目標は含まれていますが、それを基にしつつ「開発側目線で見ると現実的ではないこと」「より効率的な課題解決の手段」などがないかを精査・検討しつつ、発注者側に都度確認をとりながら整理の必要がある部分を再構築していきます。

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

システムの課題と目標が明確に定まったら、いよいよシステム全体の構成や内容を決定していきます。
システムを利用することになるユーザーのデバイスの種類や利用環境を視野に入れつつ、システム全体をまずはロジックレベルで整理します。
整理したロジックは、業務フロー図やシステム化業務フローなどの、フローチャートを用いて図式化しておきます。

4.機能要件を定義する

機能要件定義を進めていきます。
機能要件定義は開発プロジェクトの予算、参加メンバー、全体スケジュールを踏まえ、優先順位をつけながら実現可能な機能を定義していきます。
どのような開発プラットフォーム、プログラミングスキルが必要になるのかも考慮に入れておきましょう。

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

続いて、非機能要件を定義します。
前段の機能要件定義を踏まえたうえで、機能面以外の性能、拡張性やユーザビリティ、セキュリティなどを定義していきます。
なかでも拡張性については、ビジネスモデルの変化のトレンド、今後の見通しなども踏まえた定義をおこなうことが重要です。

画面のレイアウトや操作性などについては、ユーザー満足度に直結する部分でもあり発注者側の率直な希望をあらかじめヒアリングしやすい部分でもあるため、必要に応じてすり合わせをしながら決定していくとよいでしょう。

6.プロジェクト内容を決定する

ここまで定義した内容を踏まえたうえで、プロジェクトの予算、参加メンバー、スケジュールなどの内容を決定します。
プロジェクトの各工程のどの段階でどのくらいの人数が必要か、どのような順序で進行していくのかという細かな面まで検討し、リソースの枯渇が発生しないようしっかりとイメージを持って決定していきます。

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

定義した内容に基づいて、要件定義書を作成します。
前述の「システム要件定義書の項目」で解説した各項目を、明確に文書化していきます。
また、必要に応じて関連資料なども用意し、まとめます。

システム要件定義が終わったら？

開発プロジェクト全体から見て、初期段階に含まれる工程を一般的に上流工程といいます。
上流工程には、本記事で解説している要件定義のほか、計画の立案や構成の管理などが含まれます。

一方の下流工程が、要件定義後に行うべき工程となります。
下流工程では、上流工程で定義された仕様や機能に基づき、実際にプログラミング（コーディング）をおこなってシステムを構築していきます。

プログラミングが終わったら、完成したシステムが想定どおりに動作するか、正しいレスポンスを返すか、といったことを確認するための「テスト」をおこないます。

開発環境側でのテストが完了したら、クライアント側の環境（本番環境）へシステムをリリースし、最終的な動作テストをおこないます。

要件定義の際、予約システムの仕組みが必要になった場合は「ChoiceRESERVE」へご相談ください

様々なニーズ、要件に基づいたシステム開発をおこなう場合に、システム側に「ユーザーからの予約を受け付けする仕組み」が必要となることもあるでしょう。
特定の商品やサービスの利用受付をするようなシステムはもとより、例えばシステム内で担当者のアサインをする業務が生じたり、業務に関連した備品や施設を確保する流れが必要になったりする場合には、予約受付の仕組みを簡単に組み込める、予約管理システムが便利でおすすめです。

予約管理システム「ChoiceRESERVE」では、システム要件定義ご担当者様、開発ご担当者様からの状況に応じたご相談もお待ちしております。ぜひ、お気軽にお声がけください。

システム要件定義スキルはエンジニアとしての成長につながる

システム要件定義を成功させるためには、開発現場の実状を踏まえつつ、発注者のニーズを汲み取って要件定義するための経験則・高いスキルが必要となります。
決して簡単な職務ではありませんが、ITエンジニアの皆様にとっては経験を積める貴重な経験ともなるでしょう。

システム要件定義に際して、もし「予約受付の仕組みを既存のもので簡単に組み込める方法はないかな」という状況があれば、ぜひ「ChoiceRESERVE」の活用をご検討ください。