はじめてのスクラム体験ワークショップ ～ アジャイル時代のテスターを目指して楽天株式会社　川口恭伸

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, 上記の著者たち この宣言は、この注意書きも含めた形で全文を含めることを条件に自由にコピーしてよい。

ソフトウェア品質シンポジウム2012 併設チュートリアル 配布資料

1 Robert C. Martin 『Clean Code』『Clean Coder』等の著者、通称 Uncle Bob (ボブおじさん)2 http://d.hatena.ne.jp/wayaguchi/20110213/12975312293 http://agilemanifesto.org/iso/ja/

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

アジャイルは様々な方法論を含む総称としてつけられたラベルのため、「アジャイル開発をしている」という場合にも、その実体としてどのようなプラクティスを採用しているのか、どの程度行っているかによって、大きな多様性があります。

　

ソフトウェア品質シンポジウム2012 併設チュートリアル 配布資料

3. アジャイル・テスティングソフトウェア開発プロジェクトをアジャイルで行う際の、テスターや品質保証(QA)のスキルを持つ人の役割を定義したのが、リザ・クリスピンとジャネット・グレゴリーによるアジャイル・テスティング Agile Testing です。

従来の品質保証担当は、製品開発の最終段階におけるチェックを主に行ってきました。仕様書を(開発者とは別に)読み解き、テストケースを作成し、主に手作業で実施する...。しかし、テストの自動化が進展した現在では、そのあり方も変化しています。

TDD (テスト駆動開発) は、ケント・ベックらXPコミュニティで発展してきた技法です。開発者自身がユニットテストとソースコードをセットで書くことで、仕様の理解を明確にし、リファクタリングを用いてコードの品質を洗練していきます。テストコードのカバレッジを計測し、ユニットテストが用意されていないコードをなるべく無くすことを目指します。ペアプログラミング(２人一組でのプログラミング)によって、仕様の明確化とコードレビューを同時に行うこともあります。

CI (継続的インテグレーション) 用のサーバを用意し、ソースコードとテストがソースコード管理システムにコミットされたらすぐに、ビルドとテストを自動実行して後退(リグレッション)がないことを確認します。

このように、開発者自身が自動テストを書くようになれば、時間のかかる品質保証(QA)は不要になるのではないか？という意見もアジャイルコミュニティにはあったようです。しかし、TDDで記述するテストはあくまで「開発の足がかりになるもの」にとどめるのが一般的です。その一方で、求められる品質を確かめようとすれば、必要なテストは多岐にわたります。ですから、包括的なテスト設計のために、テスターの ”役割とスキル” が重要になります。

　　　　　　　　　テスト自動化ピラミッド ( Mike Cohn ) (c)2012 Lisa Crispin, Janet Gregory

ソフトウェア品質シンポジウム2012 併設チュートリアル 配布資料

アジャイルテスターアジャイルチームの中に、テストについての十分なスキルを持った人が必要です。リザとジャネットはそういった人を「アジャイルテスター」と定義しました。アジャイルテスターになるためには、アジャイルチームの文化や振る舞いを知り、参加していく必要があります。

“アジャイルチームは業務に近いところで作業を行い、要求の詳細を理解しています。チームが何を提供できるかに焦点を当て、昨日の優先順付けの決める多くの要素を把握しているのです。テスターは座って待っているのではなく、開発サイクルを通してチームに役立つことを探しています。” 4

“アジャイルでは、テスターや品質保証の人たちだけが、品質に責任を持っているわけではありません。「組織の壁」は気にせず、最高の製品を作り出せるスキルと要員だけを考えています。アジャイル開発の肝は高品質のソフトウェアを作り出すことです。しかも、ビジネス価値を最大化するようなスピード感覚でソフトウェアを作り出します。これがチーム全体で進める仕事であり、テスターや任命された品質保証の専門家だけでやるものではありません。アジャイルチームにいる人はみな、「テスト好き」になります。単体テスト以降のテストはコーディングを促進し、アプリケーションがいかに稼働すべきかを理解し、タスクまたはストーリーが完了したことが分かります。”5

アジャイルチームが生み出すソフトウェアの品質は、チーム全体で責任を持ちます。 ですから、アジャイルテスターはチームの一員として、製品の品質を高めることに寄与します。

　　　　　　　　ドキュメントで受け渡すプロセス(左上)と、　　　　アジャイルのクロスファンクショナルチーム(右下)

ソフトウェア品質シンポジウム2012 併設チュートリアル 配布資料

4 『実践アジャイルテスト テスターとアジャイルチームのための実践ガイド』 (2009) 　P.125 『実践アジャイルテスト テスターとアジャイルチームのための実践ガイド』 (2009) 　P.15

4.スクラム : 最も普及したアジャイル・チーム・マネジメントの枠組みスクラムはアジャイルのチームマネジメントのフレームワークとして、現在、最も普及している手法です。90年代前半に、ジェフ・サザーランドとケン・シュウェイバーによって作られ、96年に発表されました。この両名もアジャイルマニフェストの策定に参加しています。スクラムは技術的なプラクティスを一切削ぎ落とし、チーム・マネジメントにフォーカスしたプラクティスのみを残した”フレームワーク”としました。その結果、様々な分野/プロダクトで利用可能な汎用性を持っています。

また、スクラムが参考にした論文の一つに、 日本人の竹内弘高・野中郁次郎の “The New New Product Development Game (1986)” があります。これはホンダやキャノン、富士ゼロックスの新製品開発の事例を研究したものです。従来の開発工程をフェーズ毎に明確に区切るプロセスに対し、開発工程をオーバーラップさせ、全体を１チームとして作業を進める過程を採用していました。竹内と野中は論文中でその過程をラグビーの「スクラム」と表現しました。

　　　　　 　　　　　”The New New Product Development Game” Hirotaka Takeuchi, Ikujiro Nonaka (1986)

ソフトウェア品質シンポジウム2012 併設チュートリアル 配布資料

(1)３つの原則スクラムはエンピリカル(経験主義)に基づくマネジメント手法です。机上の予測だけに頼らず、できる限り実際の作業や成果物を用いて、意見を聞き、仮説を修正します。できる限り頻繁にリリースとデモを行います。徐々にチームとして知識を獲得し、予測可能性を上げ、現実的なリスクマネジメントのノウハウを獲得していきます。

　３つの原則　・透明性 transparency : チーム及び関係者全員が共通理解(common sense)を持つ　・検査 inspect : (作業の妨げにならない程度に)頻繁に成果物やプロセスを検査する　・適応 adapt : プロセスおよび成果物に問題があると判断された場合は対策を行う

一般的には以下のような制約を利用します。　・チームメンバーの頻繁な入れ替えを避け、なるべく固定のメンバーとする　・固定のスプリント期間(2-4週)を設け、ミーティングや計測、成果物の引渡しを行う　・チームの状態は特定の個人ではなく、チーム自身が管理を行う　・チームが持つ情報は、できる限りチーム内で共有する　・外部からの直接の指示を出さない (話は聞くが、メンバーが判断を行う)

(2)４つのミーティングスクラムでは、スプリント内で行う４つのミーティングを定義しています。

　４つのミーティング(儀式)　・スプリント計画 : スプリント冒頭で行う　　・第一部 : 実績に基づき、当スプリントの到達点をプロダクトオーナーと合意する　　・第二部 : 当スプリント内で行うタスクをチーム内で詳細に検討する　・デイリースクラム(朝会) : 現在の状況をチームに共有する　・スプリントデモ(レビュー) : 成果物をステークホルダに共有、フィードバックを得る　・レトロスペクティブ(ふりかえり) : 自分たちのプロセスを見直し、改善案を出す

　　例えば、２週間のスプリントの場合、以下のような時間を割り当てます。

　　　 6

ソフトウェア品質シンポジウム2012 併設チュートリアル 配布資料

6 http://www.publickey1.jp/blog/11/10_5.html

(3)３つのロールスクラムではチームが主体ですが、チームを支援する２つのロールを定義しています。

　３つのロール(役割)　・チーム Team : 　　　スクラムの主体となる自己管理されたチーム。　　　理想的にはプロダクトを作るのに必要な全ての能力を備えている。　・プロダクトオーナー Product Owner(PO) : 　　　チームが生み出すプロダクトの方向性を決定する役割。舵取り役。　　　プロダクトバックログを適切にメンテナンスする責任を持つ。　　　不確実な将来に対し、投資判断を行う。　・スクラムマスター Scrum Master(SM) : 　　　チームとプロセスの健康状態をチェックし、チームの前進と成長を促す。　　　チームドクター。ミーティングのファシリテーションも行う(適宜)。　　　前進への障害物を確認して、チームや外部 に除去を働きかける。　　　次のスクラムマスターを育てる。

　　　　　　　　　　　　@IT 開発チームを改善するためのスクラムTips 　　　　　　　　　　　最終回 5分で分かる、「スクラム」の基本まとめ

(4)３つのアーティファクトチーム内の共通理解(common sense)を手助けするのがアーティファクトです。

　３つのアーティファクト(道具)　・プロダクトバックログ Product Backlog : 　　　プロダクトの要件を優先順位漬けされたリストにしたもの。　　　一つ一つの項目をプロダクトバックログ項目(PBI)という。　　　各PBIは、実現したときの価値をプロダクトオーナーが見積もり、　　　実現のための作業規模をチームが見積もる。　　　優先順位付け(並べ替え)はプロダクトオーナーが行う。

ソフトウェア品質シンポジウム2012 併設チュートリアル 配布資料

　・スプリントバックログ Sprint Backlog : 　　　当該スプリントで完成する見込みのプロダクトバックログの一部。　　　規模見積もりとベロシティ(推定される作業量)によって予測到達点を推測する。　　　スプリント計画第一部で合意し、第二部で詳細に作業計画を行う。

　・バーンダウン・チャート Burndown Chart: 　　　スプリント内の残作業量をプロットする右下がりのグラフ。　　　スプリントバックログ内のPBIをスプリント期間内にすべて完了することが　　　できるか、視覚的に把握する。

　　　　　Henrik Kniberg “塹壕よりScrumとXP（Scrum and XP from the Trenches)”7

ソフトウェア品質シンポジウム2012 併設チュートリアル 配布資料

7 http://www.infoq.com/jp/minibooks/scrum-xp-from-the-trenches

5.アジャイル開発のライフサイクルとテスターの役割次にアジャイル開発のタイムボックスと、各タイミングでのテスターの役割についてみていきましょう。

(1)リリース計画

　　顧客と利用者が期待しているものを分析し、今回のリリースで優先する機能(フィーチャー)を決定します。ユーザーストーリーを洗い出し、作業規模を見積もり、優先順位を調整して、プロダクトバックログを完成させます。

　リリース計画で行うこと(チーム全体として)　・利用者が誰であるかを共有する　・利用者のワークフローを明らかにする、もしくは仮説を共有する　・利用者に提供する機能を、利用者視点で記述する (ユーザーストーリー)　・各ユーザーストーリーについて必要な受入テスト項目を洗い出す　・各ユーザーストーリーの規模を見積もる　・改善後のワークフローを確認し、ユーザーストーリー間の依存関係を考慮しながら、　　最小限必要なものを確認する　・リリースに必要な設備や、利用者に届けるための戦略と予定表/締切を確認する　・関連システムと移行計画、全体への影響やリスクを確認する　・テスト戦略について決定する。必要な環境、データ、リソース、時間はどれだけか　・完了の定義(各ユーザーストーリーの実装完了の基準、必要なテスト等)を決定する　・状況の見える化の仕組みを検討する

テスターは 成果物の価値を期待通りに届けられるよう、アイデアや計画の実現可能性について情報を提供し、テスト計画を立案することに主体的な貢献を行っていきます。

ストーリーカードと受け入れテスト項目アジャイル開発で最も有名な手法の一つが「ストーリーカード」です。要件定義は、多様な情報の収集と整理のプロセスですので、優れた”誰か”に情報を集めることで、効率的な意思決定を行う、というのが従来の方法でした。しかし現在では、解くべき問題が複雑になり、求められる時間的制約も厳しくなり、”誰か” 一人だけでは実現可能な計画を作り上

ソフトウェア品質シンポジウム2012 併設チュートリアル 配布資料

げることは不可能になってきています。そこで、アジャイルでは、カードを媒介することで、チームの中央に知識を置き、多様なスキルを持つメンバーが集まり、効率的な要件定義を行うのです。紙のカードは同時に複数のメンバーが書いたり、操作したりすることができます。

8

あわせて、完了までに確認が必要な項目(受け入れテスト項目)について検討します。具体例で考えることで、利用者にとっての価値を共有し、完了までに必要な作業の規模をより正確にし、スプリント開始後に確実に着手できるようにします。

テスト自動化による品質の作り込みテスト自動化には２種類の取り組みがあります。TDD(テスト駆動開発)はデベロッパーテストとも呼ばれ、開発者自身の作業の足がかりとしてテストを書いていくものです。各メソッドの振る舞いをテストするコードを先に書き、テストに合格するようにメソッドの実装を書いていきます。結果的にはコードとともに、十分な量のユニットテストが生み出され、いつでも確認できるようになります。また、テストを壊さないようにコードを洗練させるリファクタリングも行っていきます。

一方で、受け入れテストレベルでの自動化を行うのがATDD(受入テスト駆動開発)やBDD(ビヘイビア駆動開発)です。 受け入れテストを定義したり実施するのはプロダクトオーナーや顧客の役目です。このため、FitNesse や Selenium、Cucumber などのツールでは、非プログラマでも理解／記述できるよう、自然言語に近いドメイン特化言語やHTML表などでテストケースを記述できるようになっています。スプリントの開始前にどのような受け入れテストを実施するのかを決め、その実行のための環境を整備しておくことが重要です。

アジャイルテスターにとって、受け入れテスト項目を洗い出し、自動テストに落とし込むこと、また自動テストを適切に管理することは必須スキルといってよいでしょう。

ソフトウェア品質シンポジウム2012 併設チュートリアル 配布資料

8 http://www.mountaingoatsoftware.com/blog/advantages-of-the-as-a-user-i-want-user-story-template

テストの全体像を俯瞰する製品の品質を確保するには、自動化できるテスト以外にも、多様なテストがあります。

　 　　アジャイルテストの四象限 ( Brian Marick ) (c)2012 Lisa Crispin, Janet Gregory

第１象限(左下) : テスト駆動開発(TDD)です。第２象限(左上) : 機能レベルで受入条件をテストします。ATDDやBDDが支援します。第３象限(右上) : 期待に合っているか、競合に対して価値があるかなどを確認します。第４象限(右下) : 非機能要件やセキュリティをテストします。

テスト環境、テストデータの整備スプリントを始める前に、テストやリリースのための環境を確認し、できる限り整備しておくべきです。また、各ユーザーストーリーの完了基準を考えておく必要もあります。

見える化の仕組みを検討する テストの進捗や自動テストのカバレッジなどを、チームから見える場所に表示しておく方法を整備しておきます。

ソフトウェア品質シンポジウム2012 併設チュートリアル 配布資料

(2)スプリント計画スプリント計画フェーズでは、チームが当該スプリントで完成させるストーリーが選択され、詳細なタスク(作業計画)を検討します。

　　　

ストーリーがテスト可能であることを確認するストーリーがテスト可能であるかどうかは、カードを見るたびに気にする必要がありますが、スプリント計画はそれを確認する最後のチャンスです。

ストーリーをどのようにデモンストレーションするか検討するスプリントの終了時にはステークホルダー向けにデモを行います。そのストーリーの成果物や価値をわかってもらうためには、効果的なデモンストレーションが必要です。そのストーリーははっきりと見せられるでしょうか。完成したストーリーを、プログラマやテスター以外の人にも簡潔に説明する方法について検討します。

ストーリーの規模を明らかにするチームはストーリーの規模を、プランニングポーカーなどを用いて見積もっていきます。テスターもチームの一員として参加し、必要に応じて明確化(clarify)のための質問をしましょう。

大きすぎるストーリーは分割します。その際にも、最低限の機能はどこか？ テスト工数を最小限にしつつ、そのストーリーの有効性を確認できる実装方法はないか、検討を行います。

まだ経験のない技術を採用するときなどは、「スパイク」という技術確認のためのストーリーを行います。有限の調査検討時間を決めて、その技術を採用する意味があるかどうかを検討します。その結果、次回以降のスプリントではより正確に見積もれるようになります。

ソフトウェア品質シンポジウム2012 併設チュートリアル 配布資料

(3)スプリントの進行とテスト、完了の確認チームは、ストーリーを優先順位に従って実装していきます。受け入れテストの自動化を行う場合は、開発と平行して受け入れテストの自動化を進めます。

　　　デイリースクラム(朝会)スクラムでは、一日一回のミーティングを行って、日々の進捗やメンバーの状況を確認します。以下の３点を手短かに共有します。　・昨日やったこと　・今日やること　・問題になっている事 (前進を妨げているもの)

開発者との協同作業開発者の隣に座ってテストを実装する(ペアテスト)、気になる部分の進捗を適宜見せてもらう、ストーリーが持つ価値の理解を深めるためにチーム外の人々と話すなど、チームが前進するために、できることを行っていきましょう。

不具合との対峙スプリント進行中に、以前リリースしたシステムの不具合(バグ)が報告される事があるでしょう。この場合は、スプリントで計画されたストーリーよりも優先して対処しなければならない事がほとんどでしょう。すぐに直せる場合は、修正し、リグレッションテストを行い、修正リリースします。 テストが自動化されていれば、リグレッションテストは短時間ですみます。不具合への対処時間が短くなり、スプリントの見積もり工数からのズレも軽微ですみます。

大きな対策が必要な場合は、プロダクトオーナーに説明し、プロダクトバックログに記載します。

スクラムでは、プロダクトバックログを優先度順に記述しているため、予定外の作業を行う場合にどのストーリーが実装できなくなるかが明らかです。プロダクトオーナーに報告し、必要な対策(ステークホルダーへの説明など)をとってもらいます。

ソフトウェア品質シンポジウム2012 併設チュートリアル 配布資料

(4)スプリントデモ、レトロスペクティブ(ふりかえり)スプリントの終盤では、完成したストーリーをステークホルダに見せ、フィードバックをもらいます。その後、チームでスプリントをふりかえって、今後改善できるところがないか検討します。

　　　いつでも出荷可能なプロダクトの増分スクラムでは、各スプリント中に各ストーリーを「いつでも出荷可能なプロダクトの増分 (Potentially shippable increment)」に仕上げます。プロダクトオーナーの出荷判断が下ればいつでも出荷に応じられる状態、ということです。受け入れテストはすべて終了しており、事前に定義した「完了の定義(DoD)」にしたがって、その他の確認がすべて終了した状態です。

デモンストレーションのための過剰な準備をしてはならないスプリントデモでは「いつでも出荷可能なプロダクトの増分」のあるがままをステークホルダーに見せます。デモンストレーションのために過剰な資料や、ハリボテを準備してはいけません。うまく伝えられなかった場合は、次に向けて改善策を検討しましょう。

チームとして改善するスプリントデモは、チームの間違いや、ステークホルダー間の意見の食い違いなどを発見する、よいチャンスです。多くの人は、動くソフトウェアや明日から使うような状態のツールがあってはじめて、具体的な想像力が働きます。チームは、成果物を提示し、ステークホルダーの意見に耳を傾けます。どんな情報も「見つかってよかった！」と考えましょう。

レトロスペクティブ(ふりかえり)を行って、チームとして改善のヒントを探っていきます。すぐにできない対策も、メモをとっておき、順に解決していきます。すぐに解決できる問題だけを問題と考えるのは危険です。

チームは前進しました。ささやかな成功を祝い、次のスプリントに備えましょう。

ソフトウェア品質シンポジウム2012 併設チュートリアル 配布資料

(5)リリースとデリバリー

　　　　

製品を磨き上げる複数のスプリントで作られた「いつでも出荷可能なプロダクトの増分」を組み合わせてリリースする場合には、結合した状態で、利用者にとって不都合がないかをチェックする必要があります。まず、利用者になりかわって、チームとして探索的テストを行います。あらかじめ時間を決め、全員で使ってみるのです。可能であれば、実際のユーザー像に近い第三者に協力をあおぎ、試しに使ってもらうところを、後ろから観察させてもらうと効果的です。見つかった問題はすぐさま修正を検討します。

問題が発見されない/修正済みになったら、利用者の一部に使ってもらうことも検討しましょう。UAT(ユーザによる受け入れテスト)や、A/Bテスト(一部の顧客に先行リリース)を通して、リリースされるストーリーの価値を確認していきます。

本番にリリースできてはじめて価値がある本番環境へのリリースを行い、顧客に成果物を届けることで、初めて価値が発生します。リリースできないストーリーはすべて在庫です。デリバリーをスムーズに行えるように環境を整備することは、非常に重要です。　・ 開発環境、ステージング環境、本番環境は同じソースコードで展開可能ですか？　・ 本番環境の構成はバージョン管理システムで管理されていますか？ 　・ デプロイは自動化されていますか？　・ リリースをスムーズに行える手順が確立できていますか？　・ 問題があった場合の切り戻しの手順や影響は明らかですか？　・ 稼働監視は考慮できていますか？　・ 本番環境での障害時に情報を適切に収集する仕組みはできていますか？

ソフトウェア品質シンポジウム2012 併設チュートリアル 配布資料

成功への鍵最後に、『実践アジャイルテスト』より、リザ・クリスピンとジャネット・グレゴリーの挙げる成功への鍵を紹介します。

　・1 : チーム全体のアプローチ (whole team approach) 　・2 : アジャイルテストの考え方を採用する　・3 : 自動リグレッションテスト　・4 : フェードバックを与え、受ける　・5 : コアプラクティスの基礎を築く (CI, テスト環境、技術的負債の管理)　・6 : 顧客と共同作業する　・7 : 広い視野を持つ

もしかすると、企業の中にはさまざまな組織の壁があり、簡単にはチーム全体のアプローチができないと感じることもあるかもしれませんが、一つ一つ分析し、実験を積み重ね、できることを増やしていっていただくことを祈っております。

謝辞本原稿は、執筆の過程で山口鉄平氏、木村卓央氏、細谷泰夫氏の助言をいただきました。また、本研修は森崎修司氏よりきっかけをいただきました。ジャネット・グレゴリーさんには東京での研修の開催を通じて多くのことを教えていただきました。ここに感謝を申し上げます。

ソフトウェア品質シンポジウム2012 併設チュートリアル 配布資料