アジャイルの成功を体験するには、テスト自動化が最適解である
これはウイングアーク Agile and DevOps Stories のAdvent Calendar 2021、第9弾（2021年12月13日）の投稿です！
1. 私のミッションは、テスト自動化をチームにアジャイルに導入することです。
現在のチームに配属になって、テスト自動化を導入するべく、6カ月が経ちました。
実感したことは、とても動きやすいことです。
それはなぜだろう？と考えてみました。
答えは、テスト自動化を導入する時が一番動きやすく、それはアジャイルであることでした。
では、なぜテスト自動化の導入は、アジャイルに動きやすいのだろう？と考えてみました。
2. 私が考えるアジャイルの動きかたは、小さく素早くです。
アジャイルとひと言に言っても、皆さんで捉え方が異なります。
なので、まずは前提を揃えます。
私が考えるプロダクトを開発するときに、アジャイルになるために必要なことを次の2行でまとめます。
アジャイルは、プロダクト（自身が作った作品）を小さく、そして素早く、世の中にお披露目（リリース）することである。
その効果は、常に変化する世の中が求めていることを、素早くプロダクトに取り入れることができる。
3. 私が考えるアジャイルの動き方で、失敗の要因は３つあります。
成功を知るには、まずは失敗からということで、失敗の要因を考えます。
それは、次の3つ（A、B、C）になります。
- <失敗の要因A>
プロダクトを小さく、世の中にお披露目できていません。 - <失敗の要因B>
プロダクトを素早く、世の中にお披露目できていません。 - <失敗の要因C>
世の中が求めていることを素早く、プロダクトに取り入れることができていません。
私の考えるアジャイルの動きに当てはめると、次の図２の通りになります。
4. 失敗の要因の原因は、「恐怖」です。
では、失敗する要因を発生させる人間の心理は何でしょうか？
私は、「恐怖」であると考えています。
そして、それはとても大きいです。
5. 「恐怖」と失敗する要因の３つと繋げます。
具体的に、「恐怖」がなぜ失敗する要因と繋がるのか？を考えます。
次より、「3.で示した失敗の要因A、B、C」と「恐怖」を因果で繋げます。
- <恐怖の内容A>
世の中が求めていることが分からない、という「恐怖」があります
<因果関係A>
「恐怖」により、求めていそうなことを詰め込み、大きくして、求めていることと合う確率を上げます。
<失敗の原因A>
その結果、プロダクトを小さく、世の中にお披露目できません。 - <恐怖の内容B>
世の中にお披露目すると簡単には元に戻せない、という「恐怖」があります。
<因果関係B>
「恐怖」により、丁寧に時間をかけて完璧を求めます。
<失敗の原因B>
その結果、プロダクトを素早く、世の中にお披露目できません。 - <恐怖の内容C>
プロダクトに取り入れることに、自分が意思決定者になりたくない、という「恐怖」があります。
<因果関係C>
「恐怖」により、多くの人に意思決定者になってもらおうとする、時間がかかる仕組みを作ります。
<失敗の原因C>
その結果、素早く世の中が求めていることを、プロダクトに取り入れらません。
6. ここまでを整理して、次の表１に示します。
7. 私の考えるアジャイルの動き方をテスト自動化に置き換えてみます。
「恐怖」が大きいから、プロダクトでのアジャイルは失敗することが分かりました。
それでは、本題である『なぜテスト自動化でのアジャイルは成功するのか？』を考えます。
私の考えるアジャイルの動き方において、「プロダクト」を「テスト自動化」に置き換えてみます。
アジャイルは、テスト自動化（自身が作った作品）を小さく、そして素早く、チームにお披露目（リリース）することである。
その効果は、常に変化するチームが求めていることを、素早くテスト自動化に取り入れることができる。
8. アジャイルによりプロダクトが失敗する恐怖の原因３つは、テスト自動化はとても小さいです。
ここでは、プロダクトの「5.で示した恐怖の内容A、B、C」はテスト自動化では、小さいのか？を考えます。
アジャイルが失敗する原因は、恐怖が大きいことが分かっています。
それがテスト自動化では小さいと分かった場合には、『アジャイルでテスト自動化は成功できる』と証明できます。
その証明を、恐怖の原因に対して反証することで確立します。
- <恐怖の内容A>
世の中が求めていることが分からない、という「恐怖」があります。
<反証A>
この「恐怖」に対して反証します。
テスト自動化を使うのは、自分自身を含めたチームです。
なので、自分自身が求めていることが、分からないことは無いです。
<失敗の原因A>
つまり、求めていることが分からない「恐怖」は小さいです。 - <恐怖の原因B>
世の中にお披露目すると簡単には元に戻せない、という「恐怖」があります。
<反証B>
この「恐怖」に対して反証します。
テスト自動化を使うのは、チームです。
なので、戻すために必要な影響範囲の調査は、プロダクトを比較すると狭いです。
<失敗の原因B>
つまり、戻すことの「恐怖」は小さいです。 - <恐怖の原因C>
プロダクトに取り入れることに、自分が意思決定者になりたくない、という「恐怖」があります。
<反証C>
この「恐怖」に対して反証します。
テスト自動化の意思決定者は、自分自身とテスト自動化の使用者です。 なので、意思決定者の数は、プロダクトと比較すると少ないです。
意思決定者の数が少ないということは、関係者が少なく、影響範囲が狭いということです。（図４で可視化します）
<失敗の原因C>
つまり、意思決定をする「恐怖」は小さいです。
9. ここまでを整理して、次の表２に示します。
10. 恐怖が小さいことでテスト自動化がアジャイルに動きやすいことが分かりました。
テスト自動化は恐怖が小さいことが分かりました。
では、恐怖が少ない中どのように実際に動いたのか？を私の経験を書きます。
と思ったのですが、長くなるのでまたの機会にします。
少しだけ頭出しをすると…
- <テスト自動化の実践A>
テスト自動化は、自分自身がフィードバックするユーザです。
どのような内容をテスト結果に出力すると自分自身が喜ばれるのか？は常に考えましょう。 - <テスト自動化の実践B>
運用後にテスト自動化が、話題に上がらなくなってきたら危険です。
それは、安定稼働しているのではなくて、チームが興味を無くしています。
使っていたら、少なからず不満は出てきます。
興味がある方は、ぜひclapをお願いします！
