SREやインフラ担当者にとって、フィードバックという言葉はどうしても抽象的に聞こえます。
ただしAWSクラウドの運用現場で起きているフィードバックのやり取りは、実は障害対応の仕組み化やSLO運用と地続きの話です。
AWSコミュニティでは、AWS Heroes（AWSが認定する外部の有識者プログラム）が定期的に集まり、AWSの各サービスチームに直接フィードバックを伝える機会があります。
この場でのやり取りは、単なる感想交換ではなく、サービスの次の改善サイクルに反映される入力情報として扱われています。
この構造は、SREチームが社内で運用しているポストモーテム（障害後の振り返り記録）やSLO（サービスレベル目標）の見直しプロセスと驚くほど似ています。
本記事では、この「フィードバックが機能する条件」をSRE視点で分解し、自分のチームの障害対応やIaC運用にどう当てはめられるかを整理します。
フィードバックが機能する条件を分解する
フィードバックには「機能するフィードバック」と「機能しないフィードバック」があります。
機能する条件は大きく3つに分けられます。
- 具体的で行動可能であること（「動かない」ではなく「どの手順のどこで失敗するか」を示す）
- 個人攻撃ではなく仕組みへの指摘であること
- 私的な場で率直に伝え、公開の場では慎重に扱うこと
この3条件は、SREのポストモーテム運用における「blameless（非難のない）ポストモーテム」の原則とほぼ同じです。
blamelessポストモーテムは、障害の原因を「誰がミスしたか」ではなく「どの仕組みが機能しなかったか」に焦点を当てる手法です。
たとえば本番デプロイでTerraformのapplyが意図しないリソースを削除した場合、blamelessな振り返りでは「誰が実行したか」ではなく「なぜレビュー段階でplan差分に気づけなかったか」を問います。
AWS Heroesのフィードバックサイクルも、サービスチームの担当者個人を追及するのではなく、機能や仕様そのものの改善を目的にしている点で構造が共通しています。
「聞く」側の設計がSLOレビューに近い
フィードバックを与えることは比較的簡単ですが、受け取って行動に変える側の設計はずっと難しいという指摘があります。
聞く側には「ノイズの中で意図を拾う」「わからなければ質問する」「一度止まって考える」という手順が必要です。
これはSREチームがSLOのエラーバジェット（許容できる障害の残り枠）を四半期ごとに見直す会議の進め方と重なります。
エラーバジェットの消費理由をアラート疲れやオンコール担当の主観だけで判断すると、本当に直すべきボトルネックを見誤ります。
そのため多くのSREプラクティスでは、振り返りの前に必ずオブザーバビリティ（システム内部の状態を外部から把握できる仕組み）のデータを揃えることを推奨しています。
具体的には、DatadogやAmazon CloudWatch、Grafanaなどで取得したレイテンシ・エラーレート・飽和度（リソース使用率）の時系列データを、感覚的な「重かった気がする」という主観より先に確認します。
つまり「聞く」という行為を個人の姿勢論で終わらせず、データという形に落として仕組み化することが、フィードバックを機能させる鍵になります。
AWSとGoogle Cloudの競争に見る「外部フィードバック」の実例
AWSが長年クラウド市場でシェアを維持できた背景には、開発者からの率直な指摘を製品改善に反映してきた経緯があります。
一方でGoogle Cloudは、AWSが複雑にしすぎた部分をシンプルにすることでシェアを伸ばしてきたという構図も指摘されています。
これはSREの現場でも参考になる比較軸です。
IaCツールのTerraformとPulumiを比較する際、多くのチームは「HCL（Terraform独自の設定言語）の学習コストが高い」というフィードバックを受けてPulumiがTypeScriptやPythonなど汎用言語で書ける設計を選んだ経緯があります。
つまりツール選定そのものが、既存ツールへのフィードバックの積み重ねの結果であるという見方ができます。
自分のチームがTerraformを使い続けるかPulumiに移行するかを検討する際も、「なぜ今のツールに不満があるのか」を具体的な行動レベルで書き出すプロセスが、良いフィードバックの条件と同じです。
今日から確認できること
障害対応やIaC運用のフィードバックループが機能しているかどうかは、いくつかの具体的なチェックポイントで判断できます。
1. 直近のポストモーテムに「個人名」ではなく「仕組み名」が主語になっているか確認する
2. SLOレビューの議事録に、感覚的なコメントだけでなくCloudWatchやDatadogのメトリクスへのリンクが貼られているか確認する
3. Terraform/Pulumiのplan差分レビューで、指摘事項がPR（プルリクエスト）のコメントとして具体的な行動に落ちているか確認する
4. AWSサポートやAWS re:Postへのフィードバック投稿履歴があるか、社内のナレッジ共有ツールで確認する
これらは特別なツールを導入しなくても、既存のGitHubリポジトリやIncident管理ツール（PagerDuty、Opsgenieなど）のテンプレートを見直すだけで確認できます。
ポストモーテムのテンプレートに「Blameless確認欄」や「メトリクス根拠欄」がなければ、次回の障害対応から追加してみるのが手早い一歩です。
まとめ
フィードバックという抽象的なテーマは、SREの現場では具体的な仕組みに翻訳できます。
- blamelessポストモーテムは「機能するフィードバック」の条件を組織プロセスに落とし込んだものです
- SLOレビューはメトリクスという客観データを介して「聞く」側の精度を上げる仕組みです
- IaCツールの選定履歴自体が、過去のフィードバックの蓄積結果として読み解けます
まずは直近のポストモーテムやSLOレビューの議事録を1件開き、主語が個人か仕組みか、根拠がメトリクスか感覚かを見直してみることから始められます。