ガバナンスと IT プログラム管理
コンテキスト
このページでは、GitLab IT プログラムのプログラム手法を説明します。強固な成果と効率的な実行を確保し、イテレーションの価値観に沿った適切なスコーピング、コラボレーションの価値観に沿った適切なステークホルダーの関与、透明性の価値観に沿った法令遵守のための適切なドキュメント管理を実現することを目的としています。
この基準を満たすプログラムの条件
- プログラムが2スプリント（1ヶ月）を超えること
- プログラムが要件定義とテストのために複数部門を必要とすること
- プログラムが SOX システムで動作すること
プログラム開発に従う非 SOX プロジェクト
- 以下の1回限りのプログラム開発コントロールを参照し、ベストプラクティスとして要件に従ってください
- 非 SOX プロジェクトのユーザー受け入れテスト（UAT）の実施方法：
- 高リスク/クリティカルなテストシナリオのみのテストスクリーンショットを取得します。これらは、システムのセキュリティとコア機能を検証するためのテストケースである必要があります。高リスク/クリティカルなテストケースが失敗した場合、システムの運用とビジネスプロセスに重大な悪影響を与えることになります。
- 高リスク/クリティカルなテスト失敗の場合、テスターは自分自身のテストのスクリーンショットを撮るとともに、解決策を文書化するスクリーンショットも取得する必要があります。
*SOX プロジェクトでは、すべての UAT テストシナリオのスクリーンショットを含め、すべての要件が満たされていることを確認してください
プログラムガバナンス
すべてのプログラムには、以下を含むプログラムガバナンスのセットが必要です：
- IT プログラムマネージャー
- ビジネス要件書（BRD）
- プログラムチャーター
- ステアリングコミッティ
- コアチーム
- 運営リズム
- エスカレーションプロセス
- プログラムタイムライン
- データモデルの明確なドキュメント
- コンプライアンスの明確なドキュメント
- 有効化計画
- トレーニング資料
- コミュニケーション計画
- 実装後サポート計画
IT プログラムマネージャー
プログラムには、プログラムガバナンスの構築に責任を持つプログラム DRI が必要です。
ビジネス要件書（BRD）
ビジネス要件書（BRD）は、新しいプログラムを開始するために、プログラム DRI がビジネスリードと共同で最初に作成するドキュメントです。BRD は、なぜそのプログラムが実施されるかを説明し、成功のために新しいプログラムが必要とするすべての詳細を記載したレポートで、ステークホルダーに明確さとコンテキストを提供します。
プログラムチャーター
BRD が完成したら、プログラムチャーターはプログラム DRI が次に作成し、プログラムキックオフ時にすべての関連ステークホルダーに提示するドキュメントです。プログラムチャーターには以下が含まれる必要があります：
1. プログラム目標
SMART（具体的、測定可能、達成可能、関連性のある、時間的に限定された）目標を使用して、プログラム完了時に達成が期待されることを説明します。
2. プログラムスコープ
すべてのタスク、成果物、コスト、期限、および実行チームを含む、プログラムの具体的な目標をリスト化します。
3. 役割と責任
プロジェクトスポンサー、ビジネスリード、プログラム管理オフィス（PMO）チーム、専門家（SME）を含む主要なステークホルダーを明記します。
- プロジェクトスポンサー：最終意思決定者、エスカレーションポイント、リソースキャパシティの確保、プロジェクト作業の推進。
- ビジネスリード：要件の承認者、プロジェクトチームとのソリューション協力、プロジェクト作業の支援と形成。
- PMO：ステークホルダーとの調整、タイムライン管理、要件収集・作業量（LOE）の見積もり。
- 専門家（SME）：プロジェクトの成果物がステークホルダー、法律、ポリシー、基準、ベストプラクティスのニーズを満たすよう、事実と詳細が正確であることを確認する。
4. 初期タイムライン
必要なリソースを含む、開始から終了までのプログラムタイムラインを示します。
5. 主要マイルストーン
プログラム内の重要なイベントまたは分岐決定ポイントを示すすべての参照ポイント。
6. プログラム指標と成功基準
すべてのプログラムには成功指標が必要です。これらの指標は、収益の増加またはコスト削減に役立つ効率の向上のいずれかを示すものでなければなりません。
ステアリングコミッティ
プログラムチャーターの一環として、経営陣によるステアリングコミッティを指名する必要があります。これには、スポンサーとなるビジネス組織の経営幹部と IT の経営幹部が含まれる必要があります。例えば、私たちの経費管理プログラムでは、VP IT、VP コントローラー、VP フィールドオペレーションを含むステアリングコミッティを設立しました。このステアリングコミッティにより、有効化とフロントオフィス、バックオフィス、および IT の経営幹部をカバーしています。
コアチーム
コアチームを設立し、これらのチームメンバーからコミットメントを得る必要があります。これには、PMO チームからのプログラム DRI、ビジネスリード、異なるエリアの SME、BSA（必要な場合）、IT からの技術リソースが含まれる必要があります。プログラムの DRI は、ビジネスから要件収集、UAT テスト、有効化/トレーニングサポートの時間コミットメントを得る必要があります。また、IT チームから設計、開発、機能テストのスプリント時間を得る必要があります。経費管理の場合、私たちは AP のマネージャーをビジネスリードとして指名し、会計、営業、エグゼクティブアドミン全体に SME を配置しました。
ステータスロールアップを含む運営リズム
各プログラムには、コアチームが同期的に会議を行う時間と経営陣が同期的に会議を行う時間を含む運営リズムが必要です。プログラムマネージャーは、タスクの完了を文書化し、GitLab エピックを通じてステータスを報告するための非同期構造を提供する責任があります。
ステータスレポート
大規模プログラムについては、Rolly からの情報に基づき、IT プログラムマネージャーがプログラムチーム全体に共有するステータスレポートを作成することがあります。このレポートは、週次プログラムステータスミーティング中にレビューされることが多いです。
Geekbot
IT プログラムマネージャーは、Geekbot を使用して、専用のプログラム Slack でプログラムの非同期アップデートを共有します。このレポートには以下の質問が含まれます：
- 週終了
- レポートリンク
- これはステータスレポートへのリンクです
- プロジェクトステータス
- 今週の達成事項
- アクションアイテム
- Issue/リスク
- プロジェクトの主要日程
エスカレーションプロセス
プログラム DRI は、プログラムメンバーがブロックされたりサポートが必要な場合に、プログラム DRI やステアリングコミッティに警告できるよう、明確なエスカレーションプロセスを確立する必要があります。
プログラムタイムライン
小さな増分でプログラムを提供できるよう、スプリントが定義された明確なプログラムタイムラインが必要です。主要な要件期限、成果物のマイルストーン、テストタイムラインについて、全員が明確に把握できるようにする必要があります。プログラムタイムラインでは、会社の休日、有効化の時間を考慮し、複雑な要件に対して追加の時間を設けることも検討してください（必要な場合）。
データモデルの明確なドキュメント
技術的なソリューション以外のプログラムの成果物の1つは、新しいシステムまたはプログラムのデータモデルに関するドキュメントです。私たちはこのアプローチを使用しています。
コンプライアンスの明確なドキュメント
さらに、変更管理コントロールと新製品導入コントロールを満たすための明確なドキュメントが必要です。これらはこちらに完全に文書化されています。
これらのプログラムで文書化が必要な関連コントロールは以下の3つです：
変更管理（永続的に存在）
- コントロール - PC2：変更管理ポリシーに従い、変更が適切な担当者によってテストおよび承認されること。
- 変更を行うためのプロセス。
- ベンダーが要求後に所有している場合でも、変更を要求できますか？テスト/承認が必要ですか？
- 多くの場合、変更が最終的にベンダーによって実装される場合でも、その変更を社内で文書化してテストするプロセスを持つ必要があります。SOC 1 または 2 レポートを常にレビューして、私たちの責任を理解する必要があります。
- コントロールを実行する作業をベンダーに割り当てることができますが、コントロールの効果的な実行に対する最終的な責任は GitLab にあります（つまり、ベンダーが GitLab に代わってコントロールを不適切に実行した場合でも、GitLab は SOX コントロールの欠陥を報告する必要がある場合があります）。
プログラム開発 / システムの実装（1回限りのコントロール）
- コントロール - PD1 - マネジメントはプロジェクトリスクとスコーピング、ガバナンス構造、プロジェクト要件、ビジネス要件を評価・定義します。プロジェクトステータスと主要マイルストーンが定義され、主要ステークホルダーに伝達されます。
- コントロール - PD2 - マネジメントはゴーライブ前に適切なユーザー受け入れテスト（UAT）を実施します。テストケースが作成、実行、文書化されます。失敗したテストケースは正式にログに記録され、成功するまで再テストされるか、ゴーライブ後に解決するための承認が得られます。
- コントロール - PD3 - マネジメントは実装/カットオーバー計画を策定し、カットオーバーの主要タスク、システム要件、バックアウト計画を概説します。実装/カットオーバー計画とゴーライブ評価の文書化された承認が、ゴーライブ前に主要ステークホルダーから得られます。
- コントロール - PD4 - データ変換/移行の検証がゴーライブ後に実施され、移行された情報/データの完全性と正確性を評価します。データ検証手順が実施・文書化され、実施したステップ、差異、サポートファイルが含まれます。特定された差異は正式に追跡され、差異がなくなるまで再移行されるか、ゴーライブ後にこれらの差異を解決する計画を持ってゴーライブするための承認が得られます。
その結果、DRI は以下を実施する必要があります：
プロジェクト計画 / SDLC
- ゴーライブ前に完全なスコープが文書化され、実装された機能と照合されていることを確認する。
- UAT が完了し、コアチームに設定されたビジネスステークホルダーによる UAT のサインオフが確立されていることを確認する文書があること。この UAT サインオフは、ゴーライブ前にステアリングコミッティによってレビューされ、サインオフされる必要があります。
- 主要プロセス、レポートに関するテスト、およびシステムがビジネスニーズを満たすことの確認（およびその方法）。
- UAT 中またはゴーライブ前に既知の問題が特定された場合、文書化され、Issue の解決/是正が追跡される必要があります。システムのセキュリティと機能に影響を与えるすべてのクリティカルおよび高リスクの Issue はゴーライブ前に解決される必要があります。ただし、例外的な状況がある場合は、ゴーライブ前にビジネス、IT リード、ステアリングコミッティによって回避策計画を特定、文書化、承認する必要があります。ゴーライブ前のすべての未解決 Issue を文書化・追跡し、ゴーライブ後に解決する必要があり、解決ドキュメントを保持する必要があります。
- ビジネスゴーライブの最終承認が得られていること。適切なレベルの技術オーナーとビジネスオーナーからの承認（例：これは CFO サインオフが必要か、マネージャーサインオフで十分か）。
SDLC 承認
各ドキュメントおよび/または SDLC ステージのサインオフプロセスは、プロジェクトによって異なる場合があります。すべての関連ステークホルダーからサインオフを得ることが理想的ですが、役割の優先順位は特定の状況とプロジェクトのダイナミクスによって異なる場合があります。PMO チームは承認を求める際に以下のガイドラインに従います：
| プロジェクト条件 | プロジェクトキックオフ | ビジネス要件書（BRD） | ユーザー受け入れテスト（UAT） | デプロイ / 本番移行 |
|---|---|---|---|---|
| プロジェクトの成果物が3チーム以下の限られた対象に影響を与える場合 | ビジネスからのサインオフ不要 | - ビジネスリード - 技術リード（要件定義の一部である場合） | - ビジネスリード - 技術リード（テストの一部である場合） - テスト参加者 | - ビジネスリード |
| プロジェクトの成果物が4チーム以上の広範な対象に重大な影響を与える場合 | - プロジェクトスポンサー（Zip / Coupa の承認となる場合あり） | - ビジネスリード - 技術リード（要件定義の一部である場合） - プロジェクトスポンサー | - ビジネスリード - 技術リード（テストの一部である場合） - テスト参加者 | - ビジネスリード - プロジェクトスポンサー |
データ管理/移行
- データ移行がある場合、ゴーライブ前に移行が完了し正確であることの照合を示す。理想的な証拠には、システムの証拠（例：レポート、ソースシステムとターゲットシステムからのレポート生成方法のスクリーンショット、行数の一致）と各行/フィールドの比較が含まれます。差異はゴーライブ前に解決され、照合がサインオフと整合している必要があります。
- インポートされるデータについて、それをシステムに取り込むプロセスは何か、完全かつ正確にデータが取り込まれることを確保するためのコントロール/チェックは何かを明確にします。
- これはいくつかの方法で解決できますが、良いドキュメントが重要です。変換中に誰がアクセスできますか？変換前後のチェックはありますか？「重要」フィールドは何ですか？許容できるデータ損失/不正確さのレベルはありますか？
- データ管理の証拠化は、このプログラム開発プロセスの最も重要な部分です。ビジネスニーズに応じてシステム内のデータが完全かつ正確であることを、どのように適切に示すことができますか？
- 有効化計画のドキュメントと、変更が変更されたシステムのユーザーに効果的に伝達されたことを示す。
有効化計画
プログラムには有効化計画が必要です。ビジネスリードがこの計画の DRI となる必要があります。これには、トレーニング資料の作成、コミュニケーションの草稿作成、AMA の実施、デモの実施、動画の録画が含まれる場合があります。また、この活動についてゴーライブ前後の明確な日程が必要です。
トレーニング資料
プログラムマネージャーはビジネスリードと協力して、必要に応じてすべての関連するトレーニングセッションとオフィスアワーまたは AMA をスケジュールし、すべての関連参加者に伝達する必要があります。
コミュニケーション計画
プログラムマネージャーはビジネスリードと協力して、コミュニケーション計画（メッセージ、スケジュール、媒体（例：Slack、メール等）を含む）の草稿を作成する必要があります。コミュニケーションはプログラムスポンサーの一人によってレビュー、承認、送信される必要があります。GitLab 内部コミュニケーションチームがこのプロセスをサポートできます。連携方法の詳細については、People Communications & Engagement との連携のハンドブックページをご確認ください。
実装後サポート
新しいシステムは質問量の増加につながる可能性があるため、実装後サポートの計画も必要です。これは専門家（SME）チームによって対応される必要があります。
