SEとテスト駆動開発と技術よがり
テスト駆動開発は継続的インテグレーション（CI：Continuous Integration）の中心となります。
技術が好きなエンジニアはテスト駆動開発に理想を感じ導入を進めます。
一方で
- なぜかテスト駆動開発が進まない
- どうせSEはテストファーストできる技術ないんでしょ？
と思っている方はいませんか？
導入がなかなか進まないのが実情じゃないでしょうか。
それもそのはず。
SEが活躍する現場ではテスト駆動開発と相性がとても悪いからです。
この記事ではSEとテスト駆動開発に関する導入への苦悩を紹介していきます。
テスト駆動開発へのアンチパターンを知ることで今後のプロジェクト推進の参考になることが多いでしょう。
ぜひ最後までお読みください。
目次で流し読み
テスト駆動開発とは？メリットはなに？
テスト駆動開発は先に実装すべき機能のテストコードを書き、そのテストを満たしていくようにプログミラングを進めるという開発スタイルです。
テスト駆動開発 (てすとくどうかいはつ、test-driven development; TDD) とは、プログラム開発手法の一種で、プログラムに必要な各機能について、最初にテストを書き（これをテストファーストと言う）、そのテストが動作する必要最低限な実装をとりあえず行った後、コードを洗練させる、という短い工程を繰り返すスタイルである。
なぜこのような進め方をするのでしょうか。
テスト駆動開発のメリットは次があげられます。
- ゴール（テスト合格）に向かって開発が進められるため効率的である
- テスト可能なプログラムであることを保証する（メンテナンス性、堅牢性の向上）
- テストに合格されたコードであることを保証している
- テスト工程での成果物は、テストコードや合格のレポートを納品すれば良いため工数が削減される
- 積極的なリファクタリングを行いやすい
- 継続的インテグレーションが可能となる
このようにテスト駆動開発を行うことでたくさんのメリットを得ることができます。
では、システム構築を請け負うSIの現場でこのテスト駆動開発を導入するとどうなるのでしょうか？一緒に考えていきましょう。
テスト駆動開発をSIに導入した場合の効果
システム構築を請け負う場合、構築したシステムが拡張や改善を行うことは大規模プロジェクト以外あまりないでしょう。
すなわち、積極的なリファクタリングや継続的インテグレーションの必要性がないわけです。
また、数年後に発生する改修ではすでにプロジェクトメンバは解散しているばかりか別会社な可能性もあるわけです。
そのときの担当者がスキル不足である場合、テスト駆動開発を進める気もなければ環境構築もできないでしょう。
逆に技術スキルが高い場合は、網羅されたか否かわからないテストケースを実行して「すべてグリーンでした」となっても信じきれないでしょう。
そして何よりテストコードの流用性のことを考えると、テストコードを手間暇かけて書くよりExcelでテスト仕様書を作り、ひとつひとつテストをしたほうが早いというケースが大半なのではないでしょうか。
それらの将来的なことに目をつむって開発を進めても、開発工程における技術力の低さが課題となります。
通常、システム構築では下流工程ほど多くの人が必要になります。
上流工程はSIer社員で進め、開発工程以降は派遣や協力会社と進めますが正直、テスト駆動開発を進めるほどの技術力がないことが多いです。
職業訓練でJavaを勉強したレベルの人がいたり、すべてが受け身な人がいたり、おじちゃんがいたり。。
テスト仕様書も満足に設計できないそんな人に「テスト可能なプログラム」の重要性説いても響かないでしょう。
よくSEの技術力をバカにする人がいますが、私が見てきた現場では優秀なプログラマーは少ない印象です。
マッチングが失敗していますね。
まとめると、次のケースはテスト駆動開発が合わないと考えられるでしょう。
- システム納品後に拡張・改善がないプロジェクト
- テスト駆動開発の良さを享受できない文化
それでもSIerがテスト駆動開発を導入したらどうなるか？
そんな中、私が知っているSIでテスト駆動開発した事例を紹介いたします。
比較的おおきな案件（億単位）で、リリース後も保守・メンテ費用があったためテスト駆動開発を導入した事例がありました。
結果どうなったかというと、テストコードにはテスト仕様書の内容を網羅しきれず、「テストはOKでも不具合は多発」といった結果となりました。
言うは易しですが、あらためてテスト仕様書の大切さとそれをテストコードに反映させるための大変さがうかがい知れました。
SEがテスト駆動開発にチャレンジする意義
これまでテスト駆動開発に対しSIの現場からみると悲観的な考え方を主張してきましたが、「じゃぁ知らなくていいや」という問題ではありません。
あなたの年齢がまだ若いなら今後さまざまな開発案件に出会い、それに合った開発方法を適用する必要があります。
したがってテスト駆動開発を知っておくことで柔軟に対処することができるでしょう。
私は少人数プロジェクトのときにテスト駆動開発を導入することをおすすめします。
次を意識して進めることであなたの知見を広げてくれるでしょう。
- やらないよりも、やってみる
- テスト仕様書のテストケースを網羅する
あなたならどのテスト工程までテスト駆動にしますか？
まとめ
テスト駆動開発は、次のようなたくさんのメリットがあります。
- ゴール（テスト合格）に向かって開発が進められるため効率的である
- テスト可能なプログラムであることを保証する（メンテナンス性、堅牢性の向上）
- テストに合格されたコードであることを保証している
- テスト工程での成果物は、テストコードや合格のレポートを納品すれば良いため工数が削減される
- 積極的なリファクタリングを行いやすい
- 継続的インテグレーションが可能となる
一方でSIの現場では
- システム納品後に拡張
- 改善がないプロジェクト
- テスト駆動開発の良さを享受できない文化
ということが多く、導入しずらいことが現実でしょう。
クックパッドをはじめ、様々な開発論がチャレンジされています。
しかしSEは流行に流されずに本質を見抜き、SIの現場ならではの開発論を極めれば良いと思います。
少しでも参考になれば幸いです。
