要件定義とは？決定までの具体的な流れや要件定義書ついて詳しく解説！

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

 

 

システム開発を行う上で「何をどうシステム化するのか」を決めるのが要件定義です。

システム開発は、ユーザーの求める要求を要件へ落とし込むところから始まります。

似た言葉として「要求」と「要件」がありますが、明確に違う部分があります。

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

それぞれは要求定義書、要件定義書としてドキュメント形式で残されるのが一般的です。

 

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

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

要件定義は、システム開発の上流工程に位置します。

様々な種類のプログラミング言語を知ることや、豊富なプログラミング経験が活かされる業務です。

 

 

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

 

 

上流工程は設計

 

システム開発では、要件定義から詳細設計までを上流工程と言います。

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

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

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

 

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

 

下流工程では、仕様書を基にプログラミングによるシステム実装を行います。

また、機能ごとに行う単体テストから、全体を通した総合テストなども下流工程に含まれます。

上流工程をこなすエンジニアは、下流工程での豊富な経験が基盤です。

下流工程での経験が多いほど、様々なパターンや手法を明確にイメージできるようになるのです。

 

まずはキャリアの相談をしてみる

 

 

要件定義の具体的な流れ

 

 

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

 

企業では、よりユーザーに近い部署が営業を行いユーザーからの要求をヒアリングしてくるところからシステム案件が始まります。

もちろん、システムエンジニアが営業を兼任する企業も多いのですが、そこでユーザーの要求をシステム要件へ変換していくのが要件定義の始まりとなります。

ユーザーが目指すのは、これまで手作業だった業務のシステム化や、既存システムの変更などです。

これらの要求を正確に把握し、細かく的確にイメージすることで、具体的なシステムの全体像を把握します。

 

要求の細分化

 

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

ユーザーの業務フローの詳細を把握し、全てがひとつのシステムとして動くように、実装すべき機能を洗い出していきます。

ユーザーの要求や業務フローにおいて、取りこぼしが無いように配慮しなければなりません。

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

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

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

 

要件定義書の作成

 

要件の機能を細分化できたら、いよいよ要件定義書の作成です。

要件定義書で書き出すドキュメントの内容は、要件定義後の工程である「システム設計」に落とし込む前段階です。

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

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

 

要件定義書で定義すべきもの

 

 

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

ここでは要件定義に関わる重要ワードをいくつか整理して説明しましょう。

 

 

また、それぞれのフェーズをスムーズに進行させるためのコツもお伝えします。ぜひ参考にしてみてください。

 

機能要件

 

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

機能要件はシステム開発を通して最低限実現すべき機能です。

機能要件はヒアリングなどの形でクライアントに具体的に確認することができます。

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

 

非機能要件

 

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

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

例えばシステム画面の切り替え速度などの性能要件、セキュリティ面、デザイン面の要件があげられます。

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

 

サイト要件

 

サイト要件はWebサイトの要件定義を指します。

ユーザーからのアクセスを目的として作られるWebサイトは、あらかじめ明確にしておくべき項目があります。

例えばターゲット層や利用端末、ブラウザ、OS、SEO対策などです。

目的やコンセプト、どのような機能を実装するか、また予算やスケジュールなども該当します。

 

インフラ要件

 

システムの環境を支える基盤がインフラです。

インフラ要件では基本設計以降のフェーズのコストを見積もることも重要です。

インフラ要件定義書はほぼ非機能要件となります。

 

セキュリティ要件

 

システムの安全性確保に関する要求がセキュリティ要件です。

情報漏洩やウイルス感染などの被害による社会的・経済的損失を防ぐために重要な項目であり、セキュリティだけはコストを考慮に入れないことも多いです。

さまざまな攻撃手法のパターンに対応することが求められます。

 

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

 

 

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

 

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

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

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

また、どうしてもシステム化できない部分も明確にしていかなければなりません。

この切り分けが曖昧なものは、全て仕様バグとして後々浮き彫りになってしまいます。

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

 

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

 

要件定義はアナログをデジタルに置き換える作業です。

プログラムはコーディングした通りにしか動きませんので、ユーザーの要求の細部まで把握する必要があります。

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

そのスキルは、下流工程の豊富な経験が土台となります。

プログラミングをする際には、完成したシステムの動きを明確にイメージする能力が必要だからです。

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

 

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

 

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

システムは細かなプログラムの集まりです。

それら大きなまとまりとなったシステムの全体像から、どのようなプログラムがどこで動くべきなのかを逆算することで、ある程度の工数も把握することができます。

逆算するスキルはスケジュールの大まかな把握にも役立ちます。

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

 

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

 

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

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

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

 

 

 

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

 

 

ITシステムは”要件定義で決まる“と言っても過言ではありません。

要件定義書は、建築で言うところの設計図です。

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

 

 

 

要件定義のスキルを磨こう

 

 

今後も需要が高いスキルが身に着く

 

コミュニケーションやマネジメントのスキルは、エンジニアに限らず多くの職種で重宝されます。

しかし、特にエンジニアにおいては、これらのスキルの有無は大きく差がつくポイントとなるでしょう。

これからはよりITが普及し、多くの人がシステムに触れる時代。

技術用語のわからない顧客や、社内の営業、事務の方と同じ目線で会話ができるエンジニアの市場価値が高まるのは当然です。

同様に人材不足が叫ばれるなかで人々をマネジメントし、プロジェクトを最短で成功に導くことができる人材もまた、市場からの需要が高まるのです。

 

年収にも大きな影響が

 

要件定義はシステム開発の上流部分を担い、非常に重要な業務です。

実際の職種としても、一定の経験を積んだシステムエンジニアだけでなく、プロジェクトマネージャーやITコンサルタントが担うこともとても多いです。

システムの全体像を把握しなければならないため、難易度は高く責任も大きくなりますが、その分だけ下流のエンジニア職種と比較して平均年収は高い傾向にあります。

 

技術者としてのキャリアを積み上げたい人にとっても、要件定義の経験はおすすめです。

「システムの全体像を考えてから実装までできる」つまり全体視点を持ちつつ開発ができるようになるためです。

 

まずはキャリアの相談をしてみる

 

要件定義に悩んだら、IT転職のプロに相談しよう

 

 

システム開発を行う上で「どうシステム化するのか」を決めるのが要件定義であり、要件定義書を作成するためにはユーザーの要求をシステムの要件へ変換・細分化することが必要です。

そのため用語の正しい理解のほか、コミュニケーション能力、具体的なシステムをイメージする能力など様々なスキルが求められます。

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

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

 

「未経験だけど要件定義に携わりたい」「開発エンジニアだが、更に上流工程に携わりたい」「既に要件定義に携わっているが年収を上げたい」

これらに当てはまる方はIT専門の転職エージェントであるギークリーを活用することがおすすめです。