|
|
概 要 要求抽出では問題領域の専門家の知識や顧客ニーズ、現状の問題、経営課題などに基づいて要求を獲得する。要求抽出段階の課題を分類すると、対象領域の決定と問題の理解、要求の変化になる。このときシナリオやユースケースなども利用する。要求抽出には要求の収集、分析、優先順位付けがある。要求抽出手法も多様なものが提案されている。本稿では、要求抽出手法を概観する。 要求抽出の位置づけ まず要求工学プロセスの中での要求抽出の位置づけを復習しておくと、次のようになる[1][2]。要求工学プロセスには、要求抽出、要求分析、要求の仕様化、要求確認がある。要求抽出と要求分析までが問題領域に関するプロセスである。これに対して要求の仕様化と要求確認がソリューション領域のプロセスである。要求抽出では問題領域の専門家の知識や顧客ニーズ、現状の問題、経営課題などに基づいて要求を獲得する。 このときシナリオやユースケースなども利用する。要求抽出で獲得した要求間の構造や一貫性を明らかにするのが要求分析である。要求分析ではさらに要求間の優先順位を明確化して顧客との合意を形成する。この過程で概要レベルの要求が具体化される。 要求抽出の課題 要求抽出の課題には次の3つがある[3]。 ◆問題の範囲 システム化の境界が明確に定義できない。不必要な設計情報が要求の中に混入する。 ◆理解の問題 ユーザー自身が要求について完全に理解していない。コンピュータの能力や限界についてのユーザーの理解が不十分である。問題領域についての知識が不十分。ユーザーと分析者の言葉が異なる。当たり前の情報を見逃しやすい。顧客ごとに視点が異なり互いに矛盾する。「ユーザフレンドリ」などのように要求が曖昧で確認できない。 ◆揮発性（volatility）の問題 時間の経過とともに要求が変化する。 要求の構成 抽出すべき要求にはいくつかの種類がある。どのような要求を対象としているかを識別しておくことにより要求抽出作業を効率化できる。たとえば、次のように要求を分類できる。 ◆経営目標 組織活動の目的としての戦略的な目標。戦略目標はより具体的な戦術レベルの目標に展開される。 ◆ビジネスプロセス 組織の経営目標を実現する上での運用プロセスに対する要求。ビジネスプロセスには人が実行するプロセスとソフトウェアが実行するプロセスがある。 ◆機能要求 ビジネスプロセスの中でソフトウェアが実行する機能に対する要求。 ◆制約要求 機能に関する制約条件。性能面、コスト面、セキュリティ面などの観点からの要求がある。また要求間の依存関係も制約要求の一種であると考えられる。 要求抽出プロセス 前述した要求の段階的な構成に従えば、次のような要求抽出プロセスを構成できる。 ◆経営目標の確立 ビジネスの目標を明らかにしてシステム化の対象領域を明確化する。 ◆組織構造の明確化 ビジネスに関連する組織を明らかにするとともに組織間の連携の可能性についても明確化する。この過程で必要な領域知識についても収集する。 ◆関係者（Stakeholder）の明確化 経営目標や組織構造などの情報に基づいて組織ごとに適切な関係者を特定して要求に係わる関係者間の関係を明らかにする。 ◆要求の明確化 関係者から要求を抽出し、組織の要求、運用プロセスの要求、機能要求、制約要求を明確化するとともに各要求間の関係を整理する。 ここで挙げた順番で要求を抽出することもできるが、実際にはこれらの活動が反復的に混在して実施されることになるだろう。重要なことはこれらの活動を繰り返すことで可能な限り漏れなく要求を抽出していくことである。このためには、これらの要求に番号や種別を付与して列挙可能な形で整理することで類似性や重複の確認ができるようにしておく必要がある。 実際には要求抽出プロセスの中でこれらの活動が反復的に混在して実施されることになるだろう。 要求抽出手法 表要求抽出の方法には次のようなものがある[2][3][4][5][6][7]。 （１）資料収集 開発対象となるシステムやその業務に関する既存の資料を収集し、それらを分析することにより、問題点や要求事項を抽出する方法である。 （２）アンケート 顧客にアンケートし、その結果を分析することにより、システムに求められる顧客の要求を抽出する方法である。 （３）インタビュー 顧客にインタビューすることにより、システムに求められる顧客の要求を抽出する方法である。オープン型インタビューと構造化インタビューがある。オープン型インタビューでは、顧客から自分の業務について自由に話をさせ自然に業務情報を獲得していくことで、対象領域に関する分野知識を包括的な視点から獲得することにより要求を抽出する。しかし個別的な要求の詳細を具体化するためには、構造化インタビューを用いる必要がある。構造化インタビューでは、要求エンジニアが予め想定した質問への回答を顧客から抽出することを目的とする。インタビュー上の留意点には、次の2つがある。 質問者が顧客の現実の声に可能な限り耳を傾けることが最も重要である。また顧客から具体的な意見を効率的に収集するためには何らかの具体的なインタビューの観点を質問や提案書などの形で提示する必要がある。 （４）現場観察 対象とする組織の戦略を理解するためには、社内を直接観察する方が顧客にインタビューするよりも容易な場合もある。社内観察の結果を「現場観察カード」にまとめることで網羅的に現場の状況を把握することができる。たとえば我々が使っている「現場観察カード」[5]では、オモテ面には現場で起きている事実、問題、対処策、改善の機会を記入し、ウラ面には成功要因（CSF）と評価指標（KPI）ならびに関連組織を記入する。現場観察カードでは現場の課題をはがき大のカードの両面を使って簡便に収集できる。またKPIを観測提示することにより、経営目標間の因果関係の妥当性を分析・評価できる。こうすることで社内プロセスをKPIで定量的に可視化できるようになるだけでなく、必要なアクションを適切に実施できるようになる可能性もある。 現場観察カードで記述する具体的な内容は次のようになる。 ・事実：現場で起きている問題を端的に表す名称を記入する。 例：売りたい商品は売れる商品ではない ・問題：現場で起きている問題を記入する 例：企画部が新製品への期待度が高いことから強気の予測をしてしまったため、営業が在庫処分の為に顧客に無理やり商品を勧めている ・対処策：現場での問題対処の仕方を記入する。 例：出来る営業は売るときに、製品のコンセプトや製品を作った人の思いを聞き、顧客を選別している。また予測とのズレが少ない場合は、自社で開発した製品を客観視し、市場の動きを適切分析している。 ・改善の機会：改善すべき点や具体的な解決策を記入する。 例：企画部が販売予測をするに当たって、営業担当者などの意見を聞く。予測が的中した場合、外れた場合、そのときの在庫の数などの要因を分析し、今後につなげる製品開発のコンセプト、アピールポイントなどを開発者に聞く ・成功要因：誰と誰の間にどんな課題があり、解決する必要があるかを記入する。 例：「企画」と「営業」で「新製品に対する期待度から強気の予測や発注をするために在庫を多く抱えてしまう」という課題を解決する ・KPI候補：断絶の有無や、程度の判断ができるKPIの案を記入する。 例：結果指標＝＞在庫管理維持費、顧客満足度、先行指標＝＞販売予測とのズレ率 ・関連組織： KPI の良し悪しに関係する組織名を記入する。 例：企画部、販売部営業担当ここで紹介したように、現場観察による要求抽出は、社会学的な人間観察の手法を用いているので、要求工学では「Ethnography」（民族誌学）と呼ばれている[4]。 （５）目標分析（Goal Analysis） 目標に関する階層的な木を使った発想法を利用して，システムに求められる要求を抽出する方法である。システムの目標を大きな目標から、それを構成する部分目標に段階的に展開していくことにより、具体的な要求を抽出することができる。目標分析が対象とする要求はたとえば「売り上げを増加させる」とか「在庫を削減する」などの経営上の目標としての非機能要求であることが多い。この階層木では幹から枝へ、枝からより小さな枝へと、ある関連に基づいて枝を伸ばして行く。またこの階層木はゴール階層、ゴール-サブゴール階層、目的-手段階層などとも呼ばれる。 目標間の関係にはこのような階層関係だけではなく因果関係がある。目標の階層関係では、上位の目標が複数の下位の目標にAND分解される場合とOR分解される場合がある。 これに対して、異なる目標の間に依存関係があって、一方が成立するならば他方も成立するときに因果関係が必要になる。このような因果関係は経営目標を戦術的な作業目標に展開する場合、異なる部門間の戦略目標間の間接的な関係などを明確化する場合などに必要になるだろう。 （６）事務手続き分析図を利用する方法 システムに求められる顧客の要求を、業務フロー図や産能大式事務手続き分析図などを利用して抽出する方法が用いられることが多い。業務の流れを忠実に記録できるので顧客にも分かりやすいという特徴があるが、業務手順と経営目標との関係などを明確にしてシステムのあるべき姿との対応付けに留意するなどの工夫も必要だ。 （７）ユースケースやシナリオを利用する方法 オブジェクト指向分析手法ではユースケースが使われている。ユースケースではアクタが実行する必要のある業務目標とその過程で必要となる機能やタスクの一連の利用シナリオを記述する。ユースケースの抽出では業務フローに基づいて利用シナリオを作成することもできる。 また、システムの機能をユースケースで抽出するだけでなく、システムへの攻撃や想定すべき例外を抽出するためにミスユースケースという考え方も提案されている[6]。ミスユースケースは機能に対するユースケースの性質を表現しているので非機能要求のひとつである。ミスユースケースとユースケースの関係には、ミスユースケースからのユースケースに対する脅威（攻撃）関係と、ミスユースケースからの脅威に対するユースケースによる緩和（防御）関係がある。たとえば、ユースケース「サービスアクセス機能」に対する脅威として「管理が厳しいとフラストレーションがたまる」というミスユースケースが考えられる。このミスユースケースに対して「管理をゆるくする」というユースケースを考えると、さらに「システムに侵入する」というミスユースケースがあることに気づく。このようにユースケースとミスユースケースはちょうど、チェスや将棋のように交互に手を指す感覚で要求を抽出できるという特徴がある。ミスユースケースはセキュリティなどの非機能要求を抽出するのに適していると思われる。 ところでユースケースにおける利用シナリオとシナリオ分析におけるシナリオとは類似点もあるが異なる点もあるので注意が必要だ。シナリオ分析はもともと人間とコンピュータの対話過程を典型的な事例を用いて詳細に記述するものだ。シナリオでは将来の理想的なソフトウェアにおける典型的な利用例を叙述的に紹介する。このため未来社会を想定したデモシステムなどではシナリオ分析がよく利用される。たとえば高齢化社会で必要となる福祉支援システムの要求を抽出する場合、典型的な利用者として、年齢83 歳の花子おばあさんのある1日を具体的に想定することで必要なシステム機能の見落としを防ぐことができる。 またプロトタイピングでも、対象とするシナリオを明確にしておくことで関係者の声を効果的に収拾して的確に要求を抽出できる。 （８）会議により要求を抽出する方法 会話が主体の会議だけで要求を抽出しようとするのでは会話内容が十分正確に記録できないと、作成される要求仕様が不正確になる。また会議の中では同じ話題の繰り返しや互いに矛盾する提案が行われるなど非生産的な活動も発生してしまうかもしれない。この問題の原因は、要求を記述するための重要な情報が会話の中に含まれているにもかかわらず、顧客の意図や設計理由などの検索・参照などに適した構造を議論自体が持っていないことにある。 このため議論の内容の記録項目とその記録方法を規定することにより、議論の進め方を制御しつつ要求抽出を支援する方法として、Inquiry Cycle モデル（ICM）が提案されている[7]。ICMでは、議論の内容をQuestion, Answer, Reasonの３つのノードからなるハイパーテキストを用いて記述することにより、要求を段階的かつ系統的に抽出することができる。会議の過程を構造化することにより、議事録から効率的に要求を抽出できるだけでなく、必要な議論の抜けを防いで会議を効率化できる可能性がある。ICMは一種の構造化インタビューと考えることもできる。 また会議には複数の利害関係者を同時に集めて議論する「協調セッション」という手法もある[4]。協調セッションでは異なる視点からの要求を同時に収集できるので発見的な会議を効率的にできる可能性がある。 （９）ブレインストーミング ブレインストーミング（Brain-Storming）を利用して、システムに求められる顧客の要求を抽出する方法である。ブレインストーミングは会議形式によるアイデア発想法である。次の４つのルールを守るだけで他には特に細かい約束ごとを持たない。 ・他人の発言は一切批判しない ・自由奔放に発想する ・量を求める ・組み合わせによりアイデアを改善する （10）カードの利用による方法 カードを使った発想法を利用して、システムに求められる要求を抽出する方法である。たとえばKJ法などの発想法が利用されている。KJ法では(1)ラベル作り(2)、ラベル拡げ、(3)ラベル集め、(4)表札作り、(5)A型図解化（空間配置、グループ編成、タイトル付け、囲みの間の関係図示）、(6)B型叙述化（ストーリー作り、文章化など）の６つの過程から構成される[8]。 コミュニケーション 本要求抽出では様々な人々からの情報を入手するためのコミュニケーションが大変重要である。このようなコミュニケーションの方法はもちろん情報技術分野だけではなく人間生活の中でも大切な技である。一般書なども参考にしてSEと呼ばれる専門家もコミュニケーション能力をつけるべきであろう。技術の専門家は往々にして対話力よりも自分のうちに閉じた思考を優先しがちでそういう行動をとりやすいことがあるが、顧客からの要求獲得の場面で、こういう態度では、顧客の心からの要求は抽出できないと思われる。たとえば昨年暮れに岩波新書から出版された「コミュニケーション力」の第３章でもコミュニケーションの技法がいくつか紹介されている[9]。会議を運営するコツ、ブレインストーミングのコツ、ディスカッションのコツ、メタ・ディスカッション、質問力などは、読者の皆さんもなるほどと思われるに違いない。メタ・ディスカッションは簡単に言えば、議論過程を客観的に可視化することだ。実は「議事録」などはメタ・ディスカッションを文章化したものと考えればいい。ICMもメタ・ディスカッションの例だ。新米のSEなどは先輩と一緒にお客さんとのシステム開発会議で議事録作成を修行する訳だが、なんで何時間もかけて済んでしまった議論の結果を残すのか理解できなかった方も多いだろう。しかし、実は会議の中で誰がどういう発言や提案をし、その結果、どういう判断や結論に至ったかを分析しておくことは、単に、どの会議で誰が何を言った、言わないというような言質をとるためだけではなく、どのような発言や質問によって参加者の反応がどう変化し会議の流れが変化するかを分析できる貴重なノウハウになる可能性がある。こういう視点で普段の会議を見直せば、どの発言は成功で、失敗する発言にはどういう傾向があるか客観的に分析できるようになるのではないだろうか。齋藤氏は「会議はサッカーのようなもので、現実を具体的に変えるアイデアがゴールだ」という。この指摘に賛成だ。だれがその会議のMVPだったか、得点王はだれか振り返ってを見てみれば、会議も楽しくなる。 また質問力のポイントは、「自分が聞きたいこと」ではなく、「相手が熱く語りたくなること」を第一に考えて質問するということだそうだ。こういう質問ができるようになれば、顧客の抱える現実の本質的な課題がどこにあり、それをどうすれば具体的に変えることができるかについて実りのある議論ができると思われる。 まとめ 本稿では、要求工学における要求抽出の課題と基本的な考え方を紹介した。要求抽出の技法については様々な手法が提案されているので、ソフトウェア開発の現場で適用する場合には状況に応じた取捨選択も重要だ。しかし、要求抽出の中心はなんといっても顧客との真に心の通い合うようなコミュニケーションであると思われる。納得はできても喜んで満足していただけないような要求だとしたら、システム開発投資への意欲は消失してしまうに違いない。要求に対する顧客満足度を評価するために品質機能展開QFD（Quality Function Deployment）を要求抽出に使うことも効果的だ[10]。QFDでは「お客様のニーズ」を「ソフトウェアに対する技術的な機能要求」に系統的に翻訳することができる。たとえば顧客の求める非機能要求の視点から、機能要求を「標準的な要求」、「期待どおりの要求」、「素晴らしい要求」に分類して評価することで、抽出した機能要求の満足度を図ることができるだろう。このようにQFDでは顧客満足度を最大化することに着目して顧客の求める品質という非機能要求の観点からソフトウェアが具備すべき機能要求を評価できる。 さて次回は、要求の分析について紹介する予定である。 参考文献 [1] 山本修一郎、要求工学、ビジネスコミュニケーション,http://www.bcm.co.jp/ [2] Kotonya, G. and Sommerville,, I.,Requirements Engineering ? Processand Techniques, John Wiley & Sons,2002. [3]Christel, M.G. and K.C. Kang, Issues in Requirements Elicitation,CMU/SEI-92-TR-12, 1992. [4] Hickey, A.M. and Davis, A.M.,Elicitation Technique Selection: How Do Experts Do It?, IEEE Requirements Engineering, 2003 [5]古久根他，“社内観察情報を活用した戦略構築と組織展開 −業務評価モデリングの試み―”，経営情報学会2004年秋季全国大会，(2004)． [6] Alexander I., Misuse Cases: Use Cases with Hostile Intent, IEEE Software, January/February, pp.58-66, 2003. [7]C.Potts, K.Takahashi and A.Anton,Inquiry-Based requirements analysis,IEEE Software, Vol.11, No.2, pp.21-32, 1994. [8]川喜多二郎、発想法 創造性開発のために、中央公論社、1967 [9]齋藤孝、コミュニケーション力、岩波新書915,2004 [10] Hallowell, D.L., QFD: When and How Does It Fit in Software Development? http://software.isixsigma.com/library/content/co40707b.asp
Copyright:(C) 2004BUSINESS COMMUNICATION All Rights Reserved |
