製品の前に責任を比較する
完了アシスタント、社内のデリバリープラットフォーム、ソフトウェアファクトリーを比較します。それぞれが担う作業と、残る責任を明らかにします。
理解度を確認サプライヤーが、実装とテストの実行を自動化します。業務要件の責任は誰が持ちますか？演習に取り組む
学べること
- 同じ必須の成果に照らして、選択肢を比較する。
- 作業の実行と、その結果への責任の引き受けを区別する。
- 提案された運用モデルの抜けと重複を特定する。
同じ成果を比較する
プロトタイピングのツールを選ぶことと、本番環境の運用モデルを選ぶことは、切り離せます。各自の仕事に合うツールで、アイデアを試せます。それでも組織には、有用な成果を安全にし、デプロイし、保守し、運用するための、支援体制のある方法が必要です。
コーディングアシスタント、社内プラットフォーム、ソフトウェアファクトリーは、それぞれ問題の異なる部分を解決できます。範囲を定義せずにサブスクリプション料金を比較すると、判断を誤るおそれがあります。
まず、必要な成果を定めます。会社のデータ、セキュリティ、信頼性の要件に従って、社内サービスを提供し、運用することです。その上で、ライフサイクル全体に必要な作業を特定します。最初のデモが成功した後の作業も含めてください。
架空の契約管理サービスでは、承認された要件、従業員のアクセス、非公開のレコード、検証されたリリース、インシデント対応、継続的な更新が必要です。エンドポイントを生成するツールが対応するのは、この一覧の一部です。
考えられる三つの運用モデルを記述する
コーディングアシスタントを使うモデルでは、開発者は既存のエンジニアリングシステム内でAIを使います。周辺のプロセス、連携、プラットフォーム機能、証拠の収集は、組織が提供します。成熟した共有サービスを持つ組織に適している場合があります。
社内で組み立てるデリバリーシステムでは、組織がエージェント、コンテキスト、チェック、デプロイ、運用からのフィードバックを統合します。設計を管理できる一方で、その統合された製品、サポート、アップグレードにも責任を持ちます。
ソフトウェアファクトリーを購入するモデルでは、サプライヤーが、より広い範囲のつながったワークフローを提供します。実際の範囲と、対応する連携を検証してください。組織には、引き続き製品に関する判断と、明示的な責任分担が必要です。
これらは比較用のモデルであり、すべての製品に共通する分類ではありません。特定のサプライヤーや社内プラットフォームは、異なる形で機能を組み合わせる場合があります。
プロトタイプから稼働するサービスまでの経路を検証する
各選択肢に、同じ具体的なシナリオを使います。銀行のプロトタイプでは、合成トランザクションと、本番への権限がない状態から始めます。アクセスを広げる前に、次の能力をチームまたはサプライヤーに実証してもらってください。
- プロトタイプを評価し、変更または置き換えが必要なコードを特定する。
- 必要なインフラにデプロイする。ポリシーで求められる場合は、自社のクラウドアカウントを使う。
- アプリケーションの権限、シークレットの扱い、開発時と実行時のデータフローを検証する。
- 適用される要件に対する証拠を作り、リリースの判断を記録する。
- サービスを監視し、脆弱性を修正し、復旧をテストし、インシデントに対応する。
コードを自社アカウントに移すことは、この作業の一部です。環境を管理できる人と、外部サービスにデータが渡る場所を検証します。管理策を自社の義務に合わせてください。デプロイ先だけで、コンプライアンスが成立するわけではありません。
サプライヤーが示す責任境界の一例として、Taigaの責任共有の説明を、自社の責任分担表と比較してください。これは、このサイトの発行元が所有する資料です。Taigaを有効にする前に、適用される契約と設定を検証してください。
実行、確認、判断を分ける
各作業について、実行する主体、結果を検証する主体、その結果への責任を引き受ける主体を記録します。一つの主体が複数の役割を持つことはできますが、空欄の役割は責任分担の抜けです。
| 作業 | 責任分担表で確認する問い |
|---|---|
| 要件 | 曖昧な業務ルールを誰が確定するか |
| データの扱い | 受領者と処理条件を誰が承認するか |
| 実装 | 受け入れ後の生成コードを誰が保守するか |
| 検証 | 証拠が実際のリリースを対象としていることを誰が確認するか |
| デプロイ | 誰のIDが、どの環境を変更するか |
| 運用 | サービスに障害が起きたとき、誰が対応するか |
| プラットフォームの更新 | 依存先が変わったとき、誰が連携を調整するか |
クラウドサービスでも、提供者と顧客の間で責任を分担します。正確な分担は、サービスによって異なります。すべてのマネージド製品の境界が同じだと考えず、詳細な分担表を求める理由にしてください。AWSの責任共有。
責任の抜けと作業の重複を探す
プラットフォームチームが承認済みのデプロイ経路をすでに保守しているのに、サプライヤーが別のパイプラインを生成するとします。サプライヤーが既存の経路を使うべきかを判断します。独立して保守する二つのパイプラインは、管理策の競合や不要なコストを生む可能性があります。
逆に、サプライヤーは顧客にインシデント対応チームがあると考え、顧客は運用も含まれると考えているかもしれません。ユーザーがサービスに依存する前に、その抜けを解消します。
CNCFのプラットフォームガイダンスでは、社内の機能とマネージドな機能を組み合わせられます。重要なのは、その結果得られる体験が、責任の所在を明確にしながらユーザーのニーズを満たすかどうかです。CNCFのガイダンス。
商業上の判断に責任分担表を使う
評価の記録に責任分担表を添付し、適用される契約で明確にします。自社に残る作業の費用を見積もります。コンポーネント間の接続を保守するコストも含めてください。
広い範囲を担うサプライヤーは、統合作業を減らし、ライフサイクル全体で証拠を保つ場合に価値があります。独自の要件が、継続して自社で責任を持つことに見合うなら、社内方式に価値があります。必要な成果と、検証した範囲に基づいて判断してください。
演習に取り組む
コーディングアシスタント、社内で組み立てるデリバリーシステム、購入するソフトウェアファクトリーの三列を作ってください。要件、ポリシー、実装、検証、リリース、運用、更新の行を追加します。各作業を実行する人、検証する人、受け入れる人を記録します。不明な項目はすべて明示してください。
ワークシートをダウンロード（Markdown）この選択を解除すると、このブラウザーに保存した進捗がすべて削除されます。
進捗はこのブラウザー内に保存されます。アカウントも追跡もありません。