Tanya Reilly著「スタッフエンジニアの道」。読み終えてしばらく経ったいまも、いくつか頭に残っているところがある。整理がてら書いておく。

間違いは曖昧さより価値がある

これは個人的に「そうだよな」と思った部分だ。

ドキュメントを書くとき、設計を提案するとき、批判が怖くて表現を曖昧にしてしまうことがある。「〜を検討する余地があります」「〜も考えられます」みたいな書き方。でもそれって、読んだ側からすると何も言っていないに等しい。

自分はわりと意識して、多少冗長になっても具体的に書くようにしている。「このクエリは500ms以内に返すべき」「インデックスはここに追加する」みたいに。間違っていたとしても、具体的な記述があれば議論を始められる。曖昧なままだと、なんとなく合意したように見えて、実は何も決まっていない、ということになりがちだから。

本書はこれを明確に言語化していて、改めて「そう、これなんだよな」と思った。

コイントスで決める

IETF（Internet Engineering Task Force）の意思決定の話。対立する選択肢があって決まらないとき、コインを投げて決めたことがあるという。

最初は「さすがに極端では」と思ったけど、読み進めるとわかる。完璧な答えを探し続けることより、前に進むことを優先する、という判断だ。

実際、仕事の中でも「どちらでも大差ない、あとは決めの問題」という局面はある。そういうときに延々と議論するのは、むしろ非合理だ。「ラフ・コンセンサス」——全員が完全に納得しなくても、大まかに合意して進む——という考え方は、理屈としてよくわかる。

質問に答えるな、問題を解決しろ

ジュニアエンジニアが「フルネームを返すエンドポイントはありますか？」と聞く。シニアは「ない」とだけ答える。1時間後、またジュニアが来て「別のエンドポイントは？」と聞き、ようやく「/fulluserを使って」と言う。

このシニアの最初の答えは技術的には正しい。でも、リーダーとしては不十分だと本書は言う。

自分はどちら側にもなったことがある。ジュニアのとき、質問に正確に答えてもらったのに全然解決しなかった経験。シニア側になったとき、質問の文字面だけに答えてしまった経験。

「相手が本当に達成したいことは何か」を考えることは、意識しないと抜け落ちる。コードレビューでも同じで、文脈を無視した「この方法もありますよ」系のコメントは、親切なつもりで相手を混乱させることがある。

技術よりも「人間関係の難所」で差がつく

これが一番グッときた。

技術的な問題でプロジェクトが止まることは、実はそれほど多くない。たいていの場合、止まる理由は人間関係にある。互いにどう話せばいいかわからないチーム、誰も自分に権限があると思っていない意思決定、表に出ない権力争い。

スタッフエンジニアの影響力が最も発揮されるのは、こういう「誰もが及び腰になる領域」だという。技術的な正しさを主張するだけでなく、対立するチームの間に立って、合意形成を助ける。それは信頼の積み重ねの上に成り立つ仕事で、一朝一夕にはできない。でもだからこそ、価値がある。

技術力を磨くこととは別に、組織を動かす力を意識的に磨かないといけない、と思わされた。

留まることも戦略

テック業界では「転職でキャリアアップ」が半ば常識になっている。でも本書は、一箇所に長く留まることの価値を力説する。

自分の感覚としても、長くいられるに越したことはないと思っている。自分が下した決定の結果を数年後に直接見られる。組織の「OS」みたいなものが蓄積される。関係性が深まる。これは短期間では得られない。

ただ、「留まること」が「転職しないこと」を意味するわけではない。成長の機会がなくなったとか、方向性が合わなくなったとか、転職が正解になる局面はある。選択肢を持ちつつ、意図的に留まる——というのが現実的な考え方だと思う。