2016年11月12日 NaITE#18 勉強会(＠ワークプラザ勝田)での資料です。

1. ISO/IEC DIS 20246について
(ごく簡単な)説明
2016年11月12日＠ワークプラザ勝田
すずき しょうご
NaITE #18

2. 自己紹介
• すずき しょうご
• 某メーカ系関連企業の企業向けソフトウェアの品質保証部門
• 設計レビュー / プロセス改善 / ソフトウェアテスト
• JCSQE初級、JSTQB FL/AL(Test Manager)
• 「バグ票ワーストプラクティス検討プロジェクト」メンバ
– 「バグレポートの改善に向けた問題事例の調査とアンチパターン化」
ソフトウェア品質シンポジウム2013(Best Paper Future Award受賞)
JaSST’14 Tokyo 経験発表
– 「バグレポートの改善に向けた問題事例の調査とアンチパターンの作
成」
ソフトウェア品質シンポジウム2014招待講演
Twitter ： @rin2_

3. 今日お伝えしたいこと
• ソフトウェア評価の規格の流れ
• 規格を知る意義
• 規格について
– 国際規格について
– ISO / IEC
• 作業成果物レビューの国際規格について
– ISO/IEC DIS 20246

4. 目次
• レビューについて思うこと
• 今日のテーマ
• ソフトウェアの評価の規格のトレンド
– ISO/IEC/IEEE29119ファミリ
– ISO/IEC DIS 20246
• ISO/IEC DIS 20246の内容説明
• まとめ

5. レビューについておもうこと
• 集まって話せば欠陥がでてくる？
• レビューの目的はなにか？
レビューを行なうことが
目的になっていないか？
• 他の組織やプロジェクトの
レビューは知らないことが多い？
• いいレビューと、
そうでないレビューの違い？

6. 今日のテーマ
• なぜ、規格か？
– 評価(テスト、レビュー)のやり方を知る
• 他の組織ではどうやっているか？
• テスト・レビューの共通認識はどのようなものか？
– 共通認識から、自分たちのプロセス改善を行なう
• 0から作るよりも効率的
• パートナー企業も同じ認識だと、仕事が楽になる、カモ

7. ISO/IEC/IEEE29119ファミリー
• ソフトウェアテストに関する国際規格
(2013年9月1日初版発行)
– ISO/IEC/IEEE29119 Part1 概念と定義
– ISO/IEC/IEEE29119 Part2 テストプロセス
– ISO/IEC/IEEE29119 Part3 テストの文書
– ISO/IEC/IEEE29119 Part4 テスト技法
– ISO/IEC/IEEE29119 Part5
キーワード駆動テスト
– ISO/IEC 33063
テストプロセスアセスメント
– ISO/IEC 20246(DIS)
作業成果物のレビュー
ISTQB
• ソフトウェアテストに関する
スキル認定の枠組み
(2002年11月設立)
– Foundation Level(FL)
– Advanced Level(AL)
• Test Manager
• Test Analyst
• Technical Test Analyst
– Expert Level
• Test management
• Improving the Test Process
• 日本においては、JSTQB
国際的なソフトウェアテスト共通認識
2つのトレンド

8. ISO/IEC/IEEE 29119ファミリー
Part.1 Concept & Definitions
Part.2 Test Process
Part.3 Test Documentation
Part.4 Test Techniques
Part.5 Keyword Driven
Testing
ISO/IEC 33063
Process assessment model for
software testing
参考：ソフトウェアテストの国際標準(ISO/IEC/IEEE29119シリーズ)の活用 (情報処理学会 短期集中セミナー 2016/7/15)
ISO/IEC 20246
Work Product Reviews
IEEE829
Test Documentation
IEEE1008
Unit Testing
ISO/IEC/IEEE29119
動的テスト
静的テスト

9. ご参考：ISO/IEC/IEEE29119
• IVIAからの日本語補助資料
• 勉強会
– 第1回 規格の全体構成と各規格の概要
– 第2回 テストプロセス
– 第3回 テストドキュメント
• WACATE
– 1時間でわかった気になるISO29119

10. 規格名の説明
• ISO/IEC DIS 20246
– ISO : International Organization for Standardization
• 国際標準化機構
• 国際間の取引をスムーズにするために共通の基準策定
– 例：ISO 9000シリーズ（品質マネジメントシステム）
ISO 14000シリーズ(環境マネジメントシステム)
– IEC : International Electrotechnical Commission
• 国際電気標準会議
• 電気工学、電子工学、および関連した技術を扱う国際的な標
準化団体
– DIS : Draft International Standard
• 国際規格案
• 案なので、今後内容等が変わることもありえる。

11. 国際規格のステータス
• 20246の現在状況
（2016/11/12）
– DISはドラフト版
– まだ正式には
国際規格とは
なっていない
– 現在、DIS投票中
出典：http://www.jsa.or.jp/wp-content/uploads/1_08.pdf

12. ISO/IEC DIS 20246とは
• システム開発、テスト、保守、管理に関する
作業成果物のレビューのための
汎用フレームワーク
• レビュー時の一般的な事項について記載
– 用語 /プロセス / アクティビティ / タスク /
レビュー技法 / ドキュメントテンプレート
• システムやソフトウェアに関わる全ての人が
利用可能

13. ISO/IEC DIS 20246の内容(1/2)
• スコープ
• 使用目的
• 用語定義
• 作業成果物レビュー
– レビューの属性
– レビュータイプ
• レビュープロセス
– モデル
– 目的
– 結果
– アクティビティ・タスク
• 計画
• レビュー開始
• 個人レビュー
• 問題の議論と分析
• 修正と議事録作成
– レビューに関する項目
• レビュー技法
– 個人レビューの技法
• アドホックレビュー
• チェックリストを使ったレビュー
• シナリオを使ったレビュー
• 観点を使ったレビュー
• ロールを使ったレビュー
– 問題分析の技法
– レビューミーティング技法
• ページ毎レビュー
• チェックリスト使ったレビュー
• ロールを使ったレビュー
• シナリオを使ったレビュー

14. ISO/IEC DIS 20246の内容(2/2)
• 問題の記録
– ドキュメントのID
– 発行者
– 承認権限
– 変更履歴
• インシデントレポート
– ドキュメントのID
– 発行者
– 承認権限
– 変更履歴
• レビュードキュメントの
フロー
• レビュー属性
– 目的
– ロール
• IEEE1028とのマッピング
• ツールサポート

15. 作業成果物とは
• 作業成果物
– 契約
– 設計仕様
– 開発計画
– 保守計画
– コード
– プロジェクト計画
– RFP/要求仕様
– テスト計画/テスト仕様
– ユーザマニュアル
• フォーマット
– テキスト
• 自然言語、コード
– シナリオ
• ユースケースフロー
– モデル
– 形式手法
– UML
ソフトウェア開発工程のすべての成果物が対象にできる

16. レビュープロセスとドキュメントの例
レビュー
計画
レビュー
開始
個人
レビュー
議論
分析
修正
報告
問題記述
深刻さ
ステータス
分担
レポート
インシデント
レポート
問題記録
参考：ISO/IEC DIS 20246 AnnexB Figure B.1 (20ページ)

17. レビューにあるもの
• レビューを考えるうえで必要なこと
– 目的
– 役割
– レビュー技法
– レビューワとレビューワ数
– レビュー計画とレビュー数
– レポート
– 教育
– レビューの改善
– 開始・終了基準

18. レビューのタイプ
• 作成者チェック
• 同僚のチェック
• 非公式なグループレ
ビュー
• インスペクション
• ピアレビュー
• ピアデスクレビュー
• テクニカルレビュー
• ウォークスルー
• どのタイプを使うかは
限定されない
• 組み合わせてもよい

19. アクティビティとタスク
• レビューが成功した結果
– 欠陥や問題点の検出・識別
– 品質特性の評価
– レビューワが新しい知見を得る
– 新たなアイディアが湧く
– 成果物のアップデート
– 作業に関する改善の可能性を認識する
レビュー
計画
レビュー
開始
個人
レビュー
議論
分析
修正
報告
得られることが
良いレビュー？

20. アクティビティとタスク
• レビュー計画
– 作業成果物の定義
– レビューで行なうこと、役割、技法、使用するする
チェックリスト等の合意
– レビューにおける役割と参加者の特定
レビュー
計画
レビュー
開始
個人
レビュー
議論
分析
修正
報告

21. アクティビティとタスク
• レビュー開始
– レビューに必要な資料の配布
• レビュー対象、チェックガイドライン・チェックリスト 等
– レビューリーダーは範囲、レビューに考慮することを
参加者へ通知
– 役割、責任、焦点を参加者に通知
– レビュー時に、作成者は成果物について説明してもよい
レビュー
計画
レビュー
開始
個人
レビュー
議論
分析
修正
報告

22. アクティビティとタスク
• 個人レビュー
– レビューワは、気になる点を特定する
レビュー
計画
レビュー
開始
個人
レビュー
議論
分析
修正
報告

23. アクティビティとタスク
• ディスカッションと分析
– 識別された気になる点について通知する
– 気になる点は、割り当てのために分析される
– 気になる点は、個人やチームに割り当てられる
– 成果物の品質特性を基準とともに評価する
レビュー
計画
レビュー
開始
個人
レビュー
議論
分析
修正
報告

24. アクティビティとタスク
• 修正とレポート
– インシデントレポートが作成され、割り当てられた人やチー
ムに通知される
– 変更が必要なものについて対応する
– 修正終了時、確認が行われ、最新版に更新される
– レビュー結果が満足されると、成果物が受け入れられる
– 結果の報告
レビュー
計画
レビュー
開始
個人
レビュー
議論
分析
修正
報告

25. レビュー技法
• 個人レビュー
– アドホックレビュー
– チェックリストベースドレビュー
– シナリオベースドレビュー
– パースペクティブレビュー
– ロールベースドレビュー

26. アドホックレビュー
• もっとも一般的なアプローチ
• 構造化されていない
• ガイドなどが提供されさない
• レビュー対象を順番に読んで欠陥を検出する
• レビューワのスキルに大きく依存
• 複数のレビューワで同じ問題が指摘される

27. チェックリストベースドレビュー
• チェックリストに基づいたアプローチ
• レビューワ毎に異なるチェックリストが割り当
てられる
– 広いカバレッジ
• チェックリストに限定されるあまり、他の問題
を見逃してしまう(無視されてしまう)
• レビューワの責任はチェックリストだけでない
ことを認識してもらう必要がある

28. シナリオベースドレビュー
• レビュー対象を読むためのガイドラインがある
• シナリオに記載されていない欠陥は
見落とす危険がある
• リスク情報を付加することにより
レビュー対象をより深く検討することが可能

29. パースペクティブレビュー(PBR)
• 異なるステークホルダの視点でレビュー対象を読む
• 視点の例
– ビジネスアナリスト
– 経営者
– 設計者
– 保守担当者
– マーケティング担当
– オペレータ
– プログラマ
– 装置
– テスター
– ユーザ

30. • レビュー対象に適したバランス
– 要件文書：ユーザ、設計者、テスターの視点
– 規制区域内のシステム：機器
– 長期間運用されるシステム：保守担当者
• アプローチの3つのポイント
– レビューで考えるべきステークホルダの視点を考える
– ステークホルダが期待している高品質な製品を考える
– 上記を説明するためのチェックリストを考える
• 再利用を考慮する

31. ロールベースドレビュー
• 異なるステークホルダーのロールから、
レビュー対象を評価する。
パースペクティブベースドレビューとの
違い？

32. アドホックレビュー チェックリスト
ベースドレビュー
シナリオベースド
レビュー
パースペクティブ
ベースドレビュー
ガイドラインの有無 × ○(チェックリスト) ○(シナリオ) ○(ステークホル
ダーの視点・観点)
長所 ・多くの欠陥を検出
可能
・チェックリストによ
る割当てにより、拾
いカバレッジが確
保可能
・指摘項目が重複
しにくい
・リスク情報を付加
することでより深く
チェック可能
・シナリオをレ
ビューワで分担す
るので、指摘事項
が重複しにくい
・「ドライラン」(予行)
により、利用時の欠
陥を検出できる
・狙った欠陥を検出
しやすい
・リスク情報を付加
することでより深く
チェック可能
・ステークホルダー
の観点で分担して
評価する評価する
ため、指摘事項が
重複しにくい
・観点のバランス、
組み合わせを考慮
する
・再利用できる
短所 ・レビューワのスキ
ル依存
・指摘項目が重複
する恐れ
・チェックリストにな
い不具合について
は見落とす
・チェックリストが長
くなりがち
・シナリオに含まれ
ていない不具合は
見落とす
・狙っていない欠陥
は検出にくい
・レビューワによっ
ては、観点を利用
にしくい
その他 ・レビュー対象(ドメ
インごと、製品ごと、
文書ごと)に異なる
チェックリスト
・定期的な更新

33. レビュー技法
• レビューミーティングでの技法
– ページ毎レビュー
– チェックリストベースドレビュー
– ロールベースドレビュー
– シナリオベースドレビュー

34. レビューの計測と改善
• レビュープロセス改善の必要性
– 短期的な目標
• 製品の欠陥検出 などなど
– 長期的な目標
• 開発とテストの実践
• 製品の品質の向上
実践結果からプロセス改善
定量的なメトリクスを収集し、
レビュープロセスの改善に繋げる

35. レビューのメトリクス
• 欠陥密度
– レビュー対象物の質
– ページあたりの欠陥数、FPあたりの欠陥率
• 欠陥混入率
– 工程別の開発プロセスの質
– ページあたりの欠陥数、機能あたりの欠陥数
• 欠陥検出率
– レビュー時間当たりの欠陥検出数
• レビュー進度
– ページあたりの時間

36. ツールによるサポート
• ツールによる効率化
– レビューワ間のコラボレー
ション・コミュニケーション
– 作業成果物のコメントをハ
イライトする
– コメント・修正と作業成果
物のトレーサビリティ管理
– レビューメトリクスの自動
収集
– 他ツールとの連携
• テスト管理ツール、BTS、
VCS、IDEとの統合
• 具体的なツール
– 文書のレビューツール
• C-Review Support
(クライム)
• Review Coordinator
(日立ソリューションズ)
– コードレビューツール
• Redmine Code Review
プラグイン
• Review Board
コードレビューツールについては、
IDE統合、ITS・BTS・VCS連携等ふくめて
いろいろ出ている。

37. まとめ
• ソフトウェア評価の規格の流れ
– ISO/IEC/IEEE29119シリーズ
– ISTQB
• 作業成果物のレビューの規格の紹介
– ISO/IEC DIS 20246

38. ご参考：レビューア心得十ヶ条と
レビューアべからず集
• レビューア心得十ヶ条
1. 技術に厳しく、人には優しく、楽しくや
ろう
2. 付加価値をつけて設計者を助けよう
3. 設計者の説明を最後まで聞こう
4. 設計者の考えを引き出す質問をしよ
う
5. できたことを認めて、ほめよう
6. 設計者が考えていない領域に視野を
広げよう
7. その場で決着をつける努力をしよう
8. 結果をみて、レビューの成果を真摯
に振り返ろう
9. 重大不具合から学んだことをすべて
頭に入れておこう
10. お客様の信頼を得るころを最後まで
あきらめない
• レビューアべからず集
1. やっていないことを責めてはいけない
2. ワークシートの書き方を指導してはいけ
ない
3. 言葉だけで確認するな 図面やモノを
みよ
4. DRは設計者にお墨付きを与える場では
ない
5. 説明者と同じ目線になるな
6. 知識や経験があることを誇示するな
7. 謙虚であれ(反り返るな、怒鳴るな、意
地を通すな)
出典：日産自動車における未然防止手法Quick DR 日科技連出版社 (2012/02)
レビューワが常に念頭におく心得 レビューワがやってはいけないタブー

39. 参考文献
• ソフトウェアインスペクション(共立出版)
Tom Gilb, Dorothy Graham
• ピアレビュー 高品質ソフトウェア開発のために
(日経BPソフトプレス)
Karl. E. Wiegars
本資料のイラストの一部は以下の
サイトから利用しました
• いらすとや
• http://www.irasutoya.com/