キーワードは3つ、テスト期間ゼロへの挑戦：Agile Japan 2016 レポート(9)

本セッションは、ユーザや開発者にとって理想の開発・テストを追い求めるプロダクトオーナー兼テストアーキテクトのkyon_mm氏と、共に試行錯誤しながら実現していったチームメンバーのotf氏の2名による発表でした。35分という短い時間にも関わらず、実践的な内容にまで踏み込んだセッションとなりました。

テスト期間を設けていますか？

冒頭、kyon_mm氏より3つの質問がありました。

• アジャイル実践者が提案しているプロセスで仕事をしているとき、統合テストやシステムテストのいくつかは最後にまとめてやっている
• テストってプログラムのように速くできないし、テストは各フィーチャー、ストーリーごとに網羅できない
• 上みたいなことは思っていないけど、どうしてもテスト期間のようなものをつくらないと、うまくいかない

順に読み上げられ、当てはまる人は挙手をします。はっきりと見えなかったのですが、どの質問にも多くの手があがっていたようです。「よかった」と笑みがこぼれるkyon_mm氏。参加者の多くは、テスト期間を設けているか、テスト期間がないとうまくいかないと考えているようです。

kyon_mm氏、うさみみを付けて登壇

自分の現場では、開発と評価が組織レベルでわかれています。テスト期間を設け、評価側が統合やシステムレベルのテストをまとめて行っています。そんな環境なので会場の反応は当たり前であり、「テスト期間をつくらず、どうやって品質を上げているのだろう？」と興味をそそられました。

うまくいかないチーム、変えるべきは仕事のやり方

実際の取り組みを話す前に、チームや開発状況の簡単な説明がありました。
kyon_mm氏とotf氏は2人を含めた合計4名のチームで、Web APIをつくるためのフレームワークやライブラリの受託開発を行っています。最初の3年間は、アジャイルでよく登場するカンバンやgitなどのツールを活用していましたが、終盤に大量にバグが見つかるなど、うまくいっている実感はなかったとのことです。
そこで、4年目に入るときにチームの仕事のやり方を変えることにしました。今回はその中からテストに絞った話となります。

チームが抱えていたテストの課題は、

• 後回しになっているテストがあり、リリースできないものが堆積する
• 特定の品質が満たされない傾向にある

の2つでした。
これらを解決するために「全員で常にテストする」という方法が挙がりました。しかし、常にテストさえすればうまくいくか？というと、そうではありません。

そもそも課題を生み出していた要因はなにか本質に目を向けたところ、

• リリース可能
• 学習
• オーナーシップ

という3つのキーワードが重要だと気づいたそうです。この3つのキーワードをチームで議論し、やるべきことに向き合ったことで、最終的にテスト期間をゼロにできたとのことでした。

改善の3つのキーワード

リリース可能

「リリース可能」とは、ストーリーを完了させてリリース可能な状態にすること。今までリリース可能にできなかったのは、技術や意識の問題だけではなく、さまざまな習慣やフォースによるところが多かったそうです。
そこで、まず「リリース可能」にするという目標を掲げ、障害を分析して一つずつ対処しました。

学習

テストとは「学習」するということ。テスト工学とは「効率よく学習する方法の体系的知識の一部」です。
なにかを学習する際、「期間」や「対象」、「ゴール」の設定は重要です。テストも同じで、「いつまで」に「どんな情報」が「どれくらいほしいか」に基づいて戦略を立てるのが大切とのことでした。

テストとは「学習」

オーナーシップ

バグのいくつかは、「関心の低い作業」から生まれていました。「関心が低い」とは、繰り返しのような単調な作業だけではありません。リーダークラスであれば発見できるバグを開発者が発見できないのも、開発者の関心がユーザに向いていない＝「関心が低い」ことになります。このような見逃しを減らすために、開発者の関心をどうやってユーザに向けるかを意識したそうです。

リーダークラスがバグを発見できるのは、技術や業務知識が豊富だからと思っていましたが、「関心がどこに向いているか？」も重要であるというのは発見でした。

実践編～理想の姿を目指して

ここからotf氏にバトンが渡され、3つのキーワードの具体的な取り組みの話になりました。

otf氏、3つのキーワードの具体的な取り組み

「リリース可能」～テストで共通認識を得る

以前は、開発工程の最後にテスト期間（テストスプリント）を設けて統合テストを実施していたそうです。この方法だと、開発の終盤にバグが大量に見つかり、いつリリースできるかわからない状態に陥ることがありました。
そこで、テスト期間を設けるのをやめ、ストーリーごとにテストをするようにしたそうです。ストーリーの完了は「リリース可能にすること」と定めました。

同時に、ユーザと共通認識を得る工夫も行いました。それが、

• テストは自然言語を用いたシナリオ形式で書く
• スプリントレビューでテストのレビューも行う

の2点です。
自然言語を使うことで、テスト自体がユーザとのプロトコル＝共通認識になります。こうして書いたテストもユーザの目につかなければ無意味ですが、ユーザとテストレビューの機会を設けることで共通認識を得られるようにしたそうです。

「学習」～テスト結果に気づきを含める

効率的に「学習」するために、探索的テストを取り入れました。
30分を1単位として

• テストの対象
• テストの目的
• テストの方針
• テスト結果と気づき

の4点を明確にしながら実施しました。
テスト結果に気づきを加えたことで、類似プロダクトと比べてよい点、悪い点に気づくことができたとのことです。

「オーナーシップ」～責任感を持ち、ユーザに関心を向ける

以前は、開発者とテスターとでロールがわかれており、テスターをセーフティーネットにしていました。それをメンバー全員がテストの責任を持つように徹底したとのことです。

そのうえで、

• スプリントイベントのファシリテーターを交代制にする、特にレビューイ
• スプリントゴールをドラマ仕立てにして共有する
• バグの特徴づけ、工程別ではなく特徴別

といったことも実施したそうです。

ファシリテーターを交代制にすることは自分のチームでも実践していますが、実質、議論を引っ張るのは常に同じ人物になりがちなので、どんな工夫しているのかが気になりました。

また、スプリントゴールをドラマ仕立てにするという施策はおもしろいと思います。「第20話 フレームワーク新バージョン登場！つくったアプリを簡単に配信できるように！」などの例が挙げられました。
こうすることで、ユーザのメリットがわかりやすくなり、ユーザがなにを求めているのか、今回達成するべきことはなにかが見通しよくなると感じました。

テスト期間ゼロを目指すために大切なもの

最後のまとめとしてkyon_mm氏から「今まではユーザの要求を低い理想にマッピングしていたが、今回は高い理想を目指した」との言葉がありました。ユーザに「できました」と言って完成しているベストな状態の中に「テスト期間ゼロ」という姿があったため、近づくためにさまざまな施策を実施したとのことでした。

「テスト期間ゼロ」を目指すうえで重要なことは、

• バグを埋め込まない
• プロセス中にバグをどれだけ減らせるか
• コミュニケーションコストを下げる
  （テストシナリオを提示して「要求はこれですか？」で伝わるのが最良）

の3つとのことです。

バグ以外にコミュニケーションコストにも触れていたのが意外でした。ただ、コミュニケーションエラーによるバグが一定数あることを考えると、この考えは納得できます。

増やそう、生かそう！テストからの学び

当初、テスト期間を設けずにどうやって品質を確保できるのか想像できなかったのですが、そのための考え方と実現するための施策を丁寧に説明されたので、イメージがつきやすかったです。
テスト期間を設けて最後にまとめてテストを行った場合、終盤にバグが見つかりリリースできなくなるという問題は、多くの人が感じていると思います。しかし、それ以上に、テストから得られる生きたフィードバックが減ってしまうことが問題ではないかと感じました。

kyon_mm氏やotf氏の現場では、ユーザとの要件決めや開発環境の学習などさまざまな用途にテストが使われていました。終盤でまとめてテストを行っていると、バグが出たという事実にだけ目が行きがちで、そこからなにかを学習するという考えにいたりません。開発と並行してテストを行っているほうが、得たものを生かしやすいと思います。

すぐ「テスト期間ゼロ」に向けて動きたくなりますが、いきなり「テスト期間ゼロ」は難しいため、まずはテストから得る学びを増やすことから始めたいと思います。

参考文献

• 「いつまでテスト期間つくっているの？-アジャイルなテストとの付き合い方-」（きょん@kyon_mm、2016年）
• 「いつまでテスト期間つくっているの？- 実践編 –」（@otf、2016年）

Agile Japanとは

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

レポートコーナー

• Agile Japan 2016 レポート
• Agile Japan 2015 レポート
• Agile Japan 2014 レポート
• Agile Japan 2013 レポート
• Agile Japan 2012 レポート
• Agile Japan 2011 レポート