XP祭り2014に参加してきました（２）
※本記事はNCデザイン&コンサルティング㈱のブログに私が記載したものを転載・修正したものです。
9/6にXP祭り2014に参加してきましたので印象に残った事をまとめたいと思います。
まとめていたらかなりのボリュームになってしまったので、２回に分けて記述したいと思います。 今回は後半戦です。
STARのスコープは、JSTQBでいう所のシステムテスト/受け入れテストです。狩野モデルでは、製品の品質は魅力的品質（充足されれば満足、不充足でも仕方がない）と当たり前品質（充足されれば当たり前、不充足で不満）で成り立っているとあります。魅力的品質も重要だけれども、もう一方の当たり前品質を落とさない事がとても難しい。また、製品の進化は早く、少し前の魅力的品質は、次の魅力的品質の実装に推移すると当たり前品質になってしまう。そのため、当たり前品質を検証のスコープはどんどん広がり、それを落とさないための技術が必要。
アジャイルのようなインクリメンタル開発のリスクはデグレード。アジャイルは新規プロダクトでも初回のイテレーション以外は派生開発でありデグレがつきものです。だから回帰テストの自動化が注目を集めます。
アジャイルを採用しているプロジェクトでも、システムテストや受け入れテストは全てのイテレーションが終わってから場合が多い。そして、結局プロジェクトの終盤でバグが発生してその修正に追われます。イテレーション後のシステムテストは最終局面であるため、バグはチームにフィードバックされないし、プロセスも改善されない。計画ゲームとプロセスの改善を続けていても、結局最後がパワー勝負。これって本当にアジャイルなのか？フィードバックループを早くするなら、システムテストもイテレーション内でやるべきではないか。
という事で、STARではシステムテスト/受け入れテストの自動化を研究されているようです。
また、システムテストの自動化に伴ってテストエンジニアのロールが変わるとの事。従来のテストエンジニアのロールは、テスト計画・設計・結果の分析と報告であった。しかし、自動化に伴って、テストオートメータというロールが必要。テストオートメータは、自動テストの計画・設計・開発・運用を行うロールで、その結果を随時開発チームにフィードバックする。開発チームも新しいストーリーに着手したり、完了したらその内容をテストオートメータに共有する。アジャイルでは、イテレーションを繰り返しながら徐々に機能をくみ上げて行くため、テストできる箇所が徐々に増えたり、途中で変わったりする。そのため、WFの時よりテスト設計が高度であり、設計と運用に柔軟性が必要になる。それを解決するためには、特別な役割を設け、常に開発者とコミュニケーションを取りながら進める必要があるとの事でした。
これは私の私見ですが、アジャイルを実践しているプロジェクトでも、最後にシステムテスト/受け入れテストを実施されている案件が多い気がします。私もそういう風に運営したプロジェクトが多かったです。アジャイルだとイテレーション中はショーケースで動く物を見せるために力を注ぐ傾向があるため、システムテストフェーズでは細かな不具合や、イレギュラー処理の実装漏れが多数発見されます。そのため、リリースイテレーション（リリーススプリント）みたいな機会を計画しておき、帳尻合わせをする事が多かったのです。今後このような問題を解決するために、このイテレーションの中でシステムテスト/受け入れテストを行うという方法は重要になってくるのだろうと思います。
今年のAgile2014では、2年前のAgile2012に比べ、アジャイル/スクラム/リーンの基礎はもう周知である事を前提に、基礎セッションは少なくなっているとのこと。
世界を代表するカンファレンスでも、もう基礎を理解している事は前提になってきているようで、その上で現在のトレンドは以下の３つとのこと。
内容としては、マインドやスピリチュアルな話しかなく、「でどうするの？」という部分の話があまりないのが気にかかったとの事。それでも、方法論よりそういうマインド系の話のほうがアメリカ人には受けるらしく、一方で諸外国の参加者はしらけているようです。一方で、アメリカではこのような方法論やビジネスを無視したマインドだけのアジャイルコンサルタントにプロジェクトを失敗に追い込まれる事例が多いのだとか。そのため、アメリカではアジャイルコンサルタントは信用されていないらしいです。鷲崎先生がその理由の考察として、アメリカのような多民族国家では、プロセスや方法論の前にマインドを合わせる事が最大の課題になっているため、このようなマインド的な話が受けるのではないかと話されていたのが印象的でした。Agile Japan 2014の基調講演で水野さんが単一民族国家のアドバンテージとして、文化・価値観・習慣が揃っている事で意思疎通がスムーズに行える点を挙げて、日本はこのアドバンテージを生かすべきとおっしゃっていましたが、日本のアジャイル業界やソフトウェア業界は、まさしくこの点をうまく活用すべきなのでしょう。
Agile2014で人気のあったメトリクス
印象的だったのは、バーンダウンチャートを書くだけで見える化していると考えていないか？バーンダウンが落ちないのはなんで？理由を計測しないとダメだよねという話。私自身、バーンダウンチャートの先にあるものを可視化する事を考えられていなかったと反省しました。そして、それをチーム内のコミュニケーションの手段として活用する事で、改善のサイクルをより良くまわす事ができるんですね。
多くの刺激を貰えたので、この活気を関西にも持って帰りたいなと思います。
9/6にXP祭り2014に参加してきましたので印象に残った事をまとめたいと思います。
まとめていたらかなりのボリュームになってしまったので、２回に分けて記述したいと思います。 今回は後半戦です。
関連記事
参加したセッション
- XPの俺 / XP再考を再考する【基調講演】 関 将俊さん
- チームビルディングのためのワークショップ ～アジャイルの導入の勝算は、チームビルディングにあり！～【ワークショップ】 うえだ まさみさん
- システムテストも自動化していこう 永田 敦さん
- 国際会議 Agile2014の風 ～とある参加報告～ 鷲崎 弘宜先生、伊藤 宏幸さん、山本 洸希さん
システムテストも自動化していこう 永田 敦さん
永田さんは、STARと呼ばれるテスト自動化研究会(STAR: Software Test Automation Research Group Jp)に参加されておられます。今回はこのSTARで取り組んでいるシステムテストの自動化とはどういう事かという講演でした。具体的な手法は、2014/12/14に開催されるシステムテスト自動化カンファレンス 2014で話があるそうです。STARのスコープは、JSTQBでいう所のシステムテスト/受け入れテストです。狩野モデルでは、製品の品質は魅力的品質（充足されれば満足、不充足でも仕方がない）と当たり前品質（充足されれば当たり前、不充足で不満）で成り立っているとあります。魅力的品質も重要だけれども、もう一方の当たり前品質を落とさない事がとても難しい。また、製品の進化は早く、少し前の魅力的品質は、次の魅力的品質の実装に推移すると当たり前品質になってしまう。そのため、当たり前品質を検証のスコープはどんどん広がり、それを落とさないための技術が必要。
アジャイルのようなインクリメンタル開発のリスクはデグレード。アジャイルは新規プロダクトでも初回のイテレーション以外は派生開発でありデグレがつきものです。だから回帰テストの自動化が注目を集めます。
アジャイルを採用しているプロジェクトでも、システムテストや受け入れテストは全てのイテレーションが終わってから場合が多い。そして、結局プロジェクトの終盤でバグが発生してその修正に追われます。イテレーション後のシステムテストは最終局面であるため、バグはチームにフィードバックされないし、プロセスも改善されない。計画ゲームとプロセスの改善を続けていても、結局最後がパワー勝負。これって本当にアジャイルなのか？フィードバックループを早くするなら、システムテストもイテレーション内でやるべきではないか。
という事で、STARではシステムテスト/受け入れテストの自動化を研究されているようです。
また、システムテストの自動化に伴ってテストエンジニアのロールが変わるとの事。従来のテストエンジニアのロールは、テスト計画・設計・結果の分析と報告であった。しかし、自動化に伴って、テストオートメータというロールが必要。テストオートメータは、自動テストの計画・設計・開発・運用を行うロールで、その結果を随時開発チームにフィードバックする。開発チームも新しいストーリーに着手したり、完了したらその内容をテストオートメータに共有する。アジャイルでは、イテレーションを繰り返しながら徐々に機能をくみ上げて行くため、テストできる箇所が徐々に増えたり、途中で変わったりする。そのため、WFの時よりテスト設計が高度であり、設計と運用に柔軟性が必要になる。それを解決するためには、特別な役割を設け、常に開発者とコミュニケーションを取りながら進める必要があるとの事でした。
これは私の私見ですが、アジャイルを実践しているプロジェクトでも、最後にシステムテスト/受け入れテストを実施されている案件が多い気がします。私もそういう風に運営したプロジェクトが多かったです。アジャイルだとイテレーション中はショーケースで動く物を見せるために力を注ぐ傾向があるため、システムテストフェーズでは細かな不具合や、イレギュラー処理の実装漏れが多数発見されます。そのため、リリースイテレーション（リリーススプリント）みたいな機会を計画しておき、帳尻合わせをする事が多かったのです。今後このような問題を解決するために、このイテレーションの中でシステムテスト/受け入れテストを行うという方法は重要になってくるのだろうと思います。
国際会議 Agile2014の風 ～とある参加報告～ 鷲崎 弘宜先生、伊藤 宏幸さん、山本 洸希さん
私は、世界のアジャイルの情勢を確認するために、このセッションを聞きにいきました。今年のAgile2014では、2年前のAgile2012に比べ、アジャイル/スクラム/リーンの基礎はもう周知である事を前提に、基礎セッションは少なくなっているとのこと。
世界を代表するカンファレンスでも、もう基礎を理解している事は前提になってきているようで、その上で現在のトレンドは以下の３つとのこと。
エンタープライズアジャイル
エンタープライズアジャイルは、企業全体レベルでのアジャイルを実現しようという考え方です。伊藤さんのブログ(Agile2014に参加してみて分かった昨今の世界のアジャイル事情)に書かれていますが、私もこのエンタープライズアジャイルを「大規模プロジェクトでのアジャイル」と誤解していました。内容としては、マインドやスピリチュアルな話しかなく、「でどうするの？」という部分の話があまりないのが気にかかったとの事。それでも、方法論よりそういうマインド系の話のほうがアメリカ人には受けるらしく、一方で諸外国の参加者はしらけているようです。一方で、アメリカではこのような方法論やビジネスを無視したマインドだけのアジャイルコンサルタントにプロジェクトを失敗に追い込まれる事例が多いのだとか。そのため、アメリカではアジャイルコンサルタントは信用されていないらしいです。鷲崎先生がその理由の考察として、アメリカのような多民族国家では、プロセスや方法論の前にマインドを合わせる事が最大の課題になっているため、このようなマインド的な話が受けるのではないかと話されていたのが印象的でした。Agile Japan 2014の基調講演で水野さんが単一民族国家のアドバンテージとして、文化・価値観・習慣が揃っている事で意思疎通がスムーズに行える点を挙げて、日本はこのアドバンテージを生かすべきとおっしゃっていましたが、日本のアジャイル業界やソフトウェア業界は、まさしくこの点をうまく活用すべきなのでしょう。
テスト手法
日本でもBDDやATDDは注目されつつありますよね。私は昨年受講したCSM研修の講師がJim Coplienであり、Scrumの研修中にも関わらずTDDの是非の議論が盛り上がっていたので、BDDやATDDには興味を持っていました。そんな中で、今回紹介があったのが以下の２点。- Exploratory Testing（探索的テスト）
特別新しいものではないですが、従来の記述的テストだけでなく探索的テストが注目されている。いわゆる、テストをしながら次のテストケースを考えていくというやり方です。テスト時にはテストチャーターと呼ばれる原則・方針を決めて実施します。テストチャーターによって、フィーチャや複雑性、苦情、構成、ユーア、テスト性、可変性、相互性、データ構造、シナリオ等が限定され、限定した領域をテストで分析していきます。
今回はどのような場面でこの探索的テストを活かすのかまでは話を聞けなかったですが、想像するに、テスト用の部隊を用意する、またはテストを集中的に実施する時間を用意して、そこで、品質を分析したい、または品質が低い機能や事象に対して適用する事で、あらかじめテストケースを定義する記述的テストでは発見できない問題の抽出や分析を行うのではないかと考えています。これは、基調講演であった忍者式テストのメリットに通じる部分があり、１つのプロダクトを継続的にエンハンスしていく事を念頭においているアジャイルにおいて、注目されるべき領域なのだと感じました。 - Mutation Testing
テストコードが正しく作られているかを確認する手法です。具体的には、対象のプロダクトコードの一部を機械的に書き換えて、わざとバグを含ませたコードを作ります。そして、改変前の正しいプロダクトコードに対して作られたテストコードを、改変してバグの含まれたプロダクトコードに対して流した時に、正しくバグを検知するかという事を検証するというものです。一般的に、バグが多く含まれる部分というのは分岐や符号部分にあるため、プロダクトコードの分岐条件や符号を意図的に改変する事で実施するようですが、これを人手でやるのは大変なので、基本的には機械（ツール）にやらせます。このツールが進化しオープンソース化された事で注目を浴びて来ているようです（代表的なオープンソースツールにPITという物があるようです）。
確かに、TDD等、xUnitを使ったテストコードを書く機会が増えてきましたが、そのテストコードの妥当性を機械的に検証する方法が、カバレッジくらいしか無かったので、このテストコードの品質を自動検知してくれるツールの導入はおもしろと思いました。
メトリクス
メトリクスの話は時間が無くなった事と、発表者の伊藤さんが最後LT大会のネタにされており、ネタバレするという事で割愛になりました。しかし、LTの中で発表があった内容を簡単にまとめました。Agile2014で人気のあったメトリクス
- Cumulative Flow Diagram(CFD)
- スループット（ある一定時間で、どれだけのチケットが終了しているのか？）
- サイクル・タイム（チケットが次のフェーズに移動するのに、どれだけ時間がかかっているのか？）
- リード・タイム（チケットが開始してから終了するまで、どれだけ時間がかかっているのか？）
印象的だったのは、バーンダウンチャートを書くだけで見える化していると考えていないか？バーンダウンが落ちないのはなんで？理由を計測しないとダメだよねという話。私自身、バーンダウンチャートの先にあるものを可視化する事を考えられていなかったと反省しました。そして、それをチーム内のコミュニケーションの手段として活用する事で、改善のサイクルをより良くまわす事ができるんですね。
所感
基本、関西勤務の私は、東京開催であるXP祭りに参加するのは今回が初めてでした。XPはどことなくScrum人気に押されがちで少し下火になっているのかなと思っていましたが、東京のXP祭りはにぎやかでした。そして、Scrumの話は出てくるものの、XPを中心に話をされる方が多かったのでScrumがベースの私にはいろいろと新鮮でした。多くの刺激を貰えたので、この活気を関西にも持って帰りたいなと思います。
