この記事はJohanna Rothmanによるゲスト投稿です。
あなたのいるアジャイルチームでは、開発者は開発者と共同し、テスターはテスターと共同するものと考えているかもしれません。しかし、専門分野を越えてもっといろいろな人たちが共同すれば、製品はもっとよくなる可能性があります。それに、もっと速く作業を完了できるかもしれません。
開発者とテスターのコラボレーションの例
テスターのエイミーは、いつもテストチームの皆とお昼を食べています。開発者はたいてい別のテーブルで食べています。今日、たまたま開発者のデイヴィッドとジョンがパフォーマンスのテストについて話しているのが耳に入りました。ふたりは行き詰っているようでした。
エイミーはふたりのほうを向いて声をかけました。「先週、そのあたりのテストを作ったんだけど。見てみる？」
デイヴィッドはうつむいてお皿を見つめていました。まあ、デイヴィッドがとてもシャイなのは知っています。
ジョンが答えました。「うん。送ってくれる？」
「もちろん。お昼が終わったらすぐ送るね」エイミーはテスターたちのほうに向きなおり、お昼を終わらせました。
オフィスに戻ると、デイヴィッドとジョンに先週作ったテストのリンクを送信しました。
1時間ほどで、デイヴィッドからメッセージが来ました。「やった！すごく助かった。ありがとう！」
ろくに口もきかなかった人から感嘆符つきのメッセージを受け取るなんて、記念すべき日に違いありません。
何週間か経って、エイミーはお昼を食べながら、テストの課題の1つについて話をしていました。そこへ誰かに肩をたたかれました。
デイヴィッドです。「たぶん、どうすればいいかわかると思う」目を合わせようとはしませんでしたが、少なくともしゃべってはいます。
「お昼のあと、席に行って話すのでかまわない？」エイミーは尋ねました。
「うん」
お昼の後、エイミーはデイヴィッドのオフィスに寄りました。ふたりはじっくり問題を話し合い、ホワイトボードにいくつか図を描きました。そしてデイヴィッドが言いました。「ちょっとコードを書いてこれを試してみてもいいかな？」
「どうぞ。次に私にもやらせてくれるなら」
ふたりは1時間ほどかけて小規模な試験的テストを作成しました。ふたりは交代でテストを作成しました。1時間経ったときには、エイミーには何をすべきかが見え、デイヴィッドはコードのどこを変えればもっとテストしやすくなるかがわかりました。
これは従来のドライバーとナビゲーターというペアリングとは違います。それでも、ある種のペアリングであり、ふたりにとってはうまくいきました。ペアで作業することで、エイミーもデイヴィッドも個別にやるより多くのことを学んだのです。
ペアリングは職種を越えて有効
アジャイルを実践しているとされるチームでも、開発者とテスターが個別に作業している例をよく見ます。開発者が別の開発者とペアを組むのはよいでしょう。テスターが別のテスターとペアを組むのもよいでしょう。しかし、専門を越えてペアを組むと、より良い結果が得られるケースもよくあります。
それは開発者とテスターの間だけに限定されません。テスター/データベースのエキスパートやテスター/ユーザーインターフェイスのエキスパートという組み合わせもあり得ます。
テスターがデータベースのエキスパートと組めば、エキスパートはデータベースの内部構造をよりテストしやすいものにする方法を学べることが多いでしょう。そして、テスターのほうはテストをより簡単に、速くする技を学べるかもしれません。
ある企業では、テスターはテストしようとするとき、毎回1時間近くかけて一からデータベースを再作成していました。データベース管理者がテスターのしていることを見て、必要とするデータベースをたった5分で再作成する方法を教えました。テスターは興奮しました。いっぽうデータベース管理者は、テスターたちがデータベースの問題を見つけるのをこころよくは思っていませんでしたが、テスターたちがDBの変更をより速くテストできるようになったことを喜びました。
別の会社では、ユーザーインターフェイスのエキスパートのアルが設計する画面が、テスターのボブから見ると使えないという状態でした。
ボブが尋ねました。「ねえ、ずっとこの画面で手こずっているんだけど。問題のところを見てもらえないかな」
アルは同意し、ボブの隣に座りました。ふたりは互いに自分の見解を説明しました。アルは問題を認識し、画面を変更しました。
ペアリングは有効です。モブプログラミングならいっそう効果があるかもしれません。
モブプログラミングはチーム全体の学びに役立つ
チームでモブプログラミングを行うということは、全員が力を合わせて1つの問題に取り組むということです。一般的に、モブではキーボードの前に座るタイプ担当者がいます。中心的なナビゲーターについて、あるいは誰もがいっぺんにタイプ担当者に話しかけることができるかどうかについてガイドラインを決めてもよいでしょう（進行中の作業について議論すると決めた場合を除いて、皆がいっぺんに話すことはお勧めしません）。
モブを実施するのに必ずしもアジャイルチームである必要はありません。必要なのは、1つの問題を皆で解決する意欲だけです。
エイミー、デイヴィッド、ジョンはアジャイルを標榜するチームの一員でした。しかし、チームメンバーが共同で取り組むことは多くありませんでした。チームメンバーが共同していなかったために、作業はフィードバックループという点では「時間がかかりすぎ」ていました。
チームのメンバーは、お昼でも職能グループごとに分かれて食べていました。昼食の時間は非公式な実践コミュニティになっていました。ところが、チームとして皆で問題を議論して解決することのメリットを活かしてはいませんでした。
エイミーとデイヴィッドは、ペアでのコードアンドテストの試みがどんなふうだったかをチームに報告しました。デイヴィッドは言いました。「しゃべるのはあまり好きじゃないけど、これは本当にうまくいった。もっと難しい問題のひとつでモブプログラミングを試してみたい」
チームのほかの人たちは驚きましたが、やってみたいと意欲を示しました。大きなスクリーンを使えるよう、カンファレンスルームを押さえました。
ナビゲーターとなる1人からチームの他の人たちがタイプ担当者にしてもらいたいことを説明するということで合意しました。5分ごとに役割を交代するということでも合意しました。また、ナビゲーターの番が来たら、それぞれが自分自身の専門に従って進めるということでも合意しました。
実装に1週間近くかかるだろうと考えられていた機能が選ばれました。最初は、何一つ意見が一致しないように思えました。そのときデイヴィッドが言ったのです。「これを一連の実験だと考えてみよう。やりたい実験のリストは？」
チームは18個の試みを挙げました。これで、計画らしきものができました。実験を１つずつコードに落としてテストするのです。
途中で開発者の1人が、思考を進める方法として、テスト駆動型開発をやってみてはどうかと提案しました。それを試してみました。このやり方をチームの半数は気に入り、半分は嫌がりました。元通りのやり方を続けることにしました。
その日の終わりには、18個の中から2つの選択肢にまで絞られました。次の日も継続して、チームとして何ができるか試すことで合意しました。
次の日、皆が集まると、午前中を費やして機能を完成させました。コード一式、テスト一式、必要なリリースノートまでができました。チームは3日以上かかると考えられる機能があったら、毎回モブプログラミングを行うことに決めました。
しかし何よりの成果は、皆が学んだことです。開発者は自分たちがコードを作成するより前にテスターがどんな手がかりを必要としているかを知りました。テスターは開発者がどのようなデータを望んでいるかを知りました。バグレポートではなく、テストからデータを組織する方法です。
誰もが製品の内部についてより多くを学び、開発とテストを簡略化する方法を学びました。
チームのコラボレーションは効果的
チームがチームとして—専門分野を越えて—作業することが増えるほど、作業を終わらせることが容易になります。さらに、誰にとっても予想以上の学びがあります。
まだ分野を越えたコラボレーション、特にテスターとして開発者とのコラボレーションを行っていないなら、検討してみてください。また、どうしたらチームがモブやその他の方法で共同できるかを考えてみてください。
チームとしての取り組みが増えるほど、作業はより速く、容易になるでしょう。
Pragmatic Managerとして知られるJohanna Rothmanは、顧客の難しい問題に対して率直なアドバイスを提供しています。リーダーやチームが問題を直視し、リスクを解決し、製品開発を管理できるよう支援します。Johannaはこれまでに14冊の書籍と多数の記事を執筆しています。jrothman.com および createadaptablelife.comで月一回発行の電子メールニュースレター「Pragmatic Manager」およびブログをご覧ください。
（この記事は、開発元Gurock社の Blog 「Developer-Tester Collaboration: How and Why」2019年11月12日の翻訳記事です。）
