はじめに
勤務先で今期から新しい行動評価制度が始まり、初めての自己評価を入力しました。グレードごとに7つの項目があり、自分の行動がどのグレードの水準にあたるかを1〜5で付ける仕組みです。
私は一人体制のSRE / platformエンジニアで、部下はいません。この立場で入力してみて感じたことを、個人的な感想として残しておきます。
技術者にも合っていると感じたところ
下位〜中位のグレードの定義は、職種を問わず通用する内容で、違和感なく自分の仕事を当てはめられました。特に次のような行動は、SREの仕事そのものだと感じました。
- 属人化していた作業を、手順・ルール・仕組みに変えて、担当が変わっても回るようにする
- 改善を型にして、数字と再現手順とセットで公開する
IaC化、手順書づくり、仕様駆動開発、コストや障害の記録など、普段やっていることがそのまま根拠になりました。
マネージャー寄りだと感じたところ
一方で、上位グレードになるほど「メンバーに方針を伝えて動かす」「メンバーのギャップを言語化して業務を任せる」「部門の予算や人の配分を決める」といった、部下やチームを持つことが前提の定義が増えていきます。
一人体制の技術者だと、ほかの項目で高い水準に届いていても、人材育成の項目だけが構造的に低くなってしまいます。実際、私の自己評価もそうなりました。
評価軸にない観点
逆に、技術者を評価するうえで大事だと思う次のような観点は、項目として直接は出てきませんでした。
- 技術判断の質（アーキテクチャ選定、トレードオフの説明）
- 信頼性の成果（障害件数、復旧時間、SLO）
- セキュリティやコストのリスク低減
- 技術負債の返済や、EOL対応などの将来への備え
これらはコメント欄に間接的に書き込むしかありませんでした。
専門職の道という考え方
多くの技術組織では、マネージャーとは別に専門職の道（Staff / Principal Engineerなど）が用意されています。そこでは影響力を「部下の数」ではなく、「技術方針で組織を動かす」「仕組みやプラットフォームで他チームの生産性を上げる」「設計レビューや発信で周囲の技術水準を上げる」といった形で測るのが一般的です。
勤務先の制度でも、上位グレードは役職が前提ではないと説明されていて、考え方としては専門職も想定されているようです。ただ、定義の文面がまだそれに追いついていない印象を受けました。
入力してみて気づいたこと
最初は普段の作業記録（ドキュメントやタスク管理）だけで評価しようとしたのですが、それだと「自分が何をしたか」の根拠しか集まりませんでした。上位グレードで問われるのは「他者や他部署に何が起きたか」なので、チャットのやり取りや会議の議事録まで見直して、ようやく根拠が揃いました。
日頃から次のような記録を残しておくと、評価のときに楽になると思います。
- 作ったツールや手順書を、誰が何回使い、何時間・いくら減ったか
- 他のメンバーや他部署からの反応、採用されたという報告
- 作った型を他チームに渡した日、相手、その後の状況
おわりに
評価制度は、作る側も運用しながら育てていくものだと思います。一人体制の専門職としてどう評価されるべきかは、上長と話しながら、自分なりの読み替えを探していくつもりです。同じように「評価項目が自分の仕事と合わない」と感じている技術者の方の参考になれば嬉しいです。
