機能を速く作ることよりも大切なことがあります。それは「検証可能なリリースのリズム」です。2週間のサイクルの中でテスト、リファクタリング、価値検証がワンセットで回ってこそ、品質と成長が両立できるんです。
この記事では、2週間の開発サイクルをどう運用すればいいか、そしてその中心にある受け入れテスト駆動開発(ATDD)をどう適用するかを整理してみます。
2週間サイクルの基本構造#
2週間という時間をただ流してしまわないためには、開始・中盤・終了のそれぞれでやるべきことが明確でなければなりません。
- サイクル開始 — フィーチャーの目標と受け入れ基準(AC)を確定します
- サイクル中盤 — フィーチャーごとのテストシナリオを具体化します
- サイクル終了 — ビジネステストを実施し、振り返りを行います
ポイントは、サイクルが終わるたびにビジネステストを実施することです。マイルストーンの中にテスト項目を明記し、既存のテストと新規のテストがすべて通って初めてそのサイクルが終わります。
テストゲート:欠陥がある状態でリリースしない#
リリース前に必ず通すべきゲートを決めておくと、判断がぶれません。
- 新規テストの通過 — 今回のサイクルで追加した機能のテスト
- 回帰テストの通過 — 既存機能が壊れていないかの確認
- 欠陥許容基準の明確化 — 致命的/重要/軽微に等級を分けます
- 致命的な欠陥がある場合はリリース保留 — 欠陥がある状態ではリリースしません
「これくらいなら大丈夫だろう」という判断が入り込む余地を減らすのが、ゲートの役割です。
ATDDを適用する方法#
ATDD(受け入れテスト駆動開発)は、要件を受け入れテストシナリオとして先に定義し、そのシナリオを基準に実装と検証を進める方式です。
この方式の大きなメリットは、コミュニケーションコストの削減です。ビジネスの言葉とテストの言葉を一致させれば、企画者と開発者が同じ文章を見て同じことを理解できますよね。
リファクタリングは設計の健康を保つ活動#
リファクタリングを機能追加のように別のスケジュールで組むと、どんどん後回しになってしまいます。だから視点を変える必要があります。
- リファクタリングは機能追加ではなく、正しい設計を維持する活動です
- フィーチャー単位の開発ごとに小さなリファクタリングを一緒に行います
- テストがリファクタリングのセーフティネットの役割を果たしてくれます
テストがしっかりしていれば、リファクタリングを恐れる理由はありません。これが、先ほどのテストゲートとリファクタリングがワンセットになる理由です。
何を作るかを判断する価値フレーム#
何を開発するかを決めるときは、3つの価値を基準に判断します。
- ユーザー価値 — 実際の問題を解決しているか
- ビジネス価値 — 持続可能な成長と収益に貢献しているか
- 個人/チームの価値 — 自分たちが大切にしている哲学と一致しているか
順序も重要です。まずユーザー価値を開発し、情報を収集・評価したうえでビジネス価値につなげる流れです。そして、他人のための価値だけでなく、自分が大切だと考える価値も反映してこそ続けられます。
こうした文化は採用でもアピールになります#
このような運用方式は、社外の開発者にとっても魅力的なポイントになります。
- 「私たちのチームはATDD/TDDを実務で体得している」
- 「サービス中心の意思決定とテスト文化が成長の核心」
- 「入社すれば機能開発だけでなくプロダクト思考も学べる」
機能開発のスピードだけを強調するチームより、検証可能なリズムで働くチームのほうが、開発者にとって良い成長環境なんですよね。
まとめ#
2週間サイクルを単なる締め切りの単位ではなく、テストゲート、ATDD、リファクタリング、価値検証が一緒に回るリズムにしてみてください。スピードは少し遅く見えても、欠陥のないリリースが積み重なれば、それが結局いちばん速い道です。
Your future depends on many things, but mostly on you.
— Frank Tyger
