個人開発のテスト戦略：週3時間で実装する段階的フレームワーク

Q: MVP期に手動テストだけで本当に大丈夫？

はい、MVP期は仮説検証が最優先のため、手動テストのみで十分です。 [Fintan](https://fintan.jp/page/10596/)によれば、MVPの目的は「仮説を検証可能な最小限の製品」であり、使い捨てを前提とした開発です。この段階でテスト自動化に時間を使うと、ROIが低くなります。むしろ、市場フィードバックを早期に獲得し、ピボット判断を迅速に行うことが重要です。 ただし、以下の点には注意してください： - **セキュリティの基本は担保する**: XSS・SQLインジェクション対策は手動でも必ず確認 - **データ損失リスクは避ける**: ユーザーデータの保存・削除機能は慎重にテスト - **致命的なバグのみ防ぐ**: 完璧を目指さず、サービス停止につながるバグのみ防止 MVP期を抜けたら（100ユーザー獲得後）、速やかにE2Eテストの導入を検討してください。

Q: テスト時間を週3時間以上に増やすべき？

週3時間（開発時間の約15%）が個人開発の上限であり、これ以上増やすとROIが低下します。 [テスト自動化のROI](https://qiita.com/YoheiKanamaru1/items/d7264e541c793801692c)に関する調査では、テスト実装時間と損益分岐点の関係が分析されており、個人開発では週3時間程度が最適とされています。 もしバグが頻発する場合は、テスト時間を増やすのではなく、以下を検討してください： - **コードレビューの強化**: AI（ChatGPT/Claude）を使った事前レビュー - **リファクタリング**: テストしやすい設計への改善 - **テスト対象の絞り込み**: 効果の低いテストを削除し、重要部分に集中 テスト時間の上限を守り、その範囲内で最大の効果を得る工夫が重要です。

副業エンジニアのテスト時間不足を解決する段階的アプローチ

「テストを書きたいけど、時間がない」——週18時間程度で副業開発を行うエンジニアの多くが直面する課題です。MVP開発ではスピードが命と言われる一方で、テストなしでリリースするのは不安。かといって、企業のQAチームのような包括的なテスト体制を個人で構築するのは現実的ではありません。

本記事では、副業エンジニアが限られた時間でテスト品質を段階的に高めるための実践的フレームワークを提案します。MVP期（週1時間・手動テスト）、成長期（週2時間・E2Eテスト導入）、スケール期（週3時間・包括的自動テスト）の3段階で、無料ツールを使って効率的にテスト戦略を実装する具体的な手順を解説します。

この記事を読むことで、以下のメリットが得られます：

テストにかける時間の上限を設定し、ROI（投資対効果）を最大化する方法
フェーズに応じた優先順位の高いテストの選び方
PlaywrightやVitestなどの無料ツールの具体的な実装手順
「時間最適化テストピラミッド」という新しい概念による、時間制約下での最適なテスト配分

注意: 本記事で提示する時間配分（週1〜3時間）はあくまで参考値です。実際の所要時間は、プロジェクトの規模、個人のスキルレベル、環境などによって変動します。

テストピラミッドを時間制約に適合させる「時間最適化テストピラミッド」

従来のテストピラミッドは、ユニットテスト70%、統合テスト20%、E2Eテスト10%の比率を推奨しています。しかし、これは企業のQAチーム前提の配分であり、週18時間制約の副業エンジニアには適していません。

「時間最適化テストピラミッド」では、テスト時間の上限を先に決め、その時間内で最大のROIを得られるテストを優先的に実装します。この考え方により、限られた時間で効果的にバグを防ぎ、品質を担保できます。

時間最適化テストピラミッドの3原則

時間制約下でテスト戦略を構築する際の3つの原則を以下に示します：

原則1：テスト時間の上限を設定する: 開発時間の約15%（週18時間の場合は週3時間が上限）をテストに割り当て、この範囲内で最適化を図る
原則2：フェーズ別に優先順位を変える: MVP期は手動テスト、成長期はE2Eテスト、スケール期でユニットテストを追加する段階的アプローチ
原則3：ROIを継続的に測定する: テストの実装時間とバグ検出率を記録し、効果の低いテストは削除または簡略化する

この3原則に従うことで、限られた時間を無駄にせず、プロダクトの成長段階に応じた最適なテスト体制を構築できます。従来のテストピラミッドが「テストの種類」を軸にした配分であるのに対し、時間最適化テストピラミッドは「時間」を軸にした配分である点が大きな違いです。

MVP期のテスト戦略：週1時間で重要パスを手動テスト

MVP期（リリース前〜最初の100ユーザー獲得まで）は、仮説検証が最優先です。この段階では、テスト自動化の実装時間よりも、機能開発と市場フィードバックの獲得に時間を使うべきです。

MVP期の基本方針

MVP期のテスト戦略は「最小限の手動テストで重要パスのみを担保する」ことです。Fintanによれば、MVPの目的は仮説検証であり、その目的を達成できる品質を担保できれば十分とされています。

MVP期のテスト時間配分と実施内容を以下に示します：

テスト時間: 週1時間程度（開発時間の約5%）
テスト方法: 手動テストのみ（自動化なし）
対象範囲: ユーザーの重要パス（コアとなる2〜3シナリオのみ）
ツール: チェックリスト（スプレッドシートで管理）

この配分により、最小限の時間で致命的なバグを防ぎつつ、開発スピードを維持できます。

重要パスの手動テストチェックリスト作成

手動テストを効率化するために、チェックリストを作成します。GRIによれば、Webアプリケーションの手動テストでは、入力中のエラー制御、送信前の確認、サーバー処理エラー防止、データ登録後の整合性確認の4つの観点が重要です。

具体的なチェックリスト項目例（Webアプリケーションの場合）：

観点	チェック項目	確認内容	所要時間
認証	ログイン/ログアウト	正常系・異常系の動作確認	5分
コア機能	メイン機能の実行	ユーザーストーリーの主要パス	15分
データ保存	CRUD操作の確認	作成・読込・更新・削除の動作	10分
エラー処理	異常系の挙動	バリデーション・エラーメッセージ	10分
画面表示	レスポンシブ対応	モバイル・デスクトップ表示	10分
パフォーマンス	基本動作速度	ページ読み込み・API応答時間	5分
セキュリティ	基本的な保護	XSS・SQLインジェクション対策	5分

このチェックリストを使うことで、週1時間（60分）で重要パスを網羅的にテストできます。MVP期は毎週リリース前にこのチェックリストを実行し、致命的なバグがないことを確認します。

成長期のテスト戦略：週2時間でE2Eテストを導入

成長期（100〜1,000ユーザー）では、手動テストだけでは追いつかなくなります。機能が増え、リグレッション（既存機能の不具合）リスクが高まるためです。この段階でE2Eテストを導入し、重要パスの自動化を開始します。

成長期の基本方針

成長期のテスト戦略は「重要パスのE2Eテストを2〜3シナリオ自動化する」ことです。令和トラベルのQA戦略でも、成長期ではE2Eテストの段階的導入が推奨されています。

成長期のテスト時間配分と実施内容を以下に示します：

テスト時間: 週2時間程度（開発時間の約10%）
- E2Eテスト実装・メンテナンス: 週1時間
- 手動テスト（非自動化部分）: 週1時間
テスト方法: E2Eテスト（Playwright）+ 手動テスト
対象範囲: 重要パス2〜3シナリオを自動化、その他は手動
ツール: Playwright（無料）

この配分により、リグレッションリスクを抑えつつ、新機能開発の時間も確保できます。

PlaywrightによるE2Eテスト実装

Playwrightは、Microsoftが開発したE2Eテストフレームワークで、Chromium・Firefox・WebKitの3ブラウザに対応しています。Next.jsとの統合も公式にサポートされており、個人開発に最適です。

インストールと設定

Next.jsプロジェクトにPlaywrightを導入する手順：

# Playwrightのインストール
npm init playwright@latest

# プロンプトに従って設定
# - TypeScript: Yes
# - tests folder: tests
# - GitHub Actions: No（後で追加可能）

playwright.config.tsの設定例：

import { defineConfig, devices } from '@playwright/test'

export default defineConfig({
  testDir: './tests',
  // 開発サーバーを自動起動
  webServer: {
    command: 'npm run dev',
    url: 'http://localhost:3000',
    reuseExistingServer: !process.env.CI,
  },
  // 3ブラウザでテスト（時間制約がある場合はChromiumのみに絞る）
  projects: [
    { name: 'chromium', use: { ...devices['Desktop Chrome'] } },
  ],
})

重要パスのE2Eテスト例

ユーザー登録→ログイン→メイン機能実行の重要パスをテストする例：

import { test, expect } from '@playwright/test'

test('重要パス：ユーザー登録からメイン機能実行まで', async ({ page }) => {
  // 1. ユーザー登録
  await page.goto('http://localhost:3000/signup')
  await page.fill('input[name="email"]', 'test@example.com')
  await page.fill('input[name="password"]', 'password123')
  await page.click('button[type="submit"]')

  // 登録完了を確認
  await expect(page).toHaveURL('http://localhost:3000/dashboard')

  // 2. メイン機能実行（例：記事作成）
  await page.click('text=新規作成')
  await page.fill('input[name="title"]', 'テスト記事')
  await page.fill('textarea[name="content"]', 'テスト内容')
  await page.click('button:has-text("公開")')

  // 作成完了を確認
  await expect(page.locator('text=公開しました')).toBeVisible()
})

このテストを2〜3シナリオ作成し、週1回実行します。実装時間は1シナリオあたり30分〜1時間程度が目安です。

E2Eテストの運用ポイント

E2Eテストを効率的に運用するためのポイント：

テストは少数精鋭: 2〜3シナリオに絞り、メンテナンスコストを抑える
data-testid属性を活用: 要素選択を安定させる（<button data-testid="submit-button">）
非同期処理の待機: await expect().toBeVisible()で確実に待機
スクリーンショット機能: テスト失敗時の自動スクリーンショットで原因特定を効率化

これらのポイントを押さえることで、週1時間のメンテナンス時間で2〜3シナリオを維持できます。

スケール期のテスト戦略：週3時間で包括的自動テストを実装

スケール期（1,000ユーザー以上）では、バグの影響範囲が大きくなり、品質への要求が高まります。この段階でユニットテストを導入し、E2Eテストと組み合わせた包括的なテスト体制を構築します。

スケール期の基本方針

スケール期のテスト戦略は「時間最適化テストピラミッドに従い、ユニットテスト50%・E2Eテスト30%・手動テスト20%の時間配分で実装する」ことです。

スケール期のテスト時間配分と実施内容を以下に示します：

テスト時間: 週3時間程度（開発時間の約15%）
- ユニットテスト実装・メンテナンス: 週1.5時間
- E2Eテスト実装・メンテナンス: 週1時間
- 手動テスト（非自動化部分）: 週0.5時間
テスト方法: ユニットテスト（Vitest）+ E2Eテスト（Playwright）+ 手動テスト
対象範囲: ビジネスロジックはユニットテスト、重要パスはE2Eテスト、UIの細かい挙動は手動テスト
ツール: Vitest（ユニットテスト）+ Playwright（E2Eテスト）

この配分により、バグ検出率を高めつつ、開発スピードも維持できます。

Vitestによるユニットテスト実装

Vitestは、Viteベースの高速テストフレームワークで、Next.jsとの親和性が高く、個人開発に最適です。

インストールと設定

Next.jsプロジェクトにVitestを導入する手順：

# Vitestと関連パッケージのインストール
npm install -D vitest @vitejs/plugin-react jsdom @testing-library/react @testing-library/dom vite-tsconfig-paths

vitest.config.mtsの設定例：

import { defineConfig } from 'vitest/config'
import react from '@vitejs/plugin-react'
import tsconfigPaths from 'vite-tsconfig-paths'

export default defineConfig({
  plugins: [tsconfigPaths(), react()],
  test: {
    environment: 'jsdom',
  },
})

package.jsonにテストスクリプトを追加：

{
  "scripts": {
    "test": "vitest"
  }
}

ビジネスロジックのユニットテスト例

ユニットテストは、ビジネスロジック（関数・クラス）を対象とします。UI依存のないロジックを切り出してテストすることで、高速で安定したテストを実現できます。

// lib/pricing.ts（価格計算ロジック）
export function calculateDiscountPrice(basePrice: number, discountRate: number): number {
  if (basePrice < 0 || discountRate < 0 || discountRate > 1) {
    throw new Error('Invalid input')
  }
  return Math.floor(basePrice * (1 - discountRate))
}

// lib/pricing.test.ts
import { test, expect } from 'vitest'
import { calculateDiscountPrice } from './pricing'

test('割引価格の計算：正常系', () => {
  expect(calculateDiscountPrice(1000, 0.2)).toBe(800)
  expect(calculateDiscountPrice(1500, 0.5)).toBe(750)
})

test('割引価格の計算：異常系', () => {
  expect(() => calculateDiscountPrice(-100, 0.2)).toThrow('Invalid input')
  expect(() => calculateDiscountPrice(1000, 1.5)).toThrow('Invalid input')
})

ユニットテストは1関数あたり5〜10分で実装できます。週1.5時間で10〜15関数程度をカバーできます。

スケール期のテスト配分まとめ

スケール期のテスト配分を時間ベースで整理します：

テストレベル	時間配分	対象範囲	期待効果
ユニットテスト	週1.5時間（50%）	ビジネスロジック	バグの早期発見・高速フィードバック
E2Eテスト	週1時間（30%）	重要パス2〜3シナリオ	リグレッション防止
手動テスト	週0.5時間（20%）	UIの細かい挙動・新機能	自動化困難な部分の補完

この配分により、週3時間でバグ検出率を最大化しつつ、メンテナンスコストを抑えられます。

FAQ

Q1. MVP期に手動テストだけで本当に大丈夫？

はい、MVP期は仮説検証が最優先のため、手動テストのみで十分です。

Fintanによれば、MVPの目的は「仮説を検証可能な最小限の製品」であり、使い捨てを前提とした開発です。この段階でテスト自動化に時間を使うと、ROIが低くなります。むしろ、市場フィードバックを早期に獲得し、ピボット判断を迅速に行うことが重要です。

ただし、以下の点には注意してください：

セキュリティの基本は担保する: XSS・SQLインジェクション対策は手動でも必ず確認
データ損失リスクは避ける: ユーザーデータの保存・削除機能は慎重にテスト
致命的なバグのみ防ぐ: 完璧を目指さず、サービス停止につながるバグのみ防止

MVP期を抜けたら（100ユーザー獲得後）、速やかにE2Eテストの導入を検討してください。

Q2. E2Eテストとユニットテスト、どちらを先に実装すべき？

成長期（100〜1,000ユーザー）ではE2Eテストを優先し、スケール期（1,000ユーザー以上）でユニットテストを追加するのが推奨です。

従来のテストピラミッドではユニットテストが基盤とされますが、個人開発では「ユーザー体験の保証」が優先されます。E2Eテストは重要パス全体をカバーするため、少数のテストで大きな効果が得られます。

一方、ユニットテストは細かいロジックをテストするため、実装数が多くなりメンテナンスコストが高まります。スケール期に入り、コードベースが大きくなってからユニットテストを追加することで、ROIを最大化できます。

Q3. テスト時間を週3時間以上に増やすべき？

週3時間（開発時間の約15%）が個人開発の上限であり、これ以上増やすとROIが低下します。

テスト自動化のROIに関する調査では、テスト実装時間と損益分岐点の関係が分析されており、個人開発では週3時間程度が最適とされています。

もしバグが頻発する場合は、テスト時間を増やすのではなく、以下を検討してください：

コードレビューの強化: AI（ChatGPT/Claude）を使った事前レビュー
リファクタリング: テストしやすい設計への改善
テスト対象の絞り込み: 効果の低いテストを削除し、重要部分に集中

テスト時間の上限を守り、その範囲内で最大の効果を得る工夫が重要です。

まとめ：段階的にテスト品質を高める3ステップ

副業エンジニアが週18時間制約の中でテスト品質を高めるための3ステップを以下にまとめます。

MVP期は週1時間の手動テストから始める: チェックリストを作成し、重要パス（2〜3シナリオ）を毎週確認。テスト自動化は後回しにし、機能開発とフィードバック獲得を優先する
成長期は週2時間でE2Eテストを導入: Playwrightで重要パスを2〜3シナリオ自動化し、リグレッションリスクを抑える。手動テストは新機能や非自動化部分に絞る
スケール期は週3時間で包括的自動テストを実装: Vitestでビジネスロジックのユニットテストを追加し、E2Eテストと組み合わせた包括的なテスト体制を構築。時間配分はユニットテスト50%・E2Eテスト30%・手動テスト20%を目安にする

この3ステップに従うことで、限られた時間を無駄にせず、プロダクトの成長に合わせて最適なテスト品質を実現できます。テスト時間の上限（週3時間）を守り、ROIを継続的に測定しながら、効率的なテスト戦略を構築してください。

本記事と合わせて読むことで、より効果的な個人開発を実現できます：

忙しいエンジニアが最短でMVPをリリースする実践的開発戦略: MVP開発のスコープ削減と時短技術の選定方法を解説。本記事のMVP期テスト戦略と組み合わせることで、最短でのリリースを実現できます
個人開発で失敗しない技術スタック選定：週18時間で習得できるNext.js + Supabase + Vercel構成の判断基準: テスト自動化のしやすさも考慮した技術選定の判断基準を提示。PlaywrightやVitestとの親和性が高いNext.jsの選定理由を理解できます
個人開発の運用を週1時間に抑える自動化戦略の完全ガイド: デプロイ・監視・バックアップの自動化を解説。テスト自動化と組み合わせることで、運用負荷を最小化できます
個人開発のセキュリティ対策を週1時間で実装する実践ガイド: セキュリティテストの優先順位付けと実装方法を提示。本記事の手動テストチェックリストにセキュリティ項目を追加する際の参考になります

参考資料

副業エンジニアのテスト時間不足を解決する段階的アプローチ

この記事を読むことで、以下のメリットが得られます：

テストにかける時間の上限を設定し、ROI（投資対効果）を最大化する方法
フェーズに応じた優先順位の高いテストの選び方
PlaywrightやVitestなどの無料ツールの具体的な実装手順
「時間最適化テストピラミッド」という新しい概念による、時間制約下での最適なテスト配分

テストピラミッドを時間制約に適合させる「時間最適化テストピラミッド」

時間最適化テストピラミッドの3原則

時間制約下でテスト戦略を構築する際の3つの原則を以下に示します：

原則1：テスト時間の上限を設定する: 開発時間の約15%（週18時間の場合は週3時間が上限）をテストに割り当て、この範囲内で最適化を図る
原則2：フェーズ別に優先順位を変える: MVP期は手動テスト、成長期はE2Eテスト、スケール期でユニットテストを追加する段階的アプローチ
原則3：ROIを継続的に測定する: テストの実装時間とバグ検出率を記録し、効果の低いテストは削除または簡略化する

MVP期のテスト戦略：週1時間で重要パスを手動テスト

MVP期の基本方針

MVP期のテスト時間配分と実施内容を以下に示します：

テスト時間: 週1時間程度（開発時間の約5%）
テスト方法: 手動テストのみ（自動化なし）
対象範囲: ユーザーの重要パス（コアとなる2〜3シナリオのみ）
ツール: チェックリスト（スプレッドシートで管理）

この配分により、最小限の時間で致命的なバグを防ぎつつ、開発スピードを維持できます。

重要パスの手動テストチェックリスト作成

具体的なチェックリスト項目例（Webアプリケーションの場合）：

観点	チェック項目	確認内容	所要時間
認証	ログイン/ログアウト	正常系・異常系の動作確認	5分
コア機能	メイン機能の実行	ユーザーストーリーの主要パス	15分
データ保存	CRUD操作の確認	作成・読込・更新・削除の動作	10分
エラー処理	異常系の挙動	バリデーション・エラーメッセージ	10分
画面表示	レスポンシブ対応	モバイル・デスクトップ表示	10分
パフォーマンス	基本動作速度	ページ読み込み・API応答時間	5分
セキュリティ	基本的な保護	XSS・SQLインジェクション対策	5分

成長期のテスト戦略：週2時間でE2Eテストを導入

成長期の基本方針

成長期のテスト時間配分と実施内容を以下に示します：

テスト時間: 週2時間程度（開発時間の約10%）
- E2Eテスト実装・メンテナンス: 週1時間
- 手動テスト（非自動化部分）: 週1時間
テスト方法: E2Eテスト（Playwright）+ 手動テスト
対象範囲: 重要パス2〜3シナリオを自動化、その他は手動
ツール: Playwright（無料）

この配分により、リグレッションリスクを抑えつつ、新機能開発の時間も確保できます。

PlaywrightによるE2Eテスト実装

インストールと設定

Next.jsプロジェクトにPlaywrightを導入する手順：

# Playwrightのインストール
npm init playwright@latest

# プロンプトに従って設定
# - TypeScript: Yes
# - tests folder: tests
# - GitHub Actions: No（後で追加可能）

playwright.config.tsの設定例：

import { defineConfig, devices } from '@playwright/test'

export default defineConfig({
  testDir: './tests',
  // 開発サーバーを自動起動
  webServer: {
    command: 'npm run dev',
    url: 'http://localhost:3000',
    reuseExistingServer: !process.env.CI,
  },
  // 3ブラウザでテスト（時間制約がある場合はChromiumのみに絞る）
  projects: [
    { name: 'chromium', use: { ...devices['Desktop Chrome'] } },
  ],
})

重要パスのE2Eテスト例

ユーザー登録→ログイン→メイン機能実行の重要パスをテストする例：

import { test, expect } from '@playwright/test'

test('重要パス：ユーザー登録からメイン機能実行まで', async ({ page }) => {
  // 1. ユーザー登録
  await page.goto('http://localhost:3000/signup')
  await page.fill('input[name="email"]', 'test@example.com')
  await page.fill('input[name="password"]', 'password123')
  await page.click('button[type="submit"]')

  // 登録完了を確認
  await expect(page).toHaveURL('http://localhost:3000/dashboard')

  // 2. メイン機能実行（例：記事作成）
  await page.click('text=新規作成')
  await page.fill('input[name="title"]', 'テスト記事')
  await page.fill('textarea[name="content"]', 'テスト内容')
  await page.click('button:has-text("公開")')

  // 作成完了を確認
  await expect(page.locator('text=公開しました')).toBeVisible()
})

このテストを2〜3シナリオ作成し、週1回実行します。実装時間は1シナリオあたり30分〜1時間程度が目安です。

E2Eテストの運用ポイント

E2Eテストを効率的に運用するためのポイント：

テストは少数精鋭: 2〜3シナリオに絞り、メンテナンスコストを抑える
data-testid属性を活用: 要素選択を安定させる（<button data-testid="submit-button">）
非同期処理の待機: await expect().toBeVisible()で確実に待機
スクリーンショット機能: テスト失敗時の自動スクリーンショットで原因特定を効率化

これらのポイントを押さえることで、週1時間のメンテナンス時間で2〜3シナリオを維持できます。

スケール期のテスト戦略：週3時間で包括的自動テストを実装

スケール期の基本方針

スケール期のテスト時間配分と実施内容を以下に示します：

テスト時間: 週3時間程度（開発時間の約15%）
- ユニットテスト実装・メンテナンス: 週1.5時間
- E2Eテスト実装・メンテナンス: 週1時間
- 手動テスト（非自動化部分）: 週0.5時間
テスト方法: ユニットテスト（Vitest）+ E2Eテスト（Playwright）+ 手動テスト
対象範囲: ビジネスロジックはユニットテスト、重要パスはE2Eテスト、UIの細かい挙動は手動テスト
ツール: Vitest（ユニットテスト）+ Playwright（E2Eテスト）

この配分により、バグ検出率を高めつつ、開発スピードも維持できます。

Vitestによるユニットテスト実装

Vitestは、Viteベースの高速テストフレームワークで、Next.jsとの親和性が高く、個人開発に最適です。

インストールと設定

Next.jsプロジェクトにVitestを導入する手順：

# Vitestと関連パッケージのインストール
npm install -D vitest @vitejs/plugin-react jsdom @testing-library/react @testing-library/dom vite-tsconfig-paths

vitest.config.mtsの設定例：

import { defineConfig } from 'vitest/config'
import react from '@vitejs/plugin-react'
import tsconfigPaths from 'vite-tsconfig-paths'

export default defineConfig({
  plugins: [tsconfigPaths(), react()],
  test: {
    environment: 'jsdom',
  },
})

package.jsonにテストスクリプトを追加：

{
  "scripts": {
    "test": "vitest"
  }
}

ビジネスロジックのユニットテスト例

// lib/pricing.ts（価格計算ロジック）
export function calculateDiscountPrice(basePrice: number, discountRate: number): number {
  if (basePrice < 0 || discountRate < 0 || discountRate > 1) {
    throw new Error('Invalid input')
  }
  return Math.floor(basePrice * (1 - discountRate))
}

// lib/pricing.test.ts
import { test, expect } from 'vitest'
import { calculateDiscountPrice } from './pricing'

test('割引価格の計算：正常系', () => {
  expect(calculateDiscountPrice(1000, 0.2)).toBe(800)
  expect(calculateDiscountPrice(1500, 0.5)).toBe(750)
})

test('割引価格の計算：異常系', () => {
  expect(() => calculateDiscountPrice(-100, 0.2)).toThrow('Invalid input')
  expect(() => calculateDiscountPrice(1000, 1.5)).toThrow('Invalid input')
})

ユニットテストは1関数あたり5〜10分で実装できます。週1.5時間で10〜15関数程度をカバーできます。

スケール期のテスト配分まとめ

スケール期のテスト配分を時間ベースで整理します：

テストレベル	時間配分	対象範囲	期待効果
ユニットテスト	週1.5時間（50%）	ビジネスロジック	バグの早期発見・高速フィードバック
E2Eテスト	週1時間（30%）	重要パス2〜3シナリオ	リグレッション防止
手動テスト	週0.5時間（20%）	UIの細かい挙動・新機能	自動化困難な部分の補完

この配分により、週3時間でバグ検出率を最大化しつつ、メンテナンスコストを抑えられます。

FAQ

Q1. MVP期に手動テストだけで本当に大丈夫？

はい、MVP期は仮説検証が最優先のため、手動テストのみで十分です。

ただし、以下の点には注意してください：

セキュリティの基本は担保する: XSS・SQLインジェクション対策は手動でも必ず確認
データ損失リスクは避ける: ユーザーデータの保存・削除機能は慎重にテスト
致命的なバグのみ防ぐ: 完璧を目指さず、サービス停止につながるバグのみ防止

MVP期を抜けたら（100ユーザー獲得後）、速やかにE2Eテストの導入を検討してください。

Q2. E2Eテストとユニットテスト、どちらを先に実装すべき？

成長期（100〜1,000ユーザー）ではE2Eテストを優先し、スケール期（1,000ユーザー以上）でユニットテストを追加するのが推奨です。

Q3. テスト時間を週3時間以上に増やすべき？

週3時間（開発時間の約15%）が個人開発の上限であり、これ以上増やすとROIが低下します。

テスト自動化のROIに関する調査では、テスト実装時間と損益分岐点の関係が分析されており、個人開発では週3時間程度が最適とされています。

もしバグが頻発する場合は、テスト時間を増やすのではなく、以下を検討してください：

コードレビューの強化: AI（ChatGPT/Claude）を使った事前レビュー
リファクタリング: テストしやすい設計への改善
テスト対象の絞り込み: 効果の低いテストを削除し、重要部分に集中

テスト時間の上限を守り、その範囲内で最大の効果を得る工夫が重要です。

まとめ：段階的にテスト品質を高める3ステップ

副業エンジニアが週18時間制約の中でテスト品質を高めるための3ステップを以下にまとめます。

MVP期は週1時間の手動テストから始める: チェックリストを作成し、重要パス（2〜3シナリオ）を毎週確認。テスト自動化は後回しにし、機能開発とフィードバック獲得を優先する
成長期は週2時間でE2Eテストを導入: Playwrightで重要パスを2〜3シナリオ自動化し、リグレッションリスクを抑える。手動テストは新機能や非自動化部分に絞る
スケール期は週3時間で包括的自動テストを実装: Vitestでビジネスロジックのユニットテストを追加し、E2Eテストと組み合わせた包括的なテスト体制を構築。時間配分はユニットテスト50%・E2Eテスト30%・手動テスト20%を目安にする

本記事と合わせて読むことで、より効果的な個人開発を実現できます：

忙しいエンジニアが最短でMVPをリリースする実践的開発戦略: MVP開発のスコープ削減と時短技術の選定方法を解説。本記事のMVP期テスト戦略と組み合わせることで、最短でのリリースを実現できます
個人開発で失敗しない技術スタック選定：週18時間で習得できるNext.js + Supabase + Vercel構成の判断基準: テスト自動化のしやすさも考慮した技術選定の判断基準を提示。PlaywrightやVitestとの親和性が高いNext.jsの選定理由を理解できます
個人開発の運用を週1時間に抑える自動化戦略の完全ガイド: デプロイ・監視・バックアップの自動化を解説。テスト自動化と組み合わせることで、運用負荷を最小化できます
個人開発のセキュリティ対策を週1時間で実装する実践ガイド: セキュリティテストの優先順位付けと実装方法を提示。本記事の手動テストチェックリストにセキュリティ項目を追加する際の参考になります

あなたにおすすめの記事

エラーハンドリングを週2時間で実装：MVP期から段階的に導入する実践ガイド

個人開発のパフォーマンス最適化：週2時間で実装する段階的モニタリングガイド

個人開発のデプロイとCI/CD：週3時間で実装する段階的自動化ガイド

個人開発の競合分析を週2時間で完結させる実践ガイド：差別化ポイント発見から機能比較まで無料ツールで効率化

個人開発のユーザーリサーチを週3時間で完結させる実践ガイド：フィードバック収集から優先度付けまで

この記事をシェア

あなたにおすすめの記事

エラーハンドリングを週2時間で実装：MVP期から段階的に導入する実践ガイド

個人開発のパフォーマンス最適化：週2時間で実装する段階的モニタリングガイド

個人開発のデプロイとCI/CD：週3時間で実装する段階的自動化ガイド

個人開発の競合分析を週2時間で完結させる実践ガイド：差別化ポイント発見から機能比較まで無料ツールで効率化

個人開発のユーザーリサーチを週3時間で完結させる実践ガイド：フィードバック収集から優先度付けまで

この記事をシェア