要件定義工程の役割分担

　一つ前にエントリーで要件定義工程における発注者（ユーザ側）と受託者（システム開発会社側）の役割分担の話を書いたが、もう少し深掘りしてみる。
　要件定義工程とは、文字通りシステム化したい内容を決めて明確にする工程ではあるが、この要件にはいくつか種類がある。システム屋的視点で、業務要件とシステム要件に分け、システム要件はさらに機能要件あとは非機能要件に分けることが多い。

　このうちまず業務要件であるが、これはシステムにやらせたい仕事、あるいはシステムを使ってやりたい一連の仕事の全般の内容である。例を挙げると「受注伝票を入力し、そのデータを使って請求書を発行したい」などになる。要は今やっている仕事の内容やそれをどうしたいかを説明すればよく、特段専門用語を用いる必要もなく普通の日本語で書けば良い。
　但し、１文で占める仕事の範囲（＝業務の粒）が大きすぎるのはダメで、例えば「受注から請求・入金まで営業の仕事を全部システムで処理する」という業務用要件だと範囲が広すぎて曖昧な部分が多くなりすぎる。その場合は実際の仕事をやるときの手順などに沿っていくつかの仕事（＝業務）に分ける。
　この業務要件を開発会社側から提示しろという乱暴なことをいう顧客が時々いるが、はっきり言って無理である。永年業務システムをメンテナンスしてきたシステムエンジニアであってもユーザ側でそのシステムをどのように使って日々どのような仕事をやっているかを把握できていることはまずない。こういう要求するのは、たいていモンスター顧客なので、こいう発言を受けたらそっとPCを閉じて退出し逃げ出したい。

　提示された業務要件からシステム要件を導出（あるいは転換）するのがシステムエンジニア（あるいはシステムコンサルタント）の仕事だと思う。先の例であれば「請求書を発行する」だけでなく「請求書には受注日（あるいは出荷日）を印字する」「場合によっては請求日は空欄とできるようにする」「一つの受注でも請求書は複数に分割して出すことがある」などといった、より細かい要望や条件を顧客から上手に聞き出して、機能要件としての文章にすることが求められる。ちなみにこの機能要件までを、全て顧客側担当とするシステム会社も時々あるが、正直そんなことができる顧客はほとんどいないので、私としては聞き出した業務要件から類推されるものをシステムエンジニア側から提示して確認をするべきだと思うし、実際にそのほうが早いと思う。経験豊富なシステムエンジニアだと、このときにいろいろな場面や例外処理を提示できるので機能要件に漏れが少なくなる。特に要件定義の上手いシステムエンジニアは、この過程で出てくる細かいケースをすべて機能要件として拾うのではなく、この段階で適宜無視すべき例外処理や過去からの慣例で残っているすでに不要となっている機能要件などを分別してそぎ落とす。

　これとは別に、システム開発時に必要なシステム要件として非機能要件というものがある。システムの可用時間とかレスポンス性能条件とかが代表的な非機能要件になるが、非機能要件についても、顧客サイドに提示を求めるとと時間がかかる割には漏れが発生するだけなので、開発会社側から非機能要件の項目リストを提示して、その場で内容（値）を顧客に決めてもらう方法が手っ取り早い。非機能要件は対象業務やシステムの種類毎に異なる部分が少なく、業界団体から標準構成案なども公開されているからそれを流用すれば良い。

　これら業務要件、システム要件（機能要件、非機能要件）以外に要件定義工程で決定（同意）しておくべき重要な項目として、システム範囲の定義がある。人とシステムの境界、今回導入するシステムと他のシステムとの境界などはできるだけわかりやすく明確化しておくと後からのトラブルが減る。業務要件をシステム要件に転換する時に削ぎ落としたものは人とシステムの境界として別途明示した方が良いし、他のシステムとのデータ連携が発生するのならデータ整備はどちらの担当なのか、受け渡しはどちらが手動でやるのかなどはこの工程で決めておくべきだ。

　繰り返しになるが纏めると、要件定義工程のうち業務要件を出すのは発注者（顧客側）の担当で業務要件をシステム要件に変換して要件定義書に纏めるのが受託者（システム開発会社側）の役割であると私は考える。