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

 

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

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

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

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

 

・要求定義：要求定義書

・要件定義：要件定義書

 

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

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

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

 

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

 

上流工程は設計

 

 

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

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

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

 

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

 

 

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

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

 

要件定義の具体的な流れ

 

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

 

 

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

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

 

要求の細分化

 

 

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

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

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

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

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

 

要件定義書の作成

 

 

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

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

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

 

 

要件定義において重要な用語と進め方のコツ

 

要件定義という工程を深く理解するためには、いくつかの用語について正しく理解する必要があります。

ここでは要件定義に関わる重要ワードをいくつか整理して説明しましょう。また、それぞれのフェーズをスムーズに進行させるためのコツもお伝えします。ぜひ参考にしてみてください。

 

業務要件とは？

 

業務要件は要件定義の初期に実施する工程です。業務要件のフェーズでは、システム化に先立って現状の業務がどのように流れているかを分析し、問題を抽出した上で、新たに何を実現すべきかを決めていきます。

この段階ではシステムは意識せず、あくまで業務そのものに焦点を当てます。業務要件では業務に詳しい担当者に参加してもらい、密度の高いコミュニケーションを図ることが大切です。

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

 

システム要件とは？

 

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

ここで決められる、システム開発の方向性をシステム要件と呼びます。一見、業務要件と大きな違いがないように見えますが、実際には両者にギャップがあることが多いので注意しましょう。

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

例えば業務要件が「取引先の地名をすぐ調べられるようにしたい」だとしましょう。これに対するシステム要件は、「ノートPCからブラウザ経由で検索できること」や「スマホにインストールしたアプリを使う」などの手段になります。

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

 

機能要件とは？

 

システム要件でシステム化の方向性が決まると、システムに必要な機能について検討します。

機能要件はシステム開発を通して最低限実現すべき機能です。機能要件はヒアリングなどの形でクライアントに具体的に確認することができます。

また、機能要件の成果物は、後述の非機能要件と合わせて、後続の基本設計フェーズでの重要なインプットとなります。

 

非機能要件とは？

 

機能要件がクライアントにとって必須の機能なのに対して、非機能要件はクライアントが「あればいいな」と考える要件です。

非機能要件を実現していくことでクライアントの満足を上げることができます。例えばシステム画面の切り替え速度などの性能要件があげられます。

非機能要件は必ずしも明確に要望されないため、予算や納期も意識しつつ、クライアントと合意形成を図ることが重要です。

 

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

 

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

 

 

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

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

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

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

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

 

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

 

 

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

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

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

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

 

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

 

 

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

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

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

 

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

 

 

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

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

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

 

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

 

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

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

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

 

要件定義のまとめ

 

 

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

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

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

 

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