[{"data":1,"prerenderedAt":647},["ShallowReactive",2],{"/ja-jp/the-source/platform/":3,"footer-ja-jp":33,"the-source-navigation-ja-jp":344,"the-source-newsletter-ja-jp":370,"the-source-resources-ja-jp":382,"platform-articles-list-authors-ja-jp":414,"platform-articles-list-ja-jp":445,"platform-page-categories-ja-jp":646},{"_path":4,"_dir":5,"_draft":6,"_partial":6,"_locale":7,"config":8,"seo":9,"content":12,"type":25,"slug":26,"_id":27,"_type":28,"title":7,"_source":29,"_file":30,"_stem":31,"_extension":32},"/ja-jp/the-source/platform","the-source",false,"",{"layout":5},{"title":10,"description":11,"ogImage":7},"プラットフォームとインフラストラクチャ","プランニングからデリバリーまで、チームを成功に導くDevSecOpsフレームワークを構築する方法をご紹介します。",[13,19],{"componentName":14,"componentContent":15},"TheSourceCategoryHero",{"title":10,"description":11,"image":16},{"config":17},{"src":18},"https://res.cloudinary.com/about-gitlab-com/image/upload/v1751463263/bdz7hmhpbmgwvoybcaud.png",{"componentName":20,"componentContent":21},"TheSourceCategoryMainSection",{"config":22},{"gatedAssets":23},[24],"gitlab-2024-global-devsecops-report","category","platform","content:ja-jp:the-source:platform:index.yml","yaml","content","ja-jp/the-source/platform/index.yml","ja-jp/the-source/platform/index","yml",{"_path":34,"_dir":35,"_draft":6,"_partial":6,"_locale":7,"data":36,"_id":340,"_type":28,"title":341,"_source":29,"_file":342,"_stem":343,"_extension":32},"/shared/ja-jp/main-footer","ja-jp",{"text":37,"source":38,"edit":44,"contribute":49,"config":54,"items":59,"minimal":332},"GitはSoftware Freedom Conservancyの商標です。当社は「GitLab」をライセンスに基づいて使用しています",{"text":39,"config":40},"ページのソースを表示",{"href":41,"dataGaName":42,"dataGaLocation":43},"https://gitlab.com/gitlab-com/marketing/digital-experience/about-gitlab-com/","page source","footer",{"text":45,"config":46},"このページを編集",{"href":47,"dataGaName":48,"dataGaLocation":43},"https://gitlab.com/gitlab-com/marketing/digital-experience/about-gitlab-com/-/blob/main/content/","web ide",{"text":50,"config":51},"ご協力をお願いします",{"href":52,"dataGaName":53,"dataGaLocation":43},"https://gitlab.com/gitlab-com/marketing/digital-experience/about-gitlab-com/-/blob/main/CONTRIBUTING.md/","please contribute",{"twitter":55,"facebook":56,"youtube":57,"linkedin":58},"https://twitter.com/gitlab","https://www.facebook.com/gitlab","https://www.youtube.com/channel/UCnMGQ8QHMAnVIsI3xJrihhg","https://www.linkedin.com/company/gitlab-com",[60,87,160,232,294],{"title":61,"links":62,"subMenu":68},"プラットフォーム",[63],{"text":64,"config":65},"DevSecOpsプラットフォーム",{"href":66,"dataGaName":67,"dataGaLocation":43},"/ja-jp/platform/","devsecops platform",[69],{"title":70,"links":71},"価格",[72,77,82],{"text":73,"config":74},"プランの表示",{"href":75,"dataGaName":76,"dataGaLocation":43},"/ja-jp/pricing/","view plans",{"text":78,"config":79},"Premiumを選ぶ理由",{"href":80,"dataGaName":81,"dataGaLocation":43},"/ja-jp/pricing/premium/","why premium",{"text":83,"config":84},"Ultimateを選ぶ理由",{"href":85,"dataGaName":86,"dataGaLocation":43},"/ja-jp/pricing/ultimate/","why ultimate",{"title":88,"links":89},"ソリューション",[90,95,100,105,110,115,120,125,130,135,140,145,150,155],{"text":91,"config":92},"デジタルトランスフォーメーション",{"href":93,"dataGaName":94,"dataGaLocation":43},"/ja-jp/topics/digital-transformation/","digital transformation",{"text":96,"config":97},"セキュリティとコンプライアンス",{"href":98,"dataGaName":99,"dataGaLocation":43},"/ja-jp/solutions/security-compliance/","security & compliance",{"text":101,"config":102},"自動化されたソフトウェアデリバリー",{"href":103,"dataGaName":104,"dataGaLocation":43},"/ja-jp/solutions/delivery-automation/","automated software delivery",{"text":106,"config":107},"アジャイル開発",{"href":108,"dataGaName":109,"dataGaLocation":43},"/ja-jp/solutions/agile-delivery/","agile delivery",{"text":111,"config":112},"クラウドトランスフォーメーション",{"href":113,"dataGaName":114,"dataGaLocation":43},"/ja-jp/topics/cloud-native/","cloud transformation",{"text":116,"config":117},"SCM",{"href":118,"dataGaName":119,"dataGaLocation":43},"/ja-jp/solutions/source-code-management/","source code management",{"text":121,"config":122},"CI/CD",{"href":123,"dataGaName":124,"dataGaLocation":43},"/ja-jp/solutions/continuous-integration/","continuous integration & delivery",{"text":126,"config":127},"バリューストリーム管理",{"href":128,"dataGaName":129,"dataGaLocation":43},"/ja-jp/solutions/value-stream-management/","value stream management",{"text":131,"config":132},"GitOps",{"href":133,"dataGaName":134,"dataGaLocation":43},"/ja-jp/solutions/gitops/","gitops",{"text":136,"config":137},"Enterprise",{"href":138,"dataGaName":139,"dataGaLocation":43},"/ja-jp/enterprise/","enterprise",{"text":141,"config":142},"スモールビジネス",{"href":143,"dataGaName":144,"dataGaLocation":43},"/ja-jp/small-business/","small business",{"text":146,"config":147},"公共機関",{"href":148,"dataGaName":149,"dataGaLocation":43},"/ja-jp/solutions/public-sector/","public sector",{"text":151,"config":152},"教育",{"href":153,"dataGaName":154,"dataGaLocation":43},"/ja-jp/solutions/education/","education",{"text":156,"config":157},"金融サービス",{"href":158,"dataGaName":159,"dataGaLocation":43},"/ja-jp/solutions/finance/","financial services",{"title":161,"links":162},"関連リソース",[163,168,173,178,183,188,192,197,202,207,212,217,222,227],{"text":164,"config":165},"インストール",{"href":166,"dataGaName":167,"dataGaLocation":43},"/ja-jp/install/","install",{"text":169,"config":170},"クイックスタートガイド",{"href":171,"dataGaName":172,"dataGaLocation":43},"/ja-jp/get-started/","quick setup checklists",{"text":174,"config":175},"学ぶ",{"href":176,"dataGaName":177,"dataGaLocation":43},"https://university.gitlab.com/","learn",{"text":179,"config":180},"製品ドキュメント",{"href":181,"dataGaName":182,"dataGaLocation":43},"https://docs.gitlab.com/","docs",{"text":184,"config":185},"ブログ",{"href":186,"dataGaName":187},"/ja-jp/blog/","blog",{"text":189,"config":190},"お客様の成功事例",{"href":191,"dataGaLocation":43},"/customers/",{"text":193,"config":194},"お客様成功事例",{"href":195,"dataGaName":196,"dataGaLocation":43},"/ja-jp/customers/","customer success stories",{"text":198,"config":199},"リモート",{"href":200,"dataGaName":201,"dataGaLocation":43},"https://handbook.gitlab.com/handbook/company/culture/all-remote/","remote",{"text":203,"config":204},"GitLabサービス",{"href":205,"dataGaName":206,"dataGaLocation":43},"/ja-jp/services/","services",{"text":208,"config":209},"TeamOps",{"href":210,"dataGaName":211,"dataGaLocation":43},"/ja-jp/teamops/","teamops",{"text":213,"config":214},"コミュニティ",{"href":215,"dataGaName":216,"dataGaLocation":43},"/community/","community",{"text":218,"config":219},"フォーラム",{"href":220,"dataGaName":221,"dataGaLocation":43},"https://forum.gitlab.com/","forum",{"text":223,"config":224},"イベント",{"href":225,"dataGaName":226,"dataGaLocation":43},"/events/","events",{"text":228,"config":229},"パートナー",{"href":230,"dataGaName":231,"dataGaLocation":43},"/ja-jp/partners/","partners",{"title":233,"links":234},"Company",[235,240,245,250,255,260,265,269,274,279,284,289],{"text":236,"config":237},"GitLabについて",{"href":238,"dataGaName":239,"dataGaLocation":43},"/ja-jp/company/","company",{"text":241,"config":242},"採用情報",{"href":243,"dataGaName":244,"dataGaLocation":43},"/jobs/","jobs",{"text":246,"config":247},"経営陣",{"href":248,"dataGaName":249,"dataGaLocation":43},"/company/team/e-group/","leadership",{"text":251,"config":252},"チーム",{"href":253,"dataGaName":254,"dataGaLocation":43},"/company/team/","team",{"text":256,"config":257},"ハンドブック",{"href":258,"dataGaName":259,"dataGaLocation":43},"https://handbook.gitlab.com/","handbook",{"text":261,"config":262},"投資家向け情報",{"href":263,"dataGaName":264,"dataGaLocation":43},"https://ir.gitlab.com/","investor relations",{"text":266,"config":267},"Sustainability",{"href":268,"dataGaName":266,"dataGaLocation":43},"/sustainability/",{"text":270,"config":271},"ダイバーシティ、インクルージョン、ビロンギング（DIB）",{"href":272,"dataGaName":273,"dataGaLocation":43},"/ja-jp/diversity-inclusion-belonging/","Diversity, inclusion and belonging",{"text":275,"config":276},"トラストセンター",{"href":277,"dataGaName":278,"dataGaLocation":43},"/ja-jp/security/","trust center",{"text":280,"config":281},"ニュースレター",{"href":282,"dataGaName":283,"dataGaLocation":43},"/company/contact/","newsletter",{"text":285,"config":286},"プレス",{"href":287,"dataGaName":288,"dataGaLocation":43},"/press/","press",{"text":290,"config":291},"現代奴隷制の透明性に関する声明",{"href":292,"dataGaName":293,"dataGaLocation":43},"https://handbook.gitlab.com/handbook/legal/modern-slavery-act-transparency-statement/","modern slavery transparency statement",{"title":295,"links":296},"お問い合わせ",[297,301,306,311,316,321,326],{"text":295,"config":298},{"href":299,"dataGaName":300,"dataGaLocation":43},"/ja-jp/sales/","sales",{"text":302,"config":303},"サポートを受ける",{"href":304,"dataGaName":305,"dataGaLocation":43},"/support/","get help",{"text":307,"config":308},"カスタマーポータル",{"href":309,"dataGaName":310,"dataGaLocation":43},"https://customers.gitlab.com/customers/sign_in/","customer portal",{"text":312,"config":313},"ステータス",{"href":314,"dataGaName":315,"dataGaLocation":43},"https://status.gitlab.com/","status",{"text":317,"config":318},"利用規約",{"href":319,"dataGaName":320,"dataGaLocation":43},"/terms/","terms of use",{"text":322,"config":323},"プライバシーに関する声明",{"href":324,"dataGaName":325,"dataGaLocation":43},"/ja-jp/privacy/","privacy statement",{"text":327,"config":328},"Cookieの設定",{"dataGaName":329,"dataGaLocation":43,"id":330,"isOneTrustButton":331},"cookie preferences","ot-sdk-btn",true,{"items":333},[334,336,338],{"text":317,"config":335},{"href":319,"dataGaName":320,"dataGaLocation":43},{"text":322,"config":337},{"href":324,"dataGaName":325,"dataGaLocation":43},{"text":327,"config":339},{"dataGaName":329,"dataGaLocation":43,"id":330,"isOneTrustButton":331},"content:shared:ja-jp:main-footer.yml","Main Footer","shared/ja-jp/main-footer.yml","shared/ja-jp/main-footer",{"_path":345,"_dir":5,"_draft":6,"_partial":6,"_locale":7,"logo":346,"subscribeLink":351,"navItems":355,"_id":366,"_type":28,"title":367,"_source":29,"_file":368,"_stem":369,"_extension":32},"/shared/ja-jp/the-source/navigation",{"altText":347,"config":348},"the source logo",{"src":349,"href":350},"https://res.cloudinary.com/about-gitlab-com/image/upload/v1750191004/t7wz1klfb2kxkezksv9t.svg","/ja-jp/the-source/",{"text":352,"config":353},"購読する",{"href":354},"#subscribe",[356,360,363],{"text":357,"config":358},"人工知能",{"href":359},"/ja-jp/the-source/ai/",{"text":96,"config":361},{"href":362},"/ja-jp/the-source/security/",{"text":10,"config":364},{"href":365},"/ja-jp/the-source/platform/","content:shared:ja-jp:the-source:navigation.yml","Navigation","shared/ja-jp/the-source/navigation.yml","shared/ja-jp/the-source/navigation",{"_path":371,"_dir":5,"_draft":6,"_partial":6,"_locale":7,"title":372,"description":373,"submitMessage":374,"formData":375,"_id":379,"_type":28,"_source":29,"_file":380,"_stem":381,"_extension":32},"/shared/ja-jp/the-source/newsletter","The Sourceニュースレター","ソフトウェア開発の未来への洞察に関する最新情報を入手しましょう。","The Sourceのニュースレターへの登録が完了しました。",{"config":376},{"formId":377,"formName":378,"hideRequiredLabel":331},28467,"thesourcenewsletter","content:shared:ja-jp:the-source:newsletter.yml","shared/ja-jp/the-source/newsletter.yml","shared/ja-jp/the-source/newsletter",[383,400],{"_path":384,"_dir":385,"_draft":6,"_partial":6,"_locale":7,"config":386,"title":389,"description":390,"link":391,"_id":397,"_type":28,"_source":29,"_file":398,"_stem":399,"_extension":32},"/shared/ja-jp/the-source/gated-assets/navigating-ai-maturity-in-devsecops","gated-assets",{"id":387,"formId":388},"navigating-ai-maturity-in-devsecops",1002,"DevSecOpsにおいてAIの活用を進める","組織がソフトウェア開発ライフサイクルにAIをどのように組み込んでいるかのインサイトについては、[世界中の5,000人を超えるDevSecOpsプロフェッショナルからの調査結果](https://about.gitlab.com/ja-jp/developer-survey/2024/ai/)をご覧ください。",{"text":392,"config":393},"レポートを読む",{"href":394,"dataGaName":395,"dataGaLocation":396},"https://about.gitlab.com/developer-survey/2024/ai/","Navigating AI Maturity in DevSecOps","thesource","content:shared:ja-jp:the-source:gated-assets:navigating-ai-maturity-in-devsecops.yml","shared/ja-jp/the-source/gated-assets/navigating-ai-maturity-in-devsecops.yml","shared/ja-jp/the-source/gated-assets/navigating-ai-maturity-in-devsecops",{"_path":401,"_dir":385,"_draft":6,"_partial":6,"_locale":7,"config":402,"title":404,"description":405,"link":406,"_id":411,"_type":28,"_source":29,"_file":412,"_stem":413,"_extension":32},"/shared/ja-jp/the-source/gated-assets/source-lp-how-to-get-started-using-ai-in-software-development",{"id":403,"formId":388},"source-lp-how-to-get-started-using-ai-in-software-development","ソフトウェア開発でAIを使用する方法","安全なソフトウェアをより迅速に開発する上で、戦略的なAIのフレームワークの構築に役立つ具体的なヒントが満載のeBookをぜひご一読ください（英語版のみ）。",{"text":407,"config":408},"ebookを読む",{"href":409,"dataGaName":410,"dataGaLocation":396},"https://about.gitlab.com/the-source/ai/getting-started-with-ai-in-software-development-a-guide-for-leaders/","How to Get Started Using AI in Software Development","content:shared:ja-jp:the-source:gated-assets:source-lp-how-to-get-started-using-ai-in-software-development.yml","shared/ja-jp/the-source/gated-assets/source-lp-how-to-get-started-using-ai-in-software-development.yml","shared/ja-jp/the-source/gated-assets/source-lp-how-to-get-started-using-ai-in-software-development",{"amanda-rueda":415,"andre-michael-braun":416,"andrew-haschka":417,"ayoub-fandi":418,"brian-wald":419,"bryan-ross":420,"chandler-gibbons":421,"dave-steer":422,"ddesanto":423,"derek-debellis":424,"emilio-salvador":425,"erika-feldman":426,"george-kichukov":427,"gitlab":428,"grant-hickman":429,"haim-snir":430,"iganbaruch":431,"jlongo":432,"joel-krooswyk":433,"josh-lemos":434,"julie-griffin":435,"kristina-weis":436,"lee-faus":437,"ncregan":438,"rschulman":439,"sabrina-farmer":440,"sandra-gittlen":441,"sharon-gaudin":442,"stephen-walters":443,"taylor-mccaslin":444},"Amanda Rueda","Andre Michael Braun","Andrew Haschka","Ayoub Fandi","Brian Wald","Bryan Ross","Chandler Gibbons","Dave Steer","David DeSanto","Derek DeBellis","Emilio Salvador","Erika Feldman","George Kichukov","GitLab","Grant Hickman","Haim Snir","Itzik Gan Baruch","Joseph Longo","Joel Krooswyk","Josh Lemos","Julie Griffin","Kristina Weis","Lee Faus","Niall Cregan","Robin Schulman","Sabrina Farmer","Sandra Gittlen","Sharon Gaudin","Stephen Walters","Taylor McCaslin",{"allArticles":446,"visibleArticles":645,"showAllBtn":6},[447,490,510,551,571,608,626],{"_path":448,"_dir":26,"_draft":6,"_partial":6,"_locale":7,"config":449,"seo":454,"content":458,"type":485,"category":26,"slug":486,"_id":487,"_type":28,"title":455,"_source":29,"_file":488,"_stem":489,"_extension":32,"date":459,"description":456,"timeToRead":460,"heroImage":457,"keyTakeaways":461,"articleBody":465,"faq":466},"/ja-jp/the-source/platform/why-software-logistics-is-key-to-accelerating-innovation",{"layout":5,"template":450,"articleType":451,"author":452,"featured":331,"gatedAsset":453,"isHighlighted":6,"authorName":437},"TheSourceArticle","Regular","lee-faus","source-lp-building-a-resilient-software-development-practice",{"title":455,"description":456,"ogImage":457},"ソフトウェアロジスティクスこそがイノベーションの加速の鍵である理由","ソフトウェアロジスティクスによってデプロイプロセスを変革して、運用チームがデベロッパーを効率的にサポートできる体制を整え、デリバリーを高速化しましょう。","https://res.cloudinary.com/about-gitlab-com/image/upload/v1751463545/nomdlhvlawqmncg0g1p8.png",{"title":455,"date":459,"description":456,"timeToRead":460,"heroImage":457,"keyTakeaways":461,"articleBody":465,"faq":466},"2025-04-15","4分で読めます",[462,463,464],"ソフトウェアロジスティクスは、プロビジョニング、デプロイ、設定、モニタリング、および保守といった、コードのパッケージ化後の処理に焦点を当て、ソフトウェアサプライチェーンの重要な後半部分を最適化します。","通常、全技術スタッフのうち、運用業務に携わるスタッフは1%しかいません。そのため、組織においてはデプロイプロセスを自動化し、デベロッパーエクスペリエンスを向上させるために「ロジスティクスの考え方」が求められます。","ソフトウェアロジスティクスに「Platform as a Product」のアプローチを取り入れれば、柔軟性を維持しながら標準化を実現し、セキュリティリスクを低減し、さらにデプロイサイクルを短縮できます。","ソフトウェアは単にビジネスを推進するものではなく、ビジネスそのものです。しかしながら、組織は開発力に多額の投資を行う一方で、ソフトウェアロジスティクスという重要な要素を見落としがちです。\n\nソフトウェアロジスティクスには、デリバリー用にコードをパッケージ化した後に行われるすべてのプロセス、つまりプロビジョニング、デプロイ、設定、モニタリング、保守が含まれます。ソフトウェアサプライチェーンの後半部分とみなされるこれらのプロセスは、大変重要です。非常に優れたソリューションを設計したとしても、適切に実行しなければうまくいかない可能性があります。\n\n統計によると、組織内のデベロッパー100人に対して、運用担当者は1人しかいない可能性が高いことが示されており、取り組むべき課題は明らかです。運用担当者は通常、ネットワークエンジニアリングやデータベース管理、プラットフォームエンジニアリング、サイトの信頼性に重点的に取り組んでいます。生成AIの活用によってデベロッパーが作成するコード量が劇的に増えようとしている今、このままではソフトウェアデリバリーの継続が不可能になるというボトルネックが生じます。\n\n## 従来のアプローチでは不十分な理由\n**このようにバランスが取れていない状態で従来のアプローチを取った場合、通常、運用チームに負荷がかかりすぎるか、必要に迫られてデベロッパーが運用に詳しくなるかのどちらかになります。どちらもうまくいきません。**\n\n運用チームに多大な負荷がかかると、制限の多いプロセスを取らざるを得なくなり、結果としてデリバリー速度が遅くなります。一方、デベロッパーが運用を担当せざるを得なくなると、本来の強みである、コーディングによるビジネス上の問題解決に取り組む時間が減ってしまいます。GitLabの[調査結果によると](https://about.gitlab.com/developer-survey/2024/ai/)、デベロッパーが通常、新規コードの作成に費やす時間はわずか21%であり、残りの時間は会議や保守作業、事務作業に費やされていることがわかっています。\n\nこのような非効率的な状態では不満も出やすく、余計なコストもかかります。イノベーションを起こしても、常にデプロイ待ちの状態となるため、ビジネス価値の損失となります。\n\n## ソフトウェアのプレミアムデリバリーモデル\nではソフトウェアデリバリーにおいて、常に信頼性と予測可能性を確保できるとしたらいかがでしょうか？これこそが、ソフトウェアロジスティクスの効率化によって実現できることです。\n\n現代の物流会社が、製品を効率よく倉庫から顧客まで配達できるようにサプライチェーンの効率化を行うことで小売業に革命をもたらしたように、組織はソフトウェアをパッケージレジストリから本番環境までスムーズに移行できるようにする必要があります。\n\n今や[プラットフォームエンジニアリング](https://about.gitlab.com/the-source/platform/driving-business-results-with-platform-engineering/)に投資して、開発チーム向けにベストプラクティスとコンポーネントを標準化することで、ソフトウェア開発を加速しようとする組織がますます増えています。ただし、デベロッパーエクスペリエンスだけに焦点を当ててプラットフォームエンジニアリングに取り組んでいるのであれば、本来取り組むべき重要な目標を見落としています。もちろんデベロッパーエクスペリエンスを向上させることは重要です。しかしながら、コードを効果的にデプロイ、設定、モニタリング、保守できるような運用成熟度に達していなければ、コード作成を効率化できたとしても意味がありません。\n\nそこでソフトウェアロジスティクスの出番です。ソフトウェアロジスティクスを最適化すれば、コードの開発速度が向上しても、デプロイのボトルネックや運用面での混乱が生じなくなり、実際のビジネス価値の創出に確実につながるようになります。\n\n## ソフトウェアロジスティクスの競争優位性\nソフトウェアロジスティクス戦略を効果的に立てると、次のようないくつかの重要な利点を得られます。\n- **デリバリーサイクルの短縮**：コード完成から本番環境へのデプロイまでにかかる時間が数週間から数日、さらには数時間に短縮されます。\n- **セキュリティ対策状況の改善**：セキュリティを最後のゲートとして実装せずに、開発パイプラインに組み込むことで、開発速度を維持しながら脆弱性を軽減できます。\n- **業務効率性の向上**：自動化とセルフサービス機能の活用により、限られた人数の運用スタッフでより多くのデベロッパーをサポートできるようになります。\n- **リソースの有効活用の推進**：貴重なデベロッパーが、複雑なデプロイ作業に煩わされることなく、ビジネス価値の創出に注力できるようになります。\n\n## 効果的なソフトウェアロジスティクスの実現に向けた最適化\nあらゆる規模の組織の技術リーダーと話をする中で、ソフトウェアロジスティクスの実装を成功させるには、いくつかの一貫したパターンがあることがわかりました。以下に、ソフトウェアロジスティクスを最適化するための3つのステップをご紹介します。\n\n### エンタープライズアプリケーションデリバリーフレームワークの構築\n最新のソフトウェアデリバリーにおいては、多様な環境、デプロイ戦略、および運用上の懸念事項に対処できる高度なオーケストレーションが求められます。効果的なフレームワークを構築するには、複数の環境間で相互依存するサービスのデプロイを調整する「**リリースオーケストレーション**」、自動検証によりロールアウトを制御するカナリアリリースや機能フラグのような「**段階的デリバリー戦略**」、セキュリティガードレールやコンプライアンス要件を適用しながらポリシーによって制御されたインターフェイスを介して基盤となるインフラを構築する「**プロビジョニングの自動化**」などの要素を含める必要があります。このフレームワークでは、各ステージで証明書を生成することで、デリバリープロセス全体の検証可能な記録をもたらし、リアルタイムでのリスク評価とコンプライアンス検証を実現します。\n\n### 統合データストアを備えたプラットフォームの採用\n優れた業績を上げている組織では、コードコミットから本番環境のパフォーマンスまで、デリバリーパイプライン全体をカバーする包括的なメトリクスが必要です。測定せずに、何かを管理することはできません。優れたチームは、開発速度から運用の安定性、セキュリティ対策状況まで、あらゆるものを測定対象としています。データファブリックを統合することで、効果的なソフトウェアロジスティクスの神経系統として機能し、ソフトウェアデリバリーライフサイクル全体にわたってそれまでサイロ化されていた情報が関連付けられ、インテリジェントな意思決定と自動化を実現できるようになります。\n\n### 「ゴールデンパイプライン」によるデベロッパーの自律性の向上\n根底にある複雑さをわかっていなくても、デベロッパーがデプロイプロセスを開始できる直感的なインターフェイスに適切なガードレールを組み込んで提供することで、運用チームの負担が軽減されるとともに、デリバリーサイクルが短縮されます。以前、あるプラットフォームエンジニアリングのリーダーも「私たちの仕事は、各チームが自分たちで実行できるように、プラットフォームを使いやすくすることです」とおっしゃっていました。\n\n## ソフトウェアロジスティクス：デジタルファーストに取り組む組織にとっての競争上の差別化要因\n競争圧力が高まる今、ソフトウェアをテストステージから本番環境に効率的に移行できる能力は、競争上の重要な差別化要因となります。ソフトウェアロジスティクスの考え方を取り入れることで、限られた人数の運用スタッフで開発チームを効果的にサポートできるようになり、セキュリティと信頼性を維持しながらイノベーションを加速できます。",[467,470,473,476,479,482],{"header":468,"content":469},"ソフトウェア開発におけるソフトウェアロジスティクスとは？","ソフトウェアロジスティクスとは、プロビジョニング、デプロイ、設定、モニタリング、保守など、コードのパッケージ化後に発生するプロセスを指します。つまり、ソフトウェアサプライチェーンの後半部分を指します。信頼性が高く、安全で、効率的な本番環境へのデリバリーを保証するプロセスです。",{"header":471,"content":472},"今、ソフトウェアロジスティクスの重要性が高まっている理由は？","生成AIの活用によってコードの開発速度が加速する中、作成されたコードを効率的にデプロイして保守しなければならないというプレッシャーが高まっています。限られた運用リソースの中で、ボトルネックの発生を防ぎ、開発速度を向上してビジネス価値を創出するには、ソフトウェアロジスティクスの効率化が不可欠です。",{"header":474,"content":475},"ソフトウェアロジスティクスがきちんと最適化されていないと、デリバリーサイクルにどのような影響が生じますか？","ソフトウェアロジスティクスが最適化されていない組織では、デプロイの遅延や一貫性のないオペレーションが発生し、運用チームが手一杯になったり、デベロッパーが運用業務をせざるを得なくなり、いずれにしても過度な負担がかかります。そうなると、イノベーションの速度に悪影響が生じ、運用リスクが高まります。",{"header":477,"content":478},"ソフトウェアロジスティクスにおいて「ゴールデンパイプライン」はどのような役割を果たしますか？","ゴールデンパイプラインは、デベロッパーが独自に使用できる、あらかじめ設定された自動デプロイワークフローを提供します。これらのパイプラインを活用することで、デベロッパーの自律性が向上し、さらにセキュリティとコンプライアンスのガードレールが組み込まれるため、運用チームへの依存度が軽減します。",{"header":480,"content":481},"統合データストアによって、どのようにソフトウェアロジスティクスを改善できますか？","統合データストアは、コードコミットから本番稼動まで、ソフトウェアデリバリーライフサイクル全体のメトリクスを結び付けます。これにより、リアルタイムでのインサイトの取得、パフォーマンスの追跡、自動化を行うことができ、組織はデリバリーに伴うリスクを制御し、最適な成果を得られます。",{"header":483,"content":484},"プラットフォームエンジニアリングにおいてロジスティクスに注力すべき理由は？","プラットフォームエンジニアリングにおける多くの取り組みは、デベロッパーエクスペリエンスの向上に重点を置いています。一方で、ロジスティクス面の取り組みは、コード開発速度の向上によって、実際にデプロイの効率化が実現されることを保証します。ロジスティクス能力がなければ、開発速度が向上してもビジネスアジリティを達成できません。","article","why-software-logistics-is-key-to-accelerating-innovation","content:ja-jp:the-source:platform:why-software-logistics-is-key-to-accelerating-innovation:index.yml","ja-jp/the-source/platform/why-software-logistics-is-key-to-accelerating-innovation/index.yml","ja-jp/the-source/platform/why-software-logistics-is-key-to-accelerating-innovation/index",{"_path":491,"_dir":26,"_draft":6,"_partial":6,"_locale":7,"config":492,"seo":494,"content":498,"type":485,"category":26,"slug":506,"_id":507,"_type":28,"title":495,"_source":29,"_file":508,"_stem":509,"_extension":32,"date":499,"description":496,"timeToRead":500,"heroImage":497,"keyTakeaways":501,"articleBody":505},"/ja-jp/the-source/platform/high-performing-development-teams-your-business-advantage",{"layout":5,"template":450,"articleType":451,"author":493,"featured":6,"gatedAsset":453,"isHighlighted":6,"authorName":419},"brian-wald",{"title":495,"description":496,"ogImage":497},"優れたパフォーマンスを発揮する開発チーム：ビジネス上の優位性","パフォーマンスの高いソフトウェア開発チームを構築すれば、納期が早まり、コード品質が向上し、イノベーションが推進されるため、主要なビジネス目標を達成できます。","https://res.cloudinary.com/about-gitlab-com/image/upload/v1751463980/zj2aimb3oznkxhkh9l2a.png",{"title":495,"date":499,"description":496,"timeToRead":500,"heroImage":497,"keyTakeaways":501,"articleBody":505},"2025-03-13","5分で読めます",[502,503,504],"優れたパフォーマンスを発揮するソフトウェアエンジニアリングチームは、組織における複雑な課題にうまく対処し、優先順位のバランスを取り、新しいテクノロジーに適応しながら、高品質のコードを作成することで、イノベーションを推進します。","自主性と当事者意識を持つチームは、より多くの価値を迅速に提供し、ビジネス目標に向けた歩みを加速し、イノベーションの最前線に立てるようにエンゲージメントを促進します。","パフォーマンスの高いチームは、ソフトウェアを開発するだけでなく、ベストプラクティスを広める素晴らしいお手本となります。結果として、組織全体でパフォーマンス基準が上がります。","常に競合他社の一歩先を行く組織と、追いつこうと苦戦している組織の違いは一体何でしょうか？ 大抵の場合、その答えは、技術や市場戦略ではなく、チームの能力にあります。\n\nどのようなソフトウェア組織においても、イノベーションと効率性の原動力となるのは、パフォーマンスの高いチームです。こういったチームは、複雑な企業構造の中でも効率的に業務を進め、高品質のソフトウェアを生み出すことで、優れたパフォーマンスを達成します。また、相反するニーズのバランスを取り、変化する技術に適応し、組織における多様かつ、しばしばサイロ化された部分にもうまく対応します。\n\nパフォーマンスの高いチームに、さらに多くの責任と自由を与えると、より短時間でより良い結果を達成し、組織目標の達成までの時間が短縮されます。当事者意識が高まることで、チームメンバーのエンゲージメントとモチベーションも向上し、大抵の場合、チームメンバーによってイノベーションが牽引され、新機能や新製品の開発が進みます。\n\nこのようなチームがもたらす利点は、開発されるソフトウェアだけにとどまりません。他のチームの模範となって、ベストプラクティスを共有し、組織全体のパフォーマンスを向上させます。\n\n## 優れたソフトウェアチームの育成\nパフォーマンスの高いチームは偶然できるものではなく、綿密な計画、強力なリーダーシップ、そして卓越性を重視するカルチャーを通じて構築されます。エンジニアリングリーダーは、以下に紹介する重要な戦略に従うことで、パフォーマンスの高いチームを育成できます。\n\n### 卓越したパフォーマンスを実現しているチームを特定する\n常にパフォーマンス基準を上回っている開発チームを特定し、そのチームのリーダーから、どのようにプロセスを改善したのかをヒアリングしましょう。そのチームとの関係を構築し、他のチームのお手本にできます。\n\n### 明確かつ達成可能なチーム目標を設定する\n組織のビジョンに沿った、明確かつ達成可能な目標を設定すれば、パフォーマンスの高いチームは、その達成に向けて前進します。目標には期限を設定し、具体的かつ測定・達成可能で、関連性がある内容でなければなりません。\n\n### チームに意思決定の権限を与える\n権限が与えられたチームは、柔軟性に優れ、適応力があります。ツールの選択、ワークフローの設計、優先順位付けなど、自分たちの業務に直接影響する意思決定プロセスをチーム内で管理できるようにしましょう。そうすれば、開発環境が効率化され、全体的なデベロッパーエクスペリエンスが大幅に向上します。\n\n### 心理的安全性と当事者意識を育む\n信頼は、パフォーマンスの高いチームの基盤です。また、チームメンバー間で強い信頼感を生み出すためには、率直なコミュニケーションも不可欠です。チームメンバーが安心してアイデアの共有やフィードバックの提供を行い、それぞれが責任を負えるような文化を育みましょう。定期的なチームミーティングやフィードバックセッションを開催すれば、チームでパフォーマンスを振り返り、改善策を見つけやすくなります。\n\n### 継続的な学習に投資する\n優れたパフォーマンスを発揮できるチームは、常に改善策を模索しています。継続的なトレーニング、認定、その他の学習リソースへのアクセスを提供して、チームメンバーの技術スキル向上を支援しましょう。これにより、スキルアップを望む経験豊富なデベロッパーを含め、チームメンバーに対し、キャリアアップのための貴重な機会を提供できます。\n\n### 協調的な職場環境を育む\n成功を収めるには、チーム内およびチーム間のコラボレーションが不可欠です。プロジェクト管理ツールやリアルタイムコミュニケーションプラットフォームを使用すると、チームワーク、ドキュメントの共有、プロジェクトの進捗状況の追跡を簡単に行えます。協調的な職場環境では、多様な視点がもたらされるため、複雑な問題を解決できます。また、人間の創造性と最新技術が組み合わさることでイノベーションが促進されます。現在、特に先見の明のあるチームは、生成AIツールを使用して、どのようにコラボレーションを強化し、[慎重かつ戦略的な方法で生産性を高められるか](https://about.gitlab.com/the-source/ai/devops-leaders-fix-this-productivity-blocker-before-adding-ai/#-thoughtfully-incorporate-ai-into-workflows)を検討しています。\n\n### 優れたパフォーマンスを認めて報いる\nパフォーマンスの高いチームは、努力が認められる環境において成長します。大小を問わず、功績を認めるシステムを確立しましょう。具体的には、正式な表彰プログラム、パフォーマンスに基づく賞与のほか、単に公の場で優れた成果を認めることなどが考えられます。卓越したパフォーマンスを認めることで、チームのモチベーションが高まり、成功につながる行動や習慣が促進されます。\n\n## パフォーマンスの高いチームが戦略的に不可欠な理由\n[調査によると](https://about.gitlab.com/developer-survey/)、DevSecOps プラットフォームの導入など、パフォーマンスの高いソフトウェアチームを構築するための対策を行った組織では、デベロッパーのオンボーディングの高速化や脆弱性の修正の効率化など、さまざまな利点を得ています。そして、そのすべてがビジネス上の競争優位性につながっています。\n\n戦略的価値は、目先の生産性向上にとどまりません。多様な視点を持つ機能横断型チームは、複雑な問題を解決するイノベーションを推進し、多くの場合、サイロ化されたアプローチでは見逃される新たな市場機会を特定できます。おそらく経営陣にとって最も説得力があるのは、乗数効果でしょう。パフォーマンスの高いエンジニアリングチームを1つ作るために投資すれば、チームの効果的な業務の進め方が組織全体のパフォーマンスを向上させるテンプレートとなり、スケール可能なフレームワークを確立できます。\n\n卓越したパフォーマンスを後押しし、適切なリソースが提供される企業文化は、パフォーマンスの高いソフトウェアチームを構築する基盤となります。チーム全体が共通の目標を持ち、それを達成するための自主性があれば、素晴らしい成果を達成できます。","high-performing-development-teams-your-business-advantage","content:ja-jp:the-source:platform:high-performing-development-teams-your-business-advantage:index.yml","ja-jp/the-source/platform/high-performing-development-teams-your-business-advantage/index.yml","ja-jp/the-source/platform/high-performing-development-teams-your-business-advantage/index",{"_path":511,"_dir":26,"_draft":6,"_partial":6,"_locale":7,"config":512,"seo":514,"content":518,"type":485,"category":26,"slug":547,"_id":548,"_type":28,"title":515,"_source":29,"_file":549,"_stem":550,"_extension":32,"date":519,"description":516,"timeToRead":500,"heroImage":517,"keyTakeaways":520,"articleBody":524,"faq":525},"/ja-jp/the-source/platform/from-toolchain-chaos-to-business-roi-a-5-step-roadmap",{"layout":5,"template":450,"articleType":451,"author":493,"featured":331,"gatedAsset":513,"isHighlighted":6,"authorName":419},"transform-your-software-development",{"title":515,"description":516,"ogImage":517},"ツールチェーンの混乱からビジネスの成果へ：5つのステップで導くロードマップ","ツール、プロセス、運用方法を標準化し、ビジネス全体の目標に向けてすべてのチームの足並みを揃えることで、複雑性を削減しましょう。","https://res.cloudinary.com/about-gitlab-com/image/upload/v1751463923/joqzi3uwfbqptjynlkbs.jpg",{"title":515,"date":519,"description":516,"timeToRead":500,"heroImage":517,"keyTakeaways":520,"articleBody":524,"faq":525},"2025-03-11",[521,522,523],"ソフトウェア開発プラットフォームを標準化することで、運用コストを削減し、同時にデリバリースピードとセキュリティを向上させ、テクノロジーをコスト要因から競争優位に変えられます。","評価、基準の設定、AIの活用、システムの集約、およびトレーニングで構成される5段階の標準化プロセスを通じて、技術的負債を回避しつつ、持続的なイノベーションを実現するためのフレームワークを構築できます。","一体型の開発プラットフォームは、オペレーションを効率化するだけでなく、市場への迅速な対応、より的確な意思決定、将来を見据えたテクノロジー投資も可能にします。","企業が成長するにつれて、チームはソフトウェアのデリバリーを急ぎ、その結果、さまざまなソフトウェア開発ツールや手法が混在する状況になりがちです。各チームが短期的解決のために各自でソリューションを開発することもあり、[混乱した作業環境](https://about.gitlab.com/the-source/platform/devops-teams-want-to-shake-off-diy-toolchains-a-platform-is-the-answer/)が生まれることもあります。隠れたコストはすぐに蓄積していきます。重複するツールのライセンス費用、増加する保守作業、非一貫な実践によるセキュリティの脆弱性、異なるシステム間の統合課題に費やされる膨大な時間。これらは単なる非効率ではなく、組織の収益に直接影響を与える可能性があります。\n\n[標準化された開発プラットフォーム](https://about.gitlab.com/the-source/platform/driving-business-results-with-platform-engineering/)によって、こうした非効率は排除されます。すべてのソフトウェア開発チームが一貫したツールとプロセスで作業できる統一されたワークスペースを構築することで、技術投資をより広範なビジネス目標と整合させることができます。その結果として、コスト削減、提供スピードの向上、セキュリティの改善、そして明確な競争優位性が実現します。## 標準化された開発プラットフォームのメリット\n**コストを削減**：標準化されたプラットフォームを運用することで、大幅なコスト削減が可能です。多数の個別ツールを使う代わりに1つのシステムを使用することで、ライセンス費用、保守作業、異なるシステムの連携にかかるコストを削減できます。また、外部ベンダーへの依存度が下がり、チームに対して複数のツールをトレーニングする手間と時間も削減されます。\n\n**より迅速にリリース**：集中型プラットフォームにより、開発プロセス全体のスピードが向上します。ツールとワークフローを統合してプロセスを効率化することで、多数の異なるツールを使用している際に発生する遅延を解消できます。\n\n**セキュリティとコンプライアンスを向上**：プラットフォーム全体に一貫したセキュリティ対策を適用することで、セキュリティの脆弱性を低減し、規制遵守を容易にします。\n\n**より良いインサイトを得る**：プラットフォームアプローチにより、ソフトウェア開発ライフサイクル全体に関する正確で信頼性の高いデータを取得できます。これにより、チームのワークフローが改善され、データ主導の意思決定が可能となり、ビジネスの成長を支援します。\n\n**将来への備え**：最後に、標準化されたソフトウェア開発のアプローチは、将来的な成長や変化への適応を可能にします。組織が拡大しても、このフレームワークがあれば、チームは混乱なくスムーズに拡大できます。\n\n> もっと詳しく：[デベロッパーのオンボーディングを加速させる方法と、それが重要な理由](https://about.gitlab.com/the-source/platform/how-to-accelerate-developer-onboarding-and-why-it-matters/)\n\n## 標準化されたソフトウェア開発プラットフォームを構築するための5つのステップ\nほとんどの企業にとって、標準化されたソフトウェアプラットフォームを構築することは可能です。ただし、それには慎重な計画が必要です。リーダーたちは、以下の5つのステップを通じて、ツールとワークフローを効果的に標準化できます。\n\n### 1. 現在のツールを評価する\nまず、現在使用しているツールやプロセスをしっかりと見直しましょう。このレビューには、デベロッパー、セキュリティの専門家、[プラットフォームエンジニアリングチーム](https://about.gitlab.com/the-source/platform/driving-business-results-with-platform-engineering/)など、すべての関係者からのフィードバックを含めるべきです。目的は、ツールの重複や連携できていない部分を特定し、顧客のためのソフトウェア開発プロセスを改善する方法を見つけることです。\n\n### 2. 明確な基準と目標を設定する\nレビュー結果をもとに、社内での基準やベストプラクティスを定めます。これには、コーディングルール、デプロイパイプライン、セキュリティポリシーを含めることが重要です。これらの基準が自社の主要なビジネス目標を支援し、すべてのチームが簡単に従えるようにしましょう。またこの段階で、何を達成したいのか（たとえばチームワークの向上、コスト削減、スケーラビリティの強化など）を明確にすることも重要です。### 3. AIを活用してよりスマートに作業する\nAIツールは、現代のソフトウェア開発において重要な存在になりつつあります。AIを使ってルーチン作業を自動化することで、デベロッパーはより戦略的な業務に集中できます。さらに、AIは開発全体を通じてコードをチェックし、本番環境に移行する前に問題を早期に発見することで、セキュリティも向上させることができます。\n\n### 4. 中央集約型システムを構築する\n基準が定まったら、それらを保管・共有する場所が必要です。集中型のプラットフォームを構築すれば、すべてのドキュメント、コード、プロジェクト管理ツールを１か所に集約できます。すべてが揃っていることで、全員が同じ基準に従って作業できるようになり、摩擦が減り、コラボレーションが向上します。\n\n### 5. トレーニングに投資する\n標準化が機能するには、チームがその基準を理解し、運用できることが前提です。プロセス全体をカバーする包括的なトレーニングプログラムに投資しましょう。継続的な教育により、さまざまなプログラミング言語やプラクティス、テクノロジーに関する最新の知識をチームが保ち続けることができます。\n\n## ソフトウェア開発プラットフォームの標準化によるROI\nソフトウェア開発プラットフォームの標準化への移行は、単なる技術的な改善ではなく、測定可能な成果をもたらす戦略的なビジネス投資です。このアプローチをうまく導入した組織では、最大で[483%の投資収益率（ROI）](https://about.gitlab.com/resources/study-forrester-tei-gitlab-ultimate/)、デベロッパーの生産性が400%向上、そしてソフトウェアツールチェーンのコストを25%削減するなどの成果が報告されています。これにより、一体型の、アジリティとセキュリティに優れたソフトウェア開発ライフサイクルが実現し、技術的負債も抑えられます。\n\nこの変革を検討するうえで忘れてはならないのは、現状維持こそが最もコストのかかる選択肢となることが少なくないという点です。ソフトウェアの能力が競争力を左右するようになってきている現在、「開発プラットフォームを標準化する余裕があるかどうか」ではなく、「標準化せずに市場で生き残れるのかどうか」が問われているのです。まずは自社の現在の環境を丁寧に評価することから始め、明確な目標を中心にステークホルダーの合意を形成し、単なる技術的なプロジェクトとしてではなく、戦略的な課題として取り組むべきです。",[526,529,532,535,538,541,544],{"header":527,"content":528},"標準化されたソフトウェア開発プラットフォームとは？","標準化されたソフトウェア開発プラットフォームとは、あらゆるツール、ワークフロー、プロセスをひとつの統一された環境にまとめるものです。この仕組みによってチーム間の分断が解消され、業務の一貫性が促進され、ツールの重複も減り、部署を超えたコラボレーションが可能になります。さらに、開発の取り組みを全社的なビジネス目標と整合させることもできます。",{"header":530,"content":531},"企業が規模を拡大するにつれて、ツールチェーンの混乱に直面するのはなぜですか？","組織が成長するにつれて、さまざまなチームが独自のツールやカスタムワークフローを導入して、目の前の問題を解決することが増えていきます。その結果、ツールの重複やプロセスの不一致、連携の問題が発生し、効率の低下を招くだけでなく、コストの増加やセキュリティリスクの上昇にもつながります。",{"header":533,"content":534},"プラットフォームの標準化によるビジネス上のメリットとは？","開発ツールやプロセスを標準化することで、ソフトウェアのライセンス費用や連携コストを削減できるほか、納期の短縮、セキュリティ対策状況の強化、コンプライアンス対応の簡素化などのメリットが得られます。また、管理体制とビジネス目標との整合性を維持しながら、開発運用をスケールしやすくなります。",{"header":536,"content":537},"プラットフォームの標準化により、デベロッパーの生産性はどのように向上しますか？","重複したツールを排除し、ワークフローを効率化することで、デベロッパーは頭を切り替えたり、連携トラブルの解決に費やす時間を減らすことができます。一元化されたプラットフォームは、セルフサービスや一貫したプロセスを支える仕組みをサポートし、デベロッパーはより多くの時間をイノベーションや価値創出に注げるようになります。",{"header":539,"content":540},"AIはプラットフォームの標準化を強化できますか？","はい、できます。AIは、繰り返しタスクの自動化、リアルタイムのコードスキャンによるセキュリティ向上、そしてソフトウェアライフサイクル全体にわたるインテリジェントなインサイトの提供によって、標準化の促進に貢献します。これにより、運用負荷が軽減され、開発速度を向上させつつ、標準化されたプロセスに従って作業できるようになります。",{"header":542,"content":543},"プラットフォームの標準化を始めるために、企業はどのようなステップを踏むべきですか？","まずは、現在使用しているツールを評価し、重複するものを特定する必要があります。そこから、社内における明確な標準を定め、それを徹底するために一元化されたプラットフォームを導入します。さらに、チーム全体で一貫して活用できるよう、トレーニングプログラムに投資することも重要です。",{"header":545,"content":546},"開発ツールの標準化は、大企業のみが行うべきですか？","いいえ。規模にかかわらず、どの組織にとっても開発プラットフォームの標準化にはメリットがあります。実際のところ、ツール構成が比較的シンプルで導入も迅速に行える中小企業の方が早く効果を実感できる場合もあります。長期的には、このアプローチが組織の成長を支え、大規模化に伴う技術的負債の削減にもつながります。","from-toolchain-chaos-to-business-roi-a-5-step-roadmap","content:ja-jp:the-source:platform:from-toolchain-chaos-to-business-roi-a-5-step-roadmap:index.yml","ja-jp/the-source/platform/from-toolchain-chaos-to-business-roi-a-5-step-roadmap/index.yml","ja-jp/the-source/platform/from-toolchain-chaos-to-business-roi-a-5-step-roadmap/index",{"_path":552,"_dir":26,"_draft":6,"_partial":6,"_locale":7,"config":553,"seo":556,"content":560,"type":485,"category":26,"slug":567,"_id":568,"_type":28,"title":557,"_source":29,"_file":569,"_stem":570,"_extension":32,"date":561,"description":558,"timeToRead":500,"heroImage":559,"keyTakeaways":562,"articleBody":566},"/ja-jp/the-source/platform/why-your-development-team-should-plan-small-to-deliver-big",{"layout":5,"template":450,"articleType":451,"author":554,"featured":6,"gatedAsset":555,"isHighlighted":6,"authorName":415},"amanda-rueda","source-lp-navigating-a-smooth-transition-to-agile-planning",{"title":557,"description":558,"ogImage":559},"開発チームが大きな成果を成し遂げるためには、小規模な計画を立てるべき理由","四半期ごとの製品計画を戦略的に立てることで、長期的な目標に向けて有意義な進展を促進し、組織の成功を最大化する方法をご紹介します。","https://res.cloudinary.com/about-gitlab-com/image/upload/v1751464024/paqecyxpszplzdwohg9d.png",{"title":557,"date":561,"description":558,"timeToRead":500,"heroImage":559,"keyTakeaways":562,"articleBody":566},"2025-01-22",[563,564,565],"組織の目標を達成するためには、戦略的な四半期計画を立てることが不可欠です。これにより、リソースを調整し、大きな影響を及ぼす仕事にチームを集中させ、長期的な目標に向けて有意義な進展を促進できます。","四半期計画を成功させるには、目標を会社のビジョンと一致させること、多様なインサイトを採り入れること、大規模なプロジェクトを小さな単位に分割することに加え、実施内容を長期的な成功メトリクスに継続的に結び付ける必要があります。","効果的に計画を立てるには、目標と整合性を取るための方針管理フレームワークの採用、漸進的なプランニングの奨励、早期段階でのチームの関与により得られる効果の活用、顧客からのフィードバックの重視、適切なメトリクスによる成功の測定を行うことが必要です。","_達成可能だと思う規模よりも小規模な計画を立てましょう。_\n\nこの直感に反するようなアドバイスは、意欲的な目標設定に関してご存知のことすべてと相反するように聞こえるかもしれません。しかしながら、ソフトウェア開発のロードマップを計画する際にこの原則を守ることで、多くの場合、より大きな成功を達成できます。なぜでしょうか？効果的な四半期計画とは、機能や技術目標をできるだけ詰め込んだものではなく、日々実施するエンジニアリング作業を長期的な製品ビジョンに戦略的に結び付けるものだからです。\n\n組織が四半期ごとの計画を単に定期的に行う作業ではなく、前進に向けた強力な原動力とみなすことで、野心的な目標を達成可能なステップへと細分化し、実践内容を会社のビジョンと結び付け、顧客のフィードバックをすべての意思決定の中核に置くという、実証されたアプローチを取ることができます。\n\n## 真に戦略的な四半期計画を行うには？\n四半期計画の目的は、単に今後数か月間の目標や優先事項を決めることではありません。それらの目標や優先順位を、組織における全体的なビジョンや戦略と一致させることが重要です。四半期計画は、会社の長期的な目標と、各チームの仕事がその目標にどのように貢献するかを明確に理解した上で実施すべきです。そのためには、戦略的な四半期計画は以下の条件を満たすものでなければなりません。\n\n- 日々のタスクを、影響の大きいビジネス成果に結び付ける\n- 大規模なプロジェクトを、それぞれ価値をもたらす小さな単位に分割する\n- 多様な専門知識を持つチームによるインサイトを採り入れる\n- 実際のユーザーや顧客のニーズに根ざした内容である\n- 日々の作業と長期的な成功メトリクスを結び付ける\n\nこのようなアプローチを取ることで、進捗状況の追跡、変化へのダイナミックな対応、会社のビジョンに沿った成功を実現しやすくなります。**四半期計画のサイクルを正しく行えた場合、チームは明確な成果と成果物（明確に定義された目標、優先順位付けされたロードマップ、割り当て済みのタスク、成功に向け合意済みのメトリクスなど）を定義できているはずです。**それでは、成果をもたらし、チームのモチベーションと連携を保つ戦略的な四半期計画を立てて、実施する方法について見ていきましょう。\n\n## 四半期計画を成功させるためのヒント\nこれまで各業界のリーダーや同業者と話し合う中で、組織の規模を問わず、四半期計画のプロセスにおいて最大限の可能性を引き出すのに役立つ、いくつかの重要な実践方法が明らかになりました。\n\n### 四半期ごとの目標を全体的なビジョンと合わせる\nプロダクトマネジャー（PM）との会話で頻繁に出てくるテーマは、四半期ごとの目標をより広範な会社の目標に結び付ける必要性です。自分の業務が全体像においてどこに位置するかを把握できれば、もっとも重要な作業に優先順位を付けやすくなります。あるPMは_「四半期計画の目的は、単に何かを成し遂げることではなく、引き続き正しい方向に向かっているかどうかを確認することです」と述べました。_\n\nそのために役立つのが_[方針管理](https://www.leanproduction.com/hoshin-kanri/)_フレームワークです。日本の経営手法から生まれた方針管理は、組織のあらゆる部分が会社のもっとも重要な目標と合致していることを保証します。大局的な目標を実行可能かつ測定できるステップに分解し、それをチーム間で連鎖させます。このフレームワークは日々のタスクを戦略的な成果に結び付けることで、チームメンバー全員に明確な目的意識を与え、各メンバーの業務がどのように組織の成功に貢献するかを理解できるようにします。\n\n_**プロによるアドバイス**：会社の[OKR（Objective and Key Results）](https://docs.gitlab.com/ee/user/okrs.html)を製品ロードマップと結び付けるプラットフォームを活用しましょう。チーム間で足並みをそろえて集中力を高め、開発タスクと大局的な目標とのつながりをツール内で直接明確にできる効果的な方法です。_\n\n### 小規模な計画によって多くのことを達成する：イテレーションの技術\n先程お伝えした「小規模な計画を立てる」という、直感に反するようなアドバイスを思い出してください。なぜこの方法だとうまくいくのでしょうか？仕事というのは、必ず想定よりも拡大するものです。どんなに綿密に四半期計画を立てたとしても、すべての課題や機会、優先順位の変化を予測することは不可能です。だからこそ、小規模な計画を立てることで大きな結果を得られます。チームが成功するためには、リーダーは漸進的なプランニングを奨励する文化を推進する必要があります。チームが、達成できないことを恐れることなく、野心的な目標を達成可能な小さなステップに分解し、[反復的に](https://handbook.gitlab.com/handbook/values/#iteration)考えられるようにすることで、学ぼうという心構えと迅速なフィードバックに適応する姿勢が育まれます。\n\n_[バーティカルスライス](https://careers.webjet.com.au/category/agile/)_を行って、プロジェクトをエンドツーエンドの価値を提供する小さな断片に細分化することをおすすめします。たとえば、チームにおいて製品メトリクスを追跡するためにダッシュボードを構築しているとします。その場合、各イテレーションにおいて、ユーザーへの価値を提供する小さなバーティカルスライスが提供されるように計画を最適化します。\n\n1. データパイプラインを構築して、ユーザーエンゲージメントのような主要メトリクスを1つ収集して表示する\n1. データのフィルタリングと並べ替えの機能を追加する\n1. 経時的なトレンドの可視化機能を導入する\n1. ユーザーからのフィードバックをもとにしたカスタムオプションによってダッシュボードを拡張する\n\nこのように機能を追加していくことで、全体的な目標を見失うことなく、小規模なレビュー、早い段階でのテスト、より迅速なフィードバックの獲得、小さな単位での価値の提供を実現できます。\n\n_**プロによるアドバイス**：ご利用のツールのネストされた作業アイテムフレームワークを使用すると、明確なワークストリームを作成できるだけでなく、進捗状況を効率的に追跡できます。たとえばGitLabの場合は、エピックやイシュー、タスクを使用して、包括的な目標との整合性を維持できます。_\n\n### 早い段階でチーム全体を巻き込む\nプロセスの早期段階で関係者を巻き込まずに、単独で計画を立てることは、計画サイクルにおいてお客様がよく陥りがちな間違いです。エンジニア、デザイナー、その他の主要な関係者から独自のインサイトを収集することで、より優れたソリューションを構築し、後で驚かされるような事態を防止できます。\n\n[専門家](https://www.producttalk.org/2024/06/product-trios/)によると、さまざまな専門知識を持つメンバーがいるチームでは、革新的なアイデアが生まれやすいそうです。エンジニアは技術的な制約や機会を早い段階で見つけられます。また、デザイナーは意思決定を行う際に、ユーザーエクスペリエンスを中心に考えるよう喚起してくれます。早期にコラボレーションすることで、下流工程での摩擦が減り、解決すべき問題にチームが注力でき、納期が早まります。\n\n_**プロによるアドバイス**：リアルタイムの可視性を備えた単一のエンドツーエンドのソフトウェア開発プラットフォームを使用すれば、効果的にコラボレーションし、最初から整合性が確保され、他部門と連携が取れた状態で意思決定を行うことができます。_\n\n### 顧客からのフィードバックを中心に計画を立てる\n顧客の声に耳を傾けなければ、仮定に基づいて計画を立てるということになります。定期的に顧客と関わっているプロダクトオーナーは、本当に重要なことをもっとも把握している立場にいるため、計画における決定事項が実際のユーザーニーズに基づいているかどうかを確認できます。\n\nここで活用できるのが、もう1つの重要な計画手法である_[デュアルトラックアジャイル](https://medium.com/@daviddenham07/dual-track-agile-the-secret-sauce-to-outcome-based-development-601f6003ea73)_です。この手法では、製品開発を並行した2つのトラックに分割します。\n\n- **ディスカバリー**：インサイトを収集してアイデアを検証し、可能性のあるソリューションを模索する\n- **デリバリー**：検証済みのソリューションを構築し、出荷する\n\nデュアルトラックアジャイルを採り入れると、チームはプロセスを止めたり遅らせたりすることなく、ユーザーや顧客からのインサイトを収集することに注力できます。たとえば、あるチームが顧客にインタビューしてアイデアをもとにプロトタイプを構築している間に、別のチームが検証済みのニーズに基づいて機能の開発に取り組めます。これにより、チームは常に適切な問題に取り組みつつ、安定したケイデンスでデリバリーできます。\n\n_**プロによるアドバイス**：[ワークストリーム全体でのシームレスなコラボレーション、優先順位付け、インサイトの共有](https://about.gitlab.com/ja-jp/solutions/visibility-measurement/)をサポートするツールを使用すれば、顧客からのフィードバックをもとにあらゆる意思決定を行い、ユーザーニーズとビジネス目標に沿って作業を進められます。_\n\n### 適切なメトリクスを使用して成功を測定する\nメトリクスは単なる数値ではなく、四半期ごとの目標が会社の戦略的目標とどれだけ緊密に合致しているかを把握するためのものです。\n\n開発チームにとって、_[DORAメトリクス](https://about.gitlab.com/ja-jp/solutions/value-stream-management/dora/)_を使用することで、効率性と信頼性に関する強力なインサイトを得られます。チームはボトルネックを特定してワークフローを改善し、予定していたスケジュールどおりに納品できます。これらの運用メトリクスを顧客満足度や機能のアドプションなどのビジネスメトリクスと組み合わせれば、日々の作業内容と長期的な成功を関連付けられます。信頼性の高い測定方法を採用することで、四半期中に軌道修正しやすくなり、レトロスペクティブプロセスを行う際の判断材料となります。何がうまくいき、何がうまくいかなかったのかを振り返ることで、四半期計画のアプローチを継続的に改善し、戦略的な目標に注力し続けられます。\n\n_**プロによるアドバイス**：DORAメトリクスやその他のバリューストリーム分析を[包括的なインサイトダッシュボード](https://about.gitlab.com/blog/data-driven-devsecops-exploring-gitlab-insights-dashboards/)に表示すれば、カスタマイズ可能なデータドリブンのビューで、アイデアを実現するためにかかる時間を簡単に追跡できます。_\n\n## まとめ：最適な四半期計画を立てよう\n四半期計画は、単にタスクの整理や期限の順守をするためのものではありません。チームの取り組みを会社のもっとも戦略的な目標と合致させるためのものです。\n\n目標を全体的なビジョンに結び付け、顧客から得たインサイトを採り入れ、コラボレーションの文化を育むことで、四半期ごとの目標を達成できるようになり、長期的な成長と成功が促進されます。","why-your-development-team-should-plan-small-to-deliver-big","content:ja-jp:the-source:platform:why-your-development-team-should-plan-small-to-deliver-big:index.yml","ja-jp/the-source/platform/why-your-development-team-should-plan-small-to-deliver-big/index.yml","ja-jp/the-source/platform/why-your-development-team-should-plan-small-to-deliver-big/index",{"_path":572,"_dir":26,"_draft":6,"_partial":6,"_locale":7,"config":573,"seo":576,"content":580,"type":485,"category":26,"slug":604,"_id":605,"_type":28,"title":577,"_source":29,"_file":606,"_stem":607,"_extension":32,"date":581,"description":578,"timeToRead":582,"heroImage":579,"keyTakeaways":583,"articleBody":587,"faq":588},"/ja-jp/the-source/platform/optimize-value-stream-efficiency-to-do-more-with-less-faster",{"layout":5,"template":450,"articleType":451,"author":574,"featured":6,"gatedAsset":575,"isHighlighted":6,"authorName":443},"stephen-walters","source-lp-dora-insights-where-is-ai-really-driving-developer-productivity",{"title":577,"description":578,"ogImage":579},"バリューストリームの効率を最適化して、より少ないリソースでより多くのことを迅速に成し遂げる","バリューストリーム管理によってソフトウェアデリバリープロセスを最適化し、業務効率性を高める方法についてご紹介します。","https://res.cloudinary.com/about-gitlab-com/image/upload/v1751463530/doerc0wzbg75r8yixgnf.png",{"title":577,"date":581,"description":578,"timeToRead":582,"heroImage":579,"keyTakeaways":583,"articleBody":587,"faq":588},"2024-12-18","6分で読めます",[584,585,586],"バリューストリーム管理を効果的に行うことで、ビジネスの市場投入までの時間の短縮、プロセスの可視性および顧客体験の向上を実現できます。","バリューストリーム管理の主要なメトリクスには、「バリューストリーム分析のフローメトリクス」と「バリュー実現メトリクス」の2種類があります。前者はソフトウェアデリバリーにおけるボトルネックの特定に役立ち、後者はデリバリーされたものを測定します。","ソフトウェア開発ライフサイクル全体に統合プラットフォームを導入することで、ペルソナや製品全体が包括的に可視化されるため、ビジネスのスピードと市場での競争力が高まります。","イノベーションの速度はソフトウェアによって決まります。そのため、あらゆる組織が同じ課題に直面しています。つまり、より少ないコストで、より安全なコードをより迅速に提供する必要に迫られています。競合他社に勝ってマーケットリーダーとなれるかの境界線は急速に変化しており、今やこのデジタルトランスフォーメーションの取り組みを成功させられるかどうかが鍵となりつつあります。そのため、組織はソフトウェアの開発、保護、デプロイの仕方を根本的に見直す必要があります。\n\nその答えとなるのが、バリューストリーム管理です。実績のあるアプローチであるバリューストリーム管理は、市場投入までの時間を短縮し、ハンドオフやフィードバックループの断絶などのよくある障壁を取り除き、高品質な顧客体験を提供するために必要な可視性をリーダーに提供します。\n\n## バリューストリーム管理を行うべき理由\nこの1年間、エグゼクティブラウンドテーブルに10回以上参加し、世界各地の多数の顧客と話をし、[DevOps Institute](https://www.devopsinstitute.com/)や[Value Stream Management Consortium](https://www.vsmconsortium.org/)などの団体の意見やアドバイスに耳を傾けてきました。\n\nデジタルトランスフォーメーションの目標について業界のリーダーと話し合う中で、共通のテーマがあることに気づきました。誰もが、ソフトウェア企業になることだけに留まらず、優れたパフォーマンスを発揮できるようにならなければならない、と認識していたのです。\n\nビジネス目標とIT業務の整合性を取り、ソフトウェアデリバリープロセスを高速化し、ソフトウェア品質を向上させることは容易ではありません。しかしながら組織は、次の4つの重要な原則に従うことで、デジタルトランスフォーメーションの取り組みを推進し、より少ないリソースでより多くのビジネス価値を生み出すことが可能です。\n\n1. **デベロッパーの生産性を高める**：デベロッパーエクスペリエンスを向上させれば、技術者をより効果的に雇用・維持できるようになり、デベロッパーの生産性も高まります。結果的に、高品質なソフトウェアをより迅速にリリースできるようになります。\n2. **生産性と効率性を測定する**：ソフトウェアデリバリーライフサイクル全体にわたる影響を測定して、業務効率性を改善しましょう。\n3. **ソフトウェアサプライチェーンを保護する**：セキュリティとコンプライアンス上のリスクを軽減しましょう。\n4. **クラウドへの移行を推進する**：リスクを最小限に抑えるために適切なセキュリティ管理を行いつつ、クラウドへの移行を進めましょう。\n\nこれらの原則をうまく取り入れるには、人材、プロセス、テクノロジーをつなげる体系的なアプローチが不可欠です。バリューストリーム管理はそのためのフレームワークとして機能し、ソフトウェアのデリバリー方法を体系的に変革するのに役立つ、実績あるロードマップを組織に提供します。Value Stream Management Consortiumは、9つのステージ（開始、評価、ビジョン、特定、整理、マッピング、接続、調査、適応）からなる導入パスを策定しました。\n\n## バリューストリーム管理の導入\nロードマップの初期段階での重要なステップは、**ビジョン**を定義することです。これにより、バリューストリームを調査する際のパラメータが決まります。ここで重要なのは、ビジネス上の成果に基づいてビジョンを定義することです。たとえば、ある組織のビジョンが、新製品をいち早く市場に投入することであれば、デリバリースピードが重要な要素となります。しかし、顧客満足度やサービスの信頼性がもっとも重要な要素であれば、品質に関するメトリクスが最優先事項になります。\n\nビジョンを特定したら、ロードマップの残りのステップで、そのビジョンを実現するために必要な人材、プロセス、テクノロジーがそろっていることを確認します。\n\n* **特定**および**整理**は、人材に関するステージです。組織は、[バリューストリーム参照アーキテクチャ](https://skilupit.thinkific.com/courses/value-stream-reference-architecture-paper)を用いて、これらのステージの人材に関する側面を視覚的に表現する必要があります。\n* **マッピング**ステージでは、リーンなプロセスで効率的に適切な人材を集めます。バリューストリームマッピングを行うことで、ワークフローが可視化されるだけでなく、ムダな箇所や継続的な改善が必要な箇所が明らかになります。\n* **接続**ステージでは、プロセスを自動化し、機能横断型チームのオペレーションを簡素化するテクノロジーを使えるようにすることで、認知負荷の軽減、品質とセキュリティの向上、より迅速な価値提供の実現を目指します。\n* 最後に、組織はソフトウェアのバリューストリームを**調査**して**適応**させることで、継続的かつリアルタイムに最適化を行えるようになります。\n\nこのロードマップによって、人材とテクノロジーがつながり、誰もがテクノロジーを効果的に活用できるようになります。また、[バリューストリームディスカバリ](#putting-value-stream-discovery-to-work)も、デベロッパーエクスペリエンスとユーザーエクスペリエンスを向上させるように戦略的に設計されたワークフローに、各メンバーとチームをマッピングする上で重要な役割を担います。\n\n実装を成功させるには、プラットフォームアプローチが不可欠です。Gartner社の『[Market Guide for DevOps Value Stream Delivery Platforms](https://www.gartner.com/en/documents/3991050)』によると、バリューストリーム提供プラットフォームには、ソフトウェアの継続的デリバリーを行うために必要な機能がすべて備わっています。これらの機能には、計画、バージョン管理、継続的インテグレーション、テストの自動化、リリースオーケストレーション、継続的デプロイとロールバックモニタリング、セキュリティテスト、バリューストリームメトリクスの分析などが含まれます。バリューストリーム提供プラットフォームは、インフラストラクチャおよびコンプライアンスの自動化ツールと統合可能であるため、インフラストラクチャのデプロイとポリシーの適用を自動化できます。\n\n## バリューストリームメトリクスを使用した成功の測定\nバリューストリーム管理では、「フロー」と「実現」という2種類のメトリクスを使用します。\n\nバリューストリーム分析のフローメトリクスは、アイデア出しから実現まで、どのようにソフトウェアデリバリーを行うかを定義します。このメトリクスの測定対象は、ビジネス価値の流れ（フロー）です。ソフトウェアがバリューストリーム全体を進んでいく際の効率性、品質、スピードに関するインサイトを得られます。フローメトリクスを理解することで、ボトルネックと改善すべき領域を特定できます。\n\nDORAメトリクスはフローメトリクスのサブセットであり、パフォーマンスを定量的に測定します。以下がその一例です。\n\n1. **デプロイ頻度**：組織による本番環境へのコードのデプロイ頻度。デプロイ頻度が高いほど、開発チームがより迅速に変更をリリースできることを示し、ソフトウェア開発プロセスがよりアジャイルで効率的であることがわかります。\n2. **変更のリード時間**：コードの変更がコミットされてからデプロイされるまでの時間。リードタイムが短いほど、チームがアイデアに基づき効率的にデプロイを行えていることを意味します。そのため、機能のリリースや顧客の要望への対応をすばやく行えます。\n3. **サービス復旧時間**：サービス障害から復旧し、正常なオペレーションを復元するのにかかる時間。サービス復旧時間が短いほど、システムの回復力が高く、有能な対応チームであることを示しており、ダウンタイムが最小限に抑えられ、ユーザーエクスペリエンスも向上します。\n4. **変更失敗率**：インシデントやバグ、ロールバックを必要とする変更など、サービスの低下をもたらす変更の割合。変更失敗率が下がった場合、コード変更の品質が向上したことを意味し、開発プロセスに対する信頼度が高まります。\n\nこれらのメトリクスをイシュー解決リードタイムやサイクルタイム、新規イシュー、デプロイなどのメトリクスと組み合わせて分析することで、包括的なアプローチでバリューストリームの効率性を把握できます。ソフトウェア開発ライフサイクル全体で改善すべき箇所を特定するには、このようなさまざまなメトリクスをうまく組み合わせて活用することが重要です。\n\n一方、バリュー実現メトリクスの測定対象は、デリバリーの取り組みの具体的な成果です。収益や売上、利益率のような従来のメトリクスからは財務関連のインサイトを得られますが、ネットプロモータースコアやカスタマージャーニータイムのような他の重要なメトリクスからもまた、実現された価値の重要な側面を把握できます。これらの遅延メトリクスには過去のパフォーマンスが反映される一方、訪問者トラフィック、顧客レビュー、コンバージョン率などの先行メトリクスからは、今後の成功の予測に役立つ貴重な情報を得られます。\n\n## バリューストリームディスカバリの実践\nバリューストリームディスカバリでは、メトリクスと調査を組み合わせます。このプロセスでは、テクノロジーバリューストリーム（アイデアや要件をもとにデプロイおよび顧客価値の創出にいたるまでに必要な時間とリソースの量）の観点から、組織の現状と今後目指す状態を調べます。また、バリューストリームディスカバリを通じて、ソフトウェアデリバリーのパフォーマンスの進捗状況を測定し、プロセスにおいて顧客やビジネスに付加価値をもたらさないタッチポイントを見極めるためのベースラインを確立します。組織はバリューストリームディスカバリの結果をもとに、より簡単にリーンな構成のDevSecOpsツールチェーンを構築できます。\n\nデベロッパーと顧客のニーズに応えながら理想の未来を実現するためには、統合プラットフォームが不可欠です。このように体系的なアプローチを取ることで、効果的にバリューストリームの調査を行う上で不可欠な透明性が促進されるため、現状の評価・理解にメトリクスを使用することの重要性がよくわかります。プロセスやペルソナ、ツール、やり取り、測定値を包括的にマッピングして単一のビューにまとめるためには、バリューストリームディスカバリの実施が不可欠です。\n\n## イノベーションの速度はソフトウェアによって決まる\nソフトウェア開発においてバリューストリームを調査する理由を考えてみれば、組織が何をどのように提供するかを理解するためには、可視性が鍵となることは明らかです。適切なメトリクスを導入することで、組織はソフトウェアデリバリーがどのように進んでいるか、どこがボトルネックや非効率な箇所なのか、そして継続的に改善するためにどのように調整すればよいのかを確実に把握できます。一体型のDevSecOpsプラットフォームとバリューストリームディスカバリテクニックを一緒に導入することで、継続的にデリバリープロセスの改善および強化を行えるようになります。これにより、イノベーションが加速し、長期的な成功への道が開かれるでしょう。",[589,592,595,598,601],{"header":590,"content":591},"バリューストリーム管理とは何か、そしてなぜソフトウェアデリバリーにおいて重要なのでしょうか？","バリューストリーム管理（VSM）は、アイデア出しから顧客価値の創出までの全ステップをマッピングして分析することで、ソフトウェアデリバリーを最適化する戦略的アプローチです。これにより、全ステップの可視化、ボトルネックの特定、ワークフローの効率化が実現され、コストとリスクを削減しつつ、高品質なソフトウェアをより迅速に提供できます。",{"header":593,"content":594},"バリューストリーム管理を行うと、どのように業務効率性が改善されますか？","VSMは、ハンドオフ、フィードバックループの分断、冗長なプロセスなどの非効率的な状態を解消することで、業務効率性を改善します。人材、プロセス、テクノロジーをつなげることで、機能横断型チームがより連携しながら生産的に作業できるようにします。その結果として、市場投入までの時間が短縮されます。",{"header":596,"content":597},"バリューストリーム分析のフローメトリクスとは何か、そして効率性の測定にどのように役立ちますか？","バリューストリーム分析のフローメトリクスは、アイデア出しからデプロイまで、ソフトウェアデリバリーライフサイクル全体を通じてビジネス価値の動きを追跡します。デプロイ頻度や変更のリード時間、変更失敗率などのメトリクスは、ボトルネックの特定、ワークフロー効率の改善、ソフトウェア品質の向上を行う際に役立ちます。",{"header":599,"content":600},"バリューストリーム管理を行うと、ソフトウェアデリバリーにおけるセキュリティとコンプライアンスはどのように強化されますか？","VSMは、セキュリティチェックとポリシーの適用を開発パイプラインに統合することで、セキュリティとコンプライアンスを強化します。これにより、継続的にモニタリングと監査が実施されるようになり、リスクが軽減されます。また、ソフトウェアライフサイクル全体を通じてセキュリティおよびコンプライアンス対策が一貫して適用されるようになります。",{"header":602,"content":603},"ソフトウェアデリバリーを最適化する上で、バリューストリームディスカバリはどのように役立ちますか？","バリューストリームディスカバリは、現状のソフトウェアデリバリープロセスをマッピングすることで、効率的でない箇所と価値を高めるアクティビティを特定する作業です。これにより、パフォーマンス測定におけるベースラインを把握でき、効率的でリーンなDevSecOpsツールチェーンを構成しやすくなります。結果として、より迅速で信頼性の高いソフトウェアデリバリーを実現できます。","optimize-value-stream-efficiency-to-do-more-with-less-faster","content:ja-jp:the-source:platform:optimize-value-stream-efficiency-to-do-more-with-less-faster:index.yml","ja-jp/the-source/platform/optimize-value-stream-efficiency-to-do-more-with-less-faster/index.yml","ja-jp/the-source/platform/optimize-value-stream-efficiency-to-do-more-with-less-faster/index",{"_path":609,"_dir":26,"_draft":6,"_partial":6,"_locale":7,"config":610,"seo":611,"content":615,"type":485,"category":26,"slug":622,"_id":623,"_type":28,"title":612,"_source":29,"_file":624,"_stem":625,"_extension":32,"date":616,"description":613,"timeToRead":500,"heroImage":614,"keyTakeaways":617,"articleBody":621},"/ja-jp/the-source/platform/finops-balancing-financial-responsibility-and-innovation",{"layout":5,"template":450,"articleType":451,"author":452,"featured":6,"gatedAsset":513,"isHighlighted":6,"authorName":437},{"title":612,"description":613,"ogImage":614},"FinOps：財務責任とイノベーションをバランスよく実現","FinOpsがどのように財務責任とビジネス目標を調和させ、現代企業において費用対効果の高いイノベーションを促進するかをご説明します。","https://res.cloudinary.com/about-gitlab-com/image/upload/v1751463866/i27a3wecdhplvd9wbxqr.png",{"title":612,"date":616,"description":613,"timeToRead":500,"heroImage":614,"keyTakeaways":617,"articleBody":621},"2024-11-26",[618,619,620],"FinOpsは、財務、エンジニアリング、ビジネスの各チーム間のコラボレーションを促進し、戦略的なビジネス目標に合わせてクラウドへの投資を調整することで、最大限の価値を引き出します。","FinOpsにより財務面での透明性が高まることで、組織はデータに基づいて迅速な意思決定を行えるようになり、クラウドへの支出が最適化されます。","FinOpsを導入することで、イノベーションとコスト管理のバランスが取れ、製品開発チームと運用チーム間の緊張が緩和されます。","エンジニアリングチームとともにクラウドへの支出が増加すると、出荷時期を早めるようデベロッパーに催促するか、増大するコストを抑えるかという厳しいトレードオフがしばしば発生します。では、プロジェクトコストを25%削減しつつ、デベロッパーの生産性を30%向上させることは可能でしょうか？これは不可能に思えるかもしれませんが、FinOps（財務オペレーション）を導入している企業にとっては現実的な目標です。FinOpsとは、ソフトウェア開発ライフサイクル全体にDevOpsの原則と手法を適用することで、人、プロセス、テクノロジー関連のコストを最適化するデータドリブンアプローチです。\n\nこれまで、FinOpsの導入によってソフトウェア開発のあらゆる側面に財務上の透明性がもたらされることで、組織が変わっていく様子を実際に見てきました。先日、FinOpsを採用したばかりの保険会社のDevOpsチームと話しました。初期段階で話し合った内容は、クラウドへの支出などの基本的な測定方法の決定や、バリューストリーム管理による収益促進、コスト削減に関するその他のメトリクスの特定などについてです。FinOpsプラクティショナーにとって、このような話し合いは、チームとリソースの編成と割り当てを評価し、どのようなプロセスとツールを導入すれば変化を促進できるかを検討する上で非常に重要です。\n\nチーム構造から開発プロセス、テクノロジーの選択まで可視化することで、リーダーがオペレーション全体にわたって投資を最適化しやすくなります。FinOpsは、財務チーム、製品チーム、エンジニアリングチームをまとめることで、CFOやCPO、CTOが情報に基づいた意思決定を行えるようにし、ビジネス全体の効率を向上させます。\n\n効率性の向上およびコストの最適化は、技術的な課題であるだけでなく、特に組織がクラウドにより多くの投資を行う今、企業にとって戦略面でも重要な課題となっています。FinOpsによって、クラウドの変動費モデルに必要な財務責任を確保できます。FinOpsのメリットと、運用ワークフローにFinOps手法を取り入れる方法を見ていきましょう。\n\n## FinOpsとは？\nFinOpsは、Financial Operations（財務オペレーション）の略で、財務、エンジニアリング、テクノロジー、ビジネスの各チームの運営方法を変革することで成功をもたらす手法です。リアルタイムのデータと分析を通じて、チームはクラウドへの支出を即座に可視化し、コストが増大する前に対応できます。このように財務責任に対して積極的なアプローチを取ることで、リソースの割り当てについて情報に基づいた迅速な意思決定を行うことができ、結果として測定可能なコスト削減を実現できます。\n\nFinOpsは根本的には、このような変革を持続可能にする文化的慣習です。明確なプロセスと共通のメトリクスを確立することで、各チームが日々行うテクノロジーに関する意思決定が、企業のビジネス目標の達成に貢献できるようになります。\n\n## 今FinOpsが人気な理由\n多くの企業が生成AIとデベロッパーの生産性に重点的に取り組む中、[推奨される方法](https://about.gitlab.com/the-source/platform/driving-business-results-with-platform-engineering/)を確実に採用できるように、デリバリーにおいて自動化されたワークフローや再利用可能なテンプレートなどのガードレールが必要となっています。これは、アプリケーションをモダナイズし、本番環境でもクラウドアーキテクチャを使用する組織にとって今や不可欠です。\n\n継続的インテグレーション（CI）コストのような非生産的コストを管理する場合、さらに難しい課題に直面します。企業がデータドリブンアプローチを採用している場合、CIコストをより深く可視化できます。CIの水平展開または垂直展開が、フィードバックサイクルとさまざまなプロセッサアーキテクチャのコストの両方にどのような影響をもたらすかを正確に把握できます。一時的なテスト環境などの標準を実装することで、支出を最適化しつつ、コード品質とセキュリティを実現することが可能になります。\n\n通常、製品ラインの予算の責任者であるプロダクトオーナーが、ITチームやエンジニアリングリーダーと協力して、透明性に関するメトリクスを提供することもできます。このような協力関係を通じて、リーダーは複数のサービスにわたる予算予測をまとめ、インフラストラクチャリソースが最適な状態で活用されるようにすることができます。その結果、財務チームが、最終的に最も投資効果の高いアプリケーションを把握できるようになります。\n\n## 技術領域と財務領域の橋渡し\nFinOpsモデルを構築する際は、場合によってアメとムチの手法が両方とも必要になります。アメの手法を取り入れることで、より協調的で透明性の高い環境が構築されます。一方、大抵の場合、ムチの手法（予算を超過した開発チームへの厳重注意など）を取り入れると、プロセスが破綻することになります。FinOpsによって、デベロッパーのクラウドリソースの利用をモニタリングするだけでなく、デベロッパーの業務に必要なものと、それが会社の収益にどのような影響を及ぼしているかを把握できるようにする必要があります。\n\n最近、年間500万ドル近くをCI Runnerフリートに費やしている大手航空会社の担当者と話をしました。この航空会社では、セキュリティスキャン、依存関係スキャン、トークンスキャンをすべてRunnerフリート内で実行していました。支出を削減するために、セキュリティ措置を取らないことも可能でしたが、Runnerフリートに費やすコストよりも[セキュリティ問題が発生する可能性](https://about.gitlab.com/the-source/security/how-to-strengthen-security-by-applying-devsecops-principles/)をより一層懸念していました。同社は、セキュリティ措置をスキップすることなく、支出の削減に加え、デベロッパーによる実験とイノベーションを促進するために、Runnerフリート全体の効率化を実現する方法を見つける必要がありました。\n\nFinOpsプログラムを成功させるために、FinOps専門家の専任チームを常時置く必要はありません。FinOpsは、財務、製品、エンジニアリングなど、機能横断型チーム間の戦略的に結びつける役割を担います。FinOpsプログラムには通常、CTOやエンジニアリング部門副社長、財務リーダー、定期的に連携して問題の評価を行い、新たな効率化の機会を特定し、修正計画を策定する1人以上のエンジニアリングリーダーなど、さまざまな職務と部門が関与します。\n\n財務目標に沿って技術的な運用を行うことで、クラウドインフラストラクチャとソフトウェア開発への投資対効果が最大化されます。これによって、DevSecOpsチームは、自分たちの業務がどのように収益の増加に直接つながり、どのようにコストを削減できるか、またはその両方を把握できます。\n\n## デベロッパーのワークフロー内でスマートな財務管理を実現\nFinOpsでは、ユーザーと運用の両方の観点からリソースの消費をモニタリングすることで、デベロッパーのワークフローを最適化できるようにします。そのための方法には、CIジョブを分析し、価値を正当化できる以上にコストがかかるジョブを特定することなどが考えられます。各ソフトウェア開発パイプラインには複数のジョブが含まれ、それぞれ仮想マシン（VM）やコンテナなどの実行リソースが必要となります。各ジョブの実行にかかる時間が長くなるほど、コストも高くなります。FinOpsを実践することで、デベロッパーがどのジョブのパフォーマンスが低いかを確認して、リファクタリングする必要があるジョブを把握できます。\n\nこれにより、セルフサービスモデルが構築されるため、DevSecOpsチームが明確なガイドラインに従って作業できるようになります。たとえば、ポリシーによってAWS上で10万ドル相当のリソースをプロビジョニングすることは禁じられているとしても、テスト実施の目的でEC2イメージをスピンアップすることは可能な場合もあります。しかしながら、10万ドル相当のリソースをプロビジョニングする必要がある理由を正当化できる場合は、リクエストを提出して、そのプロジェクトによって会社にどれだけの収益を生み出せる可能性があるかを説明できます。リクエストが承認されれば、作業を開始できます。\n\n一方、DevOpsの担当者には、FinOpsはモニタリングによってイノベーションを制限するものではないことをあらためてお伝えしたいと思います。そうではなく、組織におけるクラウドの使用とコストを完全に可視化することで、チームがクラウドの生産性を高める機会を特定できるようにするものです。FinOpsを実践することで、財務、テクノロジー、ビジネスの各チーム間のコラボレーションが促進されるだけでなく、使用パターンを分析し、需要を予測できます。これにより、予算超過が発生する前に、将来のニーズに合わせてリソースの増減が必要かどうかを事前に予測することが可能です。\n\n## 緊張の緩和\nエンジニアリングチームと運用チームの間には、常に攻防が繰り広げられています。エンジニアリングチームの使命は、顧客に素晴らしい体験を提供できるようにしつつ、新たな収益源をもたらすイノベーションを推進することです。一方、運用チームは、コストを削減しながら生産性を最大化することに重点を置いています。FinOpsは、クラウドへの支出を削減しながらデベロッパーの生産性を向上させることで、これらのチーム間の緊張を緩和し、技術面での効率性と財務上の慎重さを両立できるようにします。\n\nFinOpsを実践することで、DevSecOpsチームは主観的なコストではなく、正確な数値をもとに考えられるようになります。プロジェクトによって収益が増えるか、コストが削減されるかという2つの重要な基準に基づき、プロジェクトの継続について十分な情報をもとに決定を下すためには、組織に対する財務的影響を明確に理解した上でソフトウェア開発に取り組むことが不可欠です。\n\n根本的にFinOpsは、コスト削減を実現するだけでなく、ソフトウェア開発ライフサイクル全体を最適化する手法でもあります。FinOpsの目標は、エンジニアチームや運用チームが技術革新とともに財務上の効率性を考慮し、各自の業務が組織の収益向上にどのように結びつくかを把握できるようにすることです。\n\n_FinOpsの詳細については、[FinOps Foundationウェブサイト](https://www.finops.org/introduction/what-is-finops/)をご覧ください。_","finops-balancing-financial-responsibility-and-innovation","content:ja-jp:the-source:platform:finops-balancing-financial-responsibility-and-innovation:index.yml","ja-jp/the-source/platform/finops-balancing-financial-responsibility-and-innovation/index.yml","ja-jp/the-source/platform/finops-balancing-financial-responsibility-and-innovation/index",{"_path":627,"_dir":26,"_draft":6,"_partial":6,"_locale":7,"config":628,"seo":629,"content":633,"type":485,"category":26,"slug":641,"_id":642,"_type":28,"title":630,"_source":29,"_file":643,"_stem":644,"_extension":32,"date":634,"description":631,"timeToRead":635,"heroImage":632,"keyTakeaways":636,"articleBody":640},"/ja-jp/the-source/platform/driving-business-results-with-platform-engineering",{"layout":5,"template":450,"articleType":451,"author":493,"featured":6,"gatedAsset":24,"isHighlighted":6,"authorName":419},{"title":630,"description":631,"ogImage":632},"プラットフォームエンジニアリングでビジネスの成果を上げる","プラットフォームエンジニアリングは、市場投入までの時間短縮、セキュリティリスクの軽減、デベロッパーエクスペリエンスの向上により、ビジネス効率を高めます。本記事でチームを成功に導く方法をご紹介します。","https://res.cloudinary.com/about-gitlab-com/image/upload/v1751463790/xmrjm5ztb49zx5bggima.png",{"title":630,"date":634,"description":631,"timeToRead":635,"heroImage":632,"keyTakeaways":636,"articleBody":640},"2024-10-29","7分で読めます",[637,638,639],"プラットフォームエンジニアリングは、企業がより少ないコストでより多くのことを成し遂げるための重要な戦略として最近注目を浴びています。","その利点として、市場投入までの時間の短縮、セキュリティとコンプライアンスのリスクの軽減、デベロッパーのエクスペリエンス向上などが挙げられます。","プラットフォームエンジニアリングを成功させるには、製品指向の文化を確立し、明確なビジネス目標を設定することが不可欠です。","開発チームのベストプラクティスとコンポーネントを一元化するプラットフォームエンジニアリングは、DevSecOpsのプラクティスとフレームワークが組織全体に組み込まれるようになるにつれ、さらに注目を集めています。また、大部分の作業に対しては最適化された「Golden Path」をデベロッパーに提供し、残りの作業に対しては例外的なケースを定義できるような柔軟性を持たせることで、デベロッパーのワークフローを正規化・標準化することがプラットフォームエンジニアリングの目的とされています。\n\nGartner®社によると、「2026年には大規模なソフトウェアエンジニアリング組織の80%でアプリケーションデリバリー用の再利用可能なサービス、コンポーネント、ツールの社内プロバイダーとしてプラットフォームエンジニアリングチームが確立される」と予想されています[1]。これは、2022年の45%と比較して大きな増加です。プラットフォームエンジニアリングは、組織（特に多くのエンジニアリングのイニシアチブが並行して行われている大規模な組織）がDevSecOpsの原則やツールをより簡単に拡張できるようにするものです。必要コストを下げながらで多くの成果を上げるようプレッシャーを受けている企業では、このアプローチは非常に重要となります。\n\n## プラットフォームエンジニアの主なメリット\n__市場投入のスピードを加速：__ プラットフォームエンジニアリングは、組織が高品質なソフトウェアをより速く、費用対効果の高い方法で提供できるよう支援します。大規模な組織がプラットフォームエンジニアリングチームを結成することで、ツールを減らして迅速に作業を進められ大幅なコスト削減が可能になるなど、長期的なメリットが見込めます。\n\n__セキュリティとコンプライアンスのリスクを軽減：__ ツールを減らしてワークフローを標準化することで、組織のコンプライアンスオーバーヘッドと潜在的なアタックサーフェス（攻撃対象領域）を軽減できます。[データ侵害のコストに関する調査 2024年](https://www.ibm.com/jp-ja/reports/data-breach)によれば、2023年における世界の平均データ漏洩コストは445万ドルでした。データ漏洩にかかるコストはまだ大きいものの、アタックサーフェスを効果的に管理している組織はより迅速に漏洩を封じ込めることができます。\n\n__デベロッパーエクスペリエンスの向上：__ [DevEx](https://about.gitlab.com/developer-experience/)の優先度は高まっており、企業は優秀なデベロッパーを引き付けて確保すべく競争しています。プラットフォームエンジニアリングチームは、効率的で自動化されたワークフローやGolden Pathを構築し、デベロッパーのワークロードから手作業で冗長なタスクを取り除くことで、エクスペリエンスを向上できます。これにより日々の作業が簡素化され、アプリケーションを効率的にビルド、テスト、デプロイし、よりインパクトのあるビジネスクリティカルな作業に集中できるようになります。\n\n## プラットフォームエンジニアリングのベストプラクティス\n\n### まず文化を変える\n「プラットフォーム」が私たちが構築するものであるのなら、「エンジニアリング」はそれを構築する方法と言えるでしょう。多くの組織が、導入を成功させるには組織文化をどう進化させたらいいのかを検討せずに、テクノロジーの購入や導入に踏み切っています。プラットフォームエンジニアリングチームは、デベロッパーを顧客、自身をプロダクトオーナーと考えて行動することが求められます。デベロッパーのニーズを理解するための調査の実施や、提供されたリソースを活用して成功できるようエンドユーザーとやり取りをする必要があります。これには内部マーケティング、コミュニケーション、カスタマーサポートのスキルが必要ですが、多くの場合、技術チームには欠けている要素です。\n\nここで重要なのは、製品志向の考え方と文化です。プラットフォームエンジニアリングチームは、ユーザーのフィードバックに耳を傾け、製品（デベロッパー向けプラットフォーム）を継続的に反復して改善することで、エンドユーザー（デベロッパー）に価値を提供することに集中できます。リーダーは、チームメンバーが特定の（内部）顧客を支援する方法を模索できる環境を作る必要があります。セルフサービスインターフェースやプログラム可能なAPIを通じて、ユーザーがサービスをできるだけ簡単に利用できるようにすることに重点を置きます。\n\n### ビジネスバリューの提供に集中\n\nプラットフォームエンジニアリングのイニシアチブを開始すると、組織は非常に生産性の高いチームを見て、その真似をしたくなるかもしれません。開始当初はチームの構造や使用するツールに重点が置かれすぎることがよくありますが、多くの場合、こうした要素は生産的なチームによって生み出される成果であり、最初に構造やツールありき、というわけではありません。リーダーは、チーム構造やツールではなく、求めるビジネス上の成果に焦点を当て、その目標を達成するための適切なツールやチーム構造を特定する必要があります。\n\nビジネスインパクトの観点から、プラットフォームエンジニアリングの目標を定義しましょう。ソフトウェアを迅速に開発することは素晴らしいことですが、なぜそれが必要なのでしょうか？どのようなビジネス目標に役立つでしょうか？\n\nたとえばスピードと俊敏性の向上は一般的な目標ですが、その背後には複数のビジネス目標が隠れている可能性があります。市場投入までの時間が遅いと、どの製品を優先させるかという難しい選択を迫られ、機会コストの問題が発生します。より迅速に動くことができる組織は、急速に変化する市場に対応する準備も整っています。また、セキュリティ上の意味合いもあります。セキュリティインシデントが発生した場合に迅速かつ効率的に対応できるということを組織が十分に理解している必要があります。\n\n一般的な生産性や効率性の指標は参考になりますが、リーダーは指標を金額に変換してビジネス価値を明確にする必要があります。たとえば、プラットフォームエンジニアリングによって、新人のデベロッパーがコードを本番環境へ初めてリリースするまでの時間を短縮できたとします。この場合、組織はそのデベロッパーの1年目の給与の一定の割合と、オンボーディングを支援する社内の人材の給与の一部を節約できます。また、定着率を高め、コストのかかる雇用のニーズ（広告、リクルーター、長期面接サイクルなど）を減らせる可能性もあります。\n\nリーダーは、ビジネス価値に常に焦点を当て適切な結果をもたらすことで、プラットフォームエンジニアリングのイニシアチブを最適化できます。\n\n### 測定可能な状態を保つ\nプラットフォームエンジニアリングチームの進捗状況を追跡し、デベロッパーが提供されるサービスをどのように使用しているか（または使用していないか）を理解するのに役立つ指標を設定することが重要です。これにより継続的な改善が可能になり、成功している領域や追加リソースが必要な領域を特定でき、社内のマーケティング活動に役立ちます。\n\n役に立つ指標として次のものが挙げられます。\n\n- __導入率：__ プラットフォームを積極的に使用しているデベロッパーの数\n\n- __価値創出までの時間：__ 新しいデベロッパーがプラットフォームでコードのデリバリーを開始するまでにかかる時間\n\n- __コミュニティのエンゲージメント：__ プラットフォーム内のコンポーネントのうち、コミュニティによって提供されたものの割合（例：あるチームが他のチームにも役立つような新しいCIジョブを開発した場合に、それをプラットフォームエンジニアリングチームと共有してより広範な適用とメンテナンスを行うかなど）\n\n### すべての人を念頭に置いた構築\nデベロッパープラットフォームの早期導入者は、プロセスの初期段階で最も目立ち、発言力も強くなりがちです。ただし、早期導入者（通常は組織の20%未満）は、最終的にプラットフォームを活用するほとんどのユーザーとは非常に異なるニーズを持っているため、その発言が他ユーザーと必ずしも一致しない可能性があることに注意しましょう。組織にとって理にかなったGolden Pathを定義する際には、早期導入者だけでなく、大多数のユーザーを念頭に置いて構築する必要があります。\n\n早期に投資する価値のある一般的なGolden Pathの1つに、1つのターゲットプラットフォーム（Kubernetesなど）で特定のタイプのワークロードをサポートするエンドツーエンドのCI/CDパイプラインがあります。この基本的なワークロードがサポートされれば他のワークロードにとっても強力な基盤となり、プラットフォームが価値を提供できるという確信が得られます。Golden Pathがビジネス上で生み出す成果を踏まえた上で、組織が優先すべきものを定義しましょう。\n\n## DevSecOpsプラットフォーム：プラットフォームエンジニアリングの基盤\nDevSecOpsプラットフォームは単一のユーザーインターフェース、統一されたデータストア、DevSecOpsライフサイクルに組み込まれたセキュリティを提供するものです。DevSecOpsプラットフォームを使用すると、組織はソフトウェア開発プロセス全体に対応するWorkflow-as-a-Serviceを活用して、プラットフォームエンジニアリングの基盤を構築できます。\n\nここでは、プラットフォームエンジニアリングでチームを成功に導くDevSecOpsプラットフォームの重要な要素をいくつかご紹介します。\n\n- __計画とコラボレーション：__ プラットフォームエンジニアリングは透明性がなければ機能しません。[全員が同じプラットフォームに参加](https://about.gitlab.com/ja-jp/solutions/agile-delivery/)することでコミュニケーションが円滑に進み、デベロッパーが戦略とスコープを把握できるようになり、コードの計画、ビルド、テスト、保護、デプロイ、モニタリングをより効率的に行えるようになります。\n\n- __CI/CDとオーケストレーション：__ オーケストレーションはプラットフォームエンジニアの中心です。プラットフォームを使用すれば、デベロッパーは[コード品質を確認して本番環境に移行](https://about.gitlab.com/ja-jp/solutions/continuous-integration/)できるようになります。さらに、テンプレートメカニズムを適用すれば、共通のベストプラクティスを確実に導入し、すべての変更が一貫した品質プロセスを経るようにすることも可能です。\n\n- __デベロッパーエクスペリエンス：__ DevExは、手作業のタスクを自動化し、不要な意思決定を抽象化することで、デベロッパーの日常業務を簡素化することを目的としています。DevSecOpsプラットフォームを使用するとすべてのコードが1か所にまとめられるため、デベロッパーは頭の切り替えを最小限に留めながら何をするべきかを簡単に判断できます。さらに、再利用可能なテンプレートやコード提案、コードの説明などのAI搭載の機能をデベロッパーに提供することで、障害がなくなり、デベロッパーはオンボーディングを迅速に完了してすぐに価値を生み出せるようになります。\n\n- __統合セキュリティ：__ DevSecOpsプラットフォームを使用すると、[自動セキュリティスキャン](https://about.gitlab.com/solutions/security-compliance/)で、すべてのコードが基準のポリシーを満たしていることが確認されます。 さらに重要なのは、デベロッパーがそのデータにセルフサービスでアクセスできることです。本番環境へのロールアウトをする前に重大な脆弱性を発見できます。\n\n- __メトリクスと分析：__ プラットフォームエンジニアリングのイニシアチブを成功させるには、組織はプロジェクトの背後にあるビジネス目標を特定し、その目標に向けた進捗をモニタリングできる必要があります。[ソフトウェア開発ライフサイクル全体からデータを集めるダッシュボードと分析](https://about.gitlab.com/solutions/value-stream-management/)により、組織は主要メトリクスの追跡、プロセス改善の影響の評価、ボトルネックの詳細な分析を簡単に行うことができます。これにより、リーダーはトレンドやボトルネックをすばやく特定し、リスクのあるプロジェクトに集中できるようになります。\n\n[こちらのページ](https://about.gitlab.com/solutions/platform-engineering/)では、ソフトウェア開発を加速する方法についてご紹介します。GitLabはDevSecOpsチームにツールとワークフローのための単一のセルフサービスポータルを提供して認知負荷を軽減し、よりスケーラブルなソフトウェアデリバリーを実現します。その詳細をご覧ください。\n\n*[1] Gartner, Top Strategic Technology Trends for 2024、Bart Willemsen、Gary Olliffe、Arun Chandrasekaran、2023年10月16日。GARTNERは、GARTNER, INC.および/またはその関連会社が有する米国内および国際的な登録商標であり、ここでは許可を得て使用されています。無断転載を禁じます。*\n\n*監修：川瀬 洋平　[@ykawase](https://gitlab.com/ykawase)\n（GitLab合同会社 カスタマーサクセス本部 シニアカスタマーサクセスマネージャー）*","driving-business-results-with-platform-engineering","content:ja-jp:the-source:platform:driving-business-results-with-platform-engineering:index.yml","ja-jp/the-source/platform/driving-business-results-with-platform-engineering/index.yml","ja-jp/the-source/platform/driving-business-results-with-platform-engineering/index",[447,490,510,551,571,608],{"ai":357,"platform":10,"security":96},1753207538420]