- AIプロダクト開発|PdM候補
- 完全在宅|カスタマーサクセス
- 未経験歓迎|フルリモート
- Other occupations (57)
- Development
-
Business
- AIプロダクト開発|PdM候補
- エンジニア|テックリード候補
- エンジニア|リードテック候補
- 開発エンジニア|PdM候補
- SD|セールスディレクター
- 在宅勤務|セールスディレクター
- 経理経験者歓迎|コーポレート職
- バックオフィス全般|フルリモ
- コーポレート職|フルリモート
- 総務|フルリモート
- 経理/労務|フルリモート
- フルリモート|人事採用職
- CSO直下の経営企画メンバー
- フルリモート|ビジネス職
- フルリモート|事業企画・開発
- フルリモート|営業責任者候補
- フルリモート|営業経験者歓迎
- 居住地不問|セールス・事業開発
- 業務委託|テレアポセールス
- 在宅OK|フィールドセールス職
- フルリモート|セールス職
- 長期インターン|セールス職
- 26/27卒インサイドセールス
- フルリモート|コンサルタント
- 在宅勤務|インサイドセールス
- フルリモート|セールス
- インサイドセールス
- 営業総合職
- セールスプランナー
- フルリモート|広報
-
Other
- 完全在宅|カスタマーサクセス
- 未経験歓迎|オープンポジション
- オープンポジション
- フルリモート/フルフレックス
- フルリモ|カスタマーサクセス
- 完全在宅|オープンポジション
- セールスコンサルタント候補
- フルリモ|オープンポジション
- 経験不問|オープンポジション
- 経験不問|カスタマーサクセス
- 26卒|文理不問|勤務地不問
- 在宅勤務|カスタマーサクセス
- セールス戦略コンサルタント
- 内定直結|オープンポジション
- 業務委託|セールスポジション
- 長期インターン|内定直結
- 26卒|文理不問|フルリモート
- 26卒|オープンポジション
- 新卒|オープンポジション
- カスタマーサクセス|内定直結
- 26/27卒|フルリモートOK
- フルリモートOK|内定直結
カイタクの開発スタイルのひとつであるTDD(Test Driven Development=テスト駆動開発)。
実は、日本では採用している企業はまだ少数派です。今回は、TDDって何がいいの?というテーマを、エンジニア目線で解説します。
TDDってなんだ
ソフトウェアを作るには、ソースコードを書いてそれが動くことを検証しなければなりません。まずコードを書いて、そのあとにそれが動くことを検証する、というのが自然な流れです。TDDを採用しない世界では、この動作検証をひとつひとつ手動で行う必要があります。
TDDはこの流れを逆転します。RED→GREEN→REFACTORINGと言われる流れです。
RED
まず最初にテストコードを書いてプログラムが動かないことを確認します(RED)。この時点でテスト(動作確認)が自動化されていることに注目してください。
GREEN
そのあとに初めてテストが通るようにコードを書きます。ここでテストが通れば機能が実装されて動くことことが確認できます(GREEN)。前段階で動作確認が自動化されているので、何度でもコマンドひとつで自分の書いているコードを実行できる、ということが重要です。細かくコードを実行してデバッグすることは効率的に開発を進めるうえで非常に有益です。自動テストを使ってコードを実行してみたら思っていた結果が得られない、ということは日常茶飯事です。そんなときは、ログを仕込んだり書き方を変えたりして原因個所を絞りこんでいきますよね。ここでも一発で原因が特定できるとは限りません。あれでもないこれでもない、と考えられる原因をしらみつぶしに試していくことも多いです。何度でもコマンド一発でこの検証を実行できるというのは、試行錯誤のサイクルを早めることに大いに寄与します。
さらに、コード品質を高く保つためには、テストが通るようになった後に、よりよいコードに書き換えるリファクタリング作業を行うことが必要です(Refactoring)。ここでも動作検証が自動化されていることが効いてきます。せっかく機能しているコードに手を入れることは怖いですよね。ちょっとした変更が思いもかけないところに影響を与えて今まで動いていた機能を壊してしまうかもしれません。でもすべての機能について自動テストがあればまたコマンド一発で壊れていないことが確認できます。
TDDとアジャイル開発
カイタクではアジャイル型の開発を徹底しています。アジャイルでは、短い期間で細かく顧客に機能をリリースします。ここで、前回のリリースまでに作っていた機能が新機能の追加に伴って動かなくなっていたらどうでしょう? 地獄ですね。でも、頻繁にリリースするアジャイル開発では既存の機能をリリースのたびにすべて検証することは現実的ではありません。
そこで、自動テストの作成が必須になるわけです。機能のリリースがされる時点では自動テストが備わっていないと、それ以降のリリースでその機能が壊れても検知することができなくなってしまうからです。
どうぜ自動テストを書かないといけないなら、実装に先立ってテストを書いておけば上記のような開発効率面でのメリットを享受することができます。
TDDと設計
テストを実装に先立って書くということは、実装する前にその設計が頭にないといけません。
必然的に設計について実装前によく考えることになります。その結果、設計ミスによる手戻りが少なくなるというメリットもあります。
でもテスト書くのって面倒くさくない?
一見するとTDDでは、非TDDと比べて「テストを書く」という作業が増えているために開発効率が落ちるように思われるかもしれません。
しかし長い目で見れば確実に開発効率が向上すると考えています。一説によると、非TDDとテスト自動化との損益分岐点は、「動作確認4回」だといわれています。非TDDで進めた場合、ひとつの機能を作るだけでも4回以下の動作確認で作り切れる人はまれでしょう。ましてや開発プロジェクトは数か月から数年続くものも少なくありません。通算4回以上の動作確認を行うことはほぼ確実です。
もちろん、テストフレームワークやテストすべき項目などについて学習コストはかかります。しかし、慣れてしまえば、テストコードは似たパターンの使いまわしであることが多いので、初学者が思っているほどテストコードの作成にかかる工数は多くありません。
カイタクではすべての開発プロジェクトでTDDを徹底しているので、ノウハウの移転もスムーズに行われる環境が整っています。
TDDやってみようぜ
テスト駆動開発はその名の示す通り品質管理手法ではなく開発手法です。とにかくTDDの最大のメリットは、開発効率の改善につきます。品質の向上は副次的なメリットに過ぎないと考えています。
また、やってみると想像しているよりも楽しいです。ひとつひとつテスト結果がGREENになっていくのはゲームをクリアしていくような快感があります。着実に開発が前進している実感も得られます。安心してリファクタリングできるので、自分の創造性を試すことも後押ししてくれます。
みなさんのプロジェクトでもぜひトライしてみてください。