アジャイル開発における、テストエンジニアの姿：Agile Japan 2015 レポート (27)

講演者であるJanetが、海外などの分散したチームでテスティングを行った経験をシェアしました。そのなかで、アジャイル開発におけるテストエンジニアの姿を示してくれました。

分散開発は難しい

アジャイル開発を行ううえで最も機能するチームは一拠点に集まったチームです。
しかし、グローバル企業であったり、企業合併、（理論的な）コスト削減といった理由で分散チームによる開発がおこなわれます。これには、必要な人を雇えたり、ダイバーシティを得られるなどの利点があります。

その一方で、余分なコミュニケーションコストがかかったり、フィードバックが遅くなるといった制約も発生します。

Janetは『実践アジャイルテスト』の執筆を行う際も、共著者であるLisaと地理的に離れた位置でコミュニケーションをとりながら進めていったそうですが、コミュニケーションにかかるコストは大きかったようです。
たとえば、カンファレンスに出すアブストラクトを書くのに、同じ場所にいるなら2時間もあれば書けてしまうところ、時差の問題で4日もかかったそうです。また、JanetとLisaが本を執筆時、Lisaの旦那様が体調を崩して執筆が進まないこともあったそうです。そのとき、JanetはLisaのもとを訪ねます。その結果、Lisaがどういう課題を抱えているか、言葉ではなくフィーリングでわかるようになったと言います。

Janetでも、一冊の本を書くために、距離の離れた場所にいる仲間と作業を進めるのは大変。私たちがオフショア開発を行うときに多くの問題が出てくるのも、当然かもしれません。

分散開発における障害と対策

Janetは分散チームで開発を行ううえで障害となる要因と、その対策を示してくれました。

対策について、もう少し細かく見ていきます。

• コミュニケーションの取り方一つをとっても、Emailは情報をブロードキャストしたり、会話のあとのフォローアップに向いている。
  電話やメッセンジャーもそれぞれ長所が違うので、使い分ける必要がある。
• Virtual Facetimeとして、相手側の気候がわかるくらい、大きなスクリーンを使ってお互いを映し合いながら朝会を行う。
• チャットやWiki、Idobataのような協調ツール、Astah*のようなマインドマッピングツールといったCollaboration Toolを使う。
• 分散チーム同士で重なる時間帯を作り、そこでミーティングを行ったり、計画を共有する。ふりかえりを行う。

といったことができるようです。

分散開発にテスティングで立ち向かう

Janetはテストエンジニアならではの分散チームへの貢献の仕方も示してくれました。

Janetの著書『実践アジャイルテスト』には、各章の要約としてマインドマップを掲載しています。このマインドマップを分解して、ウォークスルーレビューを行うことで、すばやいフィードバックを行ったり、求められるふるまいを示すことができる。こうした取り組みでチーム内の共通認識を醸成できる。単体テストや受け入れテスト、それぞれのフェーズに応じたDoneの定義を示す。DeveloperやPOから聞いたことに対して、テストという形式で絵を描く。といった形で共通理解を作っていくこともできる。

日本の研究会・交流会も気づいている

A-1のセッション「各種協会・研究会・交流会からのエール！一緒にスクラムを組み前進！NextStageへトライ！」でも、アジャイル開発におけるテストエンジニアの姿について語られていました。

日本科学技術連盟ソフトウェア品質保証部長の会、梯 雅人様の講演では、アジャイル開発における品質保証部門の関わり方として、

• 自己組織化したチームの力を最大限に発揮させる
• データで示して、開発者に気づきを与える
• ファシリテーターとしてのQA
• チームに入ってコミュニケーションの基盤を作る
• 製品コードを書く以外はなんでもやる。でも、品質中心、ユーザ目線は忘れない

ことが必要ではないかと紹介されていました。

また、ソフトウェアテスト技術振興協会ASTERの長谷川様の講演では、アジャイル開発におけるテスティングの当てはめ方として、

• 探索的テストをアジャイルに行う
• 自動化で支援する
• 品質観点をナビゲートする
• 開発者を技術でサポートする

があるのではないかと語られていました。

アジャイルなテストエンジニアの姿

Janetがこの講演で示してくれたことは「テストエンジニアは、プロジェクトの初期から品質の観点でアジャイルチームに関わる」ということだと思います。特に、テストを使ってDeveloperにすばやくフィードバックを返す方法は、テストエンジニアだからこそできることだと思いました。

私は以前『実践アジャイルテスト』の読書会に参加していたのですが、そのなかで紹介されたプログラマとの共同作業としての「ペアテスト」を思い出しました。ペアプロではなく、ペアテスト。それをコーディングレベルだけではなく、POや顧客に対しても、Integration TestやAcceptance Testで適用していくことができるのだと気付きました。私自身はDeveloperですが、こうしたテストエンジニアと共同で仕事ができると楽しいのだろうなと改めて感じています。

また、Virtual Facetimeの使い方や、コミュニケーションツールの使い方も、品質を上げるための戦術といえるのではないでしょうか。このあたりはDeveloperでもできることだと思います。ですが、テストエンジニアだからこそ、品質にコミットするための戦術として、より運用できるのかもしれません。

よくよく見てみると、個々の手法は、アジャイルチームでなくても実行できそうなものです。ですが、プロジェクトの後半から行っても、効果は小さいでしょう。プロジェクトの初期から、品質を高めるためにできることをなんでもやる。こうした取り組みを行いやすいのがアジャイル開発であり、アジャイルなテストエンジニアなのでしょう。

もっと知りたい！Agile Japan

Agile Japanとは

• Agile Japanとは
  
• 公式サイト：Agile Japan
• Twitter：@agilejapan
• Facebookページ：Agile Japan

レポートコーナー

• Agile Japan 2015：http://www.manaslink.com/aj2015
• Agile Japan 2014：http://www.manaslink.com/aj2014
• Agile Japan 2013：http://www.manaslink.com/aj2013
• Agile Japan 2012：http://www.manaslink.com/aj2012
• Agile Japan 2011：http://www.manaslink.com/aj2011