DevOps プラットフォームメッセージハウス
概要
Command of the Message の精神に基づき、このページは GitLab チームメンバーが GitLab DevOps プラットフォームソリューションを、競合との差別化を意識しつつ、本物で一貫した方法でお客様に理解・定義してもらえるよう支援します。本ページには次の内容が含まれます。
注意: DevOps プラットフォームを説明するための承認済みコピーをお探しの場合は、Messaging Guidelines までスキップしてください。
DevOps の 4 つのフェーズ
DevOps が進化するにつれて、その複雑さも増してきました。この複雑さは 2 つの要因によって駆動されています。
- 組織がモノリシックアーキテクチャからマイクロサービスアーキテクチャへ移行している。マイクロサービスを使うことで、チームは独立して作業し、より速く動ける。
- DevOps が成熟するにつれて、組織はプロジェクトごとにますます多くの DevOps ツールが必要になる。
プロジェクト数の増加とプロジェクトあたりのツール数の増加の結果、プロジェクト・ツール統合の数が指数関数的に増加しました。これにより、組織が DevOps ツールを採用する方法を変える必要が生じました。この進化は 4 つのフェーズで起こりました。
フェーズ 1: Bring Your Own (BYO): バラバラなツール
Bring Your Own DevOps フェーズでは、各チームがそれぞれのツールを選んでいました。このアプローチは、チーム同士が一緒に作業しようとした際に、他チームのツールに精通していないという問題を引き起こしました。
フェーズ 2: Best In Class (BIC): 標準化されたツールチェーン
これに対処するため、組織は第 2 フェーズ Best in Class DevOps に移行しました。このフェーズでは、組織は同じツールセットに標準化し、DevOps ライフサイクルの各段階に推奨ツールを 1 つ持つようにしました。これによりチーム間のコラボレーションは助けられましたが、今度は各段階のツールを通してソフトウェア変更を移動させることが問題となりました。
フェーズ 3: Do It Yourself (DIY): カスタム統合
この問題を解決するため、組織は「Do It Yourself DevOps」を採用し、ツールの上に、そしてツール間に自前で構築しました。彼らは多くのカスタム作業を行って DevOps ポイントソリューションを統合しましたが、これらのツールは統合を念頭に置かずに独立して開発されたため、ぴったりはまることはありませんでした。多くの組織にとって DIY DevOps の保守は大きな労力を要し、エンジニアがコア製品ではなくツール統合の保守に注力することで高コストにつながりました。
フェーズ 4: DevOps プラットフォーム: 単一アプリケーション
チーム体験とビジネス効率を向上させるためには、プラットフォームアプローチが必要でした。GitLab、The DevOps Platform は DIY DevOps を置き換え、DevOps ライフサイクルのすべての段階に対する可視性と制御を実現します。
ソフトウェア、運用、IT、セキュリティ、ビジネスのすべてのチームが、エンドツーエンドの統合システム全体で協力的に計画・構築・セキュア化・デプロイできるようにすることで、GitLab は DevOps の可能性を完全に実現するための根本的な転換を象徴します。DevOps プラットフォームは、自己管理型または SaaS デプロイメントに関わらず統一されたユーザーインターフェースに支えられ、統一データストアを持つ単一コードベースで構築された単一アプリケーションであり、信頼性の低い DIY ツールチェーンの非効率性と脆弱性を解決できるようにします。
ソフトウェア主導の組織がさらに分散型かつアジャイルになっていく将来に向けて、すべての企業はソフトウェア開発と提供をモダナイズするために DevOps プラットフォームを必要とするでしょう。マイクロサービスからサーバーレス、最終的にエッジアーキテクチャまで、次世代のクラウドネイティブ技術の採用をより簡単で信頼できるものにすることで、すべての企業はソフトウェアをより速く、最大限の効率で、エンドツーエンドのソフトウェアサプライチェーンに組み込まれたセキュリティとともに出荷できるようになります。
メッセージングガイドライン
| カテゴリー名 | DevOps プラットフォーム |
|---|---|
| カテゴリー定義 | 単一のユーザーインターフェース、統合データストア、DevOps ライフサイクルに組み込まれたセキュリティを備え、単一アプリケーションとして提供されるプラットフォーム。 |
| カテゴリーの根拠 | 競争力を維持するためにあらゆる企業がソフトウェア企業になる必要があると認識する中で、DevOps 業界は拡大し、組織内のツール・プロジェクト統合の数と複雑性は増しました。これは DevOps における 2 つの動きの結果です。 1. 企業がモノリシックアーキテクチャからマイクロサービスアーキテクチャ へ移行した。これによりアプリケーションは独立してスケールでき、チームはより速く動けるようになりました。 2. ソフトウェアの高速な提供は、企業がプロジェクトごとにより多くの DevOps ツールを使うことも要求しました。 プロジェクト数の線形的な増加とプロジェクトあたりのツール数の線形的な増加は、プロジェクト・ツール統合数の指数関数的な増加につながりました。 その結果、サイクルタイムの長期化と生産性の低下、ソフトウェア脆弱性の増加が起きました。これを解決するには、DevOps ライフサイクルにわたるツールを統合するプラットフォームが必要です。 |
| シングルセンテンス（ビジネス／テクノロジーリーダー向け） | GitLab は DevOps プラットフォームであり、組織がソフトウェアをより速く効率的に提供しつつ、セキュリティとコンプライアンスを強化することで、ソフトウェア開発全体のリターンを最大化できるようにします。 |
| シングルパラグラフ（ビジネス／テクノロジーリーダー向け） | GitLab は DevOps プラットフォームであり、組織がソフトウェアをより速く効率的に提供しつつ、セキュリティとコンプライアンスを強化することで、ソフトウェア開発全体のリターンを最大化できるようにします。GitLab を使えば、組織内のすべてのチームが完全な透明性、一貫性、トレーサビリティをもって、より速くビジネス成果を生み出すために協力的に計画・構築・セキュア化・デプロイできます。 |
| シングルセンテンス（エンジニア向け） | GitLab は DevOps プラットフォームであり、ソフトウェアを開発・セキュア化・運用する能力を、より使いやすくサイクルタイムを短縮する単一アプリケーションに統合します。 |
| シングルパラグラフ（エンジニア向け） | GitLab は DevOps プラットフォームであり、ソフトウェアを開発・セキュア化・運用する能力を、より使いやすくサイクルタイムを短縮する単一アプリケーションに統合します。GitLab を使えば、組織内のすべてのチームがエンドツーエンドの開発ライフサイクルを管理する単一ツールで協力でき、より多くの価値をより速く提供し、可視性を高め、コンテキストスイッチを排除できます。 |
| キーバリュー | バリュー 1: 運用効率の向上 | バリュー 2: より良い製品をより速く提供 | バリュー 3: セキュリティ & コンプライアンスリスクの低減 |
|---|---|---|---|
| 約束（Promise） | 効率: R&D と IT の生産性を最大化。 | 速度: 市場投入までの時間を加速。 | セキュリティ: 妥協のないコンプライアンス。 |
| 顧客の痛み | 組織はツールチェーン統合の保守、ツール固有のコンピテンシーのサイロ化、統合における「データギャップ」によるコンテキスト不足と手動回避策に時間とリソースを浪費しています。 | DIY ツールチェーンは意思決定を支えるべき重要な DevOps データへの可視性を制限します。また、信頼性が低く一貫性もないため、リスクを大幅に増やすことなく組織が大規模に意思決定を実行することを妨げます。 | セキュリティスキャンが遅すぎる、または全く実施されないため、開発者が脆弱性をソースまでさかのぼり、脆弱なコードとそれに依存する変更の両方を修復するという広範な再作業が必要となります。 |
| GitLab の約束 | 統合データソース上に構築された単一アプリケーションとして、GitLab は DIY ツールチェーンを構築・保守するためにリソースを費やすことなく、完全な DevOps ソリューションを提供します。何らかの理由で統合が必要な場合も、一度統合すればプラットフォーム全体にアクセスできます。 | 統合データソース上に構築された GitLab の単一アプリケーションは、ソフトウェアサプライチェーン全体のエンドツーエンドビューを提供し、完全な透明性を実現します。ツールチェーン統合の不在は、より一貫性があり予測可能で保守の少ない開発フローを生み出します。 | 組み込みセキュリティスキャナーにより、組織はコミットごとにすべてのコード行をスキャンでき、開発者はプッシュする前に脆弱性を特定・修復できます。 |
| ROI のテーマ | 統合データソース上に構築された単一アプリケーションとして、GitLab は DIY ツールチェーンを構築・保守するためにリソースを費やすことなく、完全な DevOps ソリューションを提供します。何らかの理由で統合が必要な場合も、一度統合すればプラットフォーム全体にアクセスできます。 | 統合データソース上に構築された GitLab の単一アプリケーションは、ソフトウェアサプライチェーン全体のエンドツーエンドビューを提供し、完全な透明性を実現します。ツールチェーン統合の不在は、より一貫性があり予測可能で保守の少ない開発フローを生み出します。 | 組み込みセキュリティスキャナーにより、組織はコミットごとにすべてのコード行をスキャンでき、開発者はプッシュする前に脆弱性を特定・修復できます。 |
| 製品証跡 | - インストール・保守すべきシステムは 1 つ。- 1 社のプロバイダーによるエンドツーエンドのライフサイクルサポート。- 外部システムとの統合ポイントは 1 つ。- ライフサイクル全体で 1 つのユーザーインターフェース。 | - Value Stream Analytics により、作業の流れを監視・管理し、価値提供への非効率とブロッカーを特定できる。- アイデアからコード作成、テスト、セキュリティスキャン、パフォーマンス影響まで、ライフサイクルにわたるアーティファクトとアクションの自動相関により完全なトレーサビリティを実現。- 詳細レベルへのコンテキスト付きドリルダウンが可能なロールベースのダッシュボード（Security Dashboard、Epic Roadmap など） | - コードをマージせずにすべてのコミットで静的・動的セキュリティスキャンを実行。- セキュリティ脆弱性とポリシー違反の導入・修復・却下に対する明確な説明責任を提供。- 開発、運用、セキュリティ、監査／コンプライアンスにわたる単一システムでの協業により、完全なコンテキストを維持。 |
| 顧客事例 | Glympse（20 種類の異なるツールを GitLab に置き換え）、Jasper Solutions（YoY 33-37% のコスト削減、サイクルタイム 30% 短縮、デプロイ頻度 25% 向上、プロジェクトの 90-95% を予算内・期限内に完了） | Goldman Sachs（隔週のビルドから 1 日 1,000 回以上へ）BI Worldwide（モダナイズされたアプリケーションで 1 日 10 倍のデプロイ、複数ツール、ログイン、ユーザー体験の課題を排除） | HackerOne（より早く、より頻繁に、より経済的にスキャン） |
サポートデータ
Market Guide for DevOps Value Stream Delivery Platforms において、Gartner の戦略計画上の前提は次のとおりです。
「2023 年までに、組織の 40% がアプリケーションデリバリーの効率化のために、複数のポイントソリューションから DevOps バリューストリームデリバリープラットフォームに切り替えるだろう。2020 年の 10% 未満から増加。」
Market Guide for DevOps Value Stream Delivery Platforms, Manjunath Bhat, Hassan Ennaciri, Chris Saunderson, Daniel Betts, Thomas Murphy, Joachim Herschmann, 28 September 2020
Gartner はリサーチ刊行物に登場するベンダー、製品、サービスを推奨するものではなく、技術ユーザーに対して評価が最も高いベンダーやその他の指定を持つベンダーのみを選ぶように助言するものでもありません。Gartner のリサーチ刊行物は Gartner のリサーチ組織の意見で構成されており、事実の表明と解釈すべきではありません。Gartner はこのリサーチに関するすべての保証（明示的または黙示的）について、商品性または特定目的への適合性に関する保証を含め、これを否認します。
GitLab は、これは単一アプリケーションとして提供される DevOps プラットフォームの市場が、DevOps 市場全体よりもはるかに速く成長することを示すと考えています。
セグメント別メッセージングとポジショニング
以下に、DevOps プラットフォームのユースケースで異なるセグメントが見出す価値の要約と、その価値を最も効果的に説明できる GitLab のポジショニングの提案を示します。
SMB
すべての SMB は成長するにつれて何らかのリソース制約に直面します。DevOps プラットフォームは、彼らがなりたい企業へと成長するのに最も摩擦の少ない成長経路を提供します。
一部の SMB は DevOps ソリューションに何を求めるかについて非常に明確な考えを持っているのに対し、他は旅を始めたばかりです。前者のカテゴリーのビジネスにとって、DevOps プラットフォームは成長するにつれてニーズを予測する生産的なソリューションへのガイドとなり、世界最大級の企業を含む、あらゆる規模の成功企業が同じソリューションを使っているという証拠に支えられます。DevOps プラットフォームは、まだ遭遇していない問題による頭痛を最小限に抑えることを保証できます。
DevOps を始めたばかりの SMB はおそらくすでに複数ツールの統合プロセスを始めており、すでにリソース制約に直面している可能性が高いです。これらの組織はポイントソリューションの保守と統合に時間を浪費していることをよく自覚しており、おそらくより生産的な作業に集中したいと思っています。彼らは最終的に、DevOps プラットフォームが彼らの基準を満たし、特にソースコード管理と継続的インテグレーションのポイントソリューションに対抗できることを知る必要があります。SMB のもう一方のカテゴリーと同様に、関連する大企業の顧客事例は重要な第三者証跡となります。
ミッドマーケット
ミッドマーケット企業は、大企業と同じ課題を経験するのに十分な規模と成熟度を持っており、エンタープライズの項で言及されたメッセージングの多くは一般に響きます。効率は不可欠で、より多くの価値をより速く開発するためにリソースを解放します。組織横断のコラボレーションも重要です。
ミッドマーケットとエンタープライズセグメントの主な違いは成長への要請です。ミッドマーケットビジネスは大企業とまだ純粋なスケールで競争できないものの、機敏なスタートアップに出し抜かれるには十分な規模であり、成長とイノベーションに非常に志向性があります。そのため、彼らは速く動くことに非常に関心がありますが、上方または外方への成長を最終的に制限する可能性のあるロックインや拡張性の悪さに警戒しています。これらのビジネスにとって、大企業、特に競合他社や類似業界の証跡は非常に役立ちます。機会が現れるたびにコンポーネントごとに即座にプラットフォームを採用できる能力は好評を博すでしょう。
エンタープライズ
エンタープライズはマルチプロダクト統合の「ツールチェーン税」の痛みにすでに精通しているでしょう。より積極的な DevOps 戦略を追求してきた企業は、複数のツールチェーンの構築・保守に多くのリソースを費やしている可能性が高く、他は複雑性とコストのために野心を縮小してきたかもしれません。
いずれの場合も、単一のエンドツーエンドプラットフォームの効率性はあらゆる役割に響きます。保守と統合に費やすリソースを減らせば、無駄が減り、生産的で興味深い成果に集中できるようになります。さらに DevOps プラットフォームは、可視性とコラボレーションを高め、すべての関係者が SDLC により深く関与することを促すことで、エンタープライズが行う作業の 品質 を向上させます。プランナーとビジネスステークホルダーは、要件と提案がデプロイ後のビジネスインパクトまで一貫して追跡できる一方、開発者・運用・セキュリティの専門家はビジネス議論のコンテキストを理解し、貢献できます。セキュリティ、コンプライアンス、監査は、不規則性のソースまで完全なトレーサビリティを持ちます。
単一プラットフォームの可視性とコラボレーションは、トランスフォーメーション施策とも相性がよいです。エンドツーエンド DevSecOps の単一プラットフォームとして、GitLab はプロジェクトベース思考からプロダクトベース思考へ、ウォーターフォールからアジャイル方法論へ、その他の文化的・プロセス的トランスフォーメーションのエンジンになり得ます。
セグメントとペルソナごとのエレベーターピッチ
以下は、ペルソナの企業の市場セグメントに基づき、DevOps プラットフォームユースケースの価値の関連する側面をポジショニングするために、ユーザーペルソナとバイヤーペルソナに提供できる価値を 1 文で要約したものです。
SMB
| ユーザー: Delaney - 開発チームリード | ユーザー: Devon - DevOps エンジニア | バイヤー: CTO* | バイヤー: CIO* |
|---|---|---|---|
| コミット時に即座にコードの品質、パフォーマンス、セキュリティのフィードバックを受け取れる。チーム間でシームレスに協業できる。 | カスタム統合を構築・サポートする必要なく成長できる。 | 単一システムで協業し、コンテキストスイッチを最小化し、開発者の生産性と集中力を高める。 | カスタム統合を構築・サポートせずに成長できる。単一システムをスケール・管理する。 |
* CTO（開発、外部志向）と CIO（運用、内部志向）のペルソナは開発中であり、セグメントによって異なる場合があります。
ミッドマーケット
| ユーザー: Delaney - 開発チームリード | ユーザー: Devon - DevOps エンジニア | バイヤー: Erin - アプリケーション開発エグゼクティブ から CTO* までの幅 | バイヤー: Kennedy - インフラエンジニアリングディレクター から CIO* までの幅 |
|---|---|---|---|
| コミット時に即座にコードの品質、パフォーマンス、セキュリティのフィードバックを受け取れる。チーム間でシームレスに協業できる。 | 信頼性を高め、その場しのぎでチームベースの統合を排除する。 | 単一システムで協業し、コンテキストスイッチと待ち時間を最小化し、生産性のブロッカーを特定・除去し、生産性が高く集中した開発者でより多くの価値をより速く提供する。 | カスタム統合を排除して、成長しながら信頼性とパフォーマンスを高める。単一システムをスケール・管理する。 |
* CTO（開発、外部志向）と CIO（運用、内部志向）のペルソナは開発中であり、セグメントによって異なる場合があります。
エンタープライズ
| ユーザー: Delaney - 開発チームリード | ユーザー: Devon - DevOps エンジニア | バイヤー: Erin - アプリケーション開発エグゼクティブ | バイヤー: Kennedy - インフラエンジニアリングディレクター |
|---|---|---|---|
| コミット時に即座にコードの品質、パフォーマンス、セキュリティのフィードバックを受け取れる。チーム間でシームレスに協業できる。 | 信頼性を高め、その場しのぎでチームベースの統合を排除する。 | 単一システムで協業し、コンテキストスイッチと待ち時間を最小化し、生産性のブロッカーを特定・除去し、生産性が高く集中した開発者でより多くの価値をより速く提供する。 | カスタム統合を排除して、成長しながら信頼性とパフォーマンスを高める。単一システムをスケール・管理する。 |
