次の方法で共有

ツールとプロセスを標準化するためのレコメンデーション

この Azure Well-Architected Framework のオペレーショナル エクセレンスチェックリストの推奨事項に適用されます。

OE:04 業界で実績のある Development and test のプラクティスに従って、ソフトウェア開発と品質保証のプロセスを最適化します。 あいまいでないロール指定を行うには、ツール、ソース管理、アプリケーション設計パターン、ドキュメント、スタイル ガイドなどのコンポーネント全体でプラクティスを標準化します。

このガイドでは、ソフトウェア開発ツールとプロセスの標準を定義するための推奨事項について説明します。 一貫したプラクティスを定義すると、効率的なワークロード チームと質の高い作業が実現します。 パフォーマンスの高いチームは、業界で実証済みのツールとプロセスを使用して、無駄な労力と潜在的なコード エラーを最小限に抑えます。

主要な設計戦略

開発プラクティスを最適化する最初のステップは、ツールとプロセスを標準化することです。 可能であれば、社内ソリューションを開発するのではなく、業界で実証済みのソリューションを使用してください。 プラクティスをさらに最適化するには、ローコードツールとノーコードツールを採用します。 これらのツールを使用すると、アプリケーションに集中し、時間の節約に役立ちます。 標準化するすべてのツールとプロセスについて、チームがそれらを効率的に理解して使用できるようにトレーニングを実装します。 開発プラクティスの最適化に役立つ標準を定義するには、次のレコメンデーションを考慮してください。

よく知られている成熟した既製ツールを使用する

よく知られている成熟した既製ツールを使用し、その使用を標準化します。 非常に効率的なエンジニアリング チームは、クラス最高のツールを採用しています。 このアプローチにより、計画、開発、テスト、コラボレーション、継続的インテグレーションと継続的デリバリー (CI/CD) のためのソリューションを開発する必要性が最小限に抑えられます。 多くの企業では、開発者にいくつかのツールを選択できますが、すべてのオプションは組織の標準的なツールであり、内部的に検証されます。 最も重要なのは、ワークロードの要件を満たすツールを選択することです。 既製のツールでは、次の機能を提供する必要があります。

  • 作業計画とバックログ管理

  • バージョン管理とリポジトリ

  • CI/CD パイプライン

  • 統合テスト、スモークテスト、カオステスト、シミュレーション、合成ユーザー評価、その他の品質評価などのテスト

  • コード開発

場合によっては、1 つのツールまたはツール スイートが複数の機能を提供することもあります。 ツールの機能とその制限事項を理解し、機能全体の要件を満たしていることを確認します。

高価なツールまたはプレミアム バージョンのツールに投資する必要があるかどうかを判断します。 プレミアム ツールが提供する機能と比較して、独自のソリューションを開発する時間と労力を考慮してください。 一時的なコストと定期的なコストを考慮してください。 ほとんどの場合、既製のツールの方がチームに高い価値を提供します。

実用的な場合は、ローコード、ノーコード、AI ツールを使用します。 コードが少なく、コード不要のツールでは、コード開発プロセス全体を実行するのではなく、機能を簡単にプラグインできるため、経験豊富な開発者の時間を節約できます。 これらのツールを使用すると、トレーニングを受けた開発者ではない可能性のあるワークロード チーム メンバーがワークロードの運用に貢献することもできます。 AI ツールは、コードの開発、レビュー、最適化に役立ちます。

ブランチ戦略を標準化する

可能な場合は、トランクベースのモデルを選択します。 トランクベースの分岐により、ワークロード開発チームの同期が維持され、継続的デリバリーが促進されます。 メイン ブランチなどの重要なブランチを保護するためのブランチ ポリシーを定義します。 詳細については、「 Git ブランチ戦略の採用 」および 「ブランチのポリシーと設定」を参照してください。

メトリックを評価して開発の有効性を定量化する

ソフトウェア開発チームと品質保証チームは、有効性を定量化できる場合にのみ改善できます。 有効性を定量化するには、 開発者の速度 を測定し、KPI を定義するメトリックを識別する必要があります。 これらのメトリックの例には以下が含まれます。

  • デプロイの頻度: 各開発者が毎日デプロイするデプロイの数。

  • リード タイム: タスクまたはユーザー ストーリーがバックログから運用環境のデプロイに移行するまでにかかる時間。

  • 平均解決時間: コードのバグや欠陥の修正に費やされた平均時間。

  • 変更失敗率: 失敗の原因となる変更の割合。

関係者とワークロード チームがベロシティを簡単に追跡できるように、ダッシュボードやその他のレポート ツールを使用して KPI を視覚化します。

ワークロード チームがコードを作成、レビュー、文書化する方法を標準化します

スタイル ガイドを使用して、ワークロード チームがコードを作成、レビュー、文書化する方法を標準化します。 標準スタイルによりコラボレーションが容易になり、新しい開発者の新人研修に役立ちます。 効率的に作業するために、新しい開発者はワークロード チームがどのように機能するかを知る必要があります。 明確に定義された基準を備えたスタイル ガイドを使用すると、トレーニング プロセスが容易になります。 スタイル ガイドでは、開発言語、ライブラリ、フレームワーク、およびその他の規則の標準を定義します。

実用的な場合は、ツールを使用してコード形式の標準を適用します。 たとえば、Visual Studio には、スタイル、品質、保守容易性、デザイン、その他の問題についてコードをスキャンするいくつかの ツール が用意されています。 コードとしてのインフラストラクチャ (IaC) の場合は、Terraform に Checkov または Terrascan を使用できます。

一貫性を確保し、混乱を避けるために、スタイル ガイドには、成果物、環境、ブランチ、ビルド、および実行の標準的な名前付け規則を含める必要があります。

また、環境で許容される分散の程度に関するガイドラインと標準も設定する必要があります。 ワークロード チーム メンバーが標準リストに追加する新しい言語、フレームワーク、またはその他のテクノロジがある場合は、サンドボックスまたはそれ以下の環境でこれらのツールを使用するためのプロセスを実装します。 その実行可能性をテストし、必要に応じて既存のテクノロジを置き換えます。

アーキテクチャ決定レコード (ADR) を使用して 、ワークロード チームの設計上の決定の履歴を保持します。 ADR は、チームがワークロードを新たに理解するのに役立ちます。 また、新しいチーム メンバーが、ワークロードのライフサイクル中に行われる設計上の決定について学習するのにも役立ちます。 ADR がバージョン管理されていることを確認します。

ADR には、次のものが含まれます。

  • チームが選択する特定のツールとテクノロジ (SQL や NoSQL の使用など)。

  • あなたのチームの決定の理由。

  • 検討されたその他のオプション。最終的な決定をコンテキスト化するのに役立ちます。

  • 決定に組み込まれる機能要件と非機能要件。

  • 対処された問題など、意思決定プロセスのコンテキスト。

技術的負債に対処するための標準を実装する

技術的負債は意図的であり、ワークロード チームの成果物に必要であるという考え方を採用します。 この考え方により、チームは技術的負債の蓄積を避けるために定期的に技術的負債を検討し、対処するようになります。 バックログで定期的に繰り返されるタスクとして技術的負債に対処します。

たとえば、あなたのチームがライブラリを標準化することに決めたとします。 時間の経過とともに、ワークロードの新機能のために別のライブラリに切り替える必要があります。 その移行により、技術的負債が発生する可能性があります。 このような移行は、2 つのテクノロジをサポートするワークロード チームから離れる可能性があります。これは、完全にスムーズに移行できないためです。 ワークロードチームは、ワークロードが新しい機能を達成したときに利害関係者が満足し、技術的負債を考慮する可能性が低いため、移行の完了に優先順位を付ける必要があります。

成果物にバージョン管理を適用する方法を標準化する

成果物にバージョン管理を適用する方法と、内部および外部でバージョン管理を公開する方法を標準化します。 たとえば、クライアント側のシステムは、ユーザー インターフェイスで実行中のバージョンを公開する必要があります。 この手法は、ワークロード チームが問題のトラブルシューティングを行うときに役立ちます。これは、お客様が使用するバージョンを簡単に伝えることができるためです。 REST インターフェイスは、特定のコンポーネントまたはデータベースのバージョンを公開できます。 スキーマのメタデータ内の特定のテーブルを使用して、スキーマのバージョンを公開できます。

業界で実証済みのアプリケーション設計パターンを使用して、アプリケーションが信頼性が高く、パフォーマンスが高く、セキュリティで保護されていることを確認します。 これらのパターンを使用して、アプリケーション用の独自のソリューションを開発する場合と比較して、時間と労力を節約します。 ワークロードに利益をもたらすパターンを選択してください。 ワークロードの進化に合わせて適切なパターンを使用するように、設計パターンを定期的に確認します。

テストにシフトレフト アプローチを導入する

開発プロセス全体をとおして、ユニット テストを早期かつ頻繁に実行することで、テストにシフト レフト アプローチを実装します。 各開発環境で頻繁にテストを行うことで、開発者はアプリケーションに自信を持てるようになります。 シフトレフト アプローチでテスト戦略を作成するには、次の原則を考慮してください。

  • 可能な限り低いレベルでテストを記述します。 外部依存関係が最も少ないテストを優先し、ビルドの一部としてテストを実行します。

  • テストを 1 回記述し、運用環境を含むすべての場所でテストを実行します。 暗号化されたシークレットや構成など、特定の環境に固有の要素を考慮せずに、あらゆる開発環境で実行できるテストを作成します。

  • テスト用にワークロードを設計します。 アプリケーションを開発するときは、テスト容易性を要件にします。

  • テスト コードをアプリケーション コードとして扱います。 同じ品質と開発標準をアプリケーション コードとテスト コードに適用します。 テスト コードをアプリケーション コードと共に格納します。 アプリケーション コードを使用してテスト コードを開発および保守します。 テストの品質を確保するには、信頼できないテストを破棄します。

  • ワークロードの所有権に基づくテスト所有権を検討してください。 ワークロード チームはテストを所有しており、コードをテストするために他のチームに頼るべきではありません。

  • テストを可能な限り自動化します。 自動化されたコードにより、ワークロード チームの負担が軽減され、一貫した品質が確保されます。

ユニット、スモーク、統合、受け入れテストなど、さまざまな種類のテストを実装します。 これらの種類のテストの詳細なレビューについては、ワークロード サプライ チェーンの推奨事項ガイドのテストセクションを参照してください。

標準の運用手順の一部として DevSecOps プラクティスを要求する。 ワークロード チームは、ソフトウェア開発と品質保証に関連するセキュリティ プラクティスを理解する必要があります。 例外なく、これらのプラクティスに従う必要があります。 詳細については、 セキュリティ開発ライフサイクル ガイドを参照してください。

リソースの名前付けとタグ付けの標準を実装する

タグ付けと名前付け規則の実装は、Azure リソースを管理および整理するためのベスト プラクティスです。 タグ付けと名前付け規則は、環境、アプリケーション、所有者、コスト センターなどの一般的な属性に基づいてリソースを識別、分類、グループ化するのに役立ちます。 また、サブスクリプションとリソース グループ全体のリソースのセキュリティ、自動化、レポート、ガバナンスも可能になります。

標準化されたタグ付けと名前付け規則を使用する利点の一部は次のとおりです。

  • リソースの識別と管理の一貫性と明確さが提供され、Azure portal、PowerShell、CLI、API 全体での検出と検索が容易になります。
  • 課金、監視、セキュリティ、コンプライアンスの目的でリソースのフィルター処理とグループ化が可能になります。
  • プロビジョニング、使用停止、バックアップ、復旧などのリソース ライフサイクル管理をサポートします。
  • これらはセキュリティ上の目的で不可欠です。 セキュリティ インシデントが発生した場合は、影響を受けるシステム、それらのシステムがサポートする機能、および潜在的なビジネスへの影響をすばやく特定することが重要です。

クラウド リソースに名前付け規則を使用する方法の詳細については、「 名前付け規則を定義する」を参照してください。 クラウド リソースにメタデータ タグを適用する方法の詳細については、「 タグ付け戦略を定義する」を参照してください。

Azure ファシリテーション

  • Azure DevOps は、コラボレーションで効率的で一貫した開発プラクティスを構築するために使用できるサービスのコレクションです。 Azure DevOps は、次のソリューションをバンドリングします。

    • Azure Pipelines には、アプリケーションの CI/CD をサポートするためのビルド サービスとリリース サービスが用意されています。

    • Azure Boards は、スクラムやかんばんなどのアジャイル プラクティスをサポートする Web ベースの作業管理ツールです。

    • Azure Repos は、 Git 分散バージョン管理システム と Team Foundation バージョン管理 システムをサポートするバージョン管理ツールです。

    • Azure Test Plans は、計画的な手動テスト、ユーザー受け入れテスト、探索的テスト、関係者からのフィードバックの収集に必要な機能を提供する、ブラウザーベースのテスト管理ソリューションです。

    • Azure Artifacts は、 開発者が自分のコードを効率的に共有し、パッケージを管理できるようにするために使用されます。

  • GitHub Actions for Azure は、CI/CD プロセスを自動化するために使用できるツールです。 デプロイを簡略化するために、Azure と直接統合されます。 リポジトリに対するすべてのプル要求をビルドしてテストするワークフローを作成したり、マージされたプル要求を運用環境にデプロイしたりできます。

  • GitHub Projects は、かんばんボード、レポート、ダッシュボード、およびその他の機能を作成するために使用できる作業管理ツールです。

  • ローコードツールとノーコードツールは次のとおりです。

  • Azure Resource Manager テンプレート と Bicep は、IaC のデプロイに使用できる Azure ネイティブ ツールです。 Terraform は、インフラストラクチャのデプロイと管理に使用できる、Azure でサポートされているもう 1 つの IaC ツールです。

  • Visual Studio は、Azure と統合され、多くの言語をサポートする堅牢な開発ツールです。

  • GitHub Copilot は、ペア プログラマとして機能し、コーディング時にオートコンプリート スタイルの提案を提供する AI サービスです。 Copilot は、Visual Studio およびその他のいくつかの開発ツールで拡張機能として使用できます。

  • Azure Load Testing は、アプリケーションのホスト場所に関係なく、アプリケーションのトラフィックをシミュレートすることで、高スケールの負荷を生成するために使用できるフル マネージドのロード テスト サービスです。

組織の配置

Azure のクラウド導入フレームワークには、 Azure リソースのタグ付けと名前付けに関する一般的なガイドラインと推奨事項のほか、さまざまなリソースの種類に対する特定の規則と例が用意されています。

オペレーショナル エクセレンス チェックリスト

完全なレコメンデーションのセットを参照してください。

オペレーショナル エクセレンス チェックリスト