ITシステム発注者から見たプロジェクトマネジメント

ITシステムをベンダーに発注するにあたって、要件定義は最も重要な作業になります。

プロジェクトで発注者と受注者の間で揉める原因としてよくあるのは、「利用者がシステムを使ってやりたいこと」と「ベンダーが構築するシステムで実現されること」に認識のずれがあるままでプロジェクトが進んでしまうことだと考えています。

このずれを少なくしていくためにも、業務要件とシステム要件の違いについて認識しておく必要があると考えてます。



ものすごくざっくり言うと
業務要件：やりたいこと
システム要件：システムで実現すること
なのですが、この両者の線引きがしばしば曖昧になってしまうことがあります。

例えば、「○○のデータを××の条件で検索できるようにする」というのは、「業務要件」「システム要件」のどちらでしょう？

一見簡単な話のように思えますが、意外に人によって意見が分かれてしまうところかなと思います。

私の考えでは、「システム要件」となります。
つまり、「How」にあたるものです。
それに対する「業務要件」は、「なぜ検索できる必要があるのか」を考えれば出てきます。
つまり、「Why」にあたるものです。

要は目的と手段がごっちゃにならないようにしないといけないのですが、しばしばごっちゃにされてしまいます。

大事な話なので、もう一つ例を挙げます。
「業務要件」と「システム要件」の線引きは、システムの機能だけの話に限りません。非機能部分でも線引きをしておく必要があります。
例えば「IDS（不正侵入検知システム）を導入すること」はもちろん「システム要件」ですが、
「不正アクセスされないように対策をとること」も「システム要件」です。
それに対する「業務要件」は「秘密情報が外部に漏れないこと」であったり、「データを改竄されないこと」であったりします。
確かに「IDS（不正侵入検知システム）を導入すること」に対する「Why」は
「不正アクセスされないように対策をとること」になるのですが、
だからと言ってそれが「業務要件」になるとは限らないところが難しいのです。

ポイントは、「システム化する／しないに関わらず」利用者がやりたいこと（やるべきこと）が「業務要件」で、それをシステム化する際に必要な機能や対策が「システム要件」ということです。

別の視点で言うと、「システム要件」は場合によってはシステム化しない（つまり「システム要件」から外す）ことや別の「システム要件」で該当する「業務要件」に対応することが可能な一方で、「業務要件」は基本的にはその業務をやめたり別の業務で代替するということがないものとなります。（もちろん、業務を改革をするといった話でそういう判断が出ることもありますが、ここでそこまで話を広げるとややこしくなるのでいったん置いておきます。）

いかがでしょうか。
まずは、この考え方を理解することが第一歩かと思います。

「次ページ（その２）」に続く。

---

こちらもあわせてお読みください。
要件定義に必要な体制