TLとTLMのあいだ

chezou
·

@riywo さんからご恵贈いただいて、前々から積んでいた「スタッフエンジニアの道」を冬休みの課題図書よろしく読み進めている。

本当は、きちんと読み終わってから感想を自分のブログにでも書こうと思っていたのだが、読んでいるうちに色々と思うところが増えてきたので、dumpしておこうと思う。

この本は、いわゆる"Staff+ Engineer"と呼ばれるIndividual Contributor (IC) の上級職にまつわる話である。順番は色々あれど、Junior, Intermediate, Seniorの上に来るものという位置づけであると本には書いてある。

なお、Staff+がSeniorより「偉い」というわけではないのは、以下の本書の脚注で書かれている筆者の好きなSrの定義からもわかる。

「昇進するのを止め、現在の生産性、能力、アウトプットのレベルをキャリアの残りの期間継続しても後悔のないレベル」

ただ、Staff+と呼ばれるこのポジションに関する書籍がいろいろと出てきているのは理由がある。この本をいただくきっかけになったriywoさん、wataru さんとのご飯のきっかけにもなったのだが、Staff Engineer以降になると会社によっても何をやってるかばらばらになるし、道を見失いがちになるのである。

かくいう自分も、春にPrincipal Software Engineerにpromotionしてからというものの、やっていることは変わらないと思いきや、プレッシャーは増えて責任範囲も順調に拡大してきて、道を迷いそうになりながらも踏みとどまっているのが現状である。

Staff+が何をするのかというといろいろと書いてあるのだが、「大局的な思考を持ち、大きなプロジェクトを実行し、よい影響を与えるようなことをする」というのがざっくり良いまとめであると感じる。そのため、

戦略を立てたり、プロジェクトを立て直したり、標準を設定したりしている時間には、コーディングや新しいシステムのアーキテクチャを設計したりといった、ソフトウェアエンジニアとして評価されるような多くの仕事はできません。

という事実にも直面する。自分の与えられる影響を大きくするには、コードを書くことも大事だが、そうではない取り組みも大きい。これは、ステークホルダーが多かったり、重要度の高く困難なプロジェクトを割り当てられるのも大きい。

そう、結局は重要な技術的課題を解決するためになんでもやるのだ。こういうと、「高機能雑用」のある種正統進化だなあともさえ思えてくる。

当然、コミュニケーション力とやらも求められる。ラダーの上の方のエンジニアの機会費用は高いから、ちゃんとVPなどのサポートを得て(得続けて)、やるべきことをやりましょう、という話である。

これはある種の社内政治だなあ、うーんと思っていると、見透かされたように言われる。

エンジニアは時々、組織に関するスキルを「政治的なもの」として軽視することがあります。しかし、システムの一部である人間を考慮し、解決べき問題を明確に理解し、長期的な結果を把握し、優先事項についてトレードオフを行うといったスキルは、優れたエンジニアリングの一部です。自分の組織をどのようにうごかすかをわかっていなければ、あらゆる変革がはるかに困難になります。

そう、ゲームのルールが変わってきているのを直視しないといけないのである。今まではランダムエンカウントのターン制RPGをやっていたと思ったら、リアルタイム性が高くなってきた戦略シミュレーションになっていたのだ。それを示唆するように、本書でも霧のある戦争マップの中でマッピングせよ、みたいな話が出てくる。あー、FEの索敵マップね。社内の色々な関係者のマップ書いたり、プロジェクトのゴールに辿り着くまでのマップ書いたり、それを更新し続けたり。

これらは、ある意味では(大企業で大嫌いだった)社内政治とどう向き合うかという話に他ならない(そしてそれはData ScientistもSoftware Engineerも変わらない!)。結局は、ビジネスの営みはステークホルダーが色々といて、重要度が上がれば(予算がつくつかないは別にして)出てくる口の数は増える。そういう中では、今いるチームのアーキテクトとマネージャーとで週次である種の「現状認識会」をできていたのは、よかったのかもしれない。この間辞めたCXOのプロジェクトへの影響は、隣のプロジェクトにPdMのリソース持ってかれてる、などなど本書で言うところの、トポグラフィーマップを更新し続けていたのだ。

ある種の社内政治は、日本、アメリカ、エンプラ、スタートアップを問わず、どこでも発生しうる、というのは過去の経験でも感じていたし、Will Larsonの本でも言及されていた。

これ以外にも、技術ビジョンや戦略の立て方の話、他のメンバーのロールモデルになる話、どうやってリーダーシップを発揮するのか、みたいな話が本書には書かれており、自分の通ってきた道と過去の失敗の反省をしながら読んでいる。しかし、自著の「仕事ではじめる機械学習」もそう感じていたが、痛い目を見てはじめてわかる書籍に書かれた事の重みというのはあるのだなあ、と痛感する。

また、自分が直接の部下ではないが、MLチームの技術リードをすることになった関係で、色々ともがいた年でもあった。いかにチームを回るようにして、タスクブレイクダウンをし、そして来クオーターの計画を立てるのか。ある種のTLM的な感じでICのモチベーションを最大化するのに心を砕いたり、色々とはじめての挑戦も多く、正直に言って今までの経験があまり生きない一年だった。

そんな中本書を読むと、シニアに対するメンタリングで何ページも書かれていたのは、不要なアドバイスをしてはいけない、何を求められているかを解きほぐすのに労力を割くべきだし、アドバイスをしたくなったら(センシティブな情報は抜きにして)ブログやsocial mediaに書くのがいいだろう、と書かれている。耳が痛いなと思いながら、この文章をdumpしたのであった。

@chezou
落ち着いて、箸にも棒にもかからないことを書けるのっていいですね