Security メンターシッププログラム

概要

Security メンターシッププログラムは、Security 部門のチームメンバーに、メンターを見つけたり、自分がメンターになったりするための体系的な方法を提供します。学びたいことや支援できることを教えていただき、私たちがペアを組み、それぞれのペアが具体的な仕事に関する目標に向けて取り組みます。

まずは、FY27 Q4 の 2026 年 11 月から 2027 年 1 月まで、1 四半期の試験運用を行います。終了時に、このページの目標に照らして結果を測定し、次の参加期を実施するか、方法を変更するか、終了するかを決めます。

Product Security がこのプログラムを開始し、試験運用は Product Security、Security Operations、Security Assurance、Corporate Security を含む Security 部門全体に開かれています。

プログラムは GitLab プロジェクトで運営します。プロフィール、組み合わせ、テンプレートはそこにあります。このページでは、プログラムの目的とガイダンスを説明します。

VP of Product Security の Zach Brightがプログラムのスポンサーを務めます。運営を担うプログラムチームは、このプロジェクトの CODEOWNERSです。

目標

GitLab にとっての目標

GitLab にとっての目標は、有能なチームメンバーが最高の仕事をできるように成長と能力開発を支援することです。私たちは Security 部門全体で専門知識をさらに深めたいと考えており、シニアのチームメンバーにはその専門知識の育成を支援することが期待されています。部門全体のチームメンバーは、仕事の中で暗黙的に、あるいは仕事の外でより非公式に、すでに多くのメンタリングを行っています。しかし、一部のチームは Staff や Principal のエンジニアに偏っているため、メンターに最も適した人でも自分のチーム内には指導する相手がほとんどいません。一方、部門内のほかのチームには、メンターを求めていても、自分のチーム内では適任者が見当たらないチームメンバーがいます。このプログラムはチームの枠を越えてメンターとメンティーをつなぎ、その組み合わせを明確かつ正式なものにします。メンターとメンティーの双方が時間を確保し、具体的な職業上の目標を設定し、日々のプロジェクトや技術的な支援を超えて取り組めるように設計されています。また、チームがどの分野で成長したいのか、誰が支援できるのかをより明確に把握できるほか、現在のスキルや能力についても、参加登録した人の範囲で部分的に把握できます。

チームメンバーにとっての目標

個人にとっての目標は、職業能力の開発目標に支援を結び付けることです。誰にでも学びたいことや学ぶ必要があることがあり、それを実現するには時間、機会、支援が必要です。多くのチームメンバーはすでに自分でメンターを見つけていますが、それがすべての人にうまくいくわけではありません。身に付けたいスキルを把握することと、部門全体の誰がその習得を支援できるかを把握することは別で、後者のほうが困難です。このプログラムはその組み合わせを行い、関係を始めるための一定の枠組みを提供します。

私たちのバリューとのつながり

これらの目標は GitLab のバリューと運営原則に沿っています。

• オーナーシップの姿勢： 仕事に最も近い人が意思決定を行い、結果に責任を持ちます。その経験を持つメンターがいれば、まだ直面したことがない状況でも、判断の際に参考にできるものが増えます。
• 品質を伴うスピード： すでに経験した人から学ぶほうが、一人で解決するよりも速く進められます。異なる経験を持つ人から学ぶことで、馴染みのある問題にもより多角的に取り組めるようになり、より良い成果につながります。
• コラボレーション： ペアはチームの枠を越えて協力し、メンティーはほかの人が実際にどのように問題に取り組むかを学びます。
• 卓越性と帰属意識の文化： この文化では、深い理解、成果を生むスキル、互いに良き人間であることが求められます。メンタリングの成果は、この 3 つすべてに貢献します。定期的に互いにフィードバックする人同士は理解も深まり、それが帰属意識を育みます。

このプログラムに該当しないもの

• パフォーマンス管理。
• 昇進の判断材料。ほかの仕事と同じように、自分のメンタリング活動を昇進のための文書やフィードバックに記載することはできますが、プログラムがその判断に情報を提供することはありません。
• マネージャーとの 1:1 の代わり。
• 義務。メンターとしてもメンティーとしても、参加する必要はありません。
• 公開して放置する名簿。プログラムチームはプロジェクトを管理し、試験運用中にペアの状況を確認し、チームの関心に応じて新しい参加期の日程を発表し、うまくいかないことがあれば変更します。Security 部門全体は、余力に応じて各参加期に参加するかどうかを選び、可能な範囲で時間を提供します。スポンサーとメンティーのマネージャーは、このプログラムのための時間を確保するようチームに働きかけ、ほかの優先事項からその時間を守る必要があるときは支援します。この 3 つのグループが協力することで、プログラムが機能します。

メンタリングとコーチング

このプログラムではメンタリングとコーチングの両方を行う可能性がありますが、これらは異なるスキルです。GitLab のコーチングページでは、会話の中でかぶり分ける異なる帽子として説明されており、Lara Hoganも同じ区別をしています。

• メンタリングとは、自分の経験に基づく助言や視点を共有することです。「私はこう対処しました」。
• コーチングとは、答えを与えずに、相手が自分の課題を考え抜けるよう支援することです。コーチは質問して耳を傾け、相手が次のステップを考えます。

おそらく、3 つ目の帽子をかぶることもあります。スキルを身に付けられるよう知識を伝える「教えること」は、職務やプロジェクトに特化したコースで頻繁に行われます。

このプログラムでは、メンティーはどちらが必要か、あるいはまだわからないかをプロフィールに記載します。メンターは、会話中に自分がどの帽子をかぶっているのかを認識し、意識して切り替えてください。あるミーティングでは主にメンタリングを、次のミーティングでは主にコーチングを行っても構いません。GitLab 全体でのメンタリングについては、GitLab でのメンタリングを参照してください。

ここでのコーチングは、Security 部門のチームメンバー同士のピアコーチングを指します。プロのコーチを探している場合は、コーチの選び方を参照してください。

GROW モデルを使ったコーチング

コーチングが初めての場合は、GROW モデルを使うと、会話を始めるためのおおまかな形が得られます。GitLab のコーチングページで使用しているのと同じモデルです。順番どおりに進める必要はありません。ほとんどの会話は目標と現状から始まり、その後は各段階を行き来します。

もっと手軽な方法として、Michael Bungay Stanier の The Coaching Habitは、「ここで、あなたにとって本当の課題は何ですか？」などの 7 つの質問にコーチングをまとめています。

要件

これらの要件は、2026 年 9 月（FY27 Q3）に RFC: メンターシッププログラムの構築を通じて ProdSec チームから寄せられたものです。試験運用の対象が Security 部門全体に広がった現在も、これらの要件は適用されます。

進め方

コース

• 職務やプロジェクトに特化。 特定の技術、GitLab のコードベースの一部、セキュリティスキルなど、今の仕事で必要なことを向上させたい場合です。
• 幅広いキャリア。 Staff への昇格、マネジメントへの挑戦、権限によらずに影響力を発揮する力の向上など、今後の方向性についての視点を得たい場合です。

提供できることや必要なことを率直に伝えてください。職務やプロジェクトに特化したメンタリングは、幅広いキャリアについての会話よりも通常は実践的な支援に時間がかかるため、メンターは時間を確保できるコースだけを記載してください。幅広い支援にしか時間を割けない場合も問題ありません。その旨をプロフィールに記載してください。メンティーは、支援できる人と組み合わせられるよう、自分が必要とするコースを選んでください。

参加方法

1. 期待されることを含め、このページを読んでください。
2. プロフィールテンプレートを使ってプログラムのプロジェクトに MR を作成し、参加する期を選んでください。メンティーは、学びたいこと、希望するコース、「完了」がどのような状態かを記述します。メンターは支援できることと、対応できるコースを記述します。プロフィールには参加した期を記載します。ある期を見送る場合は追加せず、準備ができたら次の期を追加してください。
3. #security-mentorship-programに参加してください。プログラムの更新情報や状況確認を投稿するチャンネルで、質問もできます。

プロフィールは GitLab 社内の全員に公開されます。その人たちに見られてもよい内容だけを記載してください。

参加登録時には、任意で開始時点の状況を記録するフォームにも回答できます。終了時に自分の状況を比較できるよう、出発点を記録します。フォームには名前を記録するため、私たちは障害となっていることをフォローアップしたり、開始時点の回答と最終回答を並べて提示したりできます。回答を閲覧するのはプログラムチームだけで、共有する情報はすべて集計したものとし、個人が特定されることはありません。

組み合わせ

プログラムチームは、各メンティーが学びたいことと各メンターが支援できることに基づいて、メンティーとメンターを組み合わせます。各組み合わせは、そのペアにした理由とともにプロジェクトに記録します。

組み合わせは、所属するチームや部署ではなく、学びたいことに基づいて行います。日々の業務が自分とは異なる別の部署の人とペアになることもあります。各メンターは支援できることを記載し、私たちはそれを基準に組み合わせます。

また、どちらかにとって早すぎたり遅すぎたりしない時間であれば毎週のミーティングを続けやすいため、タイムゾーンの違いを考慮しても、無理なく活動できる時間帯が重なるペアを優先します。これは必須条件ではなく、望ましい条件です。プログラムチームが、メンターがメンティーの学びたいことを支援できるかを検討した後に考慮します。

組み合わせの案を作成するために、プログラムのプロジェクトにある Claude スキルを使用します。このスキルはプロフィールに記載された内容だけを読み取り、確定前にプログラムチームの担当者がすべての組み合わせを確認します。

組み合わせでは、まず、すべてのメンティーにメンターが付くようにします。Security 部門内でメンターが足りない場合、プログラムチームはメンティーとそのマネージャーに連絡し、部門外のメンターを探します。その組み合わせはプログラム外で手配しますが、メンティーには組み合わせを記録するファイルを作成します。これにより、そのメンティーも状況確認と最終評価の対象となり、希望すれば次の参加期には部門内で組み合わせることができます。

自分のマネージャーや直属の部下とは組み合わせません。プログラムチームは各組み合わせでこれを確認します。

メンターを務めるのが初めての場合は、できる限り目標がより絞られたメンティー 1 人と組み合わせます。

ペアとしての活動開始

メンターは初回のミーティングを設定し、キックオフテンプレートを使ってアジェンダを準備する責任を持ちます。メンティーは、設定しやすいようにカレンダーを最新の状態に保ちます。キックオフテンプレートには、二人で取り組むための、互いを知るための短い質問集が含まれています。相手の仕事の進め方を理解するのに役立ち、最後に目標を設定します。その目標を 1 行で書いてください。「試験運用が終わるまでに ___ したい。そして、___ ならうまくいったと判断します」。

2 回目以降のミーティングでは、GitLab 全体でのメンタリングや、自分の 1:1 を主導するのと同じように、メンティーが主導します。プロジェクトには継続的なミーティングの推奨構成がありますが、決まったテンプレートはありません。双方に合う詳しさで共有アジェンダを維持してください。タイムゾーンが異なる場合は、早めに定期的な時間枠を決め、できるだけ守るようにしてください。

メンターへの支援

初回のミーティングまでにメンターガイドを読んでください。GitLab のメンターとメンティーのトレーニングも、自分のペースで学び始めるのに適しています。試験運用に参加するメンターは、方法を比較したり互いに助けを求めたりするための非公開 Slack チャンネル #security-mentor-club に招待されます。メンターが仲間として互いに信頼関係を築けるよう、意図的に非公開にしています。話し合うのはメンティーについてではなく、自分がどのようにメンタリングするかについてにしてください。自分とメンティーが話したことは、二人の間にとどめます。このチャンネルは、メンティーを含むプログラム参加者全員向けの公開チャンネル #security-mentorship-programとは別のものです。特定のペアについて支援が必要な場合は、プログラムチームに DM を送ってください。参加登録の締め切り後、初めてのメンターが何人いるかを確認し、必要に応じて支援を追加します。

必要な時間

メンティー 1 人につき、週に少なくとも 30 分を予定してください。複数のメンティーを担当するメンターは、メンティーごとにその時間を確保してください。

状況確認

試験運用中に、何回か状況確認を送ります。いずれも数分で回答できる、少数の質問です。誰かを評価するためではなく、障害を早期に把握するためのもので、何を話したかではなく、活動が行われているかを尋ねます。次のような内容を予定しています。

• 開始から 2 週間： ミーティングは実施しましたか？目標は設定しましたか？妨げになっていることはありますか？
• 開始から 6 週間： 進み具合はいかがですか？妨げになっていることはありますか？
• 終了の 2 週間前： 次の参加期にも参加したいですか？
• 試験運用終了後： 全体を通していかがでしたか？

フォームには名前を記録するため、私たちは障害となっていることをフォローアップしたり、開始時点の回答と最終回答を並べて提示したりできます。回答を閲覧するのはプログラムチームだけで、共有する情報はすべて集計したものです。

ペアでの活動がうまくいかない場合

どちらからでも、いつでもペアでの活動を終了できます。メンターには、黙って活動をやめるのではなく、メンティーと終了のための会話をすることを期待します。どちらの場合も、ペアでの活動を終了したいときはプログラムチームに連絡し、理由を教えてください。その情報はプログラムチーム内にとどめ、希望する場合の再組み合わせやプログラムの改善に役立てます。

期待されること

GitLab のメンタリングで期待されることは、ここでも適用されます。これには守秘義務も含まれ、双方が共有に同意しない限り、話した内容は二人の間にとどめます。それに加えて、このプログラムではいくつかの具体的なことをお願いしています。

メンティー

• 自分の目標に責任を持ってください。取り組むことと「完了」の意味は自分で決めます。
• キックオフ後のミーティングを主導し、共有アジェンダに話題を持ち寄ってください。
• 日程調整（必要に応じた変更も含む）がしやすいように、カレンダーを最新の状態に保ってください。
• 何が役立ち、何が役立っていないかをメンターに伝えてください。

メンター

• 初回のミーティングまでにメンターガイドを読んでください。
• 初回のミーティングを設定し、キックオフテンプレートを使ってアジェンダを準備してください。
• メンタリングとコーチングのどちらを行っているかを明確にし、メンティーがどちらを望むかを尋ねてください。
• メンティーの選択を尊重してください。あなたの役割は導くことであり、それをどう生かすかはメンティーが決めます。
• 確保できる時間を正直に伝え、引き受けすぎないでください。確信がない場合は、ある参加期でメンティー 1 人やコース 1 つなど、負担を小さくして始め、様子を見てください。

双方

• 必要な時間を計画に組み込み、守ってください。
• 状況確認に回答してください。
• 妨げになっていることがあれば、早めにプログラムチームへ伝えてください。
• 目標を意識してください。数回のミーティングごとに見直し、変化していれば調整してください。
• （任意）開始時点の状況を記録する Google Form に回答し、自分自身とプログラムチームが試験運用の成果を追跡できるようにしてください。

試験運用の日程

今回の試験運用は FY27 Q4（2026 年 11 月 2 日から 2027 年 1 月 31 日）に実施します。以下の日付は、プログラムチームが確定するまでは目安です。

試験運用の評価

1 四半期は長期的なキャリアへの影響を示すには短すぎる期間であり、それを超えて参加し続けるようお願いするものでもありません。この期間でわかるのは、プログラムを継続し、測定を続けられるほど十分に機能するかどうかです。終了時に、以下の問いに基づいて、継続するか、方法を変更するか、終了するかを決めます。

途中で終了したペアの数と理由も確認します。結果は集計したものだけを共有し、個人を特定できるほど小さなグループ単位では決して共有しません。得られた知見と判断をプログラムのプロジェクトに投稿します。

トレーニングと費用

このプログラムには独自の予算はありません。メンティーやメンターが必要なスキルを伸ばすために（個別に）受講するトレーニングの機会が見つかった場合は、G&D 予算の一部として（それぞれのマネージャーと）相談できます。

関連リソース

• GitLab でのメンタリング: メンターとメンティーのトレーニング、目標設定、アジェンダ例、メンターシップの終了方法を説明しています
• GitLab チームページのメンターになる: このプログラム以外でも自分を見つけてもらいたい場合に利用できます
• コーチング: GROW モデルやプロのコーチの探し方を含みます
• 成長と能力開発の福利厚生

質問とフィードバック

プログラムの進め方についてのフィードバックを歓迎します。特に最初の参加期が始まる前にお寄せください。#security-mentorship-programで質問するか、プログラムのプロジェクトに Issue を作成してください。

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