要求仕様レビュー技法のクロスオーバー試験に基づく評価研究

(1)

Vol. 30, No. 2, December, 2020 95

要求仕様レビュー技法のクロスオーバー試験に基づく

評価研究

谷﨑浩一

（東京工業大学）

Chang Shuang

（東京工業大学）

出口弘

（東京工業大学）要約製品開発プロジェクトにおいて，要求仕様書の考慮漏れに起因する欠陥が後工程で発見されると修正に大きなコストがかかる．要求定義工程で要求仕様書のレビューにより欠陥を検出することが重要である．レビューは製品の振る舞いを机上でシミュレーションし欠陥を発見する行為であり，境界条件の考慮が必要である．従来のレビューではチェックリストやシナリオに基づき仕様書を読む技法が利用されるが，仕様書に記載のない境界条件を考慮することは難しい．この課題を解決するため，境界条件のモデリングの概念を取り入れた，悪条件分析に基づくレビュー技法（ACA）が提案されているが，従来のレビュー技法との比較や有効性の検証は不十分である．本論文では小規模実験に適した試験法であるクロスオーバー試験によって，従来のレビュー技法と ACA の効果を比較した． ACA を用いた場合，重要度の高い欠陥を多く検出できること，費用対効果が大きいことを確認した．また，ACA へのゲーミングの応用について考察した．キーワード：要求分析，要求仕様，レビュー，境界条件，悪条件

1. はじめに

近年，様々な工業製品にソフトウェアが組み込まれ，高機能化・複雑化が進み，製品のリリース前の検証作業にて欠陥を検出する難易度が増している．製品を開発する企業は，ユーザのニーズを満たし他社との競争に勝つために，革新的な製品やこれまで開発したことのない製品の開発にチャレンジしていく必要がある．経験のない製品の開発プロジェクトでは，要求仕様書で考慮すべき事項に漏れが起きやすく，後工程で考慮漏れが判明すると大きな手戻りに繋がる．製品開発プロジェクトにおいて，早期の欠陥検出は手戻りの抑止に繋がるため重要である．製品開発プロセスの上流工程で実施可能な欠陥検出の活動として，ドキュメントのレビューがある．上流工程で定義されるドキュメントである要求仕様書の妥当性を，レビューにより検証する重要性が高まっている．要求仕様書のレビューは，当該仕様に基づいて開発された製品がどのように動作するかを机上でシミュレーションし，仕様の欠陥を発見する行為である（Adrion, Branstad, & Cherniavsky 1982）．そのシミュレーションは，レビュー対象の構造や振る舞いに関するレビューアの認識モデルに基づく．レビューアが仕様書の内容を理解し認識モデルを構築することで，製品，利用者，利用環境の相互作用を想定した複数のシナリオを，人間が机上で実行する形でシミュレーション可能となる．レビューアは製品がどのように動作するか，ユーザがどのように製品を利用するかを想定し，様々なシナリオで机上シミュレーションを実行しながら，各シナリオで発生しうる欠陥を検出し，仕様書への指摘事項を導出する．レビューアが認識モデルを構築する際，製品の機能を理解し，利用者や利用環境といった様々なアスペクトから境界条件を整理することで，多様なシナリオを想定でき，より多くの欠陥を検出できる．対象のモデルを策定するときにそこで扱われる変数は内的に決定できる変数と外的に所与のものとして与えられる変数に分けられる．外的に所与のものとして与えられる変数を一般にモデルの境界条件と呼ぶ．境界条件はモデルの表現する対象に対する環境などの所与の条件を一般に表現している．本研究では所与の外的な変数である境界条件は，対象製品の仕様を決定するために想定され，対象製品の機能に影響を与える外的条件を指す．製品の利用環境やユーザやユースケースなど，仕様を決定するために考慮が必要な，内的に決定できない所与の条件が境界条件に該当する．ソフトウェアを対象製品と捉えた場合は，製品のハードウェアに関連する条件もソフトウェアにとっての所与の外的条件となる．例えば，スマートフォンのアプリケーションがレビュー対象の場合，対象とする OS のバージョンや端末の画面サイズやユーザが端末を持つ向き，利用環境として想定する周囲の明るさや環境音の大きさなどが境界条件として想定される．要求仕様書で考慮されなかった外的条件は要求定義以降の工程でも考慮されず，製品のリリース後に想定外の条件で製品が利用され問題となるケースがある．要求仕様書のレビューでは境界条件の考慮漏れに起因する仕様の欠陥を検出することが重要な課題である．論文 doi: 10.32165/jasag.30.2_95 2020 年 9 月 2 日受付，2020 年 11 月 30 日受理

(2)

従来のレビューでは，レビューアの経験に基づくチェックリストを用いる方法や，レビュー観点を設定する方法が利用されてきた（ISO/IEC 20246 : 2017 2017; 沖汐・誉田・森田・大場・小島・服部・藤原 2017; Basili, Green, Laitenberger, Lanubile, Shull, Sorumgard, & Zelkowitz 1996; Porter, Votta, & Basili 1995）．本論文ではこれらを「従来手法」と呼ぶ．従来手法の一つである Perspective Based Read-ing（PBR）は様々なステークホルダーの視点からレビュー観点を設定することで，網羅的な欠陥の検出が可能となる（Shull 1998; Shull, Rus, & Basili 2000）．従来手法ではチェックリストやレビュー観点の設定方法について議論が行われてきたが，製品の境界条件の整理に関する議論は行われてこなかった．様々な境界条件が与えられた際のシステムの振る舞いを机上でシミュレーションするには，システムの仕様をマクロに見て設計意図を満たしているかという視点から評価するだけでなく，ミクロな視点から境界条件を把握する必要がある（出口 2013a）．仕様書に定義された境界条件を構造化するとともに，仕様書で考慮が漏れた境界条件を補完しモデリングする方法論が求められる．

Tanizaki, Chang, & Deguchi（2018）は，境界条件の想定範囲を超える条件を「悪条件」と呼び，要求仕様書で考慮すべき境界条件をモデリングし悪条件を検討するレビュー手法を提案した．本論文ではこの手法を「悪条件分析（Adverse Conditions Analysis）に基づく要求仕様レビュー技法」と呼び，以降は「ACA」と表記する．悪条件は，境界条件として想定している所与の外的条件の範囲を超える条件であり，所与の外的条件のもとで設計された製品の仕様を満たさなくする要因である．例えば Wiﬁ 通信を行う端末の仕様を設計する場合，所与の条件として標準的な建物環境がまず想定される．これに対して特別な金属遮物などの電波を遮る外的環境が存在した場合に，標準的な境界条件のもとで設計された端末では正常に通信できず，通信可能な距離に関する仕様を満たさなくなる可能性がある．このような，仕様の設計者が想定しなかった悪条件を明らかにすることで，仕様の設計者に対して仕様の修正を促すことができる．一般に，ある製品の仕様に対して境界条件として想定される範囲は，設計者によって異なる場合が往々にしてあり，絶対的な基準を作成することは難しい．ACA においては，ある条件が設計者によって想定された境界条件か否か，あるいは想定外の悪条件か否かはレビューアの主観的判断によって決定される．重要なのは絶対的な基準を作成することではなく，所与の境界条件について理解したうえで悪条件の検討を明示的に行うことで，設計者とレビューアの想定範囲のギャップを議論できるようになることである．仕様の設計およびレビューの段階でこの議論を行うことで，後工程で欠陥が検出され大きな手戻りコストがかかるリスクや，製品の市場リリース後に想定外の条件に起因する欠陥が発生し改修コストがかかるリスクを低減することができる．谷・Chang・出口（2018）は ACA の可用性と有効性を検証するための実験を実施し，レビューの初心者であっても ACA を使用して要求仕様書への有効な指摘事項を導出できたこと，手法を利用しない場合に比べレビューアの考慮範囲が広がり，多くの指摘を導出できたことを報告している．ACA は要求仕様書のレビュー技法として一定の効果があると考えられるが，谷ら（2018）の実験は（1）比較対象が特別な方法を利用しないアドホックレビューである，（2）レビューに投入する時間が実験ごとに異なり，単純に指摘事項の件数を比較できない，（3）同一の被験者がレビューを繰り返し実施しており学習効果の影響を排除できないという問題がある．ACA による要求仕様書のレビューの効果が十分に評価されているとは言えない． ACA は従来手法と異なり境界条件を整理し悪条件を検討するプロセスや詳細なテンプレートを含むことから，従来手法よりも指摘を多く導出できることは当然のように見える．しかし，谷ら（2018）の実験結果では，ACA はレビューアごとに指摘件数のばらつきが大きく，効果を得られない被験者もいた．ACA によるレビューの結果は，レビューアの境界条件を構造化する能力や悪条件に気付く思考力への依存が大きいと考えられ，従来手法よりも指摘の導出効果が高いかは自明でない．また，谷ら（2018）は ACA はレビューの実施に時間を多く要することを実用上の懸念として示している．時間がかかったとしても多くの指摘を導出できれば費用対効果は高くなるが，従来手法よりも費用対効果が高いかは自明でない．本論文は ACA による要求仕様書レビューの効果の評価を目的とする．評価を行うために，従来手法を用いたレビューと ACA を用いたレビューの比較実験を行う．実験では従来手法を用いる被験者群と ACA を用いる被験者群それぞれに要求仕様書のレビューを実施してもらい，結果を比較する．ACA の効果として指摘を多く検出できるか，レビューの費用対効果が大きいかを確認する．以降，2 で従来の仕様書レビューの課題を示し，3 で ACA によるレビューのプロセスを解説するとともに，従来手法と ACA のアプローチの違いを議論する．4 で実験の方法と結果を示し，5 で考察を行う．6 でまとめと今後の展望を述べる．

2. 従来の仕様書レビュー技法の課題

ISO/IEC 20246:2017 ではレビュー技法として，Checklist-based reviewing（CBR），Scenario-ではレビュー技法として，Checklist-based reviewing, Perspective-Based reading（PBR），Role-based reviewing が挙げられている．PBR は Role-based reviewing の 1 つの形式とされるが，事前に欠陥検出のためのシナリオを作成してレビューを行うことから，シナリオベースのレビュー技法に分類されることもある（沖汐ら 2017）．その他のシナリオベースのレビュー技法として，過去に発生した欠陥の情報に基づきシナリオを定義するDefect-Based Reading（DBR）が知られる．シナリオベースのレビュー技法は網羅的な欠陥指摘ができることが報告されている（森崎 2009）．ここで，欠陥検出

(3)

のためのシナリオは前章に記載した机上シミュレーションのシナリオとは異なることに注意が必要である．欠陥検出のためのシナリオは，レビューアが仕様の欠陥を検出するための仕様書のチェック方法を示したものである．PBR におけるシナリオの具体例としては「要求仕様書に記述されたすべての要求に対して，製品の利用者・顧客が製品に期待する内容かどうかを確認する」といった，レビューアが指摘を導出するための行動を示した文章がシナリオとなる．以降，単に「シナリオ」と記載した場合は欠陥検出のためのシナリオを表す．これらの従来手法では，過去の経験や不具合の情報，または利用者や設計者といったステークホルダーの一般的な視点からシナリオを作成する方法が規定されている．レビューアはシナリオに基づきレビューを行う際に暗黙的に境界条件を想定し机上シミュレーションを実施していると考えられるが，明示的に境界条件を整理する方法は規定されていない．境界条件は，過去に類似製品の開発を経験していたり類似製品の不具合の情報があれば従来手法でもチェックリストやシナリオに明示的に含めることができるが，これまで開発したことのない製品を開発する際や当該製品に対する業務経験の浅いエンジニアには考慮が難しい．これらの境界条件を考慮した仕様が要求仕様書で定義されていなかった場合，後工程で仕様の追加や修正が発生し，手戻りや開発の遅延に繋がる．境界条件の考慮漏れに起因する仕様の欠陥をレビューで検出するには，レビューアが仕様書の内容を分析し，レビュー対象の製品ごとに境界条件をミクロなレベルで構造的に整理するアプローチが必要である．しかし，境界条件のモデリングのプロセスを陽に含むレビュー技法は体系化されてこなかった．ユースケースを使用して仕様書を読むレビュー技法として，Usage-Based Reading（UBR）がある（Thelin, Runeson, & Wohlin 2003）．ユースケースとは，利用者が製品やシステムを用いて特定の目的を達するまでの，製品やシステムとのやり取りを表す．ユースケースは複数の境界条件を含み，ユースケースに基づいて仕様書を読み製品やシステムの振る舞いを想定することは，ユースケースを机上シミュレーションのシナリオとして用いて机上シミュレーションを実行する行為と言える．しかし，UBR はユースケースに重要度を付けピンポイントに欠陥を検出する技法であり，様々なアスペクトで境界条件を分析するアプローチに関する議論はない．

3. 悪条件分析に基づく要求仕様レビュー技法

（ACA）

3.1 ACA のプロセスと特徴 前述の従来のレビュー技法の課題を解決するため，谷ら（2018）は ACA を提案した．ACA によるレビューのプロセスを図 1 に示す．レビューアは要求仕様書を読み解き，当該製品で考慮すべき境界条件を Boundary Breakdown Structure（以下，BBS）と呼ぶツリー構造の図で整理する．その後，悪条件を検討し悪条件への対策案を仕様書への指摘事項として導出する． ACA の特徴は境界条件をモデリングするプロセスを陽に含む点と，そのプロセスで利用するテンプレートが定義されている点である．ACA では要求仕様で考慮すべき境界条件の一般的な構造を規定し，テンプレートとしてレビューアに提供する．レビューアはテンプレートを利用し境界条件を整理することで，仕様書に記述されている境界条件だけでなく記述のない境界条件を補完できる． 3.2 ACA によるレビューの手順とテンプレート 後述の実験で利用したテンプレートを示しながら ACA によるレビューの手順を解説する．図 1 の「境界条件の整理」において，レビューアは要求仕様書の記述内容を読み，図 2 のテンプレートを利用し BBS を作成する．レビュー対象の境界条件を分析する枠組みとして，「製品ライフサイクル」，「エージェント」，「システム」，「オブジェクト」，「外部環境」の各ノードが規定されている（Tanizaki et al. 2018）．レビューアは規定のノードは変更せず，矩形のノードをレビュー対象に応じた具体的な値に編集・追加し，境界条件を整理する．境界条件を整理するには，境界条件が影響を与える対象製品の 図 1 ACA によるレビューのプロセス［谷ら（2018）の図 2 を一部修正して引用］

(4)

機能の理解が必要になるため，テンプレートには対象製品の機能に関するノードとして，「ソフトウェア（機能）」のノードが存在する．製品ライフサイクルのノードでは，ライフサイクルのフェーズに応じたユースケースおよび，ライフサイクル全体を通しての製品のトレーサビリティや製品に関する情報の開示方法について整理する．エージェントのノードでは，レビュー対象製品を利用するユーザなど，レビュー対象のステークホルダーを列挙する．システムのノードでは，レビュー対象を構成するハードウェアと，ソフトウェアまたはレビュー対象が有する機能を要素として抽出する．オブジェクトのノードでは，レビュー対象と関連する物体を検討する．外部環境のノードでは温度や湿度などレビュー対象と関連する環境を表現する．組み込みソフトウェア開発における要求仕様分析手法では，分析対象のシステムを構成する要素として機能，ハードウェア構成，環境，運用の 4 つの概念が示されている（三瀬・新屋敷・橋本・鵜林・片峯・中谷 2005）．BBS のテンプレートは同様の要素をカバーしつつ，環境を外部環境とオブジェクトに分けた点，運用に関連する要素をユースケースとして別途詳細に分析する点，時間変化の概念として製品ライフサイクルを取り入れた点が異なるが，要求仕様の分析で考慮すべき境界条件のメタな構造を表す．境界条件に関する議論として出口（2013b）は，システムや制度の設計では当該の問題状況に関連する様々な境界条件に応じ，複数の視点からモデルを構築する必要があると論じた．BBS のテンプレートで規定されたノードが，境界条件を整理する際の視点として機能する．図 1 の「ユースケースの特定」について，谷ら（2018）は「BBS で抽出したエージェントごとに，レビュー対象を利用する目的，場所，時間，使い方を別途整理する」と報告しており，ユースケースは複数の境界条件に分解して整理できる．しかし，谷ら（2018）ではこれらの境界条件を整理するテンプレートは示されていない．本論文では図 3 に示す 5W1H の構造のテンプレートを作成した．What はレビュー対象製品，Who はエージェントと捉え，当該エージェントのユースケースごとに，レビュー対象製品を利用する目的（Why），利用する場所（Where），利用する時間（When），使い方（How）を記載する．ユースケースの記法としてユースケース図やユースケース記述が一般的に知られるが，これらの記法では 5W1H のうち Where, When が明示的に表現されない．谷ら（2018）の報告にあるように製品を利用する場所や時間に起因して悪条件が発生する可能性があるため，本論文では 5W1H のテンプレートを採用した．レビューアは，BBS のテンプレートと同様に図 3 の矩形のノードに具体的な値を代入することでユースケースを整理する．ユースケースは BBS で洗い出したエージェントごとに整理する．同一のエージェントが複数のユースケースを持つ場合は，「ユースケース名」以下のノードを複数作成する．図 1 の「悪条件の導出」において，レビューアは表 1 に示すガイドワードを参考に，BBS およびユースケースから悪条件を検討する．Tanizaki et al.（2018）は悪条件を導出するためのガイドワードを提案した．Tanizaki et al.（2018）のガイドワードはケーススタディから経験的に導出したものであり，妥当性や十分性についての議論は十分にされておらず，拡張の余地がある．Tanizaki et al.（2018）のガイドワードはハードウェア，外部環境，オブジェクト，ユースケースという 4 つの悪条件の発生源に関連付けて整理されている．ユースケースについては，利用する場所や時間，ステークホルダーのアクションに関連するガイドワー 図 2 BBS のテンプレート［谷ら（2018）の図 3 を引用］ 図 3 ユースケースのテンプレート

(5)

ドしか提示されていない．図 3 の「利用目的」および「ステークホルダーの属性」に関するガイドワードは筆者が独自に表 1 に追加した．元来，ガイドワードは HAZOP や STAMP/STPA などのハザード分析の手法で利用され，設計意図からのずれや非安全な状態を引き起こす要因を検討するためのヒントになる語を指す．IEC 61882:2016 では HAZOP で利用するガイドワードとして，「無（no）」，「逆（reverse）」，「他（other than）」，「大（more）」，「小（less）」などが示されている．Leveson（2012）により STAMP/STPA で利用するガイドワードとして，「必要なコントロールが与えられない（Not Providing）」，「非安全なコントロールが与えられる（Providing）」，「誤ったタイミングや順序（Wrong timing or order）」などが示されている．HAZOP は主に化学プラントにおけるハザードの分析を対象としており，ソフトウェアを含む製品の分析に向いていない．Pumfrey（1999）や河野（2012）はソフトウェア製品向けに整理したガイドワードを提案しているが，ガイドワードと境界条件の構造との紐づけに関する議論はない．STAMP/STPA はコントロールストラクチャーを作成し要素間の相互作用に着目した分析を行うが，要素として洗い出すべき境界条件の構造は規定がない．ACA のガイドワードは，HAZOP や STAMP/STPA

のガイドワードを参考に BBS およびユースケースのテンプレートの構造に合わせて具体化したものであり，要求仕様書のレビューに適用しやすいものとなっている．図 1 の「要求仕様への指摘の導出」では，レビューアは悪条件と要求仕様書の記述を照らし合わせ，現状の仕様で問題ないか検討し，問題のある仕様の改善案や悪条件への対策案を指摘事項として導出する．ACA では対策案を導出するための補助として，表 2 に示す悪条件への対策案のサンプルをレビューアに提供する．表 2 は Tanizaki et al.（2018）が提案したフィードバック項目をベースに，レビューアが利用しやすいように谷ら（2018）が悪条件への対策のタイプと対策のポイントごとに抽象的な対策案を整理したものである．レビューアは表 2 を参考に悪条件への対策案を検討する．例として，後述の実験でレビュー対象とした「パン自動会計システム」では，学習データに基づく画像認識によりパンの種類を自動判別する機能を備えるため，機能の実行 表 1 悪条件導出のガイドワード ［Tanizaki et al.（2018）の表 5 を元に筆者が一部追加］ 表 2 悪条件への対策案のサンプル ［谷ら（2018）の表 2 を引用］

(6)

に影響を及ぼす境界条件として，判別するパンの焼き加減や店内の明るさが考えられる．これらは BBS のテンプレートの「オブジェクトの属性」と「環境因子」に該当する．悪条件としては，パンの焼き加減がバラバラなことや，店内の明るさが店舗ごとに異なることが考えられる．これらは，悪条件導出のガイドワードの「オブジェクトの属性が規定の範囲を超える」，「規定にない属性の影響を受ける」，「規定の環境条件の範囲を超える」，「規定にない環境条件の影響を受ける」をもとにレビューアが検討する．仮に，要求仕様書で店内の明るさの許容範囲や，明るさをえるための照明の指定等が記載されていなければ，それらの考慮が必要なことを指摘することで，仕様書で考慮されていなかった境界条件をレビューアが認識し仕様の改善案を指摘として導出したことになる．

4. 要求仕様書のレビュー実験

4.1 クロスオーバー試験による実験方法 製品開発現場での要求仕様書のレビューを模した実験を行い，従来手法によるレビューの結果と，ACA によるレビューの結果を比較することで，要求仕様書レビューに対する ACA の効果を評価する．レビューの効果を測る指標としてレビュー実施の工数当たりの指摘件数や，レビュー対象の規模ごとの指摘件数が一般的に使われるほか，レビューで検出された欠陥が見逃された場合の修正コストを試算し指標とする方法が提案されている．小池ら（2007）は修正コストを考慮した指標として「修正規模の金額効果」を算出する方法を提案しており，レビューの費用対効果を金額に換算することができる．本論文では定量評価として指摘件数および修正規模の金額効果を従来手法と ACA で比較し，（1）指摘を多く検出できるか，（2）費用対効果が大きいか，の 2 点を評価する．さらに定性評価として，提案手法の効果を被験者がどのように感じたか，被験者へのアンケートとインタビューにより確認する．実験全体の流れは図 4 に示すクロスオーバー試験の形式とした．クロスオーバー試験は少数の被験者により 2 つの手法の効果を検証する試験方法として標準的に確立された手法で，新薬の効果の比較などエビデンス重視の臨床研究で用いられる試験方法である（折笠 2016）．クロスオーバー試験では，手法の使用順序を入れ替えて 2 回の適用を行うことで，少数の被験者で 2 回分のデータを得ることができる．本研究におけるレビューの結果は被験者の能力への依存を避けることが難しく，1 回のみの比較実験では，結果に差が生まれたとしても比較すべき技法によるものか，被験者の能力によるものか結論付けることができない．クロスオーバー試験ではレビュー技法の使用順序を入れ替えて 2 回レビューを実施することで，被験者の能力差による要因を除去することができる．本研究ではクロスオーバー試験をレビューに適用することで 2 つのレビュー技法の比較をレビューアの能力差に依らない形で行うことを可能とした．比較対象の従来手法は，ISO/IEC 20246:2017 にて「もっとも効果的で効率的なレビュー技法」とされる PBR を選択した．PBR は網羅的な欠陥検出を可能とする手法であり，境界条件の考慮漏れを検討するプロセスは明示的には含まれていないが，境界条件の考慮漏れに起因する仕様の欠陥も検出の対象となる．実験の被験者として，システム・製品検証の専門会社である V 社のエンジニア 14 名の協力を得た．被験者数に関して，PBR と他の技法の比較実験を行った Basili（1996）は，時間とコストの制約から 12∼18 名の被験者が妥当であると報告している．本論文の実験の被験者数は，2 つのレビュー技法の比較実験を行ううえで，過去の研究と同等と言える．なお Basili（1996）の実験はクロスオーバー試験の形式をとっていない．表 3 に本論文の実験と Basili（1996）による実験の比較を示す．Basili（1996）では 2 グループとも 1 回目のレビューでは比較対象のレビュー技法を使用し，2 回目のレビューで調査対象である PBR を使用している．この実験方法では表 3 に矢印で示したように，各グループ間で交差するように結果を比較する．すなわち，2 つの技法を知っているグループと，1 つの技法しか知らないグループの間でレビュー結果を比較することになる．各試行で使用したレビュー技法以外に，もう一方のレビュー技法を知っているか否かという差が生じ，レビュー結果へ予期しない影響を与えることが懸念される．これに対し本研究では，レビュー技法の効果を比較するためにクロスオーバー試験を導入した．クロスオーバー試験では表 3 に矢印で示 図 4 実験全体の流れ 表 3 本論文と Basili （1996）の実験の比較

(7)

したように 1 回目と 2 回目それぞれ，グループ 1 とグループ 2 の間で結果を比較する．1 回目はいずれのグループもその時に使用したレビュー技法しか知らない状態，2 回目はいずれのグループも 2 つのレビュー技法を知った状態となる．1 回目・2 回目ともに各試行で使用したレビュー技法以外に差がない状態で結果を比較できる．このようにクロスオーバー試験ではレビューアの知識の差による結果への影響を与えにくい形で評価が可能であり，この形式が適切と言える．被験者を 7 名ずつの 2 グループに分け，各被験者が個人でレビューを実施しレビュー対象の仕様書への指摘事項を導出した．被験者はシステム・製品検証に関する業務経験年数が 1 年∼23 年だった．グループごとの検証業務経験年数の平均値，中央値，標準偏差を表 4 に示す．平均値はグループ 1 とグループ 2 ともに 8 年前後で同程度だった． 4.2 実験手順 実験のタイムテーブルを表 5 に示す．まず被験者に対し筆者らがレビュー技法の訓練を 120 分間実施した．訓練では，筆者らがレビュー技法の使い方を説明したうえで，訓練用に用意した仕様書を用いて被験者にレビューの演習を実施してもらった．その後，実験用の仕様書を被験者に渡し，考えつく指摘事項をすべて導出し終わるまで個人レビューを実施してもらい，各被験者が指摘事項の一覧表を作成した．レビューの開始前に，レビューの目的として「要求仕様書がこれから製品開発を進めるにあたって妥当なものになっているかをレビューすること」を口頭および紙面で被験者に伝えた．要求仕様書が妥当であることの定義は，「この要求仕様書に基づいて製品開発するとエンドユーザにとって有用な製品が出来上がること」とした．各手法を使って，仕様が妥当でなく修正や再検討が必要であるとレビューアが考えた指摘をすべて導出してもらった． 1 回目，2 回目ともにレビュー実施の完了後，被験者にアンケートに回答してもらった．実験が完了した後，ACA について被験者にインタビューした．レビュー対象の仕様に関して学習効果を生じさせないように，1 回目のレビューと 2 回目のレビューでは異なる仕様書をレビュー対象とする必要がある．1 回目のレビューではパン自動会計システムの要求仕様書，2 回目のレビューでは腕時計型通信端末の要求仕様書をレビュー対象とした．いずれの仕様書も日本語による要求仕様の記述と，製品の外観や画面イメージ等の図から構成されている．実務に近い形とするため，仕様書に意図的に欠陥を埋め込むことはしなかった．各仕様書の特徴を表 6 に示す．パン自動会計システムの要求仕様書は，実際の製品を参考に筆者らが実験用に作成した要求仕様書である．このシステムはパン屋のチェーン店における会計業務の効率化を目的とし，画像認識によりパンの種別を自動識別して料金をレジへ自動入力する．日本語での要求事項の記述が約 2300 字，画面イメージが 15 個，画面の一覧表および画面遷移図が各 1 個，表紙および更新履歴が各 1 ページであり，全体では A4 サイズで 14 ページだった．腕時計型通信端末の要求仕様書は V 社の研修用に作成された要求仕様書である．この製品はスマートフォンと接続して音声通話やビデオ通話を行うことができ，BtoC にて販売される製品である．日本語での要求事項の記述が約 2000 字，外観図が 4 個，表紙および目次と更新履歴が各 1 ページであり，全体では A4 サイズで 7 ページだった．パン自動会計システムの仕様書は具体的な画面イメージを含み，機能の振る舞いが詳細に記述されていた．腕時計型通信端末の仕様書は抽象的な外観図があるのみで，機能の振る舞いは概要的な記述が多く，利用シーンや考慮すべき境界条件があいまいだった． PBR でレビューを行う際は表 7 に示すレビュー観点を被験者に提供し，レビュー観点に基づいて仕様書を読んで指摘事項の一覧を作成してもらった．表 7 は，岡本・内山・鈴木・高橋・西山・野中（2004）が「利用者／顧客」，「設計者／開発者」，「テスト担当者」の 3 つの視点で整理したレビュー観点をベースに，筆者が一部修正したものである．岡本ら（2004）の実験では，要求仕様書の上位文書としてニーズ記述書が存在し，ニーズ記述書と要求仕様書を比較するレビュー観点が存在したが，実際の開発現場ではニーズ記述書が必ずしも存在しないことから本実験では 表 4 システム・製品検証業務の経験年数 表 5 レビュー実験のタイムテーブル 表 6 レビュー対象の仕様書の特徴

(8)

ニーズ記述書は用意せず，該当するレビュー観点は除外した．PBR は担当者ごとに視点を割り振ってレビューすることで指摘の重複を減らす効果があるが，本実験では個人レビューにおいてレビューア一人ひとりが指摘できた件数や考慮できた範囲を ACA と比較するため，各被験者がすべての視点を順に考慮してレビューを行った．ACA でレビューを行う際は，図 2，図 3，表 1，表 2 を被験者に提供し，3.2 節で解説した手順に沿ってレビューを行い指摘事項の一覧を作成してもらった．レビュー実施後のアンケートは，レビュー時に考慮した範囲とレビュー技法の実務での活用について 5 段階の選択肢から 1 つを選択する形式とした．考慮範囲に関するアンケートでは，表 1 で悪条件の発生源として定義された「ハードウェア」，「オブジェクト」，「外部環境」，「ユースケース」を対象とし，それぞれに対して「悪条件を考慮してレビューを行いましたか？」という質問項目を作成した．回答選択肢は「明確に考慮した」，「なんとなく考慮した」，「どちらとも言えない」，「あまり考慮しなかった」，「まったく考慮しなかった」とした．レビュー技法の実務での活用に関するアンケートでは，「本日使用したレビュー技法を業務で活用したいと思いますか？」という質問項目を作成し，「非常にそう思う」，「そう思う」，「どちらとも言えない」，「思わない」，「まったく思わない」を回答選択肢とした．実務での活用に「非常にそう思う」か「そう思う」と回答した被験者には，理由を問う質問に追加で回答してもらった．回答選択肢は「指摘の途中経過を含めて顧客に説明しやすそうだから」，「普段思いつかない指摘を思いつくことができそうだから」，「指摘の漏れを減らせそうだから」，「重要な指摘を出せそうだから」，「レビューの時間を短縮できそうだから」，「その他」とした． 4.3 実験結果 ACA の成果物の具体例として，ある被験者が作成した BBS と悪条件の一部を図 5 に示す．エージェントとして「高齢者」，「子供」，オブジェクトとして「手袋」，「トレイ」，「コンセント」，外部環境として「明るさ」などが境界条件として識別された．各ノードに対する悪条件は図 5 に斜体で記載しており，「視力が悪く，文字が見えない」，「背が小さく，ディスプレイが見えない」，「手袋をつけてタッチ操作する」，「白色以外のトレイを使った」，「コンセントの長さがギリギリで，抜けてしまう」，「室内環境によって画面が見づらい」などが導出された．これらの悪条件を元に被験者が作成した指摘一覧を表 8 に示す．表示フォントの変更，ディスプレイの角度の変更，画面の輝度の調整といったユーザや利用環境を考慮した仕様の改善案，急に電源が落ちた場合などの異常系に関する対策，ユーザが手袋をしている場合のタッチ操作の可否や，使用可能なトレイの条件といった，仕様で考慮が不足していた 図 5 実験で作成された BBS と悪条件の一部 表 7 PBR のレビュー観点 ［岡本ら（2004）の付録 F を元に筆者が一部修正］

(9)

利用時の制約が指摘事項として導出された．指摘件数の集計結果を表 9 に示す．集計にあたり指摘を有効なものと無効なものに分類した．無効と判断した指摘は，（1）製品の仕様から大きく逸脱する改善案，（2）誤字脱字や文章の分かりにくさといった文章表現に対する指摘，（3）仕様の内容の認識が正しいか確認するための単なる質問，（4）指摘ミス，である．（1）について，レビュー対象の境界条件から大きく逸脱する改善案は，実際の製品開発プロジェクトにおいても採用されないため無効とした．（2）は誤読を生む可能性があるため実際の製品開発プロジェクトでは修正するのが望ましいが，表現の問題であり仕様の内容の問題ではないことから無効とした．（3）はレビューアが仕様に対して疑問を持ったことから仕様書の文章表現に何らかの問題がある可能性があるが，レビューアによる仕様の内容の認識は正しかったため問題ないと判断した．（4）について，仕様書に記載のある内容に関して「記載がない」と指摘した場合や，同内容の指摘を重複して記載した場合は指摘ミスとして集計から除外した．表 9 より 1 回目，2 回目ともに指摘件数の平均値，中央値は PBR と比較して ACA の方が高かった．ACA は指摘件数の標準偏差が大きく，被験者によるばらつきは大きかった．レビュー実施時間は PBR よりも ACA の方が長かった．並べ替え検定により PBR と ACA の指摘件数の平均値差の 検定を行った結果，1 回目のレビューでは p=0.339, 2 回目 のレビューでは p=0.042 となり，2 回目のレビューの指摘 件数は 5% 水準で有意差があった．被験者が導出した仕様書への指摘を 3 段階の重要度で分類し，重要度ごとの指摘件数の平均値を集計した．重要度の定義を表 10 に，集計の結果を表 11 に示す．要求仕様書で考慮が漏れた境界条件が後工程で検出されると大きな手戻りに繋がること，境界条件を構造的に整理しないと検出が難しいことから，仕様書で考慮されていなかった境界条件を考慮した改善案の重要度を「高」とした．仕様書で考慮されている境界条件の範囲内であっても，製品として必要な機能の定義が漏れると後工程で手戻りが発生することから，製品として必要な機能の定義不足に関する指摘の重要度を「中」とした．要求仕様書で機能自体が定義されていれば詳細な動作条件や設定値等は後工程でも議論可能であり手戻りの影響が小さいことから，仕様書で定義されている機能の動作条件や設定値等の定義不足に関する指摘の重要度を「低」とした．各重要度に該当する指摘の例として，パン自動会計システムのレビュー結果では「セール品などの割引販売時に割引料金を計算できる機能がないため追加してはどうか」という指摘が導出されたが，「割引販売」という境界条件は仕様書に記載がなかったことから，この指摘の重要度は「高」とした．別の指摘の例として「消費税率を変更する際の設定方法について説明がない」という指摘が導出された．「消費税率の変更」という境界条件は仕様書に記載されていたが，具体的な変更手順の定義がなかった．製品として必要な機能を明確に定義するには変更手順の定義は必 表 8 実験で作成された指摘一覧の一部 注：白色のトレイを使用する旨が仕様書に記載されていた 表 9 実験結果の概要 表 10 重要度の定義 表 11 重要度別の指摘件数の平均 ※単位は「件」．p 値は並べ替え検定により算出．

(10)

要なため，この指摘の重要度は「中」とした．腕時計型通信端末のレビュー結果では「電池残量を 3 段階で表示する際の，残量の閾値の数値が定義されていない」という指摘が導出されたが，「電池残量」という境界条件は定義されており，具体的な閾値の定義が不足していたのみだったため，この指摘の重要度は「低」とした．表 11 から，1 回目・2 回目のレビューともに PBR より ACA の方が重要度「高」・「中」の指摘件数の平均値は高かった．重要度「低」の指摘件数の平均値は PBR の方が高かった．並べ替え検定により PBR と ACA の指摘件数の平均値差の検定を行った結果，重要度「高」の指摘の 1 回目 のレビューは p=0.880, 2 回目のレビューは p=0.001 とな り，2 回目のレビューは 1% 水準で有意差があった．重要 度「中」の指摘の 1 回目のレビューは p=0.101, 2 回目のレ ビューは p=0.374 となり，5% 水準で有意差はなかった． 重要度「低」の指摘の 1 回目のレビューは p=0.010, 2 回目 のレビューは p=0.851 となり，1 回目のレビューは 1% 水 準で有意差があった． PBR と ACA の重要度別の指摘件数の分布を図 6 に示す．重要度が「高」と「中」の指摘は，1 回目・2 回目のレビューともに ACA の方が指摘件数は多い傾向が見られた．重要度が「低」の指摘は，1 回目のレビューでは PBR の方が指摘件数は多い傾向が見られたが，2 回目のレビューでは PBR と ACA の指摘件数の差は小さかった． 4.4 修正規模の金額効果の算出結果 修正規模の金額効果は，「修正範囲に関するポイント」，「発見工程に関するポイント」，「単位ポイントあたりの修正工数」，「時間単価」の積により算出できる（小池ら 2007）．修正範囲に関するポイントは表 12 の定義に従った．小池ら（2007）は修正範囲に関するポイントを，欠陥を修正する際の影響範囲によりランク分けした．本論文では指摘の分類として表 10 の重要度を用いている．重要度が高いほど仕様作成時に考慮していなかった境界条件を仕様に取り込む必要があり，修正する際の影響範囲が広くなると想定される．そこで，本論文における指摘の重要度の「高」「中」「低」が，小池ら（2007）による修正範囲のランクの「大」「中」「小」に該当するものとした．発見工程に関するポイントは小池ら（2007）により，要求定義工程は 5，詳細設計工程は 2，コーディング工程は 1 と定義されている．本実験は要求定義工程における要求仕様書のレビューが対象のため，発見工程のポイント数は 5 とした．小池ら（2007）の試算に基づき，単位ポイントあたりの修正工数は 4 時間，時間単価は 5,000 円とした．表 11 に示した重要度別の指摘件数の平均値をもとに，修正規模の金額効果を算出した結果を表 13 に示す．コストは，表 9 のレビュー実施時間の平均値と時間単価 5,000 円の積から算出した．修正規模の金額効果はレビューを実施したことによりプロジェクトで支払わなくて済んだ費用であり，コストはレビューを実施するためにプロジェクトで追加で支払った費用である．これらの差を取ることでプロジェクト全体としてどれだけの費用を節約できるか算出できるため，金額効果からコストを引いた値をレビューの費用対効果と考え，表 13 に示した．PBR より ACA のほうがコストはかかるが，費用対効果も大きかった． 4.5 アンケートの集計結果 レビュー時の考慮範囲に関するアンケートの集計結果 図 6 重要度別の指摘件数の分布 表 12 修正範囲とポイント ［小池ら（2007）の表 3 を元に筆者が作成］ 表 13 レビューの費用対効果

(11)

を表 14 に示す．表 14 では，5 段階の回答選択肢を「明確に考慮した =5 点」，「なんとなく考慮した =4 点」，「どちらとも言えない =3 点」，「あまり考慮しなかった =2 点」，「まったく考慮しなかった =1 点」として被験者の回答を点数に置き換え，平均値を算出した．1 回目・2 回目のレビューともにすべての悪条件の視点で PBR より ACA の 方が平均点が高かった．並べ替え検定により p 値を算出 した結果，2 回目のレビューの「ハードウェアの悪条件」 は p=0.001，「オブジェクトの悪条件」は p=0.002，「外 部環境の悪条件」は p=0.003，「ユースケースの悪条件」 は p=0.009 となり 1% 水準で有意差があった．1 回目のレ ビューでは，いずれの悪条件の視点も 5% 水準で有意差はなかった．レビュー技法の実務での活用に関するアンケートの集計結果を表 15 に示す．各選択肢を選んだ人数について，1 回目と 2 回目のアンケート結果を合計した．「非常にそう思う」，「そう思う」，「どちらとも言えない」を選んだ被験者が PBR と ACA で同数となり，「思わない」，「まったく思わない」を選んだ被験者はいなかった．実務での活用に関するアンケートで「非常にそう思う」か「そう思う」を選んだ被験者に，理由を質問した結果を図 7 に示す．該当する選択肢をすべて選んでもらい，のべ人数を集計した．ACA は「指摘の途中経過を含めて顧客に説明しやすそうだから」を選んだ被験者がのべ 6 名でもっとも多く，PBR は「指摘の漏れを減らせそうだから」を選んだ被験者がのべ 6 名でもっとも多かった．次に多かったのは，ACA は「普段思いつかない指摘を思いつくことができそうだから」，「指摘の漏れを減らせそうだから」を選んだ被験者が各のべ 4 名，「重要な指摘を出せそうだから」を選んだ被験者がのべ 3 名だった．PBR は「普段思いつかない指摘を思いつくことができそうだから」，「重要な指摘を出せそうだから」を選んだ被験者が各のべ 4 名，「指摘の途中経過を含めて顧客に説明しやすそうだから」を選んだ被験者がのべ 3 名だった．PBR は「レビューの時間を短縮できそうだから」を選んだ被験者が 1 名いたが，ACA はこの選択肢を選んだ被験者はいなかった．

5. 考察

5.1 ACA の効果 表 11 および図 6 から重要度が「高」と「中」の指摘は PBR に比べ ACA の方が多く検出できており，仕様書で考慮されていない境界条件に関する指摘や製品として必要な機能の定義漏れに関する指摘を ACA によって多く検出できたと言える．特に 2 回目のレビューにおける重要度が「高」の指摘件数は 1% 水準で有意差があり，ACA の方が明らかに多く指摘を検出できている．表 14 から 1 回目・2 回目ともに ACA の方がレビュー時の考慮範囲の平均点が高く，レビューアが境界条件を明確に意識してレビューできている．ACA を使用することでレビューアの考慮範囲が広がり，重要度が「高」の指摘が多く検出されたと考えられる．表 14 から 1 回目のレビューでは PBR と ACA の考慮範囲の平均点に有意差はなく，2 回目のレビューでは有意差があった．レビュー対象の仕様書の記述の詳細さが影響したと考えられる．表 6 より 1 回目のレビュー対象であるパン自動会計システムは利用者や利用シーンが限定的かつ仕様書の記述が詳細だった．1 回目のレビューでは PBR を利用した場合でも，レビューアが仕様書に記述された境界条件は考慮できたと考えられる．2 回目のレビュー対象である腕時計型通信端末は不特定多数により利用されるため利用シーンが不明確かつ仕様書にあいまいな記述が多かった． 2 回目のレビューでは境界条件の整理のプロセスを陽に含む ACA の効果がより強く生じたと考えられる．仕様書に記載されている境界条件はレビュー技法に関わらず考慮し 表 14 レビュー時の考慮範囲に関するアンケート結果 ※単位は「点」．p 値は並べ替え検定により算出． 表 15 実務での活用に関するアンケート結果 図 7 レビュー技法を実務で活用可能と思った理由

(12)

やすいが，後工程で大きな問題に繋がるのは，仕様書に記載されていない想定外の外的条件である．BBS を作成し悪条件を検討することで仕様書に記載のない外的条件を考慮することは，腕時計型通信端末のように利用シーンが多岐にわたる製品がレビュー対象である場合や，開発の初期段階など仕様書の記述が詳細化しきれていない場合など，境界条件の考慮漏れが発生しやすい状況で効果的なアプローチだと言える．境界条件の考慮漏れが発生しやすいという点で，新製品を開発する場合や経験の浅いエンジニアが要求仕様書の作成に携わっている場合にもこのアプローチは有効であると考えられる．表 11 および図 6 から重要度が「低」の指摘，すなわち仕様書で定義済みの機能の動作条件や設定値等の定義漏れは，ACA より PBR の方が多く検出できている．特に 1 回目のレビューにおける重要度が「低」の指摘件数は 1% 水準で有意差があり，PBR の方が明らかに多く指摘を検出できている．1 回目のレビュー対象は仕様書の記述が詳細だったため，記述されている仕様に対してレビュー観点を照らし合わせる PBR のアプローチにより，詳細な動作条件や設定値等に関する指摘を検出しやすかったと考えられる．仕様書に記述されている境界条件の内部を詳細に確認する際は，従来手法のアプローチが効果を出しやすいと考えられる． ACA と PBR は背反するものではなく，レビューの狙いに合わせて使い分けが可能と考えられる．新製品の開発時や要求定義の初期段階など境界条件の考慮漏れが懸念される場合は，ACA を使用して考慮すべき境界条件を明確にし，製品として必要な機能や考慮すべき境界条件に漏れがないか確認すると良い．そのうえで，PBR で詳細な仕様の定義を確認していくといった併用の方法が考えられる．表 9 から ACA のレビューにかかる時間は PBR の 2∼3 倍程度に増加しているが，費用対効果は表 13 から ACA の方が大きい．上流工程で指摘を導出するほど費用対効果は高くなるが，上流工程であるほど境界条件が不明確な場合が多く従来手法のアプローチでは指摘を導出できる範囲が限定される．ACA は仕様書の記述があいまいな場合でも想定外の境界条件を考慮し重要度の高い指摘を導出できるため，大きな費用対効果に繋がったと考えられる．表 15 からレビュー技法の実務での活用に関して，被験者の主観評価では PBR と ACA で差はなかった．図 7 から ACA を実務で活用可能と考えた理由で最も多かったのは「指摘の途中経過を含めて顧客に説明しやすそうだから」であり，PBR よりも ACA のほうがこの選択肢を選んだ人数が多かった．ACA では BBS 等の中間成果物の作成により，レビュー対象に対するレビューアの認識モデルが可視化され，指摘を導出する思考過程が可視化されるため，他者へレビュー結果を説明しやすくなるという評価を被験者から得られたと考えられる．レビューアの認識モデルを可視化できることは，他のレビューアや設計者の認識モデルとの差を議論し，レビューの妥当性確認やレビュー結果の振り返りに有用である．経験の浅いレビューアがレビューの思考過程を学習する際にも活用できると考えられ，教育面での効果も期待できる．図 7 から PBR を実務で活用可能と考えた理由で最も多かったのは「指摘の漏れを減らせそうだから」であり， ACA でこの選択肢を選んだ人数は PBR よりも少なかった． ACA は様々な境界条件を考慮できるが，指摘を導出する際の視点は悪条件に限定している．PBR は様々なステークホルダーの視点で網羅的に指摘を導出できるため，指摘の漏れを減らせるという被験者の評価に繋がったと考えられる．しかしながら，ACA においても 4 名の被験者から「指摘の漏れを減らせそうだから」という回答を得ており，指摘の漏れを減らす効果について一定の評価は得られたと言える．実験後に ACA について被験者にインタビューしたところ次のような意見が得られた．・ACA は使いこなすのが難しい反面，使いこなせれば効果的な武器になるだろう・実験後に，異常状態に対して対策が立てられているかチェックするという視点をテストにも組み込んだところメンバーの視野を広げることができたように思う・悪条件だけでなく製品の価値やユーザにとって良いことを考えるという視点も必要ではないか悪条件を考慮することが有用であるという意見があった一方，それだけではレビューの視点として不十分ではないかという意見があった．沖汐ら（2017）は「レビューの効果を高めるためには，利用者が適材適所でレビュー技法を選び適用することが求められる」と述べている．1 つのレビュー技法であらゆる指摘を導出できるものではなく，レビュー技法のアプローチの違いによって生じる指摘の傾向を把握したうえで，レビュー技法を使い分けたり複数のレビュー技法を併用するのが効果的と考えられる． ACA の適用範囲について，本研究の実験で扱った事例以外への適用の検証はできておらず，今後の課題である．製品の規模が大きくなると BBS の作成に時間がかかり，レビューの実施に多大な時間がかかることが懸念される． BBS が巨大になり俯瞰性が下がることでレビュー結果の確認や他のレビューアや設計者との議論が難しくなることも予想される．このような場合，対象製品を機能など何らかの軸で分割し，欠陥の残存可能性や欠陥が流出した際の影響度合いを考慮したうえで，リスクの高い部分に優先的に ACA を適用することが考えられる．この考え方はリスクベースドテストとして知られる（Veenendaal 2012）． 5.2 ACA へのゲーミングの応用 新たなシステムや製品をデザインする方法論がデザイン科学研究の領域で議論されている（March & Smith 1995; Hevner, March, Park, & Ram 2004）．デザイン科学のアプローチでは，解決すべき問題を特定し，ソリューションの検討，開発を実施し，成果物の評価を行い改善していく（Islam & Grönlund 2012; Baskerville, Kaul, Pries-Heje, &

(13)

Storey 2019）．田名部（2019）はデザイン科学研究とシミュレーション & ゲーミングの類似性として成果物の構築行為を通した問題解決をあげ，情報システムの改善や新規構築において「望ましい成果物と利用者に対する共通理解を与えるために，（中略）評価フェーズにおいてゲーミングを用いることは可能」と論じた．ゲーミングにおいてゲームの参加者が体験したゲームをリバースエンジニアリングすることで，ゲームの対象の構造やプロセスの理解を促すという教育実践があり（武市・加藤 2011），リバースエンジニアリングによってゲーム世界の認識モデルを構築することで設計者の構築したモデルとの比較が可能となる（田名部 2019）．ACA によるレビューは，設計者が構築したモデルとレビューアが認識したモデルの比較により，設計者が構築したモデルの漏れや誤りを指摘する行為ととらえると，ゲーミングとの類似性がある．ゲーミングを将来 ACA に応用できる可能性がある．ゲーミングでは，ゲームの体験後にディブリーフィングを実施し，ゲームの振り返りやゲームから得られた学びを議論することの重要性が知られる．ディブリーフィングには，現実認識が複数存在することに気付く役割や，自分にとっての現実認識と他者にとっての現実認識が異なるものであることを理解するといった役割がある（中村 2008）．仕様書のレビューもゲーミングと同様に，指摘を導出して終わりではなく，指摘の導出後に設計者とレビューアの間で，考慮した境界条件・悪条件の共有や指摘に対する修正要否の議論が必要である．BBS やユースケースといったレビューアの認識モデルに基づく議論には，ゲーミングのディブリーフィングの方法が応用できる可能性がある． 5.3 妥当性 実験の被験者は実際にレビュー対象の製品を開発している企業の社員ではなく，検証業務を請け負う検証専門の企業の社員であるため，実験の状況は，製品開発企業内でエキスパートがレビューを実施する状況とは異なる．しかしながら，検証専門企業の業務としては，エキスパートではない製品の検証や仕様書の欠陥検出を担当することがあり，本研究の実験は検証専門企業の社員にとって実際の業務に近い状況を再現していると言える．製品開発企業においても，その企業で初めて開発する製品の開発プロジェクトや，経験の浅い担当者がプロジェクトにアサインされた場合には同様の状況が発生しうる．グループ 1 とグループ 2 は異なる被験者群のため，欠陥検出能力が同一ではなく，被験者の能力の差が実験結果に影響した可能性がある．しかしながら，14 名の被験者をランダムに各グループに割り付けたこと，表 4 から検証業務経験年数の平均値に大きな差がないことから，能力の差の影響は小さいと考える．同一の被験者が 2 回レビューを実施したため，1 回目に使用したレビュー技法の学習効果が 2 回目のレビューの結果に影響した可能性がある．しかしながら，レビューの目的はどちらの技法を使用する場合でも同じ内容を被験者に伝えたことと，実験の手順を被験者に説明した際に，PBR の場合は表 7 のレビュー観点に沿ってレビューすること， ACA の場合は 3 章で解説した手順に沿ってレビューすることを伝えており，他の技法のレビュー観点を考慮することはある程度防ぐことができたと考える．1 回目の PBR と 2 回目の PBR, 1 回目の ACA と 2 回目の ACA でレビュー時の考慮範囲のアンケート結果を比較し，並べ替え検定 により p 値を算出したところ，PBR を使用した場合の「オ ブジェクトの悪条件」のみ p=0.050 となり 5% 水準で有意 差があったが，それ以外は有意差はなかった．表 14 より， PBR を使用した場合の「オブジェクトの悪条件」の考慮度合いは 2 回目よりも 1 回目のほうが高かったため，学習効果によるものではなく，該当の境界条件が仕様書に記述されていたことによる影響と考えられる．

6. 結語

本論文では，悪条件分析に基づく要求仕様レビュー技法（ACA）と従来手法の比較実験により，ACA の効果を確認した．ACA の特徴は境界条件の整理のプロセスを陽に含むことである．BBS を作成することでレビュー対象製品の境界条件をモデリングし，ガイドワードを元に悪条件を検討する．BBS のテンプレートを活用し複数の視点から境界条件を構造化できる．従来手法に比べレビューアの考慮範囲が広くなり，重要度の高い指摘を多く導出できることを，クロスオーバー試験に基づく実験により確認した．ACA は従来手法よりもレビュー実施にかかる時間が長い傾向があるが，境界条件の考慮漏れに起因する欠陥を要求仕様書のレビューの時点で導出できることから，費用対効果は大きくなることを確認した．利用シーンが多岐にわたる製品がレビュー対象である場合や，要求定義の初期段階で仕様書の記述が詳細化しきれていない場合など，境界条件の考慮漏れが発生しやすい状況で利用すると効果的であることの示唆を得た．被験者へのアンケートとインタビューにより，ACA の特徴である境界条件の可視化のアプローチに対して好意的な評価を得られ，実務で活用したいとの意見を得ることができた．今後は，ACA の適用範囲の検証，ACA へのゲーミングの応用の研究，レビューの目的に応じたレビュー技法の使い分けや併用の方法の研究が必要である．参考文献

Adrion, W. R., Branstad, M. A., & Cherniavsky, J. C. (1982) Validation, Verification, and Testing of Computer Software, ACM Computing Surveys, 14(2), 155‒192.

Basili, V. R., Green, S., Laitenberger, O., Lanubile, F., Shull, F., Sorum-gard, S., & Zelkowitz, M. V. (1996) The empirical investigation of Perspective-Based Reading, Empirical Software Engineering, 1(2), 133‒164.

Baskerville, R., Kaul, M., Pries-Heje, J., & Storey, V. (2019) Inducing Creativity in Design Science Research, Extending the Boundaries of Design Science Theory and Practice. DESRIST 2019, Lecture Notes in Computer Science, 11491, 3‒17.

(14)

出口弘（2013a）「社会シミュレーション & サービスシステムが目指す世界」，『計測と制御』，52(7), 563‒567. 出口弘（2013b）「社会システムの研究動向 2̶研究のための方法論̶社会システムの制度デザインの方法論：政策科学の方法としてのエージェントベースモデリング & シミュレーション」，『計測と制御』，52(7), 574‒581.

Hevner, A. R., March, S. T., Park, J., & Ram, S. (2004) Design Science in Information Systems Research, Management Information Systems Quarterly, 28(1), 75‒105.

IEC 61882 : 2016. Hazard and operability studies (HAZOP studies)̶ Application guide.

Islam, M. S., & Grönlund, Å. (2012) Applying Design Science Approach in ICT4D Research, Practical Aspects of Design Science. EDSS 2011, Communications in Computer and Information Science, 286, 132‒143.

ISO/IEC 20246 : 2017. Software and systems engineering̶Work product reviews. 小池利和・相澤武・中川忠彦・渡井克己・山下英祐・奥村学（2007）「レビューの質と価値の定量化の提案」，https://www. juse.or.jp/sqip/workshop/report/attachs/2007/1_A_report.pdf 河野哲也（2012）「ソフトウェア要求仕様における HAZOP を応用したリスク項目設計法」，http://jasst.jp/symposium/jasst12tokyo/ pdf/D2-1_paper.pdf

Leveson, N. G. (2012) Engineering a Safer World: Systems Thinking Applied to Safety, MIT Press.

March, S. T., & Smith, G. F. (1995) Design and natural science research on information technology, Decision Support Systems, 15(4), 251‒266. 三瀬敏朗・新屋敷泰史・橋本正明・鵜林尚靖・片峯恵一・中谷多哉子（2005）「組込みソフト非正常系における基礎モデル及び仕様分析手法の提案」，『情報処理学会研究報告』，2004-SE-147(29), 81‒88. 森崎修司（2009）『技法の分類とテンプレート（応用編）』，https:// thinkit.co.jp/article/893/1?page=0%2C1. 中村美枝子（2008）「多元的現実の理解を促すディブリーフィング̶仮想世界ゲームに基づく提案̶」，『シミュレーション & ゲーミング』，18(1), 21‒30. 岡本博幸・内山敬太・鈴木彩子・高橋一仁・西山茂・野中誠（2004）「要求仕様書の特性に着目した個人レビュー手法の実験的評価」，http://www.juse-sqip.jp/workshop/seika/2004/6/6_report. pdf 沖汐大志・誉田直美・森田純恵・大場みち子・小島嘉津江・服部克己・藤原良一（2017）「レビュー技術動向」，SQuBOK 策定部会編『SQuBOK Review 2017』，日本科学技術連盟，1‒18. 折笠秀樹（2016）「クロスオーバー試験の計画および解析」，『薬理と治療』，44(9), 1261‒1276.

Porter, A., Votta, L., & Basili, V. (1995) Comparing detection methods for software requirements inspections: A replicated experiment, IEEE Transactions on Software Engineering, 21(6), 563‒575.

Pumfrey, D. J. (1999)The Principled Design of Computer System Safety Analyses, PhD thesis, The University of York.

Shull, F. (1998) Developing Techniques for Using Software Documents: A Series of Empirical Studies, PhD thesis, Computer Science Dept., Univ. of Maryland.

Shull, F., Rus, I., & Basili, V. (2000) How perspective-based reading can improve requirements inspections, Computer, 33(7), 73‒79. 武市祥司・加藤鴻介（2011）「経営情報教育へのビジネスゲーム適用の試み」，『日本シミュレーション & ゲーミング学会全国大会論文報告集 2011 年春号』，65‒68. 田名部元成（2019）「シミュレーション & ゲーミング学再考」，『シミュレーション & ゲーミング』，29(1), 18‒23. 谷浩一・Shuang, C.・出口弘（2018）「要求仕様書の改善のためのフィードバック導出手法」，『日本シミュレーション & ゲーミング学会全国大会論文報告集 2018 年秋号』，30‒37. Tanizaki, K., Chang, S., & Deguchi, H. (2018) Propose a Method of

Requirements Review considering Adverse Conditions, in Proc. 2018 Joint 10th International Conference on Soft Computing and Intelligent Systems and 19th International Symposium on Advanced Intelligent Systems, 383‒388.

Thelin, T., Runeson, P., & Wohlin, C. (2003) An experimental compari-son of usage-based and checklist-based reading, IEEE Transactions on Software Engineering, 29(8), 687‒704.

Veenendaal, E. (2012) Practical risk-based testing: the PRISMA approach, UTN Publishers.

谷浩一 tanizaki16@cs.dis.titech.ac.jp

An Evaluation Study of Requirements Review Techniques Based on a Crossover Trial

Koichi Tanizaki, Shuang Chang, Hiroshi Deguchi

Tokyo Institute of Technology

Creating requirements specifications is essential in product development projects. It is important to detect defects of requirements specifica-tions by reviewing them in a phase of requirements analysis because it can lead big cost to fix the defects if they are found in post-process. Reviewing of requirements specifications is a form of manual simulation and reviewers should consider various boundary conditions to simulate the behavior of products and to detect defects. Considering boundary conditions that are not written in requirements specifications is difficult with conventional review techniques such as Checklist-based reviewing and Scenario-based reviewing. To solve this problem, a review technique based on adverse conditions analysis (ACA) was proposed. ACA incorporates modeling of boundary conditions. According to previous research, ACA is effective to review requirements specifications. However, discussion about the difference between ACA and conventional review techniques was insufficient. Verification of the effectiveness of it was also not enough. Therefore, we clarified its characteristics and confirmed effectiveness through experiment based on a crossover trial that test engineers conduct reviewing of requirements specifications using ACA and the conventional review technique. It was confirmed that many important defects can be detected by reviewing requirements specifications using ACA and that it was cost-effective. We also discussed the application of gaming to ACA.

(15)

付

録

実験の被験者が作成した BBS およびユースケース

ACA における境界条件および悪条件の具体例として，実験の被験者が作成した BBS およびユースケースの一部を掲載する．BBS のテンプレートおよびユースケースのテンプレートに沿って，レビューアが識別した境界条件が各ノードに記載されている．各ノードに対してレビューアが想定した悪条件が斜体で記載されている．

要求仕様レビュー技法のクロスオーバー試験に基づく評価研究