SPA チームのガイディングプリンシプル

最終更新: 2026年5月5日

SPA チームのガイディングプリンシプル

これらの原則が存在するのは、チームが指示を待つフォロワーではなく、リーダーとして動かなければならないからです。以下のすべての原則は、特定の個人への依存を減らし、チームの意思決定のスピードと質を高めるために設計されています。

私たちの意思決定の仕方

• 許可を求めるのではなく「私は〜するつもりです」と言う。 ローテーションの穴、壊れたプロセス、より良いアプローチを見つけたら、自分の意図を明示して行動してください。「〜してもいいですか?」と聞くために 1:1 を待たないでください。期待されるフォーマットは次のとおりです: 「私は [行動] を [理由] のために行うつもりです。[時刻] までに別意見がなければ進めます。」 これは GitLab が言う マネージャー・オブ・ワン であることを意味します。
• 意思決定は情報のあるところで行う。 問題に最も近い人が判断します。MR を読んでいる、Issue をトリアージしている、エンジニアと話しているのがあなたなら、あなたに決定する権限があります。エスカレーションは、その決定が不可逆的、チーム横断的、または重大なリスクを伴う場合のみにしてください。あなたの権限の範囲については GitLab の 意思決定 ページを参照してください。
• 迷ったら、行動して報告する。待ったり尋ねたりしない。 早く下されて修正される間違った決定は、承認を待つ無決定よりも優れています。利用できる情報をもとに誠実に行動したのであれば、チーム と リーダーシップがあなたを支えます。

私たちの仕事のオーナーシップの取り方

• 自分の名前がついているなら、その成果を最初から最後までオーナーシップする。 DRI であるということは、作業を完了まで推進し、自分でブロッカーを解消し、ステークホルダーをフォローアップし、クローズアウトすることです。他の誰かが思い出させてくれるのを待つことはありません。何かがブロックされている場合、提案された前進策とともにブロッカーを表に出します。GitLab の 効果的な委任 ガイダンスを参照してください。
• 運用上のハイジーンはオプションではなく、リマインダーも必要ない。 ラベル、ステータス更新、マイルストーンのクローズアウト、ダッシュボードのフォーマットは、仕事の一部であり、別タスクではありません。コードレビューと同じように扱ってください: 正しく終わるまで完了ではありません。
• 自分のローテーションを完全にオーナーシップする (AppSec チームのみ)。 トリアージ 担当のときは、あなたがチームの玄関口です。目に留まったものだけでなく、トリアージダッシュボード 全体 (AppSec 側) をレビューしてください。キューが伸びている場合は、声を上げて計画を提案してください。誰かが気づくのを待たないでください。トリアージローテーションランブック と ローテーションスケジュール があなたの相棒です。
• リンクだけでなく、コンテキストとともに引き継ぐ。 仕事を渡すとき、DRI を切り替えるとき、PTO に入るときは、何 (現状)、なぜ (コンテキストと下された決定)、次 (受け手が最初にすべきこと) を提供してください。きれいな引き継ぎは、チームメイトの時間に対する敬意の表れです。

私たちのコミュニケーションの取り方

• 知っていることをブロードキャストする、抱え込まない。 役立つリソースを見つけたり、厄介な問題を解決したり、他のチームから何かを学んだ場合は、チームに直接共有してください。他の誰かが伝えてくれると想定しないでください。すべてのチームメンバーは情報の発信源であり、単なる消費者ではありません。
• チームチャンネルで考えを声に出す。 問題に取り組んでいるときは、チームチャンネルに考えを投稿してください。これにより推論が可視化され、早期に意見を募ることができ、サプライズを防ぎます。目的は助けを求めることではありません。他の人があなたの上に積み上げられるように、思考プロセスを利用可能にすることです。これがリモートチームにおける 信頼の構築 の方法です。
• ステータスの質問をステータス更新で置き換える。 誰かが「X はどこまで進んだ?」と尋ねるのを待たないでください。意味のある変化があったとき (進捗、ブロッカー、スコープ変更、完了) は、プロアクティブに更新を投稿してください。チームやリーダーシップがあなたに情報を追いかける必要はないはずです。
• 問題を提起するときは、提案を持ってくる。 「これはうまくいかない」は観察です。「これはうまくいかない、Y だから X を試すべきだと思う」はリーダーシップです。常に問題には少なくとも 1 つの提案された方向性を組み合わせてください。

私たちのお互いの支え方

• 頼まれなくても踏み込む。 チームメイトがローテーション中でキューが重い、または不慣れな仕事に立ち上がっている人がいる場合は、直接助けを申し出てください。マネージャーがサポートを割り当てるのを待たないでください。チームは共に成功します。
• 答えではなくコントロールを共有してメンタリングする。 新しいチームメンバーを助けるときは、引き取りたい衝動を抑えてください。代わりに、推論を一緒に歩み、実行は彼らに任せてください。私たちの目標は、能力を集中させることではなく、増殖させることです。このアプローチの詳細については、GitLab の コーチング ページを参照してください。
• 率直に意見が違うと言い、決まったら全力でコミットする。 異なるアプローチがあれば、直接的かつ敬意を持ってそう言ってください。チームまたは DRI が決定したら、それを機能させることにコミットしてください。受動的な反対 (従いつつエンゲージしない) は、オープンな議論よりもチームを傷つけます。私たちが全社的にどう取り組んでいるかについては、GitLab の フィードバックに関するガイダンス を参照してください。

私たちの改善の仕方

• すべてのプロセスをドラフトとして扱う。 何かが非効率、壊れている、不要だと感じたら、変更を提案してください。プロセスは私たちに仕えるものであり、その逆ではありません。改善を提案するためのバーは低く、摩擦を無視するためのバーは高くあるべきです。
• 繰り返しは自動化し、思考は守る。 私たちの時間は、判断を要する仕事 (脅威モデルレビュー、セキュリティテスト、アーキテクチャレビュー) に最もよく使われます。それ以外のすべて (トリアージのルーティング、ステータスのフォーマット、ラベルのハイジーン、さらには脅威モデルの作成) は、自動化またはテンプレート化されるべきです。同じ手作業を 3 回目にしている自分に気づいたら、Issue を作成してください。すでに導入されているものについては AppSec の 自動化モニタリングページ を参照してください。
• 短い実験を走らせ、学んだことを共有する。 新しいプロンプト、異なるレビューアプローチ、ツールの変更を試していますか? タイムボックスを切って試し、結果をチームと共有してください。実験が可視で小さいとき、私たちは早く学びます。

何より大切な唯一のルール

• あなたはこのチームのリーダーであり、タスクの実行者ではない。 あなたの仕事は課題を完了することではありません。専門知識、判断力、イニシアチブを発揮して、私たちの製品をより安全にすることです。あなたが本来である専門家のように振る舞ってください。マネージャー・オブ・ワン であってください。

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