開発はアジャイルだけどテストがウォーターフォール問題のまとまらないまとめ

少し前に開発はアジャイルだけどテストがウォーターフォール問題という記事を書いたのですが、このテーマを話したイベントが終わったので、話題になったところを、ふりかえりもかねてまとめてみようと思います。思い出しながらの回答なので、当日と違ったことを書くかもしれませんがご了承ください。イベントの資料はこちらで公開されています。

言葉の定義

セッションは350名を超える方に参加いただき、Discordのメッセージもたくさんいただいたので、興味があるテーマなのかもしれません。

まとめる前に、言葉を定義しておこうと思います。スライドではざっくり3つにまとめたのですが、活動なのが手段なのか人なのかをわかりやすくするために、ざっくり2つに絞りたいと思います。

従来型QA（ウォーターフォール型QA）：従来型開発のQAフェーズでやっているQA活動（主にテスト活動）
アジャイルQA：アジャイル型開発で行っているQA活動

「QA（品質保証）」は、よく使われる便利な言葉なので、ここでも使わせてもらってます。ただ、QAがマッチしないのであれば、自分たちにとってわかりやすい言葉（例えば「テストや品質」とか）に置き換えてもいいんじゃないかと思います。

このブログで両方の言葉を「活動」にしたほうが、「QA = テストをすることやテストをする人」を切り離して考えられるのではないかと思ったからです。この記事ではできるだけ、何をやるか？誰がやるか？を無視して書いてみようと思います。

あと、向き不向きはあるでしょうが、2つは対立構造ではないです。

テストがウォーターフォール問題：ドキュメント

アジャイル開発においてドキュメントをどこまで書くのか？たしか、館石さんからの質問だったと思います。

ドキュメントでもテストでも設計でもなんでも、ソフトウェア開発に必要な活動やアウトプットは、アジャイル開発でも行います。

「アジャイル開発はスピード重視だからテストをあまりしない」とか「アジャイル開発はドキュメントを書かない」とかたまに聞いたりしますが、やるべきことはやります。このネタはアジャイル開発に限らないと思いますが、やらないと損することが多いならやりますよね。

ただし、どれぐらいやるかが違うと思います。

たとえば、Discordにも書かれていましたが、契約的に必要であれば、必要なレベルのドキュメントを書いているはずです。おそらく詳細まで書かれている場合が多いかもしれませんが、

アジャイル開発だとそこまで書く必要がない場合が多いので（契約や納品がなかったり）、自分たちに必要最低限のドキュメントを書きます。必要であれば体型だって書いている場合もありますし、チケットに書ける範囲で書いているところもあります。

ひとつ、大きなポイントとしては、「ドキュメントを書くをどこまで仕事にするか」だと思います。これは「どれくらいやるか」に紐づく部分で、ドキュメントにコストをかけると、単なるタスクを超えて、スプリントを圧迫する仕事になります。

チームにとって、そこまで必要ないなら、そこまでコストを割かなくてもいい方法を考えてもいいんじゃないかと思います。

もし、必要であれば、コストをかけてやるべきでしょう。たとえば、大人数がかかわる複雑なシステムであれば、ドキュメントがコミュニケーションを支えるツールになります。コストを割いただけのメリットもあるかもしれません。

Discordにも書かれていましたが、仕様は誰が書いてもいいと思います。それぞれの役割や視点で作成したり、更新していければいいはずです。

テストがウォーターフォール問題：テスト設計〜テスト実行

アジャイル開発でもテスト計画をしたり、テスト設計をしたり、テスト実行をしたりする場合もあります。ただ、「スプリントの最後3日を従来型QAフェーズ」などにすると、変化につよいプロセスなのに、変化に弱くなってしまいます。また、従来型と同じく、後半で問題が起きたときに、リスクが大きくなってしまいます。

僕の場合、アジャイル開発の恩恵を受けたいけど、その恩恵をうけられていない状態を「なんちゃってアジャイル」と呼んでいます。これは揶揄するというより、「使い方間違ってますよね」という指摘です。

「スプリントの最後3日を従来型QAフェーズ」とかは典型的ななんちゃってアジャイルです。「ちっちゃなウォーターフォール」であっても、アジャイル開発の価値の一つである「スプリントごとに価値提供」できているのであれば、良いんじゃないかと思います。

完璧なアジャイル開発なんて存在しません。よって、現場に合わせて、やっていくうちに自分たちでカスタマイズしていく部分が出てきます。それを全部「なんちゃって」と呼んでいたら、「じゃー、なんちゃってじゃないアジャイル持ってきてよ」と一休さんみたいな問答になってしまいます。これは不毛。

アジャイル開発の導入のはじめに、本に書かれている通り完璧にやってみるのはとてもいいことです。なぜなら、何ができていないか、窮屈な部分はどこかなど、発見をたくさん経験できます。そこからどう改善していくかは現場次第です。

そのときに、アジャイル開発が提供してくれる価値を得られるのか？は重要なチェックポイントだと思います。

テストがウォーターフォール問題：小さな未完成品のテスト

アジャイル開発は、小さく積み上げていく開発なので、完全なプロダクトは遠い先の未来にしかありません（もしくプロダクトビジョンを更新していくならたどり着かないかもしれない）。よって、スプリントごとにリリースされるものは、小さな未完成品です。

ここで言いたかったのは、従来型だと仕様なりが完成しており、完成したものをベースに開発やテストしますが、アジャイル型だと、完成しているかも大切ですが、作ったものでフィードバックを得られるかが重要です。いわゆる「正しいものを作れているか」が重要です。

小さな未完成品が間違っていれば捨てますし、間違いがなければさらに正しいものを探します。

テストがウォーターフォール問題：「テストをする」をなくしたら何をしますか？

僕は従来型QAの専門家ではないのですが、アジャイルコーチとしていろんな相談を受けていると、「QA ＝テストすること」や「QA ＝テストする人」になっていることが多いです。

従来型QAの経験がベースになっている現場が多いので、アジャイルQAを考えるきっかけづくりとして、以下のような質問をしています。

テストを担当するQAエンジニアがいないアジャイルチームで、どうやってプロダクトの品質を守りますか？
セッションのスライドを要約

Discordでもいろいろ意見をいただきました。

重要シナリオのみテストする
チームの活動を2週間観察して何ができるか考える
ドッグフーディングする
チームみんなでQAする
リリースゴールを話す
POにQAどうしますって問題提起する
機能減らす
テストで何をして、テスト以外で何をするか考える
品質をあげる仕組みを作り込む
自分で作って自分でテストする
開発ですべてでテストする

「テストをする」に頼っている現場であれば、その当たり前を除外して「テストせずにプロダクトの品質を守りますか？」と聞いてもいいかもしれません。

先にも書きましたが、開発もテストもどちらも大切なので、どっちもやるべきでしょう。しかし、誰がやるかは現場によっていろいろあるとおもいます。

たとえば、QAエンジニアであれば、「QAエンジニアはこうなるべきだ」みたな論理はあんまり重要ではなく、QAエンジニア自身が「QAエンジニアとしてどうなりたいか」を考えるのが正しいステップではないかと思っています。その結果、「テストをする役割」をもつ場合もありますが、アジャイルQAでは、そうじゃない場合も増えてきているように思います。

昔、僕はQA組織のエンジニアリングマネージャをしていたので、メンバーの将来のために「QAとは何か」をいろいろ考えていました。しかし、今はしがないスーパーアジャイルコーチでしかないので、自分の仕事でないものを他人にとやかく言うのではなく、「どうしたいの？」と質問しています。