「要件定義」と「要求定義」は混同されることも多い工程ですが、厳密には異なる目的・作業内容の工程です。

要求定義とは、システム開発において、クライアントの希望を確認する工程です。

クライアントの希望、つまり「システム開発に求めるもの」をまとめる作業を指し、要求定義は要件定義の前工程として実施されます。


対して、要件定義は要求定義の内容を受けて、システム要件として落とし込む工程のことです。

予算や納期の関係で、全ての要求を叶えることはできないため、要求を整理して、本当に必要なもののみに絞り込みます。


要件定義がシステム部門（エンジニア）の作業範囲なのに対し、要求定義は、ユーザー企業・部門の役割となります。

とはいえ、ユーザー企業・部門は潜在的な要求を抱えていることが多く、しっかりとしたヒアリングを行い、ユーザー企業・部門の意図を汲み取る必要があります。


要求定義の段階でユーザーの希望を正しく把握できていないと、大きなトラブルや工程の遅延につながる可能性があるので、慎重に行いましょう。

要件定義を決定するために、最初に行われるのがヒアリングです。

開発側がクライアントの潜在的な要求を掘り起こすことを目的として行います。

すでに要求定義が行われている場合は、さらに開発者側の視点を交えてヒアリングを行いましょう。


ヒアリングを行うには、クライアントの要望を聞き出し、意図を正確に把握するためのコミュニケーションスキルが必要になります。

すべてがクライアントの要望通りに進められるわけではないので、実現可能か判断できるスキルも必要です。

不可能な要求はしっかり断ることができるよう、開発に関係する知識も求められます。


この段階で、内容のすり合わせをしっかりと行い仕様について合意しておくことで、仕様変更が頻発したり、手戻りによるコスト超過やスケジュール遅延を防ぐことができるため、ヒアリングは非常に重要です。

ヒアリングで掘り起こした要求を細分化し、必要な機能を洗い出す作業を行い、システム化すべき要件を検討しましょう。

現状の問題点、課題などを掘り下げ、解決策を検討します。

すべての要求をシステム化できるわけではないので、開発側とクライアントの認識に齟齬がでないようにしましょう。


また、要求内容をもとにした機能要件だけではなく、性能やセキュリティなどの非機能要件の検討も忘れずに実施しましょう。

クライアントの関心は機能要件へ向きがちですが、非機能要件にも目を向け、意識的に検討することで、システムの満足度向上へもつながります。

要求定義の内容を明文化し、「要件定義書」として正しく落とし込むことも重要です。

「要件定義書」とは要件定義の内容をドキュメントとしてまとめたものです。

システム開発の要件定義書を作成しておくことで、開発メンバーと要件の共有をしやすくなり、プロジェクトをスムーズに進めることができます。


そして、システム要件をベースにどれくらいの工期や工数が必要になるのかを見積もりましょう。

プロジェクト発足時に想定していたスケジュールや予算をオーバーしてしまうこともあります。

重要度や緊急度などで優先順位をつけながら対応範囲、スケジュール、予算などを定め、実行計画を立てていきます。

機能要件とは、「必ず実装すべき機能」のことで、システム化の要となる部分です。

機能要件はユーザーが「これができなくては困る」という直接的な希望と直結しやすいので、比較的簡単に決まると思います。


機能要件は「出来て当たり前」の最低限のラインなので、機能要件を明確にすることでプロジェクト全体のスケジュールが大体決まります。

機能要件とは、「必ず実装すべき機能」のことで、システム化の要となる部分です。

機能要件はユーザーが「これができなくては困る」という直接的な希望と直結しやすいので、比較的簡単に決まると思います。


機能要件は「出来て当たり前」の最低限のラインなので、機能要件を明確にすることでプロジェクト全体のスケジュールが大体決まります。

<h3>非機能要件</h3>
非機能要件は、実装される要件のうち機能以外の部分のことを指します。

保守性やセキュリティ、可用性といった項目が非機能要件です。


機能要件はユーザーが求めるものですから要求を満たすものであれば、ユーザーの評価を得ることはできるでしょう。

しかし、利用していくうちに不満な点が出てくるかもしれません。

例えば、ユーザーの要望を満たしたシステムを開発しても、使っていて画面表示が遅かったりスマホやタブレットとの連動ができなかったりすると、徐々にユーザーの満足度は下がってしまいます。


非機能要件は、一見ユーザーからは認識されづらく、直接評価に結びつかないように思われがちです。

ですが、非機能要件が充実していればユーザーの満足度のアップが期待できます。

サクサク動作する、便利な機能がある、サポートが充実しているということが実現できればユーザーは長く利用してくれるでしょうし、新たな発注につながる可能性もあります。


非機能要件は、ユーザーの隠れた要望であり、システムを支える質の部分と言えるのです。

サイト要件はWebサイトの要件定義です。

Webサイトは企業のスタッフが使うのではなく、ユーザーにアクセスしてもらうのが目的です。

そのためにターゲット層や利用端末、ブラウザ、OS、SEO対策などをユーザーからヒアリングして明確にしていく必要があります。

インフラ要件は、サーバやDB、SSL証明書、ネットワークなど、システムの環境を支える部分を指します。

高性能のものはそれだけコストがかかりますので、ユーザーの要望を踏まえてメリット・デメリットを伝えながら決定していきます。

セキュリティ要件とは、システムを安全に運用するために、開発を始める際に設定するセキュリティに関する目標のことを指します。

機密情報を扱うことになりますから、情報漏洩やウイルス感染などの被害を避けるためにも、セキュリティ要件は重要な項目のひとつです。


想定される攻撃手法に対してどのように防御するのか、さまざまなパターンに対応できるシステムを構築するために欠かせない項目です。

要件定義で一番最初に行う業務要件のヒアリングは、最も重要な工程のひとつです。

5W2Hを意識することで、曖昧さがなくなり、ヒアリング精度が格段に向上します。

ヒアリングにおける5W2Hは下記のとおりです。

　1.Why：なぜシステム化を行いたいのか、背景は？

　2.What：課題、改善したいポイントは何か、何を実現したいのか

　3.Where：要求を満たすための開発範囲

　4.Who：システムの利用者は誰なのか、運用者は誰なのか

　5.When：いつまでに開発が必要なのか

　6.How：どのように要求・要件を実現するのか

　7.How much：システムの実装に対し、いくらの予算を組むのか


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

システム開発の目的が現在の業務を改善したいという場合は特に、現行システムの確認が欠かせません。

稼働中のシステムに影響が出ないよう、入念な仕様調査を実施しましょう。

現行のシステムの足りない点や改善点などをはっきりさせておくことで、より良いシステム開発を行うことができます。


また、全く新しいシステムを作る場合であっても、現行の業務フローやシステムの確認は必須です。

ユーザーの理想とするシステム像の検討が先行してしまうと、必要な業務プロセスや機能に漏れや無駄が生じてしまうことがあります。

ユーザーの要求のみにとらわれず、全体を俯瞰して見るようにしましょう。

一般的なプロジェクトでは要件定義を少人数のチームでこなし、設計工程からメンバーを増やすことが多いです。

要件定義を担当した会社とは別の会社が設計を担当するプロジェクトもあります。


作成した要件定義書を共有するだけではなく、関係者を集めて読み合わせを実施することで、最終的なすり合わせを行います。

その際、ただ、項目を読み上げるだけではなく、記載されていない背景や仕様検討の経緯なども合わせて説明することで、担当者間の業務知識、理解の溝を埋めることができます。


システムを導入した後に業務フローがどのように変わるのか説明することも大切です。

大きな変更などがある場合は、フローチャートなどを用意しておくとイメージしやすくなるでしょう。

読み合わせを実施することで、要件定義書のなかの不備を見つけることもできますので、ぜひ実施するようにしてください。

プロジェクトをどのように進めて行くのかロードマップを明確にし、開発チーム全員で共有しましょう。

スケジュール管理や、運用開始後の体制に関する計画も大切になります。


また、要件定義で失敗しないためには、プロジェクトの管理も欠かせません。

すべての工程にスケジュールを立て、業務に遅れや漏れが生じないようにしなくてはいけません。

プロジェクト管理を行っておくことで、工程で遅れやトラブルが生じたときにもすぐに対応できます。

プロジェクトの管理には、タスク・プロジェクト管理ツールを使用すると便利です。