システム開発において、要件と要件定義は、プロジェクトの土台となる重要な要素です。
しかし、システム開発を求める顧客の中には、要件と要件定義の違いが混同しているケースがあり、認識の齟齬が生じる原因の一つとなっています。
この記事では、要件や要件定義の概要、要件定義を行う際の手順などについて解説しています。また、要件定義を行うポイントも紹介しているので、システム開発に携わる方、実際に顧客と関わる機会のある方はぜひ参考にしてください。
要件とは
システム開発やソフトウェア開発などにおける要件とは、顧客が求めるシステムを実現するために 満たさなければならない条件を指します。言い換えると、システムが達成すべき機能や性能、品質などを明確に定義したものです。
要件はシステムを成立させるために欠かせないものであり、要件の質が成果物の品質に直結するといっても過言ではありません。
要件があいまいで、開発側と顧客側で共通認識がないと、開発途中で修正が必要となり、スケジュールやコストの増加、さらには品質問題につながる可能性も高まります。そのため、最初の段階で要件を明確にしておく必要があります。
要件定義とは
要件定義とは、各種開発業務を始める前に、システムに必要な機能や性能、品質などを明確に定義する作業のことです。
要件定義を行うにあたり、顧客側がシステム開発を通じて達成したい目標や、システムに期待していることや、どのような機能を求めていて、制約条件はどの程度あるのかなどを細かく落とし込んでいく必要があります。
顧客が求めるすべての要件を満たすことは、必ずしも現実的ではありませんが、コストや人員、技術的な制約などを考慮し、実現可能な要件の優先順位をつけることが重要です。
プロジェクトは、要件定義の内容をベースに進行するため、要件定義の入念な実施はプロジェクトの重要な役割を担います。
要件定義を行う理由
要件定義を行う理由は、要件定義の内容がプロジェクト全体の指針となるためです。
システム開発は、要件定義→外部設計→内部設計→プログラミング→テストを経て運用に進むケースが一般的です。要件定義は、すべての作業の最初の段階で行うものであり、機能・性能に関する機能要件やセキュリティなどに関する非機能要件を明確に定義していきます。
その後の工程は、要件定義で決めた内容に沿って進めていくため、最初の工程となる要件定義は特に重要なものです。
要求定義との違い
要件定義と混同しやすいものに要求定義がありますが、両者は異なる意味を持つものです。
要求定義は、開発にあたって顧客の要望を確認することです。要件をヒアリングすることが要求定義であり、要件定義の前工程として行われます。一方、要件定義は、要求定義で収集した顧客の要望を基に、システムを実現するために必要な仕様を具体的に定めることです。
顧客の求めるすべての要件をシステムに落とし込むことは、予算、人員、納期の制約により必ずしも実現可能ではありません。そこで、要求定義という工程を通して、開発側は顧客のニーズを丁寧にヒアリングし、その中から実現可能な要件を取捨選択します。そして、要件定義という工程で、具体的な仕様として定義していくのです。
合わせて読みたい
![開発業務のベースになる要件とは?要件定義の進め方も解説](https://lychee-redmine.jp/wp-content/themes/agileware/assets/img/noimage.jpg)
開発業務のベースになる要件とは?要件定義の進め方も解説
要件と要件定義は、開発業務においてベースとなるものです。この記事では、要件や要件定義の概要、要件定義を行う際の手順などについて解説しています。また、要件定義を行.....
要件定義の手順
ここからは、要件定義を行う具体的な手順を紹介します。要件定義はプロジェクト全体の指針となるため、手順を理解し正しく取り組むことが重要です。
「要件」「要件定義」という言葉の共通認識を持つ
要件定義を行うにあたり、開発側と顧客との間で要件と要件定義という言葉の共通認識を持つ必要があります。
要件と要件定義を同じものと考えていると、顧客は「要件を伝えた時点で要件定義が完了した」と誤解し、自身たちの希望がすべて満たされると考えてしまう可能性があります。
このように認識違いが発生すると、開発が進むにつれて、修正や仕様の見直しなどが発生し、時間やコストが余計にかかってしまう恐れがあるため、「要件」と「要件定義」の言葉の定義を共有することが重要です。
顧客の要求をヒアリングする
要件と要件定義の違いを明確に理解した上で、顧客が何を求めるのか要件をヒアリングします。
ヒアリングでは、顧客の要求を漏れなく正確に理解し、具体的な機能や性能に落とし込めるようにしなければなりません。ただ相手の言うことを聞いてメモを取るだけでなく、相手の話を聞きながら「それなら〜といった機能も必要なのでは?」など、潜在ニーズを引き出すことで、より満足度の高いシステムに仕上げることができます。
顧客側は機能面に関心を持ちやすい一方で、セキュリティ面などには具体的な要求を持っていないことも多いです。このような場合、開発側が積極的に顧客へヒアリングを行い、潜在的な要求を明確にすることが重要です。
ヒアリングを丁寧に行えば、開発後の手戻りなどの発生も回避できるため、できる限り細かくヒアリングを行いましょう。
要求を分類して機能を選別する
ヒアリングの内容を踏まえて、顧客の要求を分類し、機能を選別する必要があります。これは、予算や人員などの都合により、すべての要求を機能に落とし込むことができないためです。
機能を選別するにあたり、システムがどのような業務に利用されるのか、業務プロセスを明確にすることが重要です。プロセスを踏まえた上で、実装すべき機能の優先順位をつけ、システムに落とし込む要件を決定していきます。
要件定義書を作成する
分類・選別が完了したら、要件をドキュメント化し、要件定義書を作成します。要件定義書には、これまでのステップで決定した機能や性能に関する要件をはじめ、拡張性や保守性、セキュリティ、システム環境といった非機能要件もすべて記載する必要があります。
さらに、用語の定義や開発スケジュールなども記載して、顧客との認識の齟齬を生まれにくくします。
要件定義書を作成したら、顧客とすり合わせを行い要件提議書を完成させましょう。
要件定義で定義するべき内容
要件定義書では、機能要件、サイト要件、インフラ要件、セキュリティ要件を定義する必要があります。ここではそれぞれの概要を解説します。定義するべき内容を理解できれば、ヒアリングの際に聞く内容が明確になるため、ぜひ参考にしてください。
機能要件
機能要件とは、システムに実装するべき機能を明確に示すものです。顧客がシステムに何を求めているのかを明確にし、実現すべき機能を漏れなく洗い出すことが重要です。
機能要件は、システム開発において最低限満たすべきラインであるため、機能要件の把握により開発工程の流れを想像できます。
サイト要件
サイト要件は、Webサイトの要件定義において重要な要素の一つです。Webサイトは顧客ではなく、顧客の商品のユーザーやファンが利用するものです。
そのため、ターゲットの属性やブラウザ・OSの種類などを顧客からヒアリングして明確にしなければなりません。
インフラ要件
インフラ要件とは、システムを稼働させるために必要なハードウェア、ソフトウェア、ネットワークなどの環境を定義するものです。具体的には、サーバーやデータベース、SSL証明書などが該当します。
インフラ要件の高性能化は、システム全体の性能向上につながりますが、コストも増加します。そのため、顧客の予算やニーズを考慮しながら、適切な要件を定義することが重要です。
セキュリティ要件
セキュリティ要件とは、その名の通りシステムのセキュリティを確保するための要件です。
システム内で機密情報を扱うケースもあるため、情報漏洩やウィルス感染などが起こらないようにするためにも、セキュリティ要件は非常に重要です。システムに対する攻撃手法は多様化しているため、あらゆる攻撃パターンを想定した対策が求められています。
要件定義のポイント
ここからは要件定義を行うポイントを紹介します。基本的な部分ですが、しっかりと理解し実践することで顧客との認識齟齬を未然に防ぐことができます。
5W2Hを意識する
要件定義の手順で最初に行うヒアリングでは、5W2Hを意識して相手に機能などを確認することが重要です。
5W2Hの概要は以下の通りです。
- Why:なぜシステムが必要なのか
- What:顧客が抱えている課題はなんなのか
- Where:開発範囲はどの程度なのか
- Who:システムは誰が使用するのか、運用者は誰か
- When:いつまでにシステムが必要なのか
- How:どのように要件を実現するのか
- How much:予算はどのくらいか
これらの点を抑えれば、顧客と開発側で共通認識を持つことができます。
ドキュメントで残しておく
要件定義は、ドキュメントで残しておくことが大切です。目に見える形で残っていれば、関係者全員がシステムの内容や機能を把握できます。
また、ドキュメント化する際は、開発に関する知識を持たない人に対しても伝えられるように、わかりやすさを意識してまとめることが重要です。必要に応じて、図表を使用するなどし、誰が読んでも理解できるようにしましょう。
要件定義書の読み合わせを行う
要件定義書を作成した後は、顧客と開発側とで読み合わせを行い認識をすり合わせることが重要です。
各項目の内容を説明することで、「あの機能がない。」といったトラブルを未然に防ぐことができます。すり合わせていく中で不明点などが出てきた場合は、丁寧に説明し、すべてをクリアにしておきましょう。
技術者が実現可能性を確認する
顧客の要求をすべて満たすことは困難な場合があるため、要件定義においては、技術者による実現可能性の確認が不可欠です。
技術者による確認がないと、要件に抜け漏れが生じる可能性もあり、後工程での問題発生や手戻り、コストやスケジュールの圧迫を招きかねません。
合わせて読みたい
![開発業務のベースになる要件とは?要件定義の進め方も解説](https://lychee-redmine.jp/wp-content/themes/agileware/assets/img/noimage.jpg)
開発業務のベースになる要件とは?要件定義の進め方も解説
要件と要件定義は、開発業務においてベースとなるものです。この記事では、要件や要件定義の概要、要件定義を行う際の手順などについて解説しています。また、要件定義を行.....
要件定義のプロセスを正しく理解しよう
今回は、要件や要件定義の概要、要件定義の手順などについて解説しました。要件とは、顧客の求めるシステムを実現するために満たさなければならないことで、要件定義は、要件やシステムに必要な機能などを明確に定義する作業です。
要件定義にあたっては、顧客と開発側とで認識の齟齬が生まれないよう、要件と要件定義の違い、要件定義書作成後のすり合わせなどを丁寧に行う必要があります。要件定義は、その後の開発工程の指針となるものです。
また、開発プロジェクトがスタートしたら、管理ツールを使って効率よく進めることがポイントです。
Lychee Redmineは、進捗管理や工数管理、予算管理などプロジェクトに関わる各種管理業務ができるプロジェクト管理ツールです。
導入社数は、7,000社を超えているなど、多くの企業で使用されているツールに興味のある方はぜひ導入を検討してみてください。