DevOpsエンジニアのスキル評価方法：方法論とルーブリック

DevOps評価における一般的な誤り

ほとんどのチームは、DevOpsの候補者をソフトウェアエンジニアと同じ方法で評価しています：コーディング演習です。しかしDevOpsは主にコーディングについてではありません。システム思考、トレードオフ判断、運用レジリエンスについてです。

候補者は素晴らしいTerraformを書くことができるかもしれませんが、深夜にデータベースのインシデント対応が入ったときに大失敗する可能性があります。一方で、コードが散らかった候補者が、ゾーン全体の障害に対して自動介入なしで耐え抜くシステムを設計できる場合もあります。

別のフレームワークが必要です。

DevOpsスキルが実際に職務遂行を予測するもの

1. システム思考と障害モード推論

候補者は障害モードに名前をつけることができますか？主動的にそれらの対策を設計できますか？

評価する内容： 簡単なアーキテクチャ（WebアプリがRDSと通信）を与えて、次のように聞きます：「ここで何が壊れますか？障害の影響範囲は何ですか？どのように軽減しますか？」Netflixのような複雑な設計を求めないでください。基本的なセットアップをいかに堅牢にするかを聞きましょう。

良い答え：「RDSは単一障害点です。フェイルオーバー用に読み取りレプリカを追加し、接続枯渇を防ぐため接続プールを追加します。アプリはステートレスであり、ロードバランサーの背後に配置します。データベースへの回路ブレーカーも追加します。」

弱い答え：「Kubernetesを使いましょう。」

2. 運用的実用性

候補者は実際に機能する最もシンプルなソリューションを選びますか？それとも最も豪華なツールに手を伸ばしますか？

評価する内容： 「毎日のバックアップジョブを実行する必要があります。Kubernetes CronJobまたはLambdaという2つのオプションがあります。チームには既存のKubernetesはありません。トレードオフについて説明してください。」

良い答え：「既にKubernetesを実行していない場合、Lambdaの方が運用は簡単です。動く部分が少なく、デバッグが容易で、CloudWatchの統合が組み込まれています。トレードオフは15分のタイムアウトとコールドスタート遅延ですが、バックアップには影響しません。私ならLambdaを使います。」

弱い答え：「ポータビリティが高いから常にKubernetesを使うべきです。」

3. 可観測性とデバッグ

候補者は監視を設計できますか？アラートからルート原因までの問題を追跡できますか？

評価する内容： ライブコーディングインタビューはここには適さないでしょう。代わりに、本番環境のアラートを与えます：「Postgresインスタンスのcpuが80%。パターンが見えません。診断結果は？」候補者に思考過程を説明させてください：どのクエリツールを使いますか、何を確認しますか、どの順序で？

良い答え：「まずpg_stat_statementsで最も遅いクエリを確認し、特定のアプリケーションエンドポイントと相関があるか確認し、次にインデックス統計をチェックしてインデックスが欠落していないか、膨張していないかを確認します。」

4. 自動化の判断

何を自動化すべきで、何を手動で行うべきかの判断ができますか？

評価する内容： 「1日に20回デプロイしますが、データベースマイグレーションは週1回だけです。マイグレーションをデプロイと同じ方法で自動化すべきですか？」

良い答え：「いいえ。自動化は、操作が頻繁で低リスクの場合に認知負荷を軽減します。マイグレーションは稀で高リスク - 実行前に人間がレビューして承認するべきです。また、まずドライ実行も必要です。」

弱い答え：「すべてを自動化しましょう。」

5. クラウドアーキテクチャのトレードオフ

AWS対Azure対GCPは機能ではなく、運用とコストの比較です。

評価する内容： シナリオを提示してコストと利益の分析を求めます。「マイクロサービスプラットフォームを構築しています。マネージドKubernetes（EKS/AKS/GKE）を使うべきですか、それとも自己管理型ですか？」

理想的な答え：「マネージドは小〜中規模チームに適しています。コントロールプレーン、更新、ネットワークを処理してくれます。トレードオフとしてコントロール性が低く、コストが若干高くなります。自己管理は専任チームと特定のネットワーク要件がある場合に向いています。」

評価の構成

パート1：テイクホームシナリオ（2時間）

アーキテクチャ図またはTerraformコードベースを、意図的なギャップやセキュリティ問題を含めて提供します。以下を求めてください：

• 問題を特定する
• トレードオフ分析とともに対策を提案する
• このシステムの監視戦略を描写する

これは非同期に実施でき、知識を大規模に測定できます。

パート2：ライブトラブルシューティング（45分）

シナリオ： 本番環境でレイテンシースパイクが発生。デバッグ方法を説明してください。

候補者が話し、あなたが聞きます。以下を評価します：

• 体系的なアプローチ（推測ではなく）
• 可観測性ツールの知識
• 優先順位付け（どこから調査するか）
• コミュニケーション（考えを説明できるか）

パート3：アーキテクチャに関する対話（30分）

制約や要件を提示します。「50TBのデータをゼロダウンタイムで新しいデータベースに移行する必要があります。アプローチは？」

これは判断力と実用性を測定します。正解はありません - 影響範囲、ロールバック計画、運用の複雑さについての推論を聞いています。

ルーブリック：採点フレームワーク

避けるべきこと

しないでください：

• DevOps候補者にLeetCode問題を解かせる。（スコアが良くても実務パフォーマンスを予測しません。）
• DevOpsを「ソフトウェアエンジニアリングの簡易版」として扱う。（異なるスキルセットです。）
• ツール知識の広さに焦点を当てる。（Kubernetes知識は他領域での運用能力を予測しません。）
• ライブインタビューを無視する。（問題について話す過程で推論が明らかになります。）

してください：

• 現実的な制約を提示する。（予算制限、市場投入時間、チームサイズ。）
• 事実ではなく判断力をテストする。（なぜTerraformをCloudFormationより選んだのか説明できるか？）
• 説明を記録する。（非同期のトラブルシューティング演習は推論を表面化しません、ライブなら表面化します。）

大規模なDevOps採用

5人以上のDevOpsエンジニアを採用している場合は、このルーブリックを使用した構造化評価プロセスを導入しましょう。シナリオを一度テンプレート化して再利用し、候補者間で結果を比較します。一貫性により信号性が向上します。セットアップを省略したい場合は、ClarityHireのDevOps評価テンプレートをそのまま使えます。K8s、Terraform、CI/CDのシナリオと重み付けされた採点ルーブリックが最初から組み込まれています。

より深いスキル固有の評価については、AWS対Azure対GCPテストフレームワークを確認してクラウド固有のギャップを発見してください。