チームが「サイロ化」しないための仕掛け

テスターのくせに Janet Gregory さんと Lisa Crispin さんの書籍『Agile Testing』『More Agile Testing』を読まずに今日まできてしまったのですが、この二冊を凝縮（Condensed）した『Agile Testing Condensed』（日本語訳）くらいは目を通しておかないとね！ということで読みはじめました。

leanpub.com

この記事は本書に書かれていたある問題を取り出し、それに対してわたしたちのチームが普段やっていることをわたしの目線で紹介したものです。ツイートするには長いのでこちらに書きました。

チームが「サイロ化」する問題

複数のチームがすべて同じプロダクトで作業している大規模な組織でよく見られる問題の1つは、チームが「サイロ化」する傾向があることです。依存関係を解決するために他のチームと話すことを忘れています。（第3章：アジャイルにおけるテスト計画）

サイロ化とは：企業のある部門が、他の部門と情報共有や連携などをせずに独自（単独）に業務を遂行し、孤立してしまう状態のこと。

たしかにそうなりがちかもしれませんね。わたしたちが開発してるプロダクトもまあまあ大きいのですが、なるべくそうならないようにするためにいくつかの仕掛けがあります。仕掛けと言っても、普段なんとなくやり続けていることがサイロ化しないための行動やふるまいだったんだなと思うわけで、はじめに「仕掛け」があったわけではないのですけど。*1

以下に隣のチームとの仕掛けのいくつかを紹介します。隣のチームはプロダクトを構成するシステム（ソフトウェア）の構造的にもわりと近い存在です。それぞれのチームの規模は小学校の1、2クラスを想像してください。*2

毎朝10分、隣のチームと会話する

毎朝10分（8:45〜8:55）同じ場所に集まり、話をしています。
参加者：隣のチームリーダー（2名）、うちのチームリーダー、テスター（2名）、@m_seki（プロの無職）*3
開発状況に合わせて期間限定で特定のプログラマーが参加することもあります。
話す内容はいろいろ（一例）

昨日見つけた問題についての補足（チームを超えてチケットをあげている）
チケットにあげてないが気になっていること、心配していることは何か
昨日の話した問題や課題がどうなっているか（現在の状況を同期）
お互いのチームでホットな話題についての情報交換
一緒にやってほしい、教えてほしい、助けてほしいことの軽い予約
いまはどこの何にどれくらいの割合で注力すべきか（複数バージョンを並行開発してるため日々の調整を大事にしている。スケジュールや各プロジェクトの状況や問題の種類や大きさやそれに対するインパクトは常に変わっていくので。）

10分しかないのでお互いのチームが関係しそうでより重要と思うことから話します。自ずとみんながそうなります。いつもだいたい時間切れで終わるのですが、たった10分でも得られる情報は多いです。多いというより中身が凝縮されている感じ。自分のチームしか見ていないと外側の小さな変化（のちに自分のチームやシステム全体に影響を及ぼす何か）に気づくのが遅れがちですが、そういうことにも気づきやすくなります。

ここで得たことを元に隣のチーム（システム、ソフトウェア）とのつなぎ目とその周辺に気を配りながら、同僚のテスターとその日のテストを柔軟に変えていきます。

隣のチームのチケットを覗く

お互いのチケットは別管理ですが誰でも自由に見ることや書くことができます。チケットはわたし（テスター）にとってはお宝みたいなもので、毎日読むのが日課になっています。

毎朝10分の会話のあと、話題になったアイテムを索引にしてチケットを覗きにいきます。そこにはもうすこし詳しい内容（開発日記）が書かれています。読んで理解を深めたり、分からないことがあれば隣のチームの誰かに聞きに行きます。
午前中のうちに現在のイテレーションのチケットを一通り目を通します。特に自分で見つけたバグについては注意深く読みます。バグの原因はなんだったのか、どのように直そうとしているのか、プログラマーはどのようなテストをするつもりなのか、スムーズに修正作業が進んでいるのかに興味があります。これらは修正後の確認で何を試したらよいかを考えたり、プログラマーに質問、相談するための材料になります。

チームの外側も気にしてテストする

自分のチームがいくらうまくできても製品としてダメなら全然ダメという意識が多分ものすごく強いです。境界値にバグが存在するのと同じようにチームとチームの境界にも問題が潜みがちで、より気づきにくい特徴があるように思います。そのことは経験的にわかっているので要件定義の段階からプロダクト全体として何がどう変わるのか、変わったら何が嬉しいのかをみんなが気にしていて、たびたび話題にもなります。

同様にテストも薄くなりがちなので自分のチームを超え隣のチームの範疇にガツガツ入りこんで積極的に触っています。このときに『毎朝10分、隣のチームと会話する』や『隣のチームのチケットを覗く』で得た知識やノウハウや人脈を使います。あまり変なふうに触らないで…と思っているプログラマーもいるようですが（実際にそう言われたことがあります）お客さまが変なふうに触るかもしれないので、気にしないようにしています。なお、チームの外側をテストするのはテスターだけではありません。プログラマーもテストしています。

問題を見つけたら隣のチームへ話しに行く

この見出しだけ読むとはじめに引用した部分「他のチームと話すことを忘れている」に対する仕掛けがこれか、、、となるのですが、何がなんでも伝えたい！と思うことがないから話すことを忘れてしまうのではないか（仮説）を提起しておきます。問題を見つけたらと書きましたが『チームの外側も気にしてテストする』ので問題が見つかるとも言えますね。結局のところすべての行動やふるまいは全部どこかでつながっていて、これらの仕掛けの何もかもが単に「サイロ化」を防ぐためだけでなく、製品開発におけるさまざまな課題や問題に対してじわじわと効いてくるのだと実感しています。

おまけ

わたしたちのチームのNGワードに「合意する」「共有する」があります。あとメールを出しておしまい（あとはずっと返事待ち）は喜ばれないふるまいです。*4

おわりに

チームが「サイロ化」する問題について、隣のチームとの具体的な仕掛けや行動やふるまいをわたしの目線で紹介しました。途中で、隣のチームのことを書いているのか、自分のチームのことを書いているのか分からなくなるときがあったので、混乱された方がいたかもしれません。それくらいチームとチームの境界が曖昧になっているのですが、今から5年前のことを思い起こすとチーム間の結びつきはずっと薄かったように思います。

書きそびれましたが『隣のチームとの夕会』もあります（週4回、30分/回）。とりあえずやればうまくいくというものでもないので、何か秘密があるのだろうなあ。同じチームの @m_seki や @vestige_ に聞いたらまた違った視点での仕掛けが出てきそうです。もしかしたら『Agile Testing』や『More Agile Testing』にもサイロ化しないためのヒントやプラクティスが書いてあるのかもしれませんね。