川口 恭伸、楽天株式会社 『ソフトウェア品質シンポジウム 2012』併設チュートリアル 講演資料 テストエンジニアのスキルとアジャイル開発はどのように交わっていくのでしょうか。 アジャイル開発において、品質保証はどのように行われていくのでしょうか。 セッションでは、アジャイル開発におけるテストについて議論した後、アジャイルの基本といえるスクラムのチーム運営について学びます。 そして最後に、ゲーム感覚のワークショップで、チームの実際の動きを体感していきます。

1. ソフトウェア品質シンポジウム2012 併設チュートリアル 配布資料
はじめてのスクラム体験ワークショップ ∼ アジャイル時代のテスターを目指して
楽天株式会社 川口恭伸
1.本研修の目的
日本においても、アジャイル開発プロジェクトは、もはや珍しいものではなくなりまし
た。テストエンジニアのスキルとアジャイル開発はどのように交わっていくのでしょう
か。アジャイル開発において、品質保証はどのように行われていくのでしょうか。
本セッションでは、アジャイル開発におけるテストについて議論した後、アジャイルの基
本といえるスクラムのチーム運営について学んでいきます。
2.アジャイルとは
2001年 ボブ・マーティン1 の呼びかけで、軽量で実践的なソフトウェア開発プロセスを
実践している人々が、米国ユタ州ソルトレイクシティ近郊のSnowBirdという山荘に集ま
りました。ここで有名な「Manifesto for Agile Software Development
(通称: アジャイルマニフェスト)」がまとめられ、以後、様々なソフトウェア開発手法や、
その文化に「アジャイル」という呼称が用いられるようになりました。2
アジャイルソフトウェア開発宣言3
私たちは、ソフトウェア開発の実践
あるいは実践を手助けをする活動を通じて、
よりよい開発方法を見つけだそうとしている。
この活動を通して、私たちは以下の価値に至った。
プロセスやツールよりも個人と対話を、
包括的なドキュメントよりも動くソフトウェアを、
契約交渉よりも顧客との協調を、
計画に従うことよりも変化への対応を、
価値とする。すなわち、左記のことがらに価値があることを
認めながらも、私たちは右記のことがらにより価値をおく。
Kent Beck, Mike Beedle, Arie van Bennekum. Alistair Cockburn
Ward Cunningham, Martin Fowler, James Grenning, Jim Highsmith
Andrew Hunt, Ron Jeffries, Jon Kern, Brian Marick, Robert C. Martin
Steve Mellor, Ken Schwaber, Jeff Sutherland, Dave Thomas
© 2001, 上記の著者たち
この宣言は、この注意書きも含めた形で全文を含めることを条件に自由にコピーしてよい。
1 Robert C. Martin 『Clean Code』『Clean Coder』等の著者、通称 Uncle Bob (ボブおじさん)
2 http://d.hatena.ne.jp/wayaguchi/20110213/1297531229
3 http://agilemanifesto.org/iso/ja/

2. ソフトウェア品質シンポジウム2012 併設チュートリアル 配布資料
12の原則
1. 顧客満足を最優先し、価値のあるソフトウェアを早く継続的に提供します。
2. 要求の変更はたとえ開発の後期であっても歓迎します。
変化を味方につけることによって、お客様の競争力を引き上げます。
3. 動くソフトウェアを、2-3週間から2-3ヶ月というできるだけ短い時間間隔でリリースします。
4. ビジネス側の人と開発者は、プロジェクトを通して日々一緒に働かなければなりません。
5. 意欲に満ちた人々を集めてプロジェクトを構成します。
環境と支援を与え仕事が無事終わるまで彼らを信頼します。
6. 情報を伝えるもっとも効率的で効果的な方法はフェイス・トゥ・フェイスで話をすることです。
7. 動くソフトウェアこそが進捗の最も重要な尺度です。
8.アジャイル･プロセスは持続可能な開発を促進します。
一定のペースを継続的に維持できるようにしなければなりません。
9. 技術的卓越性と優れた設計に対する不断の注意が機敏さを高めます。
10. シンプルさ（ムダなく作れる量を最大限にすること）が本質です。
11. 最良のアーキテクチャ・要求・設計は、自己組織的なチームから生み出されます。
12. チームがもっと効率を高めることができるかを定期的に振り返り、
それに基づいて自分たちのやり方を最適に調整します。
アジャイルは様々な方法論を含む総称としてつけられたラベルのため、「アジャイル開発
をしている」という場合にも、その実体としてどのようなプラクティスを採用しているの
か、どの程度行っているかによって、大きな多様性があります。

3. ソフトウェア品質シンポジウム2012 併設チュートリアル 配布資料
3. アジャイル・テスティング
ソフトウェア開発プロジェクトをアジャイルで行う際の、テスターや品質保証(QA)のスキ
ルを持つ人の役割を定義したのが、リザ・クリスピンとジャネット・グレゴリーによるア
ジャイル・テスティング Agile Testing です。
従来の品質保証担当は、製品開発の最終段階におけるチェックを主に行ってきました。仕
様書を(開発者とは別に)読み解き、テストケースを作成し、主に手作業で実施する...。し
かし、テストの自動化が進展した現在では、そのあり方も変化しています。
TDD (テスト駆動開発) は、ケント・ベックらXPコミュニティで発展してきた技法です。
開発者自身がユニットテストとソースコードをセットで書くことで、仕様の理解を明確に
し、リファクタリングを用いてコードの品質を洗練していきます。テストコードのカバ
レッジを計測し、ユニットテストが用意されていないコードをなるべく無くすことを目指
します。ペアプログラミング(２人一組でのプログラミング)によって、仕様の明確化と
コードレビューを同時に行うこともあります。
CI (継続的インテグレーション) 用のサーバを用意し、ソースコードとテストがソース
コード管理システムにコミットされたらすぐに、ビルドとテストを自動実行して後退(リグ
レッション)がないことを確認します。
このように、開発者自身が自動テストを書くようになれば、時間のかかる品質保証(QA)
は不要になるのではないか？という意見もアジャイルコミュニティにはあったようです。
しかし、TDDで記述するテストはあくまで「開発の足がかりになるもの」にとどめるのが
一般的です。その一方で、求められる品質を確かめようとすれば、必要なテストは多岐に
わたります。ですから、包括的なテスト設計のために、テスターの 役割とスキル が重
要になります。
テスト自動化ピラミッド ( Mike Cohn ) (c)2012 Lisa Crispin, Janet Gregory

4. ソフトウェア品質シンポジウム2012 併設チュートリアル 配布資料
アジャイルテスター
アジャイルチームの中に、テストについての十分なスキルを持った人が必要です。リザと
ジャネットはそういった人を「アジャイルテスター」と定義しました。アジャイルテス
ターになるためには、アジャイルチームの文化や振る舞いを知り、参加していく必要があ
ります。
アジャイルチームは業務に近いところで作業を行い、要求の詳細を理解していま
す。チームが何を提供できるかに焦点を当て、昨日の優先順付けの決める多くの要
素を把握しているのです。テスターは座って待っているのではなく、開発サイクルを
通してチームに役立つことを探しています。 4
アジャイルでは、テスターや品質保証の人たちだけが、品質に責任を持っているわ
けではありません。「組織の壁」は気にせず、最高の製品を作り出せるスキルと要員
だけを考えています。アジャイル開発の肝は高品質のソフトウェアを作り出すことで
す。しかも、ビジネス価値を最大化するようなスピード感覚でソフトウェアを作り出
します。これがチーム全体で進める仕事であり、テスターや任命された品質保証の
専門家だけでやるものではありません。アジャイルチームにいる人はみな、「テス
ト好き」になります。単体テスト以降のテストはコーディングを促進し、アプリケー
ションがいかに稼働すべきかを理解し、タスクまたはストーリーが完了したことが
分かります。 5
アジャイルチームが生み出すソフトウェアの品質は、チーム全体で責任を持ちます。 です
から、アジャイルテスターはチームの一員として、製品の品質を高めることに寄与しま
す。
ドキュメントで受け渡すプロセス(左上)と、
アジャイルのクロスファンクショナルチーム(右下)
4 『実践アジャイルテスト テスターとアジャイルチームのための実践ガイド』 (2009) P.12
5 『実践アジャイルテスト テスターとアジャイルチームのための実践ガイド』 (2009) P.15

5. ソフトウェア品質シンポジウム2012 併設チュートリアル 配布資料
4.スクラム : 最も普及したアジャイル・チーム・マネジメントの枠組み
スクラムはアジャイルのチームマネジメントのフレームワークとして、現在、最も普及し
ている手法です。90年代前半に、ジェフ・サザーランドとケン・シュウェイバーによって
作られ、96年に発表されました。この両名もアジャイルマニフェストの策定に参加してい
ます。スクラムは技術的なプラクティスを一切削ぎ落とし、チーム・マネジメントに
フォーカスしたプラクティスのみを残した フレームワーク としました。その結果、様々
な分野/プロダクトで利用可能な汎用性を持っています。
また、スクラムが参考にした論文の一つに、 日本人の竹内弘高・野中郁次郎の The
New New Product Development Game (1986) があります。これはホンダやキャノ
ン、富士ゼロックスの新製品開発の事例を研究したものです。従来の開発工程をフェーズ
毎に明確に区切るプロセスに対し、開発工程をオーバーラップさせ、全体を１チームとし
て作業を進める過程を採用していました。竹内と野中は論文中でその過程をラグビーの
「スクラム」と表現しました。
The New New Product Development Game Hirotaka Takeuchi, Ikujiro Nonaka (1986)

6. ソフトウェア品質シンポジウム2012 併設チュートリアル 配布資料
(1)３つの原則
スクラムはエンピリカル(経験主義)に基づくマネジメント手法です。机上の予測だけに頼
らず、できる限り実際の作業や成果物を用いて、意見を聞き、仮説を修正します。できる
限り頻繁にリリースとデモを行います。徐々にチームとして知識を獲得し、予測可能性を
上げ、現実的なリスクマネジメントのノウハウを獲得していきます。
３つの原則
・透明性 transparency : チーム及び関係者全員が共通理解(common sense)を持つ
・検査 inspect : (作業の妨げにならない程度に)頻繁に成果物やプロセスを検査する
・適応 adapt : プロセスおよび成果物に問題があると判断された場合は対策を行う
一般的には以下のような制約を利用します。
・チームメンバーの頻繁な入れ替えを避け、なるべく固定のメンバーとする
・固定のスプリント期間(2-4週)を設け、ミーティングや計測、成果物の引渡しを行う
・チームの状態は特定の個人ではなく、チーム自身が管理を行う
・チームが持つ情報は、できる限りチーム内で共有する
・外部からの直接の指示を出さない (話は聞くが、メンバーが判断を行う)
(2)４つのミーティング
スクラムでは、スプリント内で行う４つのミーティングを定義しています。
４つのミーティング(儀式)
・スプリント計画 : スプリント冒頭で行う
・第一部 : 実績に基づき、当スプリントの到達点をプロダクトオーナーと合意する
・第二部 : 当スプリント内で行うタスクをチーム内で詳細に検討する
・デイリースクラム(朝会) : 現在の状況をチームに共有する
・スプリントデモ(レビュー) : 成果物をステークホルダに共有、フィードバックを得る
・レトロスペクティブ(ふりかえり) : 自分たちのプロセスを見直し、改善案を出す
例えば、２週間のスプリントの場合、以下のような時間を割り当てます。
6
6 http://www.publickey1.jp/blog/11/10_5.html

7. ソフトウェア品質シンポジウム2012 併設チュートリアル 配布資料
(3)３つのロール
スクラムではチームが主体ですが、チームを支援する２つのロールを定義しています。
３つのロール(役割)
・チーム Team :
スクラムの主体となる自己管理されたチーム。
理想的にはプロダクトを作るのに必要な全ての能力を備えている。
・プロダクトオーナー Product Owner(PO) :
チームが生み出すプロダクトの方向性を決定する役割。舵取り役。
プロダクトバックログを適切にメンテナンスする責任を持つ。
不確実な将来に対し、投資判断を行う。
・スクラムマスター Scrum Master(SM) :
チームとプロセスの健康状態をチェックし、チームの前進と成長を促す。
チームドクター。ミーティングのファシリテーションも行う(適宜)。
前進への障害物を確認して、チームや外部 に除去を働きかける。
次のスクラムマスターを育てる。
@IT 開発チームを改善するためのスクラムTips
最終回 5分で分かる、「スクラム」の基本まとめ
(4)３つのアーティファクト
チーム内の共通理解(common sense)を手助けするのがアーティファクトです。
３つのアーティファクト(道具)
・プロダクトバックログ Product Backlog :
プロダクトの要件を優先順位漬けされたリストにしたもの。
一つ一つの項目をプロダクトバックログ項目(PBI)という。
各PBIは、実現したときの価値をプロダクトオーナーが見積もり、
実現のための作業規模をチームが見積もる。
優先順位付け(並べ替え)はプロダクトオーナーが行う。

8. ソフトウェア品質シンポジウム2012 併設チュートリアル 配布資料
・スプリントバックログ Sprint Backlog :
当該スプリントで完成する見込みのプロダクトバックログの一部。
規模見積もりとベロシティ(推定される作業量)によって予測到達点を推測する。
スプリント計画第一部で合意し、第二部で詳細に作業計画を行う。
・バーンダウン・チャート Burndown Chart:
スプリント内の残作業量をプロットする右下がりのグラフ。
スプリントバックログ内のPBIをスプリント期間内にすべて完了することが
できるか、視覚的に把握する。
Henrik Kniberg “塹壕よりScrumとXP（Scrum and XP from the Trenches)”7
7 http://www.infoq.com/jp/minibooks/scrum-xp-from-the-trenches

9. ソフトウェア品質シンポジウム2012 併設チュートリアル 配布資料
5.アジャイル開発のライフサイクルとテスターの役割
次にアジャイル開発のタイムボックスと、各タイミングでのテスターの役割についてみて
いきましょう。
(1)リリース計画
顧客と利用者が期待しているものを分析し、今回のリリースで優先する機能(フィー
チャー)を決定します。ユーザーストーリーを洗い出し、作業規模を見積もり、優先順位を
調整して、プロダクトバックログを完成させます。
リリース計画で行うこと(チーム全体として)
・利用者が誰であるかを共有する
・利用者のワークフローを明らかにする、もしくは仮説を共有する
・利用者に提供する機能を、利用者視点で記述する (ユーザーストーリー)
・各ユーザーストーリーについて必要な受入テスト項目を洗い出す
・各ユーザーストーリーの規模を見積もる
・改善後のワークフローを確認し、ユーザーストーリー間の依存関係を考慮しながら、
最小限必要なものを確認する
・リリースに必要な設備や、利用者に届けるための戦略と予定表/締切を確認する
・関連システムと移行計画、全体への影響やリスクを確認する
・テスト戦略について決定する。必要な環境、データ、リソース、時間はどれだけか
・完了の定義(各ユーザーストーリーの実装完了の基準、必要なテスト等)を決定する
・状況の見える化の仕組みを検討する
テスターは 成果物の価値を期待通りに届けられるよう、アイデアや計画の実現可能性に
ついて情報を提供し、テスト計画を立案することに主体的な貢献を行っていきます。
ストーリーカードと受け入れテスト項目
アジャイル開発で最も有名な手法の一つが「ストーリーカード」です。要件定義は、多様
な情報の収集と整理のプロセスですので、優れた 誰か に情報を集めることで、効率的な
意思決定を行う、というのが従来の方法でした。しかし現在では、解くべき問題が複雑に
なり、求められる時間的制約も厳しくなり、 誰か 一人だけでは実現可能な計画を作り上

10. ソフトウェア品質シンポジウム2012 併設チュートリアル 配布資料
げることは不可能になってきています。そこで、アジャイルでは、カードを媒介すること
で、チームの中央に知識を置き、多様なスキルを持つメンバーが集まり、効率的な要件定
義を行うのです。紙のカードは同時に複数のメンバーが書いたり、操作したりすることが
できます。
8
あわせて、完了までに確認が必要な項目(受け入れテスト項目)について検討します。具体
例で考えることで、利用者にとっての価値を共有し、完了までに必要な作業の規模をより
正確にし、スプリント開始後に確実に着手できるようにします。
テスト自動化による品質の作り込み
テスト自動化には２種類の取り組みがあります。TDD(テスト駆動開発)はデベロッパーテ
ストとも呼ばれ、開発者自身の作業の足がかりとしてテストを書いていくものです。各メ
ソッドの振る舞いをテストするコードを先に書き、テストに合格するようにメソッドの実
装を書いていきます。結果的にはコードとともに、十分な量のユニットテストが生み出さ
れ、いつでも確認できるようになります。また、テストを壊さないようにコードを洗練さ
せるリファクタリングも行っていきます。
一方で、受け入れテストレベルでの自動化を行うのがATDD(受入テスト駆動開発)や
BDD(ビヘイビア駆動開発)です。 受け入れテストを定義したり実施するのはプロダクト
オーナーや顧客の役目です。このため、FitNesse や Selenium、Cucumber などのツー
ルでは、非プログラマでも理解／記述できるよう、自然言語に近いドメイン特化言語や
HTML表などでテストケースを記述できるようになっています。スプリントの開始前にど
のような受け入れテストを実施するのかを決め、その実行のための環境を整備しておくこ
とが重要です。
アジャイルテスターにとって、受け入れテスト項目を洗い出し、自動テストに落とし込む
こと、また自動テストを適切に管理することは必須スキルといってよいでしょう。
8 http://www.mountaingoatsoftware.com/blog/advantages-of-the-as-a-user-i-want-user-story-
template

11. ソフトウェア品質シンポジウム2012 併設チュートリアル 配布資料
テストの全体像を俯瞰する
製品の品質を確保するには、自動化できるテスト以外にも、多様なテストがあります。
アジャイルテストの四象限 ( Brian Marick ) (c)2012 Lisa Crispin, Janet Gregory
第１象限(左下) : テスト駆動開発(TDD)です。
第２象限(左上) : 機能レベルで受入条件をテストします。ATDDやBDDが支援します。
第３象限(右上) : 期待に合っているか、競合に対して価値があるかなどを確認します。
第４象限(右下) : 非機能要件やセキュリティをテストします。
テスト環境、テストデータの整備
スプリントを始める前に、テストやリリースのための環境を確認し、できる限り整備して
おくべきです。また、各ユーザーストーリーの完了基準を考えておく必要もあります。
見える化の仕組みを検討する
テストの進捗や自動テストのカバレッジなどを、チームから見える場所に表示しておく方
法を整備しておきます。

12. ソフトウェア品質シンポジウム2012 併設チュートリアル 配布資料
(2)スプリント計画
スプリント計画フェーズでは、チームが当該スプリントで完成させるストーリーが選択さ
れ、詳細なタスク(作業計画)を検討します。
ストーリーがテスト可能であることを確認する
ストーリーがテスト可能であるかどうかは、カードを見るたびに気にする必要があります
が、スプリント計画はそれを確認する最後のチャンスです。
ストーリーをどのようにデモンストレーションするか検討する
スプリントの終了時にはステークホルダー向けにデモを行います。そのストーリーの成果
物や価値をわかってもらうためには、効果的なデモンストレーションが必要です。そのス
トーリーははっきりと見せられるでしょうか。完成したストーリーを、プログラマやテス
ター以外の人にも簡潔に説明する方法について検討します。
ストーリーの規模を明らかにする
チームはストーリーの規模を、プランニングポーカーなどを用いて見積もっていきます。
テスターもチームの一員として参加し、必要に応じて明確化(clarify)のための質問をしま
しょう。
大きすぎるストーリーは分割します。その際にも、最低限の機能はどこか？ テスト工数
を最小限にしつつ、そのストーリーの有効性を確認できる実装方法はないか、検討を行い
ます。
まだ経験のない技術を採用するときなどは、「スパイク」という技術確認のためのストー
リーを行います。有限の調査検討時間を決めて、その技術を採用する意味があるかどうか
を検討します。その結果、次回以降のスプリントではより正確に見積もれるようになりま
す。

13. ソフトウェア品質シンポジウム2012 併設チュートリアル 配布資料
(3)スプリントの進行とテスト、完了の確認
チームは、ストーリーを優先順位に従って実装していきます。受け入れテストの自動化を
行う場合は、開発と平行して受け入れテストの自動化を進めます。
デイリースクラム(朝会)
スクラムでは、一日一回のミーティングを行って、日々の進捗やメンバーの状況を確認し
ます。以下の３点を手短かに共有します。
・昨日やったこと
・今日やること
・問題になっている事 (前進を妨げているもの)
開発者との協同作業
開発者の隣に座ってテストを実装する(ペアテスト)、気になる部分の進捗を適宜見せても
らう、ストーリーが持つ価値の理解を深めるためにチーム外の人々と話すなど、チームが
前進するために、できることを行っていきましょう。
不具合との対峙
スプリント進行中に、以前リリースしたシステムの不具合(バグ)が報告される事があるで
しょう。この場合は、スプリントで計画されたストーリーよりも優先して対処しなければ
ならない事がほとんどでしょう。すぐに直せる場合は、修正し、リグレッションテストを
行い、修正リリースします。 テストが自動化されていれば、リグレッションテストは短時
間ですみます。不具合への対処時間が短くなり、スプリントの見積もり工数からのズレも
軽微ですみます。
大きな対策が必要な場合は、プロダクトオーナーに説明し、プロダクトバックログに記載
します。
スクラムでは、プロダクトバックログを優先度順に記述しているため、予定外の作業を行
う場合にどのストーリーが実装できなくなるかが明らかです。プロダクトオーナーに報告
し、必要な対策(ステークホルダーへの説明など)をとってもらいます。

14. ソフトウェア品質シンポジウム2012 併設チュートリアル 配布資料
(4)スプリントデモ、レトロスペクティブ(ふりかえり)
スプリントの終盤では、完成したストーリーをステークホルダに見せ、フィードバックを
もらいます。その後、チームでスプリントをふりかえって、今後改善できるところがない
か検討します。
いつでも出荷可能なプロダクトの増分
スクラムでは、各スプリント中に各ストーリーを「いつでも出荷可能なプロダクトの増分
(Potentially shippable increment)」に仕上げます。プロダクトオーナーの出荷判断が下
ればいつでも出荷に応じられる状態、ということです。受け入れテストはすべて終了して
おり、事前に定義した「完了の定義(DoD)」にしたがって、その他の確認がすべて終了し
た状態です。
デモンストレーションのための過剰な準備をしてはならない
スプリントデモでは「いつでも出荷可能なプロダクトの増分」のあるがままをステークホ
ルダーに見せます。デモンストレーションのために過剰な資料や、ハリボテを準備しては
いけません。うまく伝えられなかった場合は、次に向けて改善策を検討しましょう。
チームとして改善する
スプリントデモは、チームの間違いや、ステークホルダー間の意見の食い違いなどを発見
する、よいチャンスです。多くの人は、動くソフトウェアや明日から使うような状態の
ツールがあってはじめて、具体的な想像力が働きます。チームは、成果物を提示し、ス
テークホルダーの意見に耳を傾けます。どんな情報も「見つかってよかった！」と考えま
しょう。
レトロスペクティブ(ふりかえり)を行って、チームとして改善のヒントを探っていきま
す。すぐにできない対策も、メモをとっておき、順に解決していきます。すぐに解決でき
る問題だけを問題と考えるのは危険です。
チームは前進しました。ささやかな成功を祝い、次のスプリントに備えましょう。

15. ソフトウェア品質シンポジウム2012 併設チュートリアル 配布資料
(5)リリースとデリバリー
製品を磨き上げる
複数のスプリントで作られた「いつでも出荷可能なプロダクトの増分」を組み合わせてリ
リースする場合には、結合した状態で、利用者にとって不都合がないかをチェックする必
要があります。まず、利用者になりかわって、チームとして探索的テストを行います。あ
らかじめ時間を決め、全員で使ってみるのです。可能であれば、実際のユーザー像に近い
第三者に協力をあおぎ、試しに使ってもらうところを、後ろから観察させてもらうと効果
的です。見つかった問題はすぐさま修正を検討します。
問題が発見されない/修正済みになったら、利用者の一部に使ってもらうことも検討しま
しょう。UAT(ユーザによる受け入れテスト)や、A/Bテスト(一部の顧客に先行リリース)を
通して、リリースされるストーリーの価値を確認していきます。
本番にリリースできてはじめて価値がある
本番環境へのリリースを行い、顧客に成果物を届けることで、初めて価値が発生します。
リリースできないストーリーはすべて在庫です。デリバリーをスムーズに行えるように環
境を整備することは、非常に重要です。
・ 開発環境、ステージング環境、本番環境は同じソースコードで展開可能ですか？
・ 本番環境の構成はバージョン管理システムで管理されていますか？
・ デプロイは自動化されていますか？
・ リリースをスムーズに行える手順が確立できていますか？
・ 問題があった場合の切り戻しの手順や影響は明らかですか？
・ 稼働監視は考慮できていますか？
・ 本番環境での障害時に情報を適切に収集する仕組みはできていますか？

16. ソフトウェア品質シンポジウム2012 併設チュートリアル 配布資料
成功への鍵
最後に、『実践アジャイルテスト』より、リザ・クリスピンとジャネット・グレゴリーの
挙げる成功への鍵を紹介します。
・1 : チーム全体のアプローチ (whole team approach)
・2 : アジャイルテストの考え方を採用する
・3 : 自動リグレッションテスト
・4 : フェードバックを与え、受ける
・5 : コアプラクティスの基礎を築く (CI, テスト環境、技術的負債の管理)
・6 : 顧客と共同作業する
・7 : 広い視野を持つ
もしかすると、企業の中にはさまざまな組織の壁があり、簡単にはチーム全体のアプロー
チができないと感じることもあるかもしれませんが、一つ一つ分析し、実験を積み重ね、
できることを増やしていっていただくことを祈っております。
謝辞
本原稿は、執筆の過程で山口鉄平氏、木村卓央氏、細谷泰夫氏の助言をいただきました。
また、本研修は森崎修司氏よりきっかけをいただきました。ジャネット・グレゴリーさん
には東京での研修の開催を通じて多くのことを教えていただきました。
ここに感謝を申し上げます。