「要件定義」とは？
「要件定義」というのは、発注する人の要望や与件を明確にして、バランスをリソースと考えた上で、どのようなことを目的を達成するためにすべきかを文書化するものです。
顧客の要望を整理してまとめるのは、プロジェクトの大切なプロセスであり、建物でいえば基礎にあたるもので、建物をサポートする大切な部分になります。
要件定義では、次のようなことを行います。
全体のプロジェクトの方針を決める
まず、プロジェクトの目的や背景をチェックしてゴールを設けます。
そして、プロジェクトのスケジュールや体制、納品するものを決めます。
業務要件をチェックする
業務要件をチェックするときは、現在のサイトや業務を分析して、サイト化（システム化）する範囲を決めます。
サイト要件を決める
サイト要件を決めるときは、ページ構成やサイトマップを決めたり、ターゲットブラウザ・ユーザ・OSを決めたりします。
システム要件を決める
機能要件・非機能要件・技術要件・ユーザビリティ要件を決めます。
機能要件としてはどのような機能をサイトに持たせるかを明確にし、非機能要件としては品質やセキュリティ、運用保守やリリースなどについて明確にします。
また、技術要件としては、インフラ要件のドメインやサーバなどと、サイトを構築するための開発手法であるソフト・技術選定などを決めます。
ユーザビリティ要件としては、どの程度のレベルまでユーザビリティについて対応するかを決めます。
「要件定義書」の意味と使い方とは？
「要件定義書」というのは、顧客からの要求をシステム開発について受けた後、実際にシステムを作る前に最終的に提出される書類で、開発するシステム内容を記載しています。
そのため、メインに「要件定義書」を書くのはSE（システム開発者）になります。
「要件定義書」は、顧客からの要求を受けたシステム開発のプランをSEがまとめて、わかりやすく専門的な知識がない顧客に説明することが目的です。
「要件定義書」の内容としては、システム開発についての顧客からの要求に即して顧客とSEが相談して、最終的に了解したものになります。
専門的な知識を顧客が持っていないときは、SEが機能などをプラスするときもあります。
要件定義書をまとめるときには、どのような項目でも細かく顧客と協議することが大切です。
これによって、システム開発が終了してから「考えていたものとは違う」などというような顧客からの不満が出るのを防止することができます。
そのため、「要件定義書」は、顧客からの要求以外に、専門的なSEによる経験や知識も活かした内容になります。
開発するエンジニアが「要件定義書」は書くことが多い
「要件定義書」を書くのは、開発するシステムエンジニアです。
従来は顧客が作っていましたが、最近はシステムエンジニアが作るようになってきています。
一方、「要件定義書」は、ITがよくわかっている人が読むとは必ずしも限りません。
あまりにIT用語の難しいものを使用したり、開発する人だけがわかるような書き方をしたりすれば、読む人はよくわからなくて考えてもいなかったようなトラブルが発生することもあり得ます。
「要件定義書」は大切なものですが、工夫して書く必要があります。
「要件定義書」は顧客と開発者の了解が必要である
顧客と開発者が了解した内容をまとめたものが「要件定義書」であるということを、案外と見落としがちです。
顧客からの要求を聞いたものだけをまとめたり、開発の進め方やスケジュールだけをまとめたりした文書は、「要件定義書」とはいえません。
開発の目的や進め方、開発の具体的な方法など、内容の全てにおいて顧客と開発者が了解していることが条件になります。
ヒアリングや書き方も大事ですが、顧客と開発者が了解した内容を「要件定義書」には書きましょう。
「要件定義書」で定義する必要があるもの
「要件定義」は、一般的に「要件定義書」にまとめます。
エビデンスとして残しておくために文書化しておかなければ、トラブルに先々なることがあるためです。
「要件定義書」をベースにして、ウエブやシステムを設計するため、「要件定義」の段階において顧客や関係する人、開発者と了解をもらっておく必要があります。
受託するサイドは、顧客の要求についてはっきりとできないことはできないといっておくことが必要です。
案件を受注したために、無理な注文を受けてトラブルになったことは結構多くあります。
ここでは、「要件定義書」で定義しておくべき内容についてご紹介します。
機能要件
機能要件というのは、必ず機能として実装すべきものです。
機能要件はこれができないと顧客が困るというような要求と直結しやすいため、割合容易に決まるでしょう。
システム化のポイントになる部分が、機能要件です。
納品するためには、機能要件を実装する必要があります。
機能要件は最低限のできて当然というようなラインであるため、明確に機能要件をすることによって全体のプロジェクトのスケジュールがほとんど決まります。
非機能要件
非機能要件というのは、実装される機能を除いた要件の部分です。
非機能要件は、保守性やセキュリティ、可用性というような項目であり、性能面ともいえます。
機能要件は顧客が要求するものであるため、満足度は実装できてもそれほど獲得できません。
むしろ使っていくうちに満足できないことが生じてくるかもしれません。
例えば、顧客の要求をクリヤーしたシステムを作っても、画面の表示が使っているときに遅かったり、タブレットやスマホと連動できなかったりすれば、顧客の満足度はだんだん低下してしまいます。
しかし、充実した非機能要件であれば、顧客の満足度がアップすることが期待できます。
便利な機能がある、サクサクと動く、充実したサポートがあるということが達成できると、長く顧客は使ってくれるでしょうし、新しく発注されることもあります。
非機能要件は、隠れた顧客の要求であり、システムをサポートする部分になります。
インフラ要件
インフラ要件というのは、DBやサーバ、ネットワーク、SSL証明書など、システムの環境をサポートする部分です。
性能が高いものは費用がその分かかるため、顧客の要求を考慮してメリットとデメリットを説明しながら決めていきます。
サイト要件
サイト要件というのは、ウエブサイトの要件定義です。
ウエブサイトの目的は、会社のスタッフが使用するのでなく、顧客にアクセスしてもらうことです。
そのため、使用する端末やターゲット層、OS、ブラウザ、SEO対策などを顧客からヒアリングして明確にする必要があります。
