エンジニアとATDDを導入した背景と導入メリット
チームメンバーみんなで価値があるプロダクトを作っていきたいyoshiです。Offers PM Advent Calendar、10日目の投稿です。
Offers PM Advent Calendar 9日目は Offers マーケティング / PMMの岡田の「KARTEを活用してLPのCVRを250%改善した話」でした。
今回は、Offers to C ProductチームでトライアルしていたATDDについて書いていきたいと思います
誰向けの記事か
プロジェクトマネジメントを担当している方
エンジニア、デザイナー、PMの連携を促進したい方
ATDDとは
受け入れテスト駆動開発（Acceptance Test Driven Development 以下ATDD）の略で、「受け入れテスト」を予め作成し、それをベースにが実装していくTDD（テスト駆動開発）になります。
なぜ ATDD をやることになったのか？ープロジェクト課題
直近、開発する施策の規模・複雑性が増している中で、以下のようなプロジェクト課題が発生してました。
PdMのみで作成したユーザーストーリーでは、その他の機能との整合性や影響を網羅することが難しく、仕様の考慮漏れが発生するケースがありました。
ステークホルダー(主にPdM・エンジニア・デザイナー)での認識の齟齬が発生し、その齟齬に気づくのが実装中などで、コミュケーションコストや出戻りコストが発生し、スケジュールの遅延の理由になっていました
エンジニアのみで作成したテストケースでは、ビジネス要件を網羅できていないことがありました。
ATDDの実施プロセス
要求定義からのプロセス
PdMが実現したいユーザーストーリー記述されたSpecを作成します
PdMが実施予定の施策で、実現したい提供価値をチームメンバーに共有後、PdM・エンジニア・デザイナーでユーザーストーリーを満たす受け入れテストを作成します
実装以降のプロセス
エンジニア、受け入れテストをもとにTechSpecおよび実装を開始する(TDDサイクル)
受け入れテストをもとにSyntheticテストを作成する
実装完了後、改めて受け入れテストが満たされていることをPdMが確認し、リリースする
ATDDの魅力/導入してみてよかったこと
考慮されてない仕様変更を防ぐ
受け入れテストを作成する段階で、PdM・エンジニア・デザイナー集まって意見を言い合うため、事前にクリティカルになりそうな部分などを洗い出すことができ、リリース直前での考慮漏れによる仕様変更を防ぐことができると感じてます。
ユーザーストーリー確認コストの削減
また、受け入れテストを作成するためには、エンジニア・デザイナーも仕様を深く理解することが求められるため、開発進行段階での仕様確認・デザイン作成段階でのユーザーストーリー確認コストが下がっている傾向あります。開発プロセスの初期に時間をかけることで、他のプロセスにも副次的に効果が出るイメージです。これ結果として、安定的なプロジェクトマネジメントに繋がっていることを感じています
開発コストの把握によるスケジューリング把握
プロジェクトマネジメントの比較的初期フェーズで、エンジニア目線での開発項目(脆弱性診断の実施有無など)を把握することが、不確実性を低下に繋がっていると感じます。早い段階で一定程度の見積りがつくことで、PdMとしての着手タスクの優先順位決定にポジティブな影響がありました。
ATDDを実施することのデメリットはあるのか
PdM目線では、基本的にはないと思ってます。
受け入れ作成工数などがATDD導入前にはデメリットして想定していましたが、結局でQAをするタイミングでシナリオ一覧は作ることになります。
初期段階で作成しておき、ステークホルダーの認識が揃った段階で開発をすることができるので、トータルで考えると工数的にもプラスが多いです
ATDDを実施する上で、工夫したこと
PdM・エンジニア・デザイナーで受け入れテストを作成する前に、簡単なモックを作成すること
ATDDでは、受け入れテストがクリアされていたら品質として問題ないことになるので、受け入れテストを漏れなく、さまざまなケースに考慮された形で作成する必要があります。
告知コーナー
まだATDDを導入してみて数ヶ月なので、これまでATDDを運用されておられる方は、ぜひOffersで提供しているQ&A機能に、ATDDに関連する質問がされているので、ご回答してくださると嬉しいです！
また、PMの採用も絶賛実施しております！みなさんご応募お待ちしております！！
副業を始めたい方