では、なぜシステムを開発するのでしょう？
いろいろな理由が考えられます。
1． 古いシステムを最新のシステムにリプレイスする必要が生じた。
2． 新規ビジネスを立ち上げることになり、新しいシステムが必要になった。
3． 子会社を吸収することになり、システムの統合が必要になった。
4． 古い業務プロセスを刷新するために、現行システムの再構築が必要になった。 など・・・
現代の情報社会では規模の大小を問わず、いろいろな理由でシステム開発は必要になります。
システムを開発するために①必要な＝要、②こと＝件、を③定める＝定義、になります。
まとめて言い換えると「システム開発に必要なことを定めること」が要件定義です。
要件と似た言葉で「要求」とか「システム要求」というのも出てきます。要件と要求とではどこが違うのでしょうか？住宅を建てる場合で考えてみましょう。
まず、建て主が「４LDKの洋風の家が欲しい。」と大雑把な「要求」を出します。しかし、これでは家は建ちません、設計が必要になります。建て主は設計屋さんに設計を依頼しますが、設計では
①平屋か、２階建てか、②各部屋の広さはそれぞれどのくらいか、③洋風とはどういうしつらえか、
などに始まり、細かくなると①天井の高さは、②廊下の幅は、③窓の大きさは・・・など決めなくてはなりません。この設計に必要な事項が「要件」になります。
家であれば、例えば、日本人の住宅であれば日本の建築会社や設計事務所であれば一定の標準的な基準を持っていますから、その標準を基にして建て主の要望を聞きながら細かい設計もやってくれます。しかし、システム開発となるとそうは行きません。システム開発では依頼主の「要求」や「要件」に標準的なものは少なく、依頼主ごとに欲しいシステムが大きく異なるからです。
住宅に建売住宅があるように、システムにも標準的な「要求」や「要件」に従って構築された、ERP（Enterprise Resources Planning）に代表されるパッケージソフトと呼ばれるシステムもあります。
しかし、建売住宅と同じように建て主の個別の「要求」や「要件」はストレートには反映されません。
さて、では何故システムを開発するのでしょうか？
それは、当たり前のことですが、「仕事」をするためです。
「仕事」のやり方は、その企業や団体によって千差万別ですし、システムが必要となった状況も千差万別です。従って、そこで使われるシステムも千差万別と言うことになります。勿論、上で述べたようにお仕着せのERPで出来る仕事もありますが、ここでは一般論としてお仕着せシステムは横において話を進めます。
では、要件定義は誰の仕事でしょうか？
これまで、そして今でも「システム開発」はITベンダーの仕事だと日本では広く考えられており、その一部である「要件定義」もITベンダーの仕事だとこれまた広く考えられています。
事実、要件定義に関する書籍やインターネット上の情報はITベンダーのＳＥ（システムエンジニア）を対象に書かれているものが大半で、システム・ユーザー向けに書かれているものは殆ど目にしたことがありません。
しかし、ここで私が申し上げたいのです。「要件定義」の７０％の部分はユーザーが書くべきだと思っています。ユーザーこそが「要件定義」について学ぶ必要があります。しかし、いろいろ反論が聞こえてきます。「現場は忙しい。そっちでやってくれ。」とか「そんなこと言われたって、システムのことなんか分からないし、要件定義の書き方も分からないよ」とか「そもそも、そんなのはユーザーの仕事じゃないよ。」とかです。
私にも経験があります。システム企画をやっていた時に、ある部長に「情報システムの要望が出されているので、検討チームの組成に力を貸して戴きたい。」とお願いしたら正に「我々は業務で忙しいんだ。そっちでさっさと作ってくれ。」との返答で、さすがに参りました。（因みに、この情報システムはその後何年も放置されました。無くても何とかなったようです。（苦笑））
順番に検討してみましょう・・・
1． 「現場は忙しい。そっちでやってくれ。」
これは簡単に理解してもらえると思います。住宅を建てる時に、「仕事が忙しいから、そっちで建ててくれ。」と言う施主はいるでしょうか？逆に「ああしたい、こうしたい」がたくさん出てくると思います。「ああしたい、こうしたい」をまとめるのが「要件定義」です。
2． 「システムのことなんか分からないし、要件定義の書き方も分からないよ」
これは考え方を改めて戴く必要があります。要件定義の（私の印象では）２／３がシステムの知識は必要ありません。必要なのは「業務知識」とどのように業務を進めたいのか・・・と言う業務設計の能力です。要件定義の書き方は順を追ってご説明して行きますのでご安心を。
3． 「そもそも、そんなのはユーザーの仕事じゃないよ。」
これも２．と同じです。要件定義に必要なのは業務知識と業務設計能力で、ITベンダーはそもそも持っていないものです。毎日「仕事」をして業務が分かっている人こそが適任です。しかし、
ご心配はもっともで、プロジェクトチームの編成など経営者・管理者の判断でどのように検討体力をひねり出すか？が重要なカギとなります。
アメリカでは「ビジネスアナリスト」をいう業務が今では認められています。日本語に訳すと
「業務分析担当者」でしょうか。下記の表のようにいろいろなバックグランドの人たちがそれぞれのバックグランドを生かしつつ業務分析とシステム構築に専業として任ぜられています。
「当社にはこんな人材はいない。」「私には無理。」とか聞こえて来そうですが、私の経験ではどこの
組織にも「何かと頼りになるひと」とか「何かと重宝なひと」がいました。例えば、日本版Sox法
対応で内部統制3点セットを策定したり、ISO認証取得のための業務フローを書いたりしてくれた
人材です。そんな人材が「要件定義」でも活躍するはずです。
このブログを読んでくださっているのは、経営者や役員のかたでしょうか？それともＩＴ部門の方でしょうか？それとも業務の担当者の方でしょうか？
次のシステム開発の時には、ぜひ、ユーザー主導の要件定義に取り組んで戴きたいと思います。