キャリア

要件定義とは？システム開発における要件定義の位置付けと役割

ENGINEER.CLUB編集部

• 最終更新日:2024/9/1

システム開発プロジェクトの一番はじめに行う「要件定義」について、これから始める方向けに要件定義の概要や役割、具体的な進め方や必要なスキル等、要件定義書の作成方法を解説していきます。この記事を通じてこれから要件定義にチャレンジする方が理解を深め、成功に結び付く参考としてみてください。この記事では、要件定義初心者の方でも要件定義について理解できるように、以下の内容を解説します。

• 要件定義とは？
• 要件定義の重要性
• 要件定義と基本設計との違い
• 具体的な進め方とそのために必要な項目とスキル
• 要件定義書の作成

よい要件定義が出来ればプロジェクトの半分は出来ているといっても過言ではありません。ぜひ最後まで読んでよりよい要件定義を行いプロジェクトの成功に結び付けましょう！

１．要件定義とは

要件定義とは、システム開発の一番始めに行う工程で、必要な機能や要求を分かりやすくまとめることです。ここでシステム開発の「目的」を明確にすることにより、後の工程で実装する範囲や内容（システム要件）を決定させていく工程となります。

１-１．システム開発での要件定義の位置づけと役割り

システム開発における要件定義の位置とと役割りは以下のとおりとなります。

要件定義は上流工程の中心に位置づけられており、経営層やユーザー企業や部門の目標や要望を理解し、それを具体的なシステムやソフトウェアの機能、性能、操作性、品質、セキュリティ、制約条件等に落とし込みます。それによってシステムの利用目的や目標が明確化され開発の方向性が定まります。また、開発コストにも大きな影響を与えるため要求事項と予算のバランスを取るという重要な役割りがあります。

２．要件定義の重要性

要件定義はシステム開発の初期段階で行われる工程であり、プロジェクトの成否やシステムの品質を左右する非常に重要な役割りを担っています。要件定義は基本設計の前に行われる工程であり、基本設計は要件定義をもとに作っていくことになります。

２-１．要件定義はプロジェクト全体で大きな要素となる

前述していますが、要件定義は開発の最初に行われる工程であり、プロジェクトの成否に大きく関わってくるとても大きな要素となります。もし、要件定義が不十分な状態でプロジェクトを進めてしまうと。。。

• 予定していたものと全く違うシステムが出来上がった
• せっかく作ったものの全然役に立たなかった
• 予算が大幅にオーバーしてしまった
• 開発スケジュールが大幅に遅延し、最終的な納期に間に合わなかった

そのようなトラブルにつながりかねないほか、後から「こんな機能が欲しかった」等、ユーザーから隠れた要望が明らかになり、開発がやり直しになりコストや時間が増大する可能性があります。このようなリスクを避け、ユーザーが求める成果物を決められた期間内に完成させるためには、要件定義の段階でユーザーとベンダーとでしっかりと打合せを重ねて、お互いに納得するまでニーズと方向性のすり合わせを行う必要があります。

３．要件定義と基本設計の違い

要件定義と基本設計を混同する方もおられるのでその違いについて以下で説明します。要件定義と基本設計を図で示すと以下のようになります。

３-１．基本設計：実装機能の明確化

基本設計とは、要件定義の内容を受けて、実際にシステムを動かす部分の仕様を決定する工程です。要件定義でユーザーからの要求をもとに実装すべき機能や性能を決める工程となります。実装する機能が明確化されることにより、次の工程である基本設計で記載すべき仕様がより明確化します。

３-２．基本設計：システム仕様の明確化

要件定義が「言葉」でシステムに必要な機能を明確化するプロセスとするなら、基本設計は開発すべき内容を「図」で視覚的にユーザー側へ共有し、システムの完成イメージをすり合わせていくプロセスであるといえます。基本設計の工程でそれぞれの機能がどのようなものか、何をする機能なのか、機能同士はどのようにつながるのか、各機能の役割りについてさらに具体化していきます。

４．要件定義をするにあたり重要な要素

要件定義をするにあたり、重要となる要素として、機能要件と非機能要件、性能要件、品質要件があります。要件定義にて、システムの目的や目標を実現ｓるうために必要な要素を整理し、具体的な要件として明確化します。

４-１．機能要件と非機能要件

機能要件とは、「必ず実装する必要がある機能」のことで、システム化の要となる部分です。機能要件はユーザーが「これが出来なくては困る」という直接的にヒアリング出来る希望と繋がりますので比較的簡単に決まることが多いです。機能要件は「出来て当たり前」の最低限のラインなので、機能要件を明確にすることでプロジェクト全体のスケジュールが大体決まります。

非機能要件とは、実装される要件のうち機能以外の部分のことを指します。IPA（独立行政法人 情報処理推進機構）でも定義されています。（非機能要求グレード）大きくは可用性、保守運用性、セキュリティ等があります。非機能要件はユーザーの隠れた要望であり、システムを支える品質の部分と言えます。非機能要件は一見ユーザーからは認識されづらく、直接評価に結び付かない。コストが掛かる等思われがちです。しかし、非機能要件が充実していればユーザーの満足度アップが期待できます。サクサク動作する、便利な機能がある、安定・安心して稼働している、サポートが充実しているということが実現できればユーザーが長く利用してもらえるシステムになります。

４-２．性能要件

性能要件は、そのシステムがどのような機能を持つ必要があるかと定義することです。例えば、画面の応答時間は５秒以内である、バッチ処理能力は1000件/秒以上である必要があるなど、具体的なシステム性能を定義します。

４-３．品質要件

品質要件は、システムが持つ品質基準を定義することです。例えばセキュリティ面やユーザーが使用している時の」システムの動きなど、品質は最低限どの程度満たすべきかを定義します。品質は目に見えないことが多く、ユーザーが体感して評価する部分もあるため、言語化してユーザーと合意出来るよう定義することが重要です。

５．要件定義の進め方と必要な項目

要件定義は、開発するシステムのユーザーへの要求ヒアリングを行いそれを具体化、分析したのちに要件として落とし込む流れで作成を進めます。要件として確定・合意するためにはいくつかのステップを踏み、要求を具体化する必要があります。

５-１．まずはヒアリング！

要件定義でまず行うヒアリングは最も重要な工程のひとつです。要件定義後もヒアリングは重要ですのでここでのみではなく、各工程でも必要に応じてヒアリングは大切です。ヒアリングはビジネス概要から、ビジネスを推進するうえでの課題や問題点を解決するために必要な機能だけでなく、既存システムや外部システム・サービスと連携する必要があるのか、将来的に連携させたいのかなどについても確認します。そのほか情報セキュリティ規定や顧客要望など直接業務に関係することだけでなく、システムを取り巻く環境についても詳細に確認することが重要です。ヒアリングする際は「５Ｗ２Ｈ」を意識すると曖昧さが無くなりヒアリング精度が格段に向上します。

ヒアリングにおける「５Ｗ２Ｈ」を下記に示します。

ヒアリングを成功させるためには、参加する関係者全員がIT技術に詳しいわけではないという事を念頭に置き、専門用語はできるだけ使用せずサンプルやフローチャートなどの図表を用いて分かりやすくなるよう工夫することが大切です。

５-２．「要求」を「要件」に変換し要求を具現化・細分化！

ユーザーの要求をヒアリングで明確化したら、実現できる内容か整理します。挙がったすべての要求を実現できるとは限らないため、打合せなどでユーザーと話し合い、要求に優先順位をつけましょう。システム開発時の要件は大きく「必須要件」と「希望要件」の２つに分かれます。

• 必須要件とは、必ず実現したい機能などの要件です。
• 希望要件とは、できれば実現したい要件です。

その他、リプレース等の場合「現行踏襲」も挙がってくるので現行の要件を確実に確認する事が大切です。

これらの要求を細分化する事でヒアリングで挙がったユーザー要望を漏らすことなくプロジェクトを進められるでしょう。このように詳細な要求と要件を具現化できれば、全体のスケジュールが把握しやすく、成功しやすくなります。

６．要件定義に必要なスキル

要件定義を的確に実施するためにはある程度のスキルが必要ですので、そこを確認していきましょう。要件定義を行うために必要なスキルは以下のようなものがあります。

• ITスキル
• 客先の業務・業界についての知見
• コミュニケーションスキル
• 実現可能なシステムの設計を提案できるスキル
• 要件をドキュメント化するスキル

６-１．ITスキル

当然ながら要件定義では、ユーザーからの要求が実現可能かを判断する必要があります。その判断をするためには十分なITスキルが必要です。ある程度はITの専門知識がないと判断出来ないケースもあります。ITスキルは開発者側とユーザー側である発注者側の双方に必要です。開発を依頼する側がITスキルを備えていないと、実現可能な使用や機能なのかを判断出来ず、スムーズは形で要件定義を進めることができなくなります。

６-２．客先の業務・業界についての知見

システム開発を行ううえで十分なスキルがあっても、業務や業界についての知見がないと、要望に見合ったシステムを開発することは難しいです。そのため、システム開発担当や開発依頼の決定権を持つ責任者は、ユーザーが行っている業務をきちんと調べて理解しておく必要があります。ユーザーのことを理解するのに効果的な方法は、ユーザーと意思疎通がしやすい関係を築くことです。ヒアリング段階やその前の段階で、可能な範囲でユーザーとコミュニケーションをとり業務のことや課題に思っていることをいろいろ教えてもらえるように努めましょう。

６-３．コミュニケーションスキル

要求を引き出すスキルはヒアリングやコミュニケーションなどの能力で、ユーザーの意図を把握する力のことを意味しています。ユーザーがある程度要求をまとめているとしても、話をする中でユーザーが気づいていない要求も少なからずあります。その要求を引き出してユーザーに伝えられるとより良いシステムを完成させることが可能です。実現の可否を判断し、実現が難しいものであればユーザーへ説明し、納得いただく事も重要です。また、今後の工程をスムーズに進めるためにもユーザー側と良い関係性を築くためにもコミュニケーションスキルは非常に重要です。

６-４．実現可能なシステムの設計を提案するスキル

ユーザーからの要求をまとめたら、その要求の内容を細かく設計していくスキルも必要です。なぜなら、要件定義の担当者が実現可能だと伝えて発注して、開発メンバーがユーザーの要求を実現させるのに苦労してしますケースも少なくありません。要件定義を作成する段階で開発メンバーがどこまで実現可能な内容なのかをイメージし、そのイメージを踏まえて要件定義を固められるかが大事になってきます。

６-５．要件をドキュメント化するスキル

要件定義の担当者がシステムの設計をイメージできているだけでは意味がありません。そのイメージを開発メンバーに正確に伝える必要があります。正確に情報を伝えるためには要件定義の内容をドキュメント化して伝えるスキルが求められます。開発メンバーにもわかりやすく伝えられるように、文章だけではなく図なども積極的に活用しましょう。

７．要件定義書を作成しよう

最後に要件定義の成果物といえる要件定義書を作成します。要件定義書は上流文書となるためユーザーの上位職の方などが読むドキュメントになりますので、有識者等の知見を借りながら丁寧に作成することが大切です。

７-１．目的は関係者全員の認識を揃えること

要件定義書は誰か1人が見るものではありません。システム開発に携わるメンバーはもちろん、上位職の方などIT分野の専門知識があまり豊富でないユーザーなど、関係者となるたくさんの人が見るものです。そして、各関係者の間で専門知識レベルが異なるということは、認識のずれが発生するということになります。認識のずれを放置したままプロジェクトを進めてしまうと、後々想定外のシステムに出来上がって、「思っていたものと違う」「こんなはずではなかった」とクレームにつながる恐れがあります。そのため、要件定義書を作成する際は、ユーザーが最終的な成果物を具体的にイメージできるよう、ITに関する専門知識がなくともすんなり理解できるよう説明を分かりやすく工夫することが大切です。

７-２．作成だけではなく共有方法にも工夫が必要

要件定義以降の工程では複数のチーム・メンバーとなるケースがほとんどです。そのため、作成した要件定義書は共有するだけでなく、読み合わせ等を実施し、記載されていない背景や仕様検討の経緯なども併せて共有することで担当者間での共通認識、理解のギャップを埋めることとなりますのでぜひ実施するようにしてください。

８．まとめ

要件定義と聞くととても難しく経験を積んだ上級SEが行うというイメージがあるかと思います。しかし、ITスキルだけではなく業務知識の習得、顧客とのコミュニケーション、ドキュメント作成等、ご自身の能力をさらに向上できる要素が多々あります。また、曖昧なユーザーの要求をヒアリングし実現させるための答えをドキュメントに落とし込むという重要な役割りを担っているため非常にやりがいがあります。これから要件定義をやっていく方はこの記事を参考によりよい要件定義を実施しプロジェクトを成功させて頂ければ幸いです。