はじめに
- 失敗→工夫みたいなのは繰り返してるけど、まだ答えは見つけてない。
- 過去の試行錯誤の結果（主にうまく行かなかったアプローチと結果）を書いてるだけです。
過去のチャレンジ
理解度が浅い状態で「TDDを導入しよう」と宣言
背景
- 新規プロジェクト。すごく小さなプロジェクト。
- 2〜3年目。初めてプロジェクトデザインを任された。
- 実装を担当したプロジェクトとほぼ同じプロジェクトをプロジェクトリーダーポジションでやらせてもらった。
やったこと
- PJのプロセスデザインのタイミングで「TDDやりませんか！やりましょう！」とプッシュしまくった。
結果
- ハマらなかった。
- TDDの理解度が浅く「テストを書く→実コードを書く」くらいのスタンスで押してしまっていた。
- いまいちメリット感がみんなに伝えわらずに途中でやらなくなってしまった。
今振り返ってみれば
- 全員が言語仕様の理解度が浅く、テスト自体が正しくかけているのかが不安があった。
- 当時は、そのせいでUnitTestレベルの検証の妥当性に自信を持てず、実際に動かして検証することを重視してしまった。
- 今思えば、t-wadaさんの動画を見れば「言語仕様の理解度向上」にこそ、TDDは効果があるはず。悔やまれる。
TDDを勉強してt-wadaさん動画を通じて伝達
背景
- 既存プロジェクト。そこそこ大きなプロジェクトの保守開発。
- 5〜6年目。テストのやりづらさを感じていて、そこの解決策としてTDDを推進した。
- スクラムマスターのポジショニングで実コードを書くのはDEVメンバー。
やったこと
- 詳細： Qiita - TDDを現場へ導入した時のなるべく具体的な話
- ざっくり
- TDDの勉強会を実施。（t-wadaさんの動画ベース）
- 実際の適用の仕方を目の前の修正を元に一緒にやってみる。
結果
- ハマらなかった。
- 現場のテストフレームワークとの相性が悪かったし、既存のプロセスとも相性が悪かった。
- 現場が独自のテストフレームワークを用いており、テスト実行が時間がかかりやすかった。（DBへのロード/アンロードなどが含まれる）
- 既存の開発プロセスの枠組みの中でTDDをどのようにはめ込むかのイメージまで整理しきれなかった。
- 個人としての活用では部分的に残ったものの、テスト実行が遅すぎるため、本当に部分的に止まった。
学び
- TDDの普及のためにはテスト実行時間の短さはすごく大事。
- TDDしやすい開発プロセスってのはあるというか、テストの立ち位置みたいなものを少し組み立て直した方が良い。
今のチャレンジ
テストの立ち位置みたいなのを少し組み立て直している。（ここはまだうまく言語化できてなくて、検討中としか言えん。。。）
次回予告
本記事は、2022アドベントカレンダー「受託アジャイル」です！
次回は、「アジャイル導入における「自社の都合に合わせて形を変えるな」というのは言葉足らずだと思っているので私見を述べる」をします。