アジャイル開発における品質保証‘08.6.5 細谷泰夫
JaSST Kansai ‘08

アジェンダ• 何故アジャイルプロセスか？
• アジャイルプロセス導入の障壁
ジプ
障• 品質保証とは？
• ウォータフォールモデルでの品質保証のおさらい• XPにおける品質保証における品質保証• まとめ1

何故アジャイルプロセスか？

SW開発が直面する問題と取り組み

急激な大規模化
複雑化なプロジェ
クト崩れ

無計画なソフトウェア開発

開発プロセスの整備、ルール化な整備 ルール化な無計画な開発の減少、結果としてプロジェクト崩れの減少

一方で・・・

ルール化による弊害も現れている2

ルール化により現れた弊害
ルール化が間違っている訳ではない。
ルール化により初歩的な問題が解決し、新たな段階の問題が見えてきたルール化による改善パターン 改善前
不明確な仕様開発のゴールが見えない

低い見積もり精度、工程精度

予算超過、新たな要求が頻発、計画通りに進まない開発工程遅延ルール化により現れた弊害
ルール化が間違っている訳ではない。
ルール化により初歩的な問題が解決し、新たな段階の問題が見えてきたルール化による改善パターン 改善後
不明確な仕様
明確な仕様

開発のゴールが開発のゴール
見えないが見える高い見積もり精低い見積もり精度、工程精度度、工程精度

予算内、工程予算超過、工程遅延
遵守

新たな要求が頻
計画通りに実発、計画通りに行進まない開発これで開発が失敗することはない、めでたし、めでたし・・・

3本当にそうだろうか？
明確な仕様が決まらなければ？
着手しない

無理にでも仕様を決めて客先と合意する

不明確なまま着手

工程へのリスク大

工程、予算リスク小失敗のパターンに適合

本当にユーザが望んでいるシステムにならない可能性がある

いずれのパターンも失敗する。反省会の言葉はいつも「仕様は早期に決めましょう」
だったりしませんか？

実際問題として、ユーザが満足する仕様を早期にFIXするのはとても難しい。

アジャイル開発では？
「要求は変化するもの」が前提要求は変化するもの」が前提

開発側とユーザが協調して開発側とユザが協調してゴールを目指すことに重点4

明確な仕様が決まらなくても開発を短期のイテレーションに分割する
ユーザがイテレーションで実装するストーリー（要求）を開発側に提示するユーザが提示したストーリーを開発側が開発するユーザが受け入れテストを実施しストーリーが実現されているかを確認す
る

繰り返しの中で、ユーザは、自身が満足する要求を正確に掴み、正確に開発側に伝えられるようになる。
開発側は、ユーザが満足する要求についてユーザとイメージを共有できるようになる。

ユーザが満足するソフトウェアを適正な予算と期間で提供するための有効な方法としてアジャイルプロセスを導入する

アジャイルプロセス導入の障壁

5

書籍、シンポジウム、雑誌等でアジャイルが度々紹介されている認知度アップ。反面、実行している企業は多くはない

何故か？
アジャイルプロセスを導入する上で、様々な障壁が存在する。

契約

調達

品質保証

今回は品質保証に注目！

品質保証とは？

6

品質保証について考えてみる• 「品質保証」とは「品質」を「保証」すること• では、「品質」とは何か？

「ソフトウェア品質保証の考え方と実際」（日科技連）によると・・・
JIS、ISOの定義• 「品質とは、ユーザの要求（ニーズ、使用目的）を満足させるために製品（含むサービス）の持つべき特性である。」
クロスビー（P.Crosby）の定義• 「品質は「要求に対する適合」である」
ワインバーグの定義• 品質は誰かにとっての価値である。・・・• ここで価値という言葉は、「人びとはその要求が満たされるなら、喜んで対価を支払う（また何かをする）か？」ということを意味している。
品質保証の観点からの品質の定義• ワインバーグの言う「誰か」とは品質保証の観点では「ユーザ」であるべきと述べており、品質保証の観点での品質を以下のように定義している。
• 『品質は、ユーザにとっての価値である』• すなわち、『品質は、ユーザの満足度である』

7

品質とは、ユーザの満足度である

品質保証とは、製品が「ユーザの満足」を実現することを保証すること

ウォータフォールプロセス
ウォ
タフォ ルプロセスにおける品質保証

8Verification（検証） & Validation（妥当性確認）
Verification（検証）• 各開発工程が適切に実行されているかどうかをチェックすること
Validation（妥当性確認）• ソフトウェア開発工程の最後に、ソフトウェ
ソフトウ ア開発工程の最後に ソフトウ
アの要求事項に従っているかどうかを確認するためにソフトウェアを評価する工程
参考文献：ソフトウェア品質保証入門（日科技連）

V&Vの概念
妥当性確認
要求分析

検証

方式設計

検証

詳細設計

検証

コーディング、デバッグ

適格性テスト

結合テスト

単体テスト

検証

検証

検証

検証

検証の手段：品質メトリクスの実績と指標との差異分析による評価
評価対象となる品質メトリクスと実際の品質（ここでは要求を満たすこと）の相関関係を定義し、評価の根拠としている。

9

各工程で検証を行う理由
最大のリスクは「品質を満たさないソフトウェアが完成すること」

リスク対策として各工程で適切な開発が行われているかを検証することにより不適切な開発を早期に検出

不適切な工程については、是正処置を行い、後工程を適正化する

eXtreme Programmingにおけるi における品質保証

10

XPにおける開発の流れ
イテレーション（1～2週間）

計画ゲームゲム

受け入れテスト

開発

計画
ゲーム
ゲ
ム

開発

受け入れテスト

計画
ゲーム
ゲ
ム

開発

受け入
れテスト

・・・

イテレーション
• 1～2週間の定間隔の開発周期。
計画ゲーム• イテレーションで実施するストーリをユーザと開発側との共同作業により決定する。ストーリーは作成された時点で見積もりを実施する。
開発• 開発が決定したストーリーをタスクに分割し、実装する。タスクへの分割、共同設計（メタファ、概略モデル）、実装の流れ
受け入れテスト• ユーザがイテレーションの成果物であるソフトウェアがストーリーを満足しているかをテストする

XPのプラクティス（抜粋）イテレーションの開発段階

イテレーションの計画段階

計画ゲーム

ペアプログラ
ミング

常時結合

TDD

10分ビルドリファクタリング

ソースコードの共同所有

イテレーションの終了段階

受け入れテスト

プロセス全体で適用するコンセプト

全員同席

継続可能なペース

短期リリース

継続的な設計頻繁なふりかえり

この中で品質確保に直接関連するプラクティスは？

11XPのプラクティス（抜粋）イテレーションの開発段階

イテレーションの計画段階計画ゲーム

ペアプログラ
ミング

常時結合

TDD

10分ビルドリファクタリング

ソースコードの共同所有

イテレーションの終了段階

受け入れテスト

プロセス全体で適用するコンセプト

全員同席

継続可能なペース

短期リリース

継続的な設計頻繁なふりかえり

多くのプラクティスが品質確保に寄与している。

ペアプログラミング• 2人1組で1台のPCに向かってプログラミングを行う。
テスト駆動開発（TDD)• 「今から実装するプログラムはどのように動作すべきか？」という観装点でテストコードを作成し、テストにパスする実装を行う。テストコー
ド作成→実装→テスト結果確認を5分程度のスパンで繰り返す。
リファクタリング• 「動作を変えずにプログラムの構造を改善する」こと。XPにおいては、TDDで作成したテストをパスした状態を保ちながら構造を変更していく。
10分ビルド• ビルドにかかる時間を10分以内に抑えることにより、1日に何度もビルド可能な状態にする。

12常時結合• 最低1日に1度は各メンバーのコードを結合し自動的な結合試験をパスするかどうか確認する。
コードの共同所有コドの共同所有• コードの所有権を決めずに、どのペアがどのコードを変更するかは柔軟に決める。ルールは必ずテストを通ること。
継続的な設計• ユーザが作成するストーリーを満たす最適な設計を継続
ユ ザが作成するスト リ を満たす最適な設計を継続的に実施する。ユーザのストーリーから洞察できる確度の高い変更予測を元に変更コストが小さくなる設計を実施するが、決して、開発側の視点に偏った拡張性を追求しない。

再び、品質保証とは？
品質とは、ユーザの満足度である

品質保証とは、製品が「ユーザの満足」を実現することを保証すること

13

XPにおける品質保証
XPにおけるVerification（検証） & Validation（妥当性確認）

Verification（検証）• プラクティスが適切に実行されているかどうかを検証する
Validation（妥当性確認）• イテレーション毎に、計画ゲームにおいて実装対象となったストーリーに従っているかどうかを確認するためにソフトウェアを評価する工程XPにおけるVerification
ウォータフォールプロセスにおける考え方

検証の手段：品質メトリクスの実績と指標との差異分析による評価
評価対象となる品質メトリクスと実際の品質（ここでは要求を満たすこと）の相関関係を定義し、評価の根拠としている。

基本はXPでも変わりなし。ただし、XPでは「プラクティスが正しく行われていること」を評価するためのメトリクスを収集、評価する必要がある。
例）TDD：実装コードとテストコードの割合
テスト実行によるカバレッジ率 etc.
リファクタリング：コードクローンの測定結果
ペアプログラミング：ペアプログラミグでのコード作成率
ペアの組み合わせの妥当性 etc.

14

XPではイテレーション毎に検証する（イテレーション内では検証しない）
最大のリスクは「品質を満たさないソフトウェアが完成すること」

リスク対策として開発を短期のイテレーションに分割し、イテレーション毎の仕様を計画ゲームでユーザと合意する。

イテレーションの検証の結果、不適切な部分については、次イテレーションでの改善項目としてフィードバックし是正を行う。

XPにおけるValidation
ユーザの満足が実現できるか？
①ユーザは要求を開発側に提示し、開発側との詳細の協議を経て ストー開発側との詳細の協議を経て、ストーリーを作成する。
ストーリーの粒度は小さくなるようにする。（ただし、あくまで要求レベル）

要求

詳細な協議
開発側

ユーザ
ストーリー

見積もり

実装対象ストーリを協議②計画ゲームによりイテレーションで実装するストーリーを決定する。この時、ユーザと開発側で「このストーリーを満たすことで最終的なユーザ満足に近づく」ことを共有する。

計計画
ゲーム
開発側

ユーザ
ストーリー
ストーリー
ストーリー

実装対象ストーリー
ストーリー

15

③ユーザは受け入れテストを実施し、計画ゲームで決定したストーリーをソフトウェアが満たしていることを確認する。
この確認によって。最終的なユーザ満足に近づいた」ことをユーザと開発側が共有する。

実施

受け入れテスト

リリース
開発側

ユーザ

ゴール（不明確だが方向は見えている）

XPにおける妥当性確認
ユーザと開発側が協調し、ゴールへの方向性が正しいかをイテレーション毎に共有認識を持ちながら進める

ユーザにとって満足する方向で進んでいることは、これまで説明したプロセスで評価可能。

これでは、適格性確認にあたる部分しか妥当性を確認できていない？
→XPでは、「TDD」「常時結合」によって適格性確認以前の妥当性を常に確認しながら開発している。

XPにおける品質保証概念
イテレーション毎の繰り返し
計画ゲーム

概略モデル
概略
デ検討

頻繁な繰り返し

テストコード作成

実装
実装（リファクタリング含む）
開発側適格性試験

結合結合テスト

テスト

ユーザ受け
入れ試験
Verificationに当たる作業
検証

Validationに当たる作業

16

まとめ
• 標準的なXPにおける考え方を示したが、いつも同じ方法が良いわけでなない。
• 例えばイテレーションが3か月の開発であれば、イテレーション内のフェーズを明確にして、フェーズ毎の検証が必要となる。
• 大切なのは、開発プロセスで変わらない「品質を保証する」という本質を捉えて 開発プロセス毎に達成のためのる」という本質を捉えて、開発プロセス毎に達成のための手段を考えること。画一的に扱うべきではない。
• 本質が判れば、新しい開発プロセスや、特殊な状況に対応して、品質保証のプロセスを改善していくことができる。

ふりかえり• アジャイルプロセスはユーザと開発側が協調して共通のゴ ルに向かう開発プロセスであるこて共通のゴールに向かう開発プロセスであることを説明しました。
• 品質保証とは、「ユーザの満足」を保証することであると説明しました。
• ウォータフォールプロセスの品質保証の考え方としてV & Vについて説明しました。
• XPの概要と、XPにおける品質保証の考え方を説明し、本質的な意味ではウォータフォールプロセスの場合と違いはないことを説明しました。

17

是非、開発プロセス選択のメニューの一つとしてア是非、開発選択ののしてアジャイルプロセスも加えていただければと思います。

ありがとうございました。

参考文献• 「ソフトウェア品質保証の考え方と実際」（保田勝通 日科技連）• 「ソフトウェア品質保証入門」（保田勝通、奈良隆正 日科技連）• 「XPエクストリーム・プログラミング入門」（Kent Beck ピアソンエデュケーション）

18