今回はシステムの要件定義において、ある要件を実現することが正しいかどうかとはどうやって決まるかについて考えてみたいと思います。
私は、その要件のコストパフォーマンスがプラスである場合にのみその要件を実装することが正しいと考えます。つまり、要件から生じる顧客の利益がそれを実現するのにかかるコストよりも大きい場合にのみその要件を実現するべきであり、これを真の要件と定義します。
ところが、実際には真の要件ではないものが要件定義に紛れ込み、結果としてエコでないシステムが頻繁に構築されているように思われます。個々の要件について利益とコストを見積もることを怠ったためにそのようなことが起こるわけですが、要件の利益とコストを見積もることは難易度が高く、正確性を極めようとすると時間もかかるため、ある程度仕方がない面もあります。
また、利益とコストを比較するためにはそれぞれ金額に換算する必要があり、そう簡単にできることではありません。
しかし、難しいからと言ってやらなければ、暗いところでなくした鍵を明るいところで探すパターンになってしまいます。
要件がもたらす利益
要件を実現すると、顧客に利益がもたらされるわけですが、必ずしも目に見える効果がすぐに出るわけではありません。たとえば、システムで拡張性や可搬性が高いアーキテクチャを採用しても、システムに変更が行われるまでその性質のメリットを得ることはできません。また、可用性が高い、操作性が良い、スマホからでも使えるなどの性質もその要件の効果を金額換算するのが難しいでしょう。
重要なことはこれらの目に見えない利益も含めて評価することです。
要件の実現にかかるコスト
要件を実現するのにかかるコストについて、構築作業費のようなものであれば計算しやすいのですが、隠れたコストとなるものが多数あり、それに注意する必要があります。たとえば、セキュリティを強化する機能を導入したためにエンドユーザの負担が増えたという場合はには、その負担増加分を導入コストに算入すべきです。
要件の海
要件定義をITのコンサルタントにお願いすると、世の中で言われている様々な要件を列挙してくれます。バグはないほうがいい。実績があるほうがいい。先進的なアーキテクチャを採用している方がいい。脆弱性がないほうがいい。といった方針に基づいて抽象的で情報量の少ない要件が大量に提示されることになります。それぞれについて、顧客に必要であるか、ベンダが実装可能かの検討が必要ですが、もっとも重要なのは真の要件であるかどうかです。
これらの大量の要件を整理するためのベン図を書いてみました。

気をつけなければいけないのは、真の要件でない要件が出やすい要注意領域です。
顧客側では技術的な難易度が判定できない状態で様々な要件を入れてしまい、コストが思ったより高いものが入ってしまうことが起こりがちです。
ベンダ側ではセカンドシステム症候群とも呼ばれるもので、第二バージョンを開発するとなると、顧客側の利益がどのくらいあるかを考えずに、豊富な機能で勝負しようとしてしまう傾向があることです。
極端なケースでは、バグ修正でさえお客様の利益にならず、新の要件とは言えない場合もあります。
特に日本のIT企業は非機能要件に必要以上にお金をかけたシステムを作りがちなので、真の要件だけを実装してエコなシステムを構築するよう心がける必要があります。
また、ベンダ側と顧客側の両方で必要であると思った要件でも、真の要件でないものもあります。バズワードや流行にのっていれてみても実際の利益がそれほど大きくない場合(ex. RPA)やセキュリティ要件のように誰も否定できず裸の王様の服のようにみんなから肯定されて入ってしまうものなどがあります。まあ、このようなものは前述の要注意領域にくらべれば問題は少ないと思います。
まとめ
プロキューブはソフトウェア製品ベンダですので、セカンドシステム症候群で自己満足で勝手に要件を追加しないように気をつけております。特にセキュリティや可用性などの非機能要件についてコスト対効果を無視して開発費をつぎ込むことは、最終的に製品の競争力を下げるだけでなくお客様のお金を無駄遣いする意味があり、 lose-lose となるため、避ける必要があると考えております。