サプライヤーに証拠を求める

自社の要件から始める

サプライヤーは、最も重要な問いに答えずに、印象的な成果を示すことができます。デモの前に要件を定義してください。

機密の契約データを持つ架空の会社を考えます。チームが必要としているのは、既存アプリケーションの保守にAIの支援を使うことです。サプライヤーは、空のリポジトリから作った新しいアプリケーションを見せます。その成果は一つの能力を示しますが、会社の保守ワークフローをテストしてはいません。

承認された合成データを使って、小さくても代表的なリポジトリを準備します。既存の規約、失敗するテスト、人の判断を必要とする変更を一つずつ含めます。各サプライヤーに、同じ受け入れ基準を渡します。

要件	求める証拠	解決する問い
データの扱い	データフローの説明、現行の条件、関連する設定	どのコピーが、どのサービスに渡るか
エージェントの権限	権限モデルと、操作が拒否されるデモ	どこで制限を強制するか
デリバリー	計画、diff、チェック、その結果としてのpull request	レビュー担当者が要件を追跡できるか
人の判断	ブロックされたワークフローと、その解決記録	誰が次の段階を承認できるか
運用	責任分担とインシデント対応手順	サービスに障害が起きたとき、誰が対応するか
サービスからの移行	エクスポートのサンプルと独立した再ビルド	アクセス終了後、何が引き続き使えるか

「SSOに対応」という説明にも、背景が必要です。どのIDプロバイダー、契約プラン、役割、利用終了時のアクセス解除動作が含まれるかを尋ねます。関連するアクセス変更をテストします。

保証報告書や認証については、範囲、対象サービス、レビュー期間、例外を確認します。サプライヤーの保証が、チームの作るアプリケーションまで自動的に対象にすると考えないでください。

必須チェックが失敗したときに何が起きるかを、サプライヤーに示してもらいます。その後、生成された成果物と判断の経路を確認します。有用なシステムは、未完了の作業と不足している証拠を明示します。

契約管理アプリケーションでは、アクセス境界を越える架空の要求を追加します。評価では、システムがその要件をどう扱い、レビュー担当者が結果をどう検証するかを示す必要があります。デモを現実的に見せるために、実際の機密データを使わないでください。

デモで示した構成と、購入を提案されている構成の違いを記録します。将来提供すると約束された機能は、提供済みの能力ではなく、依存条件です。

要件ごとに、証拠のリンク、日付、設定、レビュー担当者、結論を記録します。「このシナリオで検証済み」「未解決」「対象外」のように、明確な状態を使います。

未解決の項目には、担当者と期限を割り当てます。各項目について、判断を止めるのか、契約上の条件を求めるのか、制限を文書化して受け入れられるのかを決めます。

同じ基準をTaigaにも適用します。公開ドキュメントとTrust Centreは、確認の出発点になります。選択したサービスの取り決めが、要件を満たすことを確認してください。続いて、サービスからの移行とポータビリティを学んでください。