川村渇真の「知性の泉」

ニーズ分析:システムの目的や機能を規定する重要作業


利用者のニーズから、システムの機能を規定する

 どんなシステムでも、それを構築するための目的を持っている。その目的に適合してなければ、どんなに信頼性の高いシステムであっても価値はない。つまり、目的に合ったシステムを作ることがもっとも重要だ。そのためには、システムの目的を的確に把握しなければならない。その作業こそ、ニーズ分析である(「要求仕様定義」とも表現する)。利用者が自分で設計するなら、ニーズ分析を行わなくてもよい。それができなくて、設計者と利用者が異なるため、ニーズ分析が必要となる。
 システムの目的といっても、短い文章で表現するような内容ではない。もっと細かな部分にまで突っ込み、できるだけ具体的な内容としてまとめ上げる。現在の作業ではどんな問題点があり、どんな点をどのように変更したら作業が改善できるのか、対象となる業務の観点から調べる作業が中心だ。それぞれの改善点を機能として規定することで、システムに求められている内容か明らかになる。洗い出された各機能は重要性に差があるので、効果の大きさや優先度なども明確にしなければならない。
 開発するシステムの中には、企業の戦略に大きく関係するものもある。その場合、要望や目的をトップマネジメントから聞かなければならない。システムの内容の決定権のある人に尋ねるのは、ニーズ分析で必須といえる。
 ニーズ分析の結果は、要求仕様書としてまとめる。その内容は、求められている機能であって、実現方法まで触れないのが基本だ。また、実現できないと分かっている項目も、あえて含める。ここで作成した要求仕様書をもとに、次の工程で、実現方法の概要を設計する。本当に実現できないかや、別な機能で代替できるかなどは、概要設計の工程で検討すべきである。そのためにも、各機能が必要な理由や背景を、詳しく調べて記述することが大切だ。

対象分野を分析して、必要な機能を導き出す

 ニーズ分析では、対象となる分野を幅広く調べる必要がある。まず最初は、その分野に含まれる作業とその目的を洗い出す。それで全体像が理解できたら、だんだんと細かな部分に手を伸ばす。その分野で扱う全データ項目を洗い出すのは別な工程なので、重要なデータ項目だけを選び、その特性などを調べる。
 どんな分野にでも、例外的な処理が発生する。受注作業なら、商品や個数の間違いとか、途中でのキャンセルなどだ。その種類と頻度を的確に把握し、システム側で対応する必要がある。その機能を持たないと、使いものにならないシステムになりやすい。また例外処理は、現状の問題点と直結している場合が多く、問題点の洗い出しにも役立つ。
 このように調査しているうちに、現状での問題点や求めている機能が分かってくる。大きな目的と照らし合わせながら問題点を整理して、必要な機能を規定する。要求仕様書では、必要な機能だけでなく、それが必要な理由まで含めて記述する。理由の中で問題点などを明記し、全体の関係や構造を整理して見せる。
 ニーズ分析の作業では、対象業務の細かな部分まで調べることが多い。その際に得られた情報は、設計の工程で幅広く役立つ。その意味から、中心となる設計者がニーズ分析を行ったほうが無駄が少ない。もし設計者と異なる人がニーズ分析を実施する場合には、ニーズ分析で得られた資料に“細かなコメント”を付け、設計者に渡したほうがよい。そうすることで、システムの機能が的確に設計されるし、設計作業の効率も上がる。

専用ツールを用いて、分析の質を向上させる

 ニーズ分析を上手に行うには、何でもかんでも闇雲に調べたのではダメだ。分析に適したツールを利用して、分析の結果を向上しなければならない。
 問題点の原因や現象は、複雑なリンク構造を持つので、それらの関係を整理して明確化することが大切だ。1つの原因が複数の現象を引き起こしたり、1つの現象が複数の原因に関係することが多い。これらの全体像を明らかにしないと、的確な対策を打てない。問題点を上手に整理できれば、解消するための対策が導き出せ、それがシステムの機能となる。
 ニーズ分析に役立つ一般的なツールとしては、KJ法がもっとも有名だ。知名度がかなり高いので、知っている人も多いだろう。それを改良する形で、システム開発でのニーズ分析に特化させた手法も、かなり以前から現れている。比較的知られているのは富士通のC-NAP(段階的に変更が加えら、少し名前が変わったようだ)で、富士写真フイルムの情報システム部により、KJ法を改良して開発されたFSPANが元になっている。
 これらのツールを利用すると、ニーズ分析の質が向上し、作業もスムーズに進む。ただし、慣れてないと上手に使いこなせないので、実際の仕事で使う前に、別な分野を選んで試したほうがよい。その際、よく知っている人にアドバイスを受けると、苦労せずに使い方をマスターできる。
 システム開発にはオブジェクト指向の波が押し寄せているものの、目的と機能の規定が中心のニーズ分析にはあまり関係がない。オブジェクト指向は、設計段階で大きく関係する技術だからだ。ただし、次の設計工程へとスムーズにつなげる意味から、分析の過程で得られた細かな資料を、オブジェクト指向の考え方でまとめることは可能であろう。そのようなツールが出現すれば、開発全体での効率を上げるために、ニーズ分析の作業で使うかも知れない。

利用者の言うことを全部信じたらダメ

 システムに求められる機能を、利用者だけから調べると、不十分な内容になるケースが意外に多い。この点は、十分に理解しておく必要がある。
 利用者の中には、自分の業務を表面的に見ていない人がいる。また、将来の変化まで考慮する人は少なく、現状での問題点だけを見がちだ。開発したシステムは何年か使い続けるので、最低でも5年先を考慮しなければならない。対象となる業界が5年後や10年後にどう変わるのか、システム開発では重要な点である。もう1つ重要なのは、将来の変化にコンピュータが大きく関わってくることだ。コンピュータのプログラムは作れなくても、コンピュータの特徴や利点を理解して、業界の変化を予測しなければならない。それができないと、システムに必要な機能を求めるのは難しい。
 ニーズ分析の担当者は、利用者から得られた問題点や機能が本当かどうか、的確に判断する必要がある。そのためには、対象となる分野の十分な知識が求められる。それも、単純に理解するのではなく、全体をシステムとして捉えながら理解しなければならない。コンピュータと対象分野の両方の知識が必要なだけに、かなり大変な仕事である。
 利用者の話をそのまま信用しないので、ニーズ分析という表現は的確ではないだろう。同様に、要求仕様定義という用語も適切ではない。しかし、直接的なニーズではなく、漠然と願っているニーズを求めると考えれば、ニーズ分析という表現を使ってもよいと思う。ニーズを調べるときには、このような“見えないニーズ”も十分に考慮すべきである。
 以上が、ニーズ分析の概略だ。より良いシステムを構築するためには、非常に重要な作業だけに、重要なシステムほど最適な人材を割り当てなければならない。これこそ、ニーズ分析の成功を、つまりシステムの成功を大きく左右するポイントである。

(1998年1月15日)


下の飾り