クライアントが望む機能を明確にすることは、ソフトウェア開発において重要です。
クライアントの要求と開発側の認識に齟齬があった場合、ソフトウェアが完成するまでその間違いに気づくことが出来ず、その修正に多大なコストが掛かる可能性もあります。
今回は、ソフトウェア開発における要求分析と、顧客の要求を正確に仕様書にまとめるための技法をご紹介します。
要求分析とは？
要求分析とは、ソフトウェア開発の初期段階で、利用者がソフトウェアにどのような機能を求めているのかを明確にまとめていく工程のことを指します。
開発の上流工程で行われる要求分析は、主にクライアントとの話し合いをもとに進んでいきます。
「この機能は必ず実装欲しい」「この機能も可能であれば実装してほしい」などのやり取りをクライアントと進めていき、まとめたものを要求定義書として文書化していきます。
要求分析と要件定義の違いとは？
ソフトウェア開発の工程には、要求分析と似たような名称で、要件定義というものがあります。
どちらも、クライアントがシステムに求める機能をまとめた仕様書という点で違いはありませんが、技術者向けか、非技術者向けかで違いがあります。
要求分析は、非技術者がシステムに求める機能や、ビジネスで何が必要なのかをまとめたもの、つまりクライアント側の希望を扱う工程です。
要求分析でまとめた要求をもとに、それらを業務として落とし込んでいく場合にはどのようなシステムを開発するべきか、どのような処理を追加するべきかを、開発側の立場で定義していくのが要件定義です。
要件定義については、こちらのシステム開発工程についての記事でも詳しく紹介しているのでぜひご確認ください。(https://pengi-n.co.jp/softwaretest/archives/308)
顧客ニーズに合わせて要求分析を仕様書にまとめる技法
要求分析を仕様書にまとめた、分かりやすい要求定義書を作ることは、その後の要件定義を明確に進めていくためにも重要です。
ここでは、仕様書にまとめる為の効率的な技法についていくつかご紹介します。
5W1Hを意識して作成する
伝えたい情報の趣旨を明確にする代表的な手法として、5W1Hがあります。
5W1Hの組み立ては、要求定義書を作る上でも大切になってきます。
Who(誰が)
ソフトウェアを、誰が利用することになるのかを明確に記載します。
利用するクライアント側にはどのような人がいるのか、PCの扱いに長けている人向けのシステムなのか、そうでない人向けなのかなど、ユーザーの立場を考えると求められる要求も明確になってきます。
When(いつ)
ソフトウェアがいつまでに必要なのか、納期を明確にします。
納期を明確にすることで、開発スケジュールやテストスケジュール、また不具合による急な修正が発生した場合のバッファを設ける等、開発を円滑に進めるためのスケジュールが策定しやすくなります。
What・Why(なに、なぜ)
ソフトウェアにはどのような機能が必要か、また、なぜその機能が必要なのかを明確にします。
クライアントがソフトウェアを利用する目的は何か、利用することでどのような作業を実現、または効率化することが出来るのかを考えることで、要件定義の工程に進んだ際に、開発側としてどのような処理を追加することでそれを叶えることが出来るかが明確になってきます。
How(どのように)
ソフトウェアを、クライアントがどのように利用することになるのかを明確にします。
WEBサービスとして展開するのか、クライアントサーバー型のソフトウェアとして各端末にインストールしてもらって利用するのか、クライアント側の業務形態や予算をもとに検討して、どちらを選択するのが良いかを考えましょう。
ブレーンストーミング
ブレーンストーミングは、新たなアイディアを生み出したり、要求を引き出すのに効率的な手法としてしばしば用いられます。
集団発想法とも言われており、グループで議題に沿って自由に話し合い、出てきた発想を整理して問題解決へと導きます。
ある議題に対して自由に意見やアイディアを出し合いますが、前提として4つの原則があります。
他人の意見を批判しない
自身の考えと異なる意見が出てきても批判してはいけません。批判されて萎縮してしまうと、その方が発言する機会を奪ってしまいます。
自由奔放の発言を尊重する
議題に対して、自身が感じる意見や問題点等を自由に発言しましょう。また、他の人々はその意見を尊重しましょう。
自身が奇抜かなと感じていた意見だとしても、他者に聞いてもらうことで予想外の良いアイディアに繋がるかもしれません。
質より量を考える
多くの意見やアイディアを出すことが目的なので、質にこだわらず次々と意見を出し合いましょう。
意見やアイディアを結合・発展させる
複数出てきた意見を関連付けたり、違った角度から考えてみることで新しいアイディアを生み出すことも重要です。
他者の意見には積極的に便乗して結合し、アイディアへと発展させていきましょう。
ブレーンストーミングは要求分析の場でも非常に有効な手段です。
クライアントと開発側が率直に意見を出し合って整理していくことで、クライアントが本当に求めている機能、実は必要としていなかった機能等が明確になり、認識の齟齬もなくなります。
ソフトウェア開発の目的を明確にするためには、問題についてクライアントと屈託のない意見を交わして、綿密な意思疎通を図る大切です。
フィッシュボーンダイアグラム（魚骨図）を作成する
フィッシュボーンダイアグラムは、特性要因図とも言われます。
ある結果がもたらされるまでの要因を書き出し、そこに潜む問題点を見つけ出すために用いられる手法です。
書き出した図が魚の骨に似た形をしているのが名前の由来です。
要求分析の場合、例えば結果にあたる部分が現状の不満点、要因にあたる部分が不満に感じる原因と捉えることが出来ます。
不満点を解消するためには、その原因を洗い出して改善する必要があります。
それらを書き出して明確にすることで、クライアント側の要求から実装するべき機能が見えてきます。
問題要因関連図
因果関連図とも言われています。
因果とは「原因」と「結果」の関係のことを指します。
因果関連図では、結果の部分が解決したい問題であり、その問題を引き起こす原因、原因のさらに根本的な原因を書き出していきます。
要求分析においては、解決したい現状の不満点についての原因を考え、その原因を招いている根本的な原因を整理していき、ソフトウェアの導入によってどの部分が解消されれば不満点の解決に繋がるかを検討していきます。
勘違いしやすい要求定義書と要件定義書の違いって？
要求定義書と要件定義書は混同されがちですが、要求定義書はあくまで要件定義書を作るための前段階として、クライアントの要求を仕様書としてまとめたものです。要求定義署の内容をもとに、開発側で要求を満たすための内部的な機能についてまとめた資料が要件定義書となります。
【まとめ】要求分析はソフトウェア開発の第一歩
要求分析は、クライアントの要求を明確にして、お互いの認識の齟齬がなくソフトウェア開発を進めるのための第一歩です。
要求分析を明確に行うことで、実装すべき機能や、以降の工程で行うべきことが見えてくるため、円滑に作業に入ることが出来ます。
ニーズに応えるためにも、ブレーンストーミング等でクライアント側と協力して意見を出し合い、精度の高い要求定義書を作成出来るよう心がけましょう。
