要件定義とは？進め方や項目、コツ、必要なスキルを解説

システム開発の最初の工程である要件定義は、開発の基盤となるためとても重要です。
本記事では要件定義について基礎から解説していきます。

要件定義とは？

要件定義とは、クライアントからの要求をもとに実装する機能や性能を決めていく工程を指します。
実際にシステム開発を進めていく上での、開発の目的や内容、開発スケジュールや予算など、具体的に想定し、要件定義書として文書にすることで、計画通りに運びやすくなります。
つまり、要件定義はプロジェクトの成功を左右するカギといっても過言ではないのです。

要件定義はプロジェクト成功のカギ

繰り返しにはなりますが、要件定義のでき次第でプロジェクトの命運が分かれます。システム開発の大まかな流れは次のようになります。

①　要件定義
②　設計
③　実装
④　テスト

要件定義が十分でない場合、納期に間に合わない、開発のやり直しといった事態になりかねません。
これではコストや時間の無駄になってしまいますね。また、成果物がクライアントの求めるものになっていなければ元も子もありません。
このようなことにならないよう、十分な時間をかけて要件定義を詰める必要があります。

上流工程と下流工程

設計までが上流工程
システム開発における上流工程は要件定義から詳細設計までの工程を指します。これは、開発手法でも主流なウォーターフォール開発という「水が下に落ちていくように順に開発を進めていく開発手法」から来ています。そして、システムの設計までを上流、システムの構築からが下流です。
要件定義などの上流工程はシステム開発経験の長いベテランのエンジニアが担当するというのが一般的です。

要件定義と要求定義の違い

要求定義とは、クライアントからの「何がしたい」「こういう機能がほしい」といった要望内容を開発者側が聞き取り、整理する工程です。

それに対し、要件定義はクライアントの要求定義をもとに「クライアントの要望を実現させるにはどんなシステムが必要か」を考え、実装する機能や性能など、具体的に開発するシステムの仕様を決めていく工程です。言ってしまえば「要求定義をシステム化する」のが要求定義です。

このように、要求定義は要件定義の前工程だといえます。
クライアントの要望を整理してから要件定義をすることでクライアントが求めるシステムやそれによる事業結果（業務のシステム化や既存システムの改善、コストの削減、売り上げ向上など）との隔たりを少なくできるでしょう。

要件定義の進め方

① クライアントの要求をヒアリングする

クライアントとヒアリング担当者で話し合いを重ね、具体的かつ明確にヒアリングすることで認識に齟齬がないよう徹底的に洗い出していく作業です。営業部門が担当することが多いですが実際にシステム開発に携わるSE（システムエンジニア）が担当する場合もあります。

クライアント側は要望を開発者側に伝えられるようイメージを持っておくことが大切です。
開発者側は、クライアントの伝えたいことを汲み取れるように、また、クライアント自身がまだ気づいていない潜在的なニーズを掘り起こせるようにクライアントの声に耳を傾けましょう。

② 要求を細分化する

ヒアリングを通して要求をまとめた要求を細分化することでクライアントが抱える問題点をさまざまな角度から掘り下げ、解決策の模索を行います。

要求内容が実現可能なのか整理していきますが、予算や期間が限られていますよね。そこで、問題解決のために本当に必要な要求は何か、クライアントと話し合うことで要求に優先順位をつけていきます。
要件は大きく分けて、必ず実現したい「必須要件」とできれば実現したい「希望要件」の２つがあります。優先順位の高い順にクライアントの要求を取りこぼすことなくプロジェクトを進めていけるでしょう。

クライアント側は、細分化された要件に取りこぼしが無いか確認しましょう。ただし、要求したすべてが実現可能とは限らないことを留意しておいてください。
一方、開発者側はクライアントの要求に対する取りこぼしが無いよう配慮する必要があります。

③ 要件定義書の作成

クライアントからの要求や問題点、改善点をまとめたものは、最終的に要件定義書にまとめていきます。
クライアントにもこの資料を使って説明していくため、ITに関する知識のない人にもわかりやすいよう記入していく必要があります。
要件定義書をもとに「システム設計」を行っていくため、システムの全体像から、細部までをもれなく記入できていなければ問題が生じてしまうので注意が必要です。

要件定義書の記載項目

要件定義書に記載する主な項目を紹介します。

• 概要
  システムの概要やプロジェクトの全体的な概要を記載する項目です。
• システムの目的
  システムを導入する目的やその背景、範囲やシステムの導入によって得られるメリットについて記載する項目です。
• システム導入後の業務フロー
  システムの導入後、業務フローがどう変化するのかを記載する項目です。大きく体制が変わる場合に同項目があるとイメージしやすくなるでしょう。
• クライアントの要求
  ヒアリング時に要求のあったクライアントの要望を記載する項目です。。
• 機能要件
  開発者側で決めたシステムに取り入れる具体的な機能を記載します。プロジェクトの目標ともいえる項目です。
• 非機能要件
  機能要件以外の要件全般を記載する項目で、プロジェクトの出来を示す指標にもなります。
• セキュリティ要件
  情報漏洩やウイルス感染などのといった被害に遭わないよう、想定される攻撃手法やそれに対する防御法などを記載する項目です。

要件定義書は、システム開発の土台になるため、上記の項目は記入しましょう。

要件定義書は開発者側だけではなくクライアント側も目を通すため、ITの知識がない人でも内容を理解できるよう、専門用語は省いて記入します。また、全体像から細部まで矛盾がないよう作成しましょう。

良い要件定義書の条件

専門知識がない人でもわかる内容

良い要件定義書は、ITに関する知識を持たないクライアントでも理解しやすい内容になっています。
専門用語を極力使わずに、誰が読んでも理解できる文面になっているか、気を付けましょう。

問題の解決策が記載されている

良い要件定義書にはクライアントの抱える問題点と本質的な要求を捉え、それに対する解決策が記載されています。

要件定義のコツ

目的を明確にする
システム開発がなぜ必要なのか、システムを導入する「目的」を明確にすることで実装する機能などの優先順位も明瞭になってきます。

話し合う時間をとる
開発チーム間だけでなくクライアントとも話し合いの時間を十分にとり、認識の齟齬をなくすことが最重要です。クライアントの意図を汲み取り、意見交換するようにしましょう。

要件を細分化する
「5W2H（なぜ・いつ・いくらなどの質問項目）」に当てはめて答えることで要件を整理しましょう。
問題点を認識しやすくなるだけでなく、要件定義の不備がなくせます。

要件定義に必要なスキル

クライアントの意図を汲み取るコミュニケーションスキル

コミュニケーションスキル、特にクライアントの意図を汲み取り、本質的な要求を引き出すスキルは重要です。

ドキュメント作成スキル

要件をクライアントや開発メンバーにも共有する必要があるため、誰が読んでもわかりやすいドキュメントを作成する必要があります。また、開発時だけでなく、数年後でも”読める“ドキュメントでなければいけないので、表現方法やフォーマットを統一する必要があります。

実装可能なシステム設計を把握するスキル

クライアントからの要求内容を具体的にイメージするスキルが必要になります。それには、開発に関する知識やスキルも必要になるので下流工程の豊富な経験が役立ちます。
また、クライアントの意見を鵜吞みにするのではなく、システム化が可能か判断し、不可能な要求をされた場合は断ることも必要です。