第３分科会（餡餅チーム）

SBR 法（ステルスベースドレビュー手法）の提案- ステルス情報の活用により，認識齟齬や認識漏れに起因する重大欠陥を 検出 -Proposal of SBR method. (SBR: Stealth Based Review)-Detecting critical defects due to misunderstanding or lack of awareness by the use of Stealthinformation 主査：中谷 一樹（TIS 株式会社）
副主査 ：上田 裕之（株式会社 DTS）
：原 佑貴子（日本アイ･ビー･エム 株式会社）
研究員 ：加賀 譲（株式会社 インテック）：北野 宗之（株式会社 インテック）：白幡 千香（アイエックス・ナレッジ 株式会社）：安田 聡美（株式会社 日立製作所）

研究概要
ソフトウェアレビューの主目的の一つは重大な欠陥を検出することである ．しかし，プロジェクト内で発生する認識齟齬や認識漏れに起因する重大欠陥は従来のレビュー手法では検出が難しい．本研究では，ステルス情報を活用したレビューを提案する．ステルス情報とは，プロジェクトメンバの各人が暗黙的に持ち，ドキュメントには記載されていない
状況，知識，経験に関する情報である．我々は，レビューの際に活用すべきステルス情報を検討し，またレビュー対象のプロジェクト特性ごとにパターン化を行った．
実験にて，これらを用いたレビューを実施した結果，重大欠陥の検出率が向上することを確認した．
1. はじめに1.1 背景ソフトウェア品質を向上するための施策として，ソフトウェアレビューが効果的であり，多くの企業で取り入れられている．しかし，実際の開発現場では，重大な欠陥を見逃してしまうことも少なくない．要因の一つとして，プロジェクト内の認識齟齬や認識漏れが挙げられる．具体的にはドキュメント作成者とプロジェクトメンバの間で開発項目に対する考えが異なっていたり，ユーザーに関する情報をプロジェクトで十分に共有されていなかったりした場合，重大欠陥が埋め込まれる可能性は高くなり，またそれをレビューで検出することも難しい．既存研究においては，重大欠陥のうち 88％ [1] が認識の齟齬が原因で混入しているという調査結果もある．
一方で，近年のソフトウェア開発は，スピードとユーザーニーズのタイムリーな取り込みが要求される傾向にある．これに伴いレビュー対象となる設計ドキュメントの作成の自由度が増し，汎用的なチェックリストで網羅的に欠陥検出を行うメリットが失われつつある．このような状況で品質を担保するためには，プロジェクトメンバ間でレビュー対象に関連する情報をできるだけ多く共有し，認識のずれがないことを十分に検証する必要がある．
そこで，我々は認識のずれを引き起こす要因となる情報について検討した．その中にはユーザーが求める性能などといった非機能要件や，想定している利用者の使い方など，要求分析の過程で検討し，適切にドキュメントに記載すべき情報もある．これらについてはドキュメントの書き方の問題であり，既に多くの研究が進められているため本論文では扱
1

第３分科会（餡餅チーム）
わない．我々は，ドキュメントに記載されるべき内容は記載されていることを前提に，ドキュメントに記載されない段階の情報や，読み手が適切に把握していれば問題とならない
レベルの情報に着目した．
このような情報として挙げられるのが ，日々変動するプロジェクトやユーザーの状況，
口頭で得たレベルの知識やプロジェクト内で常識と捉えられている知識 ，個人の経験やスキルである．これらの情報は積極的に共有すべきであるが，文書化するのが難しく個人の暗黙知 [2] となりやすい．
我々は，これらプロジェクトメンバの各人が持つ，隠れた経験，状況，そして知識に関する情報を「ステルス情報」と名付け，現状を把握することにした． そこで，研究員らの所属組織でレビューア経験者を対象にアンケート調査を実施した．(詳細内容は付録 1 を参照)
その結果，レビューで考慮しなければいけないステルス情報があると全員が回答した ．
「ステルス情報がレビュー時に考慮されていないことが起因となる後工程での問題や障害の発生はあると思いますか」という問いに対しては，16 名中 15 名がそう思うと回答した．
また，レビュー経験が浅い回答者よりも，レビュー経験が豊富な回答者の方が強く思っている傾向がある．
「自分が実践しているレビューで，ステルス情報を考慮して重大な欠陥を検出できていると思いますか？」という問いに対しては，レビュー経験が浅い回答者のうち，8 割は実践では有効活用できていないと回答した．また，レビュー経験が豊富な回答者でも，全面的にそう思うと回答したのは 3 割ほどに留まった．
これらの結果から，ステルス情報をプロジェクトメンバで適切に共有してレビューで活用することは効果的なレビューを実現する上で必要 であると考えた．
本研究の目的は，重大欠陥の検出に繋がる具体的なステルス情報を検討し，それらを活用したレビューにより重大欠陥の検出率が向上する かを検証することである．
なお，適用範囲はプロジェクトメンバが実施するチームレビューとし，第三者視点でのレビューについては範囲外とする．
1.2 先行研究
本研究を進めるに当たって，関連する先行研究を調査した結果を表 1-1 に示す．
表 1-1

本研究に関連する先行研究

先行研究

調査結果
HDR 法 は ，レ ビ ュー 対 象の 中 身を 詳 細 に見 る ので は なく ，兆候 を 掴 むこ と から レ ビュ ーを開 始
す る と して い る． こ の兆 候はレ ビ ュ ー対 象 の内 外 に観 察可能 な 「 特徴 」 であ り ，こ の特徴 と し

HDR 法

[3]

て ス テ ルス 情 報を 考 慮す ること も 原 理的 に 可能 と 考え られる ． し かし ， 研究 内 容で 述べら れ て
い る の は主 に 仕様 書 の概 観やキ ー ワ ード で あり ， ステ ルス情 報 に 関連 す るよ う な文 言はな い ．

IBR 法 は ，成 果 物が 作 られ た 状況 を 作 成者 へ の問 診 によ り事前 に 把 握す る とし て いる ．この 問
診 に よ り一 部 のス テ ルス 情報を 収 集 する こ とが 可 能と 考えら れ る が， 問 診の 設 計観 点は成 果 物
IBR 法 [4]作 成 者 の目 的 意識 や 姿勢 ・考え 方 と いっ た 部分 で あり ，ステ ル ス 情報 と 比較 す ると 限定的 で ある．
CDR 法 は ，レ ビ ュー 計 画作 成 技法 で あ り， レ ビュ ー 目的 と観点 の 設 定の た めに レ ビュ ーアと レ
ビ ュ ー イで プ ロジ ェ クト 情報を 共 有 する と して い る． 提示さ れ て いる プ ロジ ェ クト 情報の 中 に

CDR 法

[5]

は ス テ ルス 情 報と な り得 るもの も あ るが ， レビ ュ ー目 的を決 定 す る前 段 階で 収 集す る情報 で あり ， 具 体的 な 範囲 に つい ては言 及 さ れて い ない ．

2

第３分科会（餡餅チーム）
2. 提案する手法
2.1 レビューにおけるステルス情報
レビューにおいて考慮すべきステルス情報について，アンケートの結果や研究員らの経験から，「考慮しなかった場合に重大欠陥を引き起こす原因となり得るか」という観点で検討した．ステルス情報の所有者をユーザー，プロジェクト，作成者という視点で分け，それぞれ検討した結果を表 2-1 に示す．
このステルス情報のフレームワークを用いたレビューを，SBR 法（Stealth Based Review）
として提案する．
表 2-1

ステルス情報のフレームワーク

状況・ ユ ー ザー 要 求の 変 化
ユーザー

経験

・ お 客様 固 有の ド メイ ン 知識・ 過 去 にユ ー ザー と の間 で起・ QCD の 優先 度 や制 約
・ プ ロ ジェ ク ト体 制 の変 化

プロジェクト知識

き た ト ラブ ル・ プ ロ ジェ ク トの 独 自用 語・ 過 去 の失 敗 談(人 の 入れ 代 わり な ど )・ 過 去 の欠 陥 情報

・ 他 プ ロジ ェ クト と の関 係

・ 特 定 の業 務 経験 の ある 人の
情報作成者

・ 仕 様決 定 に至 る まで の 経緯

・ 関 係者 か ら口 頭 で伝 達 され・ レ ビュ ー 対象 に おけ る 考慮た情報

・ 使 用 技術 の 経験 ， スキ ル

範囲

2.2 SBR 法によるレビュー
SBR 法の手順について説明する．
2.2.1 レビューにおいて考慮すべきステルス情報の把握
まず，レビューアは普段のプロジェクト内のコミュニケーションや自身の持つソフトウ
ェア開発の知見から，レビュー対象に関連しそうなステルス情報を，フレームワークをもとに把握する．例えば，ユーザーの状況に関して，「ターゲットのエンドユーザーが若者か
ら中高年に変更になった」という情報を得た場合，これが一つのステルス情報になる．
また，レビューにおいて考慮すべきステルス情報は，レビュー対象のプロジェクト特性
によってパターン化が可能である．そこで，我々は表 2-2 プロジェクト特性別ステルス潜
伏箇所リストを作成した．(詳細内容は付録 2 を参照)
表 2-2
プロジェク

プロジェクト特性別ステルス潜伏箇所リスト
レビューにおける注意点

ステルス潜伏箇所

ト特性
言 語 の 違い や 遠隔 (リモ ー ト)に よ る コミ ュ ニケ ー シ

言 葉 だ けで の 説明

オフショア

ョ ン の 齟齬言 葉 の 意味 (特に 日 本と 中 国の漢 字 の 違開発

ド キ ュ メン ト 成果 物 の粒 度

い)

図 表 ， サン プ ル等 の 補足 資料

あ い ま い表 現

OSS の Web フ レ ーム ワ ーク の 使用

OSS フ レ ーム ワ ーク の 使用 経 験・ 実 績

セ キ ュ ア な シ ス テ ム (お 客 様 の セ キ ュ リ テ ィ ポ リ シ

プ ロ ジ ェク ト での セ キュ リティ 対 策 方針

ー ，プ ラ イバ シー ポ リシ ー ，コン プ ラ イア ン スの 遵 守 )ク ロ ス ブラ ウ ザの 対 応

Web ブ ラ ウザ の 機能 ， 種類 ， バー ジ ョ ン， 特 徴

ブ ラ ウ ザバ ッ クの 対 応

ス テ ー トフ ル かス テ ート レスかURL， パラ メ ータ の 設計 方 針

Web

動 的 な 画 面 制 御 (主 に JavaScript を 使 用 し た ク ラ イ
ア ン ト 側の 制 御)3

第３分科会（餡餅チーム）
この一覧を用いることで，レビュー対象が特定のプロジェクト特性に該当する場合に有効なステルス情報を考慮することが可能である．例えばオフショア開発の場合，「言葉の意味」に着目し，「以上，以下という言葉が正しく中国語に翻訳されない事例があった」というプロジェクトの経験に関する情報を得た場合，これをステルス情報として把握する．
2.2.2 ステルス情報を活用したレビュー
レビューの場では，事前に得たステルス情報を考慮しながら，欠陥検出を行う．レビュ
ー対象のドキュメントを確認し，ステルス情報のフレームワークおよびプロジェクト特性
別ステルス潜伏箇所リストを参照しながら，関連する情報はないか思い起こしていく．その過程で認識のずれを感じた箇所や，考慮が抜け落ちていそうな箇所があれば適宜質問ないしは指摘として挙げる．ステルス情報のフレームワークにある情報は，重大欠陥の原因となり得るものであり，それらを考慮しながらレビュー対象物を確認することで，ステル
ス情報がなくては検出できない欠陥が検出可能になる．これが，ステルス情報を活用して欠陥を検出するということである．
このとき，レビュー参加者に質問を投げかけることにより，更にステルス情報を引き出しても良い．例えば，作成者の経験について「クライアントサーバシステムの開発経験 があると聞きましたが，Web アプリケーションの開発はしたことありますか．」と質問する．
「ない」という回答の場合，これを考慮し，クライアントサーバにないブラウザバックなどの処理や HTTP メソッドの使い分けについて注力してレビューを実施する ．ただし，レビ
ュー中に質問する場合は，不必要な質疑応答を避けるため，有効なステルス情報に当たりを付けておく必要がある．
2.2.3 適用結果のフィードバック
ステルス情報を考慮したことより重大欠陥が検出されるなど，ステルス情報が有効に機能した場合，レビューアの知見として蓄積していくのが望ましい．蓄積方法は様々考えられるが，例えば，プロジェクト特性別ステルス潜伏箇所リストに有効だったステルス情報を追記するなどが挙げられる．
3. 実験・評価
3.1 実験方法
従来法によるチームレビューと，SBR 法を用いたチームレビューの両方を実施し，その結果を比較して SBR 法の有効性を評価する．従来法と SBR 法の実施方法を表 3-1 に示す．
SBR 法では，表 2-1 のステルス情報のフレームワーク，表 2-2 のプロジェクト特性別ステ
ルス潜伏箇所が入力情報として与えられる．
表 3-1
レビュー方法

従来法と SBR 法の実施方法

目的

形式

事前読込

従来法による

欠陥

集合

各自で

チームレビュー

検出

形式

実施する

欠陥

集合

各自で

検出

形式

実施する

司会／

質問

入力情報

記録係

SBR 法 を 用 い た
チームレビュー

置く

適宜可

無し

置く

適宜可

ス テ ル ス情 報 のフ レ ーム ワーク
プ ロ ジ ェク ト 特性 別 ステ ルス
潜伏箇所

レビュー対象のドキュメントとして，実験用に作成された 2 種類（交通費精算システム，
ヘリコプター予約管理システム）の架空システムの仕様書を用意した．それぞれ 5 ページ，
約 2000 字の分量で，同程度の欠陥混入度合いになっている．
4

第３分科会（餡餅チーム）
被験者は，レビューの経験年数，立場が異なる 4 名を選出した．
実験では 2 回のレビューを実施する．1 回目は従来法のチームレビュー，2 回目は SBR法を用いたチームレビューを実施する．被験者は事前に 2 つの仕様書をそれぞれ 15 分程度
で各自確認しておく．チームレビューの実施時間は，1 仕様書あたり 25 分とした．レビュ
ー実施中は従来法・SBR 法共に質問可能とし，質問への回答，及び，司会進行と指摘記録
は研究員が対応する．また，被験者のスキル，およびレビュー対象の違いによる誤差を極力排除するため，被験者を A，B の 2 グループに分けて，1 回目と 2 回目で仕様書を入れ替えて実施した．
表 3-2
チーム

被験者

立場

被験者の構成と実験方法
レビュー

1 回目

SBR 法

2 回目

経験

従来法の

の説明

SBR 法 を 用 い た

チームレビュー
A チーム

B チーム

a

品質保証

3年

b

開 発 リ ーダ

10 年

c

品質保証

5年

d

開発リーダ

7年

チームレビュー

仕 様 書 X(25 分 )説明を

仕 様 書 Y(25 分 )適 宜 質 問可受ける

適 宜 質 問可仕 様 書 Y(25 分 )説明を

仕 様 書 X(25 分 )適 宜 質 問可受ける

適 宜 質 問可提案手法の有効性を示す客観的な評価指標として，被験者に対して定量評価 5 項目，定性評価 2 項目からなるアンケート調査を行った．
3.2 評価方法
各被験者が従来法のチームレビューで指摘した重大欠陥（手戻り工数 8 時間以上）の数と，SBR 法を用いたチームレビューで指摘した重大欠陥の数を比較することで評価した．
アンケート結果からは，被験者による提案手法の評価を得る．以上を総合的に評価し，提案手法の有効性を評価した．
3.3 実験結果
レビュー実験結果を以下に示す．
重大欠陥の検出数を表 3-3 に示す．1 回目の実験で検出された重大欠陥数の 2 チームの平均は 4.00 件であったが，2 回目の実験では 6.00 件となり，従来法のチームレビューと比較して，SBR 法を用いたチームレビューでは，重大欠陥の検出数が 1.5 倍になったこと
が分かる．
表 3-3
チーム

実験で検出された重大欠陥数

1 回目 従来法2 回目 SBR 法

増加率(%)

A チーム

5

7

140

B チーム

3

5

150

4.00

6.00

150

平均

5

第３分科会（餡餅チーム）
3.4 アンケート結果
3.4.1 定量評価結果
アンケートの定量評価の結果を図 3-1 に示す．

図 3-1

定量項目アンケート結果

設問 1～2 は，SBR 法の活用によるレビューの効果に関する設問で，共に 4 名全員が肯定
意見(「大変そう思う」または「少しそう思う」に回答)であり，高い評価が得られた．
設問 3 は，SBR 法の実践に関する設問で， 3 名（75%）が肯定意見であったが，1 名（25%）
は否定意見（「あまり思わない」）であった．
設問 4～5 は，SBR 法の副次的な効果である認識漏れや認識齟齬の解消に関する設問で，共に 4 名全員が肯定意見であった．
3.4.2 定性評価結果
アンケートの定性評価の結果を表 3-4，表 3-5 に示す．（設問 7 の詳細は付録 3 参照）
表 3-4

定性項目アンケート結果（実践する際に難しい点）

Q6. SBR 法 を 実 践 す る 際 に ， ど の 点が難しいと感じましたか？

1. ス テ ル ス 潜 伏 箇
所の推測

2. ス テ ル ス 情 報 を 引
き出す質問

0

3. ス テ ル ス 情 報 を 考慮した欠陥検出40

設問 6 は，SBR 法の実践に関する設問で，実践する上で難しい点として，4 名全員が「ステルス情報を引き出す質問」を選択した．
設問 7 は，SBR 法の良い点や改善点などを自由に記載してもらうための設問で，良い点としては，「 質問やコミュニケーションによって認識を合わせることで品質を高めていくという考え方は，高速な開発を実現するためには必要な考え方だと思った．」，「ステルス情報やプロジェクト特性別ステルス潜伏箇所のフレームワークがあることで，具体的にどういったステルスに着目すべきか分かり良かった．」，「 仕様書記載漏れの欠陥を質問からあぶり
出そうということは有益だと思った」という良い評価が得られた．
一方，「プロジェクトの状況を把握で きたとしても欠陥知識がある程度ないと，欠陥検出は難しいと感じた．」，「 レビュー中に質問をすると，質問することに注力することになり，欠陥検出に集中できなくなる．」，「ステルス情報を引き出すための質問の仕方として ，オー
プンクエスチョンだと時間がかかるので，YES/NO で答えられるクローズクエスチョンで質問した方が効率的だと感じた．」，「 質問する相手との信頼関係ができていることが大切だと思った．」のような改善すべき課題も挙げられている．

6

第３分科会（餡餅チーム）
表 3-5

定性項目アンケート結果（SBR 法に関する意見）

質問

良い点

改善点

Q7. SBR 法 に 関 す る・ 質 問 やコ ミ ュニ ケ ーシ ョンに よ っ て・ レ ビ ュー 中 に質 問 をす ると， 質 問 する こ とに意見（自由記入）認 識 を 合わ せ るこ と で品 質を高 め て

注 力 す るこ と にな り ，欠 陥 検出に 集 中 でき な く

い く と いう 考 え方 は ，高速 な 開発 を 実なる．

現 す る ため に は必 要 な考 え方だ と 思・ プ ロ ジェ ク トの 状 況を 把握で き た とし て も欠った．

陥 知 識 があ る 程度 な いと ，欠陥検 出 は 難し い と・「 ス テ ル ス情 報 の分 類 表」や「 プ ロジ

感じた．

ェ ク ト 特性 別 ステ ル ス潜 伏箇所 の 例 」 ・オ ープ ン クエ スチ ョ ンだ と 時間 が か かる の で ，を 見 る こと で ，具体 的 にど う いっ た ス

YES/NO で 答え ら れる ク ロー ズク エ ス チョ ン で

テ ル ス に着 目 すべ き か分 かり良 か っ

質 問 し た方 が 効率 的 だと 感じた ．

た．

・ 質 問 する 相 手と の 信頼 関係が で き てい る こと・ 仕 様 書記 載 漏れ の 欠陥 を質問 か ら あが 大 切 だと 思 った ．

ぶ り 出 そう と いう こ とは 有益だ と 思・ 質 問 の仕 方 次第 で 結果 が左右 さ れ る ． 作 成者った．

へ の 質 問責 め にな ら ない ように す る ため の 質・ 作 成 者が 設 計の 意 図や 背景を 説 明 で問 の 仕 方ガ イ ドな ど があ るとい い ．

き る こ とが ま ずは 確 認す べきこ と で・ 経 験 の浅 い 人が レ ビュ ーに参 加 し た場 合 「なあ り ，ド キュ メ ント の 中身 の チェ ッ ク

ぜ そ の 質問 を した の か」で 迷子に な り そう だ とは そ の あと で 良い と 考え ている ．そ う

思った．

い う 意 味で こ の手 法 の考 え方に は 賛
同 で き る．

3.5 考察3.5.1 ステルス情報を使用した欠陥検出に関する考察
3.3 実験結果において，SBR 法を用いたチームレビューでは，従来法のチームレビューの 1.5 倍の数の重大欠陥が検出された．また，3.4 アンケート結果において，被験者全員が重大欠陥検出に効果があると感じていると回答を得た．ただし，今回の実験は架空のシ
ステム，プロジェクトを想定しており，実際の現場のレビューではステルス情報の量や質が異なるため，実験と同等の効果が得られるかまでは評価できない ．しかし，ステルス情報をレビューで活用することが重大欠陥の検出に繋がるという仮説に対して一定の確証を得ることができたと考える．
3.5.2 提案手法の実現可能性の考察
3.3 実験結果において，従来法より多くの重大欠陥を検出することができ，また，3.4 ア
ンケート結果においても，フレームワークなどの入力情報があることで，具体的に着目すべき情報に気付けたなどという肯定意見が多かった ．このことから，ステルス情報のフレームワークおよびプロジェクト特性別ステルス潜伏箇所リストを入力情報として与えたことの効果により，被験者は有効な質問を挙げることができ，さらにその表出化したス テル
ス情報を考慮した欠陥を検出できたのだと考えられる．従って，実現可能性は十分に高いと言える．
一方で，3.4 アンケート結果から，ステルス情報を引き出すための質問の仕方については工夫が必要ということが分かった．今回，ステルス情報のフレームワークおよびプロジ
ェクト特性別ステルス潜伏箇所リストを入力情報として与えたが，記されているのは単語レベルの情報に留まっているため，そこから本当に必要な着眼点を考えて質問や指摘に繋げるためには個人のスキルが要求されると考えられる．このことから，本手法をレビュー
7

第３分科会（餡餅チーム）
アの誰もが実践できるようにするためには，フレームワークやプロジェクト特性別ステル
ス潜伏箇所リストの情報からどのように質問や欠陥検出に繋げるのか具体的なプロセスとして示す必要があると考える．
3.5.3 提案手法の副次的効果の考察
3.3 実験結果において，被験者から「SBR 法を用いてレビューを行うと今までのレビューとは違った視点で行う事ができた」という意見が挙がった．指摘内容を見ても表面的な指摘ではなく，より本質的な指摘が多くなっていることが分かった． 各人がステルス情報を意識してレビューを行うことで，新たな気付きを得ることに繋がり，欠陥検出の他にも，懸念や要確認事項を洗い出したり，情報共有を促進したりする効果も見込めると考えられる．これにより，本手法を継続することによって，ドキュメント作成者がステルス情報を意識するようになり，指摘すべき欠陥が混入しない様に予防する効果もあると期待できる．
4. 今後の課題
3.5.2 提案手法の実現可能性の考察において，質問や欠陥検出を行う方法について具体的なプロセスを示す必要があると述べたが，レビューの場で適切なステルス情報を引き出すことができるかどうかは，プロジェクト内のコミュニケーションの密度やレビューアの持つ欠陥知識などといった知見によっても大きく変わると考えられる．
今後，これらレビュー以外の要素とレビューにおける質問，指摘の質との関連について研究を進め，総合的な視点でプロセスの検討を進めていきたいと考える．
5. まとめ本研究では，認識齟齬や認識漏れに起因する重大欠陥の検出を目的とし ，ステルス情報を活用したレビュー手法である「SBR 法」を提案した．本手法では，重大欠陥の原因となり得るステルス情報をまとめたフレームワークとプロジェクト特性別ステルス潜伏箇所リストを用いてプロジェクトメンバから得たステルス情報を活用することにより欠陥検出を行う．実験の結果，重大欠陥の検出率が向上することを確認した．
今後，ソフトウェア開発に一層スピードや変化への対応が要求されても ，重大欠陥を発生させてはいけないという品質の基本的な考えは変わらない はずである．本手法の考え方を取り入れるとともに，プロジェクト内のコミュニケーションの促進や，欠陥分析と合わせたステルス情報の蓄積を行うことが高品質なソフトウェア開発を実現する上で 必要になると考える．
参考文献[1] 細川宣啓，永田敦，藤原雅明，森崎修司，川合大之，奥山剛，上野直樹，會見知史，
菅野良太「検出難易度の高い欠陥を検出するレビュー観点の提案」，日本科学技術連盟 SQiP研究会，2011[2] 野中郁次郎，竹内弘高「知識創造企業」東洋経済新報社，1996[3] 細川宣啓，永田敦，藤原雅明，森崎修司，上田裕之，高橋功，高橋実雄，中谷一樹「HDR
法：仮説駆動型レビュー手法の提案」，日本科学技術連盟 SQiP 研究会，2012[4] 細川宣啓，永田敦，藤原雅明，森崎修司，芦田直之，篠崎悦郎，仁藤千博「重大欠陥検出に集中するためのレビューポイントの導出方法の提案」，日本科学技術連盟 SQiP 研究会， 2013[5] 細川宣啓，永田敦，藤原雅明，森崎修司，山本浩之，牧野将治，小原美帆，奥山剛，
小田部 健「ソフトウェア品質不安に対する心理的側面に着目した， レビュー計画作成技
法の提案」，日本科学技術連盟 SQiP 研究会， 2010

8

第３分科会（餡餅チーム）
付録１

事前アンケート結果
回答数

質問

Q0. 基本設計または詳細設計におけるドキュメント成果物のレビュー経験を以下の中から選んでください。
1. 5プロジェクト以上
2. 5プロジェクト未満
Q1. レビューする成果物には書かれていないが、レビューで考慮すべき情報があると思いますか？
1. 大変そう思う
2. 少しそう思う
3. あまり思わない
4. 全くそう思わないQ2. レビューする成果物には書かれていないが、レビューで考慮すべき情報にはどのようなものがあると思いますか？（複数回答可）
1. お客様固有の情報（ドメイン知識、利用者、利用環境、ツールや標準の指定、競合他社の動向、など）
2. 作成者個人が持つ情報（仕様決定に至るまでの経緯、各人の経験やスキル、口頭で伝達された情報、など）
3. プロジェクト固有の情報（過去の障害情報、プロジェクトの体制、QCDの優先度や制約、標準や規定の有無、など）
4. プロジェクト内では当たり前と考えられている情報（対象システムや利用製品に関する知識、用語の意味、など）
Q3. Q2の情報が考慮されないことが起因となる後工程での問題や障害の発生はあると思いますか？
1. 大変そう思う
2. 少しそう思う
3. あまり思わない
4. 全くそう思わない
Q4. Q2の情報をレビューで考慮することで、重大な欠陥を検出しやすくなると思いますか？
1. 大変そう思う
2. 少しそう思う
3. あまり思わない
4. 全くそう思わないQ5. 自分が実践しているレビューで、Q2の情報を考慮して重大な欠陥を検出できていると思いますか？
1. 大変そう思う
2. 少しそう思う
3. あまり思わない
4. 全くそう思わない

9

回答数
6
10
レビュー経験大
（6名)
4
2
0
0
レビュー経験大
（6名)
5
6
6
6
レビュー経験大
（6名)
4
2
0
0
レビュー経験大
（6名)
4
2
0
0
レビュー経験大
（6名)
2
4
0
0

レビュー経験小
（10名)
6
4
0
0
レビュー経験小
（10名)
5
6
7
7
レビュー経験小
（10名)
3
6
1
0
レビュー経験小
（10名)
7
3
0
0
レビュー経験小
（10名)
0
2
4
4

←レビュー経験大←レビュー経験小
合計
（16名）
10
6
0
0
合計
（16名）
10
12
13
13
合計
（16名）
7
8
1
0
合計
（16名）
11
5
0
0
合計
（16名）
2
6
4
4

第３分科会（餡餅チーム）

10

第３分科会（餡餅チーム）

11

第３分科会（餡餅チーム）
付録 2

プロジェクト特性別ステルス潜伏箇所リスト

プロジェクト特 性ウォーターフォール

レビューにおける注 意点

ステルス潜 伏箇 所

フェーズドアプローチによる管 理

フェーズ間 のドキュメント成 果 物 の整 合 性

フェーズ間 による認 識 齟 齬 ，欠 落

前 工 程 でフィックスしていない仕 様

後 工 程 で手 戻 りが発 生 した場 合 の影 響 大

派生 開 発変 更 ・追 加 する部 分 と既 存 部 分

変 更 ・追 加 による既 存 部 分 の修 正 範 囲

ドキュメント成 果 物 の版 管 理 とソースコードのバージョン

ドキュメント成 果 物 とソースコードとの整 合 性

管理社 内 環 境 と本 番 環 境 との整 合 性

デグレードによる影 響 大パッケージ・クラウド
反復 開 発アジャイル開 発

パッケージ・クラウドの製 品 知 識

パッケージ・クラウド製 品 の使 用 経 験 ・実 績

フィットアンドギャップ分 析 による合 意 事 項

お客 様 の要 求 と製 品 仕 様 の整 合 性

短 期 間 のイテレーション

前 のイテレーションでの不 具 合 情 報

問 題 を検 出 して修 正 する複 数 のプラクティス

ペアプ ログ ラミ ング， テスト 駆 動 開 発 ， 継 続 的 イ ンテ
グレーション，日 時 のミーティングなどで得 た情 報

大規 模 開発

オフショア開発

サブシステムごとの開 発

サブシステム間 のインターフェース

体 制 の複 雑 化 (要 員 の入 れ替 え，追 加 )他 システムの進 捗 遅 延 でフィックスしていない仕 様

会 社 間 を跨 いだ開 発 ，オフショアの活 用

要 員 の引 継 ぎ

言 語 の違 いや遠 隔 (リモート)によるコミュニケーションの齟言 葉 だけでの説 明齬言 葉 の意 味 (特 に日 本 と中 国 の漢 字 の違 い)ドキュメント成 果 物 の粒 度

あいまい表 現

図 表 ，サンプル等 の補 足 資 料

Web

OSS の Web フレームワークの使 用OSS フレームワークの使 用 経 験 ・実 績

セキュアなシステム(お客 様 のセキュリティポリシー，プライ

プロジェクトでのセキュリティ対 策 方 針

バシーポリシー，コンプライアンスの遵 守 )クロスブラウザの対 応Web ブラウザの機 能 ，種 類 ，バージョン，特 徴

ブラウザバックの対 応

ステートフルかステートレスかURL，パラメータの設 計 方 針

動 的 な画 面 制 御 (主 に JavaScript を使 用 したクライア
ント側 の制 御 )クライアントサーバ

お客 様 側 の操 作 要 求

シンクライアント製 品 の使 用 経 験 ・実 績

クライアント環 境 の OS バージョン，ディスプレイサイズの

お客 様 環 境 と同 じ条 件 下 でのテスト (同 じクライアント違い

環 境 ， 同 じ シ ンク ラ イ ア ント 製 品 ， 同 じ プ リ ンタ の 機

シンクライアント製 品 との相 性

種)

プリンタ等 のネットワーク接 続 された機 器 との接 続

モバイル(ネイティブアプリ)

端 末 の OS，機 種 ，バージョンによる違 いを考 慮OSS フレームワークの使 用 経 験 ・実 績スマ ート フォ ン ， タ ブ レ ッ ト 等 の 画 面 サイ ズに よ る表 示 のプロジェクトでのセキュリティ対 策 方 針

違い

アプリの画 面 レイアウト

アプリ側 で取 得 するデータのプライバシーポリシー

操 作 性 によるお客 様 との合 意

OSS のフレームワークを使 用

12

第３分科会（餡餅チーム）

付録 3

SBR 法アンケート結果
質問

1.大変そう思う

2.少しそう思う

3.あまり思わない

4.全くそう思わないQ1. ステルス情報を活用することで、従来のレビューで検出できなかった重大欠陥を検出できると感じましたか？

3

1

0

0

Q2. SBR法を用いることで、自分のレビューの質が上がると感じま
したか？

2

2

0

0

Q3. 説明を受けて、SBR法をすぐに実践できると感じましたか？

1

2

1

0

Q4. ステルス情報を明らかにすることで、従来のレビューと比べプロ
ジェクト内の認識を共有することができると感じましたか？

3

1

0

0

Q5. ステルス情報を明らかにすることで、従来のレビューと比べプロ
ジェクト内の認識のずれをなくすことができると感じましたか？

3

1

0

0

Q6. SBR法を実践する際に、どの点が難しいと感じましたか？

1.ステルス潜伏箇 2.ステルス情報を引 3.ステルス情報を考
所の推測
き出す質問
慮した欠陥検出04

0Q7. SBR法に関する意見（自由記入）■良い点・「ステルス情報のフレームワーク」や「プロジェクト特性別ステルス潜伏箇所の例」を見ることで、具体的にどういったステルスに着目すべきか分かり良かった。
・ドキュメントありきのレビューにならない点は非常に有益だと思った。
・仕様書記載漏れの欠陥を質問からあぶり出そうということは有益だと思った。
・ドキュメントに書かれていない抜け漏れを見つけ出すことは難しいが、質問をすることでその糸口をつかもうとする方法は、効率的なやり方だと思った。
・ドキュメントに全て書かなければならないというのではなく、質問やコミュニケーションによって意識を合わせるという考え方は、高速な開発を実現するためには必要な考え方だと思った。
・プロジェクト内で説明会や状況共有会を別途実施するよりも、欠陥を如何に効率よく見つけるかという視点においては効率的だと思った。
・作成者が設計の意図や背景を説明できることがまずは確認すべきことであり、ドキュメントの中身のチェックはそのあとで良いと考えている。そういう意味でこの手法の考え方には賛同できる。
■改善点
・プロジェクトの状況を把握できたとしても欠陥知識がある程度ないと、欠陥検出は難しいと感じた。
・レビューと質疑応答の時間を分けた方がいいのではないか。
（レビュー中に質問をすると、質問することに注力することになり、欠陥検出に集中できなくなる。）
・オープンクエスチョンだと時間がかかるので、YES/NOで答えられるクローズクエスチョンで質問した方が効率的だと感じた。
・質問はプロジェクト全体に関する共通機能の設計や仕様を決める際に聞くようなことが多いので、機能設計書のレビュータイミングで聞くものではないかもしれない。
・質問する相手との信頼関係ができていることが大切だと思った。
・要件定義のフェーズとの差別化が難しいと思った。
・経験の浅い人がレビューに参加した場合「なぜその質問をしたのか」で迷子になりそうだと思った。
・質問の仕方次第で結果が左右される。作成者への質問責めにならないようにするための質問の仕方ガイドなどがあるといい。

13