システム（ソフトウェア）開発で不可欠となる「要件」。英語だと「requirement」と表します。
まず「requirement」を明確にすることはシステム開発成功への第一歩と言えます。
日本語だと、人が要望するものを「要求」、システムに対して要望するもの（またはシステムを意識して要望するもの）を「要件」と呼び、分けて使うことが多いイメージですが、英語では「要求」と「要件」はどちらも「requirement」で表し、２つを明確に分ける表現はなさそうです。
「requirement」を使って色々な要件を表現しよう
business requirement
「業務要件」を意味します。基本的に業務側（ビジネス側）からみた要件ということで、対象となる業務プロセスやフローを明確化したものを指します。
| We need to define business requirements by the end of this month. 我々は今月末までに業務要件を定義する必要がある |
上記のように、「define requirement」で「要件を定義する」という意味になります。
system requirement
「システム要件」ということで、システム観点で実現すべき機能や性能のことです。
| The engineer has developed the new software based on the system requirements. エンジニアはシステム要件に基づいて新たなソフトウェアを開発した。 |
requirement definition
「要件定義」という意味です。これにより、業務要件やシステム要件が確定されることになります。
なお、要件定義の前段で行う「要件収集」は「requirements gathering」と表現できます。
requirement analysis
「要件分析」「要求分析」という英語表現です。
business requirement definition (business requirement document)
「業務要件定義」（業務要件定義書）のことです。BRDとも略します。
system requirement definition (system requirement document)
「システム要件定義書」のことです。SRDとも略して書くこともあります。
「英語の勉強には興味があるけど、続ける自信がない…」「自分のレベルや業務に合った英語の学習方法が分からない」＊＊＊＊＊以前から気になっていた英語学習アプリ「スタディサプリ」。1日３分から学べると評判で、特にコロナ禍では授[…]
「requirement definition」はシステム開発成功にきわめて重要
システム開発プロジェクトでは、この要件定義が成否を分ける大きなカギになります。
例えば見積り工数がブレる、成果物の品質が低い、仕様変更が頻発する、といった問題も元をたどれば要件定義の問題に起因することが驚くほど多いものです。
考えてみれば、何を実現すべきなのか曖昧なままで、QCDをきちんと満たすものが開発できるはずがありません。また、大きなプロジェクトになるほど途中で要件が変更となる（変更せざるを得ない）ケースもよく発生しますので、適切に要件定義書を更新するといったことも必要となります。
業務担当者とIT担当者のいずれかが要件定義に慣れていない場合、失敗のリスクがかなり高くなりますし、さらに、双方とも慣れていない場合は、私の経験上、ほぼ100％の確率で何らかの問題が起こると言えるほどです。
業務担当者、IT担当者とも要件定義を専門としている人は多くありませんし、また異動により要件定義に慣れていない人が参画してくるケースは常に発生するので、やむを得ない側面もあります。
そんな問題を解決する存在となり得るのがbusiness analyst（ビジネスアナリスト）です。
business analystは「要件定義に慣れていない人を相手にすること」に慣れていて、必要な情報を適切に引き出してきちんとドキュメントにまとめるスキルを有していると期待されます。
もしあなたの会社でまだこのような専任ポジションがない場合は、新設を検討・提案してみる価値があるでしょう。
