プロジェクト成功のカギを握る「要求定義と要件定義」

システム導入によって「何をしたいか」を明確にするのが要求定義です。システム開発工程におけるシステム化構想にあたります。
「便利になればいいな」と、システム開発を企画しても、システムが満たすべき目的、目標、機能を明確に定義しなくては、よいシステムはできません。
例えば、単に「パスタが食べたい」ではなく、味はミートソースなのかナポリタンなのか和風なのか、具材は何で、量は？などが分からないと料理ができないからです。
システムに関する事故やトラブルの多くは、このニーズを明確にしないまま進行したのが原因です。

業務の効率化を求めるなら、自組織の現状業務を知らずに、ＩＴを活用した業務の効率化はできません。業務フローを作成し、業務の可視化が必要です。
可視化から、業務プロセス上のボトルネック（ムリ、ムダ、ムラなど）、重複する手順、合理性の乏しい業務負担、業務のやり方やプロセスを考えるためのヒントを得られます。

要求定義では、やりたいことは明確になっているものの、まだシステム内容は決まっていない状態です。次の要件定義でこの実現方法を検討します。
要求者の望む内容が、開発者側の技術的な観点やコスト的な観点から実現が難しいケースもあります。その場合は、システム開発の目的・ゴールに立ち返り、譲れるもの、譲れないものの優先順位をつけていくことが重要です。

併せて、実現したい機能だけでなく、ユーザビリティ、性能、拡張性、セキュリティなど、システムにとって不可欠な「質」の部分も決める必要があります。
この作業は、発注側と開発側による共同作業でないとうまく進みません。一般的に、発注側はシステムに関する専門知識がなく、システム会社のサポートを受ける必要があるためです。
しかし、あくまで要件定義の最終責任者は発注側です。

要件定義では「便利にしたい」を数値で表現する必要があります。発注側と開発側で解釈のギャップが生まれるからです。
また、重要な意思決定ポイントについては、必ずステークホルダーの明確な合意・承認を得ておきましょう。後になって、大きな手戻りが発生し、納期遅れ、コストアップにつながることがあります。
特に、上流工程から計画に基づいて各工程を経る「ウォーターフォール型開発」では、流れた水が元に戻らないのと同じように、基本的に前工程に戻れません。

システム開発プロジェクトが成功するか、失敗するかは、要件定義にかかっているといっても過言ではありません。
各ステークスホルダーが同意し、明文化された要件定義書は、システム開発の指針となるものです。

要求定義と要件定義を自社内で実施できると、中堅・成長企業にとって大きな武器となります。具体的には、システム会社のリソースをうまく利用でき、開発期間の短縮、コスト削減につなげられます。
要求定義と要件定義は、自社のＤＸ実現を効率的に進めるカギとなるのです。