[{"data":1,"prerenderedAt":818},["ShallowReactive",2],{"/ja-jp/blog/categories/agile-planning/":3,"navigation-ja-jp":22,"banner-ja-jp":439,"footer-ja-jp":452,"agile-planning-category-page-ja-jp":662},{"_path":4,"_dir":5,"_draft":6,"_partial":6,"_locale":7,"seo":8,"content":11,"config":12,"_id":15,"_type":16,"title":17,"_source":18,"_file":19,"_stem":20,"_extension":21},"/ja-jp/blog/categories/agile-planning","categories",false,"",{"title":9,"description":10},"アジャイル計画","Browse articles related to アジャイル計画 on the GitLab Blog",{"name":9},{"template":13,"slug":14,"hide":6},"BlogCategory","agile-planning","content:ja-jp:blog:categories:agile-planning.yml","yaml","Agile Planning","content","ja-jp/blog/categories/agile-planning.yml","ja-jp/blog/categories/agile-planning","yml",{"_path":23,"_dir":24,"_draft":6,"_partial":6,"_locale":7,"data":25,"_id":435,"_type":16,"title":436,"_source":18,"_file":437,"_stem":438,"_extension":21},"/shared/ja-jp/main-navigation","ja-jp",{"logo":26,"freeTrial":31,"sales":36,"login":41,"items":46,"search":379,"minimal":413,"duo":426},{"config":27},{"href":28,"dataGaName":29,"dataGaLocation":30},"/ja-jp/","gitlab logo","header",{"text":32,"config":33},"無料トライアルを開始",{"href":34,"dataGaName":35,"dataGaLocation":30},"https://gitlab.com/-/trial_registrations/new?glm_source=about.gitlab.com&glm_content=default-saas-trial/","free trial",{"text":37,"config":38},"お問い合わせ",{"href":39,"dataGaName":40,"dataGaLocation":30},"/ja-jp/sales/","sales",{"text":42,"config":43},"サインイン",{"href":44,"dataGaName":45,"dataGaLocation":30},"https://gitlab.com/users/sign_in/","sign in",[47,91,190,195,301,361],{"text":48,"config":49,"cards":51,"footer":74},"プラットフォーム",{"dataNavLevelOne":50},"platform",[52,58,66],{"title":48,"description":53,"link":54},"最も包括的かつAIで強化されたDevSecOpsプラットフォーム",{"text":55,"config":56},"プラットフォームを詳しく見る",{"href":57,"dataGaName":50,"dataGaLocation":30},"/ja-jp/platform/",{"title":59,"description":60,"link":61},"GitLab Duo（AI）","開発のすべてのステージでAIを活用し、ソフトウェアをより迅速にビルド",{"text":62,"config":63},"GitLab Duoのご紹介",{"href":64,"dataGaName":65,"dataGaLocation":30},"/ja-jp/gitlab-duo/","gitlab duo ai",{"title":67,"description":68,"link":69},"GitLabが選ばれる理由","GitLabが大企業に選ばれる理由10選",{"text":70,"config":71},"詳細はこちら",{"href":72,"dataGaName":73,"dataGaLocation":30},"/ja-jp/why-gitlab/","why gitlab",{"title":75,"items":76},"利用を開始：",[77,82,87],{"text":78,"config":79},"プラットフォームエンジニアリング",{"href":80,"dataGaName":81,"dataGaLocation":30},"/ja-jp/solutions/platform-engineering/","platform engineering",{"text":83,"config":84},"開発者の経験",{"href":85,"dataGaName":86,"dataGaLocation":30},"/ja-jp/developer-experience/","Developer experience",{"text":88,"config":89},"MLOps",{"href":90,"dataGaName":88,"dataGaLocation":30},"/ja-jp/topics/devops/the-role-of-ai-in-devops/",{"text":92,"left":93,"config":94,"link":96,"lists":100,"footer":172},"製品",true,{"dataNavLevelOne":95},"solutions",{"text":97,"config":98},"すべてのソリューションを表示",{"href":99,"dataGaName":95,"dataGaLocation":30},"/ja-jp/solutions/",[101,127,150],{"title":102,"description":103,"link":104,"items":109},"自動化","CI/CDと自動化でデプロイを加速",{"config":105},{"icon":106,"href":107,"dataGaName":108,"dataGaLocation":30},"AutomatedCodeAlt","/ja-jp/solutions/delivery-automation/","automated software delivery",[110,114,118,123],{"text":111,"config":112},"CI/CD",{"href":113,"dataGaLocation":30,"dataGaName":111},"/ja-jp/solutions/continuous-integration/",{"text":115,"config":116},"AIアシストによる開発",{"href":64,"dataGaLocation":30,"dataGaName":117},"AI assisted development",{"text":119,"config":120},"ソースコード管理",{"href":121,"dataGaLocation":30,"dataGaName":122},"/ja-jp/solutions/source-code-management/","Source Code Management",{"text":124,"config":125},"自動化されたソフトウェアデリバリー",{"href":107,"dataGaLocation":30,"dataGaName":126},"Automated software delivery",{"title":128,"description":129,"link":130,"items":135},"セキュリティ","セキュリティを損なうことなくコードをより迅速に完成",{"config":131},{"href":132,"dataGaName":133,"dataGaLocation":30,"icon":134},"/ja-jp/solutions/security-compliance/","security and compliance","ShieldCheckLight",[136,140,145],{"text":137,"config":138},"セキュリティとコンプライアンス",{"href":132,"dataGaLocation":30,"dataGaName":139},"Security & Compliance",{"text":141,"config":142},"ソフトウェアサプライチェーンの安全性",{"href":143,"dataGaLocation":30,"dataGaName":144},"/ja-jp/solutions/supply-chain/","Software supply chain security",{"text":146,"config":147},"コンプライアンスとガバナンス",{"href":148,"dataGaLocation":30,"dataGaName":149},"/ja-jp/solutions/continuous-software-compliance/","Compliance and governance",{"title":151,"link":152,"items":157},"測定",{"config":153},{"icon":154,"href":155,"dataGaName":156,"dataGaLocation":30},"DigitalTransformation","/ja-jp/solutions/visibility-measurement/","visibility and measurement",[158,162,167],{"text":159,"config":160},"可視性と測定",{"href":155,"dataGaLocation":30,"dataGaName":161},"Visibility and Measurement",{"text":163,"config":164},"バリューストリーム管理",{"href":165,"dataGaLocation":30,"dataGaName":166},"/ja-jp/solutions/value-stream-management/","Value Stream Management",{"text":168,"config":169},"分析とインサイト",{"href":170,"dataGaLocation":30,"dataGaName":171},"/ja-jp/solutions/analytics-and-insights/","Analytics and insights",{"title":173,"items":174},"GitLabが活躍する場所",[175,180,185],{"text":176,"config":177},"Enterprise",{"href":178,"dataGaLocation":30,"dataGaName":179},"/ja-jp/enterprise/","enterprise",{"text":181,"config":182},"スモールビジネス",{"href":183,"dataGaLocation":30,"dataGaName":184},"/ja-jp/small-business/","small business",{"text":186,"config":187},"公共機関",{"href":188,"dataGaLocation":30,"dataGaName":189},"/ja-jp/solutions/public-sector/","public sector",{"text":191,"config":192},"価格",{"href":193,"dataGaName":194,"dataGaLocation":30,"dataNavLevelOne":194},"/ja-jp/pricing/","pricing",{"text":196,"config":197,"link":199,"lists":203,"feature":288},"関連リソース",{"dataNavLevelOne":198},"resources",{"text":200,"config":201},"すべてのリソースを表示",{"href":202,"dataGaName":198,"dataGaLocation":30},"/ja-jp/resources/",[204,237,260],{"title":205,"items":206},"はじめに",[207,212,217,222,227,232],{"text":208,"config":209},"インストール",{"href":210,"dataGaName":211,"dataGaLocation":30},"/ja-jp/install/","install",{"text":213,"config":214},"クイックスタートガイド",{"href":215,"dataGaName":216,"dataGaLocation":30},"/ja-jp/get-started/","quick setup checklists",{"text":218,"config":219},"学ぶ",{"href":220,"dataGaLocation":30,"dataGaName":221},"https://university.gitlab.com/","learn",{"text":223,"config":224},"製品ドキュメント",{"href":225,"dataGaName":226,"dataGaLocation":30},"https://docs.gitlab.com/","product documentation",{"text":228,"config":229},"ベストプラクティスビデオ",{"href":230,"dataGaName":231,"dataGaLocation":30},"/ja-jp/getting-started-videos/","best practice videos",{"text":233,"config":234},"インテグレーション",{"href":235,"dataGaName":236,"dataGaLocation":30},"/ja-jp/integrations/","integrations",{"title":238,"items":239},"検索する",[240,245,250,255],{"text":241,"config":242},"お客様成功事例",{"href":243,"dataGaName":244,"dataGaLocation":30},"/ja-jp/customers/","customer success stories",{"text":246,"config":247},"ブログ",{"href":248,"dataGaName":249,"dataGaLocation":30},"/ja-jp/blog/","blog",{"text":251,"config":252},"リモート",{"href":253,"dataGaName":254,"dataGaLocation":30},"https://handbook.gitlab.com/handbook/company/culture/all-remote/","remote",{"text":256,"config":257},"TeamOps",{"href":258,"dataGaName":259,"dataGaLocation":30},"/ja-jp/teamops/","teamops",{"title":261,"items":262},"つなげる",[263,268,273,278,283],{"text":264,"config":265},"GitLabサービス",{"href":266,"dataGaName":267,"dataGaLocation":30},"/ja-jp/services/","services",{"text":269,"config":270},"コミュニティ",{"href":271,"dataGaName":272,"dataGaLocation":30},"/community/","community",{"text":274,"config":275},"フォーラム",{"href":276,"dataGaName":277,"dataGaLocation":30},"https://forum.gitlab.com/","forum",{"text":279,"config":280},"イベント",{"href":281,"dataGaName":282,"dataGaLocation":30},"/events/","events",{"text":284,"config":285},"パートナー",{"href":286,"dataGaName":287,"dataGaLocation":30},"/ja-jp/partners/","partners",{"backgroundColor":289,"textColor":290,"text":291,"image":292,"link":296},"#2f2a6b","#fff","ソフトウェア開発の未来への洞察",{"altText":293,"config":294},"ソースプロモカード",{"src":295},"/images/navigation/the-source-promo-card.svg",{"text":297,"config":298},"最新情報を読む",{"href":299,"dataGaName":300,"dataGaLocation":30},"/ja-jp/the-source/","the source",{"text":302,"config":303,"lists":305},"Company",{"dataNavLevelOne":304},"company",[306],{"items":307},[308,313,319,321,326,331,336,341,346,351,356],{"text":309,"config":310},"GitLabについて",{"href":311,"dataGaName":312,"dataGaLocation":30},"/ja-jp/company/","about",{"text":314,"config":315,"footerGa":318},"採用情報",{"href":316,"dataGaName":317,"dataGaLocation":30},"/jobs/","jobs",{"dataGaName":317},{"text":279,"config":320},{"href":281,"dataGaName":282,"dataGaLocation":30},{"text":322,"config":323},"経営陣",{"href":324,"dataGaName":325,"dataGaLocation":30},"/company/team/e-group/","leadership",{"text":327,"config":328},"チーム",{"href":329,"dataGaName":330,"dataGaLocation":30},"/company/team/","team",{"text":332,"config":333},"ハンドブック",{"href":334,"dataGaName":335,"dataGaLocation":30},"https://handbook.gitlab.com/","handbook",{"text":337,"config":338},"投資家向け情報",{"href":339,"dataGaName":340,"dataGaLocation":30},"https://ir.gitlab.com/","investor relations",{"text":342,"config":343},"トラストセンター",{"href":344,"dataGaName":345,"dataGaLocation":30},"/ja-jp/security/","trust center",{"text":347,"config":348},"AI Transparency Center",{"href":349,"dataGaName":350,"dataGaLocation":30},"/ja-jp/ai-transparency-center/","ai transparency center",{"text":352,"config":353},"ニュースレター",{"href":354,"dataGaName":355,"dataGaLocation":30},"/company/contact/","newsletter",{"text":357,"config":358},"プレス",{"href":359,"dataGaName":360,"dataGaLocation":30},"/press/","press",{"text":37,"config":362,"lists":363},{"dataNavLevelOne":304},[364],{"items":365},[366,369,374],{"text":37,"config":367},{"href":39,"dataGaName":368,"dataGaLocation":30},"talk to sales",{"text":370,"config":371},"サポートを受ける",{"href":372,"dataGaName":373,"dataGaLocation":30},"/support/","get help",{"text":375,"config":376},"カスタマーポータル",{"href":377,"dataGaName":378,"dataGaLocation":30},"https://customers.gitlab.com/customers/sign_in/","customer portal",{"close":380,"login":381,"suggestions":388},"閉じる",{"text":382,"link":383},"リポジトリとプロジェクトを検索するには、次にログインします",{"text":384,"config":385},"GitLab.com",{"href":44,"dataGaName":386,"dataGaLocation":387},"search login","search",{"text":389,"default":390},"提案",[391,394,399,401,405,409],{"text":59,"config":392},{"href":64,"dataGaName":393,"dataGaLocation":387},"GitLab Duo (AI)",{"text":395,"config":396},"コード提案（AI）",{"href":397,"dataGaName":398,"dataGaLocation":387},"/ja-jp/solutions/code-suggestions/","Code Suggestions (AI)",{"text":111,"config":400},{"href":113,"dataGaName":111,"dataGaLocation":387},{"text":402,"config":403},"GitLab on AWS",{"href":404,"dataGaName":402,"dataGaLocation":387},"/ja-jp/partners/technology-partners/aws/",{"text":406,"config":407},"GitLab on Google Cloud",{"href":408,"dataGaName":406,"dataGaLocation":387},"/ja-jp/partners/technology-partners/google-cloud-platform/",{"text":410,"config":411},"GitLabを選ぶ理由",{"href":72,"dataGaName":412,"dataGaLocation":387},"Why GitLab?",{"freeTrial":414,"mobileIcon":418,"desktopIcon":423},{"text":32,"config":415},{"href":416,"dataGaName":35,"dataGaLocation":417},"https://gitlab.com/-/trials/new/","nav",{"altText":419,"config":420},"GitLabアイコン",{"src":421,"dataGaName":422,"dataGaLocation":417},"/images/brand/gitlab-logo-tanuki.svg","gitlab icon",{"altText":419,"config":424},{"src":425,"dataGaName":422,"dataGaLocation":417},"/images/brand/gitlab-logo-type.svg",{"freeTrial":427,"mobileIcon":431,"desktopIcon":433},{"text":428,"config":429},"GitLab Duoの詳細について",{"href":64,"dataGaName":430,"dataGaLocation":417},"gitlab duo",{"altText":419,"config":432},{"src":421,"dataGaName":422,"dataGaLocation":417},{"altText":419,"config":434},{"src":425,"dataGaName":422,"dataGaLocation":417},"content:shared:ja-jp:main-navigation.yml","Main Navigation","shared/ja-jp/main-navigation.yml","shared/ja-jp/main-navigation",{"_path":440,"_dir":24,"_draft":6,"_partial":6,"_locale":7,"title":441,"button":442,"config":447,"_id":449,"_type":16,"_source":18,"_file":450,"_stem":451,"_extension":21},"/shared/ja-jp/banner","GitLab Duo Agent Platformがパブリックベータ版で利用可能に！",{"text":443,"config":444},"詳しく見る",{"href":445,"dataGaName":446,"dataGaLocation":30},"/gitlab-duo/agent-platform/","duo banner",{"layout":448},"release","content:shared:ja-jp:banner.yml","shared/ja-jp/banner.yml","shared/ja-jp/banner",{"_path":453,"_dir":24,"_draft":6,"_partial":6,"_locale":7,"data":454,"_id":658,"_type":16,"title":659,"_source":18,"_file":660,"_stem":661,"_extension":21},"/shared/ja-jp/main-footer",{"text":455,"source":456,"edit":462,"contribute":467,"config":472,"items":477,"minimal":650},"GitはSoftware Freedom Conservancyの商標です。当社は「GitLab」をライセンスに基づいて使用しています",{"text":457,"config":458},"ページのソースを表示",{"href":459,"dataGaName":460,"dataGaLocation":461},"https://gitlab.com/gitlab-com/marketing/digital-experience/about-gitlab-com/","page source","footer",{"text":463,"config":464},"このページを編集",{"href":465,"dataGaName":466,"dataGaLocation":461},"https://gitlab.com/gitlab-com/marketing/digital-experience/about-gitlab-com/-/blob/main/content/","web ide",{"text":468,"config":469},"ご協力をお願いします",{"href":470,"dataGaName":471,"dataGaLocation":461},"https://gitlab.com/gitlab-com/marketing/digital-experience/about-gitlab-com/-/blob/main/CONTRIBUTING.md/","please contribute",{"twitter":473,"facebook":474,"youtube":475,"linkedin":476},"https://twitter.com/gitlab","https://www.facebook.com/gitlab","https://www.youtube.com/channel/UCnMGQ8QHMAnVIsI3xJrihhg","https://www.linkedin.com/company/gitlab-com",[478,501,555,588,622],{"title":48,"links":479,"subMenu":484},[480],{"text":481,"config":482},"DevSecOpsプラットフォーム",{"href":57,"dataGaName":483,"dataGaLocation":461},"devsecops platform",[485],{"title":191,"links":486},[487,491,496],{"text":488,"config":489},"プランの表示",{"href":193,"dataGaName":490,"dataGaLocation":461},"view plans",{"text":492,"config":493},"Premiumを選ぶ理由",{"href":494,"dataGaName":495,"dataGaLocation":461},"/ja-jp/pricing/premium/","why premium",{"text":497,"config":498},"Ultimateを選ぶ理由",{"href":499,"dataGaName":500,"dataGaLocation":461},"/ja-jp/pricing/ultimate/","why ultimate",{"title":502,"links":503},"ソリューション",[504,509,512,514,519,524,528,531,534,539,541,543,545,550],{"text":505,"config":506},"デジタルトランスフォーメーション",{"href":507,"dataGaName":508,"dataGaLocation":461},"/ja-jp/topics/digital-transformation/","digital transformation",{"text":137,"config":510},{"href":132,"dataGaName":511,"dataGaLocation":461},"security & compliance",{"text":124,"config":513},{"href":107,"dataGaName":108,"dataGaLocation":461},{"text":515,"config":516},"アジャイル開発",{"href":517,"dataGaName":518,"dataGaLocation":461},"/ja-jp/solutions/agile-delivery/","agile delivery",{"text":520,"config":521},"クラウドトランスフォーメーション",{"href":522,"dataGaName":523,"dataGaLocation":461},"/ja-jp/topics/cloud-native/","cloud transformation",{"text":525,"config":526},"SCM",{"href":121,"dataGaName":527,"dataGaLocation":461},"source code management",{"text":111,"config":529},{"href":113,"dataGaName":530,"dataGaLocation":461},"continuous integration & delivery",{"text":163,"config":532},{"href":165,"dataGaName":533,"dataGaLocation":461},"value stream management",{"text":535,"config":536},"GitOps",{"href":537,"dataGaName":538,"dataGaLocation":461},"/ja-jp/solutions/gitops/","gitops",{"text":176,"config":540},{"href":178,"dataGaName":179,"dataGaLocation":461},{"text":181,"config":542},{"href":183,"dataGaName":184,"dataGaLocation":461},{"text":186,"config":544},{"href":188,"dataGaName":189,"dataGaLocation":461},{"text":546,"config":547},"教育",{"href":548,"dataGaName":549,"dataGaLocation":461},"/ja-jp/solutions/education/","education",{"text":551,"config":552},"金融サービス",{"href":553,"dataGaName":554,"dataGaLocation":461},"/ja-jp/solutions/finance/","financial services",{"title":196,"links":556},[557,559,561,563,566,568,572,574,576,578,580,582,584,586],{"text":208,"config":558},{"href":210,"dataGaName":211,"dataGaLocation":461},{"text":213,"config":560},{"href":215,"dataGaName":216,"dataGaLocation":461},{"text":218,"config":562},{"href":220,"dataGaName":221,"dataGaLocation":461},{"text":223,"config":564},{"href":225,"dataGaName":565,"dataGaLocation":461},"docs",{"text":246,"config":567},{"href":248,"dataGaName":249},{"text":569,"config":570},"お客様の成功事例",{"href":571,"dataGaLocation":461},"/customers/",{"text":241,"config":573},{"href":243,"dataGaName":244,"dataGaLocation":461},{"text":251,"config":575},{"href":253,"dataGaName":254,"dataGaLocation":461},{"text":264,"config":577},{"href":266,"dataGaName":267,"dataGaLocation":461},{"text":256,"config":579},{"href":258,"dataGaName":259,"dataGaLocation":461},{"text":269,"config":581},{"href":271,"dataGaName":272,"dataGaLocation":461},{"text":274,"config":583},{"href":276,"dataGaName":277,"dataGaLocation":461},{"text":279,"config":585},{"href":281,"dataGaName":282,"dataGaLocation":461},{"text":284,"config":587},{"href":286,"dataGaName":287,"dataGaLocation":461},{"title":302,"links":589},[590,592,594,596,598,600,602,606,611,613,615,617],{"text":309,"config":591},{"href":311,"dataGaName":304,"dataGaLocation":461},{"text":314,"config":593},{"href":316,"dataGaName":317,"dataGaLocation":461},{"text":322,"config":595},{"href":324,"dataGaName":325,"dataGaLocation":461},{"text":327,"config":597},{"href":329,"dataGaName":330,"dataGaLocation":461},{"text":332,"config":599},{"href":334,"dataGaName":335,"dataGaLocation":461},{"text":337,"config":601},{"href":339,"dataGaName":340,"dataGaLocation":461},{"text":603,"config":604},"Sustainability",{"href":605,"dataGaName":603,"dataGaLocation":461},"/sustainability/",{"text":607,"config":608},"ダイバーシティ、インクルージョン、ビロンギング（DIB）",{"href":609,"dataGaName":610,"dataGaLocation":461},"/ja-jp/diversity-inclusion-belonging/","Diversity, inclusion and belonging",{"text":342,"config":612},{"href":344,"dataGaName":345,"dataGaLocation":461},{"text":352,"config":614},{"href":354,"dataGaName":355,"dataGaLocation":461},{"text":357,"config":616},{"href":359,"dataGaName":360,"dataGaLocation":461},{"text":618,"config":619},"現代奴隷制の透明性に関する声明",{"href":620,"dataGaName":621,"dataGaLocation":461},"https://handbook.gitlab.com/handbook/legal/modern-slavery-act-transparency-statement/","modern slavery transparency statement",{"title":37,"links":623},[624,626,628,630,635,640,645],{"text":37,"config":625},{"href":39,"dataGaName":40,"dataGaLocation":461},{"text":370,"config":627},{"href":372,"dataGaName":373,"dataGaLocation":461},{"text":375,"config":629},{"href":377,"dataGaName":378,"dataGaLocation":461},{"text":631,"config":632},"ステータス",{"href":633,"dataGaName":634,"dataGaLocation":461},"https://status.gitlab.com/","status",{"text":636,"config":637},"利用規約",{"href":638,"dataGaName":639,"dataGaLocation":461},"/terms/","terms of use",{"text":641,"config":642},"プライバシーに関する声明",{"href":643,"dataGaName":644,"dataGaLocation":461},"/ja-jp/privacy/","privacy statement",{"text":646,"config":647},"Cookieの設定",{"dataGaName":648,"dataGaLocation":461,"id":649,"isOneTrustButton":93},"cookie preferences","ot-sdk-btn",{"items":651},[652,654,656],{"text":636,"config":653},{"href":638,"dataGaName":639,"dataGaLocation":461},{"text":641,"config":655},{"href":643,"dataGaName":644,"dataGaLocation":461},{"text":646,"config":657},{"dataGaName":648,"dataGaLocation":461,"id":649,"isOneTrustButton":93},"content:shared:ja-jp:main-footer.yml","Main Footer","shared/ja-jp/main-footer.yml","shared/ja-jp/main-footer",{"featuredPost":663,"allPosts":691,"totalPages":816,"initialPosts":817},{"_path":664,"_dir":249,"_draft":6,"_partial":6,"_locale":7,"seo":665,"content":673,"config":684,"_id":687,"_type":16,"title":688,"_source":18,"_file":689,"_stem":690,"_extension":21},"/ja-jp/blog/safe-without-silos-in-gitlab",{"title":666,"description":667,"ogTitle":666,"ogDescription":667,"noIndex":6,"ogImage":668,"ogUrl":669,"ogSiteName":670,"ogType":671,"canonicalUrls":669,"schema":672},"GitLabで実現するサイロのないSAFe","Scaled Agile Framework（SAFe）をDevSecOpsプラットフォームのネイティブ機能にマッピングする方法と、そこから得られるメリットについて学びましょう。","https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097569/Blog/Hero%20Images/Blog/Hero%20Images/blog-image-template-1800x945%20%2811%29_2hcwWx49wQ7CHfvhhkVH6S_1750097569126.png","https://about.gitlab.com/blog/safe-without-silos-in-gitlab","https://about.gitlab.com","article","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"GitLabで実現するサイロのないSAFe\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Amanda Rueda\"}],\n        \"datePublished\": \"2025-04-08\",\n      }",{"title":666,"description":667,"authors":674,"heroImage":668,"date":676,"body":677,"category":14,"tags":678},[675],"Amanda Rueda","2025-04-08","あなたの組織がScaled Agile Framework（SAFe）を導入し、エンタープライズ規模へとスケールしようとするとき、何が起こるのか考えてみましょう。複数のチームが複雑な製品の開発に取り組んでおり、すべての作業を調整する手段が必要になります。しかし、ここでよくある問題が発生します。計画はあるツールで行い、実際の開発作業はまったく別の場所で進められているという状況です。\n\nこのような分断は、日常業務においてさまざまな問題を引き起こします。デベロッパーは複数のシステムを行き来し、プロダクトマネージャーは正確な進捗状況を把握できず、誰もが情報を手作業でほかの場所へとコピーすることに時間を浪費します。これこそがまさに、SAFeが解消しようとしている「分断された体験」の典型です。\n\nすでに開発チームがGitLabを使ってソースコード管理、CI/CD、セキュリティを行っている場合、SAFeフレームワークでの計画管理にもGitLabを活用できるのかどうか疑問に思うかもしれません。幸いなことに、GitLabのアジャイルプロジェクト管理機能はSAFeを強力にサポートしています。この記事では、GitLabがSAFeの各種概念やセレモニーとどのように対応しているのかを紹介します。しかも、すべてデベロッパーがすでに慣れ親しんでいる同じDevSecOpsプラットフォーム上で実現できます。\n\n## SAFeとは？\n\nSAFe（Scaled Agile Framework）は、アジャイルの考え方をスピードや方向性、顧客重視の姿勢を失うことなく、大規模な組織全体に広げるための手法です。少人数チームで使われる柔軟かつ反復的なアジャイルの進め方を、複数のチームやロードマップ、関係者を抱える大規模組織にも適用できるように設計されています。このフレームワークを活用することで、組織全体の方向性が揃い、計画と実行が一貫して進むようになります。プロダクトマネージャーにとっては、SAFeを導入することで、戦略と実行をしっかりつなげることができ、とにかく早くリリースするだけでなく、チームで方向性を揃え、優先順位に基づいて本当に出すべきものをリリースできるようになります。\nSAFeはサイロを減らし、チーム間のコラボレーションを促進するとともに、単なる作業の実行ではなく、「顧客が求める成果」を中心にチームをまとめます。GitLabにSAFeを統合すると、可視性、トレーサビリティ、成果のすべてが、1か所に集約され、その効果はさらに高まります。\n\n## GitLabにおけるSAFeの用語対応\n\nまず、SAFeの概念がGitLab内でどのように対応するかを確認しましょう。\n\n| SAFe | GitLab |\n| :---- | :---- |\n| Epic | トップレベルエピック |\n| Capability | サブエピック（レベル1） |\n| Feature | サブエピック（レベル2） |\n| User Story | イシュー |\n| Task | タスク |\n| Team | カスタムフィールド/範囲指定したラベル |\n| Sprint | イテレーション |\n| Program Increment (PI) | マイルストーン |\n| Value Stream | トップレベルグループ |\n| Agile Release Train (ART) | トップレベルグループ |\n\n\u003Cbr>\u003C/br>\n\nこの対応表をガイドとして活用すると、GitLabをSAFeの実装と連動させて構築できます。グループ構造を使うと、バリューストリームやART（Agile Release Train）単位で整理できます。また、最大7階層までネスト可能なエピックによる作業アイテムの階層構造により、複雑なプロダクトポートフォリオにも対応できる深さを備えています。ポートフォリオレベル（トップレベルグループ）、プログラムレベル（サブグループ）、チームレベル（プロジェクト）といった、どの階層で作業していても、GitLabの組織構造はSAFeの階層とぴったり合致します。\n\n## GitLabでのSAFeのセレモニーのサポート\n\nここからが本題です。GitLab上でSAFeのセレモニーを実際にどう実行するのか、順を追って見ていきましょう。\n\n### PIプランニング\n\nチーム間の調整と依存関係の管理を促進し、PIプランニングを成功させるために、GitLabでは以下のような機能が提供されています。\n\n* [ロードマップ](https://docs.gitlab.com/user/group/roadmap/)ビューを使用して、複数のチームや期間にわたるフィーチャーを可視化する\n* フィーチャーをPI[マイルストーン](https://docs.gitlab.com/user/project/milestones/)に割り当てる\n* 見つかったチーム間の[依存関係](https://docs.gitlab.com/user/project/issues/related_issues/#blocking-issues)を文書化し、視覚化する\n\nGitLabでは、エピックボード（チームごとの割り当てを表示するように設定可能）とロードマップビュー（ガントチャートのように時間軸でフィーチャーを表示）を使い分けることで、柔軟にPIプランニングを進めることができます。タイムラインかチーム構成のどちらに注目するかに応じて、プランニング中にビューを切り替えられます。\n\n![ロードマップビューとエピックボード](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097577/Blog/Content%20Images/Blog/Content%20Images/image3_aHR0cHM6_1750097576746.gif)\n\n\u003Cbr>\u003C/br>\n\n![ガントチャート付きロードマップビュー](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097577/Blog/Content%20Images/Blog/Content%20Images/image5_aHR0cHM6_1750097576747.png)\n\n### リファインメント\n\nプロダクトマネージャーにとって、効果的なリファインメントを行うには、フィーチャーのバックログを明確に把握しておくことが重要です。GitLabなら、リファインメントをそのままGitLab上で実施できます。会議中に1つのツールを更新して、その後に別のツールを更新する必要はもうありません。 \n\nGitLabでは、以下の機能によってリファインメントを効率的に進められます。\n\n* 状態ごとにフィーチャーを整理できる[エピックボード](https://docs.gitlab.com/user/group/epics/epic_boards/)\n* ストーリーポイントを[概要](https://docs.gitlab.com/user/group/epics/epic_boards/#view-count-of-issues-weight-and-progress-of-an-epic)ビューで直接確認できる機能\n* 作業アイテムをその場で操作しながら、全体の文脈を見失わない包括的な[drawerビュー](https://docs.gitlab.com/user/group/epics/manage_epics/#open-epics-in-a-drawer)\n* エピックから[子イシュー](https://docs.gitlab.com/user/group/epics/manage_epics/#add-an-issue-to-an-epic)を直接作成・リンクできる機能 \n\n![SAFe - 画像3](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097577/Blog/Content%20Images/Blog/Content%20Images/image2_aHR0cHM6_1750097576749.gif)\n\n### スプリント計画\n\n次のスプリントでチームが取り組む作業を決めるタイミングでは、GitLabの以下の機能を活用できます。\n\n* バックログを包括的に確認できる[イシューボード](https://docs.gitlab.com/user/project/issue_board/)\n* ボード上にユーザーストーリーの[合計ウェイト](https://docs.gitlab.com/user/project/issue_board/#sum-of-issue-weights)を直接表示\n* イシューを簡単にイテレーション間で移動できる機能\n* スプリント間のストーリー移動を効率化する折りたたみ可能なビュー\n\nつまり、すべてを1か所に集約して管理でき、プランニングミーティングではツールを行き来するのではなく、実際の計画に集中できます。\n\n![GitLabで行うスプリント計画](https://res.cloudinary.com/about-gitlab-com/image/upload/v1752378662/Blog/ynmq3wnf77yk6xkehkda.gif )\n\n* GitLabを活用したスクラムの進め方については、[こちら](https://docs.gitlab.com/tutorials/scrum_events/)のチュートリアルをご覧ください。アジャイルプランニングやスプリントの進捗管理におけるGitLabの便利な機能を詳しく確認できます。*\n\n### デイリースタンドアップ\n\nデイリースタンドアップでは、チーム全員がボードを囲んで、誰が何に取り組んでいるか、どこで詰まっているか、どの作業がレビュー待ちかを、すべて単一のビューで確認できます。GitLabでは、以下の機能が開発チームのデイリースタンドアップに役立ちます。\n\n* 現在のスプリントに絞った[イテレーションスコープ付き](https://docs.gitlab.com/user/project/issue_board/#iteration-lists)のボードを作成\n* 各カード上にストーリーポイント/ウェイトを直接表示\n* コンテキストを失わずに詳細にアクセスできる[drawerビュー](https://docs.gitlab.com/user/project/issues/managing_issues/#open-issues-in-a-drawer)の活用\n* [ヘルスステータス](https://docs.gitlab.com/user/project/issues/managing_issues/#health-status)でリスクのあるタスクをハイライト表示\n\n![デイリースタンドアップのボード](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097577/Blog/Content%20Images/Blog/Content%20Images/image4_aHR0cHM6_1750097576751.gif)\n\n### スプリントレビュー\n\nチームの進捗状況を継続的に把握したいですか？GitLabでは、以下のような包括的なメトリクスを利用できます。\n\n* イテレーションごとの[バーンダウンチャートおよびバーンアップチャート](https://docs.gitlab.com/user/group/iterations/#iteration-burndown-and-burnup-charts)\n* ベロシティのトラッキング\n* [リードタイムおよびサイクルタイム](https://docs.gitlab.com/user/group/value_stream_analytics/#lifecycle-metrics)のメトリクス\n* チーム単位でスコープ設定できるダッシュボード\n\nこれらの指標により、チームのスピードが上がっているか、どこでつまずいているか、そして次回のレトロスペクティブで話し合うべきポイントを明確に把握できます。\n\n![バーンダウンチャートとバーンアップチャート](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097577/Blog/Content%20Images/Blog/Content%20Images/image6_aHR0cHM6_1750097576755.png)\n\n## 統合プラットフォームが強みとなる5つの理由\n\nSAFeのセレモニーを管理できる計画ツールはたくさんあります。でも、GitLabが本当に他と違うと私が感じているのには、明確な理由があります。\n\n1. **頭の切り替えが不要** - 計画、コーディング、テスト、セキュリティのすべてを、1か所で完結できます。\n2. **すべてがつながっている** - 大きなエピックからコード、デプロイまで、作業の流れをたどれます。\n3. **全員が同じ認識を持てる** - デベロッパー、プロダクト担当、セキュリティチームが、同じツール上で連携できます。\n4. **完全な可視性** - ステークホルダーは、進捗の確認を1か所で行えます。\n5. **全体像が見える** - 計画と開発のメトリクスをまとめて確認できるため、本当の状況が明確になります。\n\nもしあなたの開発チームがすでにGitLabを使いこなしているなら、プランニングのためだけに別のツールへ切り替えたり、複雑なインテグレーションを無理やり組み合わせたりする必要はありません。SAFeプランニングをGitLabに取り込むことで、チーム全体にとってはるかにスムーズな体験が得られます。\n\n## 実装の原則\n\n私は従来型のSAFeツールからGitLabへの移行に取り組むチームと協力してきましたが、その経験から学んだことがあります。それは、以前のツールをそのまま再現しようとするのではなく、**それぞれのセレモニーが何を目的としているか**に注目することが重要だということです。\n\nGitLabの利点を最大限に活用しているのは、GitLabのネイティブ機能を素直に受け入れて、それに逆らわずに活用しているチームです。もちろん、SAFeの概念をどうマッピングするか、ワークフローをどう構築するかを最初に整理するには少し手間がかかります。しかし、一度その形ができてしまえば、プロセスは複雑になるどころか、むしろシンプルになります。\n\n成功のカギは、全員が従うべき規則を定義することです。どのラベルが何を意味するのか？ チームをどう追跡するのか？エピックとイシューにはそれぞれ何を入れるのか？こうした判断を事前に少し整理しておくだけで、複数ツール間の調整にかかっていた手間を解消できる、直感的なシステムが手に入ります。\n\n## 導入を始める\n\nさて、試してみる準備はできましたか？GitLabでSAFeを導入するためのステップは以下のとおりです。\n\n1. **構造を整える** - [組織構成](https://about.gitlab.com/ja-jp/blog/best-practices-to-set-up-organizational-hierarchies-that-scale/)に合わせて、グループやサブグループを作成します。\n2. **作業の詳細を定義する** - [エピック](https://about.gitlab.com/ja-jp/blog/best-practices-to-set-up-organizational-hierarchies-that-scale/)、[イシュー](https://docs.gitlab.com/user/project/issues/managing_issues/)、[タスク](https://docs.gitlab.com/user/tasks/)をどのように使い分けるかを定義します。\n3. **イテレーションを作成する** - [スプリントのスケジュール](https://docs.gitlab.com/user/group/iterations/#create-an-iteration-cadence)を設定します。\n4. **マイルストーンを追加** - GitLab上でプログラムインクリメント（PI）を表す[マイルストーン](https://docs.gitlab.com/user/project/milestones/#create-a-milestone)を作成します。 \n5. **ボードを構築する** - セレモニーごとに異なるビューを用意します。\n6. **規則について合意する** - ラベルやカスタムフィールドの使い方を文書化し、チームで統一します。\n\nこれらのポイントを最初にしっかり考えておくことで、後々のトラブルや混乱を避けられます。そして、初日から完璧にする必要はないことを忘れないでください。運用しながら学び、必要に応じていつでも調整できます。\n\n## すべてをまとめる\n\nGitLabは、SAFeを実行するための堅実な基盤を提供します。特に、あなたの開発チームがすでにGitLabに慣れ親しんでいる場合には最適です。計画と開発を同じツール上で進めることで、煩雑なハンドオフが不要になり、コラボレーションが格段にしやすくなり、すべての動きがよりスピーディになります。\n\nGitLabのプランニングツールの魅力は、あなたのチームに合わせて柔軟にSAFeをカスタマイズできることです。 決められた型にはまる必要はありません。チームが成熟し、ニーズが変われば、それに応じて運用方法も進化させることができます。\n\n> サイロ化したプランニングにさよならして、もっと快適なワークフローを体験してみませんか？まずは[無料トライアルを開始](https://about.gitlab.com/ja-jp/free-trial/?hosted=saas)して、GitLabがどのようにSAFe導入を変革できるかを実感してください。\n\n*💡 このトピックに興味を持った方は、関連記事の[アジャイルソフトウェア開発におけるGitLabの活用法](https://about.gitlab.com/ja-jp/blog/gitlab-for-agile-software-development/)もぜひご覧ください*\n",[679,680,681,682,683],"agile","DevSecOps platform","features","product","tutorial",{"slug":685,"featured":93,"template":686},"safe-without-silos-in-gitlab","BlogPost","content:ja-jp:blog:safe-without-silos-in-gitlab.yml","Safe Without Silos In Gitlab","ja-jp/blog/safe-without-silos-in-gitlab.yml","ja-jp/blog/safe-without-silos-in-gitlab",[692,713,733,754,774,794],{"_path":693,"_dir":249,"_draft":6,"_partial":6,"_locale":7,"seo":694,"content":700,"config":707,"_id":709,"_type":16,"title":710,"_source":18,"_file":711,"_stem":712,"_extension":21},"/ja-jp/blog/how-to-harmonize-agile-sprints-with-product-roadmaps",{"title":695,"description":696,"ogTitle":695,"ogDescription":696,"noIndex":6,"ogImage":697,"ogUrl":698,"ogSiteName":670,"ogType":671,"canonicalUrls":698,"schema":699},"アジャイルのスプリントを製品ロードマップと調和させる方法","ベストプラクティスとGitLabの機能を活用して、製品開発を進めましょう。一元化されたロードマップの作成、レビューセッションの実施、スプリントのライフサイクルの追跡など、製品開発をスムーズに進めるためのポイントを解説します。","https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097231/Blog/Hero%20Images/Blog/Hero%20Images/blog-image-template-1800x945%20%2821%29_2pdp2MNB7SoP4MhhiI1WIa_1750097230664.png","https://about.gitlab.com/blog/how-to-harmonize-agile-sprints-with-product-roadmaps","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"アジャイルのスプリントを製品ロードマップと調和させる方法\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Amanda Rueda\"}],\n        \"datePublished\": \"2025-02-04\",\n      }",{"title":695,"description":696,"authors":701,"heroImage":697,"date":702,"body":703,"category":14,"tags":704,"updatedDate":706},[675],"2025-02-04","製品チームと開発チームが協力せずに、それぞれ作業している様子を想像してみてください。たとえば、製品チームが12か月分のロードマップを作成して社内に共有したものの、開発チームのレビューは受けてなかったとします。このため、開発チームは、全体の計画を把握しないまま、次のスプリントで予定されている機能の開発を始めました。その影響で、プロジェクトの並行実施、チームキャパシティの考慮、再利用可能なAPIの構築など、本来なら最適なタイミングで進められたはずの機会を逃してしまいます。最終的に、非効率的になり、価値の提供も遅れてしまいます。\n短期的な成功と長期的なビジョンのバランスを取るのは簡単ではありません。明確なコミュニケーション、優先事項の調整、そして適切なツールが必要です。このガイドでは、アジャイルのスプリントを戦略的ロードマップと調和させる方法、よくある課題への取り組み方、チームに合わせた実践的なアプローチをご紹介します。\n\n## 信頼できる唯一の情報源の重要性\n\n長期的目標を含むロードマップに関する、信頼できる一貫した唯一の情報源があれば、チームは常に最新の全体像にアクセスできます。具体的には、ロードマップの情報をひとつのプラットフォームに集約し、定期的に更新することを意味します。逆に、一元化されていない、つまり微妙に差があるロードマップを複数管理する場合、方向性の理解にずれが生じてしまいます。\n\n### 一元化されたロードマップを作成する\n\n一元化されたロードマップを作成することで、次のことが可能になります。\n\n* 長期的な戦略を伝える\n* 伝達ミスを最小限に抑える\n* 部門間の足並みが揃いやすくなる\n* 背景を把握しながら、変化に素早く対応する\n* 情報を自分で取得でき、情報を保持する単一の窓口への依存度を減らす\n\n***GitLabに関するヒント**：[エピック](https://docs.gitlab.com/ee/user/group/epics/)と[ロードマップ表示](https://docs.gitlab.com/ee/user/group/roadmap/)を使用すれば、製品計画と進捗の透明性を確保できます。ロードマップ表示を使用すると、進捗の追跡やボトルネックの特定に加え、全体的な目標とスプリントレベルでの実施内容を確実に一致させることができます。* \n\n![グループのロードマップ表示](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097239/Blog/Content%20Images/Blog/Content%20Images/image1_aHR0cHM6_1750097239117.png)\n\n## ロードマップの共同レビューの実施\n\n[プロダクトトリオ](https://www.producttalk.org/product-trio/)（製品チーム、エンジニアリングチーム、ユーザーエクスペリエンスチーム）は連携し、定期的なロードマップのレビューと合意を得る仕組みを作りましょう。共同レビューを行うことで、チーム間の認識が揃い、リスクの早期発見と対処につながります。GitLabのプロダクトマネージャーは、エンジニアリングマネージャー、UXデザイナーと毎月ミーティングを行い、変更内容をレビューしてもらった上で、承認を得ています。Wikiに承認の記録を残しておくことで、スケジュールへの責任を明確にし、社内の他のメンバーに対してオープンに情報を提供しています。\n\n#### レビューセッションの効果を高める方法\n\nレビューの場を有意義なものにするには、以下のベストプラクティスを意識しましょう。\n\n* ロードマップの変更頻度に応じて、月ごとまたは四半期ごとの定期的なレビューを設定する。\n\n* 潜在的なリスクや依存関係をあらかじめ議論することで、製品目標、UXのリードタイム、技術的実現可能性の間の整合性を検証する。\n\n  * ロードマップに組織のビジネス目標が反映されているかどうかを検証する。\n  * 設計のタイムラインが現実的であり、技術的な調査や検証の必要性が考慮されていることを確認する。\n\n* チームのキャパシティの制約を考慮し、作業順序をチームのスキルプロファイルに合うよう工夫して、チームの生産性を最適化する：\nこれには、休暇期間中のスタッフ減少といった状況を見越して計画を立てながら、チームの能力の活用不足やスキルのミスマッチを避けることも含まれます。\n\n* スコープを正しく設定し、何が達成できるかについて適切な期待値を設定する：\n「全部やりたい」という気持ちを抑え、何を優先すべきかを明確にし、段階的に価値を提供するよう心がけることが大切です。タスク間の依存関係を減らしたり、再利用可能なコンポーネントを活用するなど、イテレーションの改善や開発速度を上げる方法を特定して、最適化できる機会を模索します。\n\n* トレードオフや優先順位についてオープンに話し合い、多角的な視点を取り入れる：\nこのような協調的なアプローチを取ることで課題に対して新しい視点や発想を取り入れた解決策が見つかり、今後の方向性について合意を得やすくなります。\n\n***GitLabに関するヒント**：[GitLab Wiki](https://docs.gitlab.com/ee/user/project/wiki/)を活用して[ロードマップ](https://docs.gitlab.com/ee/user/group/roadmap/)機能を補完しましょう。Wikiには、ビジネス上の根拠、ユーザー調査へのリンク、RICEスコア、依存関係やリスクに関する詳細など、製品ロードマップに関する幅広いコンテキストを記載できます。アクセスしやすいようにロードマップへの直リンクを記載し、今後のディスカッションスレッド機能を活用して、非同期コラボレーションを促進し、チームからのフィードバックを得られるようにしましょう。*\n\n![PlanFlow製品のロードマップ](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097239/Blog/Content%20Images/Blog/Content%20Images/image3_aHR0cHM6_1750097239118.png)\n\n## 継続的な方向性の検証と進捗測定\n\n製品ロードマップを作成する目的は、予定どおりに進めることだけでなく、顧客に真の価値を提供することです。ユーザーからの継続的なフィードバックや行動データを共有する機会を設けるために、スプリントのサイクルとは別に、定期的にプロダクトトリオの三者で集まる場を設けることを検討してください。このようなセッションでは、インサイトの確認やトレンドの分析、そしてユーザーの変化し続けるニーズが製品ロードマップに反映されていることを確認します。実際のユーザーから得たインサイトに基づき、ロードマップを更新することで、単に予定していた機能をリリースするだけでなく、顧客にとって本当に重要な価値を提供できます。\n顧客にとっての価値は、使いやすさの向上、技術的負債の削減、またはまったく新しい機能の提供など、さまざまです。プロダクトトリオがロードマップのビジョンで一致していれば、達成しようと目指している成果に関しても足並みが揃っている状態だと言えます。\n成果の達成に向け順調かどうかを測定するには、想定する成果がどのようなものであるかを明確に定義する必要があります。後からユーザーストーリーを追加するといったスコープクリープ（スコープの拡大）は、価値の提供を遅らせてしまう恐れがあります。さらに、ロードマップに沿っていない作業があれば、価値を提供した後であっても特定し、なぜそうなったのか理由を把握することも重要です。\n\n### スプリント計画\n\n製品ロードマップとの整合性を保つには、まずは綿密なスプリント計画を立てる必要があります。ここでは、チームが作業を順調に進め、価値の提供に重点的に取り組むために役立つベストプラクティスをいくつかご紹介します。\n\n- デリバリーに対して確信を持てるように、求める成果を明確に定義し、範囲を絞り込んで設定する。\n- デリバリーを遅らせる可能性のある遅めの段階での追加や調整を特定し、継続して注力できるようにバッファを設ける。\n- チームと作業順序を調整し、キャパシティやスキルプロファイルを最適化し、依存関係を減らす。\n- 集中力を維持し、納期遵守の確実性を高めるために、チームのキャパシティが一杯になるような計画はしないようにする。スプリント中に発生する可能性のある未知の問題や新たな発見に備えて、バッファ（10%～20%）を設けておきましょう。\n\n### スプリント期間中\n\nスプリント期間中にロードマップとの整合性を保ち続けるには、集中力とコミュニケーションに加え、継続的な評価が必要です。価値の提供が目標である一方で、進行中の作業が、事前に決めて計画した成果に沿っているかどうかを確認することも同様に重要です。\n\n- 進行中の作業をロードマップで定めた成果と照らし合わせて継続的に検証し、各スプリントが全体像に寄与しているかを確認する。\n- 想定している目標や成果に向けて引き続き取り組んでいるかどうか、定期的に確認するようチームに促す。\n- スプリントを通じてオープンなコミュニケーションを保つ：デイリースタンドアップミーティングや非同期なアップデートを用いて、リスクや予定外の作業、依存関係を早い段階で明らかにし、必要に応じて調整します。\n- 何が何でもスプリントに沿って行動する：新たに生じた問題を解決したいという衝動に駆られるのは当然ですが、事前に合意した優先順位を見失うことのないように、計画していなかった作業は慎重に見極める必要があります。\n- スコープクリープを主体的に管理する：スプリントの途中で新たな作業が出てきた場合、それが現在のロードマップで定めた注力対象にあっているかを確認しましょう。たとえ魅力的なアイデアや機能であっても、。直近の価値提供という観点では優先度が低いかもしれません。このような内容は文書化し、今後のイテレーションに含めるか、あとで検討する項目として整理しましょう。現在のスプリントで取り組むものとした優先事項を後回しにするのは避けるべきです。\n\n### スプリントレトロスペクティブ（ふりかえり）\n\nスプリントレトロスペクティブでは、チームが目指す成果にどれだけ近づけたかを「ふりかえる」時間を取りましょう。以下の質問を投げかけることをおすすめします。\n\n- スプリント期間中に、予定外の作業によって価値の提供が遅れたことはなかったか？その原因は何だったか？どのように対応すればよかったか？\n- ロードマップとずれた作業がなかったか。その背景や経緯は？今後にどう活かせるか？そこから学んだことを話し合いましょう。\n\nスプリント計画からスプリントレトロスペクティブまで、ユーザーと関係者に具体的な成果をもたらすことチームの重要な役割です。各ステップで足並みを揃えることで、ロードマップが価値を効率的かつ継続的に提供する道標になります。\n\n***GitLabに関するヒント**：[バーンダウンチャート](https://docs.gitlab.com/ee/user/project/milestones/burndown_and_burnup_charts.html)を使用すると、進捗状況が可視化され、早い段階でロードマップからの逸脱が検知できるため、チームが成果の達成に集中しやすくなります。*\n\n![バーンダウンチャート](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097239/Blog/Content%20Images/Blog/Content%20Images/image2_aHR0cHM6_1750097239120.png)\n\n## ロードマップで定めた成果を確実に実現する\n\nアジャイルのスプリントと戦略的なロードマップを結びつけるには、意図的な取り組み、チームの賛同、そして適切なツールが必要です。信頼できる唯一の情報源としてロードマップを作成し、共同レビューを実施し、進捗状況を測定することで、ビジョンに沿った行動を取ることができます。GitLabの強力な計画機能を活用することで、チームは課題をイノベーションと成長の機会へと変えることができます。\n\n早速、戦略的ロードマップに合わせてスプリントを進めてみませんか？[GitLabの無料トライアルを開始](https://about.gitlab.com/ja-jp/free-trial/)して、確実に成果を実現するために役立つツールを試してみましょう。\n\n## 関連リンク\n\n* [アジャイルプランニングのコンテンツハブ](https://about.gitlab.com/ja-jp/blog/categories/agile-planning/)  \n* [アジャイルプランニングチームに特化したGitLabの新しい「プランナーロール」のご紹介](https://about.gitlab.com/ja-jp/blog/introducing-gitlabs-new-planner-role-for-agile-planning-teams/)」（日本語）  \n* [効果的なナレッジマネジメントの実施に役立つGitLab Wikiのご紹介](https://about.gitlab.com/blog/get-to-know-the-gitlab-wiki-for-effective-knowledge-management/)（英語）\n\n\u003Cbr>\u003Cbr>\n\n*監修：佐々木 直晴 [@naosasaki](https://gitlab.com/naosasaki) （GitLab合同会社 ソリューションアーキテクト本部 シニアソリューションアーキテクト）*",[679,683,705,680],"workflow","2025-06-04",{"slug":708,"featured":93,"template":686},"how-to-harmonize-agile-sprints-with-product-roadmaps","content:ja-jp:blog:how-to-harmonize-agile-sprints-with-product-roadmaps.yml","How To Harmonize Agile Sprints With Product Roadmaps","ja-jp/blog/how-to-harmonize-agile-sprints-with-product-roadmaps.yml","ja-jp/blog/how-to-harmonize-agile-sprints-with-product-roadmaps",{"_path":714,"_dir":249,"_draft":6,"_partial":6,"_locale":7,"seo":715,"content":721,"config":727,"_id":729,"_type":16,"title":730,"_source":18,"_file":731,"_stem":732,"_extension":21},"/ja-jp/blog/introducing-gitlabs-new-planner-role-for-agile-planning-teams",{"title":716,"description":717,"ogTitle":716,"ogDescription":717,"noIndex":6,"ogImage":718,"ogUrl":719,"ogSiteName":670,"ogType":671,"canonicalUrls":719,"schema":720},"アジャイルプランニングチームに特化したGitLabの新しい「プランナー」ロールのご紹介","GitLabの新しい「プランナー」ロールを活用して、SaaS、GitLab Dedicated、Self-Managedといった各ソリューションでのアクセス権を最適化し、アジャイルチームの計画ワークフローを効率的に管理する方法についてご説明します。","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749662488/Blog/Hero%20Images/blog-image-template-1800x945__3_.png","https://about.gitlab.com/blog/introducing-gitlabs-new-planner-role-for-agile-planning-teams","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"アジャイルプランニングチームに特化したGitLabの新しい「プランナー」ロールのご紹介\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Amanda Rueda\"}],\n        \"datePublished\": \"2024-11-25\",\n      }",{"title":716,"description":717,"authors":722,"heroImage":718,"date":723,"body":724,"category":14,"tags":725,"updatedDate":726},[675],"2024-11-25","GitLabは、DevSecOpsプラットフォームに新たなロール「プランナー」を導入しました。以前リリースされた[カスタムロール機能と同様に](https://docs.gitlab.com/ee/user/custom_roles.html)、「役割に応じた柔軟なアクセス制御を実現する」というGitLabの戦略に基づいて開発されました。このロールは、ソフトウェア開発チームや計画に携わるユーザーに対し、過剰な権限を付与することなく、アジャイル開発のワークフローを管理するために必要なツールへのアクセス権を提供します。これにより、過剰な権限付与によるセキュリティリスクの増加を防止できます。プランナーロールを活用してユーザーごとの特定のニーズに合わせてアクセスを調整することで、チームは生産性を維持しつつ、セキュリティとコンプライアンスを確保し、[最小権限の原則](https://about.gitlab.com/blog/the-ultimate-guide-to-least-privilege-access-with-gitlab/)を遵守できます。\n\n## プランナーロールが開発された理由\n\nこの新しいロールの開発は、お客様や社内チームからのフィードバックをきっかけに始まりました。GitLabはアジャイル開発サイクルを計画および管理するための包括的なツールを提供していますが、役割に基づくより具体的なアクセス制御が必要だという声が度々寄せられていました。プロダクトマネージャーやプロジェクトリード、その他の計画業務を担当する役割は、計画機能へのアクセスは必要ですが、開発全体の権限は必要ありません。実際、必要以上のアクセス権は、セキュリティリスクだけでなく、コードや重要な設定に意図しない変更を加える可能性も高めるため、好ましくありません。このようなフィードバックを受け、GitLabは対応を進めました。\n\nユーザーへの聞き取り、競合分析、そして徹底的な調査を通じて、新しいロールの必要性が明確になりました。計画ツールへの十分なアクセスを提供しつつ、デベロッパー向けの機能へのアクセスを制限することでセキュリティを確保するロールが求められていました。\n\n## プランナーロールの特徴\n\nプランナーロールは、既存の[ゲストロールとレポーターロール](https://docs.gitlab.com/ee/user/permissions.html#roles)を組み合わせたハイブリッドロールであり、計画ワークフローへのアクセスが必要なユーザー向けに特化して設計されています。\n\nこのロールを使用すると、以下のことを行えます。\n\n* 主要な計画ツール（エピック、ロードマップ、イシューボード、[OKR](https://docs.gitlab.com/ee/user/okrs.html)など）へのアクセスを許可する（*一部の機能はGitLab PremiumまたはGitLab Ultimateのライセンスが必要です*）\n* 機密性の高い開発関連の機能への不要なアクセスを制限することで、セキュリティを強化する\n* プランナーロールをGitLab Enterprise Agile Planningアドオンと併用することで、チームに計画ツールへのカスタマイズされたアクセスを提供しつつ、セキュリティと制御を維持する（*プランナーロール単体はすべてのライセンスプランで利用可能です*）\n\nプランナーロールは、SaaS、GitLab Dedicated、Self-Managedを含むすべてのGitLabソリューションで利用可能となっており、すべてのお客様がこのカスタマイズされたアクセス制御のメリットを活用できます。\n\nこのロールを使用することで、チームは職務に応じて権限を柔軟に調整でき、アクセス性とセキュリティのバランスを確保できます。\n\n## アジャイル手法の実践を後押しするプランナーロールの役割\n\n[アジャイルソフトウェア開発](https://about.gitlab.com/ja-jp/blog/categories/agile-planning/)において、各チームメンバーにそれぞれの役割に即したツールと権限を与えることは、ワークフローを効率化する上で非常に重要です。プランナーロールは、計画チームのメンバーが開発やデプロイといった領域に踏み込み過ぎるリスクを排除しつつ、ソフトウェア開発ライフサイクルの計画段階に適切に参加できるようにすることで、アジャイル開発をサポートします。\n\nプランナーロールは、エピックの作成・管理からロードマップの定義まで、アジャイルチームが連携を保ちながら効率的に業務を進めるために必要なツールを提供します。\n\n## お客様中心の設計\nこのロールは、GitLabが単独で作り上げたものではありません。プロセスのすべての段階でコミュニティの意見を取り入れてきました。具体的には、アンケート調査、インタビュー、テストを通じて、プロダクトマネージャーやプロジェクトマネージャーの実務上のニーズに合致するよう、権限を細かく調整しました。\n\nまた、このロールには「エンタープライズアジャイルチーム向けのプラットフォームを提供する」というGitLabの長年の使命が反映されており、企業がアジャイル開発手法を大規模に導入する上で必要な柔軟性と制御性を提供します。\n\n## コミュニティのフィードバックとエンゲージメント\n\nGitLabでは、皆様からのご意見を大変重視しており、新しいプランナーロールに関するご感想をぜひお聞かせいただきたいと考えています。皆様からのフィードバックは、GitLabの利用体験の改良・改善に欠かせません。ご意見やご提案がありましたら、ぜひ[フィードバック用イシュー](https://gitlab.com/gitlab-org/gitlab/-/issues/503817)からお寄せください。\n\n## 今すぐGitLabで計画を始めましょう！\n\nGitLabは、ソフトウェア開発チームの効果的な計画、コラボレーション、デリバリーをさまざまなアプローチを通じて支援しており、プランナーロールはそのうちの一つにすぎません。GitLabは、製品管理ワークフローの効率化、チームコラボレーションの強化、アジャイル手法の整備など、あらゆる目的の達成を支援する充実したツールを取り揃えています。\n\n> GitLabのすべての機能をお試しになりたい場合は、ぜひ[GitLab Ultimateの60日間無料トライアルにご登録](https://about.gitlab.com/ja-jp/free-trial/)ください。チーム独自のニーズに合わせてカスタマイズされたプランナーロールを活用して、次のプロジェクトの計画を始めましょう。\n\n## その他の記事\n- [開発チームだけでなく、あらゆる職務に対応可能なGitLab Enterprise Agile Planningアドオン（英語）](https://about.gitlab.com/blog/gitlab-enterprise-agile-planning-add-on-for-all-roles/)\n- [GitLabをアジャイルソフトウェア開発で使用する方法](https://about.gitlab.com/ja-jp/blog/gitlab-for-agile-software-development/)\n- [初公開：新しくなったGitLabのアジャイル計画（英語）](https://about.gitlab.com/blog/first-look-the-new-agile-planning-experience-in-gitlab/)\n\n\u003Cbr>\n\u003Cbr>\n\n*監修：ソリス ジェレズ / Jerez Solis [@jerezs](https://gitlab.com/jerezs)\u003Cbr>\n（GitLab合同会社 ソリューションアーキテクト本部 ソリューションアーキテクト）*\n",[679,680,681,682],"2025-05-01",{"slug":728,"featured":93,"template":686},"introducing-gitlabs-new-planner-role-for-agile-planning-teams","content:ja-jp:blog:introducing-gitlabs-new-planner-role-for-agile-planning-teams.yml","Introducing Gitlabs New Planner Role For Agile Planning Teams","ja-jp/blog/introducing-gitlabs-new-planner-role-for-agile-planning-teams.yml","ja-jp/blog/introducing-gitlabs-new-planner-role-for-agile-planning-teams",{"_path":734,"_dir":249,"_draft":6,"_partial":6,"_locale":7,"seo":735,"content":741,"config":748,"_id":750,"_type":16,"title":751,"_source":18,"_file":752,"_stem":753,"_extension":21},"/ja-jp/blog/seamlessly-migrate-from-jira-to-gitlab-with-jira2lab-at-scale",{"title":736,"description":737,"ogTitle":736,"ogDescription":737,"noIndex":6,"ogImage":738,"ogUrl":739,"ogSiteName":670,"ogType":671,"canonicalUrls":739,"schema":740},"Jira2Labを使用してJiraからGitLabへの大規模な移行をシームレスに実現","複雑なデータ移行の処理、スケーラビリティの向上、効率的な統合を保証するJira2GitLabを使用することで、JiraからGitLabへの大規模な移行がどのように簡素化されるかをご紹介します。","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749663129/Blog/Hero%20Images/blog-image-template-1800x945__28_.png","https://about.gitlab.com/blog/seamlessly-migrate-from-jira-to-gitlab-with-jira2lab-at-scale","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"Jira2Labを使用してJiraからGitLabへの大規模な移行をシームレスに実現\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Maximilien Belinga\"}],\n        \"datePublished\": \"2024-10-10\",\n      }",{"title":736,"description":737,"authors":742,"heroImage":738,"date":744,"body":745,"category":14,"tags":746},[743],"Maximilien Belinga","2024-10-10","[2月にAtlassianサーバーのサポートが終了した](https://about.gitlab.com/ja-jp/move-to-gitlab-from-atlassian/)ことで、多くのユーザーがAtlassian CloudやAtlassian Data Centerのような代替製品を検討する必要に迫られています。その一方、Atlassianサーバーを使用している企業の間では、より柔軟でコスト効率に優れ、DevSecOpsの堅牢な統合を実現できるアジャイル計画ソリューションを求める動きが広がっています。こうした企業は、移行中にデータ量、カスタマイズ、ユーザーマッピング、パフォーマンス、データ整合性に関する課題にも取り組む必要があります。そこで役に立つのが、[GitLabのJira2Lab](https://gitlab.com/gitlab-org/professional-services-automation/tools/migration/jira2lab)です。Jira2Labは、CI/CDを完全に統合し、JiraからGitLabへの大規模な移行を実現するシームレスなソリューションを提供します。\n\n## 大規模なJiraの移行時に発生する問題\n\nJiraからGitLabへの移行は、特に複雑なワークフローや何千ものイシューを抱える企業では、非常に大変な作業となる場合があります。移行時に発生する最も一般的な課題は次のとおりです。\n\n- **大規模なデータ移行**：イシューや添付ファイル、コメント、プロジェクト数が多ければ多いほど、パフォーマンスの問題やデータ損失を生じさせずに、それらを移行するのは難しくなります。\n\n- **カスタムフィールドとワークフロー**：Jiraインスタンスには、GitLabにそのままではマッピングされないカスタムワークフローやフィールド、イシュータイプが含まれていることがよくあります。このようなギャップがあると、既存のツールではこれらの要素を変換するために手作業が必要となることが多いため、移行時に手間やストレスが生じます。\n\n- **包括的なDevSecOps機能の統合の欠如**：多くの移行ツールではプロジェクト管理データを処理できるものの、GitLabで提供されている包括的なDevSecOps機能は含まれていません。そのため、移行後に[CI/CD](https://about.gitlab.com/ja-jp/topics/ci-cd/)パイプラインとソース管理システムを手動で設定する手間がかかります。\n\n## Jira2Labについて\n\nJira2Labは、JiraからGitLabへの大規模な移行時に発生する特有の課題を解決するためにゼロから設計されました。単にデータを移行するだけでなく、ダウンタイムやデータ損失を引き起こすことなく、GitLabの強力なDevSecOps環境にシームレスに移行できるようにチームを支援します。\n\n### Jira2Labの主な機能\n\n1. 大規模なデータ処理の効率化\u003Cbr>\nJira2Labは、パフォーマンスを低下させることなく、複数のプロジェクトにわたって数千ものイシュー、添付ファイル、コメント、カスタムフィールドを処理できるように最適化されています。簡単にスケールできるため、最大規模の企業移行にも対応可能です。\n\n2. カスタムワークフローとフィールドのマッピング\u003Cbr>\nJira2Labの数ある機能の中でもひときわ目立つのは、JiraからGitLabへカスタムワークフローとフィールドを自動的にマッピングする機能です。このツールの柔軟なマッピング設定を活用することで、移行プロセス中の手作業が不要となり、JiraからGitLabにすべてをスムーズに移行できます。\n\n3. CI/CDパイプラインの統合\u003Cbr>\nJira2Labはイシューやプロジェクトを移行するだけでなく、GitLabのCI/CDパイプライン全体を移行プロセスに統合します。そのため、開発チームは移行後すぐに、自動テストやデプロイパイプラインなど、GitLabのDevSecOps機能を使い始められます。\n\n4. 移行テスト\u003Cbr>\nJira2Labは移行テストに対応しているため、大規模な移行を行う前に設定やワークフローをテストできます。テストを通じてあらゆる問題を早期に発見しておくことで、移行全体を中断することなく進められます。\n\n5. リアルタイムモニタリング\u003Cbr>\nJira2Labは、移行中のリアルタイムでのモニタリングとログ生成に対応しています。これらを活用することで、完全な透明性が確保され、すべてのステップがエラーなく正確に実行されていることを確認できます。\n\n6. 柔軟かつカスタマイズ可能\u003Cbr>\nJiraインスタンスに独自の設定やワークフローがある場合でも、Jira2Labは独自の要件に従って移行をカスタマイズできる柔軟性を備えているため、移行中に何かが失われることはありません。\n\n### JiraとGitLabの機能比較\n\nJiraからGitLabに移行することで、ワークフローの統合に加え、GitLab固有の高度な機能を利用できるようになります。各プラットフォームの主な機能を簡単に比較してみました。\n\n| **機能**             | **Jira**                        | **GitLab**                    |\n|-------------------------|----------------------------------|-------------------------------|\n| **イシュートラッキング**       | はい（高度にカスタマイズ可能）       | はい（DevSecOpsに統合されている）   |\n| **アジャイルボード**         | はい（Kanban、Scrum）             | はい（イシューボード、マイルストーン） |\n| **CI/CD**                | いいえ（外部ツールが必要）    | はい（ビルトインのCI/CD）           |\n| **ソース管理**       | いいえ（GitHub／Bitbucketが必要）  | いいえ（ネイティブGitサポート）       |\n| **DevSecOpsツール**         | 統合に制限あり            | DevSecOpsライフサイクル全体          |\n\nJira2Labでは、開発および運用に対するGitLabの統合されたアプローチが最大限に活用されており、イシュートラッキングからCI/CDパイプラインまで、すべての重要な要素をスムーズに移行可能です。\n\n## 移行方法\n\nJira2Labは、5段階からなる構造化された移行方法に基づき、中断を最小限に抑えてシームレスな移行を実現します。\n\n### 1. 調査と計画\n\nまずは、お客様のJiraの設定を十分に理解し、移行すべきすべてのカスタムワークフロー、フィールド、プロジェクトを特定します。この段階では、JiraとGitLabの機能を比較し、移行プロセスを細部まで計画するためのギャップ分析も行います。\n\n### 2. 設定\nこの段階では、移行ツールの設定に加え、JiraとGitLabの両方に必要な環境を設定します。移行開始前にすべての権限を確認し、Jiraデータのバックアップを設定する作業も、この段階で行います。\n\n### 3. 移行テスト\nデータセット全体を移行する前に、一部のプロジェクトで移行テストを実行して、移行プロセスやワークフロー、データの整合性をテストします。これにより、問題がある場合でも、プロセスの早い段階で特定して解決できます。\n\n### 4. 大規模な移行\n移行テストの結果を検証した後、全プロジェクトを対象に移行を行います。その際、ダウンタイムを最小限に抑え、開発チームがスムーズに移行を行えるようにします。\n\n### 5. 移行の完了および移行後のサポート\n移行完了後も、すべてのチームでGitLabを十分にご活用いただくために、引き続きサポートいたします。この段階では、ユーザートレーニングの提供に加え、必要な場合はJiraインスタンスの廃止も行います。\n\n## 事例：Jira2Labで大規模な移行に取り組む\n\nある大企業では最近、移行を実施する際に、50のプロジェクトにまたがる20,000件超のイシューをJiraからGitLabに移行する必要に迫られました。プロジェクトには高度にカスタマイズされたワークフロー、数千ものコメントや添付ファイルもあり、これらもすべて移行する必要がありました。\n\nJira2Labの活用により、以下を達成しました。\n\n- データを一切失うことなく、カスタムフィールドを含むすべてのデータを移行。\n- GitLab内にCI/CDパイプラインを設定したことで、移行後すぐにチームが作業を継続可能に。\n- 2つのプロジェクトで移行テストを実施することで、組織全体を対象に移行を進める前に、ワークフローの軽度の矛盾を特定して修正。\n\n結果として、大きなダウンタイムも発生することなく、全プロセスが予定していた期限内に完了し、GitLabへのシームレスな移行を実現できました。\n\n## Jira2Labを今すぐ利用する\n\nほかの移行ツールでは対応できない課題を解決できるJira2Labは、市場において注目を浴びています。大規模な移行に特化して設計されており、プロジェクト管理データのみを対象とする多くのツールとは異なり、GitLabのDevSecOpsライフサイクル全体と統合できます。カスタムワークフローのマッピング、およびCI/CDパイプラインの統合に対応するJira2Labは、GitLabへの移行時に開発ワークフローを強化したい企業にとって最適なソリューションです。\n\n> GitLabを使用した開発プロセスのスケーリングをご希望の場合は、GitLabの[プロフェッショナルサービスカタログ](https://about.gitlab.com/services/catalog/)をご覧ください。お客様が効率的かつ効果的に移行プロセスを進められるよう、当社チームで提供しているサポート内容をご紹介しています。GitLabによるJira2Labの個別デモをご希望の場合は、ページ下部のフォームからお問い合わせください。\n",[679,111,747,681,682],"DevSecOps",{"slug":749,"featured":93,"template":686},"seamlessly-migrate-from-jira-to-gitlab-with-jira2lab-at-scale","content:ja-jp:blog:seamlessly-migrate-from-jira-to-gitlab-with-jira2lab-at-scale.yml","Seamlessly Migrate From Jira To Gitlab With Jira2lab At Scale","ja-jp/blog/seamlessly-migrate-from-jira-to-gitlab-with-jira2lab-at-scale.yml","ja-jp/blog/seamlessly-migrate-from-jira-to-gitlab-with-jira2lab-at-scale",{"_path":755,"_dir":249,"_draft":6,"_partial":6,"_locale":7,"seo":756,"content":762,"config":768,"_id":770,"_type":16,"title":771,"_source":18,"_file":772,"_stem":773,"_extension":21},"/ja-jp/blog/best-practices-to-set-up-organizational-hierarchies-that-scale",{"title":757,"description":758,"ogTitle":757,"ogDescription":758,"noIndex":6,"ogImage":759,"ogUrl":760,"ogSiteName":670,"ogType":671,"canonicalUrls":760,"schema":761},"柔軟な組織階層を構築するためのベストプラクティス","このページでは、GitLabで組織階層をモデル化する方法をご紹介します。アジャイルの原則を守りながら、明確なコミュニケーションライン、戦略的な連携などを持つ組織を構築する方法を学びましょう。","https://res.cloudinary.com/about-gitlab-com/image/upload/v1750098165/Blog/Hero%20Images/Blog/Hero%20Images/agile_agile.png_1750098164666.png","https://about.gitlab.com/blog/best-practices-to-set-up-organizational-hierarchies-that-scale","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"柔軟な組織階層を構築するためのベストプラクティス\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Amanda Rueda\"}],\n        \"datePublished\": \"2024-07-22\",\n      }",{"title":757,"description":758,"authors":763,"heroImage":759,"date":764,"body":765,"category":14,"tags":766,"updatedDate":767},[675],"2024-07-22","GitLabサブスクリプションのメリットをフル活用するには、効果的な組織設定が欠かせません。このガイドでは、グループ、サブグループ、プロジェクト構造を設定することで、GitLabの使いやすさを向上させる方法をわかりやすく説明します。\n\n## グループ、サブグループ、プロジェクトの構造を理解する\n\nグループとプロジェクトは、組織階層をモデル化し、高度な権限管理と「チームの集合体」を活用した計画を可能にします。グループとサブグループは、戦略的な計画立案に利用され、その設定が下位階層のサブグループやプロジェクトに引き継がれるよう構成管理を行えます。\n\nこの他にも、バリューストリームをモデル化して、組織全体のプロジェクト管理やコラボレーションを強化することも可能です。\n\n- **プロジェクトレベル（チームレベル）**\n    - プロジェクトは、グループやサブグループに属しており、実際の作業はここで行われます。ここにはリポジトリがあり、プロジェクト固有の設定が管理できます。このレベルでは、日々の作業や詳しいプロジェクトの進捗を確認できます。\n    - 効果的にプロジェクトを設定することで、データを明確に整理し、報告や分析を正確に行うことができます。\n\n- **サブグループレベル（チームの集合体）**\n    - サブグループでは、より細かい権限管理が可能です。特定のチームやプロジェクトのニーズに合わせてカスタマイズできるため、組織全体で一貫したワークフローを実現できます。\n    - サブグループは、アジャイルにおける「チームの集合体」と同じように、関連するプロジェクトの集合体として機能します。\n    - このレベルは、共通の製品やサービスに取り組む複数のチームを管理する際に効果的です。これにより、複数のプロジェクト間で可視化と連携が容易になり、チーム間の同期が取れるようになるため、相互依存関係や目標の共有が可能になります。\n\n- **グループレベル（「チームの集合体」の集合体）**\n    - グループはGitLab内の組織の柱のようなもので、そこでは幅広い権限とアクセスを管理することができます。\n    - 最上位のレベルであるグループは、複数のサブグループが含まれます。アジャイルにおける『「チームの集合体」の集合体』のような、プロジェクト管理の戦略的な階層を表します。\n    - このレベルでは、包括的な目標と戦略を設定し、プロジェクトやサブグループにリソースを割り当てることで、組織の全体的なビジネス目標との整合性を確保します。\n\nGitLabを使って組織を構造化することで、選択したアジャイル手法を並行して実行でき、プロジェクト全体に自然にアジャイルの原則を適用できます。この構造により、明確なコミュニケーションライン、効率的なリソース管理、戦略的な連携が促進され、アジャイル手法特有の柔軟性や対応力が維持されます。\n\n> [GitLabアジャイルプランニング](https://about.gitlab.com/blog/categories/agile-planning/)に関するニュースやインサイトはこちらから。\n\n## GitLabの継承モデルを活用する\n\nGitLabの強力な機能のひとつに[継承モデル](https://docs.gitlab.com/ee/tutorials/scrum_events/index.html#understanding-the-inheritance-model-in-gitlab)があります。これは、上位階層で設定した権限、構成が自動的に下位階層にも適用されるようにするものです。また逆に、下位階層のデータを直感的に上位階層で利用することも可能です。継承モデルを使用すると、ポートフォリオ全体を上位のグループから可視化できます。さらに、個々のチームが作業を管理できるように、階層構造の下位に専用のスペースを確保します。\n\n例：\n- **上位グループでマイルストーンやラベルを作成**し、下位のすべてのサブグループやプロジェクトに自動的に適用することで、一貫性と組織の標準への準拠を促進します。\n- 下位レベルのプロジェクトやサブグループの**イシューやエピック**は、バリューストリーム階層の構造に沿って集約されるため、プログラム管理者やエグゼクティブ層が参照しやすくなります。\n- **グループレベルまたはトップレベルのサブグループ**でユーザー権限を管理することで、権限やアクセス制限を効率化できます。これにより、アクセス制御の管理が簡素化され、設定を繰り返すことなく、複数のプロジェクトにわたって適切な人が適切なアクセス権を持てるようになります。\n\nこうしたヒントを活用することで、管理上のオーバーヘッドを減らすことができるだけでなく、上位レベルでの変更が一貫して下位レベルに反映されるようになり、その結果、セキュリティとコンプライアンスの強化が実現できます。\n\n![組織階層図](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750098179/Blog/Content%20Images/Blog/Content%20Images/image2_aHR0cHM6_1750098179305.png)\n\n## GitLabセットアップのベストプラクティス\n\nGitLabの組織階層を設定する際には、組織のニーズに応じて以下のオプションをおすすめします。Self-managedユーザーの場合、「会社名」などのルートグループ階層を省略できます。Self-Managedはシングルテナントデプロイメントのためこのような追加の組織階層は必要ないからです。こういった柔軟性により、特定の組織構造や導入形態に合わせたGitLabのセットアップが実現できます。\n\n### オプション1：組織のサブグループレベルで権限とアクセスを付与する\n\nこのオプションは、複雑な権限構造や、多数のユーザー間で効率的にプロジェクトを共有する必要がある大規模な組織に最適です。\n\n#### 構造の例\n\n- 組織グループ\n    - 主に企業の提供システムとの統合を通じて、広範なアクセス権限を管理します。\n    - ユーザーはサブグループに追加され、これらのグループは、グループ全体を別の[グループ](https://docs.gitlab.com/ee/user/group/manage.html#share-a-group-with-another-group) や [プロジェクト](https://docs.gitlab.com/ee/user/project/members/share_project_with_groups.html)と共有する基盤として機能します。これにより、直接ユーザーを管理する手間を最小限に抑えます。\n    - ユーザーグループを作成すると、GitLab内で[グループメンション](https://docs.gitlab.com/ee/user/discussions/index.html#mentions)が利用できるので、一度に多くのユーザーグループをメンションできます。\n\n- 開発グループ\n    - 最上位の開発グループレベルにおいて、エグゼクティブレベルとプログラムマネジメントレベルに対して、すべての開発プロジェクトにまたがる可視性を提供します。\n    - 製品機能レベルの開発は、複数のリポジトリにアクセスが必要なため、サブグループレベルで作成されます。\n    - プロジェクトは開発用のリポジトリを管理するために作成されます。これは各開発チームのアクセスに利用します。\n\n![サブグループレベルの組織図](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750098179/Blog/Content%20Images/Blog/Content%20Images/Image_1_aHR0cHM6_1750098179306.png)\n\n### オプション2：任意のレベルで権限とアクセスを付与する。\nこのオプションは、アクセス要件がそれほど複雑でない小規模な組織に最適です。ユーザーは、アクセスが必要な際に、部門グループ、サブグループ、またはプロジェクトに個別に追加されます。これにより、プロジェクト管理と運用の可視性を直接管理できます。\n\n#### 概要\n- 必要なアクセス権限に応じて、ユーザーを階層の最上位にあるグループまたは下位のサブグループやプロジェクトに追加できます。同じグループに属するメンバーを一度に追加するのではなく、各メンバーを個別に追加する必要があります。\n- 最上位の開発グループレベルにおいて、エグゼクティブレベルとプログラムマネジメントレベルに対して、すべての開発プロジェクトにまたがる可視性を提供します。\n- 製品機能レベルの開発は、複数のリポジトリにアクセスが必要なため、サブグループレベルで作成します。\n- プロジェクトは開発用のリポジトリを管理するために作成します。これは各開発チームのアクセスに利用します。\n\n![任意のレベルで付与される権限](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750098179/Blog/Content%20Images/Blog/Content%20Images/Image_2_aHR0cHM6_1750098179307.png)\n\n### その他の構成に関する考慮事項\n\n- マイルストーンとイテレーション\n    - 幅広い可視性を確保するため、またはグループ間でマイルストーンを共有する必要がある場合は、グループレベルのマイルストーンを作成します。  \n    - マイルストーンが1つのプロジェクトに固有の場合は、プロジェクトレベルでマイルストーンを作成します。 \n    - 複数のグループにまたがって作業しているチームの場合、親グループレベルでイテレーションを設定すると、追跡が統一され、効率よく作業を進めることができます。\n\n- データ管理\n    - GitLabのロードマップ、ボード、リストページを活用して、組織の設定を反映したデータを取り込みましょう。これにより、進捗状況を可視化し、組織のさまざまなレベルにわたって効果的に計画を立てることができます。\n    - GitLabでは、下位レベルで作成されたデータであっても、上位レベルのグループで利用できます。\n    - 複数のグループやプロジェクトにまたがるデータを確認する場合には上位レベルのビューを作成し、特定のグループやプロジェクトのデータに集中する場合には下位レベルのビューを作成します。\n\n- テンプレートの作成\n    - 上位レベルのテンプレートを作成して、後続のすべてのサブグループやプロジェクトに確実に適用できるようにします。これには、一般的なガイドラインやプロジェクト固有の要件を盛り込みます。\n    - テンプレートは、該当するグループ（[関連するドキュメント](https://docs.gitlab.com/ee/user/project/description_templates.html)）内の独自のリポジトリ内に作成します。\n\n- ラベル\n    - 上位レベルのラベルを作成し、後続のすべてのサブグループやプロジェクトに確実に適用できるようにします。これには、組織ラベルとプロジェクト固有のラベルが含まれます。\n    - スコープ付きラベルを使用して、チームやワークフローのステータスなどの組織構造を定義します。\n\n![ラベル付きイシューボード](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750098179/Blog/Content%20Images/Blog/Content%20Images/image3_aHR0cHM6_1750098179310.png)\n\n## GitLabの機能を活用して成果を上げる\n\nGitLabで適切な構造を実装することは、ソフトウェアプロジェクトの管理を合理化するだけでなく、組織のさまざまなレベルでの可視性を高め、トップマネジメントから一般社員まで、情報に基づいた意思決定を行うために必要な情報を確実に得ることができます。 \n\n> [GitLab Ultimateの30日間無料トライアル](https://gitlab.com/-/trial_registrations/new?glm_source=about.gitlab.com/blog&glm_content=default-saas-trial)で、組織の階層構造のモデリングを始めませんか？\n\n*監修：川瀬 洋平 [@ykawase](https://gitlab.com/ykawase)\n（GitLab合同会社 カスタマーサクセス本部 シニアカスタマーサクセスマネージャー）*\n",[679,681,680],"2024-12-27",{"slug":769,"featured":6,"template":686},"best-practices-to-set-up-organizational-hierarchies-that-scale","content:ja-jp:blog:best-practices-to-set-up-organizational-hierarchies-that-scale.yml","Best Practices To Set Up Organizational Hierarchies That Scale","ja-jp/blog/best-practices-to-set-up-organizational-hierarchies-that-scale.yml","ja-jp/blog/best-practices-to-set-up-organizational-hierarchies-that-scale",{"_path":775,"_dir":249,"_draft":6,"_partial":6,"_locale":7,"seo":776,"content":782,"config":788,"_id":790,"_type":16,"title":791,"_source":18,"_file":792,"_stem":793,"_extension":21},"/ja-jp/blog/how-gitlab-agile-planning-improves-collaborative-project-management",{"title":777,"description":778,"ogTitle":777,"ogDescription":778,"noIndex":6,"ogImage":779,"ogUrl":780,"ogSiteName":670,"ogType":671,"canonicalUrls":780,"schema":781},"GitLabのアジャイル計画によって共同プロジェクト管理を推進する方法","プロジェクト管理においてGitLabを使用することでもたらされる変革は、単にツールを使用するということではなく、コラボレーションと継続的な改善の文化が育まれることです。その方法についてご紹介します。","https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097041/Blog/Hero%20Images/Blog/Hero%20Images/blog-image-template-1800x945%20%2822%29_718ZuurL0op4weunB2fBlD_1750097040694.png","https://about.gitlab.com/blog/how-gitlab-agile-planning-improves-collaborative-project-management","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"GitLabのアジャイル計画によって共同プロジェクト管理を推進する方法\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Amanda Rueda\"}],\n        \"datePublished\": \"2024-07-16\",\n      }",{"title":777,"description":778,"authors":783,"heroImage":779,"date":784,"body":785,"category":14,"tags":786,"updatedDate":787},[675],"2024-07-16","効果的なコラボレーションはアジャイルプロジェクト管理の土台であり、企業においてチームが高品質なソフトウェアを効率的に提供することを可能にします。GitLabの包括的なプラットフォームは、コラボレーションを促進し、ワークフローを効率化します。また、[アジャイルの原則](https://about.gitlab.com/ja-jp/solutions/agile-delivery/)をサポートしています。この記事では、GitLabを使用することで、チームがシームレスに協力し合い、プロジェクトの成果を向上させる方法についてご紹介します。\n\n## 共同プロジェクト管理によってエンタープライズアジャイルチームが得られる価値\n\n今日のダイナミックな開発環境においてアジャイルチームが成功を収めるには、共同プロジェクト管理方法を採用することが不可欠です。これがなぜ重要なのか、またGitLab Enterprise Agile Planningがどのように役立つかを以下に説明します。\n\n- **コミュニケーションの強化**：コラボレーションすることで、チームメンバー全員が円滑にコミュニケーションを取り、誤解を防ぎ、全員が共通の目標に向け取り組むことができます。これは、迅速なイテレーションと継続的なフィードバックが鍵となるエンタープライズアジャイル環境では非常に重要です。\n- *GitLabでエピックを分解し、スレッド形式のコメントを使用することで、だれもが共通認識を持つことができ、イシュー内での綿密なディスカッションが促進されます。*\n- **効率性の向上**：連携しやすい雰囲気を作り出すことで、チームは各メンバーのユニークなスキルや専門知識を活用できるため、結果として問題解決やタスクの完了までにかかる時間が短縮されます。コラボレーションツールを使用すると、ワークフローの効率化やボトルネックの削減に加え、チームがより迅速に価値を提供できるようになります。\t\n  - *GitLabの統合プラットフォームは、計画からデプロイまで開発のあらゆる側面を統合し、合理的かつ効率的なワークフローを実現します。*\n\n- **より良い意思決定の実現**：チームメンバーが密接に連携することで、多様な視点やインサイトを共有できるため、より良い意思決定を下せます。コラボレーションをとおして、最高のアイデアが見いだされ、実践される「集合知の文化」が促進されます。\n- *GitLabのイシューボードとラベルは、アイデアの整理や優先順位付けを行う上で便利です。使用することで、選択肢の評価や情報に基づいた意思決定を行いやすくなります。*\n- **士気とエンゲージメントの向上**：コントリビュートに重きを置く共同作業環境で働くことで、チームの士気とエンゲージメントが大幅に向上します。効果的にコラボレーションを行うアジャイルチームでは、モチベーションや所有権の意識が高く、プロジェクトの成功により積極的に取り組む傾向があります。\n- *メンバーの実績を認め、お祝いするには、GitLabでチームメンバーによるコントリビュートやアクティビティフィードにリンクしましょう。*\n- **成果物の品質向上**：多くの場合、共同作業を行うことで、より質の高い成果物を得られます。継続的なフィードバックとピアレビューにより、問題を早期に発見して迅速に対処でき、結果としてより洗練された堅牢な製品を開発できます。\n- *GitLabのマイルストーントラッキングとプロジェクトテンプレートを使用すると、プロジェクト間で一貫した品質基準を達成でき、徹底したレビューと標準化を行えます。*\n- **適応性と柔軟性**：アジャイルチームは、フィードバックや変化する要件に基づいて素早くピボット（方向転換）できなければなりません。コラボレーションを行うことで、計画や戦略をリアルタイムで柔軟に調整できるため、チームが迅速に対応できるだけでなく、プロジェクト目標に沿って作業を進められるようになります。\n- *GitLabのロードマップと動的なスケジュール機能を使用すると、タイムラインと優先順位を適宜調整できるため、チームのアジャイル性が保たれ、変化にも迅速に対応できます。*\n\n私はプロダクトマネージャーという立場から、これらのメリットがチームのパフォーマンスにどのように変化をもたらすかを目の当たりにしてきました。アジャイルチームにおいて、これらの共同プロジェクト管理方法を取り入れることで、生産性が高まり、イノベーションが促進され、そしてプロジェクト全体の成果を向上できます。\n\n> [GitLabのアジャイル計画に関する最新情報とインサイトはこちら](https://about.gitlab.com/ja-jp/blog/categories/agile-planning/)から。\n\n## GitLabを使用してアジャイルを成功させる\n\n包括的なツールを提供するGitLabは、次のような共同作業を完璧にサポートします。\n\n- **アジャイル開発の効率化**：GitLabでは階層型プランニングがサポートされているため、チームはプロジェクトをエピックに作成して、それを機能やユーザーストーリー、タスクに分解できます。このようにわかりやすい構成により、複雑なプロジェクトでも管理しやすく、透明性が確保され、着実かつ継続的な価値の提供が促進されます。GitLabでは作業を詳細なセグメントに分割できるため、アジャイルチームは焦点を維持し、効率的に目標を達成しやすくなります。\n\n![エピックと子イシューのネストされたリスト](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097050/Blog/Content%20Images/Blog/Content%20Images/image4_aHR0cHM6_1750097050298.png)\n\n- **可視性と責任の向上**：さまざまな部門が関わる取り組みでは、依存関係を管理することが重要です。依存関係を作成、トラッキング、視覚化するGitLabツールを使用すると、チームメンバーは大規模なプロジェクトにおいて、自分の作業がどの部分を担っているのかを明確に把握できます。このように視覚化することで、ボトルネックを防ぎ、プロジェクト目標に沿って作業を行えるため、より責任感を感じながら、足並みをそろえてプロジェクトを進められます。\n\n![取り組みの依存関係が表示されたスクリーンショット](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097050/Blog/Content%20Images/Blog/Content%20Images/image1_aHR0cHM6_1750097050300.png)\n\n- **すべてのユーザー向けの統合プラットフォーム**：GitLabは、すべてのステークホルダーを単一プラットフォームの下に統合し、さまざまなツールを使うことで生まれがちなサイロ化を解消します。これにより、チーム間のコミュニケーションとコラボレーションが強化されます。デベロッパー、プロジェクトマネージャー、QAスペシャリスト、UXデザイナーなど職種を問わず、GitLabでは誰もが同じデータやツールを利用できるため、より一貫性のある作業環境が実現されます。\n\n- **リアルタイムでのコラボレーションとコミュニケーション**：GitLabは、マージリクエスト、イシュートラッキング、継続的インテグレーション／継続的デプロイ（[CI/CD](https://about.gitlab.com/ja-jp/topics/ci-cd/)）パイプラインなどの機能によって、リアルタイムのコラボレーションをサポートします。これらの機能は開発プロセスを効率化し、継続的なフィードバックの提供と反復的な改善を促進します。組み込みのチャット、マージリクエストへのコメント、リアルタイムの通知により、だれもが最新情報を入手し、足並みをそろえることができます。\n\n![製品、開発、デザインチーム間のチャットのやり取りが表示されたスクリーンショット](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097050/Blog/Content%20Images/Blog/Content%20Images/image3_aHR0cHM6_1750097050305.png)\n\n- **データドリブンの意思決定と継続的な改善**：GitLabで行われるすべてのアクションは測定可能であるため、戦略的プランニングと運用調整を行う上で役立つ貴重なインサイトを得られます。[GitLabの分析機能](https://about.gitlab.com/solutions/value-stream-management/)を使用すると、サイクルタイムやデプロイ頻度などの重要業績評価指標をモニタリングできます。このようなデータドリブンアプローチにより、推測ではなく証拠に基づいて意思決定を行うことができ、リーンの原則に沿って継続的な改善が促進されます。\n\n![バリューストリーム分析ダッシュボード](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097050/Blog/Content%20Images/Blog/Content%20Images/image2_aHR0cHM6_1750097050308.png)\n\n## エンタープライズアジャイルプランニングの変革を始める\n\nGitLabがプロジェクト管理にもたらす変革はすばらしいものです。単にツールを使用するということではなく、コラボレーションと継続的な改善の文化が育まれます。担当するチームが協力し合うことなく、各自取り組みを行っていた状態から、一体となり、効率的でモチベーションの高いチームへと変化するのを目の当たりにできたときは、非常に報われた気持ちになりました。\n\nGitLabは、包括的な計画ツールとリアルタイムのコラボレーション機能を単一プラットフォームに統合することで、共同プロジェクト管理の定義を変えます。アジャイルのプラクティスとシームレスに連携し、チームがより効率的かつ正確にプロジェクトを管理できるようにします。GitLabは組織の規模を問わず、現代のソフトウェア開発の複雑さに対応するために必要なツールを提供することで、プロジェクトが成功し、納期を遵守できるようにします。\n\n> [GitLab Ultimateの30日間無料トライアル](https://gitlab.com/-/trial_registrations/new?glm_source=about.gitlab.com/blog&glm_content=default-saas-trial)で、今すぐGitLab Enterprise Agile Planningをスタート！",[679],"2025-06-12",{"slug":789,"featured":93,"template":686},"how-gitlab-agile-planning-improves-collaborative-project-management","content:ja-jp:blog:how-gitlab-agile-planning-improves-collaborative-project-management.yml","How Gitlab Agile Planning Improves Collaborative Project Management","ja-jp/blog/how-gitlab-agile-planning-improves-collaborative-project-management.yml","ja-jp/blog/how-gitlab-agile-planning-improves-collaborative-project-management",{"_path":795,"_dir":249,"_draft":6,"_partial":6,"_locale":7,"seo":796,"content":802,"config":810,"_id":812,"_type":16,"title":813,"_source":18,"_file":814,"_stem":815,"_extension":21},"/ja-jp/blog/gitlab-for-agile-software-development",{"title":797,"description":798,"ogTitle":797,"ogDescription":798,"noIndex":6,"ogImage":799,"ogUrl":800,"ogSiteName":670,"ogType":671,"canonicalUrls":800,"schema":801},"GitLab をアジャイルソフトウェア開発で使用する方法","本ブログでは、アジャイルアーティファクトが GitLab 機能にどのようにマッピングされるのか、また、GitLab 内でアジャイルのイテレーションがどのように表示されるのかについてご説明します。","https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097459/Blog/Hero%20Images/Blog/Hero%20Images/blog-image-template-1800x945%20%2821%29_2pdp2MNB7SoP4MhhiI1WIa_1750097459157.png","https://about.gitlab.com/blog/gitlab-for-agile-software-development","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"GitLab をアジャイルソフトウェア開発で使用する方法\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Victor Wu\"},{\"@type\":\"Person\",\"name\":\"Amanda Rueda\"}],\n        \"datePublished\": \"2018-03-05\",\n      }",{"title":797,"description":798,"authors":803,"heroImage":799,"date":805,"body":806,"category":14,"tags":807,"updatedDate":809},[804,675],"Victor Wu","2018-03-05","GitLab で[アジャイル開発手法](https://about.gitlab.com/ja-jp/solutions/agile-delivery/)がサポートされているかどうか考えたことはありますか。GitLab の使用を検討中の場合、DevSecOps プラットフォームの機能がどのようにアジャイルのアーティファクトと対応しているのかが分かりにくいかもしれません。そこで、本記事で詳しくご説明します。\n\nアジャイルとは、ここ数十年でソフトウェアエンジニアリング分野に導入された、最も重要で革新的な手法のひとつです。アジャイルの概念に関する細かい用語は統一されていないものの、アジャイル自体は、[アジャイルソフトウェア開発](https://about.gitlab.com/ja-jp/topics/agile-delivery/)プロセスとアジャイルデリバリープロセスを通じて顧客中心の製品を効率的に開発できるなど、ソフトウェア開発チームに大きなプラスの影響を与えてきました。\n\nGitLab は、アジャイルであっても、アジャイルの影響を受けた手法であっても、ソフトウェア開発の手法に柔軟に適応できるよう設計されています。この記事では、アジャイルアーティファクトを簡単に GitLab 機能にマッピングさせる方法をご紹介し、お客様が GitLab を使用することで、パフォーマンスの良い[アジャイルソフトウェアデリバリーチーム](https://about.gitlab.com/ja-jp/solutions/agile-delivery/)をどのように運営しているのかを解説します。\n\n## アジャイルアーティファクトを GitLab 機能にマッピングする\n\n### アジャイルアーティファクト → GitLab 機能\n\n- ユーザーストーリー –> [イシュー](https://docs.gitlab.com/ee/user/project/issues/) \n- タスク –> [タスク](https://docs.gitlab.com/ee/user/tasks.html) \n- エピック –> [エピック](https://docs.gitlab.com/ee/user/group/epics/) \n- ポイントと推定 –> [イシューのウェイト](https://docs.gitlab.com/ee/user/project/issues/issue_weight.html) \n- プロダクトのバックログ –> [イシューボード](https://docs.gitlab.com/ee/user/project/issue_board.html)\n- スプリント／イテレーション –> [イテレーション](https://docs.gitlab.com/ee/user/group/iterations/) \n- アジャイルボード –> [イシューボード](https://docs.gitlab.com/ee/user/project/issue_board.html) \n- チームワークロード –> [イシューボード](https://docs.gitlab.com/ee/user/project/issue_board.html) \n- バーンダウンチャート –> [バーンダウンチャート](https://docs.gitlab.com/ee/user/project/milestones/burndown_and_burnup_charts.html)\n\n## GitLabで行うアジャイルのイテレーション\n\n### ユーザーストーリー → GitLab イシュー\n\nアジャイルソフトウェア開発手法では、通常、ユーザーストーリーの作成から始めます。ユーザーストーリーでは、1つの機能に対する理解を深め、ユーザーにビジネス価値を提供するために必要な要素を明確にします。GitLab では、[イシュー](https://docs.gitlab.com/ee/user/project/issues/) (英語版) を作成します。GitLab のイシューはタスクやプロジェクトを管理する効果的な手法であり、アジャイルチームにとって不可欠です。ソフトウェアデベロッパーはイシューの作成、割り当て、追跡を行い、責任の明確化と進捗の可視化を実現できます。イシューには、担当者、イテレーション、ウェイト、ラベルといった重要なメタデータが含まれており、ソフトウェア開発プロセス全体を通じてタスクの優先順位付けやワークフローの管理が強化されます。さらに、ディスカッションスレッド、添付ファイル、リアルタイムでの通知により、チームが効率的にイシューに取り組むことができるため、スムーズなコミュニケーションが促進され、優れたチームワークが発揮されます。\n\n![GitLabイシューのスクリーンショット](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097468/Blog/Content%20Images/Blog/Content%20Images/image1_aHR0cHM6_1750097468371.png)\n\nGitLab のイシューは、冒頭にタイトルがあり、その下にビジネス価値やユーザーストーリーに関連するペルソナといった詳細を記載できます。右側のサイドバーには、イシューが紐付けられている親エピックや、イシューのイテレーション、イシューのウェイトなど、他のアジャイル対応機能と統合されており、推定工数を反映しています。\n\n### タスク → タスク\n\nユーザーストーリーは多くの場合、個々のタスクに細分化されます。GitLab の[タスク](https://docs.gitlab.com/ee/user/tasks.html)(英語版) を使用すると、アジャイルチームはユーザーストーリーを個々の作業に細分化できるため、効率的にプロジェクト管理を進められます。この機能は、ソフトウェアデベロッパーがプロジェクト内でタスクを作成、割り当て、追跡できるようにすることで、アジャイルフレームワークをサポートします。タスク管理を GitLab に直接統合することによって、チームは一貫したワークフローを維持し、ソフトウェア開発プロジェクトのあらゆるアクテビティを簡単に追跡、管理できます。\n\n![GitLab を使ったタスク管理とプロジェクト追跡を示すスクリーンショット](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097469/Blog/Content%20Images/Blog/Content%20Images/image3_aHR0cHM6_1750097468372.png)\n\nGitLabを使用して正確なタスク管理とプロジェクト追跡を行うことで、ユーザーに提供する価値を高められます。タスクも、担当者、イテレーション、ウェイト、ラベル、タイムトラッキング、コラボレーション機能など、イシューと同じメタデータを備えています。この包括的な各種機能により、アジャイルチームやプロジェクトマネージャーはワークロードの効果的な管理、タスクの優先順位付け、ソフトウェアデベロッパー間のシームレスなコラボレーションを実現できます。\n\n### エピック → GitLabエピック\n一方、アジャイルを使用する人の中には、エピックと呼ばれる抽象化したものをユーザーストーリーの上に指定する人もいます。エピックとは、複数の機能から構成されている大きなユーザーフローを指します。GitLab の[エピック](https://docs.gitlab.com/ee/user/group/epics/) (英語) には、イシューと同様にタイトルと説明が記載されます。また、複数の子イシューも表示させることができ、階層構造が一見して分かります。\n![ネストされたGitLabエピックのスクリーンショット](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097469/Blog/Content%20Images/Blog/Content%20Images/image7_aHR0cHM6_1750097468374.png)\n\nGitLab では、 最大9 階層までのエピックをネストできるため、アジャイルチームは大規模なプロジェクトも効果的に構築、管理することができます。この階層構造により、プロジェクトのロードマップが明確に示され、ソフトウェアデベロッパーやプロジェクトマネージャーが複雑なイニシアティブを管理しやすいサイズに細分化しやすくなります。子エピックや[紐付けされたエピック](https://docs.gitlab.com/ee/user/group/epics/linked_epics.html) (英語) を活用すると、チームは進捗状況、依存関係、プロジェクトのマイルストーンを的確に追跡できるため、コラボレーションの向上と、一環したアジャイルデリバリーを実現できます。\n\n### プロダクトバックログ → GitLabイシューボード\n\nプロダクトやビジネスのオーナーは通常、ビジネスや顧客のニーズを反映させるためにユーザーストーリーを作成します。ユーザーストーリーは緊急性や開発希望順に基づいてプロダクトバックログ内で優先順位が付けられます。プロダクトオーナーは関係者とコミュニケーションをとり、優先順位を決定したり継続してバックログを調整します。GitLab には[イシューボード](https://docs.gitlab.com/ee/user/project/issue_board.html) (英語版) があり、イテレーションをリストとして整理できるほか、ドラッグアンドドロップで作業を進められるため、アジャイルでのバックログが簡単に優先順位付けできたり、ストーリーを次のスプリントに割り当てたりできます。\n\n![GitLabイシューボードのGIF画像](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097469/Blog/Content%20Images/Blog/Content%20Images/WIP_limit_aHR0cHM6_1750097468376.gif)\n\n### スプリント → GitLabイテレーション\n\nアジャイルにおけるスプリントとは、作業が完了するまでの期限を指します。 1 週間、数週間、または 1 ヶ月以上になることもあります。プロダクトオーナーと開発チーム間で検討を重ね、次のスプリントのスコープとなる作業を決定します。GitLab の[イテレーション](https://docs.gitlab.com/ee/user/group/iterations/) (英語版) 機能ではイテレーションに開始日と終了日を設定し、イテレーションの期間を把握できます。次に、チームは特定のイテレーションにイシューを割り当て、スプリントに取り込みます。\n\nイテレーションを使用することで、GitLab の強化されたアジャイルプロジェクト管理機能を活用して、アジャイルのプランニングならびにデリバリーにおける可視性とコントロールを向上できます。\n\n### ポイントと推定 → GitLabイシューのウェイト\n\nこの章にあるリンクはすべて英語版です。\n\nまた、この段階でユーザーストーリーが共有され、スコープ内の各ユーザーストーリーごとに技術的工数の推定が行われます。GitLab では、イシューには[ウェイト](https://docs.gitlab.com/ee/user/project/issues/issue_weight.html)属性があり、工数の推定に使用されます。\n\nこの時点（またはこの後の段階）で、ユーザーストーリーがさらに技術的な成果物に細分化されたり、技術計画やアーキテクチャがドキュメント化されたりすることもあります。GitLab では、この情報をイシューか[マージリクエストの説明](https://docs.gitlab.com/ee/user/project/merge_requests/)に記載します。技術的なコラボレーションはマージリクエストで行われることが多いためです。\n\nスプリント (GitLabのイテレーション) 中、ソフトウェア開発チームのメンバーは取り組むユーザーストーリーをひとつずつ選びます。GitLab では、イシューに担当者を指定できます。イシューに自分を[割り当てる](https://docs.gitlab.com/ee/user/project/issues/multiple_assignees_for_issues.html)ことで、現在その作業に取り組んでいることを明示します。コードの最初の一行を書く前に[イシューに紐付けた空のマージリクエストを作成する](https://docs.gitlab.com/ee/user/project/issues/)ことをお勧めします。そうすることで技術的なコラボレーションプロセスをすぐに開始できます。\n\n### アジャイルボード → GitLabイシューボード\n\nこの章にあるリンクはすべて英語版です。\n\nアジャイルでは、スプリントの間、イシューは特定の組織のワークフローに応じて「`Ready for dev` (開発準備完了)」「`In dev` (開発中)」「`In QA` (QA 中)」「`In review` (レビュー中)」「`Done` (完了)」など、さまざまなステージを経て進行していきます。\n\n通常、これらのステージがアジャイルボードの列として表示されます。GitLab では、[イシューボード](https://docs.gitlab.com/ee/user/project/issue_board.html)でステージを定義し、イシューをステージ間で移動させることができます。チームは、イテレーションやその他の関連属性に応じて[ボードを設定](https://docs.gitlab.com/ee/user/project/issue_board.html#board-with-configuration)できます。毎日のスタンドアップミーティングでは、チームメンバーが一緒にボードを見て、ワークフローの観点からスプリントの進捗状況を確認します。\n\n![GitLabイシューボードのスクリーンショット](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097469/Blog/Content%20Images/Blog/Content%20Images/image6_aHR0cHM6_1750097468378.png)\nGitLab イシューボードは、GitLab イシューリストと同様、イシューを動的にプルしますが、より柔軟なワークフローも可能です。ボードに個別のリストを設定すれば、アジャイルボードのステージを反映できます。このようにして、チームはユーザーストーリーが「`Ready for dev` (開発準備完了)」から「`Released to production` (本番環境にリリース)」まで推移していくのを管理、追跡できます。\n\n### チームワークロード → GitLabイシューボード\n\nアジャイルチームは、GitLab 内で担当者別でフィルタリングされたリストを持つイシューボードを作成して、ワークフローを最適化できます。この機能により、チームメンバー間のタスクの分配が可視化され、アジャイルデリバリーが強化されます。担当者ごとのリストを作成するには、プロジェクトまたはグループに移動し、「ボード」セクションで新規ボードを作成し、各担当者用の[リストを追加](https://docs.gitlab.com/ee/user/project/issue_board.html#create-a-new-list) (英語) します。イシューをチームメンバーに割り当てると、対応するリストに割り当てが自動的に表示されます。この動的なビューにより、作業負荷のバランスを取りながら効果的なタスク管理を行うことができます。\n\n![整理されたGitLabイシューボードのスクリーンショット](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097469/Blog/Content%20Images/Blog/Content%20Images/image5_aHR0cHM6_1750097468380.png)\n\n[スコープラベル]を使用すると、担当者別またはスクワッド別にイシューボードを整理できます。GitLabのイシューボードは非常に幅広く、ソフトウェア開発ライフサイクル全体のワークフローをサポートします。\n\n### バーンダウンチャート → GitLabバーンダウンチャート\n\nこの章にあるリンクはすべて英語版です。\n\n開発チームは、リアルタイムでプロジェクトが順調に進んでいるかどうかを把握し、リスクが発生した場合にはそれを軽減したいと考えます。GitLab の[バーンダウンチャート](https://docs.gitlab.com/ee/user/project/milestones/burndown_and_burnup_charts.html)を使用すれば、チームは現在のスプリントのスコープとなっている作業が完了するにつれて「バーンダウンする（作業量が減少していく）」様子を視覚化できます。\n\nスプリントの終わりに近づくと、開発チームは完成した機能のデモをさまざまな関係者に向けて実施します。GitLab では、[レビューアプリ](https://docs.gitlab.com/ee/ci/review_apps/index.html)を使うことでこのプロセスが簡素化され、まだ本番環境にリリースされていないコードでも、さまざまなテスト、ステージング、または UAT 環境でデモを行うことができます。レビューアプリと [CI/CD 機能](https://docs.gitlab.com/ee/ci/)は、マージリクエスト自体に統合されています。\n\nデベロッパーやQA担当者は、こうしたツールを活用してCI/CDによる自動テストやレビューアプリ環境での手動テストを行い、ソフトウェアの品質を維持しています。\n\n![GitLabバーンダウンチャートのスクリーンショット](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097469/Blog/Content%20Images/Blog/Content%20Images/image8_aHR0cHM6_1750097468381.png)\n\nGitLabのバーンダウンチャートを使用すると、チームはスプリントのスコープとなっている作業が完了する様子を追跡できます。そのため、リスクに早期に対処し、それに応じて調整を行えます。たとえば、ある機能が次のスプリントに遅れることが見込まれている場合、それを関係者に知らせることができます。\n\nアジャイルスプリントの最後に行われるチームレトロスペクティブ（振り返り）は、GitLab の [wiki](https://docs.gitlab.com/ee/user/project/wiki/index.html) に記録できるため、学んだ教訓や対処項目などを長期にわたって追跡できます。実際のレトロスペクティブでは、チームは[イテレーションレポート](https://docs.gitlab.com/ee/user/group/iterations/#iteration-report)を見ながら、バーンダウンチャートや完了したスプリントに関するその他の統計などを確認することができます。\n\n## GitLabでアジャイルを試してみよう\nアジャイルにおけるプロジェクトマネジメントをレベルアップさせませんか？GitLab は、アジャイルチーム、ソフトウェアデベロッパー、プロジェクトマネージャー向けに特化した包括的な機能を提供し、円滑なコラボレーションと効率的なワークフローを実現します。GitLab の価格オプションをご覧いただき、無料トライアルを始めましょう。GitLab がどのようにアジャイルデリバリープロセスを変革できるかをぜひご体感ください。\n\n> [GitLab アジャイルプランニングについてさらに詳しく知り](https://about.gitlab.com/ja-jp/pricing/)、今すぐGitLabでアジャイルを始めましょう。\n\n*監修：ソリス ジェレズ / Jerez Solis [@jerezs](https://gitlab.com/jerezs)\u003Cbr>\n（GitLab合同会社 ソリューションアーキテクト本部 ソリューションアーキテクト）*\n",[679,681,705,808],"collaboration","2025-03-19",{"slug":811,"featured":6,"template":686},"gitlab-for-agile-software-development","content:ja-jp:blog:gitlab-for-agile-software-development.yml","Gitlab For Agile Software Development","ja-jp/blog/gitlab-for-agile-software-development.yml","ja-jp/blog/gitlab-for-agile-software-development",1,[692,713,733,754,774,794],1754424559754]