サポートトレーニングモジュールメンテナー

概要

トレーニングモジュールメンテナーは、特定のサポートトレーニングモジュールを統括する主担当者です。メンテナーは、モジュールが正確で、現行のサポートワークフローや製品ドキュメントと整合し、学習やオンボーディング体験として効果的であり続けるように責任を持ちます。また、モジュールに対する変更提案のデフォルトレビュアーでもあります。

誰でもモジュールに対して改善を提案できますが、メンテナーは構造、レビュー、継続性を提供します。

メンテナーになれる人

トレーニングモジュールメンテナーは、通常次のいずれかに該当する人物です。

• そのモジュールの領域（例: 製品知識、トラブルシューティングと診断、カスタマーサービス）について実証された専門性を持つサポートエンジニア。
• 関連する 製品グループ の サポート安定カウンターパート。
• 次の両方を満たす人物:
  • そのモジュールを自分で完了している（または同等レベルの知識を持っている）こと。
  • そのモジュールの主題に関するチケットを意義のある数だけ対応していること。

モジュールには 少なくとも 1 名の_アクティブな_メンテナーが必要です。ただし、複雑なモジュールでは複数のメンテナーを置くことも可能です。複数メンテナーには、互いの変更をピアレビューでき、単一障害点を避けられるという利点があります。また、メンテナーを異なるリージョンに分散させることで、より広い対応可能性とより速い応答時間を確保できます。

トレーニングモジュールメンテナーである場合は、必ず 1 対 1 でマネージャーに伝え、モジュールに加えた更新内容をご自身のドキュメントで共有してマネージャーに知らせてください。

時間的なコミットメントとペース

モジュールごとの目安は次のとおりです。

• 基本ライン: 平均で月 1〜2 時間程度。
• レビュー:
  • モジュールを変更する MR のレビュー依頼に対応する。
  • モジュールレビューが必要であることを知らせる自動・スケジュール・手動の通知に対応する。
• リフレッシュ:
  • 少なくとも 6 か月ごと にレビューを実施し、関連する製品機能、ドキュメント、ワークフローに大きな変更があった場合にはより早期に実施する。

メンテナーの稼働状況に変化がある場合（例: 役割変更、長期休暇）には、マネージャーと連携してオーナーシップを引き継いでください。

責務

1. コンテンツの正確さと整合性

メンテナーは、モジュールが次の状態であることを保証します。

• 完了後に学習者ができるようになるべきことを反映した、正確な Goal および Objectives セクションがある。
• 正しい 前提条件 および依存関係（例: 必要な先行モジュールやベース知識）を記載している。
• 次の最新情報を参照している:
  • 製品ドキュメント。
  • ハンドブックのワークフロー。
  • 外部リソース（コース、ベンダードキュメント、動画）が使われている場合はそれらも。

メンテナーは、重要な変更（例: 新機能、設定名の変更、廃止、新しいワークフロー）を把握したときに、次のいずれかを行います。

• 自分でモジュールを更新する、または
• Issue を作成・トリアージし、別のコントリビューターからの MR をレビューする。

2. テンプレートとワークフローのスチュワードシップ

各トレーニングモジュールは、Support Training プロジェクト内の Issue テンプレートとして存在しています。メンテナーは、テンプレート自体を良好な状態に保つ責任を負います。

• トレーニング モジュールテンプレート からの ステージ構造 を維持する。
• タスクとチェックリスト が私たちの実際の働き方を反映していることを確認する（例: チケットの量、ツール、必要な Issue リンク、自己評価のステップ）。
• そのモジュールが、その領域でのサポートのチケット業務に関連していることを確認する。
• 次のような メタデータとラベル を維持する:
  • 存在する場合は YAML フロントマター内の maintainers: リスト。
  • 標準ラベル（例: ~module, ~"Module::<Name>"、関連するグループまたはカテゴリのラベル）。
• モジュールが次の場所で正しく発見可能で、適切に分類・告知されていることを確認する:
  • スキルカタログ／モジュールインベントリ。
  • そのモジュールを参照する各種ラーニングパスウェイ。
  • Support Week in Review（SWIR）

3. レビューと協働

メンテナーは、自モジュールへの変更提案の 第一線レビュアー として機能します。

• モジュールの内容、構造、メタデータを変更する MR をレビューする。
• サポートの「Guideline to update Support Training module」プロセスを適用する:
  • メンテナーが対応可能であれば、レビューを行い、承認またはフィードバックを返す。
  • 対応不可能な場合は、次のいずれかへルーティングを支援する:
    • 別のモジュールメンテナー、または
    • 該当領域の専門家やサポートマネージャー。
    • 関連する Support Pods の Slack チャンネル。

実質的な変更（例: 大幅な再構成、新しいアセスメント、大幅なスコープ変更）の場合、メンテナーは次を行います。

• 必要に応じて、関連する領域専門家、SSC、または製品領域のリードを巻き込む。
• 更新後のモジュールが、より広範なラーニングパスウェイやサポート教育戦略に引き続き適合することを確認する。
• チームコールや SWIR で変更内容を周知・告知する。

4. 学習者体験とアセスメント

メンテナーは、モジュールが学習者にとって使いやすく効果的であるように支援します。

• 定期的に（6 か月ごとに）次を確認する:
  • タスクが明確で、不必要にブロッキングになっていないこと。 - 学習者がモジュールを自力で完了できるようになっていること。
  • チケットや顧客コールの要件が、期待値や業務量と照らして現実的であること。
  • クイズや自己評価が利用可能であること。
• 受講者やマネージャーのフィードバック（入手可能であれば）をレビューし、繰り返し現れるテーマを改善につなげる:
  • 曖昧な指示の明確化。
  • 適切な場合のタスクの順序の調整。
  • 例、図、練習タスクの追加または簡素化。

5. ライフサイクルに関する判断

メンテナーは、モジュールが時間とともにどう進化するかを決める重要な意見の発信者です。

• モジュールについて、次のどれが適切か特定する:
  • リフレッシュ（軽微なコンテンツ更新）。
  • 再構成（例: 「Basics」と「Advanced」に分割する、トピックベースのパスウェイに整合させる）。
  • 廃止または別モジュールへの統合。

期待値と成功基準

トレーニングモジュールメンテナーは、次の状態のときにうまく機能していると言えます。

• 鮮度: モジュールが妥当な範囲で最新である（コアタスクに、明らかに壊れたリンク、廃止されたワークフロー、廃止された機能が含まれていない）。
• 応答性: MR やレビュー依頼に対して妥当な期間内に最初の応答が行われる。
• 明確さ: 新しい学習者やそのマネージャーが次のように報告する:
  • 指示が明確である。
  • 必要な作業が達成可能である。
  • モジュールの開始方法、進め方、完了マークの付け方が分かりやすい。

スコープ外

メンテナーは、次の事項を 単独で 担うわけではありません。

• モジュールに紐づくすべてのトレーニングセッションを自ら実施すること。
• すべての学習者に対してモジュール全体を 1 対 1 でコーチングすること。
• そのトピックのコンテンツ作成のすべてを所有すること。

そのかわり、メンテナーは次を行います。

• 他者が貢献できる、明確で最新の構造を提供する。
• サポートエンジニア、SSC、製品チーム、その他のステークホルダーからの貢献をレビューし、ガイドする。

ページのソースコードを見る - ページの編集 - please contribute.