自動テストが威力を発揮するビジネス環境

はじめに

今日は、自動テストが威力を発揮する、ビジネス環境について考察したいと思います。

今までの筆者の経験から、筆者が重要だと思う「自動テストが威力を発揮するビジネス環境因子」を3つあげます。

1. コードベースに触るチームメンバーの人数が多い
2. メンバーの入れ替わりが激しい
3. コード変更を短期的に繰り返す

逆に言うと上記の3つに当てはまらない環境の場合、自動テストの導入の効果は薄いです。

つまり

1. コードベースに触るチームメンバーの人数が少ない
2. メンバーがほとんど入れ替われない
3. 一度リリースしたら、コード変更はバグがあったときのみ (一回発注・納品型スタイル)

の場合、自動テスト導入しても、効果は薄いと思われます。

以下、重要だと思う因子3つの根拠を記します。

3つの因子の根拠

1. コードベースに触るチームメンバーの人数が多い
当たり前ですが、関わるメンバーが多ければ多いほど。誰がどこを直したかをメンバー間で共有することは難しくなり、コードの変更管理コストも上昇していきます。Aという変更と別メンバーのBという変更が合わさったことによって、システムに矛盾した振る舞いを引き起こさせる可能性もあります。
そういった状況でも、自動テストがあれば、少なくとも現状のロジックが破壊された場合には検知してくれるので、メンバーが多くても安心して開発を進めることができます。

もちろん、対象のコードが自動テストでカバーされている + 正しいビジネスロジックのテストで網羅されているということが前提条件になります。

2. メンバーの入れ替わりが激しい

メンバーの入れ替わりが激しい場合、各メンバーが保有している知識が断片的で、システム全体の知識を持っている人が少ない、あるいは全くいないということが考えられます。またメンバーの入れ替わり画激しいため、知識は容易に失われてしまう可能性も高いです。

自動テストがあれば、自分の変更が、思いがけないところでロジックを破壊していても検知できますので、安心です。

ただし、その入れ替わっていくメンバーには、そのメンバーの責任でテストを追加してもらうことが必須になります。あまり移動しないコアメンバーがいるのであれば、そのコアメンバーがテストコードを書くほうが望ましいです。コアメンバーの方がシステム全体を把握して効率的かつ効果的なテストコードを書くことができるからです。コアメンバーがテストコードを書く負担が増えると考える方もいるかもしれませんが、入れ替わっていくメンバーに対して毎回システムの説明、コードレビューをするよりは、初回多少コストがかかっても自動テストを作成して、入れ替わっていくメンバーのコード変更のリスクを縛ってしまう方が圧倒的に効率がよいです。コードレビューはどうしても人間が行うため、精度にむらが出がちです。しかしコンピュータは、反復単純作業をミスなくこなすことに特化していますので、そういった意味でもコードの最低限の担保は自動テストに任せる方が適切です。

3. コード変更を短期的に繰り返す

あるシステムで作成した自動テストが、他のシステムで流用できることはまずありません。ですので、毎回異なるものを開発・納品を繰り返すような一回納品型のビジネスモデルですと、自動テストを追加するだけコストがかさむだけになってしまい、自動テストを導入するメリットは下がってしまいます。

というわけで自動テストは、同じコードベースに対して追加的にすばやく変更を加えていく場合に、特に有効になります。

おわりに

自動テストが威力を発揮するビジネス環境について、筆者が重要だと思う因子を3つあげました。

1. コードベースに触るチームメンバーの人数が多い
2. メンバーの入れ替わりが激しい
3. コード変更を短期的に繰り返す

上記の条件に当てはまる環境でソフトウェア開発を進めている方は、自動テストの導入を検討して頂いてみてはいかがでしょうか。