GitLab サポートにおける変更管理
GitLab サポートリーダーシップチームにおける意思決定と変更管理
GitLab サポートチームは、社内の数多くのチームの中でも特異な存在かもしれません。複数のサブチームが同じ憲章を共有しているからです。この構造の中で意思決定と変更管理を行うことは、他のチームが直面しないユニークな課題を伴います。具体的には、マネージャーは決定を下したりプロセスを変更したりしようとするとき、適切なスコープ — 個別に行動するか、他のマネージャーと連携するか — を見極めなければなりません。そして、世界中のサポートマネジメントチームが、そのスコープが正しいことに合意する必要があります。私たちはここで、スコープの判断、データとフィードバックの収集、進む道の選択、変更のロールアウト、定着の管理、そして将来の改善のための結果のレビューに関する最新のプロセスを定義します。
ここでは 2 種類の変更について説明します。
プロセス変更
このプロセスは GitLab サポートリーダーシップチームに限定されない
グローバルな変更 (定義は下記参照) をロールアウトしようとしてこのプロセスに案内された方もいるかもしれません。グローバルな変更は GitLab サポートリーダーシップチームによって取り扱われることが多いものの、それに限られません。そのため、このプロセスは「マネージャー」のハンドブックセクションにドキュメント化されています。
これは、このプロセスがマネージャーのみによって従われるべきという意味ではありません。プロセスのいずれかの部分で困っている場合は、ガイダンスを求めて手を伸ばしてください — マネージャーや、過去に同じプロセスを踏んだ SE に。
SE がこのプロセスを使った例:
Request for Comments (RFC) から始める
RFC は、すべてのコントリビューターが自分のコンテキストと知識を持ち寄り、潜在的な解決策の長所と短所を見極めるための、活発な議論のための安全な場です。
RFC では、肩書きに関係なく、全員が平等にコントリビュートします。
アイデア (または問題に気付いたこと) はあるが、まだ具体的な変更を提案する準備ができていない場合は、Request for Comments Issue テンプレートから始めることができます。テンプレートには RFC の作成方法に関するガイダンスが含まれています。
スコープの決定
変更を行う際の最も重要な検討事項のひとつは、変更のスコープがどうなるかということです。
ローカル変更かグローバル変更か？
変更がローカルかグローバルかを考えるとき、変更のサイズ (変更されたコード行数、変更されたドキュメント内のテキスト行数など) に注目したくなるかもしれません。しかし、それは実際にはこの議論とは関係のない別の種類のスコープです。
代わりに、一貫性とシンプルさのために、他のリージョンに当てはまらない、あるいは意味をなさない場合を除いて、変更はグローバルに行う方向に傾くべきだ、というアイデアから始めてください。ローカルでの変更を検討している場合は、ローカル変更による以下のすべての潜在的な影響について「ノー」と答えられることを確認してください。
- グローバルチームの残りの部分との間に意味のある不整合を生じさせるか？
例:
- ローカルの作業成果物が他のチームのものと互換性がなくなる
- 用語やワークフローがローカルチームと他のチームで分岐し、コラボレーションを阻害する
- 他のチームが新しいツールやリソースにアクセスできず、あなたのチームと連携して作業できない
- 顧客はローカル変更に気付くか？
気付く場合:
- 顧客はあなたのチームと他のチームで何らかの形で異なる方法で作業する必要があり、不便に感じたり、単に煩わしく感じたりするか？
- 顧客の「通常の」サービスへの期待は引き続き満たされるか？
- 顧客があなたの変更を気に入りすぎて、他のチームやリージョンが同じことをしないことに不満を抱くか？
- あなたのチームと他のリージョンの間で異なる職務記述書や業績評価指標を生じさせるか？
変更提案のコミュニケーション
上記の判断基準に基づいてローカル変更を行う場合でも、グローバル変更を提案する場合でも、サポートリーダーシップチームの残りのメンバーに計画をコミュニケーションすることが重要です。
Requested Change Issue や MR の作成
変更を行うための最初のステップは、support-team-meta プロジェクト で Requested Change Issue を作成する ことです。 リンクされたテンプレート (Requested Change) を使用することで、必要な情報 (DRI、問題提起、成功を測る方法など) を確実に提供でき、プロセスのスピードアップに役立ちます。
この Issue は、解決しようとしている問題の提示、そのトピックに関する議論のホスティング、テストフェーズのドキュメンテーションに使用されます。
可能な限り早く、ドキュメンテーション MR や カスタマーサポートオペレーションのコンパニオン Issue を作成して、実際の提案変更を提示してください。
MR には少なくとも以下を含めてください。
- 決定とその理由 (決定に至ったデータやテスト結果など)
- どのテストが実行され、結果がどうだったかを含む、テストの要約
- メッセージプラン Issue へのリンク
- ~“Manager Attention” ラベルを追加して、サポートマネジメントチームが提案された変更について確実に把握できるようにする
- 追加のガードレールとして、
@gitlab-com/support/managersグループも Issue に追加して、サポートマネジメントチームが提案された変更について確実に把握できるようにする
新しいワークフローやプロセスへの認識の確認を得るために、ロールアウト Issue テンプレートを使用します。
注: 提案された変更のいずれかの部分が MR を通じて提示できない場合は、代わりにその情報を Issue に記載してください。
ローカル変更提案のコミュニケーション
次回のリーダーシップシンクミーティングのアジェンダで「Inform」項目としてリーダーシップチームに通知します。 なぜでしょうか？
- 他の誰かがあなたに対して提案を持っているかもしれない
- 他の誰かがあなたが行っていることに興味を持っているかもしれない
- これは私たちの透明性の価値観によく合致する
グローバル変更提案のコミュニケーション
Issue を通じて、またリーダーシップシンクミーティング のフルアジェンダトピックを通じて、リーダーシップチームを会話に巻き込みます。
- 解決しようとしている問題を説明する
- あなたが DRI なのか、DRI を募集中なのかをチームに伝える
- 既存のデータを基に提案するソリューションがあるのか、あるいはどのソリューションを提案するか決定するために 1 つ以上のテスト (試行) を実施する予定なのかをチームに伝える
- ~“Manager Attention” ラベルを追加して、サポートマネジメントチームが提案された変更について確実に把握できるようにする
- 追加のガードレールとして、
@gitlab-com/support/managersグループも追加して、サポートマネジメントチームが提案された変更について確実に把握できるようにする- テストを行う場合は、以下を推奨します:
- 潜在的なソリューションを提示し、どれを試すかを議論する
- テストの起こりうる影響を議論する
- テストを進めることについて全般的な合意を得る
- テストが大規模で長期間にわたる場合は、各テストごとに Issue を開き、それらをすべてあなたの Issue にリンクすることを検討する
- そうでない場合は、以下を推奨します:
- 変更の必要性を示し、選択したソリューションを支持するデータの両方を提示する
- マージリクエストを通じて (Issue にリンクして) ソリューションを提案し、合理的な期限とともにフィードバックを求める
- テストを行う場合は、以下を推奨します:
- (テストだけでなく) 変更の成功をどのように測定する予定かを説明する
価値あるテスト計画の構築
可能な限りデータドリブンな決定を行います。提案された変更を裏付けるデータがない場合は、1 つまたは複数のローカルな試行を実施します。コストがある場合は節約的に、既存のワークフローを混乱させないよう常に配慮してください。
- テストの設計に自信や慣れがない場合は、他のマネージャーと協力してアイデアを練ってください
- 変更のスコープ (ローカルかグローバルか) とテストのスコープには違いがあることを念頭に置いてください。グローバル変更でも、グローバルテストが必要とは限らないでしょう
- 必要なデータを得るのに十分な期間だけテストを実施する
- テストを正当なものにするのに必要な人数、チーム、リージョンだけを巻き込む
- 本番環境でのテストが問題となる場合は、代わりにサンドボックスで実行する方法を探す
- 複数の試行を実施する場合:
- 時間を節約するために並列実行を試みる
- テストの対象を最も可能性の高い 2 つか 3 つのソリューションに限定する
標準のタイムライン
将来のイテレーションのために:
ロールアウトの特定のステップに標準のタイムラインを設けたいか？
- 初期議論の長さ
- ロールアウト開始から定着完了までの日数
一度に複雑なものを変更しすぎないように、変更の影響を考慮したいか？
変更のロールアウト
変更管理における役割
ロールアウト中、変更プロセスにおいて人々が果たすことができる異なる役割について明確にコミュニケーションするために、以下の用語と提供されている説明を使用してください。
| 役割 | 説明 |
|---|---|
| Champion (チャンピオン) | 変更の成功に強い関心、場合によっては責任を持つため、変更を推進する人物。多くの場合チャンピオンはマネージャーです。 |
| User (ユーザー) | 変更されるプロセス、ドキュメント、リソースを使用する人物。 |
| Impacted Non-User (影響を受ける非ユーザー) | 変更されるプロセス、ドキュメント、リソースの実際のユーザーではないが、ユーザーの行動の変化を経験する人物。 例: サポートエンジニアは、自分自身は何も新しいことをする必要がないものの、マネージャーがエスカレーションに対して異なる対応をすることに気付くかもしれません。 |
プロセス変更ロールアウト計画
ついに変更を行う時が来たら、プロセス変更ロールアウト計画 Issue を作成します。 プロセス変更ロールアウト計画テンプレートには、すべての適切な詳細を埋めるためのガイドとなる手順が含まれています。そして Issue 自体があなたの完全なアクションプランを記述することになります。
個別アサインと責任の変更
これらのタイプの変更はほぼ常にローカルで小規模です。例:
- SE のワークロードバランスを変更し、知識共有により多くの時間を費やし、チケット対応に費やす時間を減らす
これらの変更の動機は、個別のパフォーマンスと開発を管理する必要性、リソースのバランス調整、専門知識の分布の改善、その他類似の事項に対処することから生じます。
そのような変更の計画は (機密保持上の理由から) Issue の外部で行われ、マネージャーとディレクターの間で行われる傾向がありますが、直接関与する人以外の人々に影響を与える場合は、変更を行う前に以下のうち 1 つ以上を行うことを検討してください。
- 計画を説明し、自分のリージョンの次回マネージャーシンクで懸念事項や質問を尋ねる
- 自分のリージョン以外の各リージョンとそれぞれ別々に 2 回のクロスリージョナルミーティングをホストし、計画を説明して懸念事項や質問を尋ねる
c955a93f)