こんにちは。QAチームの尾尻です。

　先日、日本科学技術連盟主催のソフトウェア品質シンポジウム2011（SQiP2011）に参加してきました。私が受講したのは、要求工学に関するチュートリアルでした。今回はチュートリアル内容を中心に要求工学に関して簡単にまとめたいと思います

要求工学入門：要求工学知識体系と要求獲得プロセス
中谷　多哉子 氏（筑波大学大学院 ビジネス科学研究科 准教授）

　時間の関係で半日チュートリアルしか参加できませんでしたが、実践的な内容でとても参考になりました。 今回はそのチュートリアルの内容を中心に、要求工学に関して以下３項目にまとめたいと思います。

1. 要求工学の定義
2. ソフトウェア要求仕様書（SRS）と曖昧性の排除
3. 要求工学をどのように活用するか

　チュートリアルの内容を書く前に、要求工学の定義に関して簡単に説明したいと思います。要求工学と聞くと、なんだか堅苦しい印象を持つ方も多いのではないでしょうか？

　ITProから要求工学の定義を引用すると、

システム構築におけるユーザーの要求を、科学的に定義するための方法や考え方の総称。"ユーザーは何が目的なのか"、"どういった機能が必要なのか"といった要求をまとめ、それをシステムに正しく反映させる手法全般を対象にする。主な領域は、システム構築の最上流工程である要求定義の手法だが、それ以外にも、要求の変更を管理する手法や、要求が適切に反映されているかどうか検証する手法を含む。

と記載されています。

　よく読んでみると、要求工学とは単純にソフトウェア制作における問題解決（主に要求分析とその整合性や正当性の評価）の手法を形式としてまとめたものであることが分かります。

　さらに噛み砕いて説明すると、ソフトウェアを作るということの本質は、ある問題に対する解決策を提供することに他ならず、ソフトウェアの要求を定義するということは、その解決したい問題がなんであるか、どうやったら利用者の不満を解消し、よりよい世界を実現することができるか、を明らかにすることだといえます。

書籍『ライト、ついてますか ― 問題発見の人間学』から、ある問題解決の例を紹介したいと思います。（文字数の関係で一部設定を変えてあります）

エレベータの話

あるビルのオーナーは毎朝エレベータの前に長い列ができ、ビルの利用者から苦情が出ることに悩んでいました。

そこでオーナーは、コンサルタントのAさんに解決策を相談したところ「エレベータを増やしてください」と言われました。困ったオーナーは、今度はコンサルタントのBさんに解決策を相談したところ、Bさんはエレベータの前で一日中利用者を観察していました。

後日Bさんから、解決策を見つけてすでに実施したと報告を受けたオーナーは、確かに苦情がぴたりと止んだことに驚きました。

オーナーはBさんにどうやったのか聞きました。
するとBさんは、「エレベータホールの壁に鏡を付けました」と答えました。

MySpaceの設計方法

利用者は、鏡を見て身だしなみなどを整えながらエレベータを待つことで、イライラせずに待ち時間を有効に活用できるようになったのです。

　結局利用者はエレベータが混んでいることが不満だったのではなく、長い間待たされることに不満を持っていたのです。

　この話の教訓は、要求に対する解決策は、解が一つしかないような単純明快なものばかりではなく、問題の本質をとらえなければ解決できないこともある　ということだと考えます。安易な解決策に飛びつくのではなく、一歩引いて考えることが重要であるという具体例です。

　まとめると要求工学の目的とは「ソフトウェア制作において、人が無意識に行っている活動を分析し体系的にまとめること」、「利用者の要求に沿った価値の高いソフトウェアを提供するための方法を研究すること」だといえます。

　それでは、次に要求の実現方法と非曖昧性に関してまとめたいと思います。

　個人で作るソフトウェアでない限り、システムの設計書が必要になります。では、何もない状態からいきなり設計書が書けるかというと、答えはNoです。なぜなら、前章でも言及した通り「解決すべき問題の本質が明らかになっていないと、解決策（具体的な実現方法）を提供することはできない」からです。そこで重要になってくるのがソフトウェア要求仕様（SRS）です。

　SRSに関しては、以下のサイトに詳細な説明があります。

エンタープライズICT総合誌「ビジネスコミュニケーション」
要求工学 > 第3回 要求仕様

　SRSが満たすべき性質には、明確性、正確性、一貫性などがあります。もし、これらの性質が不十分だとどうなるのでしょうか。

　『要求仕様の探検学―設計に先立つ品質の作り込み』D.C. ゴーズ 他 によると、要求仕様が失敗する原因として以下の項目があります。

1. 矛盾を効率的に管理できていない
2. 設計上の問題を解決するための明確な記述が不足している
3. 曖昧さをなくすことが認識されていない
4. 何に関して誰が責任を持っているのか知られていない
5. 要求のリスクに関する意識が不足している

　この中で特に重要なのは「3.曖昧さをなくすこと」で、チュートリアルでもこの点が強調されていました。

　少し話は逸れますが、人類学者のEdward T. Hallが、high context culture （高文脈型文化）とlow context culture（低文脈型文化）という考え方を提唱しています。

　簡単に説明すると、高文脈型文化のコミュニケーションでは、情報の受け手は不完全な文からでも、その文脈や前後の状況（Context）を元に意味を読み取ることを求められます。これは意味を理解するために必要なことがらが、情報の発信者と受信者の間で共有されていることが前提のコミュニケーション方法といえます。

　反対に低文脈型文化のコミュニケーションでは、文の中に必要な情報が網羅されているため、文脈の理解や前提となる共通認識に関する依存度が低いと言えます。

LPCM 2chは何か

　日本語は典型的な高文脈の言語で、アメリカやヨーロッパなどの低文脈型文化圏の言語に比べて、直接的な表現よりも曖昧な表現が多いとされます。以下の例を見てみましょう。

「こんにゃくは太りません」

　これは決して「こんにゃくさんという人が存在して、彼/彼女が太りにくい体質である」という意味ではありません。日本人であれば「こんにゃくは低カロリーなので、人がたくさん食べても太りにくい」という意味に理解できると思います。これは、「人（主語）がこんにゃく（目的語）を食べる（述語）」かつ「こんにゃくという食べ物は低カロリーであり、食べても太りにくい」という共通認識が無ければ文として成立しません。

　以上のように日本語は高文脈であるために、日本人同士であれば曖昧な文であっても意味が通じてしまうというということが理解できると思います。

　なぜこんな話をしたかというと、この日本語的曖昧さが要求定義や設計を行う上で最大の障害になるからです。

　日本人の設計者であれば、普通は日本語で設計書を書くと思います。このときに、読み手が日本人でかつ社内システムの開発を行う場合など、外部とのコミュニケーションが必要なければ問題は起きにくいです。しかし最近はoffshoring開発など、関係者が必ず日本人だけとは限りません。そのような状況で日本的な高文脈のコミュニケーションを常識だと思い込むと、意思疎通に問題が発生することが容易に想像できます（日本語を別の言語に翻訳したとしても、元の文章が曖昧であれば、翻訳結果が期待した意味になる保証はありません）。また、たとえ日本人どうしでも、仕様理解の前提となる共通認識がずれていれば、仕様の書き手と読み手の理解は一致しません。

　このような高文脈の曖昧性を理解したうえで、要求を仕様化するときの注意点を２つ挙げたいと思います。

Ⅰ なぜ曖昧性を排除する必要があるのかを理解すること

　"曖昧である"とは複数の解釈が可能であるという意味です。では曖昧性の排除がなぜ必要なのか、以下に理由を書きます。

(ア) 曖昧な仕様や要求を解釈した人が、自分の理解が正しいと思っていても、そのこと自体が無意味であるから（つまり曖昧である時点で、それが正しいか否かを客観的に判断できないということ）

(イ) 曖昧な要求に対しては、さまざまな実装が可能となるから（Project Swing）

(ウ) 仕様を解釈するとき、仕様作成者に確認するしか正解を得る術がないという問題が発生するから（そもそも仕様書として成立していない）

　また、上記に加えて仕様作成者自身が曖昧性に気付かない可能性にも注意を払う必要があります。

Ⅱ 自然言語の曖昧性について理解すること（言語依存性の排除）

　自然言語とは私たちが普段日常で文章を書くときに使う表現方法です。仕様書にも"書"という字が含まれるので、 一般的は文章と同様に自然言語で作成することが当然と考える方も多いと思います。

クリックをリッピングする方法

　しかし、曖昧性の排除という観点からは、自然言語はなるべく避けるべきです。自然言語は誰でも書けて、意図を大まかに伝えることに優れる反面、本質的に曖昧である（読み手の解釈に依存する）という問題があるためです。

　それでは、自然言語の代わりに何を使って仕様を表現したらよいのでしょうか？その答えは形式言語です。

　UMLやロジックツリーなどの形式言語（形式表現）はすべての人が理解できるわけではありませんが、本質的に非曖昧です。形式言語は、言語的に解釈することを目的としているわけではなく、ことばに依存しないロジカルな表現をすることに焦点を当てているからです。もちろん、自然言語をすべて排除することは現実的ではないと思いますが、自然言語を使う場合でも誤解を生まないような表現にすることが重要です。（高文脈的な表現を控え、意識して低文脈的な表現を使う）

　まとめると、曖昧性の排除は重要であるが、一方で自然言語を完全に排除すると、かえってわかりにくい仕様書になってしまう危険があります。しかし、自然言語の利用を必要最低限に留め、かつなるべく曖昧性を排除するような書き方をする（低文脈化する）ことで、SRSや設計書の完成度は上がります。更に積極的に形式言語を使って表現することが、目指すべきゴールであると言えます。

　具体的には、SRSや設計書を第三者にレビューしてもらうことで曖昧性の評価ができます。（自分のミスは自分ではわからない）

　最後に要求工学をどのように活用するかに関してまとめたいと思います。

　チュートリアルで学んだことと、関連書籍から得た情報をもとに、要求工学とその応用に関してまとめます。※一部今回紹介していない内容も含まれますが、興味のある方は最後に紹介する書籍などを元に調べてみてください。

・要求工学はソフトウェアを作る意味とその実現方法を理解するための実学である
・要求はその本質を理解することによって、最適な答えを導くことができる
・高文脈な言語と低文脈な言語の違いを理解する
・仕様の曖昧さが、システム開発上の致命的な問題につながることを認識する
・SRSや設計書では自然言語と形式言語を使い分けることが重要である
・レビューを実施することはテストを行うことと同義である
・早期レビューが潜在バグの混入やヒューマンエラーの防止につながる（バグ修正のコストを最小化する）
・要求は常に変化する（開発プロセスの初期段階では、完成時に想定される要求を100％把握することは難しい）
・すべての要求を完璧に満たすことはできない。（要求のトリアージ）
・ゴール思考分析（KAOS など）
・頻繁に変化する要求に対応する方法として、開発手法に焦点を絞ったAgileやXDDPがある。これらが動的手法だとすると、要求分析による問題解決は静的手法といえる
・動的手法と静的手法のどちらか片方だけでは、変化し続ける要求には対応できない（高いパフォーマンスを維持するためには、要求のコントロールと実装方法のコントロールの両方が必要）

　ネットゲームにしろiPhone・Androidアプリにしろ、制作にかけるコストはどんどん下がり、開発期間も短くなってきています。開発プロセスを継続的に改善しない限り、流動的に変化する市場の要求に応じることは難しいと言えます。では離職率を上げずに、高いパフォーマンスを維持し続けるにはどうすればいいでしょうか？ゴールは以下3つに集約できます。

・要求を分析し、正しく表現し、管理できる体制を作ること
・管理された要求に対して、Agileなどの手法を用いて実装と評価を反復できる開発手法を採用すること
・要求定義段階から第三者評価を行い、問題の発生やバグの混入などのリスクをコントロールすること

　たとえばシステムが完成してから要求との比較をするのではなく、V字モデルの上位レベル（要求分析や仕様書のレビュー）にコストをかけ事前チェックを行うことで、結果的にリリースまでのトータルコストを下げることができます。

　そしてソフトウェアテストの観点から一番重要なのは「バグをたくさん発見してその修正結果を確認することは、ユーザーの要求に沿った質の高いソフトウェアを提供することと同義ではない」という点です。

　詳細説明は省きますが、「JSTQB 1.2 テストの一般原則 – 原則7: バグゼロの落とし穴」にもあるように、機能的な欠陥を修正したとしても、それ自体はソフトウェアの価値を保証するものではない　ということにも注意が必要です。（速度、利便性、見た目、セキュリティ、法令順守などの非機能要求に関するリスクは機能テストでは評価できない）

1. 『要求工学知識体系 第１版』 情報サービス産業協会REBOK企画WG
2011/7/4に出版されました。日本初の要求工学に関するガイドラインです。

2. 『ライト、ついてますか ― 問題発見の人間学』D.C.ゴース, G.M.ワインバーグ
先に紹介したエレベータ問題の顛末とその他のエピソードが書かれております。

3. 『パーフェクトソフトウエア』G.M.ワインバーグ
ソフトウェアテストにまつわる興味深いエピソードが多数収録されています。特にソフトウェア開発に関わる人々の心理分析が興味深いです。

4. 『[改訂第2版] [入門+実践]要求を仕様化する技術・表現する技術 -仕様が書けていますか?』 清水 吉男
要求を階層化し振る舞いで表現するUSDMという手法が紹介されております。

5. 『要求仕様の探検学―設計に先立つ品質の作り込み 』D.C. ゴーズ

6. 『成功する要求仕様 失敗する要求仕様』A.M. デービス
要求のトリアージに関して詳細な説明があります。

7. 『「あたりまえ」を疑う社会学 質的調査のセンス』好井 裕明