コアスキル：フルスタック実践プロジェクト

「何が」ではなく「なぜ」を問う

「なぜ」と問いかけることで、ニーズの背後にある本当の動機とビジネス目標を理解する。

「いつ」と「誰」を尋ねる

• • 使用シーン：「この機能はいつ使いますか？使用頻度はどのくらいですか？」
• • 対象ユーザー：『この機能を使うのは誰か？その技術レベルはどのくらいか？』
• • 使用環境："どのような環境で使用するのか？制限は何か？"

「もし...ならどうなるか」と問う

• • 境界ケース：「この機能がなかったらどうなる？」
• • 例外処理：「データに異常があったらどうなる？」
• • 拡張性："要件が変わったらどうなる？"

良いユーザーストーリーの特徴

• • 独立性：独立して開発およびテストできる
• • 交渉可能：議論や調整ができる
• • 価値がある：ユーザーに実際の価値がある
• • 見積もり可能：開発時間を見積もることができる
• • 小：1回の反復で完了できる
• • テスト可能：明確な受け入れ基準がある

受け入れ基準

各ユーザーストーリーには明確な受け入れ基準が必要で、Given-When-Then 形式を使用します：

PRD 構成

• • 製品概要：製品ポジショニング、ターゲットユーザー、コアバリュー
• • 機能要件：詳細な機能説明とユーザーストーリー
• • 非機能要件：パフォーマンス、可用性、セキュリティ、拡張性
• • ユーザーインターフェース：インターフェース設計とインタラクションフロー
• • データモデル：データ構造と関係
• • 受け入れ基準：機能受け入れ、性能受け入れ、安全性受け入れ

PRD 作成原則

• • 明確でわかりやすい：明確な言葉を使い、曖昧さを避ける
• • 実行可能：AIはPRDに基づいて直接コードを生成できます
• • テスト可能：各要件には明確な受け入れ基準がある
• • 追跡可能：要件はビジネス目標までたどれる

OpenAPI仕様の利点

• • 標準化：業界標準で、ツールのサポートが充実している
• • 実行可能：AIはOpenAPIに基づいて直接コードを生成できる
• • テスト可能：APIテストケースを自動生成できる
• • ドキュメント化可能：自動生成APIドキュメント

API Specの例

openapi: 3.0.0
info:
  title: Task Management API
  version: 1.0.0
paths:
  /api/tasks:
    get:
      summary: タスク一覧を取得
      parameters:
        - name: status
          in: query
          schema:
            type: string
            enum: [pending, in-progress, completed]
      responses:
        '200':
          description: 成功
          content:
            application/json:
              schema:
                type: object
                properties:
                  tasks:
                    type: array
                    items:
                      $ref: '#/components/schemas/Task'
    post:
      summary: タスクを作成
      requestBody:
        required: true
        content:
          application/json:
            schema:
              $ref: '#/components/schemas/CreateTaskRequest'
      responses:
        '201':
          description: 作成成功
components:
  schemas:
    Task:
      type: object
      properties:
        id:
          type: string
        title:
          type: string
        status:
          type: string
          enum: [pending, in-progress, completed]

粒度制御

• • 2〜4時間の原則：各タスクは2〜4時間以内に完了すべきです
• • テスト可能性：各タスクには明確な受け入れ基準がある
• • 独立性：タスク間の依存関係をできるだけ減らす
• • 見積もり可能：完了時間を正確に見積もれる

依存関係

• • 依存関係を特定する：タスク間の依存関係を明確にする
• • クリティカルパス：プロジェクトのクリティカルパスを特定し、優先して完了する
• • 並列タスク：並列実行できるタスクを識別する
• • 依存関係の管理：ツール（GitHub Projects など）を使用して依存関係を管理する

三点見積もり法

類推による見積もり

類似タスクの完了時間を参考にし、現在のタスクの複雑さを踏まえて調整します。

AI支援による見積もり

AIツールを使ってタスクの複雑さを分析し、過去のデータと組み合わせて時間を見積もる。

機能受け入れ

• • すべての機能をSpecどおりに実装する
• • ユーザーストーリーの受け入れ基準を満たす
• • エッジケースの処理が正しい
• • エラー処理の充実

パフォーマンス受け入れテスト

• • 性能指標が要件を満たす
• • 負荷テストに合格
• • ストレステスト合格
• • パフォーマンス監視は正常です

セキュリティ受け入れテスト

• • セキュリティスキャンを通じて
• • 重大な脆弱性なし
• • データ暗号化は正しい
• • 権限管理が正しい