要求なのか、要件なのか？
「要件を詰めましょう」「要件定義をしましょう」「要求管理どうしてる？」といったようにソフトウェア開発の現場では要件や要求が飛び交います。
現場では関係者間での共通認識を持つことが非常に大切ですが、それでも要求なんだか要件なんだかわからないことや、これらの言葉を混同していてそれによって後々のコミュニケーションや問題に発展することも少なくありません。
まずは、用語の共通認識が大切だということです。これだけを気を付けるだけでも多くの「言った、言わない」や「文脈を読んでくれよ」問題は快方に向かうのではないでしょうか。
用語を整理する
私はこの要件なのか、要求なのかの問題に直面した際には、英語に置き換えてもらうように働きかけます。
「今の『要求』とは英語だとなんですか？」「今の『要件』とは英語だとなんですか？」という具合にです。すると、多くの場合で、「要求」も「要件」もどちらも「Requirement」であることが多いです。
ここで、どの言葉が正しいかを議論したいわけではなく、もし同じことをそれぞれ異なる言葉（用語）で使っていたらどうなるのかを考えたいわけです。
RUP の場合
例えば、Rational Unified Process (RUP) では、用語の定義も徹底されています。私たちが現場で要求とか要件とかと表現しているものは RUP では、以下のように明示されています。
- ニーズ (Needs):
利害関係者が望むもの。システムやソフトウェアに依存しないもの。
例えば、「〇〇業務のコストを20%削減したい」など。 - 基本要件 (Features):
システムが外部（ユーザーや他システム）に提供するサービスなど。
例えば、「この〇〇システムにより、〇〇の担当者は、△△ができ、□□を確認できる。これは今までより作業工程を短縮できている」など。
必ず一つ以上の「ニーズ」に寄与している。 - ソフトウェア要求 (Software Requirements)
ソフトウェアとして実装し検証できるまでに落とし込んだもの。
機能要求や非機能要求がある。FURPS+ で表現できる。
FURPS+ は、Functionality (機能), Usability (使いやすさ), Reliability (信頼性), Performance (性能), Supportability (保守性) と制約を表す。
必ず、一つ以上の「基本要件」に寄与している。
とりあえず混ぜたくないもの
とりあえず現場で混乱しないようにするために混ぜたくないものは上記のようなものではなく、おそらくもっと単純なものです。
それは、やると決まったことなのかやると決まっているわけではないことなのかです。これが混ざっているのがとても危険です。
よくあるケースが、やると決まっていないことを「要求」、やると決まったことを「要件」とすることです。これでもいいので、現場で共有認識をもってみましょう。
それでも前述のように英語で表現してみると。。。のくだりだと、この表現ではどちらも「Requirment」になりがちです。そこで決まっていないことを Needs、決まったことを Requirement ととすることが多いです。
個人的にもおすすめなのは、決まっていないことは Request とすることです。日本語にすると「依頼」です。変更管理で欠かせない「変更要求」という表現があります。これは元々英語の Change Request を日本語に訳した際に定訳として定着してしまったものです。私はこのエリアで20年以上従事しており、「変更依頼」を貫いている立場ですが、それは「要求」と「変更要求」が混ざりあうことを避けたい思いからです。
まとめ
決まっていることと決まっていないことは用語をわけましょう。決まったことも分類やステージ、階層化できるならやってみましょう。すべては現場が混乱しないために。