罰金もの？“要求”と”要件”の違いとは

以前シンガポールに長期出張していた頃のお話。

一時帰国する際にお土産を探していると、あるメッセージが書かれたマグネット（表側にデザインが施されていて、冷蔵庫にメモなんかを挟んで貼り付けるアレ）が目に付きました。

Singapore is a fine city.

うん、確かにシンガポールは緑も多く街も清潔で”fine（素敵な）”ところ。しかし、様々な禁止マークが描かれたデザインとなっており、こりゃなんだと訊いてみると「”fine”には罰金の意味もあって、2重の意味に読める言葉遊びだよ」とのこと。
なるほど、ごみのポイ捨てや路上喫煙はもちろん、ガムを噛んだり電車にドリアンを持ち込むことまで禁止されているこの国の規則の多さを皮肉っているのですね。

言葉の奥深さを感じながら幾つか買い求めたのでした（そして、意外？にも帰国後にコレが一番人気でした。なんだかんだ言ってベタなお土産が一番という事か・・・いや、私の選んだ他のお土産がそもそも微妙なものだらけという噂も）。

どうも、例によって前置きが長い弘中です。

今回は言葉の定義についてちょっとお話ししてみたいと思います。

Q”要求”と”要件”は何が違うの？

これまでシステム企画において“要求”を洗い出して整理しよう、みたいなことを何度も書いてますが、この言葉についてのご質問を時折いただきます。

「システム企画の後に要件定義工程で“要件”を決めますよね。要求とは何が違うのか？」と。

これ、ややこしいことに英語ではどちらも”Requirement（＝実現したいこと）”なんですよね。なので、それぞれの言葉をしっかり説明することで違いを明らかにしなければなりません。

私のいつもの回答としてはこんな感じです。

[要求]
「どのような業務とシステムを実現したいのか」を利用側で定義したもの。システム企画工程で定義。

[要件]
要求に基づき「どのような業務とシステムを実現するか」を、網羅性・実現可能性が確保された状態で具体的に定義し、利用側・開発側で合意したもの。要件定義工程で定義。

細かい部分は書いてある本や人によって少し異なりますが、概ね上記のような考え方で説明されていることが多いかと思います。

大きな違いは2点で、「網羅性・実現可能性」と、「合意」の部分ですよね。

まず、「網羅性・実現可能性」です。
これは要求では考慮しなくても良いという訳ではなく、「ある程度」確保しておき、それを要件で100%にする、という考え方です。
システム企画段階はまだ業務変革・システム導入を判断する前ですから、あまり時間もコストも掛けられません。したがって、実現したいことを大枠で捉えることになります。例えば、「商品に貼り付けられたラベルを読み取り、その場で個品単位に在庫の棚卸ができる」という要求をさらに細分化して「ラベルがはがれた時にどうする？」、「読み取りエラーとなった場合の訂正をどうする？」といったレアケースへの対応条件まで網羅し、その実現可能性まで確認しようとすると手間が掛かり過ぎるのです。
システム企画においては、要件定義以降の活動を進めた場合に予算オーバーしてしまわない粒度にて、実現したいことやその条件を把握すれば良い、ということになります。

これは、上記のような業務・システム機能に対しての要求だけではなく、品質やセキュリティ、インフラ、運用、移行などのいわゆる非機能面の要求においても同じです。
例えば、移行要求でどのデータを移行するのかまですべて洗い出す必要はありませんが、何年分のデータを移行するのか、移行後に問題が発生した際に現行システムにも切戻せるようにしておくのか、移行期間中にシステムサービスを停止可能なのか、といった条件はコストに大きく関わって来るので、通常は要求として決定しておくべきです。

例えるなら、クルマが欲しい時に「6人乗りのミニバン、カーナビ付きで燃費が良い国産車」と要求を決め、家族に相談して予算を確保してから、ディーラーで「チャイルドシートを付けますか？」、「重量があるので燃費はどうしても悪くなってしまいますが、XX km/Lで良いですか？」といった具体的な要件を決定して購入する、といったイメージでしょうか。

また、「合意」についてですが、システム企画では企画チームが利用する組織内で合意を取るのに対し、要件は開発側も含めてその網羅性・実現可能性を担保した状態で合意することとなります。
したがって、要件定義後に「要件定義として記載されていない条件」が現れた時や、「実現できない条件」が現れた時には、コスト面の調整も含め、改めて利用側・開発側で合意を取り直す必要が出てきます。

ディーラーと契約した後に「革巻きステアリングかと思っていたのに違っていたからオプションを追加して欲しい」という話になれば、当然金額も変わってきますよね。なので、要件では利用側は実現したいことを漏れなく伝達しないといけませんし、開発側は漏れが生じないように網羅性を意識して利用側に確認しなければなりません。

それでは今回のアンサー。

A要求は予算を見積もられる粒度で、要件で実現したい条件を具体化して100%決める

“fine”には「洗練された」という意味もありますよね。

要求で「大物」を見落としてしまうと、その後の要件定義で実現したいことにブレが生じてしまい予算オーバーとなります。
また、要件で網羅性や実現可能性を確保できていないと、やっぱり次工程以降で追加要件が発生したり、要件を変更せざるを得なくなってしまい、それが積み重さなって予算オーバーとなることも往々にして生じます。

「罰金」という訳ではありませんが、後で想定外のコストが生じないよう要求も要件もしっかりと洗練された状態で定義しておくことが大切ですよね。

それではまた次回！