タスクを生成してコードを実装する
技術計画はアーキテクチャの方向性を提供しますが、実装には具体的で実用的な手順が必要です。 このユニットでは、エンタープライズ シナリオの高度なタスク生成と管理の手法について説明します。
タスクの基礎を確認する
GitHub Spec Kit の /speckit.tasks コマンドは、アーキテクチャに関する大まかな決定事項を、tasks.md ファイル内の特定の作業項目に変換します。 各タスクは、個別に実装、テスト、検証できる個別の作業単位を表します。
適切な範囲のタスクの主な特性:
- アクション可能: 実行する必要がある内容を明確に示します。
- テスト可能: 完了の検証は簡単です。
- 独立: 関係のない作業を待たずに完了できます。
- 時間制限あり: 妥当な時間枠 (時間から日) で完了できます。
フェーズベースの組織
複雑な機能は、タスクをフェーズにまとめる利点があります。 たとえば、セットアップ、基盤、コア機能、UI/統合、セキュリティ、テストなどです。 各フェーズは、マイルストーンに向けて構築される論理グループを表します。
タスクの内訳の利点
タスクの内訳は、作業を整理するだけでなく、複数の目的に役立ちます。 AI は、単一の操作で機能全体を実装するのではなく、特定の目的に合わせて重点を置いたコードを生成するのに役立ちます。 これらは、続行する前に部分的な実装をテストできる自然な検証ポイントを作成します。 完了した内容と残っている内容を正確に表示することで、正確な進行状況の追跡が可能になります。 依存関係を明示的にすることで、チームの調整が容易になります。
ドキュメントのアップロード機能の場合、このプランではアーキテクチャとテクノロジの全体的な選択肢について説明します。 タスク リストは、アーキテクチャ上の決定を特定のアクションに変換します。データベース テーブルの作成、API エンドポイントの実装、React コンポーネントの構築、検証ロジックの追加、テストの記述などです。 各タスクは、妥当な期間に完了するのに十分な小ささですが、意味のある進行状況を表すのに十分な大きさです。
タスクの構造と組織を調べる
適切に構造化されたタスク リストは、作業を論理的に整理し、依存関係を適切にシーケンスし、実装に関する明確なガイダンスを提供します。
フェーズベースの組織
複雑な機能は、フェーズベースの組織の恩恵を受けます。 各フェーズは、特定のマイルストーンに向けて構築される関連タスクの論理的なグループを表します。
ドキュメントのアップロード機能の場合、一般的なフェーズ構造には次のものが含まれます。
フェーズ 1: 基盤と構成
- appsettings.jsonで Azure Blob Storage 接続構成を設定します。
- 適切なスキーマを使用して、SQL データベースに DocumentMetadata テーブルを作成します。
- バックエンド プロジェクトに Azure.Storage.Blobs NuGet パッケージを追加します。
- ストレージ操作をカプセル化する DocumentService クラスを作成します。
フェーズ 2: コア アップロード機能
- DocumentsController に POST /api/documents/upload エンドポイントを実装します。
- DocumentService にファイル検証ロジック (サイズ、種類) を追加します。
- エラー処理を使用して BLOB ストレージのアップロード方法を実装します。
- アップロードが成功した後、ドキュメント メタデータをデータベースに保存します。
- ドキュメント ID と URL を含むアップロード結果をクライアントに返します。
フェーズ 3: フロントエンドの実装
- ファイル入力を使用して DocumentUpload React コンポーネントを作成します。
- コンポーネントにファイル サイズと型の検証を追加します。
- アップロードの進行状況インジケーターを実装します。
- アップロードの成功とエラーの応答を処理します。
- アップロードが成功した後にドキュメント一覧を更新します。
フェーズ 4: セキュリティと検証
- アップロード エンドポイントに Microsoft Entra ID 認証チェックを追加します。
- マジック ナンバーを使用して、サーバー側のファイルの種類の検証を実装します。
- DoS 攻撃を防ぐ要求サイズの制限を追加します。
- 許可されたリストに対してファイル拡張子を検証します。
- アップロード操作の監査ログを追加します。
フェーズ 5: テストとドキュメント
- DocumentService アップロード メソッドの単体テストを記述します。
- 完全なアップロード フローの統合テストを作成します。
- エラー シナリオ テストを追加します (無効なファイルの種類、サイズを超えました)。
- OpenAPI/Swagger のドキュメント API エンドポイント。
- アップロード手順を使用してユーザー ドキュメントを更新します。
この段階的なアプローチにより、自然なマイルストーンが作成されます。 フェーズ 2 の後、動作する最小限のバックエンドが得られます。 フェーズ 3 の後、ユーザーはファイルをアップロードできます。 フェーズ 4 の後、システムはセキュリティで保護され、運用の準備が整います。 フェーズ 5 の後、すべてがテストされ、文書化されます。
タスクの粒度とスコープ
各タスクは、明確な方向を提供するのに十分な範囲で適切にスコープを設定する必要がありますが、規範的なマイクロ管理になるほど詳細ではありません。
適切な範囲のタスクは、次の特性を共有します。
- アクション可能: タスクは、何を行う必要があるかを明確に示します。
- テスト可能: タスクが完了した時点を確認できます。
- 可能な限り独立: タスクは、関連のない作業を待たずに完了できます。
- 時間制限: 開発者は、妥当な期間 (通常は週ではなく、数時間から 1 日) でタスクを完了できます。
適切なスコープのタスクの例: "マルチパート ファイルのアップロードを受け入れ、ファイル サイズが 50 MB 未満であることを検証し、Azure Blob Storage にファイルを格納し、BLOB URL とドキュメント ID を返す POST /api/documents/upload エンドポイントを実装する"。
このタスクは、ビルドする内容 (エンドポイント)、受け入れる内容 (マルチパート ファイル)、適用する検証 (サイズ制限)、ファイルを格納する場所 (Azure Blob Storage)、および返す内容 (URL と ID) に固有です。 開発者は、実装する内容を正確に把握しています。
スコープが不十分なタスクの例を次に示します。「アップロードを機能させる」といったものです。この例は、「機能」が何を指すのか、またどの部分が関与するのかについて具体的なガイダンスがありません。
過剰に規範的なタスクの例を次に示します。"DocumentsController.csの 47 行目で、パラメーター (IFormFile ファイル、文字列 userId) を含む UploadDocument という名前のメソッドを追加し、正確にこれらの手順を使用して実装します。"このタスクの説明では、開発者機関が削除され、コード構造の進化は考慮されません。
タスクの依存関係とシーケンス処理
タスクの順序が重要です。 一部のタスクは、他のタスクを開始する前に完了する必要があります。
バックエンド コードはスキーマの存在に依存するため、通常、データベース スキーマの変更が最初に行われます。 バックエンド API エンドポイントは、これらのエンドポイントを呼び出すフロントエンド コンポーネントの前に存在します。 構成のセットアップは、その構成を使用するコードの前に置かれます。 テストは、テスト対象のコードが存在した後に行われます。
タスク リストは、ブロックを最小限に抑えるために作業をシーケンスする必要があります。 フロントエンド タスクとバックエンド タスクが独立している場合は、並列で作業を進めることができます。 複数のバックエンド エンドポイントが存在する場合、開発者はタスクを同時に実装できます。
ドキュメントのアップロード機能の場合、論理シーケンスによって以下が保証されます。
- 最初に構成とデータベースのセットアップが行われます (依存関係はありません)。
- バックエンド API の実装は、データベースのセットアップに従います (スキーマによって異なります)。
- フロントエンド コンポーネントは API 実装に従います (既存のエンドポイントによって異なります)。
- セキュリティ強化は、コア機能の後に行われます (既存のコードによって異なります)。
- テストはすべての実装後に行われます (完了したコードによって異なります)。
このタスク シーケンスを使用すると、関連のない作業が完了するのを待たずに継続的な進行状況を実現できます。
/speckit.tasks を使用してタスクを生成する
GitHub Spec Kit は、GitHub Copilot Chat の /speckit.tasks コマンドを使用してタスク リストを生成します。 このコマンドは、spec.md と plan.md の両方を処理して、包括的な順序付けされた実装タスクの一覧を生成します。
AI は仕様を分析して何を構築する必要があるかを理解し、アーキテクチャアプローチを理解するための計画をレビューし、これらのドキュメントと実際のコードの間のギャップを埋めるタスクを生成します。 結果の tasks.md ファイルには、番号付きタスクまたは箇条書きタスクが含まれています。多くの場合、複雑な機能のフェーズに編成されます。
タスク生成コマンドを呼び出す
Visual Studio Code で GitHub Copilot Chat を開き、「 /speckit.tasks」と入力します。 GitHub Copilot は仕様を処理し、構造化されたタスク リストの生成を計画します。 通常、生成プロセスは数分後に完了し、実装作業の包括的な内訳が生成されます。
タスク リストは、仕様とプランからコンテキストを自動的に継承します。 プランで "Azure Blob Storage の使用" が指定されている場合、生成されるタスクには、BLOB ストレージ接続の構成、アップロード ロジックの実装、ストレージ エラーの処理に関する特定の手順が含まれます。
タスク の一覧を確認して検証する
タスクの一覧では、完全性と正確性を確保するために重要なレビューが必要です。
プラン要素の対象範囲を確認する
tasks.md と plan.md を体系的に比較します。 計画内のすべてのアーキテクチャの決定と実装の手順は、1 つ以上のタスクに対応する必要があります。
プランで "サーバー側検証の実装" が指定されている場合、特定のタスクでは、ファイルの種類の検証、ファイル サイズの検証、およびエラー応答の処理に対応する必要があります。 計画で "監査ログ記録" と記載されている場合、タスクはアップロード操作のログ エントリの作成に対処する必要があります。
タスクが見つからない場合は、生成が不完全であるか、具象作業に変換されない計画要素が示されます。 タスクを手動で追加するか、より多くのコンテキストを提供して再生成することで、この問題を解決します。
論理的なギャップを確認する
計画からは明らかではないが、実装の詳細を検討するときに明らかになる機能のギャップを探します。
一般的なギャップは次のとおりです。
- エラー処理: ネットワーク エラー、ストレージエラー、またはデータベースの問題を処理するためのタスクはありますか?
- エッジ ケース: ユーザーが同じ名前のファイルをアップロードするとどうなりますか? 同時アップロードはどのように処理されますか?
- 構成: 接続文字列、API キー、およびサービス エンドポイントは正しく構成されていますか?
- ユーザーからのフィードバック: アップロードが完了または失敗したタイミングをユーザーが知る方法
- データのクリーンアップ: アップロードが部分的に成功した場合、失敗した場合、クリーンアップは処理されますか?
レビュー中にこれらのギャップを特定し、実装を開始する前に適切なタスクを追加します。
タスクの順序と依存関係を評価する
タスクが適切にシーケンスされていることを確認します。 データベース スキーマ タスクは、これらのテーブルにアクセスするコードの前に置く必要があります。 API エンドポイント タスクは、これらのエンドポイントを呼び出すフロントエンド コンポーネントの前に置く必要があります。
タスクの順序が誤っている場合は、手動で並べ替えます。 たとえば、対応するバックエンド タスクの前にフロントエンド タスクが表示される場合は、適切なフェーズに移動します。
同じフェーズ内のタスク間の依存関係を検討してください。 あるタスクの出力が別のタスクに必要な場合は、最初のタスクがシーケンスの前に表示されていることを確認します。
タスクの粒度を検証する
各タスクのスコープが適切であることを確認します。 大きすぎるタスク ("バックエンド全体を実装する") は、より小さく管理しやすい部分に分割する必要があります。 小さすぎるタスク ("42 行目にセミコロンを追加") は、より意味のある単位に結合する必要があります。
適切な範囲のタスクは、通常、完了までに数時間から 1 日かかり、個別にテストでき、実証可能な進行状況を生み出します。
タスクを使用して実装をガイドする
検証が完了すると、tasks.md が実装ロードマップになります。
タスクの体系的な進行
タスクを順番に実行し、それぞれを完了してから次に進みます。 この規範的なアプローチにより、何もスキップされることがないようにし、明確な進行状況インジケーターを提供します。
各タスクを完了すると、次のようになります。
- 必要な機能を実装します。
- 実装をテストして、正確性を確認します。
- タスクを完了としてマークします (チェック ボックスまたは取り消し線を追加します)。
- タスクへの参照を使用して変更をコミットします。
この体系的なアプローチにより、完了した作業を特定のタスクにリンクする明確な監査証跡が作成されます。
進行状況を追跡し、状態を伝える
タスク リストには、進捗状況の客観的な測定値が表示されます。 30 個のタスクのうち 15 個が完了した場合、この機能は約 50% 実装されます。 このメトリックは、プロジェクト計画と利害関係者のコミュニケーションに役立ちます。
tasks.md をチームと共有して、何が完了し、何が残っているかを伝えます。 チーム メンバーは、注意が必要な領域と、レビュー作業に集中する場所をひとめで確認できます。
実装時にタスクを調整する
実装によって新しい要件またはより優れたアプローチが明らかになった場合は、それに応じて tasks.md 更新します。 タスク リストには、古い計画ではなく、現実が反映されている必要があります。
チーム メンバー間でタスクを配布する
タスク定義をクリアすると、複数の開発者間で作業を分散できます。 バックエンド チームは API タスクに取り組むことができますが、フロントエンド チームは UI コンポーネントを構築します。 データベース管理者は、開発者が構成を準備するときにスキーマを設定できます。
タスクの依存関係を明示的に呼び出すことは、ブロックを防ぐのに役立ちます。 タスク B がタスク A に依存している場合は、タスク A が割り当てられ、適切に優先順位付けされていることを確認します。 タスクの完了条件を文書化して、ハンドオフがクリーンであることを確認します。
/speckit.implement を使用してコードを生成する
/speckit.implement コマンドは、tasks.md を使用してコードを体系的に生成します。 AI は、機能全体を 1 回のパスで実装するのではなく、タスクを順番に処理します。 この方法では、より焦点を絞った正しいコードが生成されます。
特定のタスク番号、一連のタスク、または tasks.md ファイルから取得した実装の説明を使用して、 /speckit.implement を呼び出すことができます。 AI は spec.md、plan.md、および tasks.md を参照して、全体的なアーキテクチャと要件に合ったコードを生成します。
たとえば、ドキュメント アップロード エンドポイントを実装するには、次のように入力します。
/speckit.implement Implement the MVP first strategy (Tasks: T001 - T027)
このコマンドは、タスク T001 から T027 に重点を置き、各タスクの要件を順番に満たすコードを生成するように AI に指示します。
実装時に支援を提供する
AI には、特定のタスクを続行するための支援またはアクセス許可が必要な場合があります。 たとえば、タスクでアプリのビルドまたは実行が必要な場合、AI は続行する前に確認を求めるメッセージを表示する場合があります。
さらに、AI はタスクの実装をテストするときにバグを検出する可能性があります。 問題の診断に役立つ詳細情報を提供します。 AI があいまいさを検出した場合は、追加のコンテキストや明確化を提供することもできます。
チャット ビューでサポートを求められたら、迅速な応答によって実装をスムーズに進めることができます。
検証チェックポイント
実装コマンドを完了したら、先に進む前に結果を確認します。 アプリケーションを実行し、テストを実行し、各タスクが実装され、その目的が達成されていることを確認します。 この増分検証では、修正が最も簡単な問題を早期にキャッチします。
タスク間のコンテキスト メンテナンス
タスクを進めるにつれて、以前に完了した作業は後続のタスクのコンテキストを提供します。 AI は、関連する機能を構築し、コードの品質を向上させ、アーキテクチャの一貫性を維持する際に、以前の実装を参照できます。
実装時にタスク関連の課題を管理する
実装タスクを管理する場合、一般的な課題が発生します。
スコープが広がるタスク
実装中にタスクで予期しない複雑さが明らかになった場合は、一時停止して再評価します。 肥大化したタスクを複数の小さなタスクに分割します。 tasks.md を更新して、真のスコープを反映します。 スコープの拡張を関係者に伝えます。
ブロックされたタスク
タスクが外部の依存関係によってブロックされる場合があります。 ブロックされたタスクを tasks.md で明示的にマークします。ブロックの理由は、"BLOCKED: Waiting for Azure Blob Storage container provisioning - ticket #1234" (ブロック: Azure Blob Storage コンテナーのプロビジョニングを待機しています - チケット #1234) です。ブロックされたタスクを個別に追跡して、忘れられないようにします。
優先順位の変更
ビジネス ニーズは進化します。 優先順位が変わったら、それに応じて tasks.md を更新します。 新しい優先順位を反映した方法でタスクを並べ替えます。 新しい要件の新しいタスクを追加します。 価値がなくなったタスクを延期または削除することを検討してください。
実装中に検出されたタスクのあいまいさ
あいまいさが表面化したら、実装を一時停止し、明確化を求める。 仕様を確認し、元の意図を理解することを計画します。 先に進む前に、特定の明確な言語でタスクの説明を更新します。
概要
タスクの生成により、アーキテクチャ計画が実用的な実装手順に変換されます。
/speckit.tasksを使用してタスク リストを生成し、実装作業の構造化されたフェーズベースの内訳を作成します。 生成されたタスクを注意深く検討して、包括的なカバレッジ、論理的な順序、適切な粒度を確保します。 検証済みのタスク リストを使用して、体系的な実装をガイドし、進捗状況を追跡し、チームの作業を調整します。
spec.md、plan.md、および tasks.md の組み合わせにより、完全な開発フレームワークが作成されます。 仕様では、何を構築し、その理由を定義します。 この計画では、アーキテクチャ的に構築する方法を定義します。 タスクは、ビルドを実行するための特定の手順を定義します。 これらの成果物を組み合わせることで、あいまいな要件が具体的で追跡可能な開発作業に変換され、実装全体を通じてプロジェクトの目標との整合性が維持されます。