もはや「何をすべきか」すら曖昧なシニアエンジニアが、組織から評価を得続ける方法

前回の記事では、Tebikiのスタッフエンジニアとして重視している「事に向かう」考え方や、事業に技術で貢献するための心得、そしてメンタル維持の秘訣について書きました。

最終回となる今回は、この抽象的な役割が「組織でどのように評価されるのか」という問いに対する私の考え、そして現在私自身が抱える課題である「次のスタッフエンジニアをどう見出すか」、最後に「この先どこへ向かうのか」という問いについて、今の考えをまとめたいと思います。

• keyboard_arrow_down 「何を、なぜ、どんな価値のためにやるのか」という仮説を立てる
• keyboard_arrow_down 次のスタッフエンジニアを見出すという現在の課題
• keyboard_arrow_down まとめ：この先どこへ向かうのか

評価とは、仮説に基づくものです。新人だろうとスタッフエンジニアだろうと営業部長だろうと、仮説が検証され評価が発生します。

しかし、裁量が広がるにつれて、役割は抽象度を増し、仮説を検証することが難しくなってきます。例えば、人事制度において、スタッフエンジニアを「専門領域の1年後のあるべき姿を定義し、中核となる価値をつくれる」と定義したとします。しかし、何を持って「中核となる価値」と言えるのか。また、その仮説はどのように検証できるのか。スタッフエンジニアはこれらを自分で決定し、自分で説明します。なぜなら、自ら考えて実行することが仕事であり、組織にはその機能が自分以外に無いと考えるからです。

私の場合、メインのプロダクト開発以外に開発してきたことには、CIS Controlsをベースとした社内セキュリティ統制のための方針策定、AWSアカウント統制のためのControl Tower導入と移行、IAM Identity Centerの導入と移行（結果的に、AIエージェントからAmazon Bedrockを活用する際の統制としても有効となった）、セキュリティログを管理するためのSIEM構築などがあります。

これらを実現することで、どのような状態を目指しており、何が価値で、なぜやる必要があるのか。仮説を立てることがスタッフエンジニアの評価の開始地点です。

仮に私がスタッフエンジニアの評価をする場合は、彼らが立てる仮説に着目し、方向性をキャリブレーションします。スタッフエンジニアに求めたいことは、事業レベル、組織レベルのインパクトであるため、技術的な観点だけではなく、今後の事業戦略と組織構想の観点から、仮説が事業や組織にどのようなインパクトを与えるのかを議論します。私はこうした視点を持ち、逆算して施策を考えていました。

社内エンジニアの「ロールモデル」としての影響力を自覚する

スタッフエンジニアは、意図せずも社内エンジニアのロールモデル、鏡となってしまう場合があります。そのため、いつでも頼れる存在として社内に存在しているか、他のメンバーと信頼関係を築くことができているかも、評価の軸になると思います。それだけでは足りないですが、それらは必須の要素という見方です。些細なことでも組織に雰囲気が醸成されます。スタッフエンジニアが手を抜けば他のメンバーも手を抜き、スタッフエンジニアが話を最後まで聞かなければ相談されなくなります。また、話を聞くことは大前提とし、技術的なディスカッションでは遠慮なく懸念点を指摘します。遠慮がちに指摘することは良いことだと思っていません。指摘することに遠慮が必要であるかのような雰囲気が醸成されるからです。物事になるべくフラットな態度で、チームのために行動することが重要であると考えます。その積み重ねが、周囲からの信頼を獲得するための第一歩だと考えています。

スタッフエンジニアだからといって、特別な評価プロセスはない

まとめると、スタッフエンジニアを評価するプロセスには、他のロールと比較して特別なことはありません。仮説と検証のプロセスがあるだけだと考えます。成果は、事業と組織に対するインパクトで評価します。技術は、事業と組織に還元されて初めて価値となるため、技術的に正しいことだけではスタッフエンジニアの評価に値しないはずです。

ところでインパクトとは？評価におけるインパクトとは、評価者が代弁できる成果であると言い換えることができると考えています。評価者がメンバーの成果を語れるようになるためには、仮説の意図と実績を、互いに認知している状態が必要です。最後に、社内のロールモデルとして適任であるかも重要であると考えます。

これは私の現在の課題です。これから書くことは、経験に基づく話ではなく、ただの考えです。

スタッフエンジニアの重要な仕事の1つに、次のスタッフエンジニアを見出すことがあります。組織やプロダクトの規模が一定なのであれば、その必要は無いかもしれません。しかし、日々それらが拡大している場合には、必要になります。次のスタッフエンジニアはいったいどうやって見つければよいのでしょうか。スタッフエンジニア自身が人事権を有しているわけではないため、直接的になにかポストを与えるというようなことにはなりません。

ただ、この「ポストを与える」という考え方に筋の悪さがあると思っています。リーダーとは、集団に自然発生する現象であると考えられます。これは、マネージャー、そして、スタッフエンジニアも同じであると考えます。人々を目的の単位でまとめると、そこにリーダーが自然発生します。ポイントは、人々のまとまりに裁量をセットで与えることです。裁量のないまとまりにリーダーは発生しません。

これを前提にすると、スタッフエンジニアが自然発生しやすい集団をつくることが鍵となるという考えになります。では、どのような集団なら良いでしょうか。私の現在の考えでは、恣意的な集団に対し、技術的な意思決定とオーナーシップを与えて結果までたどり着いてもらうことです。この集団のアウトプットは、全てのエンジニアが見ることとします。既存のスタッフエンジニアによる視点も入ります。どのような過程にあったとしても、あくまでこの課題のオーナーシップは集団にあるとします。彼らの最終的な意思決定は、個人単位で賛成するしないに関わらず、全社でコミットします。これが次のスタッフエンジニアの誕生に欠かせないプロセスなのではないかと考えているところです。また、事業として行うプロセスですから、集団を構成するメンバーは、自由参加とするよりも見込みのある人材を恣意的に選択すべきだと考えています。

しかし、ポストが与えられることで能力が開花するというパターンもありそうです。例えば、スタッフエンジニアが抱えている未解決テーマをそのままとある個人に渡すといったことも考えられます。これは比較的簡単に始められ、責任も取りやすいかもしれません。一方で、単にメンターとメンティーという関係になりやすくそれ以上になりづらい気もしており、そのあたりはさじ加減が難しいと感じます。現役スタッフエンジニアの方々はどのようにお考えでしょうか？

この思考実験の結果については、またどこかで書けたらと思います。

さて、これまで過去と現在を書き、次はこれからのことを書きます。

以前、Tebikiに入社した際に、会社ブログに10年のコミットメントという内容の記事を書きました。現在、そのうちの1年半が経過したところです。私は、残りの8年半をスタッフエンジニアとして過ごすのでしょうか。その頃の私は50代を迎えますが、サラリーマンとして生きていくことを考えると、そこからまだ10年以上の労働時間が残されている可能性があります。

今どのような景色が見えているのかというと、Tebikiに入社してからというもの、まだ景色の変化を感じません。たったの1年半では、気持ちの変化や、やりたいことの変化といったものはありませんでした。スタッフエンジニアは、成果が顕在化するまで時間がかかるテーマに取り組むことが多くなるかもしれません。なんだか日々、自分は本当に価値のあることができているのだろうかと不安になることがあります。

以前マネージャーを務めていたときにも同じ感情を抱いたことを覚えています。小さな成功体験を日々感じられることが、どれだけ精神を安定させることに寄与するかに気付かされます。こんなことを言うと生意気かもしれませんが、今となっては、成功体験は自分の納得感でしか得ることができないと感じています。

そう考えると、可能性は無限大だなと感じ、想像すらできません。そもそも、私は自分の未来を計画することがあまり得意ではありません。これは前回書いたとおりですが、今見える景色から何かを感じ取り、現状を認識し、進みたい方向へ足を伸ばしてきたという、言い方を変えれば、無計画であったというわけです。

ですから、ひとまず1年とか、3年先のことを考えるのが良いのだろうと思います。事業計画も、大体3年以内の範囲に収まることが多いですよね。あまり先のことを考えても、不確実性が高すぎるということです。ひとまず、3年やってみたらどうか。まだ20年ほどの時間がありますから、途方もありません。

全3回の記事で、私のこれまでのキャリア選択から、現在Tebikiのスタッフエンジニアとして何を考えているのかを書かせていただききました。この先、何か変化が訪れるとすれば、スタッフエンジニアとして自分が納得感を得られたときなのでしょうかね。今はただ、ただ漠然と、まだまだ事業や組織に与える価値が小さい存在であると感じています。スタッフエンジニア道という感じがしますね。