第 2 研究コース（観抽 Hi グループ）

ステークホルダーのアクションに着目したレビュー観点導出手法〜今日からあなたも上級レビューア！ 『SAKE』の提案〜
研究員

：

主査
副主査
アドバイザー：：：

茂木 郷志 （パナソニックＩＴＳ株式会社）
樋口 雄基 （三菱プレシジョン株式会社）
宇根 勲（ＳＣＳＫ株式会社）
蜂須賀 夏子（株式会社オージス総研）
村田 健二 （三菱総研ＤＣＳ株式会社）
濱田 航一 （ＩＤＥＣ株式会社〉
児玉 敬（旭化成株式会社）
中谷 一樹 （ＴＩＳ株式会社）
上田 裕之 （株式会社ＤＴＳインサイト）
安達 賢二 （株式会社ＨＢＡ）

研究概要
ソフトウェア開発において ,品質向上を図るために レビューの実施が重要かつ不可欠である.しかし,上級レ ビューアであれば検出できる欠陥も,上級レビューア以外では見逃すことが少なくない.その対策としてレビュー観点をあらかじめ用意することが多いが,レビューの実施効果は依然としてレビューアのスキルに依存する傾向にある.そこで筆者らは,レビューで検出すべき欠陥を上級レビューア以外でも検出できることを目的としたレビュー観点導出手法を考案した.実験により,本手法の有効性を確認することができた.
1. はじめに1.1 背景ソフトウェア開発において,品質向上を図る ためにレビューの実施が重要かつ不可欠である.しかしレビュー効果がレビューアのスキルに依存する傾向にあることも事実である.
レビューで検出すべき欠陥を 知識も経験も豊富な上級レビューアは検出できる が,全てのレビューを上級レビューアが担当することは現実的には難しい.そこで,検出すべき欠陥を上級レビューア以 外でも検出できるように,SQuaRE 品質特性 [1] の活用や,レビュー観点を準備する,などの工夫をしているが,欠陥を見逃してしまうケースが少なくな い.品質特性の活用やレビュー観点の設定 は非常に有効な手段であり一定の効果は得られる ものの,依然としてレビューアのスキルへの依存度が高い状態であることに変わりはない.
レビュー観点を設定してもレ ビューアスキルへの依存度が高い原因はいくつ かあるが,特に次の２つが重要と考える.
第 1 に,レビュー観点がプロジェクトやレビュー対象物の特性を踏まえたものになっていないケースが多いことが挙 げられる.汎用的なレビ ュー観点には当該レビュー対象に関係のない観点も含まれていた り,逆に当該レビューで 検出すべき欠陥を検出するための観点が漏れていたり,必ずしも最適なレビュー観点とは言えないケースが多い.また最適なレビュー観点を自分たちで設定しようと思っても導出方法がわからない.
第 2 に,レビュー観点の粒度をどの程度にすれば良いのか判断が難しいことが挙げられる.一般的に体系化された品質特性は抽象度が高く,いわゆる粒度の粗い観点となっていることが多いため,知識や経験が不足していると具体的 に何をチェックすれば良いのか想起できない.だからと言って具体的に細かく設定すれば良いというものではない.具体的な細かな観点を与えられるとその観点は見るが,数が増えるため時間もかかり,与えられた観点以外でレビューする時間的余 裕がなくなる.レビュー アの知識や経験の不足を補いつつも細かくなり過ぎない適切な観点の粒度があるはずだが,画一的な答えは存在しない．また,1

第 2 研究コース（観抽 Hi グループ）
適切な観点の粒度を自分たちで設定しようと思っても決定方法がわからない.
1.2 解決すべき課題
以上の背景を踏まえ,筆者らは上級レビュー アと 同等レベルのレビュー活動を上級レビ
ューア以外でも行えるようにすることを目的に,以下の点を解決すべき課題と捉えた.
RQ1：どうすればプロジェクトやレビュー対 象物の特性を踏まえたレビュー観点を導出できるか.
RQ2：どうすれば上級レビューア以外でも欠 陥を検出できる粒度のレビュー観点を導出できるか.
これら の 課 題 の 解 を 導 出で き れ ば ,レ ビュ ー 活 動 の 改 善 が 図 れ ,欠 陥 の 流 出 を 低 減 できるのではないかと考えた.
以降,2 章では課題の解決策として筆者らが提案するレビュー観点導出手法を示す.3 章
で提案手法に対する実験と評価考察を行い,4 章でまとめを示す.
2. 課題解決策の提案
2.1 提案手法が対象とする開発工程
提案手 法 が 対 象 と す る 開発 工 程 は ,筆 者ら の 担 当 開 発 領 域 を 考 慮 し,ソ フ ト ウ ェ ア 開発
工程 [2] の要求定義,アーキテクチャ設計,詳細設計,実装とする.
2.2 提案手法の方針
筆者らは課題解決に向けた 手法の検討にあたり,レビュー対象物である成果物の性質に着目した.開発における各種成果物は,製品開発に関わる様々なステークホルダーの明示的,暗黙的な要求事項を反映した ものであり,レビューは それらが適切に映されていることを検証する場に他ならない.そのため,製品に関わるステークホルダー を洗 い出し,各ステークホルダーの要求事項の源泉となる期待・要望・懸念・疑問といった『関心事』からレビュー観点を導出すれば,プロジェクトやレビュー対象 物の特性を踏まえた観点導出が可能になると考えた.また,ステークホルダーの『アクション』に着目し,ステークホルダーの視点をより具体的に理解した上で,関心事を抽出する.さらに,関心事から段階的に『レビュー観点』に落とし込むことで,具体的且つレビューアのスキルに応じた粒度の観点の導出が可能になると考えた.
これらを踏まえたレビュー観 点の導出方法を明確な手順として示すことで,スキルによる依存性を下げ,観点導出の確実性を高める.これにより,上級レビューア以外でも,有効な観点の導出が可能となり,上級レビューアに近いレベルで,欠陥を検出することができるようになると考えた.
2.3 関連するレビュー技法
レビュー技法の中で，ステークホルダーの視点を用いた従来技法を表 1 に示す.
表 1 ステークホルダーの視点を用いた従来のレビュー手法
PBR: Perspective Based Reading
RBR: Role Based Review
概要

各ステークホルダーの立場でレビュー対象各ステークホルダーの役割の観点からレビ物から成果物を作成することを通してレビュー対象物を評価する

ュー活動を行う利点 プロジェクトやレビュー対象物の特性を踏まえたレビューが可能

まえたレビューが可能

 極めて効果的な技法であることが判明している欠点

 プロジェクトやレビュー対象物の特性を踏[3]

 PBR と比較すると成果物を作成する必要がなく,実施に大きな時間・労力を要しない成果物を作 成する必要があり,大きな労力・具 体 的 な 手 順 が 定 義 さ れ て い な い た め ,レ ビ

時間を要するューアのスキルによって欠陥検出結果にばらつきが生じやすい

2第 2 研究コース（観抽 Hi グループ）
ステークホルダーの視点を用 いて,プロジェ クトやレビュー対象物の特性を踏まえたレビュー観点でレビューを実施可能な技法は存在していたが,大きな工数を必要とせず,レビ
ューアのスキルへの依存性を克服できる技法は見つからなかった.
2.4 提案手法
筆者らが提案するステークホルダーのアクションからレビュー観点を導出する手法『SAKE（Stakeholder Action Kanshingoto Extraction) Method』を以下に示す.
2.4.1 提案手法全体像
2.2 項の方針に基づき作成した,レビュー観点導出の手順を図 1 に示す.
ステークホルダーから段階的にレビュー観点を導出する「レビュー観点導出フェーズ」と導出した観点をレビュー観点特性表に当てはめ,体系的に確認する「レビュー観点補充フェーズ」から成り,計 6 つの Step を実施する.(詳細は 2.4.2 項に記載)＜ レビュ ー観点導出 フェーズ ＞
Step1-1

Step1-2

Step1-3

Step1-4

ステークホルダーの抽出

アクションの抽出

関心事の抽出レビュー観点の導出・粒度調整＜ レビュ ー観点補充 フェーズ ＞
Step2-1

Step2-2

レビュー観点の体系的整理

レビュー観点の補充

図1

レビュー観点

成果物レビュー

実施フロー

本手法は,開発計画時から実施可能である.ただし,仕様不明確や仕様変更が生じることを考慮し,仕様確定時や成果物レビュー前に適宜更新をかけることを推奨する.
本手法の実施者は,レビュー対象物のレビューアを想定している.ただし特に制限は無く上級レビューアや各ステークホルダーも可能であれば適宜参加することが望ましい.
なお,類似/派生開 発では,過去作成した観 点をベースに更新することでノウハウの継承と負荷軽減が期待できる.
2.4.2 提案手法の詳細
手法の実施手順詳細について述べる.各 Step により導出されるレビュー観点のイメージを図 2 に示す.

図2

レビュー観点の導出例3

第 2 研究コース（観抽 Hi グループ）■■Step1 観点導出フェーズ
Step1 にて,ステークホルダーとアクションに基づくレビュー観点の導出を行う.(表 2)
表 2 Step1 レビュー観点導出フェーズの各ステップの実施事項
実施事項/例/留意事項【実施事項】
Step1-1
開 発 対 象 の 製品 ラ イ フサ イ ク ル を もと に ,製 品に 関 わ る 全 て の ス テーク ホルダーを抽出する.
ス テークホル 【 例 】
Step

ダ ーの抽出ユーザー,企画,営業,設計,コーダー,テスター,保守,販 売,製造,運送,サービス<Stakeholder>【留意事項】

Step1-2【実施事項】
各ステークホルダーが目的を達成するために行うアクションを抽出する.
【例】

ア クションの抽出<Action>

Step1-3
関 心事の抽出<Kanshingoto>

組織図やプロジェクト体制表が存在する場合はこれらを参考にする.
ス テー ク ホル ダー は,悪 意を 持 った 人物 や 子供のよ うな ,意 図しない 結 果を 生み出す 可能性がある人物も含めて抽出することで,多様な観点を 導出することができる.
人 以外 の 「物 」（周辺シ ステ ム や関 連製 品 など）を 挙げ る こと で,直 接 的に 観点を導 出しやすい場合もあるため,必ずしも「人」でなくても良 い.
当 Step の 効果と効率性を高めるため, 一般的な製品開発に共通して登場すると想定されるステークホルダーの一部を筆者らが記載した「レビュー観点導出マインドマップ」(付録 1)をベースに,対象製品に応じたステークホルダ ーを抽出しても良い.

設計者：「設計書を作成する」→「機能ブロックの抽出 ,I/F 設計,リソース見積もり」【留意事項】
アクションを分解することで,より具体的なレビュー観 点導出が期待できる.
専 門 性 の 高 い ス テ ー ク ホ ルダ ー の ア ク シ ョ ン に つ い て は ,開 発 プ ロ セ ス や 作 業 手順 書等を参考にする.「物」の場合は,仕様や説明書を参考に,動作や開発対象製品にどのように関わるのかを抽出する.

【実施事項】
各ステークホルダーのアクション実施時における,レビュー対象製品,または開発成果物に対するステークホルダーの関心事を抽出する.
【例】
情 報を 入 力す る：「 少ない手 数で 入 力を 完了した い（期 待 ,要 望）」「誤 っ た値を入 力できてしまわないか（懸念）」,「どんな文字形式も入力できるのか(疑問)」【留意事項】
関 心事 は ,各 ス テー クホルダ ーが 製 品や 各開発成 果物に 対 し て持つ期 待,要 望,懸念,疑問 など の 要素 であ り,要 求事 項 の源 泉と な るもので ある .製 品や各開 発 成果 物とその 人との関係性の違いを考慮しながら,以下の点に留意して 関心事を抽出すると良い.
◯期待・要望：各アクション達成のために,製品や成果 物に対して許容できる,又はより良い状態を想定する.
(表現例：「xx であってほしい, xx あるべきだ」など.)◯懸念：各アクションの達成を阻害する要因を想定する.
(表現例：「xx となってしまわないか」など.)◯疑問：各アクション達成のために確認すべき事項,不明点を想定する.
(表現例：「xx は何か, xx はどうであるか」など.)
な お ,関 心 事 を 想 起 す る こ と が 難 し い 場 合は ,上 級 レビ ュ ー ア や ,各ス テ ー ク ホ ル ダ ーへのインタビューを行うことも有効である.

Step1-4
レ ビュー観点の 導出・粒度調整<Extraction>【実施事項】
関 心 事 か ら 想起 さ れ るレ ビ ュ ー 対 象物 で 確 認す べ き 事 項を 検 討 の上 ,適切な粒度のレビュー観点を導出する.
【例】
誤った値を入力できてしまわないか：「入力ミス検出機能はあるか」→「不正文字検 出機能はあるか」【留意事項】
レビュー観点は，Step1-3 で抽出した関心事に対し,期待・要望を達成するために,懸 念を 回避 す るた めに ,疑問 を解 消 する ため に ,レビ ュー対 象 物 がどのよ う な状 態である べきかを検討し,導出する.
ま た,レ ビュ ー 観点 の適切な 粒度 は ,レ ビ ュー アの知識 ,経験 によ っ て異 なるため ,レ ビ
ュ ー ア の 能 力 に 応 じ て 調 整す る .適 切 な 粒度 の 目 安 と し て は ,そ の 観 点 の 内 容 か ら ,レビ ュー ア 自身 が『 レビ ュ ー対 象物 の 該当 箇所 』と 『 ある べき 状 態』 を想 起で き る程 度で あ る こ と が 望 ま し い .必 要 に 応 じ て ,上 級 レ ビ ュ ーア や ,該 当 す るス テ ー ク ホ ル ダ ー
等に確認をとりながら行うことで,必要な観点の導出漏 れを防ぐことができる.
Step1-3 で抽出した関心事がレビュー観点として十分に具体的に表現できていれば,関心事をそのまま観点としても良い.

4

第 2 研究コース（観抽 Hi グループ）■■Step2 レビュー観点補充フェーズ
Step2 に て ,レ ビ ュ ー 観 点 特 性 表 で レ ビ ュ ー 観 点 を 体 系 的 に 整 理 し た 上 で ,観 点 を 補 充 する.(表 3) レビュー観点特性表は, 多様なステークホルダ ーや多様な工程に於いての特性を含め ることができるよう に,SQuaRE 品 質 特性 を ベー スに,非機能 要求グレー ドやドキュメント品
質特性など一般的に体系化された多様な特性 [1][3][4][5][6][7] を追加・統合して,筆者らが作成した特性表である(付録 2,3). なお , 本手 法が対 象とする開発工 程（2.1 項に記載）を想定し,各工程に於いて関連する特性を収集して作成している(付録 2,3).

表 3 Step2 レビュー観点補充フェーズの各ステップの実施事項
Step
実施事項/留意事項【実施事項】
Step2-1
Step1 で導 出 し たレ ビュ ー 観 点を レ ビュ ー 観点 特 性 表に 当 て は め て体系的に整理する.
レビュー観点の【留意事項】
体 系的整理<Systematization>

Step2-2
レビュー観点の補充<Replenishment>

特 性 表 全 体 を 必 ず し も 利 用 す る 必 要 は な く ,プ ロ ジ ェ ク ト や レ ビ ュ ー 対 象 物 の 特性に 応じて必要な部分を取捨選択して利用すれば良 い.

【実施事項】
レビュー観点特性表を俯瞰的に観察し,観点を補充する.
【留意事項】
観 点 の 分 布 が レ ビ ュ ー 対 象 の 特 性 を 踏 ま え て 適 正 だ と 言 え る か ,特 性 を 視 点 に 大
局 的 に 確 認す る .観点 の 分 布の 偏 り等 か ら,必 要 な 観 点 の 導出 漏 れに 気 づい た 場 合は,新たに観点を追加する.必要に応じて,追加した観点に対して, Step1-4 に示す
手順 により適切な粒度に調整すると良い. (図 3 参 照)

図 3 レビュー観点特性表 観点当てはめ結果例（某システムにおける実施例）
レビュー実施時の留意事項
 Step1,Step2 で導出したレビュー観点を観察しながらレビューを実施する.
 各レビュー観点を一つ一つ確認すると膨大な時間を要するため,ステークホルダー,アクション,関心事などのカテゴリから,複数の観点を観察しながら実施すると良い.
3. 解決策の検証
3.1 検証の目的
提案手法(以下,SAKE と呼ぶ)の方針で述べた「上級レビューア以外が上級レビューアに近いレベルで欠陥を検出できること」,「ステークホルダーからレビューアのスキルに応じた粒度の観点を導出できること」を検証する.
3.2 検証手順・筆者らを除く所属各社の被験者を,レビューア経験年数が 7 年以上を上級レビューア,7年 未満 を 上 級 レ ビ ュ ー ア 以 外 と し て ス キ ル 別 に 分 類 す る .た だ し ,経 験 年 数 に 因 ら ず判断できる場合はその分類に従う.また,レビューアはグループ A/B に分ける.
5

第 2 研究コース（観抽 Hi グループ）
グループ A : 上級レビューア 3 人,上級レビューア以外 9 人
グループ B : 上級レビューア 5 人,上級レビューア以外 7 人
・特殊なドメイン知識を必要としない同じ規模の仮想の仕様書を 2 つ用意する.
仕様書 X : 旅費精算システムソフトウェア要求仕様書(7 ページ,2883 字)仕様書 Y : ヘリコプター予約システムソフトウェア要求仕様書(6 ページ,3391 字）
・被験者は,表 4 に示す手順で計 2 回のレビューを実施する.この時,SAKE を経験したことによる優位性が出ないよう,先に RBR,次に SAKE の順とする.また,RBR の前にステークホルダー例を,SAKE の前にレビュー観点導出例を提示する.実験は個人で行う.
・レビューで検出した欠陥は,知見分析表 [8] に基づいて影響と緊急度を判定し,重大欠陥/中 程度 欠 陥 /軽 微欠 陥 の 平 均 件 数 を 比 較 す る.な お ,判 定 基 準 を統 一 す る た め ,筆 者の内 2 名を最終判定者とし,他の筆者が一次判定した後,最終判定者が再判定を行う.
表 4 レビュー方法
レビュー対象物
目安時間

グループ A
グループ B
準備
レビュー

1 回目：RBR
仕様書 X (旅費精算システム)
仕様書 Y (ヘリコプター予約システム)
10 分（ステークホルダー導出）
30 分

2 回目：SAKE
仕様書 Y (ヘリコプター予約システム)
仕様書 X (旅費精算システム)
90 分（レビュー観点導出）
30 分

3.3 検証結果(1)上級レビューア以外でも上級レビューアに近いレベルで欠陥を検出できること検出した欠陥の平均件数を図 4 と付録 7 に示す.仕様書 X,Y ともに SAKE では中程度以上の欠陥が大きく増えた(①).次に,上級レビューアと上級レビューア以外の結果を比較すると,どちらも SAKE の欠陥総数が増えた.特に上級レビューア以外の中程度以上の欠陥が大きく増えた(②).最後に,中程度以上の欠陥において,上級レビューア以外の SAKE の件数(9.37 件/人)が,上級レビューアの RBR の件数(9.63 件/人)とほぼ同程度まで向上した(③).
欠陥数の分布を見ても全体的に向上している(付録 8).個人差はあるが平均値で見て(付録9),上級レビューア以外でも上級レビューアに近いレベルで欠陥を検出できたと言える.

図 4 検出した欠陥の平均件数(2) ステークホルダーからレビューアのスキルに応じた粒度の観点を導出できること
SAKE で中程度以上の欠陥の検出に寄与した観点の粒度について検証した結果を図 5 に示
す.粒度の細かさは,検出された欠陥と対応する観点の記述が,同等レベルまで具体化されている(＝粒度が細かい)か,されていない(＝粒度が粗い)か,で測った(表 5).図 5 に示す結果から,仕様書 X,Y ともに粒度は個々人で異なり,スキルによる傾向は見えなかった.
6

第 2 研究コース（観抽 Hi グループ）
表 5 観点の粒度の例
粒度観点

検出された欠陥細かい

社内 システムと連携 は問 題ないか

社内 システムとの連 携確 認はないのか？

粗い機能 要 件は十 分か？

明細 欄には交 通費 精 算データが入力 できるとあるが,入 力 する機 能がない

図 5 観点粒度ごとの 欠陥検出数(比率)3.4 考察【考察 1 上級レビューアに近いレベルで欠陥を検出できることについて】
上級レビューアのアンケートに「関心事の洗い出しまでは,ほぼ,通常のレビューにおいて脳内でやっている作業に近い」とあり,SAKE が上級レビューアの思考プロセスに近いことで図 4 の②,③の結果を得たと推察できる.このことから,SAKE は上級レビューア以外が上級レビューアの思考プロセスを学ぶ手段ともなり得る.また,SAKE の手順に沿ったことで,上級レビューアが脳内に持つ観点やノウハウの一部がレビュー観点として表出したと考える.すなわち,SAKE を繰り返し実践することで上級レビューアの思考プロセスが身につき,観点導出結果を参照することで,他のレビューアが持つ知見やノウハウを吸収できる.レビ
ューア育成に有効な手法とも言えるのではないかと考える.
【考察 2 観点の粒度について】
上級レビューアの観点は粒度 が粗くなると考えていたが,検証結果(2)より,傾向は見られなかった.これは,適 切と思う観点の粒度は,スキルに因らず個々人で異なることを示唆している.検証結果(1)から,SAKE によって上級レビューア以外でも欠陥検出できる粒度の観点が出せた可能性はあるが、観点の粒度が結果にどう寄与するか更なる検証が必要である.
【考察 3 欠陥検出の増加について】
SAKE の方がより多くの欠陥を検出(図 4 の①)できた理由について考察する.
【考察 3-1】欠陥の内容を見ると,RBR は主に正常系の事柄や仕様書の文言から想起しやすい欠陥だったが,SAKE は保守や例外事象,連携するシステム,利便性および機能の妥当性に関わる欠陥が増えた.
[SAKE の欠陥例]「予約画面で他の利用者の予約情報が見られるのは適切か？」
これは,ステークホルダーからアクションと関心事を明らかにしたことで,人やシステムの背景をよ り 深く 理解し,何が適切 で 何が 不適切 かを具体 的に想起できたためと考える.
【考察 3-2】中程度以上の欠陥に着目すると,SAKE の Step1
で得た観点による検出数(9.21 件)は,RBR による検出数(5.92件)よりも多かった(図 6 の①).これは,レビュー観点特性表を 用 い ず と も,一 定 の 効 果が あ る こ と を 示 し て い る .加 えて,SAKE の Step2 で得た観点でも 1.79 件(図 6 の②)を検出した.Step1 で得た観点を Step2 で特性の視点から見直すことで,大きな漏れや思考の偏りに気付けたためと考える.
【考察 3-3】SAKE の観点導出結果は,それ自体が異なる粒度の
図 6 Step 毎の欠陥検出数7

第 2 研究コース（観抽 Hi グループ）
観点と相互の関連を表現したものである.SAKE では観点を一つ一つチェックするのではな
く,「レビュー観点導出マインドマップ」を俯瞰して,複数の観点を観察しながらレビューするため,ある観点の周囲にある別の観点を見て気付 きを得て欠陥数が増えた可能性もあり,今後の検証が必要である.
【考察 4 SAKE の準備時間ついて】
実験では,SAKE の準備に多くの時間をかけたが,RBR と SAKE について,欠陥検出数と準備を含めた作業時間の関連は検証できていない.これら時間と欠陥検出数の比較や,欠陥流出した時の手戻り時間も踏まえた SAKE の効果について,今後の検証が必要である.
4.
まとめ
4.1 結論本研究では,上記で述べた課題について,ステークホルダーごとのアクションと関心事からプロジェクトやレビュー対象物に合わせたレビュー観点を導出し,SQuaRE 品質特性やドキュメント品質特性などの大 きな視点への当てはめにより,重要な観点の漏れがないかを確認する手法『SAKE（Stakeholder Action Kanshingoto Extraction) Method』を考案した.
筆者らの所属各社にて本手 法を適用した実験を行い,上級レビューア以外でも上級レビューアと同等の欠陥を検出で きたことから,本手法で プロジェクトやレビュー対象物の特性を踏まえたレビュー観点の導出が可能となったと想定できる.一方で,レビュー観点の粒度と欠陥検出数の相関関係を判断できるだけの明確な結果は得られなかった.
なお,上級レビューアも従来の RBR でレビューを実施した場合と比べて,本手法を使った場合の方がより多くの欠陥を検出でき,「 本手法は頭の中で行っている手順を見える化した内容になっている」との意見が複数寄せられた.このことから,上級レビューアにとっても有効な手法であると言える.
4.2 今後の課題本手法を実際の現場へ普及させるために取り組むべき課題を挙げる.
・開発する製品やレビュー対象物に応じて必要な特性が異なるため,レビュー観点補充フェーズでより大きな効果を得るには,事前に適切な特性を選ぶ必要がある.この選び方やレビュー観点特性表自体の利用方法については今後の検討が必要である.
・個々人のスキルに応じた観点を導出する際にどのような要因が関与するのか,それが粒度設定や欠陥検出結果にどのように関係するのかは,今後さらに検証が必要である.
・SAKE の時間短縮が課題である.そのために例えば,他者の「レビュー観点マインドマップ」を流用してレビューアに応じた粒度の再調整を行う方法や,状況に応じて SAKE の手順を簡略化する方法が考えられる.今後,これらの検討と検証が必要である.
・今回検証対象外の開発工程成果物,実プロジェクトの成果物に対する検証も必要である.
参考文献[1]「つながる世界のソフトウェア品質ガイド」,IPA,2015
JIS X 25010：2013 (ISO/IEC 25010：2011)，JIS X 25012：2013 (ISO/IEC 25010：2011)[2]「組み込みソフトウェア向け開発プロセスガイド」,IPA-SEC,2007[3]「テスト技術者資格制度 Foundation Level シラバス Version2018 V3.1」,JSTQB,2021[4]「非機能要求グレード 2018」,IPA,2018[5]「システム開発文書品質モデル Ver1.1」,システム開発文書品質研究会,2018[6]「Google’s Engineering Practices Documentation」,
https://google.github.io/eng-practices/[7]「 情報処理システム高度信頼化教訓集（IT サービス編）別紙：障害事例一覧表」,IPA,2020[8] 今村 陽介,他,「 レビュー指摘を軽微欠陥から重大欠陥へシフトさせるレビュー時の新規役割「ハーベスタ」の提案」, SQiP 研究会 (2013 年度)研究コース 2(K チーム),20148