Column

システム開発をするにあたって、初期段階で出てくる「要件定義」という言葉があります。

今回、解説する要件定義は、システム開発などのプロジェクトを始める初期段階で必ず行うべきプロセスになります。

企画の進行とともに要件定義に立ち返ることも多く、目的の脱線を防止する役割もあるので、この記事でしっかりと理解するようにしましょう！

要件定義書とは、SEによって書かれる最終書類になります。

システム開発に関して顧客からの要求を受けた後に、システムを実際に作る前に提出される最終書類のことを指し、「開発されるシステム内容」について書かれています。

専門知識を使いながら開発されるシステムの内容を確認し、そのシステムの持つ機能や性能を定義していき、最終的に定義された機能や性能のこと、またそれらを定義することを「要件定義」と言います。

また、システム開発における基本設計や詳細設計のベースとなり、クライアントの要求に応えるための羅針盤とも言えるためとても重要になってきます。

要件定義書には、機能要件に加え、後に解説します非機能要件としてシステムの性能・信頼性・拡張性・セキュリティなどが記載されています。

「要件定義書の内容」＝「クライアントに確認する成果物」

要件定義書の作成には、開発プロジェクトのリーダーやディレクター、エンジニアなどのプロジェクトを指揮する人が中心となり、開発プロジェクトを進める上で必要な項目を列挙していきます。

それらの内容を要件定義書に落とし込んで、関係者に周知徹底を図ります。

要件定義書を作成することによって、成果物の完成イメージのすれ違いを避ける目的があります。

発注者側と開発・制作側の間で明確な認識合わせを行うことは、とても大切です。

きちんと作成することで、発注者側の要求を関連部署間で共有しやすくなるばかりでなく、開発側でも開発担当間で認識の不一致が生まれにくくなります。

具体的な目的として下記のようなことが挙げられます。

・業務フローの詳細を把握し、実装すべき機能範囲を顧客とすり合わせて合意を得ること。

・最終的なシステムのゴールを明確化させること。

上記のように要件定義の目的があるので要件定義がないと、最初にクライアント側から受けた要望と違う成果物を納品してしまうことがあるのです。

要件定義書がしっかりしていないと、違う成果物を納品させたクライアント側から、クレームとして叱責を受けてしまう事になります。

このようなトラブルを防ぐためにも、顧客と納得いくまで認識のすり合わせを行うことが重要です。

認識が1つでも違っていたら、顧客が本当にしてほしいシステムが作れません。

１つ1つ明確に間違いのないように打合せを行いましょう！

要件定義の工程を上流工程と呼ぶこともあります。

要件定義は、設計、実装工程の前工程として行われます。

ユーザーがそのシステムで何をしたいのか、なぜそのシステムが必要なのか、システムの目的（要求定義）に基づき分析、検討を行い、その実現のために実装しなければならない機能や性能などを明確にしていきます。

この工程では、プログラム開発などは行われず、複数回の打合せによって成果物、要件定義書を作成します。

それぞれの役割としては…

エンドユーザー側は、システムに求める要求をより具体的に示す必要があります。

システム開発サイドは、それを正しく理解して、機能や性能といった技術的な要件にまとめていく必要があります。

SEは、整理した内容を基に業務フローや業務シナリオ、データーモデルなどを作成し、ユーザー部門と認識に食い違いがないかを確認します。

ユーザーがそのシステムに求めるものを明確にすることができ、そのシステムで何がしたいのか、なぜそのシステムが必要なのかなるべく具体的に想像し、定義することができます。

ユーザーサイドと開発サイドの間で十分に話し合い、システムに期待すること、役割、目的の情報を共有化し、しっかりとした認識の統一、相互理解を深めてからシステムの開発に進むことができます。

要件定義ではプロジェクトの目的を明確にし、ユーザー・開発両者の意識を統一することでシステム開発における失敗の原因（「認識の不一致」「目的のブレ」などからおきる仕様変更や追加）を抑制し、プロジェクトを成功へ導くのです。

要件定義書の作成はクライアントにとっても、受注側にとっても大切です。

理由は、要件定義の内容を文書にすることで、本当にプロジェクトの方向性が同じになっているかが確認できるからです。

これにより、両者の認識に相違があった場合でも、要件定義書があれば開発をはじめる前に修正が可能になります。

顧客の完成イメージと本当に必要なシステムに、差があることは珍しくないのです。

クライアントからのニーズを分析や本質を考えることで出来るだけ完成品とクライアントとが求めているプロダクトで差が縮まるため、要件定義書はとても大切になるのです。

自分がクライアントの立場に立ったとき、開発側から提出された「要件定義書」がどのようなものだったらうれしいですか？

単に、要求が書かれているだけでは、メモにすぎません。

しかし要件定義書に、その要求の解決策まで書かれていれば、クライアントの満足度は非常に高くなるでしょう。

この記事では、ポイントとなる業務要件・システム要件・機能要件・非機能要件をそれぞれ徹底解説します！

業務要件は、要件定義の初期に実施する工程です。

システム化する間に現状の業務がどのように流れているかを確認し、問題を抽出した上で、新たに何を実現すべきかを決めていきます。

この段階ではシステム関係は意識せず、あくまで業務そのものに焦点を当てます。

業務要件では業務に詳しい担当者に参加してもらい、密度の高いコミュニケーションを図ることが大切になってきます。

もし、発注者と開発者の目的が噛み合わないまま開発がスタートしてしまうと、大幅な手戻りが発生して時間とコストの浪費につながってしまうのです。

業務要件で現状の業務分析と新たな業務の流れを定義した後は、それをどのようにシステムに落とし込んでいくかを決めます。

ここで決められる、システム開発の方向性をシステム要件と呼びます。

一見、業務要件と大きな違いがないように見えますが、実際には両者ギャップがあることが多いので、注意しましょう。

なぜなら、業務要件で決めた「業務上の要望」と、システム要件で決められる「システム化を通じてできること」は必ずしも同じではないからです。

例えば業務要件が「取引先の地名をすぐ調べられるようにしたい」だとしましょう。

これに対するシステム要件は、「ノートPCからブラウザ経由で検索できること」や「スマホにインストールしたアプリを使う」などの手段になります。

また、業務の要件の中にはシステム化の対象から外れるものもあります。

機能要件は、クライアントからの要求にある背景や目的の確認を行う必要があります。

これらを把握していない場合、実装する機能の要件にズレが生じ、開発側が違う機能を作成する可能性があるためです。

単に必要な機能をヒアリングするだけではなく、背景や目的まで共有しておくことで、開発側が要件を絞り込む際の判断材料にもなります。

流れとして、開発側が発注側から必要な機能をヒアリングで聞き出し、一覧にしてまとめます。

業務改善のシステム開発の場合は、業務フローから確認して必要な機能を洗い出します。

そこから、本格的に機能要件を選定していきます。

すべての機能を実現できない場合は、割り当てられた予算やスケジュールの中で、実現可能な機能要件を発注側と開発側で絞り込みます。

各機能の優先順位を考慮するほか、盛り込めない機能の代替案がある場合は開発側に提示してもらいましょう。

この機能要件の成果物は、下記に記載してある非機能要件と合わせて、後続の基本設計フェーズでの重要なインプットとなるのです。

機能要件がシステム開発において必須の機能なのに対して、非機能要件は”機能以外”でユーザーがシステムに求める要件のことを指します。

非機能要件を実現すればするほど、クライアントの満足度を上げることができます。

開発側が非機能要件を考慮し要件定義書を仮作成するのですが、非機能要件は発注側の直接的な要求では無いため、発注側からの提示が困難になります。

非機能要件は、一般的に独立行政法人情報処理推進機構（IPA)が定める「非機能要求グレード」に沿って作成されます。非機能要求グレードは下記6つのカテゴリーに分けられています。

要件を変更する場合は、理由を必ず説明することが重要です。

変更の背景を教えておくと、開発側が代替案を提示できるようになるからです。

最終的には、開発側とのすり合わせにより機能として実装する非機能要件の選定を行います。

コストを聞き、予算内で優先度の高い機能から選んでいくのが基本です。

システムを使用できる時間帯や安定性などに関する要件が分類されます。

運用スケジュールの策定、バックアップの方法、障害発生時の復旧方法などが代表例です。

システムの性能・拡張に関する要件です。

機能追加が可能かどうか、利用できるクライアント数や許容できるデータ負荷などが定義されます。

運用と保守に関する要件です。

バックアップの形式・頻度・運用時の役割分担やマニュアル作成などがこのカテゴリーに分類されます。

新システムへの移行に関する要件です。

移行によるシステムの停止期間や移行計画、トラブル時の対応について定義します。

システムの安全性確保に関する要件です。

セキュリティリスク分析やアクセス・利用制限、データの秘匿などについて定義します。

システムを設置する環境や環境規格への適合性についての項目です。

運用する上でのシステム成約や前提条件について定義します。