はじめに

本記事では、ウォーターフォール開発における Kiro を活用した要件定義工程の実施手順例を紹介します。steering を利用して要件定義のドキュメントの出力を制御し、MCP を介して Azure DevOps (ADO) Boards と連携し、要件定義時に発生した Issue（課題） を管理するプロセスで実施していきます。

1. Kiroとは

Kiro は、AIエージェントを備えた IDE（AI IDE）で、プロンプトから要件・設計・実装タスク・テストへと分解する「スペック駆動開発（spec-driven development）」を中核に、プロトタイプから本番までの開発を構造化して支援してくれます。
(https://kiro.dev/)
インストール方法や基本的な操作については、様々な方々が紹介してくれているため割愛します。

2. steering フォルダによるプロジェクト制御

Kiro では、プロジェクトの方針や生成ルールをまとめるために steering フォルダを作成し、その配下に Common steering files を配置します。本記事ではこれらを要件定義作業のインプットとして使用していきます。
[https://kiro.dev/docs/steering/]

2.1 steering フォルダ構成

Kiro 公式の Common steering files のうち、要件定義に必要なものを選定して格納していきます。今回は、 structure.mdについて、要件定義ドキュメント（requirements.md）の作成順序と出力内容の制御を目的で、フォルダ構成だけでなく、ドキュメント作成順序・各項目で必要なインプット・章立てと記載の要点を追記して利用します。
また、今回は要件定義の内容はすべてrequirements.mdに出力することとします。

product.md：プロジェクトの目的、ビジネス要件、想定する成果物を記載します。
security-policies.md：認証・認可、データ保護、脆弱性対策など、プロジェクト全体で遵守すべきセキュリティ方針を定義します。
structure.md：フォルダ構成やドキュメント作成ルールを定義します。
tech.md：アーキテクチャ構成、技術スタック、主要な非機能要件を定義します。

structure.md は 生成順序と出力の枠組みを規定しました。ここが曖昧だと、Kiro の出力が章立て・命名・形式のいずれかでブレやすくなるので、できる限り詳細に記載しました。

3. MCP による要件定義 Issue の管理

本記事ではAzure DevOps Boards を用いて、要件定義で生じる確認事項や課題（Issue）を管理します。以下はMCP を通じて、Kiro からの Issue 登録、最新 Issue の取得、ドキュメント反映までの流れのフローです。

今回は フック（Webhook）方式ではなく MCP の明示的な操作で登録タイミングを制御し、準自動（半自動）フローとしています。

4. 事前設定（MCP と ADO の接続）

MCP で ADO Boards に接続するため、.kiro/settings/mcp.json に接続情報を設定します。

今回は個人用 Microsoft アカウント (MSA) を利用したため、コミュニティ版 MCP（@tiberriver256/mcp-server-azure-devops）＋ PAT 認証で接続します。
※ Entra ID 連携の ADO 組織に所属するアカウントを利用する場合は、公式 MCPでブラウザ認証（OAuth）接続が可能です。初回接続時にブラウザが起動します。
ADO 側で Boards の Read/Write 権限を持つ PAT を発行し、環境変数 AZURE_DEVOPS_PAT に設定します。
今回はプロジェクト名を kiro とし、AZURE_DEVOPS_DEFAULT_PROJECT に設定します。（事前にAzure DevOps上でkiroというプロジェクトを作っておきます）
autoApprove は 読み取り系（一覧・参照）に限定し、登録系は都度確認とします。

{
  "mcpServers": {
    "azure-devops": {
      "command": "npx",
      "args": [
        "-y",
        "@tiberriver256/mcp-server-azure-devops"
      ],
      "env": {
        "AZURE_DEVOPS_AUTH_METHOD": "pat",
        "AZURE_DEVOPS_ORG_URL": "https://dev.azure.com/******",
        "AZURE_DEVOPS_PAT": "***********************************************************",
        "AZURE_DEVOPS_DEFAULT_PROJECT": "kiro"
      },
      "disabled": false,
      "autoApprove": [
        "list_projects",
        "list_project_teams",
        "list_work_items",
        "get_work_item"
      ]
    }
  }
}

autoApprove に 作成・更新系を含めると、意図せぬ登録・更新が走るリスクがあるため、この記事では 参照系操作のみ自動承認し、書き込み操作は手動承認としています。

5. 要件定義作業の進め方

題材は 発注管理システムのモダナイゼーション（AWS へリビルド） を想定します。要件定義のインプットとして、次の 4 ファイルを steering フォルダに格納してプロンプトを実行していきます。

product.md
security-policies.md
structure.md
tech.md

上記の資料は以下のリポジトリに格納しています。
(https://github.com/y-miyaz/kiro-requirements)

【ゴール】
「発注管理システム」の要件定義を作成する。
必要事項はすべて steering ドキュメントを参照して反映すること。

【参照（必読・厳守）】
- steering/product.md
- steering/structure.md
- steering/tech.md
- steering/security-policies.md
※ 上記の規約・章立て・命名・表記・品質基準を“そのまま”適用すること。解釈が曖昧な場合は質問リストに挙げて確認を求めること。

【進め方】
- 1セクションを作成したら確認を行い、確認と修正が終わったら次のセクションを作成すること。
- インプットで情報不足しているところは想定で記載せず、対象箇所とともに情報が不足している場合 Issue として確認内容をチャット上で提示してください。

issue例:
{
  "id": 1,
  "workItemType": "Issue",
  "title": "BR-R006：承認金額閾値",
  "description": "<h3>確認事項</h3><ul><li>承認金額の閾値</li><li>承認ルートの段階数</li><li>各閾値における承認者の役職・権限</li></ul>",
  "priority": 2,
  "tags": "1.1.1; ビジネスルール; 承認",
  "state": "Doing",
  "url": "https://dev.azure.com/y-myzk/_apis/wit/workItems/1"
},

【出力】
- specs/requirements.md

Issue を指定フォーマットで得られなかったため、変換を指示しました。

Issue を以下のフォーマットに従い、チャット上に出力し直してください。
{
  "id": 1,
  "workItemType": "Issue",
  "title": "BR-R006：承認金額閾値",
  "description": "<h3>確認事項</h3><ul><li>承認金額の閾値</li><li>承認ルートの段階数</li><li>各閾値における承認者の役職・権限</li></ul>",
  "priority": 2,
  "tags": "1.1.1; ビジネスルール; 承認",
  "state": "Doing",
  "url": "https://dev.azure.com/y-myzk/_apis/wit/workItems/1"
},

steering/structure.mdで指定した作成順序で、最初に指定されている1. 要件一覧(Requirements List)の章が作成され、指定したフォーマットでissue一覧が得られました。
続いて、MCP を使って ADO Boards に登録します。

このチャット上に出力されている JSON 配列の Issue リストを、MCP 経由で Azure DevOps Boards に登録してください。

各オブジェクトの内容を以下の項目に対応させて Work Item を作成します：
- workItemType → Work Item Type
- title → Title
- description → Description（HTMLは保持）
- priority → Priority
- tags → Tags（セミコロン区切りで登録）
- state → State

本手順では autoApprove に登録系を含めていないため、作成ごとに内容を確認し、Accept ▶ をクリックしてissueの登録を進めます。

すべての登録完了を確認できました。

次に、Issue #31（承認金額閾値とルート定義） の要件が確定した想定で ADO Boards を更新します。

Kiro から MCP を使って更新済み Issue の情報を取得し、requirements.md に反映します。

Issue #31 について要件が確定したため、MCP 経由で Azure DevOps Boards から情報を取得し、requirements.md に反映してください。

要件一覧に反映されたことを確認します。

最後に、ADO Boards 上の Issue #31 の State を Done に変更します。

6. まとめ

本記事では、Kiro を活用したウォーターフォール開発における要件定義プロセスを試してみました。steering フォルダに作業手順やドキュメント構造を定義することで、一貫性のある要件定義を出力でき、MCP を介して Kiro と Azure DevOps Boards を連携させることで、要件定義ドキュメントの作成と課題管理を統合的に運用できる実践的なワークフローが確認できました。

良かった点

インタラクティブな作業進行：次に実施すべき作業を提案してくれるため、対話的に要件定義を進められました。AI コーディングアシスタントの中でも、特に「人間と協働している」感覚が強い印象でした。
規約への高い準拠性：プロンプトや steering ファイルの指示に忠実に従い、章立て・命名規約・記載内容の一貫性を保った出力が得られたと感じました。
MCP によるツール連携：Azure DevOps との統合により、Issue 管理と要件定義ドキュメントがかなりシームレスに連携ができました。MCPのautoApprove設定で、自動と半自動を設定できるのもGoodでした。

運用上の考慮点

セッション管理：チャット上でインタラクティブに作業を進めるため、セッションを閉じた後の作業再開時に文脈を復元する工夫が必要そうです。
並行作業時の識別性：複数のセッションで異なる作業を進める場合、セッション名やタグで作業内容を明示できると管理しやすくなると感じました。
大規模ドキュメントの分割：要件定義の分量がある程度多い場合は、単一の requirements.md ではなく、サブシステム単位や章単位でファイルを分割し、複数人での並行作業時のコンフリクトを回避したほうが良いと感じました。