翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。

# 目的
<a name="objectives"></a>

DevSecOps メカニズムに関する設計上の決定は、多くの場合単独で行われるため、プラットフォームのユーザーやその他の利害関係者にとってダウンストリームの課題につながる可能性があります。従来のユーザーストーリー開発では、デベロッパーはユーザーの立場から自分自身を想像して、どの機能を実装し、特定の期間内にどのように実装するのが最適かを判断する必要があります。

開発者は、一般的な[two-way-doorの方法で](https://aws.amazon.com/executive-insights/content/how-amazon-defines-and-operationalizes-a-day-1-culture/)機能やユーザーストーリーを開発することに慣れています。ただし、DevOps および DevSecOps メカニズムは、増幅と影響のレベルがはるかに高くなります。これらのメカニズムは通常、組織全体に影響を与え、多くの場合、一方向のドアを表します。組織のユーザーのニーズに合わないように設計されている場合、導入には抵抗があります。その結果、最終的にメカニズムを再構築する必要があり、開発の大幅な遅延や信頼の喪失につながる可能性があります。

このガイドでは、これらの機能を設計およびデプロイする際に開発者に追加の戦術ガイダンスを提供することで、このようなメカニズムのユーザーや利害関係者が経験する実装上の課題を軽減することを目指しています。

このガイドの推奨事項を実装したら、以下を正しく特定できるはずです。
+ メカニズムがさまざまなコードオーサシップソースをサポートする方法
+ メカニズムがさまざまな環境デプロイ戦略をサポートする方法
+ 環境デプロイ状態を管理する方法
+ ユーザビリティに重点を置いた適切なセキュリティコントロールを実装する方法