アジャイル品質保証の動向€¦ ·...

アジャイル品質保証の動向

SQiP2016

2015年 9月15日

SQuBOK V3 研究チーム

誉田直美（日本電気株式会社）

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の品質保証

今回は、アジャイル開発の品質保証の調査結果を報告

ソフトウェア品質シンポジウム2016


SQuBOK V3 研究チームメンバ一覧

▌大場みち子

公立はこだて未来大学システム情報科学部情報アーキテクチャ学科教授

▌沖汐大志

日本ユニシス株式会社品質保証部チーフ・スペシャリスト

▌服部克己

日本ユニシス株式会社品質保証部担当部長

▌藤原良一

三菱電機インフォメーションシステムズ株式会社生産技術本部品質保証部部長

▌誉田直美

日本電気株式会社ソフトウェアエンジニアリング本部主席品質保証主幹

▌森田純恵

株式会社富士通研究所ソフトウェア研究所主席研究員

（50音順）



用語の定義

▌アジャイル開発

所定の品質を確保したソフトウェアを，短期間で繰り返しリリースする手法

（出典：誉田直美、アジャイルと品質会計－プロジェクトの高成功率を確保するハイブリッドアジャイルへの取り組み－、情報処理学会デジタルプラクティス、Vol.7 No.3、2016）

▌品質保証

品質要求事項が満たされるという確信を与えることに焦点を合わせた品質マネジメントの一部

（注）要求事項：明示される、通常、暗黙のうちに了解されている若しくは義務として要求されている、ニーズまたは期待

（出典：ISO 9000:2005 Quality management systems –Fundamentals and vocabulary (JIS Q 9000:2006 品質マネジメントシステム –基本及び用語)）

※単にバグがないことや、開発したソフトウェアが明示された要求事項に合致していることを示す活動にとどまらず、顧客満足を目的とした活動とする


アジャイル開発とは



アジャイルソフトウェア開発宣言ソフトウェア品質シンポジウム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

分析からテストを一度に短期間で「ブレンド」して実施する



代表的なアジャイル開発方法論

出典：VERSIONONE、State of Agile Survey 9th annual、 http://info.versionoNECom/state-of-agile-development-survey-ninth.html （2016年7月28日現在）

• スクラムとＸP


http://info.versiononecom/state-of-agile-development-survey-ninth.html












アジャイル用語解説（スクラム、XP）

バックログ（要件一覧）

スプリント（繰り返し）1-4Ｗ程度

ストーリー（要件）

スプリントレビュー

プラクティスの適用 • ペアプログラミング• 継続的統合（ＣＩ）• リファクタリング• テスト駆動開発• ソースコードの共同所有

…

プロジェクトオーナーが動くＳＷにより開発結果を確認する場

スプリント計画

デイリースクラム（朝会）

優先順位の高い要件から選択

ふりかえり

今回のスプリントをふりかえり、やり方を最適化していく場

反復

10 ----------

35 ----------

ストーリーポイント・その要件を実現するのに必要な工数の相対値

＜役割＞ • プロダクトオーナー：開発するプロダクトの責任者。開発要件の

内容と優先順位を決定する。• スクラムマスター：プロダクトオーナーと開発チームが正しくス

クラムを実践するために支援する• 開発チーム：要件に従って開発する。3～9人の構成が望ましい


アジャイル品質保証の特徴



分析

設計

実装

テスト

スコープ

時間

ウォーターフォールモデル繰り返し開発 XP

品質保証の対象

出典： K. Beck, Embracing Change with Extreme Programming. Computer, 32, 70-77, 1999

分析からテストを一度に短期間で「ブレンド」して実施する

動くソフトウェア各工程の成果物



品質テスト機能的

受入テスト

ステークホルダー

へのデプロイ

製品計画ロードマップ

バックログスプリント計画

スプリント実施

デイリーレビュー

関係する品質タスクを含む

鍵となる品質シナリオの特定

品質シナリオを含む

品質シナリオ

アジャイル品質保証の仕組みと実例

▌品質保証に有効なプラクティスを中心に品質保証のしくみを構築

▌品質保証の対象は「動くソフトウェア」

出典：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成功率• 品質基準値に対する実績値• 非機能要件に対する達成度など



プラクティス中心の取り組み

▌チーム全体コンセプト

その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) –システム及びソフトウェア品質モデル)

<確認方法＞プロセス品質：プロセス実施状況の十分性により確認プロダクト品質（内部特徴）：開発中の中間製品に関する静的な測定量プロダクト品質（外部特徴）：ソフトウェア製品の実行時の振る舞いに関す

る測定量利用時の品質：顧客がソフトウェアを利用して確認（＝顧客満足）



アジャイル品質保証の特徴～ウォーターフォールモデルとの比較～

アジャイル品質保証ウォーターフォール品質保証

特徴的な方式プラクティス中心品質ゲート、ＱＡテストなど

プロセス品質・メトリクス測定値による確認（プラクティス適用による効果確認を含む）

品質ゲートによる確認・組織標準への準拠度合の監査・メトリクス測定値による作業十分性検証

プロダクト品質・内部特徴

・コードの静的解析結果品質ゲートによる確認・中間成果物のできばえ評価

・外部特徴・動くソフトウェアでの確認ＱＡテストによる確認・要件に対する適合など

利用時の品質・プロダクトオーナー（顧客）による動くソフトウェアでの確認*

・出荷後の顧客による確認

▌アジャイル品質保証で弱みになりそうな箇所

内部特徴によるプロダクト品質（特に実装設計）の確認

⇒補強の例：設計仕様書の作成を義務付けて、内容をレビュー

：強み

注）*：開発途中の混乱が直接顧客に伝わってしまうため、逆に顧客に不満をもたらす危険性の指摘もある


参考：ウォーターフォールモデルの代表的な品質保証方式

▌品質ゲート

▌ＱＡテスト

現工程次工程

• 収集データ分析による開発十分性の検証• 組織標準への準拠度合の監査• 中間成果物（設計仕様書など）の内容確認など

開発ＱＡテスト

• 開発チームとは別のＱＡチームが実施

• 要求を満足していることを確認することが目的

※ＱＡテストとして、中間成果物の評価を含む場合もあるが、この分類では、それは品質ゲートでの確認観点とした


まとめ

▌アジャイル品質保証では、動くソフトウェアによる顧客を含めた確認が大きな強み

▌一方、プロダクト品質の内部特徴による確認が乏しく、提案もない

設計仕様書の作成を義務付けて、内容をレビューするなどの施策が考えられる

▌本日紹介したアジャイル品質保証は、実効性の検証が必要

日本のウォーターフォール品質保証で既に実現済の内容が多い。プラクティス中心の実現方法は、逆に実効性が低下する危険性も考えられる

▌今後は、日本ならではのアジャイル品質保証方法論の確立を目指したい


アジャイル品質保証の動向€¦ ·...

Documents