ホーム >  要求工学 >  2008年11月号 >  第49回：要求を軸としたこれからのソフトウェア社会

平成20年９月25日（木）、豊洲センタービル36階コンファレンスルームで、システム科学研究所（RISS）主催の特別セミナー『ソフトウェア社会を描く』を開催した。セミナーでは、日頃から筆者と一緒に要求工学について議論していただいている立命館大学の大西 淳教授、東京工業大学の佐伯 元司教授とコンサルタントの加藤 潤三氏に加えて筆者の講演とパネル討論を実施した（表１）。また百数十人の参加者にもご来場いただくことができ、盛会だった。今回は当日のセミナー模様を紹介することとしよう。

なお、以下ではまず「概要」で各講師の方々の講演内容をまとめ、次いで「解説」で筆者が講演内容についての関連情報を補足している。

立命館大学 教授 大西 淳氏『要求定義の難しさ』

概要

大西教授は、工業製品とソフトウェア開発における要求定義の違いについて分かり易く解説した。工業製品では、製造側とユーザーに共通認識があって想定をこえた要求がほとんど出ない。たとえば自動車への要求では、人間や荷物の運搬に使われることや運転者の指示通りに走行することなどから、最近では事故から守ることや環境に易しいことが求められるようになった。これらの要求を自動車の製造者もユーザーも共通認識していると指摘した。

またソフトウェア開発では、以下のような難しさがあることを指摘した。

• 要求は立場によって異なる
• 利用者側は当たり前のことは言わない
• 要求が間違っていることがある
• 要求は変わることがある

最後にソフトウェア要求定義がいかに難しいかということを以下の非常に簡単な例で説明した。

【例題】

「三角形の三辺の長さを入力して面積を出力する」

【解説】

ソフトウェア製品と工業製品を比較すると表２に示すように８つの観点から整理できるだろう。

また、大西教授が指摘したソフトウェア要求の困難性をまとめると次のようになるだろう（表３）。

• ユーザーにとって当たり前の要求や、ユーザーにも不明な要求については要求を明示できない
• 要求には抜け、矛盾、曖昧などの誤りがある
• ユーザー、立場、時間経過や技術の進展、環境変化などの要因で要求が変化する

三角形の面積を計算する例題に対する要求仕様を、読者の皆さんはどのように記述されるだろうか？要求記述の完全性を、どのようにして判断することができるだろうか？

大西教授は、要件記述をどのように検査すればよいかについては詳説されなかったので、筆者なりに一つのアイデアを紹介しておこう。たとえば要件の記述要素に基づいて、表4に示すような検査項目で要件の完全性を確認するのである。皆さんが記述した要求仕様をこの表に基づいてぜひ点検してみて欲しい。

なお、この表の考え方は本連載第38回「要求の曖昧さ」で紹介した内容に基づいている。また、この検査表が記述項目を示していると見なせば、要求仕様を記述する際のテンプレートとしてこの表を使えることにも気づいていただけるだろう。

東京工業大学 教授 佐伯 元司氏『要求工学概説』

概要

佐伯教授は、まずロンドン市の救急車手配サービスLAS（London Ambulance Service）の事例を紹介して、システム開発において本当に必要な情報を収集して分析することの大切さを強調した。

次いで、現代ではソフトウェアの広まりとともに要求工学の対象が人間や社会にまで範囲が広がったとして、大西教授が指摘したソフトウェア要求の難しさに対してどのような要求工学技術が提案されているかを、以下のような要求分析プロセスに基づいて紹介された。

◆要求分析のプロセス

要求獲得：ステークホルダ（関係者）を識別し、要求を抽出するとともに関係者間で合意を形成する。

要求記述：要求をモデル化し文書化する。

要求検証：要求記述を解析しテストおよび実行することにより妥当性を確認する。

要求管理：要求の変更と品質を管理する。

さらに、ステークホルダーが何をしたいのかという抽象的なニーズから具体的なゴールに向かって、要求達成を実現するためのサブゴールに分解していく『ゴール指向分析法』を概説し、佐伯研究室で開発している『ゴール指向分析法』支援ツールのデモを紹介された。

【解説】

◆LASの事例分析

LASの事例を参考文献[1]にしたがって、筆者もアクタ関係表で分析してみると、表５のようになった。この表では、×をつけることで、問題のあるアクタ関係を示している。

また、コンピュータ支援配車システムCAD（Computer Aided Dispatch）、自動位置追跡システムAVLS（Automatic Vehicle location system）、移動データ端末MDT （Mobile data terminal）などのLASを構成するサブシステムもアクタとして分析している。ただし、救急車や救急車に搭載される位置通報機器や無線システムは簡単のために省略した。

この表から、たとえば以下のようなことが分かる。LASでは、AVLSが精確な救急車の位置を追跡できることを前提にしていた。しかし実際には、当時の技術では救急車の精確な位置を把握できなかった。このためCADが最適な配車位置を計算できず、例外メッセージの大量発生によりシステムの応答性能が低下するとともに、MDTで例外メッセージがスクロールされるために救急隊員が例外を見逃すことになった。また、救急車が適切に配車できないために利用者が繰り返し配車を要請しただけでなく、配車の遅れにより利用者が既に自主的に病院に行ってしまったため無駄な配車になるという事態が発生した。このような事態のため、救急隊員にもフラストレーションがたまり適切な情報をMDTに投入できず入力の遅れにつながった。さらに、MDTの操作性の悪さから入力誤りが増え、例外メッセージの増加を加速した。

◆ゴール指向分析

ゴール指向要求分析については本連載でも繰り返し紹介してきたように、現在最も注目されている要求工学技術である。

セミナーの聴講者には筆者が執筆した書籍『～ゴール指向による～システム要求管理技法』を紹介しておいたところ後日、ある方から次のような趣旨のメールを頂いた。

「ビジネスアセスメントに基づくビジネスデザインについて検討していたが、ビジネス戦略との関わりあいをどうすればいいか悩んでいた。セミナーで紹介された『～ゴール指向による～システム要求管理技法』を読んだところ、ゴール指向とJacksonのプロブレムフレームについて述べられている箇所を、この問題にぴったりはめ込むことができることに気づいて解決できた。」

このようにゴール指向分析はソフトウェア開発だけでなく、ビジネスデザインにも役に立つのである。

加藤 潤三氏『要求とプロブレムフレーム』

概要

加藤氏はビジネスプロセスモデル、要求と仕様書の関係、プロブレムフレームの背景などについて解説した。

◆ビジネスモデルとビジネスプロセスモデル

加藤氏はまず、経営コンサルタントが開発するビジネスモデルの詳細化が、必ずしもビジネスプロセスモデルには結びつかないこと、ビジネスプロセスモデルの専門家はまだ育成されておらず、ITの専門家がビジネスプロセスモデルの開発に参加するようになっていると指摘した。次いで以下のようなビジネスプロセスモデリング手法を解説した。

・BABOK－Business Analysis Body of Knowledge

BABOKは、非常にハイエンドなビジネスプロセスモデルの知識体系に基づく資格検定サービスを提供するが、認定されるためには15年から20年の経験が必要になる。このため一般のIT技術者には敷居が高いのではないかと指摘した。

・OMGのビジネスプロセスモデリング仕様（表６）

OMGではビジネス戦略、ビジネスルール、ビジネスプロセスマネジメントに関する７種類の仕様を策定しており、2008年３月にISOに提案したと紹介した。またレンタルビデオショップを例に、ビジネスプロセスモデルの表記法であるBPMNを解説した。

◆要求と仕様

ビジネスプロセスモデルの観点から、まず計算機システムへの要求を次の３種類に整理した。

・ビジネスモデルから見たビジネスプロセスモデルへの期待、目的、目標
・ビジネスプロセスモデルの例外への対応
・計算機システムの運用

また人間社会における法律や制度、規制、慣習などは制約であり、要求とは異なると述べた。

次に、計算機システムへの要求を満足し、かつ実現できることを裏付けることを目的として記述した文書が要求仕様であると定義した。

その上で、要求を述べるのにモデルは必ずしも必要ではないが、要求仕様を記述するためには、モデルが必要となると指摘した。この理由は計算機システムを実現できることを示すためにはモデルが必要となるためであろう。

しかし、モデルだけでは計算機システムの仕様を記述できないことも分かってきたと指摘した。この問題に対処するために考案されたのがプロブレムフレームであると述べた。

◆プロブレムフレーム

プロブレムフレームでは、まず課題とその解法との対応関係を明確に記述する。

次に課題を部分課題に分解することができ、部分課題の解法が既知なら、課題の記述を終了する。

最後に部分課題を実現可能な仕様として組み立てることにより課題に対する要求仕様を作成する。

このようにプロブレムフレームでは、課題を効果的に解くために、課題とそれを解くための効果的な解法との対応関係を発見し蓄積しておくことが重要になると指摘した。

またプロブレムフレームの効果として、人間をシステムの構成要素として行動するという表現（従順、Biddable）を導入したことを挙げた。

【解説】

OMGのビジネスプロセスモデリングの概要については文献[2]が参考になるだろう。

さて要求と仕様とを明確に分けて考えることは、JacksonだけでなくParnasも同様のことを指摘しているように当たり前のようだが非常に重要である。このことは要求仕様が誰のものなのか、誰が責任を持って管理するのかを考えるとよく分かる。要求したつもりでいたのに仕様化されていなかったら、その責任はどこにあるのだろうか？仕様化されなければ実現されない。要求したつもりの機能が実現されていないときに何が起きるかは明白である。

プロブレムフレームで人間行動を明確に記述できるようになったという指摘も重要である。

たとえば、IC乗車券、乗客、自動改札機を考えてみよう。乗客はIC乗車券を自動改札機にかざすことで従順に自動改札機の動作に従う。自動改札機に乗客が「従順」に従うことで、「鉄道会社による改札業務の自動化」というニーズとしての要求を満たすことができるようになる。この例でのシーズは、IC乗車券と自動改札機である。

ただし、セキュリティの分析などでは、人間が必ずしもシステムに対して従順に行動しない場合についての扱いが必要になるので、本連載第11回でも紹介したように、乱用プロブレムフレームが研究されている。

NTTデータ フェロー 山本 修一郎『要求工学とイノベーション』

概要

筆者は要求工学についてそれまでの講演を総括する形で、現代では要求工学と製品やサービスイノベーションには密接な関係があることを指摘してITがもたらす新たな価値について解説した。

まず、本連載でも紹介したソフトウェアをベースとする「iPod」のオープンイノベーションの事例を用いて、「iPod」のような携帯音楽プレーヤ製品の製造でも消費市場への新商品の導入ではソフトウェア要求の明確化が重要になることを指摘した。

次いでITシステム価値の形成では、発注者、運用者、開発者がITシステムにどのような価値を創出するかが、どのような範囲でITシステムへの要求とこれらの関係者が主体的に係るかに依存していると指摘した。

また発注者が調達仕様を開発者に提示することで、仕様を満たすモデルを調達に参加する複数の開発者が提案し、発注者が提案されたモデル候補を調達仕様に対して仮想的に統合することで最適なモデルを選定し調達するという「モデル調達」の概念を紹介した。モデル調達ではプラットフォームのアーキテクチャが定められており、発注者は開発者から提案されたアプリケーションモデルをプラットフォームモデルと結合して信頼性や性能などをシミュレーションにより確認できる。

さらに、アクタ関係表によるビジネスプロセスマネジメントの例を紹介した。

最後に、これからのソフトウェア社会を迎えるにあたって以下のような課題を指摘した。

• ソフトウェア社会の課題として、これからのソフトウェアシステムは単独では存在しない
• 多様なソフトウェアシステムが互いに結合し、相互作用していく中で環境適応していくことが求められる
• 複数のシステムを組み合わせるときに、それぞれのシステムがもともと持っていた以上の機能が後から付加される可能性がある
• したがって、ディペンダビリティや変動性に対する取組みが必要となる

参加者からの質問

以下では、セミナー参加者の質問に対する筆者の回答例を紹介する。

◆発注企業側にも導入できる要求工学手法は何か？

要求工学は、ソフトウェア開発の欠陥を可能な限り上流で除去するための技術として研究が始まったが、最近では各講演者が述べているように、ソフトウェアを取り巻くシステムやビジネスプロセスまで含めた広い範囲を対象として研究されるようになっている。

ビジネスプロセスにおいて、どこを計算機システムで実現するかを決定することは発注者の責任であろう。要求獲得では情報収集、問題識別、対策立案などの手法が使える。また要求の優先順位付けは発注者が主体的に決定すべき事項である。ソフトウェアが社会に浸透することで、ソフトウェアを対象としてきた要求工学と、製品やサービスイノベーションとの関係も深まっている。ゴール指向手法は、ビジネスルールにも使える。今後は開発者だけではなく、発注者にも使えることを前提にした要求工学手法が数多く開発されていくことだろう。実際に要求工学の国際会議などでは、発注企業による研究発表も現れている。

◆要求工学をユーザー、発注者、開発者のどこで使うのか？

要求についてのユーザー、発注者、開発者の役割をアクタ関係表で分析してみると、表７のようになる。ここから分かることは、それぞれの立場で要求工学手法を活用できるということである。ここでは要求を管理するのが発注者、要求仕様を管理するのが開発者としたが、このような役割分担はプロジェクトごとに異なる可能性があるだろう。

重要なことはプロジェクト開始に際して、このような役割分担を予め決めておくことである。役割が明確になれば何をすべきかが決まるから、そのときにどのような要求工学手法を適用できるかを決めることができる。逆に、役割が曖昧であれば、何をすべきかも分からないからどの要求工学手法を適用できるかも分からないことになる。

◆要求獲得では、顧客からの要求を際限なくヒアリングしていくとコストオーバしてしまうがどうすればいいか？　

まず、すべての要求を集めるべきである。そうしないと重要な要求が抜けてしまう可能性がある。次いで、その要求によって生まれるビジネス価値に基づいて顧客に要求の優先順位を意志決定してもらう。さらに要求の実現性を開発者が評価することにより、要求の優先順位を顧客とともに見直す。この過程でコストや期間について顧客と合意形成する必要がある。

もし要求を獲得した順に仕様化していくと、後から重要な要求が抽出されるかもしれない。途中でコストを理由に、ビジネス価値の高い要求を捨ててしまえば、顧客の満足は得られないのではないだろうか？

また、効用の観点から見ると機能要求には２つの種類がある。

◆RTB要求

Run The Business 要求。つまり、ビジネス遂行上どうしても使わなければならない機能要求である。RTB要求については可能な限り単純化することでコストを低減できる。

◆VB要求

Value Business要求。つまり、なくても業務に支障はないがあると便利な付加価値としての機能要求である。VB要求はコストオーバするなら削減の候補になるだろう。

いずれにしろ、要求獲得の段階でこの２種類の要求を区別しておくことで、優先順位付けを容易化できると思われる。

さらに、非機能要求についてもコストの観点から調整の幅がある。たとえば操作性、性能、セキュリティなど機能に関する属性のうち、それぞれどのような水準を実現するのか、また属性間で何を優先するのかということについて、顧客との間で優先順位を決定する必要がある。

最後に、要求をソフトウェアで実現するのか人間が運用で実施するのかについて意志決定する要求割付の判断が必要である。つまり、要求としては必要だが、必ずしも計算機システムで実現する必要はないかもしれないのである。佐伯教授が紹介したLASの事例では、それまで人間が作業していた救急車の手配を、救急車の位置追跡から配車先の決定までシステムで自動化しようとして失敗した。

なお、顧客から際限なく要求が出てくるのには、それなりの理由があるかもしれない。たとえば顧客自身に要求のビジネス価値の判断ができていないのかもしれない。ビジネスモデルが明確であれば要求も、その優先順位も明確になるはずである。この理由はビジネスの優先順位が明確になっているからである。もし優先順位が曖昧な状況の下で仮にシステムを構築したとしても、ビジネスモデルが曖昧なのだから満足度は低くなる可能性が高いのではないだろうか？ではどうすればいいかといえば、探索的なビジネスモデルなのだから、iPodの事例でアップル社が実践したように、段階的に要求を実装して市場に要求の妥当性の可否を問うことである。このためにはすべての要求を実装するのではなく、段階的に少しずつ要求を選んでコストの範囲で実装していくことになるだろう。

いずれにしろプロジェクトの開始段階で、どのような方針でシステムを開発するのか要求の扱い方について合意しておくことにより、前述した手法を選択して適用することができるだろう。

パネルディスカッション

パネルディスカッションでは、「今後ますます要求工学が扱う領域が増加するが、その複雑さに対してどう対処するか」というテーマを筆者が提出した。

これに対してパネリストは、次のように述べた。

• 組み込みソフトは、開発者側がユーザーニーズを予測してつくるタイプなのでうまくコントロールできる。
• 今までソースコードレベルや設計レベルまでしか再利用されていなかったものを、どういう分析プロセスを通って出てきたかというところまで含めて再利用できるようにするのが、複雑性に対処する一番の道である。
• これから必要になるのは標準のようなもので、その標準の上にソフトウェアやシステムができれば、もとは複雑でも見方によっては、たいへん単純なものになっていくだろう。

---

■参考文献

• [1]www.cs.ucl.ac.uk/staff/A.Finkelstein/papers/lascase.pdf
• [2] OMG がBPDM、BPMM、金融フレームワーク標準化で前進
  www.object-report.jp/bptrends/BPTrends_OMG_bpdm_20070724.pdf