要件定義の基礎知識（要求と要件の違い）

 

システム開発を行う上で「どうシステム化するのか」を決めるのが要件定義です。システム開発は、ユーザー求める要求を要件へ落とし込むところから始まります。

まれに混同してしまうのが「要求」と「要件」です。

要求と要件は似ていますが、明確に違う部分があります。それは要求定義が「アナログ」なものと定義するならば、それをITシステムという「デジタル」に変換するのが要件定義です。

それぞれはドキュメントという形で残されるのが一般的です。

 

・要求定義：要求定義書

・要件定義：要件定義書

 

要件定義は、お客様の要求定義をいかにシステム化していくかを定義する、いわばシステム開発の土台となるものです。

ですので、要求にある細かな動作や、それに伴ってユーザーが行いそうなエラー動作までを想定して、ひとつひとつをプログラムの動作でイメージしなければなりません。

要件定義は、システム開発の上流工程に位置します。様々な種類のプログラミング言語を知ることや、豊富なプログラミング経験が活かされる業務です。

 

上流工程と下流工程の定義

 

上流工程は設計

 

 

システム開発では、要件定義から詳細設計までを上流工程と言います。これは、システム構築に用いられるウォーターフォールモデルから取られたもので、システムの作り始めを上流、システム構築完了までを下流と言い、滝をイメージした用語です。

システム開発では、要求をどのようにプログラミングすべきか、あるいは実現するためにはどのような手段があるのかを明確にイメージするスキルが必要です。特に経験による“勘”が重宝されます。

ユーザーが欲しい機能を提供するために最適な言語や、オペレーションの流れを想定し、「要件定義書」から「システム設計書」を完成させなければなりません。

 

下流工程はプログラミングからテストまで

 

 

下流工程では、仕様書を基にプログラミングによるシステム実装を行います。また、機能ごとに行う単体テストから、全体を通した総合テストなども下流工程に含まれます。

上流工程をこなすエンジニアは、下流工程での豊富な経験が基盤です。下流工程での経験が多いほど、様々なパターンや手法を明確にイメージできるようになるのです。

 

要件定義の具体的な流れ

 

ユーザー要求のヒアリング

 

 

企業では、よりユーザーに近い部署が営業を行い、ユーザーからの要求をヒアリングしてくるところからシステム案件が始まります。もちろん、システムエンジニアが営業を兼任する企業も多いのですが、そこでユーザーの要求をシステム要件へ変換していくのが要件定義の始まりとなります。

ユーザーが目指すのは、これまで手作業だった業務のシステム化や、既存システムの変更などです。これらの要求を正確に把握し、細かく的確にイメージすることで、具体的なシステムの全体像を把握します。

 

要求の細分化

 

 

システムの全体像が把握できたら、実際のプログラミングにおける機能のひとつひとつを、細分化して要件としてまとめていきます。

ユーザーの業務フローの詳細を把握し、全てがひとつのシステムとして動くように、実装すべき機能を洗い出していきます。ユーザーの要求や業務フローにおいて、取りこぼしが無いように配慮しなければなりません。

また、要求内容の全てをシステム化できるとは限りませんので、要件定義の時点で切り分けをしておく必要もあります。

機能範囲が明確でなければ、ここから始まるシステム開発の途中で“仕様バグ”として、大きな手戻りを発生させてしまうことになります。

最悪の場合、プロジェクトの失敗を招く元凶となってしまいますので、細かいところまでユーザーとのすり合わせが必要です。

 

要件定義書の作成

 

 

要件の機能を細分化できたら、いよいよ要件定義書の作成です。要件定義書で書き出すドキュメントの内容は、要件定義後の工程である「システム設計」に落とし込む前段階です。

要件定義書で定められたシステムの全体像から、細分化された機能までをしっかりと記載しておかなければ、システム設計の工程で頓挫します。

要件定義書はシステム開発における全ての基盤となりますし、システム運用開始後の保守にまで影響を及ぼすため、システム的な矛盾が出ることはもちろん許されませんし、ユーザーとの意識合わせが必須となります。

 

要件定義を行うために必要なスキル

 

要件をヒアリングするコミュニケーションスキル

 

 

要件定義に必要なスキルは、要求と要件との間に意識のズレが生じないよう、細部までをヒアリングするコミュニケーションスキルです。

ユーザーや自社の営業部署が、要求するものを細部に渡るまで表現できるわけではありません。

ですので要件定義を行う際には、コンピューターの動作としてユーザー要求を理解し、アナログな部分も含めた全てがどのような動きになるのかを、ヒアリングにて決定していく必要があります。

また、どうしてもシステム化できない部分も明確にしていかなければなりません。この切り分けが曖昧なものは、全て仕様バグとして後々浮き彫りになってしまいます。

コミュニケーションスキル、特にヒアリングスキルは、要件定義において非常に重要なスキルと言えます。

 

具体的なシステムをイメージするスキル

 

 

要件定義はアナログをデジタルに置き換える作業です。プログラムはコーディングした通りにしか動きませんので、ユーザーの要求の細部まで把握する必要があります。

そのためには、要求がシステム化した際にどのように動くのか、またユーザーのオペレーションがどのようになるのかを具体的にイメージするスキルが必要です。

そのスキルは、下流工程の豊富な経験が土台となります。プログラミングをする際には、完成したシステムの動きを明確にイメージする能力が必要だからです。

また、プログラミングやテストの豊富な経験は、システムをイメージするスキルを無意識に向上させることに繋がります。

 

システムが完成までの工程を逆算するスキル

 

 

ユーザーの要求がシステム化し、運用された状態を明確にイメージすることは、プログラミングなどを含めたその工程を逆算するスキルとして役に立ちます。

システムは細かなプログラムの集まりです。それら大きなまとまりとなったシステムの全体像から、どのようなプログラムがどこで動くべきなのかを逆算することで、ある程度の工数も把握することができます。逆算するスキルはスケジュールの大まかな把握にも役立ちます。

また、それに伴い開発時の役割分担も同時にイメージすることで、その後の工程である設計などもスムーズに進めることができるでしょう。

 

要件をドキュメント化するスキル

 

 

ユーザーの要求をシステムへ落とし込むと、最後にドキュメント化するために、システムの詳細を数値や言葉で正確に表現するスキルが必要です。

ドキュメントは誰が読んでも分かりやすい表現が必要ですし、実際にシステムが稼働した数年後に、システムの改良が必要な場面でも”読める“ドキュメントにしなければなりません。

また、要件定義書が完成し、その後のシステム設計やプログラミングの段階での手戻りは許されません。ですので、ドキュメント作成前には、表現方法やドキュメントフォーマットの統一をしておく必要があります。

 

要件定義で全てが決まる！

 

ITシステムは”要件定義で決まる“と言っても過言ではありません。要件定義書は、建築で言うところの設計図です。

全ての土台となる要件定義書にミスがあれば、システムはもちろんのことユーザーの業務を止めてしまうことになります。逆に、要件定義さえしっかりしていれば、その後の開発が非常にスムーズに進みます。

要件定義が難しいと言われるのは、プロジェクトを成功させるために要求の細部まで、あるいは運用・保守に至るまでをミスなく決定しなければならないからです。

 

要件定義のまとめ

 

 

要件定義は、システム開発における上流工程であり、システム化の始まりでもあります。また、要件定義に必要なのはシステム開発における全工程の経験値です。

最初から要件定義を行うのはかなりハードルの高いものとなりますので、下流工程で沢山の経験を積まなければなりません。

要件定義がいかに重要であるかを理解し、全体的な流れを把握しながら下流工程を経験することで、より早く要件定義などの上流工程へ辿り着けるはずです。

 

 

弊社Geeklyでも要件定義に携わるような、IT業界に特化した数多くの求人を保有しています。お気軽にご相談ください！