はじめに
本記事は、アプレッソAdventCalendar 2016 の 12日目の記事です。
品質マネジメント部(QA)の伊藤です。
アプレッソでは、スクラム・アジャイルを取り入れた開発にチャレンジしています。
本記事では、スクラムに参加する上で行った取り組みや感じたことや工夫していることをQAならではの視点でまとめたいと思います。
開発部のメンバーも執筆していますので、よろしければ合わせてご一読ください。
〇 AdventCalendar 2016 2日目
「「1週間ずつ製品を作る」のが最強である説 ～スプリントを「1週間」でガチでやってみた結果」
〇 AdventCalendar 2016 3日目
「わたしたちがスクラムのスプリント期間を 1 週間にし、タスクを 1 時間以下の単位に分割するのはなぜか」
開発スタイル
まず始めに、スクラムを取り入れる前の開発スタイルを軽くご紹介したいと思います。
開発とQAが分断しており、開発フェーズが完了したらテストフェーズに入るという、いわゆるウォーターフォールに近い開発スタイルでした。
「ウォーターフォールに近い」と表現したのは、基本設計から機能設計、単体テストから結合テストなどできっちり分かれているようなガチガチなウォーターフォールというわけではなかったからです。
とはいえ、フェーズが分かれてしまっていることには変わりはありません。
当然ながら、早いフェーズでQAが参画した方が効果が大きいので、
- 仕様/タスクの共有
- 新機能の画面レイアウト仕様などの共有単体テストのレビュー
- 先行検証
- 開発段階からQAが参画して検証を行い開発者へのフィードバックを行う
などなど、いろいろチャレンジを行ってきました。
どちらも先行して着手できるので、一定の効果を挙げることにつながり、あらためて先行して着手することの効果の大きさを実感できました。
スクラムによる開発
とはいうものの、さらによりよくしていく必要があると感じていました。
そんな中、現在チャレンジしているのがスクラムです。
スクラムでは、開発やQAが一緒になり開発チームの一員という立ち位置で一緒に開発をしていきます。当然、品質も確保しつつ開発していくので、早い段階から品質を作り込んでいけるわけです。
ここからはそんなスクラムに参画する上での戸惑った点や関わり方、工夫したことなどについて紹介したいと思います。
ちなみに、現段階はチャレンジ中なのでスクラムによる開発が完了した、あとあらためて従来のQAフェーズを用意しており万全の体制を整えています。
やる前
スクラムが始まる前は、QAに何ができるのかという不安しかありませんでした。
今まで、一つの機能や製品として提供されてきたものが、(一つの機能としては)未完成でリリースされてくる謎の状態のものをどのようにテストするんだという不安です。
そもそもテスト設計から詳細化までのプロセスはとても重要で、しっかり時間をかけ複数人でレビューしながら入念に取り組んできただけに、１週間で開発からテストまで行うなんて考えられないことでした。
実際にやってみて
では、実際に作業を始めてみて、どうだったのか。
今までのプロセスと異なる点はいくつもありましたが、その中から 2 つ挙げさせていただきます。
- 既存のテストセットを実施していく従来のプロセスを適用できない点
- コミュニケーションのとり方
1 つ目の従来のプロセスを適用できない点については、大きな悩みポイントでした。
「○○確認」「～～テスト」「△△テスト」などと様々なテストセットが用意しており、それぞれのテストで主眼となる観点が異なるため、機能を包括的・網羅的に確認することができます。
それが適用できないというのは、今まで培ってきたナレッジの一部を活用できないことになります。
適用できない理由としては、作成にかかるコストが大きく、機能の一部がリリースされてくるということもあり、既存のテストセットのコンセプトとはマッチしなかったということがあります。
二つ目のコミュニケーションのとり方については、スクラムというフレームワークにのっとると、必然的に密な会話が要求されます。
アジャイルソフトウェア開発宣言でも「プロセスやツールよりも個人と対話を」とある通り、対話が非常に重要です。
従来のやり方では、対話の他にバグトラッキングシステム(以下、BTS)を活用して課題のやりとりを行ってきました。
しかし、1週間という短いスプリントの中では BTS を活用するとスピード感を損ないます。
BTS に課題を登録するより前に、会話をして対応してしまった方が圧倒的に早いのは自明の理です。
まさに「プロセスやツールよりも個人との対話を」です。
（余談ですが、BTS が必要ないとは思っていませんし、実際スクラムをやっていく上でストーリーやアイテムの登録は BTS を活用しています。開発チームが開発をする場合に限った話と捉えてください。）
工夫した点
テスト設計
1週間という単位ではわずかなロスも減らしていくことが重要であり、テストも短い期間で最大の効果を得られるようにしなくてはいけません。
従来通りのやり方にのっとると、テスト設計を行い網羅的に確認するマトリクス表を作成して実施することになるので、時間的コストが大きいと考えました。
そこで、簡易的なやり方にやり方をシフトして、実施してみました。
- テスト設計はキーワードベース、テスト項目は作成しない
- テスト設計をマインドマップで行いテスト項目を作成していく
一つ目のキーワードベースというのは、以下のような感じ。
- ○○画面
- △△テキストエリア
- 入力値
- 記号/数値/文字列
- 入力値
- △△テキストエリア
これぐらい簡易なら短い時間で作成でき、すぐに実施に取り掛かれます。
自由度が高いので、熟練のQAであれば勘を働かせて効果的なテストを行えますが、反面テスト粒度が完全に実施者依存になってしまいます。
二つ目は、それを改良してテスト項目を作成するようにして、実施者依存させないようにしました。その際、テスト設計にはマインドマップを活用しています。
今までテスト設計にマインドマップを活用したことはなかったですが、作成に要する時間的コストも少なくすみ、かつ全体像が見えやすいためまずまずの方法かと思っています。
コミュニケーション
対話を素早く密にするには、物理的な距離も大きな要素になります。従来は、開発とQAはフロアは一緒であるものの、完全に部毎に分かれていました。
しかし、スクラムを実践していく中で物理的な距離は１メートルでも近い方がわかりました。
実際には、2回に分けて席替えをしました。1回目に正面になるように配置し、2回目には完全に同じ島で作業をできるようにしました。
開発・QAが隣り合って作業をするということがなかったので恐る恐る（？）徐々に近づいていきましたが、そのたびにやりやすさが増していきました。
よって結論としては、物理的な距離は１mでも近い方がいいということです。
スクラムチーム以外の波及
アジャイルやスクラム関連を調べると様々なプラクティスがあることがわかります。
スクラムチーム外のQA内で行うような作業にも、スクラムで活用されているような以下のようなプラクティスを実践しています。
- かんばん
- ファシリテータの入れ替え
- チーム毎の朝会 (QA全体の朝会は元々あり、それをチームごとでも実践)
- ニコニコカレンダー
スクラムを行わないまでも、様々なプラクティスを試すことが今までのやり方を改善することにつながることがわかりました。
最後に
スクラムチームとしてQAが参画した雰囲気がなんとなく伝わったでしょうか。
苦労した点も多いですが、スクラム自体の知識やスクラム以外にも適用できるヒントみたいなものを得られたような気がします。
スクラムチームによるチャレンジは現在進行形なので、まだまだ課題も多くあります。
これからも課題の解決と現状のプロセスの改善のため、様々な方法を模索し実践していこうと思います。