前回の記事で、ご紹介したようにシステムエンジニアの仕事内容は、「クライアント（顧客）から要望を聞き出しシステムの基本設計を行うこと」です。
システムの基本設計を行こなっていく中で、クライアントの要求事項を分析した「要求仕様書」と、要求事項をシステムの要件にまとめる「要件定義書」を作成します。
これらはの仕様書は、システム設計のベースとなる重要なものであるためシステムエンジニアとして一番最初に理解しておくべき内容です。また、クライアントと開発エンジニアとのコミュニケーションツールでもあるためシステムに必要な項目を漏れなく正しく記載できる知識が必要となります
今回は、システムエンジニアに重要な「要求仕様書」と「要件定義書」について詳しく解説していきます。
要求定義書と要求仕様書の違い
まず初めに、要求仕様書と要件定義書の違いについてご説明します。とても似ている言葉ですが、求められる内容は大きく異なるため、正しく区別して理解できるようにしましょう。
要求仕様書
要求仕様書とは、クライアントがシステムに求める要求内容をまとめたもので、システムエンジニアはこの要求仕様書を元にシステムの基本設計を行なっていきます。
この要求仕様書の作成は、クライアントが作成する場合とヒアリングしながらシステムエンジニアがまとめる場合の2通りあります。
要件定義書
一方で、要件定義書とは先ほど作成した「要求仕様書」からシステムに必要な機能や実装方法などを記述したものです。
これは、システムエンジニアが作成し、主に開発エンジニアと開発内容を整合するのに使用されます。そのため、プログラム機能や使用するデータベース・通信に至るまでシステムを実現するための設計図のようなものです。
両者の違いは？
「要求仕様書」…クライアント⇄システムエンジニア
「要件定義書」…システムエンジニア⇄開発エンジニア
両者のドキュメントは、対象としている相手が違います。
クライアントの要望をうまくシステムに反映できるよう、両者の間をうまく取り持つために役割が異なります。
まずは、この2つのドキュメントの違いを理解しましょう。
要求仕様/要件定義書の作成流れ
次に、要求仕様/要件定義書の作成方法についてご説明していきます。
以下の３ステップになります。
- Step1：顧客の要求事項をヒアリングする
- Step2：要求項目を細分化し、「要求仕様書」を作成する
- Step3：「要件定義書」を作成する
Step1：顧客の要求事項をヒアリング
クライアントの要求事項は、あらかじめクライアント側で用意された「要求仕様書」を元に話を進められることが多く、ここでは、提示された仕様書に対して不足事項や確認などを行なっていきます。
例えば、
クライアントが欲しいシステムが「手作業だった業務を自動化できるシステム」である場合は、既存で導入しているシステムや、入力される情報、出力して欲しい情報などを正確に把握する必要があります。また、ネットワーク環境や、社内体制など業務に関わる人の業務状況を的確にイメージしクライアントの欲しいシステムの全体像を把握します。
Step2：要求項目を細分化し、要求仕様書を作成する
上記の項目で、システムの全体像が把握できたら、次工程の要件定義が行いやすいよう開発エンジニアに合わせた要求項目を細分化し「要求仕様書」を作成します。
要求仕様書を作成する工程で重要となるのは、クライアントとの打ち合わせになります。そこでどれだけ必要とするシステムの全体像をイメージし、仕様書という形で具現化できるかが大切です。具現化に漏れなどがあった場合、プロジェクトの失敗を招く原因となってしまうので、細かいところまですり合わせが必要です。
Step3：要件定義書の作成
要求仕様書を元に、開発するシステムに必要な機能を明確化していきます。これは”機能展開”とも呼ばれ、顧客の要求する機能をシステムにどのように実装されるのか？を定義していきます。
機能展開によって開発する範囲が明確することで、システム開発の途中でのバグ（トラブル）など適切に対処することができます。また、クライアントの要求事項を全て実装できるとは限らないため、要件定義の段階で明確化しておく必要もあります。
以降では、要件定義を行う上での基本的用語を解説します。
エンジニアでの共通認識となるので、意味を理解した上で要件定義を行う必要があります。
①業務要件
②システム要件
③機能要件
④非機能要件
①業務要件
業務要件とは、
クライアントの業務状況や、これから開発するシステムの使われ方に関する要件になります。サーバー環境、使用するPC、オペレータの有無により実装される機能が異なってきます。この要件では、システム構成は意識せず「クライアントがどのように使うのか？」を意識して検討します。
例えば、”誰でも使用できるスマホApp”を作成するという要望であった場合、高性能な処理能力が必要な機能などは実装してはいけない、GUIなどはシンプルで直観的に操作できるもの、言語には英語版も搭載するなどシステムに実装する機能をよりクライアントに合わせることが可能になります。
②システム要件
システムの振る舞いや、それに伴う必要なMicro性能・必要メモリ数などをシステムの方向性を定義していきます。言わば、システム全体のワイヤーフレーム構造を作成するイメージです。
例えば、業務要件が「誰でも使用できるスマホApp」だとしまししょう。これに対するシステム要件は、「スマホにインストールできるサイズのApp」「通信負荷を軽減する」「処理能力はバックグラウンドでも作業可能の余地を残す」など定義が必要になります。
一見、業務要件と同じように見えますが、両者には対象が異なり、「業務要件⇔エンドユーザー」、「システム要件⇔開発エンジニア」になります。システムを通じて実現すべきことと、エンドユーザーの操作で実現するべきことに違いがあります。
③機能要件
システム要件で、システム化の方向性が決まると、システムに必要な機能について検討します。
機能とは、システムにおける最低条件であれば必ず必要なものになります。ここで定義した”機能”が無いとシステムが動かなくなったり、動作しないなどのトラブルに繋がるものを定義します。
また、機能要件はシステムが完成した際に行う”システム検証(テスト)”での確認項目でもあるため、抜け漏れ無くしっかりと定義を行う必要があります。
④非機能要件
一方で、非機能要件とは、「機能要件以外の部分」を示します。
例えば、過去調整やUI/UXのデザインなどです。基本的に、機能要件を満足していればクライアントの要望を満足することができますが、利便性や操作性などを良くするには、非機能要件もバランスよく取り入れていく必要があります。
この辺りの要件は、前述で説明した「業務要件」などクライアントとの会話の中から推定し定義していく必要もあるため、予算や納期なども意識しながら調整していくことが必要です。
代表的なシステムの各開発プロセス
ここまで、「要求仕様書」「要件定義書」に関して詳しくご説明してきましたが、どういった開発プロセスでシステムを構築されるのか簡単に説明していきます。
特に、システムエンジニアという職業は”クライアント”と”開発エンジニア”をつなぐ役割であるため情報伝達がスムーズに進むように開発プロセスを意識した、業務を求められます。
以下で、代表的な開発プロセスである「ウォーターフォールモデル」「アジャイルモデル」をご紹介します。
ウォーターフォールモデル
「ウォーターフォール:Water fall」は字のごとく「滝」です。滝のように上から下に向かって開発工程が流れていきます。その途中途中で、マイルストーンを設けて開発の進捗を確認しながら進めていく手法になります。
ウォーターフォールモデルの一番のメリットは、1つの工程が完了した後に次の工程に進むため、進捗管理やトラブルが起こりにくいという特徴があります。そのため、高品質を求める製品や開発人員の制約があるなかでも安定した開発を行えます。
しかし、次工程に進むには前工程を全て完了させる必要があるため、先行して開発を進めることは難しくなります。また、トラブルが起こりにくい＝一度システムに不具合が発生すると、上流工程まで遡り原因究明を行う必要があるため、修正に時間がかかってしまいます。そのため、ウォーターフォールモデルは、納期的に厳しいやスピードが求められるシステム開発には不向きになります。
アジャイルモデル
「アジャイル:Agile」は「素早い」という意味で、ウォーターフォールモデルとは対照的でスピードを優先するプロジェクトに適した開発プロセスになります。
基本的に、開発するシステム構成が明確になった時点ですぐに詳細設計工程へと移行します。仮にシステムに基本設計が未完了であった場合でも、途中段階の状態で進め仕様が変われば随時修正箇所を反映させます。そのため、機能ごとに「仕様定義→要件定義→設計→実装」のサイクルを何度も繰り返しクライアントの要望に近づけていきます。
ウォーターフォールモデルでは、完了してから次工程へ移行していましたが、アジャイルモデルでは修正を前提に開発が進められるため前工程の完了を待つ必要がなくスピードに開発を行うことができます。しかし、各工程の進捗やトラブル対応などを管理するのが難しく、プロジェクトマネジメント力が必要とされます。
まとめ
いかがでしたでしょうか？
今回、「SEのメイン業務である要求分析/要件定義」に関してご説明してきました。
システムの開発における要求分析/要件定義とはクライアントがシステム（エンジニア）に対して求める仕様を明確に定義することで、これらはシステムの基本設計者や詳細設計書の元となる非常に重要なドキュメントになります。
どちらも似ている言葉で混同しやすい用語ですが、中身の違いを正しく理解し、クライアント、開発エンジニアのどちらに対してもわかりやすいような仕様書を提示できるように心がけてください。
ここで、紹介したものはあくまでも一例であり、システムエンジニアの業務領域は、働く企業ごとで様々です。特に、システムエンジニアは業務の区分が難しい業務内容です。しかし、実現したい最終ビジョンはシステムエンジニアもその他プログラマー、クライアントも同じであるため、システムエンジニアとしての基本的な概念を理解しておくことでやるべきことは明確になります。
▼一緒に読まれている記事はこちら↓
