この記事は下記サイトの記事を日本語訳したものです。
はじめに
要件は、システムが何を行うべきかを定義し、実装、検証、およびコンプライアンスの基盤を提供します。製品が進化するにつれて、要件はモジュール、ストリーム、ベースライン、変更セット、テスト成果物、実装作業項目などに分散されるようになり、それらの完全なコンテキストや影響を理解することがますます困難になります。
要件エンジニア、ビジネスアナリスト、アーキテクト、コンプライアンスチーム、リリースマネージャーは、次のような質問に頻繁に答える必要があります：
リリース間で何が変更されたのか？
- 提案された変更によってどの成果物が影響を受けるのか？
- 要件はどのように実装され、検証されているのか？
- 再利用可能な既存の要件はあるのか？
これらの質問に答えるには、多くの場合、複数のエンジニアリング・ライフサイクル管理（Engineering Lifecycle Management）アプリケーションにまたがって、情報を手動で検索し、トレースし、関連付ける必要があります。
Engineering AI Hub 1.3 は、この体験を変革します。Model Context Protocol（MCP）ツールを通じて、AIアシスタントは要件データおよびライフサイクルの関連情報へ、ガバナンスされたアクセスを得ることができ、信頼できるエンジニアリング情報に対して自然言語で操作できるようになります。単に成果物を取得するだけでなく、AIアシスタントはコンテキストの発見、変更の分析、トレーサビリティの理解、さらには複数ステップのワークフローの実行が可能となり、チームがより適切なエンジニアリング判断を下すのを支援します。
注記： 本記事の例では、AIアシスタントとして IBM Bob を使用しています。ただし、ここで説明されているワークフローや機能は、IBM Engineering AI Hub 1.3 の MCPツールによって実現されており、MCPに対応したあらゆるAIアシスタントやAI対応IDEから利用可能です。
習得できること
本記事のシナリオでは、Engineering AI Hub の MCP ツールによって、AIアシスタントが次のことを可能にする様子を示します：
- プロジェクト、コンポーネント、モジュール、構成全体にわたる要件のコンテキストを発見し理解する
- ストリーム間で要件を比較し、意味のある差異を説明する
- 変更セットを分析し、エンジニアリングへの影響を要約する
- 要件、検証成果物、実装作業の関係をトレースする
- 変更が導入される前に下流への影響を評価する
- 既存のエンジニアリング知識に基づいて新しい要件を生成する
- エンジニアリング分野全体にわたるライフサイクルのトレーサビリティを確立する
- 単一の対話型リクエストを通じて、複数ステップの要件ワークフローを実行する
前提条件
開始する前に、以下が揃っていることを確認してください：
- プロジェクト領域、モジュール、および要件成果物にアクセス可能な IBM Engineering DOORS Next Requirements Management 7.0.3 以降
- IBM Engineering AI Hub 1.3
- IBM Bob や MS Copilot などの MCP対応AIアシスタント が、ELM AI Hub MCPサーバーで構成されていること
（「AIアシスタントでのMCPサーバー設定」および「個人アクセストークンの管理」を参照） - テスト成果物および関連するエンジニアリング成果物にアクセスするための 適切な権限
- プロジェクトの 型システムおよび構成に関する基本的な理解
本記事で示されている例は、AIアシスタントと DOORS Next MCPツール間の典型的なやり取りを示しています。実際のプロンプトや応答は、使用するAIアシスタント、プロジェクト構成、利用可能なテストデータ、およびユーザー入力によって異なる場合があります。
シナリオ1：ストリーム間での要件比較
要件がリリース間で進化するにつれて、ステークホルダーは何が変更されたのかを理解し、リリース承認前にそれらの変更の影響を評価する必要があります。構成管理により異なるストリームへのアクセスは可能ですが、構成間で要件を手動で比較する作業は時間がかかり、複数の成果物を個別に確認する必要がある場合があります。
Engineering AI Hub の MCPツールを使用することで、AIアシスタントはストリーム間で要件を比較し、変更点を特定し、差異を強調表示し、それらの変更の影響を要約できます。
質問（Ask）
「Test1 Banking（Requirements Management）コンポーネントにおいて、Release 1.a と Release 2.a のストリーム間で要件 21411 と 21412 を比較してください。
要件の内容、属性、およびバージョンの差異を特定してください。
各要件について：
- Release 1.a のバージョンを表示する
- Release 2.a のバージョンを表示する
- 具体的な変更点を強調表示する
- 変更の影響を説明する
また、Release 2.a で導入された変更の要約を提供してください。」
何が行われるか（What happens）
DOORS Next の MCPツールを使用して、要件エンジニアは次の処理を行います：
- 両ストリームから要件の各バージョンを取得する
- 要件の内容、属性、およびライフサイクルメタデータを比較する
- 追加・削除・変更を特定する
- 各変更のエンジニアリング上の意味を説明する
- 単なる差分レポートではなく、リリース視点での要約を作成する
出力例（Example output）
典型的な応答は、以下のような複数レイヤーの分析を組み合わせたものになります：
- 選択したストリーム間における要件変更の要約
- 変更・追加・削除された要件の特定
- 要件の内容、属性、バージョンの並列比較
- 重要な変更のエンジニアリング上の意味の説明
- 新たに追加された機能や影響を受ける機能領域の特定
- 要件変更がリリース全体に与える影響の総合評価
以下の図は出力の一部を示しています：
図1.1～1.3：2つのストリーム間で差異のある要件を特定し、それらの内容およびメタデータを比較した結果
図1.4～1.5：変更分析およびリリースレベルの要約を示し、対象ストリームで導入された最も重要な要件更新を強調した結果
図1.1：要件比較レポート
図1.2：要件分析の要約
図1.3：2つのストリーム間での要件の比較
図1.4：変更の要約
図1.5：変更の影響
なぜ重要なのか（Why it matters）
リリースの意思決定は、多くの場合時間的な制約の中で行われますが、要件の変更は新しい機能を導入したり、システムの動作を変化させたり、意図しない下流への影響を引き起こす可能性があります。
Engineering AI Hub は、ストリーム間の有意な差異を自動的に特定し、それを分かりやすく説明することで、ステークホルダーが「変更点を探すこと」ではなく「変更の意味を理解すること」に集中できるようにします。
これにより、チームはより情報に基づいたリリース判断を行うことができ、ステークホルダー間の認識の整合性を向上させるとともに、予期しない変更が本番環境に持ち込まれるリスクを低減できます。
シナリオ2：変更セット内の要件変更のレビュー
要件の変更セットを承認する前に、ステークホルダーは、その変更に含まれる修正の範囲と意図の両方を十分に理解しているという確信が必要です。要件を1つずつ個別にレビューする方法は時間がかかり、変更セット全体にわたるパターンやリスクを把握しにくくなる可能性があります。
Engineering AI Hub の MCP ツールは、変更セットを一つのエンジニアリング変更パッケージとして分析し、変更された要件を特定し、バージョンを比較し、更新の目的を説明し、その全体的な影響を要約することができます。
質問（Ask）
「Release 1.1 ストリームから『CS-101 Security Enhancements』変更セットを取得し、各変更の根拠と影響を含めて、すべての要件変更を要約してください。」
何が行われるか（What happens）
DOORS Next の MCPツールを使用して、要件エンジニアは以下を実行します：
- 指定された変更セットを取得する
- 影響を受ける要件を特定する
- 変更前と変更後のバージョンを比較する
- 各修正の目的を要約する
- 追加レビューが必要な領域を強調する
出力例（Example output）
典型的な応答は、以下のような複数レイヤーの変更分析を組み合わせたものになります：
- 選択した変更セットと、それに含まれる成果物の概要
- 変更セット内で修正された要件の特定
- 影響を受けた要件の更新前・更新後バージョンの比較
- 各修正の意図と範囲を説明する要約
- 追加のレビューや検証が必要となる可能性のある変更の特定
- 変更セット全体がエンジニアリングに与える影響の統合的な評価
以下の図は出力の一部を示しています：
図2.1～2.3：変更セットの取得および変更された要件の特定結果
図2.4：詳細な変更比較と、変更セット内の更新の目的・範囲・影響を説明する生成された要約
図2.1：変更セット分析の結果
図2.2：変更の要約
図2.3：変更内容の詳細
図2.4：変更セットの要約
なぜ重要なのか（Why it matters）
変更セットを承認するには、レビュー担当者が「何が変更されたのか」だけでなく、「なぜ変更されたのか」、そして「どのような影響があるのか」を理解しているという確信が必要です。
Engineering AI Hub は、コンテキスト、根拠、影響分析を提供することで、変更レビューを単なる成果物の確認作業から、十分な情報に基づいたエンジニアリング上の議論へと変革します。
これにより、レビューの迅速化、ガバナンスの向上、そして重要な変更が承認前に適切な注意を払われるという確信の向上が実現されます。
シナリオ3：エンドツーエンドのトレーサビリティを伴う規制コンプライアンス要件の作成
組織では、新たなコンプライアンス要件が導入されることが多く、それらは既存のポリシー、実装計画、検証活動と整合している必要があります。これらの要件を作成し、必要なライフサイクルのトレーサビリティを確立するには、通常、複数の分断されたステップとチーム間の手動調整が必要となります。
Engineering AI Hub の MCPツールは、再利用可能なパターンを特定し、新しい要件を生成し、適切なモジュール内に作成し、さらに単一のワークフローの中で実装および検証のトレーサビリティを確立することができます。
質問（Ask）
「JKE Banking Requirements Management プロジェクトの New_Module_Test モジュール内の要件 21401 および 21402 をレビューしてください。
既存の顧客データ保持および顧客データ暗号化に関する要件を分析し、共通の規制コンプライアンスパターンを特定してください。
この分析に基づき、顧客データ保持と暗号化制御を単一の規制コンプライアンス要件として統合した新しい要件を作成してください。
特定したコンプライアンスパターンに基づいて新しい要件成果物を作成し、New_Module_Test の成果物フォルダーに配置してください。
要件作成後、以下へのリンクを設定してトレーサビリティを確立してください：
- 作業項目 460 「Customer Data Regulatory Compliance Initiative」に対する Implemented By 関係
- テストケース 129 「Customer Data Compliance Validation Test Scenario」に対する Validated By 関係
以下の内容の要約を提供してください：
- 分析した要件
- 特定されたコンプライアンスパターン
- 新規作成された要件
- 成果物の保存場所
- 確立されたトレーサビリティリンク
- 対応した規制コンプライアンスの目的」
何が行われるか（What happens）
DOORS Next の MCPツールを使用して、コンプライアンスリードは以下を実行します：
- 関連するコンプライアンス要件を分析する
- 再利用可能なパターンおよび制御を特定する
- 新しい要件を生成する
- 指定された成果物フォルダーに新しい要件成果物を作成する
- 実装および検証のトレーサビリティリンクを確立する
- ライフサイクルカバレッジの要約を作成する
出力例（Example output）
典型的な応答は、以下のような要件生成およびトレーサビリティ分析の複数ステップを組み合わせたものになります：
- 参照として使用された元要件の分析
- 共通のコンプライアンスパターンおよび再利用可能な要件表現の特定
- 特定されたコンプライアンス目的に沿った要件案の生成
- 新たに生成された要件の作成詳細
- 実装および検証成果物へのトレーサビリティリンクの確認
- 既存のコンプライアンス要件に基づく新規要件成果物の作成と、指定されたフォルダーへの配置
以下の図は出力の一部を示しています：
図3.1および3.2：既存のコンプライアンス要件の分析と再利用可能なパターンの特定結果
図3.3：DOORS Next 上で生成された要件、確立されたライフサイクルトレーサビリティリンク、およびアシスタントによって生成されたコンプライアンスカバレッジの要約
図3.1：分析結果
図3.2：変更の要約
図3.3：DOORS Next における新規要件の表示
なぜ重要なのか（Why it matters）
要件の作成は課題の一部に過ぎず、それらが実装や検証活動と適切に結び付けられていることが同様に重要です。
Engineering AI Hub は、一貫性、トレーサビリティ、コンプライアンスへの対応力を維持しながら、要件作成のスピード向上を支援します。要件を初期段階からエンジニアリングライフサイクル全体に結び付けることで、組織はカバレッジの抜け漏れを減らし、監査可能性を向上させ、規制要件を実行可能なエンジニアリング成果へと確実に落とし込むことができます。
シナリオ4：オプトアウトプロジェクトにおける要件更新前の影響分析
要件の変更は、その要件自体を超えて広範な影響を及ぼす可能性があります。変更を導入する前に、どの要件、テスト、実装作業、および依存関係に影響が及ぶ可能性があるのかを理解し、安全かつ予測可能に変更を管理する必要があります。
Engineering AI Hub の MCPツールを使用すると、AIアシスタントはライフサイクルの関連関係を分析し、影響を受ける成果物を特定し、依存関係チェーンを評価し、フォローアップアクションを推奨し、適切な変更管理の構造を準備することができます。
質問（Ask）
「要件 21404 の非アクティブタイムアウトを15分から10分に短縮したいと考えています。
変更を行う前に、この要件にリンクされているすべての影響を受ける要件、テストケース、実装作業項目を特定してください。
影響を受ける可能性のある親子関係の要件も含めてください。
どの成果物がレビューや更新を必要とする可能性があるかを説明する影響分析を提供してください。
その後、「CS-102 Authentication Timeout Update」という名称の要件変更セットを作成し、要件の変更準備を行ってください。」
何が行われるか（What happens）
DOORS Next の MCPツールを使用して、要件エンジニアは次のことを実行します：
- 影響を受けるライフサイクル成果物を特定する
- 依存関係を分析する
- 下流への影響を評価する
- レビューおよびフォローアップアクションを推奨する
- 変更セットを作成し、準備する
出力例（Example output）
典型的な応答は、以下のような複数レイヤーの影響分析および変更管理分析を組み合わせたものになります：
-提案された要件変更の概要
-影響を受ける要件、テスト成果物、実装作業項目の特定
-親子関係にある要件や依存関係チェーンの分析
-エンジニアリングおよび検証における下流影響の評価
-レビュー、更新、関係者関与に関する推奨事項
-要件の変更を管理するための変更セットの作成および準備
以下の図は出力の一部を示しています：
図4.1～4.2：影響を受けるライフサイクル成果物の特定および依存関係分析の結果
図4.3～4.5：生成された影響評価、推奨されるフォローアップアクション、および提案された更新を管理するための変更セット作成の結果
図4.1：リンク分析の結果
図4.2：影響評価
図4.3：推奨されるアクション
図4.4：変更セット作成の要約
図4.5：DOORS Next における作成された変更セットの表示
なぜ重要なのか（Why it matters）
要件変更のコストは、その要件自体に限定されることはほとんどありません。変更は多くの場合、設計、実装、テスト、コンプライアンス活動にまで波及します。
Engineering AI Hub は、変更を実施する前にこれらの影響を理解できるよう支援し、より予測可能な変更管理を可能にするとともに、依存関係の見落としのリスクを軽減します。
これにより、より高品質な意思決定が促進され、手戻りを最小限に抑えつつ、システムの複雑化が進む中でも組織が適切にコントロールを維持できるようになります。
シナリオ5：トレーサビリティを通じた要件変更影響の分析
トレーサビリティ関係は、要件が実装、検証、およびその他のエンジニアリング成果物とどのように結び付いているかを示します。この情報は意思決定にとって非常に重要ですが、そこから有意義な洞察を得るには、複数のツールやビューを横断する必要があり、手間がかかることが一般的です。
Engineering AI Hub の MCPツールを使用すると、AIアシスタントはライフサイクルの関係をたどり、依存関係を説明し、影響を受ける成果物を特定し、要件がシステム全体にどのような影響を与えるかをエンジニアリング視点で可視化できます。
質問（Ask）
「要件 21404 を変更した場合の影響を分析してください。
この変更によって影響を受ける可能性のある、すべての下流の要件、テストケース、実装作業項目を特定してください。
各影響対象の成果物について：
- 成果物の識別子を表示する
- 要件 21404 との関係を表示する
- なぜレビューや更新が必要になる可能性があるのかを説明する
全体的な影響評価を提供してください。」
何が行われるか（What happens）
DOORS Next の MCPツールを使用して、要件エンジニアは以下を実施します：
- ライフサイクルの関係をたどる
- 関連するエンジニアリング成果物を特定する
- 依存関係を説明する
- リスクやレビューが必要な領域を評価する
- エンジニアリング影響評価を作成する
出力例（Example output）
典型的な応答は、以下のようなトレーサビリティおよび依存関係分析の複数レイヤーを組み合わせたものになります：
- 対象要件の概要と、ソリューション内での役割の説明
- 下流の要件、検証成果物、実装作業項目の特定
- 各成果物が要件とどのように関連しているかの説明
- 要件変更時に想定されるリスクおよびレビューが必要な領域の分析
- 検証および実装カバレッジの評価
- ライフサイクルトレーサビリティ情報に基づく全体的なエンジニアリング影響の要約
以下の図は出力の一部を示しています：
図5.1～5.3：ライフサイクル関係の探索および関連するエンジニアリング成果物の特定結果
図5.4～5.5：生成された依存関係分析、影響評価、およびトレーサビリティ要約（要件の変更が下流の実装および検証活動にどのように影響するかの説明）
図5.1：影響分析の結果（要件）
図5.2：影響分析の結果（テストケース）
図5.3：影響分析の結果（作業項目）
図5.4：全体的な影響評価
図5.5：推奨されるアクション
なぜ重要なのか（Why it matters）
トレーサビリティは、エンジニアリングにおける知識源の中でも最も価値が高いものの一つでありながら、十分に活用されていないことが多い領域です。
Engineering AI Hub は、分断されたライフサイクルの関係情報を実行可能な洞察へと変換することで、その価値を引き出すのを支援します。ステークホルダーは複数のツール間でリンクを手動で辿る必要がなくなり、要件が実装、検証、コンプライアンス活動にどのような影響を与えるかを迅速に理解できるようになります。
これにより、意思決定の質が向上し、ライフサイクル全体のガバナンスが強化されるとともに、変更がエンジニアリング視点での影響を十分に理解した上で評価されることが保証されます。
結論
Engineering AI Hub 1.3 の MCPツールは、AIアシスタントを単なる情報検索ツールから、コンテキストを理解するエンジニアリングの協働者へと進化させます。要件、構成、変更セット、トレーサビリティ関係、検証成果物、実装作業項目へのガバナンスされたアクセスを提供することで、AIアシスタントは相互に関連するエンジニアリングデータを横断的に理解し、実際のエンジニアリング判断を支援する洞察を提供できるようになります。
本記事のシナリオは共通したテーマを示しています。それは、個々の要件管理タスクを単に高速化することではなく、それらのタスクを取り巻く広範なエンジニアリングコンテキストを理解することに価値があるという点です。リリースの影響評価、変更セットのレビュー、新たなコンプライアンス要件の導入、提案された変更の影響評価、ライフサイクル依存関係の理解といった場面において、AIアシスタントは通常であれば複数のツールや成果物に分散している情報を統合して提示できます。
このように、関連付けられたエンジニアリングデータを発見し、分析し、トレースし、活用できる能力は、単なる情報検索を超えた価値をチームにもたらします。これにより、ステークホルダーはより的確な意思決定を行い、リスクを早期に特定し、部門横断の連携を強化し、システムの複雑化が進む中でもより強固なライフサイクルガバナンスを維持できるようになります。
次のステップ（Next Steps）
本記事で紹介したシナリオは、Engineering AI Hub の MCPツールが、エンジニアリングライフサイクルデータに含まれる豊富なコンテキストをAIアシスタントに結び付ける方法のほんの一例に過ぎません。
ぜひ、ご自身のエンジニアリング課題に適用し、自然言語によるやり取りによって、これまで見つけることが難しかった洞察をどのように引き出せるかを探ってみてください。実際に試したシナリオや得られた成果についても、ぜひ共有していただけると幸いです。
また、テスト管理、作業項目、ソースコード管理、その他のエンジニアリング成果物に対して、Engineering AI Hub の MCPツールがどのように活用できるかについては、関連する記事もぜひご覧ください。
AI-assisted Test Management with Engineering AI Hub 1.3 MCP Tools