【新米インフラリーダー #4】レビュー指摘で相手を萎縮させない伝え方
設計書や手順書をレビューするとき、結論を指摘として渡す前に意図とロジックを聞く。品質基準を曖昧にせず、相手を萎縮させにくい伝え方を整理します。
Personal
technical
publication
Infrastructure / AWS / PM / AI
Field notes
from practice
Articles
技術の説明だけでなく、判断の前提、進め方、運用まで含めて整理します。
設計書や手順書をレビューするとき、結論を指摘として渡す前に意図とロジックを聞く。品質基準を曖昧にせず、相手を萎縮させにくい伝え方を整理します。
若手へ正解を渡す前に、空・雨・傘で本人の事実・解釈・行動を確認する方法と、リーダーが判断を引き取る境界を整理します。
若手へ本番作業を任せる際に、実行・報告・判断を分け、報告タイミング、介入条件、委任範囲を広げる基準を実務経験から整理します。
前提変更時に若手が判断材料を整理できるよう、現状・インパクト・対策、事実と推測、二次災害の確認方法を実務経験から整理します。
インフラの基本設計書レビューで確認したい7観点を、監視と業務影響が結び付いていなかった実体験から整理します。
インフラ要件定義で最初に確認したい7項目を、実際の認識ずれをもとに整理します。目的、スコープ、現行環境、対応境界、優先順位、運用、マイルストーンを後工程の判断軸として残す方法です。
AWS移行の初期に合意したい目的、対象範囲、停止時間、切戻し条件、現行環境調査、判断者を実務の順番で整理します。
インフラPMは、進捗管理だけをする仕事ではありません。AWS移行やサーバ更改を例に、技術・顧客・運用をつなぐ役割と、現場で確認したい判断軸を整理します。
AI時代にインフラエンジニアの仕事はどう変わるのか。AIを伴走者として使い、設計・運用・レビュー支援に活かす考え方を実務目線で整理します。
インフラエンジニアの仕事は地味に見えますが、実務では確認、調整、説明など人との関わりが多い仕事です。現場感を交えて整理します。