[{"data":1,"prerenderedAt":773},["ShallowReactive",2],{"/ja-jp/blog/what-is-agile-development":3,"navigation-ja-jp":38,"banner-ja-jp":438,"footer-ja-jp":448,"blog-post-authors-ja-jp-GitLab Japan Team|GitLab":654,"blog-related-posts-ja-jp-what-is-agile-development":680,"assessment-promotions-ja-jp":724,"next-steps-ja-jp":764},{"id":4,"title":5,"authorSlugs":6,"body":9,"categorySlug":10,"config":11,"content":15,"description":9,"extension":27,"isFeatured":13,"meta":28,"navigation":13,"path":29,"publishedDate":22,"seo":30,"stem":35,"tagSlugs":36,"__hash__":37},"blogPosts/ja-jp/blog/what-is-agile-development.yml","What Is Agile Development",[7,8],"gitlab-japan-team","gitlab",null,"engineering",{"slug":12,"featured":13,"template":14},"what-is-agile-development",true,"BlogPost",{"heroImage":16,"body":17,"authors":18,"updatedDate":21,"date":22,"title":23,"tags":24,"description":26,"category":10},"https://res.cloudinary.com/about-gitlab-com/image/upload/v1749663632/Blog/Hero%20Images/%E3%82%A2%E3%82%B8%E3%83%A3%E3%82%A4%E3%83%AB%E9%96%8B%E7%99%BA7.jpg","アジャイル開発はシステム・ソフトウェア開発手法のひとつであり、近年注目されています。実際に自社の開発課題を解決するために、アジャイル開発の導入を検討している担当者は多いのではないでしょうか。\n\nこの記事では、アジャイル開発の概要やウォーターフォール開発との違い、導入するメリット・デメリットなどを解説します。アジャイル開発におけるAI活用や、[DevSecOps](https://about.gitlab.com/ja-jp/topics/devsecops/)の関係性についても触れているのでぜひ参考にして下さい。\n\n## 1. アジャイル開発とは？\n\n![アジャイル開発2](https://res.cloudinary.com/about-gitlab-com/image/upload/v1749687637/Blog/Content%20Images/%E3%82%A2%E3%82%B8%E3%83%A3%E3%82%A4%E3%83%AB%E9%96%8B%E7%99%BA2.jpg)\n\nアジャイル開発とは、ソフトウェア開発において通常1週間から4週間程度の反復期間を設定し、企画から開発、テストまでの工程を機能単位ごとに繰り返し進めていく開発手法のことです。「アジャイル」という言葉には、「素早い」「機敏な」という意味があり、その言葉の通りアジャイル開発はスピード感のある開発が可能です。\n\n近年ビジネス環境の変化が激しく、日々変化するニーズや市場に柔軟に対応していく姿勢が必要です。アジャイル開発ならスピード感を持って開発を進められるだけでなく、仮説検証を含めた柔軟な開発が可能になります。\n\n物事の予測が立てにくい不確実な要素が多い時代の中で、顧客ニーズにマッチした新しい価値を創造するための手法としてアジャイル開発が注目されているのです。\n\n## 2. アジャイルソフトウェア開発宣言とは？\n\n「アジャイルソフトウェア開発宣言」とは、17名のソフトウェア開発者が議論を行なって文書としてまとめたアジャイル開発の原則のことです。\n\n2001年に公開されたことをきっかけに、世界中にアジャイル開発の考え方が広まり、多くのソフトウェア開発者達に支持されました。\n\nアジャイルソフトウェア宣言では、アジャイル開発を実現するために以下の4つの価値を示しています。\n\n1. プロセスやツールよりも「個人と対話」  \n2. 包括的なドキュメントよりも「動くソフトウェア」  \n3. 契約交渉よりも「顧客との協調」  \n4. 計画に従うことよりも「変化への対応」\n\n※出典：[アジャイルソフトウェア開発宣言](https://agilemanifesto.org/iso/ja/manifesto.html)\n\n## 3. アジャイル開発とウォーターフォール開発との違い・比較\n\n![アジャイル開発5](https://res.cloudinary.com/about-gitlab-com/image/upload/v1749687637/Blog/Content%20Images/%E3%82%A2%E3%82%B8%E3%83%A3%E3%82%A4%E3%83%AB%E9%96%8B%E7%99%BA5.jpg)\nアジャイル開発が登場する前にはウォーターフォール開発が主に活用されており、ソフトウェア開発の初期段階として位置付けられています。\n\nウォーターフォール開発は機能単位ごとに開発工程を繰り返すアジャイル開発とは異なり、開発前にすべての機能計画を立て、その計画通りに開発を進める手法になります。つまり、要件定義から設計、実装、テスト、運用といった各工程を順序立てて直線的に開発を進めていきます。\n\n開発対象の機能を事前に決定して開発を進めるため、最終的なリリース時期がわかりやすいというメリットがあります。一方、開発前からすべての工程が決まっているため、仕様変更がしにくいなどの課題もあります。\n\n## 4. アジャイル開発でよく採用されている手法とは？\n\nアジャイル開発にはさまざまな開発手法がありますが、中でも「スクラム」と呼ばれる開発手法が最も採用されています。スクラムとは、少人数のチームにわかれて密にコミュニケーションをとりながら開発を進める手法です。\n\n実際に「[17th State of Agile Report](https://digital.ai/resource-center/analyst-reports/state-of-agile-report/)」の調査では、アジャイル開発手法の中で、63%がスクラムを採用していると報告されています。なお、スクラムの人気は2006年の最初の調査以降続いています。\n\nなぜ数ある開発手法の中でスクラムが最も採用されるのでしょうか。理由のひとつとして汎用性の高さにあると考えられます。スクラムはシンプルなフレームワークであり、さまざまな開発プロジェクトに活用することが可能です。\n\nまた、スクラムのルールが示された「[スクラムガイド](https://scrumguides.org/docs/scrumguide/v2020/2020-Scrum-Guide-Japanese.pdf)」は、18ページ程度の少なめのボリューム感となっており、内容もシンプルです。そのため、スクラムの全体の流れや仕組みについて理解がしやすく、自社の開発プロジェクトに合わせて応用がしやすいといえます。\n\nさらに、スクラムは有名な手法であることから開発事例も多く、情報収集が容易であるという事情も採用される理由として挙げられます。\n\n## 5. 「スクラム」以外の代表的なアジャイル開発手法\n\nスクラム以外のアジャイル開発手法には以下のようなものがあります。\n\n* エクストリーム・プログラミング（XP）\n* ユーザー機能駆動開発（FDD）\n* リーンソフトウェア開発（LSD）\n* 適応的ソフトウェア（ASD）\n\n### 5-1. エクストリーム・プログラミング（XP）\n\nエクストリーム・プログラミングは、短い開発サイクルの中で顧客の要望を柔軟に取り入れながら開発を進める手法であり、仕様変更への迅速な対応を重視しています。\n\n2人1組で開発を進める「ペアプログラミング」を採用しているのが特徴で、この作業スタイルによりコード品質の向上やトラブルの早期発見・解決などを実現できます。\n\n開発プロセスにおける状況の変化を前提とした手法であり、顧客とのやり取りも多く行われるため、ニーズを最大限に反映できる点が大きなメリットだと言えます。\n\n### 5-2. ユーザー機能駆動開発（FDD）\n\nユーザー機能駆動開発とは、ユーザーの視点から見て、本当に必要な機能に焦点を当てて開発を進める手法です。開発の流れとして、まずは全体モデルの作成によって開発の全体像を明確化します。その上で搭載すべき機能をリスト化し、機能ごとにチームを編成して計画から開発、テストを繰り返し行います。\n\n開発する機能によってチームを分けて作業を進めるため、アジャイル開発の中でも大規模で複雑なプロジェクトにも対応しやすいという特徴を持ちます。\n\n### 5-3. リーンソフトウェア開発（LSD）\n\nリーンソフトウェア開発とは、「リーン生産方式」の考えをソフトウェア開発に応用した手法を指します。リーン生産方式は、日本のトヨタ自動車から始まった考えであり、無駄を徹底的に排除し、必要なだけ製品を生産することに重きを置いた手法です。\n\nこのリーン生産方式をソフトウェア開発に取り入れたリーンソフトウェア開発では、以下の7つの原則に基づいて開発を進めるのが特徴です。\n\n1. 不要な作業などの無駄をなくす\n2. 早期に問題を解決し、品質を高める\n3. ノウハウやナレッジを蓄積する\n4. 重要な決定を遅らせる\n5. 開発メンバーを尊重する\n6. 素早くリリースする\n7. 全体の最適化を図る\n\n### 5-4. 適応的ソフトウェア（ASD）\n\n適応的ソフトウェアとは、複雑で変化の激しい開発環境に適応することを重視した手法です。以下の「思索」「協調」「学習」という3つのサイクルを繰り返して短期集中で開発を進め、成果物のクオリティを高めるのが特徴です。\n\n| 思索  | ・開発する機能の検討や手順の決定 ・主に開発計画の立案・顧客の要求分析  |\n| --- | ------------------------------------ |\n| 協調  | ・思索の計画に沿った開発の実施 ・チーム内で密にコミュニケーションを図る |\n| 学習  | ・成果物の品質のレビューを実施 ・次のイテレーションに向けた改善策の検討 |\n\nこのサイクルを繰り返すことで、継続的に変化するプロジェクトにおいても臨機応変に対応でき、高品質なソフトウェアを提供することが可能です。\n\n## 6. アジャイル開発の関連用語と代表的なKPI\n\n![アジャイル開発の関連用語と代表的なKPI](https://res.cloudinary.com/about-gitlab-com/image/upload/v1769751618/iicv5f87aeevb0ogwqje.jpg)\n\n\nアジャイル開発を導入する際には、よく使用される関連用語やKPIの理解も必要になります。\n\n### 6-1. アジャイル開発の関連用語\n\nアジャイル開発の関連用語は以下の通りです。\n\n| 用語             | 意味                                                                        |\n| -------------- | ------------------------------------------------------------------------- |\n| リリース計画         | ・アジャイル開発全体を管理するための計画 ・開発のゴールやサイクルの期間、ユーザーストーリーの優先順位などを決定する                |\n| ユーザーストーリー      | ・ユーザー視点で、「誰が」「何を」「どうしたいのか」を簡潔に記述したもの ・チームで共通認識を持つことで、ユーザーにとって価値ある機能を開発できる |\n| スプリント（イテレーション） | ・設計・開発・テスト・改善の一連の工程を短期間で繰り返す開発サイクル ・スクラム開発ではスプリントという言葉が使われる               |\n| プロダクトオーナー      | ・プロダクトにおける方向性を決定し、価値を最大化する責任を持つ ・プロダクトバックログの作成や、ステークホルダーとの調整などの役割を担う      |\n| レトロスペクティブ      | ・1回のスプリントごとに実施するミーティング ・改善点などを振り返り、次の開発サイクルに活かす                           |\n\n### 6-2. アジャイル開発の代表的なKPI\n\nアジャイル開発の代表的なKPIは以下が挙げられます。\n\n| KPI      | 意味                                                                 |     |\n| -------- | ------------------------------------------------------------------ | --- |\n| リードタイム   | ・顧客の要求を受け取ってから完了するまでの平均時間 ・リードタイムが短いほど、価値提供を迅速に行えている               |     |\n| サイクルタイム  | ・チームがある一連の作業を完了するまでの時間 ・パフォーマンス改善やボトルネックの特定に役立つ                    |     |\n| リリース頻度   | ・どのくらいの頻度でリリースできているかを測る指標 ・頻度が高いほど変化への対応力を高められる                    |     |\n| スプリント達成率 | ・設定したスプリント目標において、どのくらい達成したのかを示す指標 ・目標の妥当性やチームの成熟度を判断できる            |     |\n| 顧客満足度    | ・顧客がプロダクトや開発プロセスに対して価値を感じているかを測る指標 ・顧客の要望を最大限に反映できているかどうかが重要な要素になる | 　   |\n\n## 7. アジャイル開発の導入ステップ【初期フェーズ】\n\nアジャイル開発の導入はどのように進められるでしょうか。まずは導入の初期フェーズですべきことを解説します。\n\n1. 導入目的とゴールの明確化  \n2. チーム編成と役割の整理\n\n### 7-1. 導入目的とゴールの明確化\n\nアジャイル開発を自社のプロジェクトに導入する際には、まず「なぜアジャイルなのか」「導入することで何を解決したいのか」という目的をはっきりさせておくことが大切です。\n\nたとえば、「プロジェクトの特性上、頻繁な仕様変更が予想されるため」「現状リリースまで時間がかかっているため、アジャイル開発によってプロダクトの市場投入を早めたい」など、プロジェクトの内容や自社の課題と紐づけて目的を明らかにします。\n\nまた、プロジェクトのゴールやビジョン、KPIなども決定し、チーム全体で共有できる仕組みを構築しておきましょう。\n\n### 7-2. チーム編成と役割の整理\n\n次にアジャイル開発を進める上でチーム編成と役割の整理を行います。具体的に「誰が」「どのような責任・役割」を持つのかを明確にします。アジャイル開発は変化への柔軟性やスピードが求められる手法であるため、以下のような特徴を持つメンバーを集めるのが理想です。\n\n* 自律性・主体性があり課題に前向きに取り組める  \n* 密な情報共有やコミュニケーションを意識して行動できる など\n\nなお、スクラム開発においてはプロダクトオーナー、スクラムマスター、開発者を含めたスクラムチーム全体で10人以下で編成することが推奨されています。\n\n## 8. アジャイル開発の流れ【実行フェーズ】\n\nアジャイル開発はどのような流れで進められるでしょうか。IPAの「[アジャイル開発の進め方](https://www.ipa.go.jp/jinzai/skill-standard/plus-it-ui/itssplus/ps6vr70000001i7c-att/000065606.pdf)」を参考にスクラムを例に全体の流れを紹介します。\n\n1. プロダクトバックログの作成  \n2. スプリントプランニングの実施  \n3. 開発作業の実施\n\n### 8-1. プロダクトバックログの作成\n\nまずプロダクトバックログの作成を行います。プロダクトバックログとは、開発したいプロダクトが提供する価値をまとめたリストのことです。具体的には、顧客が求める機能やユーザーエクスペリエンスなどを洗い出してリストを作成していきます。\n\nこの際、リストは作業の優先順位をつけて並んでいることがポイントです。また、作成するリストは顧客を含むプロジェクトの関係者全員に共有する必要があるため、誰もが理解できる言葉で記載しなければなりません。\n\n### 8-2. スプリントプランニングの実施\n\n「スプリント」とは、スクラムにおける開発工程の反復（作業）期間のことです。スプリントが開始される前にスプリントプランニングを実施しましょう。具体的には、作成したプロダクトバックログのリストの中から対象のスプリントで扱う項目を選び出します。ここで選び出した項目は「スプリントバックログ」と呼ばれます。\n\nその後細かにタスクに落とし込み、スクラムチーム内で作業を分担します。なお、各タスクにおいては一般的に2〜8時間程度の時間単位で見積もられます。\n\n### 8-3. 開発作業の実施\n\n実際にスプリント内の開発作業を実施します。スプリントの途中では、スクラムチーム内で活動状況を報告する「デイリースクラム」が行われます。デイリースクラムは、達成すべきゴールに向けて課題になっていることを共有し、チーム全員が協力して解決を目指すためのミーティングです。\n\n無事にスプリントが完了した段階では「スプリントレビュー」と呼ばれるミーティングが開催され、関係者全員で完成したプロダクトのデモンストレーションを行います。\n\nまた、スプリントレビューの後には「スプリントレトロスペクティブ」が行われ、開発におけるプロセスを振り返ります。うまくいかなかったことは改善策を洗い出し、次のスプリントに活かします。\n\n## 9. アジャイル開発のメリット\n\n![アジャイル開発6](https://res.cloudinary.com/about-gitlab-com/image/upload/v1749687637/Blog/Content%20Images/%E3%82%A2%E3%82%B8%E3%83%A3%E3%82%A4%E3%83%AB%E9%96%8B%E7%99%BA6.jpg)\nアジャイル開発には以下のようなメリットがあります。\n\n* 開発スピードが早い  \n* ユーザーのニーズを反映しやすい  \n* 手戻りの発生を防止・軽減しやすい  \n* 継続的な学習と改善の機会が得られる\n\n### 9-1. 開発スピードが早い\n\nアジャイル開発は機能を小さな単位にわけて開発とリリースを繰り返して進めるため、結果的に優先度の高い機能から素早く価値を提供することが可能です。また、最初にプロダクトのすべての機能計画を立ててから開発するわけではないため、本来不要だった機能に関するドキュメント作成などに時間と手間をかけずに開発を進められます。\n\n一方、ウォーターフォール開発の場合は計画を重視することから、開発前に要件定義書や設計書などの作成に時間をかける必要があります。ビジネスにおいて「競合優位性を確立したい」「早期に顧客のフィードバックを収集したい」などの目的があるなら、小さな単位で素早く価値を提供できるアジャイル開発の採用が適切だといえます。\n\n### 9-2. ユーザーのニーズを反映しやすい\n\nアジャイル開発は小さな単位で開発を進めるため、開発途中で顧客の要望や市場の変化に応じて優先順位や仕様を見直すことができます。顧客ニーズや市場調査の結果を踏まえながら柔軟に開発を進めることで最大限の価値を提供できるため、顧客満足度の向上にもつながります。\n\n一方、ウォーターフォール開発ではプロジェクトの初期段階で計画を確定させるため、途中での変更が困難になりがちです。ただし、アジャイル開発で変更に対応できるといっても、変更自体のコストや影響度は慎重に評価する必要があります。\n\nたとえば、すでに開発した機能に大きな変更が必要な場合は、再設計や再実装のコストが発生します。アジャイル開発は変更を受け入れやすい仕組みを持っていますが、それはすべての変更が容易であることを意味するわけではありません。\n\n### 9-3. 手戻りの発生を防止・軽減しやすい\n\nアジャイル開発は機能単位に区切って開発からテスト、リリースまで実行するため、テストの段階で不具合や問題が発生した場合でも手戻りの工数を最小限に抑えられます。\n\nウォーターフォール開発の場合は、事前に決めた計画通りに開発を進めるため、不具合が発生した箇所によっては手戻りの工数が大きくなってしまうデメリットがあります。アジャイル開発なら、前提として開発している範囲が少ないため、大きな手戻りが発生しにくいです。\n\n### 9-4. 継続的な学習と改善の機会が得られる\n\nアジャイル開発では、小さな単位での開発を繰り返し、振り返りを行うプロセスが組み込まれています。これにより、チームは実践と改善を重ねながら学習を進める機会を得られます。たとえば、スプリントごとの振り返り（スプリントレトロスペクティブ）では、うまくいったことや課題を議論し、より良い進め方を模索します。\n\nまた、開発途中では毎日ミーティングが実施され、品質の高いプロダクトを生み出せるようメンバー同士が意見を出し合います。そのようなプロセスを通してチームワークの向上も期待できるでしょう。\n\n## 10. アジャイル開発のデメリット\n\n![アジャイル開発4](https://res.cloudinary.com/about-gitlab-com/image/upload/v1749687637/Blog/Content%20Images/%E3%82%A2%E3%82%B8%E3%83%A3%E3%82%A4%E3%83%AB%E9%96%8B%E7%99%BA4.jpg)\nアジャイル開発にはデメリットもあるため、対策を踏まえて把握しておくことが大切です。\n\n* 長期的な見通しの立て方が従来と異なる  \n* プロダクトの方向性を維持するための工夫が必要\n\n### 10-1. 長期的な見通しの立て方が従来と異なる\n\nアジャイル開発では、詳細な計画を前もって確定させない代わりに、反復的な開発を通じて計画を継続的に見直し、調整していきます。そのため、従来のウォーターフォール型開発のように、プロジェクト全体の詳細なスケジュールを初期段階で確定することは難しくなります。また、顧客の要望で何度も仕様変更が発生した場合、最終リリースまでのスケジュールが伸びてしまう可能性もあります。\n\nアジャイル開発において適切なスケジュール管理を行うためには、チームの開発速度を計測、定期的に計画と実績を比較し、場合によっては優先順位や計画を見直す必要があります。\n\n### 10-2. プロダクトの方向性を維持するための工夫が必要\n\nアジャイル開発では、開発途中での変更を受け入れやすい特徴がある一方で、その柔軟性を適切にコントロールしなければ、本来目指していたプロダクトの方向性から逸れてしまうリスクがあります。\n\nたとえば、顧客からの仕様変更や機能追加の要望を受け入れ過ぎていると、プロジェクト全体の方向性を見失ってしまう場合があります。また、顧客との摩擦や齟齬が生まれてしまう可能性もあり、プロジェクトがスムーズに進まないという事態も招いてしまうでしょう。\n\nこのようなことを避けるためには、個々の単位だけでなく定期的な全体像の把握と、関係性全員での認識の擦り合わせが必要です。\n\n## 11. アジャイル開発が向いている・向いていないプロジェクト\n\nアジャイル開発にはさまざまなメリットがありますが、プロジェクトの特性・内容によっては向き・不向きがあるため事前に把握し、自社に適した開発手法を採用しなければなりません。\n\n### 11-1. アジャイル開発が向いているプロジェクト\n\nまずアジャイル開発が向いているプロジェクトは以下の通りです。\n\n* 頻繁な仕様変更・追加の可能性がある  \n* 試行錯誤しながら開発を進めるプロジェクト  \n* 発注者が積極的に開発プロセスに参加する\n\n#### 11-1-1. 頻繁な仕様変更・追加の可能性がある\n\nアジャイル開発は、頻繁な仕様変更や優先順位の変更が想定されるプロジェクトに向いています。これは事前に綿密な計画を立てずに機能ごとに開発を進めることから、急な変更が生じた場合でも少ない手戻りで対応できるからです。\n\nたとえば、Webサービスやスマホアプリ開発の案件においては市場のトレンドに応じて仕様変更や機能追加が頻繁に発生しやすいため、アジャイル開発なら柔軟な対応を実現できるでしょう。\n\n#### 11-1-2. 試行錯誤しながら開発を進めるプロジェクト\n\n仮説ベースで機能開発を進めるといった探索的なプロジェクトにおいてもアジャイル開発が向いています。プロジェクトの大まかな方向性さえ決まっていれば、細かな要件が確定していなくてもアジャイル開発なら試行錯誤しながら作業を進められます。\n\nたとえば、実際に市場に投入してみて「想定していたよりユーザーの反応が良くなかった」など仮説が外れた要素がある場合でも、その後新たな機能開発を検討するなどの対応が可能です。\n\n#### 11-1-3. 発注者が積極的に開発プロセスに参加する\n\nアジャイル開発は顧客からの要望を頻繁に取り入れることを重視した手法であるため、発注者が積極的に開発プロセスに関わるプロジェクトでも向いています。\n\n発注者が開発チームの一員として細かに意見したいという姿勢がプロジェクト開始前から見られる場合は、アジャイル開発を採用することでフィードバックを最大限に活かした精度の高いソフトウェア開発を実現できるでしょう。\n\n### 11-2. アジャイル開発が向いていないプロジェクト\n\n以下のようなケースではアジャイル開発に向かないため、導入は慎重に検討すべきです。\n\n* 要件が明確かつ納期厳守を求められる  \n* 関係者間での円滑なコミュニケーションが難しい  \n* 規制や要件が厳しい業界での開発\n\n#### 11-2-1. 要件が明確かつ納期厳守を求められる\n\n大前提として要件が明確に決められており、開発途中での仕様変更の可能性が低いプロジェクトではアジャイル開発の柔軟性を活かすことはできないでしょう。\n\n固定された要件と納期・コストの両方が明確に存在するケースでは、ウォーターフォール型開発の方が適しています。\n\n#### 11-2-2. 関係者間での円滑なコミュニケーションが難しい\n\n状況的に開発関係者間での円滑なコミュニケーションをとることが難しいケースでもアジャイル開発の採用は厳しい可能性が高いと言えます。たとえば、プロジェクトの特性上多くのステークホルダーが集まる場合、アジャイル開発で求められる頻繁なミーティングの実施が難しいでしょう。\n\nその他にも、開発メンバー間の物理的な距離の問題もコミュニケーションの希薄化を生む原因になります。\n\nアジャイル開発は積極的な意見交換によって品質の向上や早期の課題解決を目指すため、上記のようなケースでコミュニケーションが活性化しないと開発が上手く進まないリスクがあります。\n\n#### 11-2-3. 規制や要件が厳しい業界での開発\n\n政府や医療、金融関連などの規制や要件が厳しい業界では、安全性や有効性、健全性を確保するために厳格なドキュメント作成や複数回に及ぶ承認プロセスが求められるケースがあります。\n\nそういったケースでアジャイル開発を採用する場合は、ドキュメントや承認プロセスをアジャイルの開発プロセスに組み込む工夫が必要になります。さまざまな規制に対する対応とアジャイルの両立を図るためには、適切なツールや体制の整備が求められます。  \n\n## 12. アジャイル開発を成功させるためのポイント\n\n![アジャイル開発8](https://res.cloudinary.com/about-gitlab-com/image/upload/v1749687637/Blog/Content%20Images/%E3%82%A2%E3%82%B8%E3%83%A3%E3%82%A4%E3%83%AB%E9%96%8B%E7%99%BA8.jpg)\n\nアジャイル開発を成功させるために以下のポイントを押さえておきましょう。\n\n* アジャイル開発の特性を理解した人材を選定する  \n* メンバー間で密にコミュニケーションをとる  \n* [CI/CD](https://about.gitlab.com/ja-jp/blog/what-is-ci-cd/)など自動化のテクノロジーを取り入れる  \n* 情報の透明性を保つ\n\n### 12-1. アジャイル開発の特性を理解した人材を選定する\n\nアジャイル開発では、柔軟な仕様変更に伴うメンバー間での擦り合わせや協力が重要となります。必ずしもアジャイル開発の経験が豊富である必要はありませんが、ここまで紹介してきたようなアジャイル開発の特徴を理解し、オープンな姿勢でチームや関係者とコミュニケーションを取れる人材が求められます。\n\n「プロダクトオーナー」や開発チームを支援する「スクラムマスター」の役割も重要です。場合によってはアジャイルコーチによるトレーニングを活用したり、経験豊富な外部の専門家にサポートを依頼したりすることも有効です。\n\n### 12-2. メンバー間で密にコミュニケーションをとる\n\nアジャイル開発を成功に導くためには、顧客を含めた関係者全員がコミュニケーションを密にとっていくことが大切です。先ほど説明したような「デイリースクラム」や「スプリントレビュー」などのミーティングを定期的に実施し、メンバー間でのコミュニケーションを活性化させましょう。\n\nチームメンバーが自由に意見を出しやすい雰囲気の中で開発を進めることで、進捗管理や品質の維持もしやすくなります。特に上下関係などの関係性を取り払って、お互いが率直に提案や指摘をし合えるような環境ならプロジェクトの成功率をより高められるでしょう。\n\n### 12-3. CI/CDなど自動化のテクノロジーを取り入れる\n\nアジャイル開発をスムーズに進めるためには、[CI/CD](https://about.gitlab.com/ja-jp/blog/what-is-ci-cd/)など自動化のテクノロジーを取り入れることもポイントです。[CI/CD](https://about.gitlab.com/ja-jp/blog/what-is-ci-cd/)とは、顧客にプロダクトを素早く提供するために、ビルド作業やテスト、リリースの工程といった、開発フローの一部を自動化する手法のことです。\n\nアジャイル開発と[CI/CD](https://about.gitlab.com/ja-jp/blog/what-is-ci-cd/)の相性は良く、機能単位ごとの開発フローを[CI/CD](https://about.gitlab.com/ja-jp/blog/what-is-ci-cd/)によって自動化することによって、一定の品質を維持したままリリース頻度の向上を実現できます。[CI/CD](https://about.gitlab.com/ja-jp/blog/what-is-ci-cd/)については以下の記事で解説しているので、併せてチェックしてみてください。\n\n[CI/CDとは？意味や導入のメリット・デメリット、ツールの選び方を解説](https://about.gitlab.com/ja-jp/blog/what-is-ci-cd/)\n\n### 12-4. 情報の透明性を保つ\n\nアジャイル開発においてはチームメンバーと顧客との間で信頼関係を構築することが求められます。顧客側が開発の中でどのようなことが行われているのかが把握できないと不安を抱いてしまいます。たとえば、成果物が納品されるまで状況を掴めないような進め方だと、認識の齟齬が生まれる原因になるでしょう。\n\nそのため、アジャイル開発で扱う情報においては常に透明性をもたせることが大事です。\n\nたとえば、以下のような情報に透明性をもたせて、顧客とチームメンバーとの間でスムーズに情報共有できるような仕組みを構築しておきましょう。\n\n* 全体の開発スケジュール  \n* 開発の作業内容  \n* 開発メンバーの保有スキル  \n* 開発の進捗状況 など\n\n情報の透明性を保ち、チームの誰でも同じ情報にアクセスできる状態のことをSingle Source Of Truth（SSOT、信頼できる唯一の情報源）と呼び、これがあることでチームの自律的な行動を促すことができます。こちらに関する記事は下記が詳しいため、併せてチェックしてみてください。\n\n[組織の自律自走を促すコミュニケーション](https://learn.gitlab.com/c/effective-communication-for-autonomous-organization-deck?x=JBqxmQ)\n\n## 13. GitLab活用によるアジャイル開発の成功事例　\n\nアジャイル開発の成功事例として、[GitLab](https://about.gitlab.com/ja-jp/)を導入したドイツテレコム社のケースを紹介します。\n\n同社は、ソフトウェアの市場投入までの時間に対して大きな課題を抱えていました。ソフトウェア開発ライフサイクルの効率化のために既にウォーターフォール型開発からアジャイル開発手法へと移行していたものの、各チームが使用する自動化ツールに一貫性がなく、DevOpsの土台となるプラットフォーム構築の必要性を感じていました。\n\nそこでCI/CDやAIなどの自動化テクノロジーを活用できるGitLabを導入したことによって、社内の多くの開発者がアジャイルプログラムで共通のツールを使用するようになり、生産性向上や市場投入までの時間短縮を実現しています。\n\nドイツテレコム社の事例詳細については以下の記事をご覧ください。\n\n※参考：[ドイツテレコムがGitLab UltimateでDevSecOpsの変革を推進](https://about.gitlab.com/ja-jp/customers/deutsche-telekom/)\n\n## 14. アジャイル開発が失敗してしまうケース例\n\n![アジャイル開発が失敗してしまうケース例](https://res.cloudinary.com/about-gitlab-com/image/upload/v1769751618/v4300f3dapcwei94ndeq.jpg)\n\n\n\nアジャイル開発が失敗してしまうケース例としては以下が挙げられます。\n\n* アジャイル開発に対する理解不足  \n* アジャイル開発に不向きなプロジェクトで採用している  \n* チーム内のコミュニケーション不全  \n* リーダーの機能不全\n\n### 14-1. アジャイル開発に対する理解不足\n\nアジャイル開発においては、急な仕様変更や市場の変化に迅速に対応するため、予算やスケジュールもその都度柔軟に変更する姿勢が求められます。\n\nその際、発注側の現場担当者がアジャイルの特性について理解していても、経営層に理解がなければ予算やスケジュール変更の承認が下りない可能性があります。その結果、プロジェクトがスムーズに進まず失敗に繋がるという結果を招いてしまうでしょう。\n\nアジャイル開発を成功に導くためには、経営層もアジャイルの本質を十分に理解し、変化に強い開発体制を構築しておくことが求められます。\n\n### 14-2. アジャイル開発に不向きなプロジェクトで採用している\n\n大前提としてアジャイル開発に不向きなプロジェクトでの導入は失敗を招く可能性が高くなります。\n\n先ほども紹介したようにアジャイル開発には向き不向きがあるため、プロジェクトの特性や自社の課題を考慮しながら本当にアジャイル開発の導入が自社の目標達成に貢献するのか慎重に見極めなければなりません。正確な導入可否の判断を行うためには、責任者がアジャイル開発の強み・本質も十分に理解しておく必要があります。\n\n### 14-3. チーム内のコミュニケーション不全\n\nアジャイル開発は状況の変化に応じてその都度対応しながら開発を進めるため、チーム内での細かなコミュニケーションが重要な要素になります。\n\nチーム内でのコミュニケーションが機能していない場合、認識のズレが生まれ、後の工程で手戻りが発生するなどのトラブルが起こる可能性があります。コミュニケーションが不足してしまう原因としては、メンバーが自由に意見を出し合えるような心理的安全性が現場で確保されていないことが考えられます。リーダーが中心となり、メンバー同士が提案や指摘を積極的に行える環境を構築することが大切です。\n\n### 14-4. リーダーの機能不全\n\nプロダクトオーナーやスクラムマスターのようなアジャイル開発を成功に導くために重要となる存在が本来の役割や責任を果たせていない場合、メンバーが最大限のパフォーマンスを発揮できません。\n\nたとえば、プロダクトオーナーが十分な決定権を持っていないと意思決定の遅延や方向性のブレなどが生じてしまうため、メンバーを正しくリードできないでしょう。その結果、生産性やプロダクト品質の低下を招いてしまいます。\n\nそのような失敗を招かないためには、リーダーは自身の役割を自覚して行動することが求められます。\n\n## 15. アジャイル開発におけるセキュリティの課題\n\nアジャイル開発では、仕様変更や機能追加などに対して柔軟に対応でき、スピード感を持って開発を進められます。その一方で、セキュリティが後回しにされたり、おろそかにしてしまったりするケースも多いといわれています。この課題に対応するには、リリース直前に実施される人手による脆弱性診断やペネトレーションテストだけでなく、静的解析ツールやコンテナスキャンなどの自動化されたセキュリティテストを[CI/CD](https://about.gitlab.com/ja-jp/blog/what-is-ci-cd/)パイプラインに組み込むことが効果的です。\n\nなお、セキュリティ対策の重要性はアジャイル開発に限ったことではありません。[IPAの調査](https://www.ipa.go.jp/security/10threats/10threats2024.html)から近年組織ではさまざまなセキュリティインシデントが発生していることがわかります。開発の早い段階でセキュリティ上の問題を発見し、迅速な対応が可能になるこれらのプラクティスは「シフトレフト」と呼ばれ、セキュリティリスクをより早い段階で見つけ、手戻りを少なく品質をあげていく手法として、アジャイル開発以外での開発手法でも重要であると言われています。\n\n## 16. アジャイル開発とAI・DevSecOps・DXトレンドとの接続強化の重要性\n\n![アジャイル開発1](https://res.cloudinary.com/about-gitlab-com/image/upload/v1749687637/Blog/Content%20Images/%E3%82%A2%E3%82%B8%E3%83%A3%E3%82%A4%E3%83%AB%E9%96%8B%E7%99%BA1.jpg)\n\n近年はAI・DevSecOps・DXといった新しい技術やアプローチが登場し、アジャイル開発との連携が重要視されています。\n\n### 16-1. アジャイル開発におけるAI活用\n\nアジャイル開発を採用する際には、AIを積極的に活用する視点も持っておきましょう。\n\nたとえば、前述の通り、アジャイル開発ではリリース直前での脆弱性診断だけでなく、開発段階などでも常時セキュリティスキャンなどで脆弱性を検出することが重要です。この時に[GitLab Duo](https://about.gitlab.com/ja-jp/gitlab-duo/)のようなAIを活用することによってソフトウェアの脆弱性をより効率的に把握して修正でき、開発におけるセキュリティリスクを軽減することができます。\n\nその他にも、テストコードを書いたり、ソースコードからドキュメントから詳細設計書やパラメータシート相当のものを作成するなど、特にアジャイル開発でよく行われることにAIの支援を受けることができ、開発効率の向上を実現することができます。\n\nこれらの機能のデモもありますので、参考にしていただければと思います。\n\n\u003Ciframe width=\"560\" height=\"315\" src=\"https://www.youtube.com/embed/jygdsxzBC4Y?si=yqKD7QvVVYHdhGhK\" title=\"YouTube video player\" frameborder=\"0\" allow=\"accelerometer; autoplay; clipboard-write; encrypted-media; gyroscope; picture-in-picture; web-share\" referrerpolicy=\"strict-origin-when-cross-origin\" allowfullscreen>\u003C/iframe>\n\n## 16-2. アジャイル開発とDevSecOpsの関係性\n\n先ほど挙げたアジャイル開発のセキュリティの課題においては「[DevSecOps](https://about.gitlab.com/ja-jp/topics/devsecops/)」の必要性が高まっています。\n\n[DevSecOps](https://about.gitlab.com/ja-jp/topics/devsecops/)とは、開発（Dev）・セキュリティ（Sec）・運用（Ops）を連携した開発アプローチのことです。[DevSecOps](https://about.gitlab.com/ja-jp/topics/devsecops/)では、セキュリティを後回しにすることなく、開発工程（Dev）の段階で対策を行い、ソフトウェアの安全性を高めます。\n\nアジャイル開発と[DevSecOps](https://about.gitlab.com/ja-jp/topics/devsecops/)は親和性が高く、両者とも迅速なリリースと継続的な改善を推進する手法や考え方です。つまり、アジャイル開発において[DevSecOps](https://about.gitlab.com/ja-jp/topics/devsecops/)のアプローチも取り入れることで、セキュリティレベルを高めながら、迅速なソフトウェア開発を実現できます。補足として、アジャイル開発と同様、ウォーターフォール開発でもDevSecOpsの考え方は積極的に取り入れるべきポイントです。\n\nなお、「[GitLab](https://about.gitlab.com/ja-jp/)」なら[DevSecOps](https://about.gitlab.com/ja-jp/topics/devsecops/)のアプローチを踏まえたソフトウェア開発が可能です。アジャイル開発の代表的手法である「スクラム」を1つのプラットフォームで運用することもできるため、ぜひ自社のプロジェクトにお役立て下さい。\n\n### 16-3. アジャイル開発がDX推進に必要とされる理由　\n\nアジャイル開発はDX推進に大きく貢献する手法でもあります。DX（デジタルトランスフォーメーション）とは、IT技術を活用して企業のビジネスモデルや業務プロセスを改革し、顧客や社会に対して新しい価値を提供する取り組みを指します。\n\nDX施策においては新しい技術を積極的に導入することから不確実性が高く、さらに市場の変化にも柔軟に対応しなければなりません。\n\n開発途中の仕様変更に強みを持つアジャイル開発ならDXプロジェクトとの親和性が高く、試行錯誤しながら段階的に開発を進められるため、自社の目標を達成しやすくなるでしょう。\n\n## 17. 開発だけではないビジネス領域におけるアジャイルの取り組み　\n\n「アジャイル」という概念は、開発領域だけでなく企業の組織改革のためのアプローチとしても注目が集まっています。具体的には、競争が激化するビジネス環境の中で柔軟かつ迅速の対応ができる「アジャイル組織」と呼ばれる組織構造があります。\n\nアジャイル開発と同じく、短期間で実行と改善・検証を繰り返して戦略を進めるのが特徴で、ボトムアップによる意思決定スタイルが採用されます。これにより、業務における意思決定スピードが加速化し、企業の競争力の強化にも繋げられます。\n\n## 18. アジャイル開発に関するQ＆A\n\n![アジャイル開発3](https://res.cloudinary.com/about-gitlab-com/image/upload/v1749687637/Blog/Content%20Images/%E3%82%A2%E3%82%B8%E3%83%A3%E3%82%A4%E3%83%AB%E9%96%8B%E7%99%BA3.jpg)\n最後にアジャイル開発に関するQ＆Aを紹介します。\n\n### 18-1. アジャイル開発の普及率は？\n\n「[DX白書2023](https://www.ipa.go.jp/publish/wp-dx/gmcbt8000000botk-att/000108041.pdf)」によると、アジャイル開発を「全社的に活用している」「事業部で活用している」と回答した企業の割合の合計は22.9%となっています。米国の場合は53.9%となっているため、アジャイル開発の普及率において日米差は大きいことがわかります。\n\n### 18-2. アジャイル開発手法の選び方は？　\n\nアジャイル開発にはさまざまな手法がありますが、自社の状況や目的にあわせて最適な手法を選ぶ必要があります。なお、複数の手法を組み合わせるなどの方法も検討できます。\n\n以下で選定のポイントと例を紹介します。\n\n* チーム規模\n\n【例】チーム全体で10人以下の小規模なチームならスクラムを採用する\n\n* プロジェクトの特性\n\n【例】仮説ベースで開発を進め、仕様変更が多いプロジェクトならスクラムやXPを採用する\n\n* 重視する要素\n\n【例】ユーザーにとって価値の高い機能からリリースしたいならFDDを採用する\n\n## まとめ アジャイル開発の特徴を十分に理解して自社で導入しよう\n\nアジャイル開発なら、開発途中で発生する急な仕様変更にも柔軟に対応でき、顧客ニーズにマッチした価値を提供することが可能です。\n\nしかし、アジャイル開発に限ったことではないですがセキュリティ対策における課題もあるため、[DevSecOps](https://about.gitlab.com/ja-jp/topics/devsecops/)のアプローチも積極的に取り入れていく姿勢も求められます。\n\n[DevSecOps](https://about.gitlab.com/ja-jp/topics/devsecops/)プラットフォームを提供する[GitLab](https://about.gitlab.com/ja-jp/)では、世界39か国、5,000人を超えるDevSecOps専門家のインサイトが詰まった完全版レポートを無料で公開しています。ソフトウェア開発におけるAI活用や、[DevSecOps](https://about.gitlab.com/ja-jp/topics/devsecops/)に興味がある人はぜひご覧下さい。\n\n> [2025グローバルDevSecOpsレポートはこちら](https://about.gitlab.com/ja-jp/developer-survey/japan/?utm_medium=blog&utm_source=blog&utm_campaign=eg_apac_brand_x_x_ja_gitlabjapanblogseo_what-is-agile-development)  \n\n*監修：佐々木 直晴 [@naosasaki](https://gitlab.com/naosasaki) （GitLab合同会社 ソリューションアーキテクト本部 シニアソリューションアーキテクト）*",[19,20],"GitLab Japan Team","GitLab","2026-01-28","2025-03-06","アジャイル開発とは？意味や進め方、DevSecOpsとの関係性を解説",[25],"agile","この記事では、アジャイル開発の概要やウォーターフォール開発との違い、導入するメリット・デメリットなどを解説します。","yml",{},"/ja-jp/blog/what-is-agile-development",{"ogTitle":23,"ogImage":16,"ogDescription":26,"ogSiteName":31,"noIndex":32,"ogType":33,"ogUrl":34,"title":23,"canonicalUrls":34,"description":26},"https://about.gitlab.com",false,"article","https://about.gitlab.com/blog/what-is-agile-development","ja-jp/blog/what-is-agile-development",[25],"Vjywn4d-IAquJxpryNp1EUQn_O4mR0lBiSVv9Kj8YCs",{"data":39},{"logo":40,"freeTrial":45,"sales":50,"login":55,"items":60,"search":368,"minimal":401,"duo":418,"pricingDeployment":428},{"config":41},{"href":42,"dataGaName":43,"dataGaLocation":44},"/ja-jp/","gitlab logo","header",{"text":46,"config":47},"無料トライアルを開始",{"href":48,"dataGaName":49,"dataGaLocation":44},"https://gitlab.com/-/trial_registrations/new?glm_source=about.gitlab.com&glm_content=default-saas-trial/","free trial",{"text":51,"config":52},"お問い合わせ",{"href":53,"dataGaName":54,"dataGaLocation":44},"/ja-jp/sales/","sales",{"text":56,"config":57},"サインイン",{"href":58,"dataGaName":59,"dataGaLocation":44},"https://gitlab.com/users/sign_in/","sign in",[61,88,184,189,290,350],{"text":62,"config":63,"cards":65},"プラットフォーム",{"dataNavLevelOne":64},"platform",[66,72,80],{"title":62,"description":67,"link":68},"DevSecOpsに特化したインテリジェントオーケストレーションプラットフォーム",{"text":69,"config":70},"プラットフォームを詳しく見る",{"href":71,"dataGaName":64,"dataGaLocation":44},"/ja-jp/platform/",{"title":73,"description":74,"link":75},"GitLab Duo Agent Platform","ソフトウェアライフサイクル全体を支えるエージェント型AI",{"text":76,"config":77},"GitLab Duoのご紹介",{"href":78,"dataGaName":79,"dataGaLocation":44},"/ja-jp/gitlab-duo-agent-platform/","gitlab duo agent platform",{"title":81,"description":82,"link":83},"GitLabが選ばれる理由","エンタープライズがGitLabを選ぶ主な理由をご覧ください",{"text":84,"config":85},"詳細はこちら",{"href":86,"dataGaName":87,"dataGaLocation":44},"/ja-jp/why-gitlab/","why gitlab",{"text":89,"left":13,"config":90,"link":92,"lists":96,"footer":166},"製品",{"dataNavLevelOne":91},"solutions",{"text":93,"config":94},"すべてのソリューションを表示",{"href":95,"dataGaName":91,"dataGaLocation":44},"/ja-jp/solutions/",[97,122,144],{"title":98,"description":99,"link":100,"items":105},"自動化","CI/CDと自動化でデプロイを加速",{"config":101},{"icon":102,"href":103,"dataGaName":104,"dataGaLocation":44},"AutomatedCodeAlt","/ja-jp/solutions/delivery-automation/","automated software delivery",[106,110,113,118],{"text":107,"config":108},"CI/CD",{"href":109,"dataGaLocation":44,"dataGaName":107},"/ja-jp/solutions/continuous-integration/",{"text":73,"config":111},{"href":78,"dataGaLocation":44,"dataGaName":112},"gitlab duo agent platform - product menu",{"text":114,"config":115},"ソースコード管理",{"href":116,"dataGaLocation":44,"dataGaName":117},"/ja-jp/solutions/source-code-management/","Source Code Management",{"text":119,"config":120},"自動化されたソフトウェアデリバリー",{"href":103,"dataGaLocation":44,"dataGaName":121},"Automated software delivery",{"title":123,"description":124,"link":125,"items":130},"セキュリティ","セキュリティを犠牲にすることなくコード作成を高速化",{"config":126},{"href":127,"dataGaName":128,"dataGaLocation":44,"icon":129},"/ja-jp/solutions/application-security-testing/","security and compliance","ShieldCheckLight",[131,135,140],{"text":132,"config":133},"Application Security Testing",{"href":127,"dataGaName":134,"dataGaLocation":44},"Application security testing",{"text":136,"config":137},"ソフトウェアサプライチェーンの安全性",{"href":138,"dataGaLocation":44,"dataGaName":139},"/ja-jp/solutions/supply-chain/","Software supply chain security",{"text":141,"config":142},"Software Compliance",{"href":143,"dataGaName":141,"dataGaLocation":44},"/ja-jp/solutions/software-compliance/",{"title":145,"link":146,"items":151},"測定",{"config":147},{"icon":148,"href":149,"dataGaName":150,"dataGaLocation":44},"DigitalTransformation","/ja-jp/solutions/visibility-measurement/","visibility and measurement",[152,156,161],{"text":153,"config":154},"可視性と測定",{"href":149,"dataGaLocation":44,"dataGaName":155},"Visibility and Measurement",{"text":157,"config":158},"バリューストリーム管理",{"href":159,"dataGaLocation":44,"dataGaName":160},"/ja-jp/solutions/value-stream-management/","Value Stream Management",{"text":162,"config":163},"分析とインサイト",{"href":164,"dataGaLocation":44,"dataGaName":165},"/ja-jp/solutions/analytics-and-insights/","Analytics and insights",{"title":167,"items":168},"GitLabが活躍する場所",[169,174,179],{"text":170,"config":171},"Enterprise",{"href":172,"dataGaLocation":44,"dataGaName":173},"/ja-jp/enterprise/","enterprise",{"text":175,"config":176},"スモールビジネス",{"href":177,"dataGaLocation":44,"dataGaName":178},"/ja-jp/small-business/","small business",{"text":180,"config":181},"公共機関",{"href":182,"dataGaLocation":44,"dataGaName":183},"/ja-jp/solutions/public-sector/","public sector",{"text":185,"config":186},"価格",{"href":187,"dataGaName":188,"dataGaLocation":44,"dataNavLevelOne":188},"/ja-jp/pricing/","pricing",{"text":190,"config":191,"link":193,"lists":197,"feature":277},"関連リソース",{"dataNavLevelOne":192},"resources",{"text":194,"config":195},"すべてのリソースを表示",{"href":196,"dataGaName":192,"dataGaLocation":44},"/ja-jp/resources/",[198,231,249],{"title":199,"items":200},"はじめに",[201,206,211,216,221,226],{"text":202,"config":203},"インストール",{"href":204,"dataGaName":205,"dataGaLocation":44},"/ja-jp/install/","install",{"text":207,"config":208},"クイックスタートガイド",{"href":209,"dataGaName":210,"dataGaLocation":44},"/ja-jp/get-started/","quick setup checklists",{"text":212,"config":213},"学ぶ",{"href":214,"dataGaLocation":44,"dataGaName":215},"https://university.gitlab.com/","learn",{"text":217,"config":218},"製品ドキュメント",{"href":219,"dataGaName":220,"dataGaLocation":44},"https://docs.gitlab.com/","product documentation",{"text":222,"config":223},"ベストプラクティスビデオ",{"href":224,"dataGaName":225,"dataGaLocation":44},"/ja-jp/getting-started-videos/","best practice videos",{"text":227,"config":228},"インテグレーション",{"href":229,"dataGaName":230,"dataGaLocation":44},"/ja-jp/integrations/","integrations",{"title":232,"items":233},"検索する",[234,239,244],{"text":235,"config":236},"お客様成功事例",{"href":237,"dataGaName":238,"dataGaLocation":44},"/ja-jp/customers/","customer success stories",{"text":240,"config":241},"ブログ",{"href":242,"dataGaName":243,"dataGaLocation":44},"/ja-jp/blog/","blog",{"text":245,"config":246},"リモート",{"href":247,"dataGaName":248,"dataGaLocation":44},"https://handbook.gitlab.com/handbook/company/culture/all-remote/","remote",{"title":250,"items":251},"つなげる",[252,257,262,267,272],{"text":253,"config":254},"GitLabサービス",{"href":255,"dataGaName":256,"dataGaLocation":44},"/ja-jp/services/","services",{"text":258,"config":259},"コミュニティ",{"href":260,"dataGaName":261,"dataGaLocation":44},"/community/","community",{"text":263,"config":264},"フォーラム",{"href":265,"dataGaName":266,"dataGaLocation":44},"https://forum.gitlab.com/","forum",{"text":268,"config":269},"イベント",{"href":270,"dataGaName":271,"dataGaLocation":44},"/events/","events",{"text":273,"config":274},"パートナー",{"href":275,"dataGaName":276,"dataGaLocation":44},"/ja-jp/partners/","partners",{"backgroundColor":278,"textColor":279,"text":280,"image":281,"link":285},"#2f2a6b","#fff","ソフトウェア開発の未来への洞察",{"altText":282,"config":283},"ソースプロモカード",{"src":284},"https://res.cloudinary.com/about-gitlab-com/image/upload/v1758208064/dzl0dbift9xdizyelkk4.svg",{"text":286,"config":287},"最新情報を読む",{"href":288,"dataGaName":289,"dataGaLocation":44},"/ja-jp/the-source/","the source",{"text":291,"config":292,"lists":294},"会社情報",{"dataNavLevelOne":293},"company",[295],{"items":296},[297,302,308,310,315,320,325,330,335,340,345],{"text":298,"config":299},"GitLabについて",{"href":300,"dataGaName":301,"dataGaLocation":44},"/ja-jp/company/","about",{"text":303,"config":304,"footerGa":307},"採用情報",{"href":305,"dataGaName":306,"dataGaLocation":44},"/jobs/","jobs",{"dataGaName":306},{"text":268,"config":309},{"href":270,"dataGaName":271,"dataGaLocation":44},{"text":311,"config":312},"経営陣",{"href":313,"dataGaName":314,"dataGaLocation":44},"/company/team/e-group/","leadership",{"text":316,"config":317},"チーム",{"href":318,"dataGaName":319,"dataGaLocation":44},"/company/team/","team",{"text":321,"config":322},"ハンドブック",{"href":323,"dataGaName":324,"dataGaLocation":44},"https://handbook.gitlab.com/","handbook",{"text":326,"config":327},"投資家向け情報",{"href":328,"dataGaName":329,"dataGaLocation":44},"https://ir.gitlab.com/","investor relations",{"text":331,"config":332},"トラストセンター",{"href":333,"dataGaName":334,"dataGaLocation":44},"/ja-jp/security/","trust center",{"text":336,"config":337},"AI Transparency Center",{"href":338,"dataGaName":339,"dataGaLocation":44},"/ja-jp/ai-transparency-center/","ai transparency center",{"text":341,"config":342},"ニュースレター",{"href":343,"dataGaName":344,"dataGaLocation":44},"/company/contact/#contact-forms","newsletter",{"text":346,"config":347},"プレス",{"href":348,"dataGaName":349,"dataGaLocation":44},"/press/","press",{"text":51,"config":351,"lists":352},{"dataNavLevelOne":293},[353],{"items":354},[355,358,363],{"text":51,"config":356},{"href":53,"dataGaName":357,"dataGaLocation":44},"talk to sales",{"text":359,"config":360},"サポートポータル",{"href":361,"dataGaName":362,"dataGaLocation":44},"https://support.gitlab.com","support portal",{"text":364,"config":365},"カスタマーポータル",{"href":366,"dataGaName":367,"dataGaLocation":44},"https://customers.gitlab.com/customers/sign_in/","customer portal",{"close":369,"login":370,"suggestions":377},"閉じる",{"text":371,"link":372},"リポジトリとプロジェクトを検索するには、次にログインします",{"text":373,"config":374},"GitLab.com",{"href":58,"dataGaName":375,"dataGaLocation":376},"search login","search",{"text":378,"default":379},"提案",[380,382,387,389,393,397],{"text":73,"config":381},{"href":78,"dataGaName":73,"dataGaLocation":376},{"text":383,"config":384},"コード提案（AI）",{"href":385,"dataGaName":386,"dataGaLocation":376},"/ja-jp/solutions/code-suggestions/","Code Suggestions (AI)",{"text":107,"config":388},{"href":109,"dataGaName":107,"dataGaLocation":376},{"text":390,"config":391},"GitLab on AWS",{"href":392,"dataGaName":390,"dataGaLocation":376},"/ja-jp/partners/technology-partners/aws/",{"text":394,"config":395},"GitLab on Google Cloud",{"href":396,"dataGaName":394,"dataGaLocation":376},"/ja-jp/partners/technology-partners/google-cloud-platform/",{"text":398,"config":399},"GitLabを選ぶ理由",{"href":86,"dataGaName":400,"dataGaLocation":376},"Why GitLab?",{"freeTrial":402,"mobileIcon":406,"desktopIcon":411,"secondaryButton":414},{"text":46,"config":403},{"href":404,"dataGaName":49,"dataGaLocation":405},"https://gitlab.com/-/trials/new/","nav",{"altText":407,"config":408},"GitLabアイコン",{"src":409,"dataGaName":410,"dataGaLocation":405},"https://res.cloudinary.com/about-gitlab-com/image/upload/v1758203874/jypbw1jx72aexsoohd7x.svg","gitlab icon",{"altText":407,"config":412},{"src":413,"dataGaName":410,"dataGaLocation":405},"https://res.cloudinary.com/about-gitlab-com/image/upload/v1758203875/gs4c8p8opsgvflgkswz9.svg",{"text":199,"config":415},{"href":416,"dataGaName":417,"dataGaLocation":405},"https://gitlab.com/-/trial_registrations/new?glm_source=about.gitlab.com/ja-jp/compare/gitlab-vs-github/","get started",{"freeTrial":419,"mobileIcon":424,"desktopIcon":426},{"text":420,"config":421},"GitLab Duoの詳細について",{"href":422,"dataGaName":423,"dataGaLocation":405},"/ja-jp/gitlab-duo/","gitlab duo",{"altText":407,"config":425},{"src":409,"dataGaName":410,"dataGaLocation":405},{"altText":407,"config":427},{"src":413,"dataGaName":410,"dataGaLocation":405},{"freeTrial":429,"mobileIcon":434,"desktopIcon":436},{"text":430,"config":431},"料金ページに戻る",{"href":187,"dataGaName":432,"dataGaLocation":405,"icon":433},"back to pricing","GoBack",{"altText":407,"config":435},{"src":409,"dataGaName":410,"dataGaLocation":405},{"altText":407,"config":437},{"src":413,"dataGaName":410,"dataGaLocation":405},{"title":439,"button":440,"config":445},"エージェント型AIがソフトウェア配信をどのように変革するかをご覧ください",{"text":441,"config":442},"GitLab Transcendを今すぐ視聴",{"href":443,"dataGaName":444,"dataGaLocation":44},"/ja-jp/events/transcend/virtual/","transcend event",{"layout":446,"icon":447},"release","AiStar",{"data":449},{"text":450,"source":451,"edit":457,"contribute":462,"config":467,"items":472,"minimal":646},"GitはSoftware Freedom Conservancyの商標です。当社は「GitLab」をライセンスに基づいて使用しています",{"text":452,"config":453},"ページのソースを表示",{"href":454,"dataGaName":455,"dataGaLocation":456},"https://gitlab.com/gitlab-com/marketing/digital-experience/about-gitlab-com/","page source","footer",{"text":458,"config":459},"このページを編集",{"href":460,"dataGaName":461,"dataGaLocation":456},"https://gitlab.com/gitlab-com/marketing/digital-experience/about-gitlab-com/-/blob/main/content/","web ide",{"text":463,"config":464},"ご協力をお願いします",{"href":465,"dataGaName":466,"dataGaLocation":456},"https://gitlab.com/gitlab-com/marketing/digital-experience/about-gitlab-com/-/blob/main/CONTRIBUTING.md/","please contribute",{"twitter":468,"facebook":469,"youtube":470,"linkedin":471},"https://twitter.com/gitlab","https://www.facebook.com/gitlab","https://www.youtube.com/channel/UCnMGQ8QHMAnVIsI3xJrihhg","https://www.linkedin.com/company/gitlab-com",[473,496,550,580,615],{"title":62,"links":474,"subMenu":479},[475],{"text":476,"config":477},"DevSecOpsプラットフォーム",{"href":71,"dataGaName":478,"dataGaLocation":456},"devsecops platform",[480],{"title":185,"links":481},[482,486,491],{"text":483,"config":484},"プランの表示",{"href":187,"dataGaName":485,"dataGaLocation":456},"view plans",{"text":487,"config":488},"Premiumを選ぶ理由",{"href":489,"dataGaName":490,"dataGaLocation":456},"/ja-jp/pricing/premium/","why premium",{"text":492,"config":493},"Ultimateを選ぶ理由",{"href":494,"dataGaName":495,"dataGaLocation":456},"/ja-jp/pricing/ultimate/","why ultimate",{"title":497,"links":498},"ソリューション",[499,504,507,509,514,519,523,526,529,534,536,538,540,545],{"text":500,"config":501},"デジタルトランスフォーメーション",{"href":502,"dataGaName":503,"dataGaLocation":456},"/ja-jp/topics/digital-transformation/","digital transformation",{"text":505,"config":506},"セキュリティとコンプライアンス",{"href":127,"dataGaName":134,"dataGaLocation":456},{"text":119,"config":508},{"href":103,"dataGaName":104,"dataGaLocation":456},{"text":510,"config":511},"アジャイル開発",{"href":512,"dataGaName":513,"dataGaLocation":456},"/ja-jp/solutions/agile-delivery/","agile delivery",{"text":515,"config":516},"クラウドトランスフォーメーション",{"href":517,"dataGaName":518,"dataGaLocation":456},"/ja-jp/topics/cloud-native/","cloud transformation",{"text":520,"config":521},"SCM",{"href":116,"dataGaName":522,"dataGaLocation":456},"source code management",{"text":107,"config":524},{"href":109,"dataGaName":525,"dataGaLocation":456},"continuous integration & delivery",{"text":157,"config":527},{"href":159,"dataGaName":528,"dataGaLocation":456},"value stream management",{"text":530,"config":531},"GitOps",{"href":532,"dataGaName":533,"dataGaLocation":456},"/ja-jp/solutions/gitops/","gitops",{"text":170,"config":535},{"href":172,"dataGaName":173,"dataGaLocation":456},{"text":175,"config":537},{"href":177,"dataGaName":178,"dataGaLocation":456},{"text":180,"config":539},{"href":182,"dataGaName":183,"dataGaLocation":456},{"text":541,"config":542},"教育",{"href":543,"dataGaName":544,"dataGaLocation":456},"/ja-jp/solutions/education/","education",{"text":546,"config":547},"金融サービス",{"href":548,"dataGaName":549,"dataGaLocation":456},"/ja-jp/solutions/finance/","financial services",{"title":190,"links":551},[552,554,556,558,561,563,566,568,570,572,574,576,578],{"text":202,"config":553},{"href":204,"dataGaName":205,"dataGaLocation":456},{"text":207,"config":555},{"href":209,"dataGaName":210,"dataGaLocation":456},{"text":212,"config":557},{"href":214,"dataGaName":215,"dataGaLocation":456},{"text":217,"config":559},{"href":219,"dataGaName":560,"dataGaLocation":456},"docs",{"text":240,"config":562},{"href":242,"dataGaName":243},{"text":564,"config":565},"お客様の成功事例",{"href":237,"dataGaLocation":456},{"text":235,"config":567},{"href":237,"dataGaName":238,"dataGaLocation":456},{"text":245,"config":569},{"href":247,"dataGaName":248,"dataGaLocation":456},{"text":253,"config":571},{"href":255,"dataGaName":256,"dataGaLocation":456},{"text":258,"config":573},{"href":260,"dataGaName":261,"dataGaLocation":456},{"text":263,"config":575},{"href":265,"dataGaName":266,"dataGaLocation":456},{"text":268,"config":577},{"href":270,"dataGaName":271,"dataGaLocation":456},{"text":273,"config":579},{"href":275,"dataGaName":276,"dataGaLocation":456},{"title":581,"links":582},"Company",[583,585,587,589,591,593,595,599,604,606,608,610],{"text":298,"config":584},{"href":300,"dataGaName":293,"dataGaLocation":456},{"text":303,"config":586},{"href":305,"dataGaName":306,"dataGaLocation":456},{"text":311,"config":588},{"href":313,"dataGaName":314,"dataGaLocation":456},{"text":316,"config":590},{"href":318,"dataGaName":319,"dataGaLocation":456},{"text":321,"config":592},{"href":323,"dataGaName":324,"dataGaLocation":456},{"text":326,"config":594},{"href":328,"dataGaName":329,"dataGaLocation":456},{"text":596,"config":597},"Sustainability",{"href":598,"dataGaName":596,"dataGaLocation":456},"/sustainability/",{"text":600,"config":601},"ダイバーシティ、インクルージョン、ビロンギング（DIB）",{"href":602,"dataGaName":603,"dataGaLocation":456},"/ja-jp/diversity-inclusion-belonging/","Diversity, inclusion and belonging",{"text":331,"config":605},{"href":333,"dataGaName":334,"dataGaLocation":456},{"text":341,"config":607},{"href":343,"dataGaName":344,"dataGaLocation":456},{"text":346,"config":609},{"href":348,"dataGaName":349,"dataGaLocation":456},{"text":611,"config":612},"現代奴隷制の透明性に関する声明",{"href":613,"dataGaName":614,"dataGaLocation":456},"https://handbook.gitlab.com/handbook/legal/modern-slavery-act-transparency-statement/","modern slavery transparency statement",{"title":51,"links":616},[617,619,624,626,631,636,641],{"text":51,"config":618},{"href":53,"dataGaName":54,"dataGaLocation":456},{"text":620,"config":621},"サポートを受ける",{"href":622,"dataGaName":623,"dataGaLocation":456},"/support/","get help",{"text":364,"config":625},{"href":366,"dataGaName":367,"dataGaLocation":456},{"text":627,"config":628},"ステータス",{"href":629,"dataGaName":630,"dataGaLocation":456},"https://status.gitlab.com/","status",{"text":632,"config":633},"利用規約",{"href":634,"dataGaName":635,"dataGaLocation":456},"/terms/","terms of use",{"text":637,"config":638},"プライバシーに関する声明",{"href":639,"dataGaName":640,"dataGaLocation":456},"/ja-jp/privacy/","privacy statement",{"text":642,"config":643},"Cookieの設定",{"dataGaName":644,"dataGaLocation":456,"id":645,"isOneTrustButton":13},"cookie preferences","ot-sdk-btn",{"items":647},[648,650,652],{"text":632,"config":649},{"href":634,"dataGaName":635,"dataGaLocation":456},{"text":637,"config":651},{"href":639,"dataGaName":640,"dataGaLocation":456},{"text":642,"config":653},{"dataGaName":644,"dataGaLocation":456,"id":645,"isOneTrustButton":13},[655,669],{"id":656,"title":657,"body":9,"config":658,"content":660,"description":9,"extension":27,"meta":664,"navigation":13,"path":665,"seo":666,"stem":667,"__hash__":668},"blogAuthors/en-us/blog/authors/gitlab-japan-team.yml","Gitlab Japan Team",{"template":659},"BlogAuthor",{"name":19,"config":661},{"headshot":662,"ctfId":663},"https://res.cloudinary.com/about-gitlab-com/image/upload/v1749659488/Blog/Author%20Headshots/gitlab-logo-extra-whitespace.png","5YWHF8vG80rluQ41QjgP7V",{},"/en-us/blog/authors/gitlab-japan-team",{},"en-us/blog/authors/gitlab-japan-team","xs3yRNTInC3nd_gc5t_qSB_BOSquAfXSF9QA2S_y1g8",{"id":670,"title":671,"body":9,"config":672,"content":673,"description":9,"extension":27,"meta":675,"navigation":13,"path":676,"seo":677,"stem":678,"__hash__":679},"blogAuthors/en-us/blog/authors/gitlab.yml","Gitlab",{"template":659},{"name":20,"config":674},{"headshot":662,"ctfId":20},{},"/en-us/blog/authors/gitlab",{},"en-us/blog/authors/gitlab","XCBKIcPoCs6zi2oHG7o-bAp52Jhaw8_zGhIJ2jNrEjU",[681,697,712],{"content":682,"config":695},{"heroImage":683,"body":684,"authors":685,"updatedDate":688,"date":689,"title":690,"tags":691,"description":694,"category":10},"https://res.cloudinary.com/about-gitlab-com/image/upload/v1749658924/Blog/Hero%20Images/securitylifecycle-light.png","Azure DevOpsからGitLabへの移行は困難な作業のように思えるかもしれませんが、適切なアプローチとツールを使用すれば、スムーズかつ効率的に進められます。このガイドでは、Azure DevOpsからGitLabへプロジェクト、リポジトリ、パイプラインを正常に移行するために必要な手順を説明します。\n\n## 概要\n\nGitLabは、Azure DevOps（ADO）からプロジェクトを移行するための[Congregate](https://gitlab.com/gitlab-org/professional-services-automation/tools/migration/congregate/)([GitLabプロフェッショナルサービス（PS）](https://about.gitlab.com/ja-jp/professional-services/)によって管理）と[組み込みのGitリポジトリインポート](https://docs.gitlab.com/user/project/import/repo_by_url/)の両方を提供しています。これらのオプションは、リポジトリごとまたは一括移行をサポートし、Gitコミット履歴、ブランチ、タグを保持します。Congregateとプロフェッショナルサービスのツールを使用すると、Wiki、作業アイテム、CI/CD変数、コンテナイメージ、パッケージ、パイプラインなどの追加アセットもサポートされます（この[機能マトリクス](https://gitlab.com/gitlab-org/professional-services-automation/tools/migration/congregate/-/blob/master/customer/ado-migration-features-matrix.md)を参照）。このガイドを参照すれば、移行を計画・実行し、移行後のフォローアップタスクを完了できます。\n\nADOからGitLabへ移行する企業は、一般的に複数フェーズのアプローチに従います：\n\n* CongregateまたはGitLabの組み込みリポジトリ移行を使用して、ADOからGitLabにリポジトリを移行します。\n* AzureパイプラインからGitLab CI/CDにパイプラインを移行します。\n* ボード、作業アイテム、アーティファクトなどの残りのアセットを、GitLabのイシュー、エピック、パッケージレジストリ、コンテナレジストリに移行します。\n\n移行フェーズの概要:\n\n```mermaid\ngraph LR\n    subgraph Prerequisites\n        direction TB\n        A[\"IDプロバイダー（IdP）を設定し\u003Cbr/>ユーザーをプロビジョニング\"]\n        A --> B[\"Runnerとサードパーティ\u003Cbr/>インテグレーションを設定\"]\n        B --> I[\"ユーザーの有効化と\u003Cbr/>変更管理\"]\n    end\n    \n    subgraph MigrationPhase[\"移行フェーズ\"]\n        direction TB\n        C[\"ソースコードを移行\"]\n        C --> D[\"コントリビューションを保持し\u003Cbr/>履歴をフォーマット\"]\n        D --> E[\"作業アイテムを移行し\u003Cbr/>\u003Ca href=\"https://docs.gitlab.com/topics/plan_and_track/\">GitLab Plan\u003Cbr/>および作業追跡\u003C/a>にマッピング\"]\n    end\n    \n    subgraph PostMigration[\"移行後の手順\"]\n        direction TB\n        F[\"ADOパイプラインを\u003Cbr/>GitLab CIに作成または変換\"]\n        F --> G[\"その他のアセット、パッケージ、\u003Cbr/>コンテナイメージを移行\"]\n        G --> H[\"\u003Ca href=\"https://docs.gitlab.com/user/application_security/secure_your_application/\">セキュリティ\u003C/a>と\u003Cbr/>SDLC改善を導入\"]\n    end\n    \n    Prerequisites --> MigrationPhase\n    MigrationPhase --> PostMigration\n\n    style A fill:#FC6D26\n    style B fill:#FC6D26\n    style I fill:#FC6D26\n    style C fill:#8C929D\n    style D fill:#8C929D\n    style E fill:#8C929D\n    style F fill:#FFA500\n    style G fill:#FFA500\n    style H fill:#FFA500\n```\n\n## 移行の計画\n\n**移行を計画するにあたり、次の質問を検討します:**\n\n* 移行をいつまでに完了する必要があるか?\n* 何が移行されるかを理解しているか?\n* 誰が移行を実行するか?\n* GitLabでどのような組織構造を望むか?\n* 考慮すべき制約、制限、落とし穴はあるか?\n\nタイムラインを決定します。これは移行アプローチを大きく左右します。ADOとGitLabの両プラットフォームに精通したチャンピオンやグループ（アーリーアダプターなど）を特定し、導入を推進してアドバイスを提供してもらいます。\n\n**移行が必要なものをインベントリ化:**\n\n* リポジトリ、プルリクエスト、コントリビューターの数\n* 作業アイテムとパイプラインの数と複雑さ\n* リポジトリのサイズと依存関係\n* 重要なインテグレーションとRunner要件（特定の機能を持つエージェントプール）\n\nGitLab プロフェッショナルサービスの[Evaluate](https://gitlab.com/gitlab-org/professional-services-automation/tools/utilities/evaluate#beta-azure-devops)ツールを使用して、リポジトリ、PR数、コントリビューターリスト、パイプライン数、作業アイテム、CI/CD変数などを含むAzure DevOps組織全体の完全なインベントリを作成します。GitLabプロフェッショナルサービスチームと連携している場合は、このレポートをエンゲージメントマネージャーまたはテクニカルアーキテクトと共有し、移行計画に役立ててください。\n\n移行のタイミングは、主にプルリクエスト数、リポジトリサイズ、コントリビューション量（PRのコメント、作業アイテムなど）によって決まります。たとえば、PRが少なくコントリビューターが限られた1,000の小規模リポジトリは、数万のPRと数千のコントリビューターを含む少数のリポジトリよりもはるかに高速に移行できます。インベントリデータを使用して作業量を見積もり、本番移行を進める前にテスト実行を計画します。\n\nインベントリを希望のタイムラインと比較し、すべてのリポジトリを一度に移行するか、バッチで移行するかを決定します。チームが同時に移行できない場合は、チームのスケジュールに合わせて移行をバッチ化し、段階的に実行します。たとえば、プロフェッショナルサービスのエンゲージメントでは、複雑さを管理し、[GitLab](https://docs.gitlab.com/security/rate_limits/)と[ADO](https://learn.microsoft.com/en-us/azure/devops/integrate/concepts/rate-limits?view=azure-devops)の両方のAPIレート制限を尊重するために、200〜300プロジェクト単位の段階に分割して移行を実施します。\n\nGitLabの組み込み[リポジトリインポーター](https://docs.gitlab.com/user/project/import/repo_by_url/)は、Gitリポジトリ（コミット、ブランチ、タグ）を1つずつ移行します。Congregateは、可能な限りプルリクエスト（GitLabではマージリクエストとして知られています）、コメント、関連メタデータを保持するように設計されています。シンプルな組み込みリポジトリインポートは、Gitデータ（履歴、ブランチ、タグ）のみに焦点を当てています。\n\n**通常、個別の移行または手動での再作成が必要な項目:**\n\n* Azureパイプライン - 同等のGitLab CI/CDパイプラインを作成([CI/CD YAML](https://docs.gitlab.com/ci/yaml/)または[CI/CDコンポーネント](https://docs.gitlab.com/ci/components/)を参照)。または、CongregateのAIベースのパイプライン変換を使用することを検討してください。\n* 作業アイテムとボード - GitLabのイシュー、エピック、イシュー ボードにマッピング。\n* アーティファクト、コンテナイメージ(ACR) - GitLabパッケージレジストリまたはコンテナレジストリに移行。\n* サービスフックと外部インテグレーション - GitLabで再作成。\n* [権限モデル](https://docs.gitlab.com/user/permissions/)はADOとGitLabで異なります。完全な保持を想定するのではなく、権限マッピングを確認および計画してください。\n\n各ツール（Congregateと組み込みインポート）が何を移行するかを確認し、ニーズに合ったものを選択します。手動で移行または再作成する必要があるデータやインテグレーションのリストを作成します。\n\n**誰が移行を実行するか?**\n\n移行は通常、GitLabグループオーナーまたはインスタンス管理者、または移行先グループ/プロジェクトに必要な権限を付与された指定の移行担当者によって実行されます。CongregateとGitLabインポートAPIには、Azure DevOpsとGitLabの両方の有効な認証トークンが必要です。\n\n* グループオーナー/管理者が移行を実行するか、特定のチーム/個人に委任アクセスを付与するかを決定します。\n* 移行担当者が、選択した移行ツールに必要なスコープ（api/read_repositoryスコープやツール固有の要件など）を持つ個人アクセストークン（Azure DevOpsとGitLab）を正しく設定していることを確認します。\n* 小規模なパイロット移行でトークンと権限をテストします。\n\n**注:** CongregateはADO移行のためにファイルベースのインポート機能を活用し、実行にはインスタンス管理者権限が必要です（[ドキュメントを参照](https://docs.gitlab.com/user/project/settings/import_export/#migrate-projects-by-uploading-an-export-file)）。GitLab.comに移行する場合は、プロフェッショナルサービスの利用を検討してください。詳細については、[Professional Services Full Catalog](https://about.gitlab.com/professional-services/catalog/)を参照してください。管理者以外のアカウントでは、コントリビューションの帰属を保持できません。\n\n**GitLabでどのような組織構造を望むか?**\n\nADO構造をGitLab構造に直接マッピングすることは可能ですが、移行中に構造を合理化および簡素化することをお勧めします。チームがGitLabでどのように作業するかを検討し、コラボレーションとアクセス管理を促進する構造を設計します。ADO構造をGitLab構造にマッピングする方法は次のとおりです。\n\n```mermaid\ngraph TD\n    subgraph GitLab\n        direction TB\n        A[\"トップレベルグループ\"]\n        B[\"サブグループ（オプション）\"]\n        C[\"プロジェクト\"]\n        A --> B\n        A --> C\n        B --> C\n    end\n\n    subgraph AzureDevOps[\"Azure DevOps\"]\n        direction TB\n        F[\"組織\"]\n        G[\"プロジェクト\"]\n        H[\"リポジトリ\"]\n        F --> G\n        G --> H\n    end\n\n    style A fill:#FC6D26\n    style B fill:#FC6D26\n    style C fill:#FC6D26\n    style F fill:#8C929D\n    style G fill:#8C929D\n    style H fill:#8C929D\n```\n\n推奨アプローチ:\n\n* 各ADO組織をGitLabグループ（または少数のグループ）にマッピングし、多数の小さなグループには分割しないでください。ADOチームプロジェクトごとにGitLabグループを作成することは避けてください。移行をGitLab構造を合理化する機会として活用してください。\n* サブグループとプロジェクトレベルの権限を使用して、関連リポジトリをグループ化します。\n* GitLabグループとグループメンバーシップ（グループとサブグループ）を使用してプロジェクトのセットへのアクセスを管理し、チームプロジェクトごとに1つのグループを作成しないでください。\n* GitLabの[権限](https://docs.gitlab.com/ee/user/permissions.html)を確認し、[SAML Group Links](https://docs.gitlab.com/user/group/saml_sso/group_sync/)を検討して、GitLabインスタンス（またはGitLab.comネームスペース）のエンタープライズRBACモデルを実装します。\n\n**ADOボードと作業アイテム: 移行の状態**\n\n作業アイテムがADOからGitLab Plan（イシュー、エピック、ボード）にどのように移行されるかを理解することが重要です。\n\n* ADOボードと作業アイテムは、GitLabのイシュー、エピック、イシューボードにマッピングされます。ワークフローとボード設定がどのように変換されるかを計画します。\n* ADOのエピックと機能は、GitLabのエピックになります。\n* その他の作業アイテムタイプ（ユーザーストーリー、タスク、バグなど）は、プロジェクトスコープのイシューになります。\n* ほとんどの標準フィールドが保持されます。サポートされている場合、選択したカスタムフィールドを移行できます。\n* 親子関係が保持されるため、エピックはすべての関連イシューを参照します。\n* プルリクエストへのリンクはマージリクエストリンクに変換され、開発のトレーサビリティが維持されます。\n\n例: 個別の作業アイテムのGitLabイシューへの移行（フィールドの正確性と関係性を含む）:\n\n![例: 個別の作業アイテムのGitLabイシューへの移行](https://res.cloudinary.com/about-gitlab-com/image/upload/v1764769188/ztesjnxxfbwmfmtckyga.png)\n\nバッチ処理のガイダンス:\n\n* バッチで移行を実行する必要がある場合は、新しいグループ/サブグループ構造を使用してバッチを定義します（たとえば、ADO組織ごと、または製品領域ごと）。\n* インベントリレポートを使用してバッチ選択を推進し、スケールアップする前に各バッチをパイロット移行でテストします。\n\n**パイプライン移行**\n\nCongregateは最近、Azure DevOpsからGitLab CI/CDへのマルチステージYAMLパイプラインのAI搭載変換を[導入しました](https://gitlab.com/gitlab-org/professional-services-automation/tools/migration/congregate/-/merge_requests/1298)。この自動変換は、シンプルな単一ファイルパイプラインに最適で、本番環境対応の`.gitlab-ci.yml`ファイルではなく、動作する出発点を提供するように設計されています。このツールは、機能的に同等のGitLabパイプラインを生成し、その後特定のニーズに合わせて調整および最適化できます。\n\n* Azureパイプライン YAMLを`.gitlab-ci.yml`形式に自動変換します。\n* シンプルな単一ファイルパイプライン設定に最適です。\n* 移行を加速するためのボイラープレートを提供し、最終的な本番環境アーティファクトではありません。\n* 複雑なシナリオ、カスタムタスク、エンタープライズ要件については、レビューや調整が必要です。\n* Azure DevOpsのクラシックリリースパイプラインはサポートしていません — 最初に[マルチステージYAMLに変換](https://learn.microsoft.com/en-us/azure/devops/pipelines/release/from-classic-pipelines?view=azure-devops)してください。\n\nリポジトリオーナーは、初期変換後にパイプラインをさらに最適化および強化するために、[GitLab CI/CDドキュメント](https://docs.gitlab.com/ci/)を確認する必要があります。\n\n変換されたパイプラインの例:\n\n```yml\n# azure-pipelines.yml\n\ntrigger:\n  - main\n\nvariables:\n  imageName: myapp\n\nstages:\n  - stage: Build\n    jobs:\n      - job: Build\n        pool:\n          vmImage: 'ubuntu-latest'\n        steps:\n          - checkout: self\n\n          - task: Docker@2\n            displayName: Build Docker image\n            inputs:\n              command: build\n              repository: $(imageName)\n              Dockerfile: '**/Dockerfile'\n              tags: |\n                $(Build.BuildId)\n\n  - stage: Test\n    jobs:\n      - job: Test\n        pool:\n          vmImage: 'ubuntu-latest'\n        steps:\n          - checkout: self\n\n          # Example: run tests inside the container\n          - script: |\n              docker run --rm $(imageName):$(Build.BuildId) npm test\n            displayName: Run tests\n\n  - stage: Push\n    jobs:\n      - job: Push\n        pool:\n          vmImage: 'ubuntu-latest'\n        steps:\n          - checkout: self\n\n          - task: Docker@2\n            displayName: Login to ACR\n            inputs:\n              command: login\n              containerRegistry: '\u003Cyour-acr-service-connection>'\n\n          - task: Docker@2\n            displayName: Push image to ACR\n            inputs:\n              command: push\n              repository: $(imageName)\n              tags: |\n                $(Build.BuildId)\n```\n\n```yaml\n# .gitlab-ci.yml\n\nvariables:\n  imageName: myapp\n\nstages:\n  - build\n  - test\n  - push\n\nbuild:\n  stage: build\n  image: docker:latest\n  services:\n    - docker:dind\n  script:\n    - docker build -t $imageName:$CI_PIPELINE_ID -f $(find . -name Dockerfile) .\n  only:\n    - main\n\ntest:\n  stage: test\n  image: docker:latest\n  services:\n    - docker:dind\n  script:\n    - docker run --rm $imageName:$CI_PIPELINE_ID npm test\n  only:\n    - main\n\npush:\n  stage: push\n  image: docker:latest\n  services:\n    - docker:dind\n  before_script:\n    - docker login -u $CI_REGISTRY_USER -p $CI_REGISTRY_PASSWORD $CI_REGISTRY\n  script:\n    - docker tag $imageName:$CI_PIPELINE_ID $CI_REGISTRY/$CI_PROJECT_PATH/$imageName:$CI_PIPELINE_ID\n    - docker push $CI_REGISTRY/$CI_PROJECT_PATH/$imageName:$CI_PIPELINE_ID\n  only:\n    - main\n```\n\n**最終チェックリスト:**\n\n* タイムラインとバッチ戦略を決定します。\n* リポジトリ、PR、コントリビューターの完全なインベントリを作成します。\n* スコープ（PRとメタデータ vs Gitデータのみ）に基づいて、Congregateまたは組み込みインポートを選択します。\n* 誰が移行を実行するかを決定し、トークン/権限が設定されていることを確認します。\n* 個別に移行する必要があるアセット（パイプライン、作業アイテム、アーティファクト、フック）を特定し、それらの取り組みを計画します。\n* パイロット移行を実行し、結果を検証してから、計画に従ってスケールします。\n\n## 移行の実行\n\n計画後、トライアル実行から始めて、段階的に移行を実行します。トライアル移行は、組織固有の問題を早期に明らかにし、期間を測定し、結果を検証し、本番環境前にアプローチを微調整する上で役立ちます。\n\nトライアル移行が検証する内容:\n\n* 特定のリポジトリと関連アセットが正常に移行されるかどうか（履歴、ブランチ、タグ。Congregateを使用する場合はMR/コメントも含む）\n* 移行先がすぐに使用可能かどうか（権限、Runner、CI/CD変数、インテグレーション）\n* スケジュールとステークホルダーの期待値を設定するため、各バッチにかかる時間。\n\nダウンタイムのガイダンス:\n\n* GitLabの組み込みGitインポートとCongregateは、本質的にダウンタイムを必要としません。\n* 本番環境の場合では、ADOの変更を凍結（ブランチ保護または読み取り専用）して、移行中に見逃されたコミット、PR更新、作業アイテムの作成を回避します。\n* トライアル実行では凍結は必要なく、いつでも実行できます。\n\nバッチ処理のガイダンス:\n\n* 経過時間を短縮するために、トライアルバッチを連続して実行します。チームは非同期で結果を検証できます。\n* 計画したグループ/サブグループ構造を使用してバッチを定義し、APIレート制限を遵守します。\n\n推奨手順:\n\n1. GitLabでトライアル用のテスト先を作成:\n\n* GitLab.com: 専用グループ/ネームスペースを作成（例: my-org-sandbox）\n* Self-managed: トップレベルグループまたは必要に応じて別のテストインスタンスを作成\n\n2. 認証の準備:\n\n* 必要なスコープを持つAzure DevOps PAT\n* apiとread_repositoryを持つGitLabパーソナルアクセストークン（Congregateで使用されるファイルベースのインポートの場合は管理者アクセスも含む）```suggestion:-0+0\n* apiとread_repositoryを持つGitLabパーソナルアクセストークン（Congregateで使用されるファイルベースのインポートの場合は管理者アクセスも含む）\n\n3. トライアル移行の実行:\n\n* リポジトリのみ: GitLabの組み込みインポート（URLによるレポジトリインポート）を使用\n* リポジトリ + PR/MRおよび追加アセット: Congregateを使用\n\n4. トライアル後のフォローアップ:\n\n* リポジトリ履歴、ブランチ、タグ、マージリクエスト（移行された場合）、イシュー/エピック（移行された場合）、ラベル、関係性を確認します。\n* 権限/ロール、保護ブランチ、必要な承認、Runner/タグ、変数/シークレット、インテグレーション/Webhookを確認します。\n* パイプライン（`.gitlab-ci.yml`）または（該当する場合は）変換されたパイプラインを検証します。\n\n5. ユーザーに機能とデータの正確性を検証してもらいます。\n6. トライアル中に発見された問題を解決し、実行手順を更新します。\n7. ネットワークとセキュリティ:\n\n* 移行先の環境がIP許可リストを使用している場合、インポートが成功するように、移行ホストと必要なRunner/インテグレーションのIPを追加します。\n\n8. 本番環境への移行は段階的に実行:\n\n* 各段階で、ADOで変更凍結を実施します。\n* 進捗とログを監視します。レート制限に達した場合は、再試行するか、バッチサイズを調整します。\n\n9. オプション: 完了後、サンドボックスグループを削除またはアーカイブします。\n\n\u003Cfigure class=\"video_container\">\n  \u003Ciframe src=\"https://www.youtube.com/embed/ibIXGfrVbi4?si=ZxOVnXjCF-h4Ne0N\" frameborder=\"0\" allowfullscreen=\"true\">\u003C/iframe>\n\u003C/figure>\n\n## GitLabとAzure DevOpsの用語リファレンス\n\n| GitLab                                      | Azure DevOps                     | 類似点と主な違い                                                                        |\n| ------------------------------------------- | -------------------------------- | ------------------------------------------------------------------------------- |\n| グループ                                        | 組織                               | トップレベルのネームスペース、メンバーシップ、ポリシー。ADO組織にはプロジェクトが含まれ、GitLabグループにはサブグループとプロジェクトが含まれます。  |\n| グループまたはサブグループ                               | プロジェクト                           | 論理コンテナ、権限境界。ADOプロジェクトは多数のリポジトリを保持し、GitLabグループ/サブグループは多数のプロジェクトを整理します。           |\n| Project（Gitリポジトリを含む）                        | リポジトリ（プロジェクト内）                   | Git履歴、ブランチ、タグ。GitLabでは、「プロジェクト」はリポジトリとイシュー、CI/CD、Wikiなどを含みます。プロジェクトごとに1つのリポジトリ。 |\n| マージリクエスト（MR）                                | プルリクエスト（PR）                      | コードレビュー、ディスカッション、承認。MRルールには、承認、必要なパイプライン、コードオーナーが含まれます。                         |\n| 保護されたブランチ、MR承認ルール、ステータスチェック                 | ブランチポリシー                         | レビューとチェックを強制。GitLabは保護 + 承認ルール + 必要なステータスチェックを組み合わせます。                          |\n| GitLab CI/CD                                | Azureパイプライン                      | YAMLパイプライン、ステージ/ジョブ、ログ。ADOにはクラシックUIパイプラインもあり、GitLabは.gitlab-ci.ymlを中心にしています。    |\n| .gitlab-ci.yml                              | azure-pipelines.yml              | ステージ/ジョブ/トリガーを定義。構文/機能が異なります。ジョブ、変数、アーティファクト、トリガーをマッピングします。                     |\n| Runner（共有/特定）                               | エージェント/エージェントプール                 | マシン/コンテナでジョブを実行。デマンド（ADO）対タグ（GitLab）でターゲット。登録/スコーピングが異なります。                     |\n| CI/CD変数（プロジェクト/グループ/インスタンス）、保護/マスク          | パイプライン変数、変数グループ、ライブラリ            | 設定/シークレットをジョブに渡します。GitLabはグループ継承とマスキング/保護フラグをサポートします。                           |\n| インテグレーション、CI/CD変数、デプロイキー                    | サービス接続                           | サービス/クラウドへの外部認証。インテグレーションまたは変数にマッピング。クラウド固有のヘルパーが利用可能。                          |\n| 環境とデプロイメント（保護された環境）                         | 環境（承認付き）                         | デプロイターゲット/履歴を追跡。GitLabでは保護された環境と手動ジョブを介した承認。                                    |\n| リリース（タグ + ノート）                              | リリース（クラシックまたはパイプライン）             | バージョン管理されたノート/アーティファクト。GitLabリリースはタグに結び付けられ、デプロイメントは個別に追跡されます。                  |\n| ジョブアーティファクト                                 | パイプラインアーティファクト                   | ジョブ出力を保持。保持/有効期限はジョブまたはプロジェクトごとに設定されます。                                         |\n| パッケージレジストリ（NuGet/npm/Maven/PyPI/Composerなど） | Azureアーティファクト（NuGet/npm/Mavenなど） | パッケージホスティング。認証/ネームスペースが異なります。パッケージタイプごとに移行します。                                  |\n| GitLabコンテナレジストリ                             | Azureコンテナレジストリ（ACR）または他          | OCIイメージ。GitLabはプロジェクト/グループごとのレジストリを提供します。                                       |\n| イシューボード                                     | ボード                              | 列で作業を視覚化。GitLabボードはラベル駆動型で、プロジェクト/グループごとに複数のボードがあります。                           |\n| イシュー（タイプ/ラベル）、エピック                          | 作業アイテム（ユーザーストーリー/バグ/タスク）         | 作業単位を追跡。ADOタイプ/フィールドをラベル/カスタムフィールドにマッピング。エピックはグループレベルです。                        |\n| エピック、親子イシュー                                 | エピック/機能                          | 作業の階層。スキーマが異なります。エピックとイシュー関係を使用します。                                             |\n| マイルストーンとイテレーション                             | イテレーションパス                        | タイムボックス化。GitLabイテレーション（グループ機能）またはプロジェクト/グループごとのマイルストーン。                         |\n| ラベル（スコープ付きラベル）                              | エリアパス                            | 分類/所有権。階層エリアをスコープ付きラベルに置き換えます。                                                  |\n| プロジェクト/グループWiki                             | プロジェクトWiki                       | マークダウンWiki。両方ともリポジトリでバックアップされます。レイアウト/認証がわずかに異なります。                             |\n| CI経由のテストレポート、要件/テスト管理、インテグレーション             | テストプラン/ケース/実行                    | QA証拠/トレーサビリティ。ADOテストプランとの1対1対応はありません。多くの場合、CIレポート + イシュー/要件を使用します。              |\n| ロール（オーナー/メンテナー/デベロッパー/レポーター/ゲスト） + カスタムロール  | アクセスレベル + きめ細かい権限                | 読み取り/書き込み/管理を制御。モデルが異なります。グループ継承と保護されたリソースを活用します。                               |\n| Webhook                                     | サービスフック                          | イベント駆動型インテグレーション。イベント名/ペイロードが異なります。エンドポイントを再設定します。                              |\n| 高度な検索                                       | コードサーチ                           | フルテキストリポジトリ検索。Self-managed版のGitLabでは、高度な機能にElasticsearch/OpenSearchが必要な場合があります。 |",[686,687],"Evgeny Rudinsky","Michael Leopard","2025-12-08","2025-12-03","ガイド: Azure DevOpsからGitLabへの移行",[692,693,107],"tutorial","git","GitLabプロフェッショナルサービスの移行ツールを使用してAzure DevOpsからGitLabへの完全な移行を実行する方法を学びます — 計画、実行から移行後のフォローアップタスクまで。",{"featured":13,"template":14,"slug":696},"migration-from-azure-devops-to-gitlab",{"content":698,"config":710},{"heroImage":699,"body":700,"authors":701,"updatedDate":703,"date":704,"title":705,"tags":706,"description":709,"category":10},"https://res.cloudinary.com/about-gitlab-com/image/upload/v1764108112/tyntnsy3xotlmehtnfkb.png","毎日、GitLabは世界最大のGitLabインスタンスであるGitLab.comにコード変更を最大12回、ダウンタイムなしでデプロイしています。これらのデプロイ管理には、GitLab独自のCI/CDプラットフォームを使用しており、世界中の数百万人のデベロッパーに影響を与えています。このデプロイ頻度は、私たちの主要な品質基準とストレステストとして機能しています。また、お客様は数週間や数か月待つことなく、開発から数時間以内で新機能にアクセスできるようになります。組織がDevOpsワークフローにGitLabを利用する場合、私たち自身のインフラストラクチャで大規模に実証されたプラットフォームを使用していることになります。この記事では、このデプロイの複雑さを処理するために、GitLab CI/CDのコア機能を使用して自動化されたデプロイパイプラインを構築した方法をご紹介します。\n\n\n## デプロイ速度がもたらすビジネスケース\n\n\n当社の実践から見えるもの：私たちのデプロイ頻度は単なるエンジニアリング指標ではなく、ビジネス上の必須要件です。迅速なデプロイサイクルにより、お客様からのフィードバックに数時間以内に対応し、セキュリティパッチを即座に提供し、新機能を本番環境で検証してからスケールすることができます。\n\n\nお客様が得られる価値：GitLab.comへのすべてのデプロイは、ユーザーに推奨するデプロイプラクティスを検証しています。GitLabのデプロイ機能を使用する場合、数百万のgit操作、CI/CDパイプライン、ユーザーインタラクションを日々処理する実証済みのアプローチを使用していることになります。以下のメリットがあります:\n\n- 最新機能が即座に利用可能：新しい機能は四半期ごとのリリースサイクルではなく、完成してから数時間以内に提供されます\n- 大規模環境で実証された信頼性：機能がGitLab.comで動作すれば、お客様の環境でも信頼できます\n- GitLabの完全な価値：ゼロダウンタイムデプロイにより、更新中でもDevOpsプラットフォームへのアクセスが失われることはありません\n- 実環境でテストされたプラクティス：当社のデプロイドキュメントは理論ではなく、世界最大のGitLabインスタンスを実際に運用する方法そのものです\n\n\n## コードフローアーキテクチャ\n\n\nデプロイパイプラインは、複数のステージを経て構造化された進行に従います。各ステージは、コード提案から本番環境へのデプロイまでの過程におけるチェックポイントとして機能します。\n\n```mermaid\n  graph TD\n      A[コード提案] --> B[マージリクエスト作成]\n      B --> C[パイプライントリガー]\n      C --> D[ビルド ＆ テスト]\n      D --> E{スペック/統合/QAテスト合格？}\n      E -->|いいえ| F[フィードバックループ]\n      F --> B\n      E -->|はい| G[デフォルトブランチへマージ]\n      G -->|定期的| H[Auto-Deployブランチ]\n\n      subgraph \"デプロイパイプライン\"\n          H --> I[パッケージ作成]\n          I --> K[Canary環境]\n          K --> L[QA検証]\n          L --> M[main環境]\n\n      end\n```\n\n\n## デプロイパイプラインの構成\n\nデプロイアプローチでは、GitLabのネイティブCI/CD機能を使用して、ハイブリッドインフラストラクチャ全体で複雑なデプロイを調整します。\nその実装方法をご紹介します。\n\n\n### ビルド\n\n\nGitLabのビルドは、それ自体が複雑なトピックであるため、ここでは概要レベルで説明します。\n\nOmnibusパッケージとCloud Native GitLab(CNG)イメージの両方をビルドします。OmnibusパッケージはGitalyフリート(Gitストレージレイヤー)にデプロイされ、CNGイメージは他のすべてのコンポーネントをコンテナ化されたワークロードとして実行します。PostgresやRedisなどの他のステートフルサービスは非常に大規模になったため、専任チームが個別に管理しています。GitLab.comの場合、これらのシステムはAuto-Deploy手順中にはデプロイされません。\n\n\n`gitlab-org/gitlab`を定期的に確認し、デフォルトブランチで成功した(「グリーン」)パイプラインを持つ最新のコミットを検索するスケジュールされたパイプラインがあります。グリーンパイプラインは、GitLabのすべてのコンポーネントが包括的なテスト群に成功したことを示します。次に、そのコミットから**auto-deployブランチ**を作成します。\n\n\nこれにより一連のイベントがトリガーされます。主に、このパッケージとモノリスの一部であるすべてのコンポーネントをビルドする必要があります。\n別のスケジュールされたパイプラインが、最新のビルドされたパッケージを選択し、デプロイパイプラインを開始します。手順としては、このようにシンプルに見えます：\n\n\n```mermaid\n  graph LR\n      A[ブランチ作成] --> B[ビルド]\n      B --> C[ビルドされたパッケージを選択]\n      C --> D[デプロイパイプラインを開始]\n```\n\n\nビルドには時間がかかり、さまざまな状況によりデプロイが変動する可能性があるため、最新のビルドをデプロイするように選択しています。技術的には、実際にデプロイされるよりも多くのGitLabのバージョンを.com用にビルドしています。これにより、常に準備が整ったパッケージが用意され、.comに対して完全に継続的にデリバリーされる製品に最も近い状態を実現できます。\n\n\n### 環境ベースの検証とCanary戦略\n\n品質保証(QA)は単なる後付けではなく、開発からデプロイまでのすべてのレイヤーに組み込まれています。QAプロセスでは、ユニットテスト、統合テスト、GitLabの機能との実際のユーザーインタラクションをシミュレートするエンドツーエンドテストを含む自動化されたテスト群を活用しています。しかし、デプロイパイプラインにとってさらに重要なのは、QAプロセスが環境ベースの検証を通じてCanary戦略と密接に連携していることです。\n\n\n検証アプローチの一環として、GitLabのネイティブ[Canaryデプロイ](https://docs.gitlab.com/ja-jp/user/project/canary_deployments/)を活用し、完全な本番環境へのデプロイ前に、限定されたトラフィックで変更を制御しながら検証できるようにしています。[すべてのトラフィックの約5%をCanaryステージに送信しています](https://handbook.gitlab.com/handbook/engineering/infrastructure/environments/canary-stage/#environments-canary-stage)。このアプローチはデータベースマイグレーションの複雑性を高めますが、Canaryデプロイを成功させることで、信頼性の高い製品をシームレスにデプロイすることができます。\n\nGitLabで使用するCanaryデプロイ機能は、本番環境における最も複雑なデプロイメントシナリオの管理を通じて改良されたものです。アプリケーション用にCanaryデプロイを実装する場合、大規模環境で実証済みのパターンを使用していることになります。\n\n当社のデプロイプロセスは、段階的ロールアウト戦略に従います:\n\n1. **ステージング環境 Canary:** 初期検証環境\n\n2. **本番環境 Canary:** 限定された本番トラフィック\n\n3. **ステージング環境 main:** ステージング環境への完全デプロイ\n\n4. **本番環境 main:** 本番環境への完全ロールアウト\n\n```mermaid\n  graph TD\n      C[ステージング環境 Canaryデプロイ]\n      C --> D[QA スモーク main Testステージ]\n      C --> E[QA スモーク Canary Testステージ]\n      D --> F\n      E --> F{テスト合格？}\n      F -->|はい| G[本番環境 Canary デプロイ]\n      G --> S[QA スモーク main Testステージ]\n      G --> T[QA スモーク Canary Testステージ]\n      F -->|いいえ| H[イシュー作成]\n      H --> K[修正＆バックポート]\n      K --> C\n\n      S --> M[Canary トラフィック監視]\n      T --> M[Canary トラフィック監視ベイク期間]\n      M --> U[本番環境安全性チェック]\n      U --> N[ステージング環境 main]\n      N --> V[本番環境 main]\n```\n\nQA検証は、この段階的デプロイプロセス全体の複数のチェックポイントで行われます。各Canaryデプロイ後、そしてデプロイ後のマイグレーション実施後に再度検証を行います。この多層的なアプローチにより、デプロイ戦略の各フェーズに独自のセーフティーネットが確保されます。GitLabの[包括的なテスト手法](https://handbook.gitlab.com/handbook/engineering/testing/)については、ハンドブックで詳しく説明しています。\n\n## デプロイパイプライン\n\nデプロイパイプライン全体で対処している課題についてご紹介します。\n\n### 技術アーキテクチャに関する考慮事項\n\n GitLab.comは、大規模な実環境でのデプロイの複雑性を体現しています。既知の最大規模のGitLabインスタンスとして、デプロイには公式のGitLab HelmチャートとLinuxパッケージを使用しており、これらはお客様が使用するものと同じアーティファクトです。[GitLab.comアーキテクチャ](https://handbook.gitlab.com/handbook/engineering/infrastructure/production/architecture/#gitlab-com-architecture)については、ハンドブックで詳しく説明しています。このハイブリッドアプローチにより、デプロイパイプラインは同一のデプロイサイクルでコンテナ化されたサービスと従来のLinuxサービスの両方をインテリジェントに処理する必要があります。\n\n **大規模なドッグフーディング:** [ゼロダウンタイムのアップグレード](https://docs.gitlab.com/ja-jp/update/zero_downtime/)用にドキュメント化したものと同じ手順を使用してデプロイしています。もし私たちにとってスムーズに機能しないものがあれば、お客様にも推奨しません。この自己規律により、デプロイツールの継続的な改善が促進されています。\n\n すべての環境とステージのアップグレードで、以下のステージが実行されます：\n\n```mermaid\n  graph LR\n      a[Prep] --> c[通常 Migrations - Canaryステージのみ]\n      a --> f[Assets - Canaryステージのみ]\n      c --> d[Gitaly]\n      d --> k8s\n\n      subgraph subGraph0[\"VMワークロード\"]\n        d[\"Gitaly\"]\n      end\n\n      subgraph subGraph1[\"Kubernetesワークロード\"]\n        k8s[\"k8s\"]\n      end\n\n      subgraph fleet[\"フリート\"]\n        subGraph0\n        subGraph1\n      end\n```\n\n\n**ステージの詳細:**\n\n\n- **Prep：** デプロイの準備状況を検証し、デプロイ前のチェックを実行します\n\n- **Migrations：** データベースの通常マイグレーションを実行します。これはCanaryステージでのみ実行されます。Canaryステージとmainステージは同じデータベースを共有しているため、mainステージのデプロイ時にはこれらの変更がすでに利用可能であり、タスクを繰り返す必要はありません。\n\n- **Assets：** すべての静的アセットにGCSバケットを活用しています。新しいアセットが作成された場合、バケットにアップロードし、Canaryステージですぐに利用できるようにします。アセットにWebPackを活用し、アセットの命名にSHAを適切に活用しているため、古いアセットを上書きする心配はありません。したがって、古いアセットは古いデプロイで引き続き利用可能であり、新しいアセットはCanaryがデプロイを開始するとすぐに利用可能になります。これはCanaryステージのデプロイ中にのみ実行されます。Canaryステージとmainステージは同じアセットストレージを共有しているため、mainステージのデプロイ時にはこれらの変更はすでに利用可能です。\n\n- **Gitaly：** 各GitalyノードでOmnibus LinuxパッケージによりGitaly仮想マシンスのトレージレイヤーを更新します。このサービスは[`git`とバンドル](https://gitlab.com/gitlab-org/gitaly/-/blob/master/doc/git-execution-environments.md)されているため、特殊です。したがって、このサービスがアトミックアップグレードを実行可能かを確認する必要があります。[Gitalyのラッパー](https://gitlab.com/gitlab-org/gitaly/-/tree/master/cmd/gitaly-wrapper)を活用し、新しいバージョンのGitalyをインストールし、ライブラリ[`tableflip`](https://github.com/cloudflare/tableflip)を使用しすることで、実行中のGitalyをクリーンにローテーションし、各インスタンスでこのサービスの高可用性を確保しています。\n\n- **Kubernetes：** Helmチャートを使用してコンテナ化されたGitLabコンポーネントをデプロイします。冗長性のために複数のゾーンにまたがる多数のクラスターにデプロイするため、通常これらは被害を最小限に抑えるために個別のステージに分割され、重大な問題が検出された場合はデプロイを途中で停止できるようにしています。\n\n\n### マルチバージョン互換性:隠れた課題\n\n\nプロセスを読むと、データベーススキーマがmainステージが認識しているコードより先行している期間があることに気付くでしょう。これは、Canaryステージが既に新しいコードをデプロイし、通常のデータベースマイグレーションを実行しているが、mainステージはまだこれらの新しいデータベース変更を認識していない以前のバージョンのコードを実行しているために発生します。\n\n**実際の例：** マージリクエストに新しい`merge_readiness`フィールドを追加するとします。デプロイ中、一部のサーバーはこのフィールドを期待するコードを実行していますが、他のサーバーはまだその存在を認識していません。これを適切に処理しないと、数百万人のユーザーが使用するGitLab.comが壊れてしまいます。適切に処理すれば、誰も何が起こったか気付きません。\n\nこれは他のほとんどのサービスでも発生します。たとえば、クライアントが複数のリクエストを送信する場合、そのうちの1つがCanaryステージに到達する可能性があります。他のリクエストはmainステージに向けられる可能性があります。これはデプロイとそれほど変わりません。サービスを実行している数千のPodを通過するのにかなりの時間がかかるためです。\n\n\nいくつかの例外を除いて、サービスの大部分は、Canaryでそのコンポーネントのわずかに新しいバージョンを一定期間実行します。ある意味では、これらのシナリオはすべて一時的な状態です。しかし、ライブの本番環境では数時間または数日間持続することがよくあります。したがって、永続的な状態と同じように注意を払って扱う必要があります。どのデプロイ中も、複数のバージョンのGitLabが同時に実行されており、それらすべてが適切に連携する必要があります。\n\n## データベース操作\n\nデータベースマイグレーションは、Canaryデプロイモデルにおいて独特の課題を提示します。新機能をサポートするためのスキーマ変更が必要な一方で、問題が発生した場合のロールバック機能を維持する必要があります。当社のソリューションでは、懸念を慎重に分離しています：\n\n- **通常マイグレーション:** Canaryステージ中に実行され、後方互換性を持つように設計され、可逆的な変更のみで構成されます\n\n- **デプロイ後マイグレーション:** 複数の成功したデプロイ後にのみ実行される「ポイント・オブ・ノーリターン」マイグレーション\n\n\nデータベース変更は、正確さと広範な検証手順により処理されます:\n\n\n```mermaid\n  graph LR\n      A[通常マイグレーション] --> B[Canaryステージデプロイ]\n      B --> C[mainステージデプロイ]\n      C --> D[デプロイ後マイグレーション]\n\n```\n\n### デプロイ後マイグレーション\n\n\nGitLabのデプロイには多くのコンポーネントが関与します。GitLabの更新はアトミックではないため、多くのコンポーネントが後方互換性を持つ必要があります。\n\n\nデプロイ後マイグレーションには、簡単にロールバックできない変更(データ変換、カラムの削除、または古いコードバージョンを壊す構造的変更など)が含まれることがよくあります。複数の成功したデプロイを通じて信頼を得た_後_にそれらを実行することで、次を保証します:\n\n\n1. **新しいコードが安定している**ため、ロールバックが必要になる可能性が低い\n\n2. **パフォーマンス特性**が本番環境で十分に理解されている\n\n3. **エッジケース**が発見され対処されている\n\n4. 問題が発生した場合に**影響範囲**が最小限に抑えられる\n\n\nこのアプローチは最適なバランスを提供します。Canaryリリースによる迅速な機能デプロイを可能にしながら、デプロイの安定性に高い信頼を得るまでロールバック機能を維持します。\n\n\n**拡張-移行-縮小パターン:** データベース、フロントエンド、アプリケーション互換性の変更は、慎重に調整された3段階のアプローチに従います。\n\n\n1. **拡張：** 古い構造を機能させたまま、新しい構造（カラム、インデックス）を追加\n\n2. **移行：** 新しい構造を使用する新しいアプリケーションコードをデプロイ\n\n3. **縮小：** すべてが安定した後、デプロイ後マイグレーションで古い構造を削除\n\n**実際の例:** マージリクエストに新しい`merge_readiness`カラムを追加する場合：\n\n1. **拡張：** デフォルト値を持つ新しいカラムを追加。既存のコードはそれを無視\n\n2. **移行：** 古いアプローチをサポートしながら、新しいカラムの読み書きを行うコードをデプロイ\n\n3 **縮小：** 複数の成功したデプロイの後、デプロイ後マイグレーションで古いカラムを削除\n\nすべてのデータベース操作、アプリケーションコード、フロントエンドコードなどは、エンジニアリングが遵守する必要がある一連のガイドラインの対象となります。これらは[マルチバージョン互換性ドキュメント](https://docs.gitlab.com/ja-jp/development/multi_version_compatibility/)で確認できます。\n\n\n## 結果と影響\n\nデプロイインフラストラクチャは測定可能なメリットを提供します:\n\n**GitLabにとって**\n\n* GitLab.comへの1日最大12回のデプロイ\n* 数百万人のデベロッパーにサービスを提供するダウンタイムゼロのデプロイ\n* セキュリティパッチを数日ではなく数時間以内で本番環境に提供可能\n* 一般公開前に大規模な本番環境で検証された新機能\n\n**お客様にとって**\n\n* 独自のアプリケーションに採用できる実証済みのデプロイパターン\n* お客様の環境に到達する前に、世界最大のGitLabインスタンスで実証された機能\n* 理論的なベストプラクティスではなく、実際の本番環境のプラクティスを反映したドキュメント\n* GitLabの推奨アップグレード手順が、あらゆる規模で機能するという確信\n\n## エンジニアリングチームへの重要なポイント\n\nGitLabのデプロイパイプラインは、デプロイ速度と運用の信頼性のバランスをとる洗練されたシステムを表しています。段階的デプロイモデル、包括的なテスト統合、堅牢なロールバック機能により、大規模な信頼性の高いソフトウェア配信の基盤を提供します。\n\n\n同様のシステムを実装するエンジニアリングチームにとって、次のような重要な考慮事項があります:\n\n\n- **自動テスト：** デプロイパイプライン全体にわたる包括的なテストカバレッジ\n\n- **段階的ロールアウト：** リスクを最小限に抑え、迅速な復旧を可能にする段階的デプロイ\n\n- **監視統合：** すべてのデプロイステージにわたる包括的な可観測性\n\n- **インシデント対応：** デプロイ問題の迅速な検出と解決能力\n\n\nGitLabのアーキテクチャは、最新のCI/CDシステムが競争力のあるソフトウェア開発に必要な速度を維持しながら、大規模デプロイの複雑性を管理する方法を実証しています。\n\n\n## 対象範囲に関する重要な注意事項\n\n\nこの記事では、特に**GitLab Omnibusパッケージ**と**Helmチャート**の一部であるサービス(基本的にコアGitLabモノリスとその緊密に統合されたコンポーネント)のデプロイパイプラインについて具体的に説明しています。\n\n\nただし、GitLabのインフラストラクチャの範囲は、ここで説明されている内容を超えて広がっています。他のサービス、特に**AIサービス**や**概念実証段階**にあるサービスは、Runwayと呼ばれる内部プラットフォームを使用した異なるデプロイアプローチに従っています。\n\n\nこれらの他のサービスで作業している場合、または興味がある場合は、[Runwayドキュメント](https://docs.runway.gitlab.com)で詳細情報を確認できます。\n\n\nGitLab Dedicatedなどの他のサービスは、お客様が**GitLab Environment Toolkit**を使用して、お客様自身で実行できることを期待する内容により沿った形でデプロイされます。詳細については、[GitLab Environment Toolkitプロジェクト](https://gitlab.com/gitlab-org/gitlab-environment-toolkit)をご覧ください。\n\n\nこの記事で概説されているデプロイ戦略、アーキテクチャに関する考慮事項、パイプラインの複雑性は、コアプラットフォームで使用している実証済みのアプローチを表していますが、大規模なエンジニアリング組織と同様に、さまざまなサービスタイプと成熟度レベルに合わせた複数のデプロイ戦略があります。\n\nAuto-Deployと手順に関する詳細なドキュメントは、以下のリンクで確認できます：\n  - [Engineering Deployments](https://handbook.gitlab.com/handbook/engineering/deployments-and-releases/deployments/)\n  - [Release Procedural Documentation](https://gitlab-org.gitlab.io/release/docs/)\n\n## その他のリソース\n\n- [GitLabリポジトリのバックアップ時間を48時間から41分に短縮した方法](https://about.gitlab.com/blog/how-we-decreased-gitlab-repo-backup-times-from-48-hours-to-41-minutes/)\n\n- [WebSocketでGitLab CIステータスを高速化した方法](https://about.gitlab.com/blog/how-we-supercharged-gitlab-ci-statuses-with-websockets/)\n\n- [バリューストリーム管理でMRレビュー時間を短縮した方法](https://about.gitlab.com/blog/how-we-reduced-mr-review-time-with-value-stream-management/)\n",[702],"John Skarbek","2026-01-15","2025-12-01","世界最大のGitLabインスタンスを1日12回デプロイする方法",[707,708],"product","inside GitLab","GitLab.comのデプロイパイプラインを技術的に深掘りします。段階的ロールアウト、Canary戦略、データベースマイグレーション、マルチバージョン互換性について解説します。",{"featured":13,"template":14,"slug":711},"continuously-deploying-the-largest-gitlab-instance",{"content":713,"config":722},{"description":714,"title":715,"authors":716,"heroImage":718,"date":719,"category":10,"body":720,"updatedDate":721},"SaaSの基礎、利用するメリット・デメリット、PaaSやIaaSとの違い、ソフトウェア開発に役立つサービスなどをご紹介。ぜひお読みください。","SaaSとは？意味・読み方・PaaS/IaaSとの違い・メリットをわかりやすく解説",[717],"GitLab Team","https://res.cloudinary.com/about-gitlab-com/image/upload/v1760421091/iaruhhz70gncm8bqfqyg.jpg","2025-10-15","SaaSを利用することで、様々な業務をより効率的に、かつ低コストで実施できます。本記事では、SaaSとは何かを分かりやすく説明するとともに、用途別のおすすめSaaSやソフトウェア開発におけるSaaS活用のメリットなどを解説します。GitLabが提供するSaaSも後半で詳しくご紹介します。\n## 目次\n* SaaSとは？\n* ソフトウェア利用モデルの比較\n* SaaSのメリット\n* SaaSのデメリット\n* SaaSとPaaS・IaaSの違いとは？\n* SaaSを選ぶ際のポイント\n* 代表的なSaaSと主な機能\n* GitLabはソフトウェア開発にどのように貢献するのか？\n* SaaSやGitLabに関するFAQ\n## SaaSとは？仕組みやクラウドとの違い\nSaaSは「Software as a Service」の略称で、読み方は「サース」もしくは「サーズ」です。日本語にすると「サービスとしてのソフトウェア」となります。\nSaaSは、サービス提供会社（ベンダー）のサーバーで提供されているソフトウェアを、インターネットなどのネットワークを介して利用できるサービスのことです。自身のパソコンや自社サーバーにソフトウェアをインストールしなくても、インターネット経由で最新のサービスを利用できます。\nSaaSの例としてよく挙げられるのがGoogleが提供しているGoogleドキュメントやGoogleスプレッドシート、Googleドライブなどです。特定のソフトウェアやアプリをインストールしなくても、これらの機能をオンライン上で自由に利用できます。\n弊社が提供しているソフトウェア開発プラットフォーム「[GitLab](https://about.gitlab.com/ja-jp/)」も、ソフトウェア開発に関するSaaSの代表格の1つです。\n### SaaSの仕組み\n一般的なソフトウェアは自社のサーバーやパソコンなどにインストールして利用しますが、SaaSの場合には、サービス提供会社のサーバーにてソフトウェアが起動しています。インターネットを介してサービス提供会社のサーバーに接続し、そこでソフトウェアを利用する、というのがSaaSの主な仕組みです。\n提供会社がソフトウェアを頻繁にアップデートしているため、最新のサービスがどこからでも、どのデバイスからでも利用できます。\n### SaaSとクラウドサービスの違い\nよく似た言葉に「クラウドサービス」があります。同様の意味合いで使われる用語ですが、クラウドサービスはアプリに限定されないより広範な概念です。後に説明するPaaSやIaaSなどもクラウドサービスに当てはまります。クラウドサービスの1つがSaaSだと考えるとよいでしょう。\n## ソフトウェア利用モデルの比較\n企業がソフトウェアを利用する方法は主に以下の3つです。\n*  オンプレミス型\n* インストール型\n* SaaS\nそれぞれの特徴について簡単に説明します。\n### オンプレミス型\nオンプレミス型とは、自社のサーバーにソフトウェアを組み入れ、自社独自のシステムを構築する方法です。思い通りにカスタマイズできる、情報漏洩のリスクが少ないなどのメリットがありますが、一方で構築までに時間と費用がかかる、保守が正しくできないとセキュリティリスクが高まるなどのデメリットもあります。\n### インストール型\nインストール型は、ソフトウェアを利用予定のパソコンにインストールすることで、そのパソコンでのみ機能が使えるようにする方法です。オンプレミス型に比べると低価格で利用できる、導入に時間がかからないなどのメリットがありますが、一方で機能の拡張が難しい、アップデートのし忘れによるセキュリティ脆弱性リスクが高いなどのデメリットがあります。\n### SaaS\n昨今の主流となっているSaaSは、運営会社が管理しているサービスにインターネットを介してアクセスし、オンライン上で利用する方法です。\nより最先端の機能を利用したい、セキュリティに配慮したソフトウェアを利用したい、料金を安く抑えたいなどのニーズの増加により、オンプレミス型やインストール型ではなく、SaaSを利用する企業が増えています。\n## SaaSのメリット\nSaaSには、オンプレミス型やインストール型にはない数々のメリットがあります。\n### 最新の機能を利用できる\nサービス提供会社が自社のサーバー内でソフトウェアのアップデートを行い、そのサービスをインターネットを経由して利用するため、常に最新の機能やデザインを利用できます。\n### 利用開始までの時間が短い\nSaaSはインターネット上で契約と支払いを済ませたら、即座に利用が可能です。最低利用期間が定められているSaaSが多いものの、解約手続きも比較的簡単です。\n### 導入費用を抑制できる\n多くのSaaSは初期導入費用が無料、もしくはオンプレミス型と比べて安い傾向にあります。\n初期投資で大きな資金を準備することが難しい企業にとっては、毎月支払いのSaaSの料金プランは大きな魅力といえます。\n### セキュリティ対策に強い\nSaaSはサービス提供会社がソフトウェアに対してセキュリティ対策を実施します。自社でセキュリティ対策を行う必要がないため、人件費や労力を削減できるとともに、高い安全性が確保されたソフトウェアを使い続けることが可能です。\n### 場所を選ばない\nSaaSはインターネットさえ使えれば、どこにいても、どのデバイスからでも同様のサービスやデータにアクセスできます。急な出張が入り自身のパソコンを利用できない場合でも、別のパソコンを使ってログインすることで、普段と同じデータにアクセスできます。\n昨今拡大しているリモートワークとも相性のよいモデルとして需要が高まっています。\n### 複数人での利用に強い\nSaaSは複数人による利用に優れています。元となるデータがクラウドサーバー上に保存されているため、複数人がそのデータに直接アクセスし、同時並行で作業を進められます。\n例えば、ソフトウェア開発に関するSaaSを利用すれば、複数のデベロッパーが同時に作業を行い、それぞれの作業を即座に反映させることが可能です。\n## SaaSのデメリット\n多くのメリットがあるSaaSですが、もちろんいくつかのデメリットもあります。SaaSを利用する際には、これらのデメリットについてもよく理解し、事前に対策を練るようにしてください。\n### ソフトウェアアップデートによる急な仕様の変更\nSaaSは、サービス提供会社によって常にアップデートが行われています。方向性の転換により、操作画面の機能やデザインが急に変更になったり、これまで頻繁に使っていたシステムがなくなったりすることがあります。以前のバージョンが使いやすかったと感じても、自社の判断によって戻すことはできません。\n### 継続的な出費が発生する\n初回導入時には比較的予算が抑えられるSaaSですが、月額・年額の継続費用が発生し、長期利用ではコストが高くなる場合があります。\n### ログイン情報の漏洩によるセキュリティリスク\nサービスにアクセスするためのログイン情報が漏れた場合、他者にアクセスされる可能性が生じます。二段階認証プロセスを利用することで不正なアクセスは防げるものの、ログイン情報の管理については慎重に実施する必要があります。\n### ネットワーク環境の影響を受ける\nSaaSは、インターネットが利用できない場所では利用できません。停電やネットワークエラーによってインターネットが使えない場合、SaaSにアクセスできなくなり、作業が一時中断してしまう可能性があります。\n### SaaS側の不具合やメンテナンス\nSaaSが何らかの不具合に直面した場合、もしくは大規模なシステムアップデートのため長期に及ぶメンテナンスが必要になった場合には、サービスが一時的に利用できなくなる可能性があります。\n利用予定のSaaSが頻繁なメンテナンスを実施していないか、メンテナンスの場合には代替機能が利用できるかどうかを事前にチェックするとよいでしょう。\n## SaaSとPasS・IaaSの違いとは？サービス内容も紹介\nSaaSとよく比較される用語に「PaaS」と「IaaS」があります。自社に最適な機能を選ぶうえで、これらの違いを理解することは非常に重要です。\n### PaaSとは\nPaaSは「Platform as a Service」の略称で、「パース」と読みます。名称からもわかる通り、PaaSは主にクラウド上で利用できるプラットフォームを指します。PaaSの提供範囲は主にプラットフォームのため、ソフトウェアやアプリは含みません。\n例えばPaaSは、システムやアプリケーションを開発するためのプラットフォームをクラウド上で提供します。複数のデベロッパーが同時にアクセスし、協力体制のもとでアプリケーション開発などを進める場合に役立ちます。\n### IaaSとは\nIaaSは「Infrastructure as a Service」の略称で、「イーアス」や「アイアース」と読みます。IaaSがクラウド上で提供するのはサーバーやネットワークなどのインフラ基盤のみです。ソフトウェアやプラットフォームなど、事前に構築されたシステムや枠組みがないため、より自由な開発環境を整えたい企業に向いています。ただし、開発環境の構築も含めて自社で実施するだけの人材力やスキルが必要とされます。\n### SaaS・PaaS・IaaSの比較\nSaaSとPaaS、IaaSの各サービス内容をまとめると、以下のようになります。\n表1　SaaS・PaaS・IaaSが網羅するサービスの比較\n| サービス            | SaaS | PaaS | IaaS |\n| --------------- | ---- | ---- | ---- |\n| ソフトウェア・アプリケーション | ◎    |      |      |\n| ミドルウェア          | 〇    | ◎    |      |\n| OS              | 〇    | ◎    |      |\n| ネットワーク          | 〇    | 〇    | ◎    |\n| ストレージ           | 〇    | 〇    | ◎    |\n| サーバー            | 〇    | 〇    | ◎    |\n\n\nSaaSはすべてを網羅しているとはいえ、ミドルウェアやOSの使い勝手や機能に関してはPaaSがより優れています。IaaSは質の高いインフラ基盤を比較的安価に導入できる方法として、SaaSやPaaSとは差別化できます。\nそれぞれの特徴をよく理解した上で、自社に最適なサービスを導入することが重要です。\n## SaaSを選ぶ際のポイント\n自社の現状や課題に合ったSaaSを利用することで、業務効率化やコスト削減を実現することができます。一方で、自社に合わないSaaSを選んでしまうと、不慣れな作業によって時間がかかったり、せっかく購入したにも関わらず活用されなかったりする場合があります。\nそのため、SaaSを導入する際には以下のポイントをよく確認するようにしてください。\n### 機能性\nSaaSの機能は事務系やコミュニケーション系、ソフトウェア開発系など多岐にわたります。自社で解決したい課題をリストアップするとともに、どの機能を備えたSaaSが最適かをよく検討するようにしてください。\nまた、用途だけでなく、機能や操作画面の使い勝手も確認するとよいでしょう。例えば、日本語に最適化されていないSaaSでは、言語の違いによりスムーズに利用できない可能性があります。\nミスマッチを防ぐためにも、まずは無料トライアルを提供しているSaaSを選び、試してみることをおすすめします。\n### コストや料金体系\nSaaSは初期費用が比較的安く設定されているのが特徴です。ただし、毎月もしくは毎年費用が発生するため、長期的にみると大きな費用負担になる場合があります。多くのSaaSは1ユーザーごとの料金設定のため、大勢で利用した場合にはコストが大きくなります。\nまた、SaaSは最低利用期間や解約までに必要な月数などが設定されている場合がほとんどです。解約しやすいのがSaaSの特徴の1つですが、場合によっては解約時にも費用が発生する点にも注意が必要です。\n### セキュリティ\nSaaSでは、システム利用やデータの保管はすべてサービス提供会社のサーバー内で行われるため、自社でセキュリティ対策を実施する必要はありません。ただし、提供会社側でセキュリティ問題が発生した場合には、重要なデータが消去もしくは漏洩する可能性があります。\nSaaSを利用する際には、セキュリティ対策の充実度をしっかりと確認するようにしてください。\n### サポート体制\nSaaSは様々な機能が随時追加されるため、機能やデザインなどに関して、サポートの助けが必要になることが多々あります。特に緊急性のある案件に関係するSaaSにおいては、電話対応や24時間のチャットサポートに対応しているかは重要です。また、海外発のSaaSを利用する際には、日本語サポートにも対応しているかを確認するようにしてください。\n## 代表的なSaaSと主な機能\n企業が導入を検討すべきおすすめのSaaSを紹介します。\n### オフィス業務に強い「Google WorkSpace」\n「[Google Workspace](https://www.g-workspace.jp/googleworkspace/)」は、Google社が提供する有料オンラインアプリケーションセットです。GoogleドキュメントやGoogleスプレッドシート、Googleドライブ、Gmailなど、オフィス作業や業務効率化に役立つ数々のツールが利用できます。データはすべてGoogleのサーバー内に保管され、Googleが常に最新のセキュリティ対策を行っているため、安心して利用できます。\n利用には一定の[費用](https://www.g-workspace.jp/price/)が掛かりますが、様々な便利機能を安心して利用したい企業におすすめです。\n### 気軽なチャット機能が人気「ChatWork」\n多くの企業が導入しているチャット型のコミュニケーションツールが「[ChatWork](https://go.chatwork.com/ja/)」です。メールでのやりとりでは、文章を作成したり回答を得たりするのに時間がかかりますが、ChatWorkのチャットであれば時間を大幅に削減できます。\nチャットデータはすべてChatWorkが管理するサーバー内に保管されているため、パソコンやスマホ、タブレットなど、デバイスを選ばずに利用できます。日本企業が開発したSaaSのため、日本人が使いやすいように設計・最適化されているのも大きな魅力といえます。\nフリープランは無料で利用できますが、ビジネス用途であれば高いセキュリティ性能を備えた[エンタープライズプラン](https://go.chatwork.com/ja/price/?click=header-navi)がおすすめです。現在社内でのやりとりでメールを利用している、社員間のコミュニケーションを促進するツールを探している企業に最適です。\n### オンラインミーティングの大改革を果たした「Zoom」\nミーティングや営業のあり方を大きく変えたことで知られるのが「[Zoom](https://www.zoom.com/ja)」です。インターネットを利用したオンラインミーティングが実施でき、異なる場所や出張時・在宅ワークなどでのミーティング参加が可能となりました。\nまた、Zoomは営業向けにも様々な便利機能を追加しており、録画機能や自動文字起こし、資料の共有、スケジュール管理など、1つのツールで多様な課題を解決できます。\n無料のベーシックプランでもオンラインミーティング機能は利用できますが、長時間のミーティングを開催したい、より便利な機能を利用したいという方は、有料の[ビジネスプラン](https://www.zoom.us/ja/pricing?optimizely_user_id=e1913a438ebff25397b6ac8df20b7ac4&amp_device_id=a3148cc2-3076-420f-9c2e-569a037fc688&_ics=1731285869840&irclickid=%7Ebhadihjcf8134WZOMNV1RIJGKHABFxwrmukopfgb3VKHFAypg-8Z&_gl=1*sl16es*_gcl_au*MzE1NDA4NTUwLjE3MzEyODU4Njk.*_ga*NTAzNTU1OTQ1LjE3MzEyODU4NzA.*_ga_L8TBF28DDX*MTczMTI4NTg3MC4xLjAuMTczMTI4NTg3MC4wLjAuMA..&_ga=2.208402578.1219391157.1731285871-503555945.1731285870)がおすすめです。\n### アプリケーション開発に最適な「GitLab」\nアプリケーション・ソフトウェア開発におすすめのSaaSが、弊社が提供する「[GitLab](https://about.gitlab.com/ja-jp/)」です。AI搭載のDevSecOpsプラットフォームで、開発効率化やセキュリティに優れています。\n複数のデベロッパーが同時並行で作業できる[マルチテナント環境](https://about.gitlab.com/ja-jp/why-gitlab/)を提供するとともに、AIを含めた様々な便利アプリにより開発を効率化できます。\nビジネス目的であれば、より多くの機能が利用でき、かつセキュリティも充実している「Premium」や「Ultimate」などの有料プランがおすすめです。60日間の[無料トライアル](https://gitlab.com/-/trial_registrations/new?glm_source=about.gitlab.com/ja-jp/why-gitlab/&glm_content=default-saas-trial)もあるため、まずはお気軽にお問い合わせください。\nまた、より迅速に開発を進めたい方向けに、シングルテナント型SaaSで提供される「[GitLab Dedicated](https://about.gitlab.com/dedicated/)」サービスもあります。GitLabチームがプラットフォーム管理やデプロイを担当するため、必要な作業が大幅に削減され、重要なタスクに注力可能です。\n## GitLabはソフトウェア開発にどのように貢献するのか？\nGitLabは、クラウド上で機能するソフトウェアアプリケーション開発プラットフォームです。企業は開発、保護、そしてデプロイの複雑化に効果的に対応でき、結果としてサイクルタイムを1/7に短縮できる可能性があります。\nデベロッパーの生産性が向上するとともに、メンテナンスに必要な時間を削減できるため、多くの時間をより重要な作業に費やすことが可能です。スピーディで効率的な開発を行うことで、他社と差別化できます。\n従来からDevSecOpsプラットフォームの開発に専念してきたGitLabでは、特にセキュリティ分野において優位性を持ちます。GitLabのセキュリティ対策チームが常に最新のセキュリティ対策を研究し、ツールに導入しているため、弊社SaaSを利用する際には、すでに最新の対策が施されている状態です。これにより、開発したソフトウェアの安全を確保します。\n## SaaSやGitLabに関するFAQ\nSaaSやGitLabに関するFAQについて以下にまとめてあります。ぜひ参考にしてください。\n### GitLabではどのようなSaaS開発環境やオプションが可能か？\nGitLabでは、GitLabプラットフォームが自由に使える[マルチテナントSaaS](https://about.gitlab.com/ja-jp/why-gitlab/)と、デプロイや管理をGitLab側で担当するシングルテナントSaaSの[GitLab Dedicated](https://about.gitlab.com/dedicated/)のどちらかをお選びいただけます。また、GitLabではオンプレミスにも対応しています。\n\n\nSaaSによるソフトウェア開発が初めてで管理や操作に不安が残る方には、GitLab Dedicatedをおすすめします。ぜひご検討ください。\n### 開発分野のSaaSに限定した場合、オンプレミスと比べてどのようなメリットがあるか？\nオンプレミス型の開発環境の場合、セキュリティやガバナンス対策を自社ですべて実施する必要があります。人材を保守や運用、調査などに回す必要があるため、大きな人的コストがかかるのと同時に、開発速度も遅くなります。\n\n\nSaaSによる開発環境では、セキュリティやガバナンスをGitLabが調査、適用するため、保守運用にかかる時間を大幅に削減できます。昨今は必要なセキュリティ対策やガバナンス対策が頻繁に変化する時代です。SaaSによる開発環境を利用することで、それらの心配をする必要がなくなり、重要な作業に集中できます。\n### その他のSaaS開発環境と比較した際のGitLabの強みとは\nGitLabは、ソフトウェア開発のライフサイクル全体に対応する**DevSecOpsプラットフォーム**です。Fortune100企業の50％強が利用し、登録ユーザー数は2024年時点で約3,000万人を超えています。\n\n\nGitLabは迅速かつ効率的なソフトウェアデリバリーを実現する包括的なプラットフォームとして常に進化を遂げてきました。また、早くからセキュリティやコンプライアンスを重要な軸として位置づけ、プラットフォーム内に機能を組み入れてきた歴史があります。\n\n\n昨今はセキュリティに配慮しつつ、ガバナンスやコンプライアンスを順守しながらソフトウェア開発を進めていく必要があります。しかしながら、優秀なデベロッパーが保守運用に時間をとられ、何よりも重要な開発作業に時間を割けない問題が多くの企業で発生しています。GitLabプラットフォームを利用することで、デベロッパーがセキュリティ対策やエラー修正にかける時間を大幅に削減できます。 [GitLab](https://about.gitlab.com/ja-jp/)は、設立当初から、リモートワーク、オープンソース、DevSecOps、イテレーションへの確固たる信念を持ち続けてきました。GitLabは新しいイノベーションを模索し続けます。より優れた開発プラットフォームを模索している企業様に、GitLabは最先端・最高品質のサービスを提供いたします。","2026-03-03",{"featured":32,"template":14,"slug":723},"what-is-saas",{"promotions":725},[726,740,752],{"id":727,"categories":728,"header":730,"text":731,"button":732,"image":737},"ai-modernization",[729],"ai-ml","Is AI achieving its promise at scale?","Quiz will take 5 minutes or less",{"text":733,"config":734},"Get your AI maturity score",{"href":735,"dataGaName":736,"dataGaLocation":243},"/assessments/ai-modernization-assessment/","modernization assessment",{"config":738},{"src":739},"https://res.cloudinary.com/about-gitlab-com/image/upload/v1772138786/qix0m7kwnd8x2fh1zq49.png",{"id":741,"categories":742,"header":744,"text":731,"button":745,"image":749},"devops-modernization",[707,743],"devsecops","Are you just managing tools or shipping innovation?",{"text":746,"config":747},"Get your DevOps maturity score",{"href":748,"dataGaName":736,"dataGaLocation":243},"/assessments/devops-modernization-assessment/",{"config":750},{"src":751},"https://res.cloudinary.com/about-gitlab-com/image/upload/v1772138785/eg818fmakweyuznttgid.png",{"id":753,"categories":754,"header":756,"text":731,"button":757,"image":761},"security-modernization",[755],"security","Are you trading speed for security?",{"text":758,"config":759},"Get your security maturity score",{"href":760,"dataGaName":736,"dataGaLocation":243},"/assessments/security-modernization-assessment/",{"config":762},{"src":763},"https://res.cloudinary.com/about-gitlab-com/image/upload/v1772138786/p4pbqd9nnjejg5ds6mdk.png",{"header":765,"blurb":766,"button":767,"secondaryButton":771},"今すぐ開発をスピードアップ","DevSecOpsに特化したインテリジェントオーケストレーションプラットフォームで実現できることをご確認ください。\n",{"text":46,"config":768},{"href":769,"dataGaName":49,"dataGaLocation":770},"https://gitlab.com/-/trial_registrations/new?glm_content=default-saas-trial&glm_source=about.gitlab.com/","feature",{"text":51,"config":772},{"href":53,"dataGaName":54,"dataGaLocation":770},1772652109605]