アジャイル品質保証の動向
SQiP2016
2015年 9月15日
2 © NEC Corporation 2016
自己紹介
氏 名：誉田 直美（ほんだ なおみ） 現 職：日本電気㈱ ソフトウェアエンジニアリング本部 主席品質保証主幹 上席ソフトウェアプロセス＆品質プロフェッショナル 略 歴： 日本電気株式会社入社以来、ＩＴ系ミドルソフトウェア/基本ソフトウェアなど汎用ソフトウェア製品の品質保証およ びCS向上に従事。2007年より統括マネージャー。2011年より現職。現在はNEC全体のソフトウェア品質・生産性向上 を担当。工学博士。 主な著書・執筆活動： ソフトウェア品質知識体系ガイド 第2版 -SQuBOK Guide V2- （オーム社、共著（執筆リーダー）） 2014年11月 発行 ソフトウェア品質会計（日科技連出版）2010年発行 ＜2010年度 日経品質管理文献賞受賞＞ ソフトウェア品質知識体系ガイド –SQuBOK Guide- （オーム社、共著）2007年11月発行＜2008年度 日経品質管 理文献賞受賞＞ ソフトウェア開発 オフショアリング完全ガイド（日経BP社 共著）2004年10月発行 見積りの方法（日科技連出版、共著）1993年 受賞： プロジェクトマネジメント学会 文献賞（2016/9） 第5回世界ソフトウェア品質国際会議（5WCSQ）最優秀論文賞および最優秀発表賞（2011/11） 第4回世界ソフトウェア品質国際会議（4WCSQ）最優秀論文賞（2008/9） 学会：情報処理学会、電子情報通信学会、品質管理学会、プロジェクトマネジメント学会 社外活動： 日科技連SQiPソフトウェア品質委員会 副委員長 プロジェクトマネジメント学会 上席研究員、国際委員 筑波大学 非常勤講師（2012年～）本発表内容について
▌
アジャイル開発の品質保証の世の中動向を調査した結果
▌
調査方法
論文（海外、国内）約35編（最近10年間を中心に） Webサイト、書籍 ※日本の事例は少なく、海外事例が主▌
調査した結果、複数の提案があった手法を整理・分析して発表
事例の規模：数人～数十人（グローバル分散開発）、研究レベル～軍事用システム開発▌
本発表までの経緯
「日本におけるソフトウェア品質保証」(SQuBOK V2 1.3.6章)の研究チームとして発足 日本と海外の特徴を比較するべく、品質保証の最新動向を調査したところ、最近は以下の テーマが多いことが判明 • アジャイル開発の品質保証 • クラウドの品質保証 • OSSの品質保証 今回は、アジャイル開発の品質保証の調査結果を報告4 © NEC Corporation 2016
SQuBOK V3 研究チーム メンバ一覧
▌
大場 みち子
公立はこだて未来大学 システム情報科学部 情報アーキテクチャ学科 教授▌
沖汐 大志
日本ユニシス株式会社 品質保証部 チーフ・スペシャリスト▌
服部 克己
日本ユニシス株式会社 品質保証部 担当部長▌
藤原 良一
三菱電機インフォメーションシステムズ株式会社 生産技術本部 品質保証部 部長▌
誉田 直美
日本電気株式会社 ソフトウェアエンジニアリング本部 主席品質保証主幹▌
森田 純恵
株式会社富士通研究所 ソフトウェア研究所 主席研究員（50音順）
用語の定義
▌
アジャイル開発
所定の品質を確保したソフトウェアを，短期間で繰り返しリリースする手法 （出典：誉田直美、アジャイルと品質会計－プロジェクトの高成功率を確保するハイブリッ ドアジャイルへの取り組み－、情報処理学会デジタルプラクティス、Vol.7 No.3、2016）▌
品質保証
品質要求事項が満たされるという確信を与えることに焦点を合わせた品質マネジメントの 一部 （注）要求事項：明示される、通常、暗黙のうちに了解されている若しくは義務として要求 されている、ニーズまたは期待（出典：ISO 9000:2005 Quality management systems –Fundamentals and vocabulary (JIS Q 9000:2006 品質マネジメントシステム –基本及び用語)）
※単にバグがないことや、開発したソフトウェアが明示された要求事項に合致していること を示す活動にとどまらず、顧客満足を目的とした活動とする
8 © NEC Corporation 2016
アジャイルソフトウェアの１２の原則
私たちは以下の原則に従う
1.
顧客満足を最優先し、価値のあるソフトウェアを早く継続的に提供します。
2.
要求の変更はたとえ開発の後期であっても歓迎します。変化を味方につけることに
よって、お客様の競争力を引き上げます。
3.
動くソフトウェアを、2-3週間から2-3ヶ月というできるだけ短い時間間隔でリリー
スします。
4.
ビジネス側の人と開発者は、プロジェクトを通して日々一緒に働かなければなりま
せん。
5.
意欲に満ちた人々を集めてプロジェクトを構成します。環境と支援を与え仕事が無
事終わるまで彼らを信頼します。
6.
情報を伝えるもっとも効率的で効果的な方法はフェイス・トゥ・フェイスで話をす
ることです。
7.
動くソフトウェアこそが進捗の最も重要な尺度です。
8.
アジャイル･プロセスは持続可能な開発を促進します。一定のペースを継続的に維持
できるようにしなければなりません。
9.
技術的卓越性と優れた設計に対する不断の注意が機敏さを高めます。
10.
シンプルさ（ムダなく作れる量を最大限にすること）が本質です。
11.
最良のアーキテクチャ・要求・設計は、自己組織的なチームから生み出されます。
12.
チームがもっと効率を高めることができるかを定期的に振り返り、それに基づいて
自分たちのやり方を最適に調整します。
分析 設計 実装 テスト スコープ 時 間 ウォーターフォールモデル 繰り返し開発
XP
ウォーターフォールモデル、繰り返し開発、XP
出典： K. Beck, Embracing Change with Extreme Programming. Computer, 32, 70-77, 1999
分析からテストを一度に短期間で 「ブレンド」して実施する
10 © NEC Corporation 2016
代表的なアジャイル開発方法論
出典：VERSIONONE、State of Agile Survey 9th annual、
http://info.versionoNECom/state-of-agile-development-survey-ninth.html （2016年7月28日現在）
アジャイル用語解説（スクラム、XP）
バックログ （要件一覧） スプリント （繰り返し） 1-4Ｗ程度 ストーリー （要件） スプリント レビュー プラクティスの適用 • ペアプログラミング • 継続的統合（ＣＩ） • リファクタリング • テスト駆動開発 • ソースコードの共同所有 … プロジェクトオーナーが 動くＳＷにより開発結果 を確認する場 スプリント 計画 デイリースクラム （朝会） 優先順位の高い 要件から選択 ふりかえり 今回のスプリントを ふりかえり、やり方 を最適化していく場 反復 10 --- 35 --- ストーリーポイント ・その要件を実現す るのに必要な工数の 相対値 ＜役割＞ • プロダクトオーナー：開発するプロダクトの責任者。開発要件の 内容と優先順位を決定する。 • スクラムマスター：プロダクトオーナーと開発チームが正しくス クラムを実践するために支援する • 開発チーム：要件に従って開発する。3～9人の構成が望ましい分析 設計 実装 テスト スコープ 時 間 ウォーターフォールモデル 繰り返し開発
XP
品質保証の対象
出典： K. Beck, Embracing Change with Extreme Programming. Computer, 32, 70-77, 1999
分析からテストを一度に短期間で 「ブレンド」して実施する
動くソフトウェア
各工程の成果物
14 © NEC Corporation 2016 品質テスト 受入テスト 機能的 ステーク ホルダー への デプロイ 製品計画 ロード マップ バックログ スプリント 計画 スプリント実施 デイリーレビュー 関係する品質タスク を含む 鍵となる品質シナリオ の特定 品質シナリオ を含む 品質シナリオ
アジャイル品質保証の仕組みと実例
▌
品質保証に有効なプラクティスを中心に品質保証のしくみを構築
▌
品質保証の対象は「動くソフトウェア」
出典：Joseph Yoder, et all, QA to AQ - Patterns about transitioning from Quality Assurance to Agile Quality-, 3rd Asian Conference on Pattern Languages of Programs (AsianPLoP), 2014
品質ダッシュボードによる情報共有
▌
日々の開発状況を表す測定結果などを集め、一か所に表示して情報共有
アジャイル開発は、構成管理、CI、自動テストなどのツール支援が前提 ⇒様々な数値を、自動的に収集可能なため、その利用による品質向上の取り組みが多い ＜例＞ 静的解析ツールの実行結果から、コーディングの課題を抽出し、コーディング規則を改訂 非機能要件の達成度の明示により、非機能要件の重要性を徹底 など 開発ツール類 品質ダッシュボード 自動 手動 コード中心の測定結果• 行数（実行、コメント、空行別など） • 複雑度 • ネスト • 静的解析ツールの実行結果 （重要度別 など） • バグレポート開発環境
リポジトリ テスト結果 • テストカバレッジ • テスト進捗状況 その他の測定結果 • CI成功率 • 品質基準値に対する実績値 • 非機能要件に対する達成度 など16 © NEC Corporation 2016
プラクティス中心の取り組み
▌
チーム全体コンセプト
そのSW開発に必要なメンバ全員（開発者、QAはもちろん、プロダクトオーナー、ビジネ スアナリストなども含む）が一つのチームとして動く ＝品質確保は、QAだけでなく開発者自ら取り組むべきこと 開発者とQAがペアを組むことによる改善事例が複数 • QAが非機能要件の明確化に貢献 • QAの誤った機能仕様理解が減少し、QAが提出するバグレポートで的確な指摘が増加 など▌
バグを見つけたら即修正
（正確には、プラクティスではないが、プラクティスとして扱った事例が複数） このプラクティスが実行されると、常にクリーンなコード上での開発が実現 （ウォーターフォールモデルでの）出荷間際の未修正バグの修正優先順位の交渉が不要に▌
改善活動を包含
アジャイル開発は、振り返りが当たり前（「アジャイルソフトウェアの12の原則」参照） XPでは、バグの根本原因分析をプラクティスとして提案 ⇒開発チームが自発的に継続的改善へ取り組む基盤がある※（海外はともかく）日本のウォーターフォールモデル開発では、上記を
当たり前に実施している組織が多いと考えられる
アジャイル開発とウォーターフォールモデルのコアメトリクス
コアメトリクス
アジャイル
ウォーターフォール
サイズ
フィーチャー
ストーリー
FP（ファクションポイント）
UCP（ユースケースポイント）
品質
欠陥数/スプリント
欠陥数
MTTD（平均欠陥発生時間）
欠陥数/リリース
欠陥数
MTTD（平均欠陥発生時間）
工数
ストーリーポイント
人月
生産性
ベロシティ
（ストーリーポイント/スプリ
ント）
人時/FP…
▌
アジャイルメトリクスの特徴
開発チーム内でしか通用しない相対値の使用 • ストーリーポイント、ベロシティ… ⇒開発チーム間の比較や基準値の横展開が困難 開発規模が小さいために、測定値のばらつきが大きい ⇒測定値で品質の作り込み程度を把握するのが困難 バグのカウント開始時期の定義が難しいと思われる（定義している事例なし）出典： Joseph Yoder, et all, QA to AQ - Patterns about transitioning from Quality Assurance to Agile Quality-, 3rd Asian Conference on Pattern Languages of Programs (AsianPLoP), 2014
プロセス ソフトウェア製品 ソフトウェア製品の効果 プロセス品質 内部特徴 外部特徴 利用時の品質 影響 影響 影響 依存 依存 依存 プロセス測定 内部測定量 外部測定量 利用時の品質測定量 利用状況
ライフサイクルにおける品質
出典：ISO/IEC 25010:2011 Systems and software engineering –Systems and software Quality Requirements and Evaluation (SQuaRE) – System and software quality models (JIS X 25010:2013 システム及びソフトウェア製品の品質要求及び評価(SQuaRE) –システム及びソフトウェア品質モデル)
<確認方法＞
プロセス品質：プロセス実施状況の十分性により確認
プロダクト品質（内部特徴）：開発中の中間製品に関する静的な測定量
プロダクト品質（外部特徴）：ソフトウェア製品の実行時の振る舞いに関す
る測定量
利用時の品質：顧客がソフトウェアを利用して確認（＝顧客満足）
20 © NEC Corporation 2016
アジャイル品質保証の特徴 ～ウォーターフォールモデルとの比較～
アジャイル品質保証
ウォーターフォール品質保証特徴的な方式
プラクティス中心
品質ゲート、ＱＡテスト など
プロセス品質
・メトリクス測定値による確認
（プラクティス適用による効果
確認を含む）
品質ゲートによる確認
・組織標準への準拠度合の監査
・メトリクス測定値による作業
十分性検証
プロダクト品質
・内部特徴
・コードの静的解析結果
品質ゲートによる確認
・中間成果物のできばえ評価
・外部特徴
・動くソフトウェアでの確認
ＱＡテストによる確認
・要件に対する適合 など
利用時の品質
・プロダクトオーナー（顧客）
による動くソフトウェアでの確
認*
・出荷後の顧客による確認
▌
アジャイル品質保証で弱みになりそうな箇所
内部特徴によるプロダクト品質（特に実装設計）の確認 ⇒補強の例：設計仕様書の作成を義務付けて、内容をレビュー ：強み 注）*：開発途中の混乱が直接顧客に伝わってしまうため、逆に顧客に不満をもたらす危険性の指摘もある参考：ウォーターフォールモデルの代表的な品質保証方式
▌
品質ゲート
▌
ＱＡテスト
現工程
次工程
• 収集データ分析による開発十分性の検証
• 組織標準への準拠度合の監査
• 中間成果物（設計仕様書など）の内容確認 など
開発
ＱＡテスト
• 開発チームとは別のＱＡ
チームが実施
• 要求を満足していること
を確認することが目的
※ＱＡテストとして、中間成果物の評価を含む場合もあるが、この分類 では、それは品質ゲートでの確認観点とした22 © NEC Corporation 2016
