完全な責任モデルでTaigaを有効にする

組織が求める成果から始める

最後のシナリオは、これまでのレッスンをまとめます。架空の会社は、備品申請サービスでTaigaを有効にしたいと考えています。意図する便益は、業務上のニーズから、レビュー済みのソフトウェアと保守されたproduct知識につながる、繰り返し使える経路です。

期待する成果と、組織に残る作業を定義します。会社がどの事業リスクを受け入れるか、稼働中のサービスに誰が責任を持つかを、ソフトウェアファクトリーが決めるわけではありません。

他のサプライヤーに適用するのと同じ証拠基準を使います。適切な責任者を通じて、選択したサービスの取り決め、データの扱い、責任、サービスからの移行要件を確認します。

Taigaは、組織の設定情報から、初期ポリシーと承認済み技術の表を作成します。適合すると確認する前に、その情報と生成されたポリシーを調べます。ポリシーが生成されたことは、誰かがレビューした証拠ではありません。

三種類のコンテキストを、意図して使い分けます。

コンテキスト	用途
Policies	組織の正式なルール
Instructions	そのルールを、作業に具体的に適用するための指示
Knowledge	インターフェースの仕様、データ定義、連携ガイドなどの参考資料

機密の参考資料は、許可された取り扱いの境界内に保ちます。

指示と知識は、内容が成り立つ最も上位の階層に置きます。組織、factory、productのいずれかです。下位の階層は詳細を追加します。上位のルールを打ち消すものではありません。デザイン標準をレビューし、適切な場合は、実際のデザインシステムのリポジトリを接続します。

インフラコードとCI/CDパイプラインを誰が作るかを決めます。その責任分担に合わせて、Taigaの対応する設定を構成します。実際の実行環境、IDの方式、データサービス、環境、デプロイプロセスを説明します。

備品サービスでは、プラットフォームチームが、クラウドアカウント、本番アクセス、デプロイ承認を引き続き担当します。Taigaの計画は、それらのインターフェースを使う必要があります。環境の説明はコンテキストを提供します。認証情報と権限には、別の管理された設定が必要です。

必須のレビューとデプロイのルールは、それを強制するシステムに設定します。Queueを開始する前に、productの自律動作設定と、initiativeごとの選択を確認します。

インシデント、保守、データの判断、復旧、サプライヤーとの調整に、責任者を割り当てます。運用するアプリケーションの可用性のニーズと、RTO/RPOを定義します。

TaigaのMonitoringは、productの稼働状況を対象にします。組織全体のインフラobservabilityと対応能力に置き換わるものではありません。関連する環境設定と、指摘から対応できる人につながる経路を確認します。

最初のデリバリーを、要件から計画、run、pull request、デプロイまでレビューします。承認されたテストデータで、有用に動作することを検証します。不足する証拠は、不足として記録します。

別のproductやデータ区分を追加する前に、ID、管理策、運用への影響、責任の所在の違いをレビューします。有効な共有コンテキストを再利用し、適用できない前提を修正します。

有用なデリバリー、レビューの作業量、手戻り、運用の結果を、ベースラインに照らして測定します。サービスからの移行演習と見直し日を、運用モデルに含めておきます。

学習の成果は、よりよい問いを立て、根拠のある判断ができることです。現在のワークフローにはTaigaドキュメントを、サービスの広い背景にはtai.gaを使ってください。