企業AIプロジェクトWiki

開発・テストから本番運用へ進む際に区別すべき環境、バージョン、デプロイ、リリースの概念です。

1. 01ステージング環境ステージング環境とは、本番投入前に、本番候補の成果物、環境設定、正式なデプロイ経路を最終確認する管理された非本番環境です。リリースリスクに関係する本番条件をできる限り再現しながら、実ユーザー、本番データ、不可逆な業務操作から分離し、設定、権限、通信、依存、移行、起動、観測の問題を稼働前に発見します。項目を見る→
2. 02テスト環境テスト環境は、テスター、開発者、自動化プログラムが識別可能なバージョンを実行し、期待結果を検証するための管理された非本番環境です。設定、データ、依存先、アクセス権、リセット方法を明確にし、実ユーザーや本番データに影響を与えず、問題を発見、記録、再現、再テストできるようにします。項目を見る→
3. 03デプロイデプロイとは、識別可能なSoftware／System Versionを、管理された手順で指定対象環境へ導入、設定、更新し、依存、DB、権限、起動、Health、記録を確認して期待する実行状態を作る過程です。完全なデプロイは入力Artifact、Target、実行手順、変更結果、検証証拠、失敗時の停止・復旧を説明でき、「FileをUploadした」だけでは完了しません。項目を見る→
4. 04バージョン番号バージョン番号とは、変化する対象の特定状態を区別、参照、順序付け、他状態と関連付けるため、合意された規則に従って付与する識別子です。有効な案件バージョン番号は、明確な対象と変更記録へ遡れなければなりません。同じ番号が別内容を指したり、番号変更と対象を結び付けられなければ、配備、検収、Rollback、障害調査を支える識別子ではなく表示文字にすぎません。項目を見る→
5. 05ユーザー受入テスト環境（UAT環境）ユーザー受入テスト環境（UAT環境）とは、権限を与えられた業務利用者、顧客代表、その他の受入責任者が、合意済みの業務シナリオと検収基準を用いて、一意に特定できる候補版を正式に業務評価する非本番環境です。対象業務を代表する設定、権限、データ、依存先を用意し、許可のない実業務への副作用を防ぎ、入力、実結果、問題対応、最終判断まで追跡できる記録を残します。項目を見る→
6. 06リリースリリースとは、識別可能なソフトウェアのバージョン、機能または設定を、指定時刻に所定の経路で明確な対象者が取得・閲覧・利用できる状態にすることを組織が承認し、その影響を確認する統制された過程です。変わるのは利用可能性と公開範囲であり、Traffic Route、Feature Flag、利用権限、Download Channel、Store配信などで実施できます。デプロイと同時である必要はありません。項目を見る→
7. 07ロールバックロールバックとは、変更によって許容できない結果が生じた後、事前に定めた順序で新たな統制変更を実行し、影響を受けたComponentを既知の正常・検証済み・互換状態へ戻し、変更期間中に生じたDataと外部影響を照合する過程です。旧Processの起動ではなく、Service、Data、権限、業務Flow、観測指標が規定の復旧状態に達した時に完了します。項目を見る→
8. 08環境分離環境分離とは、あるライフサイクル環境の人、プログラム、データ、資格情報、変更、障害が、明示的に許可された管理経路なしに別環境へアクセス、変更、影響することを防ぐ境界と統制の組合せです。計算資源だけでなく、権限、通信、データ流通、秘密、配備先、共有サービス、ログを制限し、試験と監査証拠で実効性を確認します。項目を見る→
9. 09実行環境実行環境とは、指定したソフトウェア成果物を起動し、処理を実行し、必要な資源と通信させる実際の技術条件の集合です。一般に、プロセッサとOS、言語またはアプリケーションランタイム、システムとアプリの依存関係、起動方法、設定と秘密情報、IDと権限、ネットワークとストレージ、資源制限、実行中に利用する外部サービスを含みます。同じコードでも、これらの条件が実質的に異なれば、動作、性能、セキュリティ結果が変わる可能性があります。項目を見る→
10. 10本番環境本番環境は、実際のユーザー、業務データ、業務操作を正式に扱うための運用条件全体です。サーバーやデプロイ済みコードだけを指すのではなく、アクセス経路、コンピュートとランタイム、ネットワーク、データストア、IDと権限、設定と秘密情報、外部依存、監視とアラート、バックアップと復旧、さらに継続運用を担う人と手順を含みます。項目を見る→

案件要件を、実行・証拠化・承認できるテストと検収の条件へ変える方法を説明します。

1. 01検収基準検収基準とは、指定した成果物またはバージョンを受け入れられるか判断するため、関係者が事前に合意する検証可能な条件です。対象、適用場面、期待結果、許容範囲、検証方法、必要な証拠、判定権限を定め、その場の感覚ではなく記録に基づいて合否を決められるようにします。項目を見る→
2. 02検収対象版（Acceptance version）検収対象版とは、検収Cycle開始前に案件の権限者が正式指定し、検収範囲、環境、基準、証拠へ結び付けたSolution Configuration Baselineです。Application Artifact、設定、DB変更、Interfaceと依存先、必要なデータ状態、文書、企業AIのModel、Prompt、Knowledge、Toolを列挙し、全参加者が同じ対象を試験できるようにします。実質変更は新Baselineとし、影響に応じて再テスト範囲を判断します。項目を見る→

案件で実施することと実施しないことを定め、見積、日程、検収、変更管理の共通境界を作る方法を説明します。

1. 01プロジェクトスコーププロジェクトスコープとは、特定の版で関係者が承認した納品境界です。今回、どの利用者と業務場面に何を届けるか、必要な作業・システム・データ・環境をどこまで含めるか、誰が何を担うか、何をもって完了とするか、何を明確に対象外とするかを定め、見積、日程、要員、検収、変更判断の共通基準にします。項目を見る→
2. 02第1フェーズのスコープ第1フェーズのスコープとは、案件全体の目標のうち、最初に合意した段階で実施することを正式に承認した目標、利用者・業務場面、成果物、必要作業、技術・データ境界、責任、費用、完了条件の集合です。本期の対象外、後続へ延期する事項、外部作業への依存も示します。独立したベースラインとして見積、日程、実施、検収ができ、段階終了時に継続、調整、再実施、停止を判断できます。項目を見る→
3. 03変更要求変更要求とは、識別された文書、成果物、またはベースラインの修正を提案する正式な記録です。現状と提案状態、理由、影響、選択肢、判断権限、実施・検証条件を結び、約束や管理対象システムを変える前に必要性、価値、安全性を判断し、決定後に関係するベースラインを整合させます。項目を見る→

実際の役割がどの条件で業務を完了し、その場面をスコープ、要件、設計、検収へどう結び付けるかを説明します。

1. 01システム要件システム要件とは、境界を明示した対象システムに配分され、所定条件下で満たすべき振る舞い、性能、インターフェース、情報、品質または制約を規定する、必要性、一義性、実現可能性、検証可能性、追跡可能性を備えた規範的記述である。承認済み要件の集合が、設計配分、実装検証、変更管理、引渡し証拠の基準となる。項目を見る→
2. 02ステークホルダー要件ステークホルダー要件とは、明確なライフサイクルと運用文脈で、識別したステークホルダー分類が必要とするサービス、相互作用、品質、情報、統制または制約を、調整済み、追跡可能、検証可能で権限確認済みの規範的記述へ変換したものです。上流のニーズ・期待をシステム要件へ接続し、解決策の妥当性確認基準になります。項目を見る→
3. 03ユーザーニーズユーザーニーズとは、利用者または利用者群が明確な利用文脈で意図した結果を得るために必要とする、特定解決策から独立した前提です。誰がどの状況で何を完了・理解する必要があり、なぜその結果が重要で、現在何が妨げているかを示し、スコープ、ユーザー要件、設計、コンテンツ、支援、妥当性確認の根拠になります。項目を見る→
4. 04ユーザーロールユーザーロールとは、サービスを直接利用する、またはその業務結果に関与する人々を、共通の目標、責任、タスク、利用文脈によって整理した安定した抽象です。その人々がなぜシナリオに入り、何を知り何を完了し、どの業務判断を行え、誰へ引き継ぎ、どの条件に制約されるかを示し、個人名やシステムアカウントを要件の代わりにしません。項目を見る→
5. 05ユーザー要件ユーザー要件とは、ユーザーニーズ、利用者の能力、利用文脈から導出した、システム利用方法と利用結果の品質に関する規定・検証可能な要件の集合です。目標達成のため利用者がシステムとどのように情報交換できる必要があるか、指定利用者、タスク、環境において結果がどの程度有効、効率的、安全、アクセシブル、満足できる必要があるかを示します。項目を見る→
6. 06機能要件機能要件とは、指定したシステム階層に配分され、明示条件下でシステムが何を受領、検証、変換、保存、検索、計算、判断、制御、表示、送信、記録、阻止または復旧すべきかを、境界外から観測または検証できる結果とともに規定する規範的記述である。必要、原子的、一義的、実現・検証可能で、双方向追跡できる必要がある。項目を見る→
7. 07業務シナリオ業務シナリオとは、明確な業務文脈の中で、一つ以上の役割が識別可能な結果へ到達するまでの作業を、有界な一本の流れとして表したものです。トリガーと前提条件から始まり、人、システム、第三者が情報を使い、判断し、引き継ぎ、例外を処理する方法を説明して、確認可能な終了状態まで進みます。適用範囲、頻度、規模、リスク、制約も記録します。項目を見る→
8. 08業務ルール業務ルールとは、業務概念を定義し、許容される状態・行動を制約し、または既知の事実から業務上の結論を導くために、組織が制定・採用・執行する管理可能な記述です。人とシステムが一貫して判断、実行、説明、再確認できるよう、権威ある根拠、適用範囲、入力事実、結論、例外、優先関係、版を明確にします。項目を見る→
9. 09業務要件業務要件とは、確立した業務目的を達成するために組織が獲得すべき能力、業務成果、または上位制約を表す管理可能な記述です。問題・機会をスコープ、ステークホルダー／ユーザー要件、業務ルール、解決策要件、検証、便益測定へ結びながら、特定製品、供給者、画面、アルゴリズムから適度に独立させます。項目を見る→
10. 10性能要件性能要件とは、指定システム対象が指定機能を実行するときの速度、遅延、期限、処理量、同時実行、処理規模、容量または資源利用を量的に規定する規範的記述である。負荷、データ、環境、測定境界、統計、閾値、許容失敗を併記し、再現、検証、配分、追跡、変更管理を可能にする。項目を見る→
11. 11非機能要件非機能要件とは、システム、製品、サービスまたは運用環境の品質特性、必要品質水準、根拠ある実装・運用制約に関する規範的記述である。機能がどの対象、文脈、負荷、期間、リスク条件でどの測定可能な応答を示すか、またはどの境界を守るかを定め、検証、追跡、配分、変更管理ができる必要がある。項目を見る→