要件定義について - Hot Heart, Cool Mind.

　情報システムの構築にあたっては要件定義が大事だということは誰でも知っているが、じゃあ今から決めようとしている「要件」って何ですかと問われると、答につまってしまうことがある。「要件」というひとつのことばに色々な意味が込められて使われているからだ。
　特に重要なのは「業務要件」と「システム要件」の区別だ。この二つの区別はプロジェクト運営上の責任と結び付けられることが多いので、区別の仕方によっては大きな混乱や行き違いが生じることもある。「ユーザ側」が業務要件を定義し、「システム側」がシステム要件定義を担当するといった役割分担を行う場合、この二つの要件の区別がそのまま両者の責任の境界になるためである。

　さて、ではこの二つの間でどう線引きすればよいだろう。
　ありがちなのは、ユーザから提示された要件を「業務要件」、開発側があげた要件を「システム要件」とする分け方だ。しかしここでは、まずは「ユーザ側」「システム側」といった責任分担の視点をいったん脇に置いて、要件の性格の違いに着目したい。以下のような分け方だ。

「業務要件」 … 人間が行うかEDP処理とするかは別にして、対象業務がなすべきことの定義。
「システム要件」… 「業務要件」をみたすために、EDP処理が行うべきことの定義。

　業務要件とは人間とEDPをあわせた複合システムに対する要件であり、システム要件は、そのサブシステムであるEDPに対する要件であると理解するわけである。プロジェクトの進め方の面からはこちらの分け方の方が重要だと思う。
　見積業務を例にとると、これは見積依頼を受けて見積書を作る業務だから、業務要件には以下のような項目が含まれる。

業務のインプット … 見積依頼を受け付ける際にお客様から入手する情報の定義。
業務のアウトプット … 見積書に盛り込まれる情報の定義。
業務上のルール … 価格や見積有効期限の決定ルール、見積書提出前の承認ルール。
業務の頻度や、要求される処理量 … 一日に何通の見積書を作成できなければならないかなど。

　上記の「業務要件」を満たす業務のあり方は色々考えられる。すべて人手で行うこともできるし、価格表などの資料は紙で用意しておいてワープロで見積書を作成する方法もある。もちろん、見積作成システムを構築する方法もある。このように色々な案がある中から、要件をみたし、技術的にも可能で、コストのかからない方法を選択、設計していく。その結果、人間とEDPの役割分担が決まり、同時に、人間系の仕事の進め方すなわち業務プロセスと、EDP処理の内容すなわち「システム要件」が決まるのだ。業務プロセスとシステム要件について整理すると、以下のようになる。

いずれも、業務要件を満たすための手段を記述するものである。
両者は相互依存している。すなわちどちらかがもう一方に先行して決まるものではない。
両者を切り分ける上では、業務要件を満たすことだけではなく、技術・コストといった要素も重要である。

　であるから、業務プロセスとシステム要件を決める上では、対象業務領域に対する深い理解と、要件を実装するための手段（そのひとつが情報技術である）に関する深い理解を結合することが必要なのだ。どちらが欠けてもうまく行かない。

　と、このように書くと「当たり前だ」と思われるに違いない。自分でも書いていてそう思った。しかし、現実のプロジェクトではこれがうまく出来ていないことがなぜか多いのだ（私が関係してきたプロジェクトだけではないことを祈りたい）。主な原因が三つあるように思う。

　ひとつめは、「業務要件」に「業務プロセス」も含めて理解していることである。そのために、業務要件を定義する際に業務プロセスも決めてしまう。業務プロセスが決まれば、必然的に（かつ暗黙のうちに）システム要件も決められてしまうことになる。私は、自分の経験や伝聞といった乏しい根拠に基づく見解であるが、このケースが実はかなりあるのではないかと疑っている。業務要件定義とシステム要件定義の分け方という、「入り口」で間違っているのだ。苦労するのは当然である。
　ふたつめは、「業務要件」を定義することの難しさに起因する問題である。業務要件を定義するには、現行の業務プロセスが本来何のためにあるのか、何を達成すればその業務として十分と言えるのかを問いつくさなければならない。それに比べて、業務プロセスについては、現行業務のここをこう直すと言えば、それでも新業務プロセスの定義にはなる。言い換えれば業務プロセスより業務要件の方が、一段、抽象度が高いのである。したがって、担当者やプロジェクトチームが、こうした抽象化の作業に慣れていないと、本来の業務要件定義を敬遠してしまうだろう。
　三つめは、役割分担に起因する問題である。業務要件定義「フェーズ」とシステム要件定義「フェーズ」に分けてプロジェクトを進めたとしよう。フェーズの切れ目が組織の切れ目になるのはよくあることだ。業務要件定義フェーズはユーザ部門が中心、システム要件定義フェーズは情報システム部門が中心になるとするなら、ユーザが情報システム部門に引き渡す「業務要件定義文書」に具体的な業務プロセスまで盛り込みたくなるのは自然だ。フェーズごとに協力会社が替わるなら、契約上の責任の問題がからみ、これに輪をかけることになる。
　いずれにしても、情報システムでは何が簡単で何が難しいか十分な検討なくしてシステム要件が決められる結果になる。そのため開発が難しくコスト高なシステムになるリスクが高まる。

　こうした問題に対処するには、フェーズ分割と契約の面、人と組織の面の両面からの対策が必要だろう。まずフェーズ分割と契約の面では、上記で問題視したような役割分担を抑制することに意を用いるべきだろう。要件定義を「業務」と「システム」に分けるのは上策とは言えないと私は思う。ベンダーとの契約にも注意が必要だ。
　人と組織の問題はもっと難しい。まず、プロジェクトチームが「業務要件定義」に不慣れな場合、その補強策が必要だ。外部コンサルタントの活用も考慮する価値がある。
　枠組みをいくらととのえても、業務サイドのメンバーと情報システムサイドのメンバーが密接に協働作業できなければ、やはりいつの間にか上述したような役割分担に戻ってしまう。人間、誰でも、自分の得意分野に留まっているほうが楽だからだ。しかし逆に、両者がお互いに尊重し、相手の得意分野に対しても「健全な素人」としての意見をお互いに言えるような関係を築くことができれば、素晴らしいプロジェクトとなると思う。これはメンバーひとりひとりのテーマであるとともに、プロジェクトリーダおよび関係部門の長の手腕の見せ所だろう。

　とはいえ、そもそも「要件定義」とは何か、どういった論理構造を持っているのか、といった基本的なことがらについて共通な理解がなければ、さまざまな努力をしても焦点が定まらず、効率が悪いのではないか。ここで述べた要件の構造、すなわち業務要件・業務プロセス定義・システム要件の関係の話なども参考に、チームで「要件定義」のあり方について検討する機会を持つ、といったことも考慮に値するのではないか、と思う。

2005/6/19 加筆修正