開発プラクティスを形式化するためのアーキテクチャ戦略

Azure Well-Architected フレームワークのオペレーショナル エクセレンスに関するチェックリストの次の推奨事項を対象とします。

OE:03 アイデアからデリバリーまで、ソフトウェア開発ライフサイクル全体にわたってプロセスを形式化し、チームと利害関係者に透過的にします。

ソフトウェア開発には、コードの生成以上のものがあります。 開発者は、何を構築し、その理由を明確に理解する必要があります。 製品の所有者とマネージャーは、作業の内容と進行状況を把握します。 一貫したプラクティスを確立することで、チームは品質の高いソフトウェアを提供し、早期にリスクを表面化し、期待を管理し、進行状況を追跡できます。

このガイドでは、構造化された予測可能な共同の方法でソフトウェア開発を実行する方法に関する推奨事項を提供します。

変更を管理するための標準を確立する

ソフトウェア開発では、すべての作業単位が変更されます。 新しい機能であっても、存在しない状態から実装された状態への移行を表します。

要求された変更の作業を開始するときは、次の考慮事項に注意してください。

  • 共同 作業。 チームは分離するのではなく、連携する必要があります。 ほとんどの変更は、複数のコンポーネントまたはロールに影響します。 開発者、テスター、運用、製品の利害関係者を早い段階で関与させ、重要な詳細が見逃されず、誰もが自分の領域への影響を理解できるようにします。 また、関連する経験を持つ人が自分の視点に貢献できるため、共同作業を行うと、より正確な労力の見積もりが得られます。

    コラボレーションの目標をシンプルに保ちます。 変更の範囲に同意し、依存関係を特定し、作業を明確で管理しやすいタスクに分割し、バックログに文書化します。

  • 通信。 チームがリリースを内部と外部の両方で通信する方法を標準化します。 外部の対象ユーザー (顧客など) と共有する必要がある情報、適切なレベルの詳細、必要なオンボーディングまたはサポート ドキュメント、およびコミュニケーション タイムラインを定義します。 たとえば、リリースの 2 週間前に関係者に通知し、デプロイの 24 時間前にリマインダーを送信します。

  • 回顧。 各開発サイクルを定期的に確認して、何が機能し、何がうまくいかなかったのか、改善できるかを特定します。 これらのレビューを非難しないで、学習に重点を置きましょう。

    この機会を使用して、標準プラクティスが有効かどうかを確認します。 たとえば、開発者タスクが明確に定義されているかどうか、時間の見積もりが正確で、プロセスが意図したとおりに動作しているかどうかを確認します。

  • レポート。 製品の変化に関するレポートを標準化します。 個々の開発者の生産性ではなく、製品の成長に重点を置いたレポートを保持します。 たとえば、利害関係者は次の項目を把握しておくとよいでしょう。

    • 導入の拡大
    • パフォーマンスの向上
    • 導入期間
    • インシデントの頻度

業界で実証済みのツールを選択する

独自のプロセスを発明する代わりに、 アジャイルスクラムかんばんボードなどの実績のあるプロセスを使用します。

実証済みのアプローチを使用すると、時間を節約し、労力を削減し、チーム メンバーにとって簡単になります。チーム メンバーのほとんどは既にこれらのツールに精通している必要があるためです。 また、標準ツールを使用すると、新入社員のオンボーディングが簡素化され、チーム間のコラボレーションが向上します。

トレードオフ: アジャイル手法は、過度に規範的である場合、厳格になりすぎる可能性があります。 明確に定義された標準とイノベーションのバランスをとるように努めてください。

開発作業の記録方法を標準化する

個別の作業単位をキャプチャするためのテンプレートを標準化します。 ユーザーの観点から記述し、次の原則に従う必要があります。

  • 独立。 重複する作業を回避するために、あるストーリーが別のストーリーに依存しないようにする必要があります。

  • 交渉可能。 開発の観点から現実的で、ビジネス目標に合わせて作業を行う必要があるため、作業は議論と洗練に開かれている必要があります。

  • 貴重。 作業はユーザーにとって明らかに有益である必要があります。

  • 見積。 チームは、時間に従って機能を提供できるように、自信を持って労力を見積もることができる必要があります。 数週間以内に完了できる小さなアイテムを優先します。

  • テスト可能。 機能の動作とデプロイを明確に検証できる方法が必要です。

運用環境のすべての開発資産は、コード、テスト、受け入れ基準、バックログ項目にトレース可能である必要があります。 追跡は、品質管理をサポートし、デバッグを簡素化し、規制された環境でのコンプライアンス要件をチームが満たすのに役立ちます。

また、チームと利害関係者が作業が完了したことを認識できるように、受け入れ基準のテンプレートを標準化します。 各作業単位は、あいまいではなく、テストによって検証できる受け入れ基準である必要があります。

開発サイクルの "完了" の意味について全員が同意していることを確認します。 要件には、完成したコード、完了したテスト、更新されたドキュメント、および対処されたアクセシビリティが含まれている必要があります。 定義をクリアすると、未完了の作業が蓄積されなくなります。

AI の機会: 組織のポリシーに基づいて、作業の説明と受け入れ基準の作成をテンプレート化できます。 Copilotを使用して、テンプレートから最初の下書きを生成します。 AI では、テンプレートに対してドキュメントを検証することで、標準を適用することもできます。 高度なシナリオでは、標準テンプレートに基盤を置いた AI エージェントを使用して、コード レビューと根本原因分析からの出力を使用し、識別された欠陥と改善のために準拠した作業項目を自動的に作成します。

コーディングプラクティスを標準化する

コーディングプラクティスは、開発者がコードを記述して共同作業するときに従う規則とガイドラインを定義します。 これらのプラクティスは、チーム内およびチーム全体でコードを構造化、文書化、およびレビューする方法を確立します。 また、開発者のオンボードを高速化し、実装のバリエーションによって発生する欠陥を減らします。

  • 開発環境とツール。 IDE の構成、開発ツール、承認されたコード生成ツールをチーム全体で標準化します。 一般的なライブラリ、フレームワーク、およびパッケージ管理標準の使用を強制して、再利用を促進し、一貫性を確保し、組織のセキュリティ要件に準拠します。

  • コーディング規則。 名前付け規則、コード構造、および書式設定に対応するコーディング標準を定義して文書化します。 例外を処理し、インストルメンテーションを実装するコード ブロックに標準を適用することをお勧めします。 明確な規則により、コードの読み取り、理解、保守が容易になり、チームが機能やコンポーネント間で一貫して作業できるようになります。 これらのガイドラインには、すべての開発者がアクセスでき、コードベースの進化に応じて定期的に更新されていることを確認します。 たとえば、Visual Studioで EditorConfig を使用して、コーディング スタイルを適用できます。

  • コード リポジトリ。 コードの統合とリリースの一貫性を確保するために、すべてのリポジトリで、Gitflow、GitHub Flow、トランクベースの開発などの標準化されたブランチ戦略を確立し、適用します。

  • ピアレビュー。 受け入れ可能な PR サイズ、必要なタイトルと説明の形式、および必須のレビュー要件を指定する pull request (PR) 標準を定義します。 標準に従っていることを確認するために、すべてのコード変更に対してピア レビューを要求します。 責任、フィードバック、承認に対する期待を設定する PR レビューのコラボレーション モデルを定義します。

  • 一般的な成果物のテンプレート。 PR の説明、コミット メッセージ、単体テストは、テンプレート化できるアーティファクトの従来の例です。 ドキュメントに目的、コンテキスト、テストの手順が含まれていることを確認します。

  • カバレッジをテストします。 すべての新しいコードの単体テストと、既存のコードに対する大幅な変更が必要です。 テストは合意されたパターンに従い、機能を検証するための意味のあるアサーションを含める必要があります。

AI の機会: AI ツールを使用すると、コーディングおよびレビュー プロセスの繰り返しの手動タスクを自動化できます。 GitHub Copilotは、標準化されたコード ブロック、単体テスト、pull request の説明を生成できるため、日常的な作業に費やす労力を削減できます。

SonarQube や Copilot Labs などのツールでは、コーディング標準からの逸脱、テスト カバレッジの不足、一般的なアンチパターンを自動的に識別できます。 これらの反復的な検証タスクを AI にオフロードすると、チームは価値の高い作業に集中できるようになります。 ただし、開発プラクティスはビジネス ロジックと全体的なワークロード品質の正しい実装に不可欠であるため、人間によるレビューは依然として不可欠です。

統合プラクティスを標準化する

統合 とは、開発ライフサイクルを通じてコードを検証、セキュリティで保護、パッケージ化するために使用される自動化されたプロセスと規則を指します。 これには、継続的インテグレーション パイプラインの一部として、コードの変更をビルド、テスト、スキャン、デプロイ用に準備する方法が含まれます。

標準化された統合プラクティスは、定義された品質とセキュリティの要件に対してコードを検証し、開発者のフィードバック ループを高速化するために必要です。

  • 自動化と統合テストを構築する: すべてのコード プッシュで実行される自動化されたビルドを標準化し、定義されたカバレッジしきい値を使用して自動化された単体テストと統合テストを適用します (該当する場合)。

  • コード品質分析: 承認されたツールを使用して静的コード分析と品質ゲートを適用し、昇格前にコードが定義された品質基準を満たしていることを確認します。

  • 依存関係の管理: 古いコンポーネントや脆弱なコンポーネントの依存関係を継続的にスキャンし、静的アプリケーション セキュリティ テスト (SAST)、動的アプリケーション セキュリティ テスト (DAST)、シークレット検出など、セキュリティ スキャンを統合します。

  • アーティファクト管理: パッケージと成果物のバージョン管理、ストレージ、および保持ポリシーを標準化して、追跡性と再現性を確保します。

  • 監視とレポート: ビルドとパイプラインのメトリックを収集して監視し、品質、パフォーマンス、コンプライアンスを追跡します。

AI の機会: AI 駆動型ワークフローを使用して、CI/CD パイプライン構成の生成、テスト スキャフォールディングの作成、不足しているテストや依存関係の問題などのビルドまたはテストの問題の検出など、反復的な統合タスクを自動化することを検討してください。 AI はパイプラインのセットアップを高速化しますが、人間のレビューを保持して重要な決定を検証します。

Azure ファシリテーション

Azure Boards は、チームが開発プロセス全体の作業を計画、追跡、および議論できるようにする Web ベースのサービスです。 これは、アジャイルベースの開発プラクティスに適しています。

GitHub プロジェクトは、GitHub の issue や pull request を使用してプロジェクトを整理し、統合できるカスタマイズ可能なプロジェクト管理ツールです。

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

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