Content last updated 2026-01-23

組織アーキタイプ

組織アーキタイプとは?

組織アーキタイプは、組織のセットアップの典型的な例です。私たちの場合、組織がどのように GitLab とエンゲージするかに関連する組織アーキタイプに特に関心があります。私たちは、さまざまな ペルソナ のロールが、彼らの会社の特定の組織セットアップに基づいて変化することを学びました。このハンドブックページでは、私たちが特定した組織アーキタイプを記載しています。

プロダクトマネージャーとして組織アーキタイプをどう使うか?

組織アーキタイプは、ペルソナ と並ぶ、エンドユーザーの人口統計への追加レイヤーと考えることができます。インタビュー中に洞察を収集する際、組織アーキタイプを通じて、ユーザーのロールと組織内におけるコンテキストを理解することは有用です。

クラウドインフラストラクチャのリソーシング

クラウドインフラストラクチャは、アプリケーションごとに柔軟で目的に応じて設計されたインフラストラクチャを可能にします。これにより、インフラストラクチャのプロビジョニングとソフトウェア開発は、結合されたワークフローの一部となりました。私たちは以下に概説する5つの異なるタイプのインフラチームまたはプラットフォームチームモデルを観察しました。

All-in-One チーム

All-in-One

All-in-One チームは、リソースを民主的に使用します。このモデルでは、開発者は DevOps エンジニアでもあります。彼らはインフラストラクチャと関連ツールへのアクセスと認証情報を持ち、必要に応じてそれらを使用することが期待されています。チームメイトが助けを求めに行く非公式なスペシャリストがいる場合があります。

会社規模: SMB

リソースの使用例:

  • 監視 & アラート
    • チームはさまざまなクライアントを横断して SaaS テンプレートを再利用し、必要に応じて調整する
    • チームメンバーはサービスとインフラストラクチャの両方のダッシュボードを使用する
  • CI テンプレート
    • チームはコミュニティプロセスとして CI テンプレートを作成する
    • 全員が同じテンプレートに貢献し、それらから始める
    • 基本的なテンプレートは、調整を加えてクライアントを横断して使用できる
    • 環境変数を持っている場合、CI テンプレートはプライベートにされる

Service Model チーム

Service Model

Service Model チームでは、インフラストラクチャチームがリソースへのアクセスをゲートし、リソースの使用を最適化する責任を負います。他の開発はインフラストラクチャチームの顧客であり、リソースを要求し、必要に応じて助けを求める必要があります。

会社規模: Mid-Market、エンタープライズ

リソースの使用例:

  • パブリッククラウドインフラストラクチャ
    • 中央集権的なインフラチームのみがクラウドプロバイダーのリソースにアクセスできる
    • 開発者は監査ログをチェックできる
    • クラウドリソースへのアクセスを要求するため、開発者は Freshworks などのツールでインフラにチケットを発行する
    • 開発者は Dev 環境ではクラウドリソースをより自由に扱える
  • 開発環境
    • インフラチームはダミー環境で実験し、ポッドの数を変更することがパフォーマンスにどう影響するかを確認する(非本番環境で)
  • 監査ログ
    • 開発者はインフラチームからの監査ログモジュールをセルフサーブし、必要に応じて適応させる

Service & Embedded チーム

Service & Embedded

Service & Embedded チームでは、リソース使用がパートナーシップの中で導かれたり最適化されたりします。チームは必要に応じてスペシャリストと組み、Dev と Ops の両方が一緒に働きます。

会社規模: SMB、小規模エンタープライズ

リソースの使用例:

  • デプロイメントパターン
    • インフラチームは、開発者がデプロイメントのポッド数を増やすためのセルフサーブな方法を提供する
  • データベースのプロビジョニング
    • Proof-of-Concept(PoC)に取り組むため、開発者は AWS Development アカウントに入り、データベースをさまざまな方法で使用して使用を最適化する実験ができる
    • 彼らはサービスチームと協力して変更を実装する
  • テスト環境
    • インフラチームは、開発者が複雑な領域で作業するときに役立つよう、本番環境を反映するローカルテスト環境のセットアップを試みた。しかし、インフラチームが開発者に変更で更新させることは非常に困難だった

All-in-One & Service Model

All-in-One & Service

All-in-One & Service チームでは、専門化されたロールが DevOps/SecOps プラクティスを導き/強制します。開発チーム内で、彼らは多くのリソースへのアクセスを持っています。中央のプラットフォームチームは、セルフサービスを促進し、ガバナンスとコンプライアンスを強制するツールを提供します。

会社規模: 大規模エンタープライズ

リソースの使用例:

  • CI テンプレート
    • All-in-One & Service チームは、SaaS または社内ツールと連携した標準化された CI テンプレートのセットを使用して、スタック全体をナビゲートしています。専門化されたサポートチーム(セキュリティなど)が、このワークフローをサイドラインから監視し、必要に応じて自動修正したり逸脱を考慮したりします
  • シークレットのワークフロー
    • All-in-One チームメンバーは、セキュリティチームから提供されたガイダンスや要件(実行するセキュリティスキャンなど)に基づいて、さまざまなタイプのサービスでシークレットがどのように扱われるかを決定します。All-in-One チームメンバーが推奨されたパターンから逸脱する場合、セキュリティチームに通知するか、ウェイバーリクエストを完了します
    • プラットフォームチームは、All-in-One チームメンバーが従う社内ドキュメンテーションを作成します

All-in-One & Embedded モデル

All-in-One & Embedded

All-in-One & Embedded チームでは、DevOps エンジニアが製品グループまたは製品ラインに組み込まれて働き、ユーザーに関連する DevOps/SecOps プラクティスを共同創出します。

会社規模: 大規模エンタープライズ

リソースの使用例:

  • CI テンプレート
    • 異なる領域に専門化されている All-in-One & Embedded チームメンバーは、異なる環境に固有の専門化されたワークフローを調整するために、密接に協力して働きます
  • デプロイメントパターン
    • All-in-One & Embedded チームメンバーは、彼らが取り組んでいる製品ライン、ユースケース、セキュリティ要件に固有の専門化されたデプロイメントパターンを作成します。彼らは一緒にそれらを洗練します