持続可能性の文化を推進する

Last reviewed 2026-01-28 UTC

Well-Architected Framework のサステナビリティの柱におけるこの原則では、組織全体のチームがサステナビリティ プラクティスを認識し、習熟している文化を構築するうえで役に立つ推奨事項が示されています。Google Cloud

原則の概要

サステナビリティ プラクティスを適用するには、ツールや手法だけでは不十分です。教育とアカウンタビリティによって推進される文化の変革が必要です。チームはサステナビリティに関する懸念事項を認識し、サステナビリティ プラクティスを実践する能力を備えている必要があります。

  • サステナビリティの認識とは、アーキテクチャと運用のあらゆる決定がサステナビリティに具体的な影響を与えるというコンテキスト上の知識です。チームは、クラウドが仮想リソースの抽象的なコレクションではなく、エネルギーを消費して二酸化炭素を排出する物理リソースによって駆動されることを認識する必要があります。
  • サステナビリティ プラクティスの習熟度には、二酸化炭素排出量データを解釈する知識、クラウド サステナビリティ ガバナンスの実装経験、エネルギー効率を高めるためのコードのリファクタリングの技術スキルが含まれます。

サステナビリティ プラクティスを組織の目標に合わせるには、クラウド インフラストラクチャとソフトウェアによるエネルギー使用量が組織のカーボン フットプリントにどのように影響するかをチームが理解する必要があります。綿密に計画されたトレーニングは、デベロッパーやアーキテクトから財務担当者や運用エンジニアまで、すべてのステークホルダーが日々の業務のサステナビリティのコンテキストを理解するのに役立ちます。この共通認識により、チームは受動的なコンプライアンスから積極的な最適化へと移行し、クラウド ワークロードを設計段階からサステナブルにすることができます。 サステナビリティは、セキュリティ、費用、パフォーマンス、信頼性に関する他の要件と同様に、コアとなる非機能要件(NFR)になります。

推奨事項

サステナビリティに関する懸念事項の認識とサステナビリティ プラクティスの習熟度を高めるには、以下のセクションの推奨事項を検討してください。

ビジネス コンテキストを提供し、組織の目標との整合性を確保する

サステナビリティは単なる技術的な取り組みではなく、個々の行動を組織の環境ミッションに合わせる文化の変革が必要です。チームがサステナビリティ イニシアチブの背後にある理由を理解すると、イニシアチブをオプションのタスクではなく、コア原則として採用する可能性が高くなります。

全体像を把握する

低炭素リージョンの選択やデータ パイプラインの最適化など、個々のアーキテクチャの選択が組織全体のサステナビリティへの取り組みにどのように貢献するかをチームが理解できるようにします。これらの選択が地域社会や業界に与える影響を明確に伝えます。抽象的な二酸化炭素排出量指標を、企業の社会的責任(CSR)目標に向けた進捗状況の具体的な指標に変換します。

たとえば、次のようなメッセージは、ワークロードを低炭素リージョンに移行し、電力効率の高いマシンタイプを使用するという決定の肯定的な結果と経営陣の認識をチームに伝えます。このメッセージでは、 二酸化炭素換算量が参照されているため、 チームは二酸化炭素排出量削減対策の影響をコンテキスト化できます。

「データ分析エンジンを us-central1 リーフアイコン 低 CO2 リージョンに移行し、クラスタを C4A Axion ベースのインスタンスにアップグレードすることで、カーボン プロファイルを根本的に変更しました。この移行により、データ分析エンジンの二酸化炭素排出原単位が 75% 削減され、今四半期には 12 メートルトンの二酸化炭素換算量が削減されました。この移行はビジネス目標に 大きな影響を与え、取締役会向けの第 4 四半期ニュースレターに 掲載されました。」

財務目標とサステナビリティ目標を伝える

サステナビリティ プラクティスを目標に合わせるには、透明性が不可欠です。可能な限り、サステナビリティの目標と進捗状況を組織全体で共有します。年次財務諸表でサステナビリティの進捗状況を強調します。このようなコミュニケーションにより、技術チームは自社の業務を組織の対外的な取り組みと財務健全性の重要な一部と見なすことができます。

運命共同体という考え方を取り入れる

クラウド サステナビリティの共同作業の性質についてチームに説明します。Google は、インフラストラクチャとデータセンターの効率を含む、クラウドのサステナビリティに責任を負います。 お客様(ユーザー)は、クラウド内のリソースとワークロードのサステナビリティに責任を負います。 このコラボレーションを運命共同体のパートナーシップとして捉えることで、組織と Google が協力して最適な環境成果を達成するという理解を強化できます。

ロールベースのサステナビリティ トレーニングを提供する

サステナビリティが理論的な概念ではなく実践的なスキルとなるように、サステナビリティ トレーニングを特定の職務に合わせて調整します。次の表に示すように、データ サイエンティストが使用できるサステナビリティのツールと手法は、FinOps アナリストが使用できるものとは大きく異なります。

ロール トレーニングの焦点
データ サイエンティストと ML エンジニア コンピューティングの二酸化炭素排出原単位: レガシー システムで AI トレーニング ジョブを実行する場合と、専用の AI アクセラレータで実行する場合の違いを示します。パラメータの少ないモデルで、エネルギー消費量を大幅に削減しながら必要な精度を実現する方法を説明します。
デベロッパー コードの効率とリソース消費量: レイテンシの高いコードや非効率なループが、CPU ランタイムの延長とエネルギー消費量の増加に直接つながることを説明します。軽量コンテナの重要性と、ソフトウェアの環境フットプリントを削減するためのアプリケーション パフォーマンスの最適化の必要性を強調します。
アーキテクト 設計によるサステナビリティ: リージョンの選択と ワークロードの配置に重点を置きます。1 行のコードを記述する前に、再生可能エネルギーの割合が高い リーフアイコン 低 CO2 リージョン( northamerica-northeast1 など)を選択すると、アプリケーション スタック全体のカーボン プロファイルがどのように根本的に変わるかを示します。
プラットフォーム エンジニアと運用エンジニア 使用率の最大化: アイドル状態のリソースと過剰なプロビジョニングの環境 コストを強調します。クラウド リソースを効率的に使用できるように、自動スケーリングと適切なサイズ設定のシナリオを示します。使用率などのサステナビリティ関連の 指標を作成して追跡する方法と、コンピューティング時間などの 指標を二酸化炭素排出量の同等の指標に変換する方法について説明します。
FinOps 二酸化炭素のユニットエコノミクス: 財務支出と環境への影響の関係に重点を置きます。GreenOps プラクティスを使用すると、組織はトランザクションあたりの二酸化炭素排出量を追跡できます。これにより、サステナビリティを、費用や使用率などの従来の KPI と同様に重要な重要業績評価指標(KPI)にすることができます。
プロダクト マネージャー 機能としてのサステナビリティ: 二酸化炭素排出量削減目標をプロダクト ロードマップに統合する方法を説明します。ユーザー ジャーニーを簡素化することで、クラウド リソースとエンドユーザー デバイスの両方のエネルギー消費量を削減できることを示します。
ビジネス リーダー 戦略的な連携とレポート: クラウド サステナビリティが環境、社会、ガバナンス(ESG)のスコアと社会的評判にどのように影響するかに重点を置きます。サステナビリティの選択が 規制リスクの軽減と、地域社会や 業界への取り組みの履行にどのように役立つかを説明します。

サステナビリティを推進し、成功を認める

長期的な進捗を維持するには、内部の技術的な修正にとどまらず、パートナーや業界に影響を与える必要があります。

マネージャーがサステナビリティを推進できるようにする

マネージャーに、市場投入までの時間や費用などの他のビジネス指標と同様に、環境への影響を優先するために必要なデータと権限を提供します。マネージャーがこのデータを入手すると、サステナビリティを、生産性を低下させる便利な機能ではなく、品質と効率の基準と見なすようになります。より詳細な二酸化炭素排出量データや、特定のリージョンでより新しいグリーン プロセッサなど、新しいクラウド プロバイダの機能を積極的に推進します。

業界標準とフレームワークに準拠する

サステナビリティへの取り組みが信頼でき、測定可能であることを確認するには、内部プラクティスを認められたグローバル標準および地域標準に合わせます。詳細については、 サステナビリティ プラクティスを業界ガイドラインに合わせるをご覧ください。

サステナビリティへの取り組みを奨励する

サステナビリティがエンジニアリング文化の永続的な一部となるように、チームはサステナビリティを優先することの価値を認識する必要があります。改善と効率化に報いる、具体的な測定可能な KPI に移行します。

二酸化炭素排出量 KPI と NFR を定義する

サステナビリティをコアとなる技術要件として扱います。二酸化炭素排出量 KPI (100 万リクエストあたりの二酸化炭素換算量や AI トレーニング実行あたりの二酸化炭素排出原単位など) を定義すると、サステナビリティへの影響を 可視化して対応できるようになります。たとえば、すべての新しいプロジェクトの NFR にサステナビリティを統合します。つまり、システムが特定のレイテンシまたは可用性の目標を満たす必要があるのと同様に、システムは定義された二酸化炭素排出量予算内に収まる必要があります。

労力の見返りを測定する

チームが、バッチジョブを別のリージョンに移行するなど、影響が大きく労力が少ないサステナビリティの成果と、最小限の成果しか得られない複雑なコード リファクタリング作業を区別できるようにします。労力の見返り(ROE)を可視化します。チームがより効率的なプロセッサ ファミリーを選択する場合は、新しいプロセッサへの移行に必要な時間と労力に対して、どの程度の二酸化炭素排出量を削減できたかを正確に把握する必要があります。

二酸化炭素削減を認識して祝う

サステナビリティの影響は、インフラストラクチャのバックグラウンドに隠されていることがよくあります。サステナビリティの進捗を促進するには、成功を組織全体に可視化します。たとえば、モニタリング ダッシュボードでアノテーションを使用して、チームが特定のサステナビリティ最適化をデプロイした日時をマークします。この可視性により、チームはダッシュボードのデータを参照して、成功を認めてもらうことができます。