任命されたのは、システムローンチの直後だった。
ベンダーから「これからは技術責任者として」みたいな言い方で引き継ぎが完了した。内心は「まあそうだろうな、他にいないし」だった。クールに受け取った。表には出さなかった。
その日から、鉄仮面をつけた。
横並びから縦関係になる違和感
入社当初は3人横並びだった。自分、若手、超若手。全員でベンダーの教育を受けていた。
それが独立後、自分がテックリードと主任を兼ねる形になった。若手は運用管理担当に、超若手は修行の日々に、という役割分担になった。
昨日まで同じ立場だった人間が、今日から部下になる。
難しかったのは、役割が変わっても「人間関係」は変わらないことだ。急に厳しくするのは簡単じゃない。でも「テックリード」という役職に責任が伴う以上、それをやらなければならなかった。望むところだったし、やると決めた。
それが鉄仮面の始まりだった。
逆転した要件フロー
体制が固まってから、構造的な奇妙さに気づいた。
普通、要件は上位から下りてくる。ビジネス側や上司が「こういう機能が欲しい」と言って、開発が実装する。
でも自分の環境は違った。若手が業務担当として要件定義をやり、それが自分に降りてきて、自分が実装する。技術的な責任者は自分のはずなのに、仕事のフローとしては若手が上流にいる。
お互いにやりにくかっただろうと思う。自分も最初は慣れなかった。「自分に要件を渡してくる」という関係性が、昨日まで横並びだった相手との間で成立している。それが日常になるまで、しばらくかかった。
誰も教えてくれなかった
「最初の1ヶ月は変えることより把握することに集中しろ」——そんなことを言ってくれる先輩はいなかった。
手引きもなかった。テックリードがどう動くべきかを書いた本や記事はあるが、「自分のチームの今の状況」に当てはまるかどうかは別の話だ。
結局、自分でやるしかなかった。
最初にやったこと：コードを読んだ、脆弱性を洗った
技術面で最初に着手したのは、コードの読み込みと脆弱性診断だった。
コードはとにかく読んだ。ベンダーから引き継いだシステムは、自分たちが設計したものじゃない。何がどこで何をしているか、全部頭に入れていかないと、何も判断できない。コードを読むことが、この時期の仕事の大半だった。
それと並行して、脆弱性診断をやった。npm audit や依存パッケージの脆弱性チェック、設定の確認。規制産業のシステムを扱う以上、セキュリティの状態を把握するのは後回しにできないと思っていた。
診断でいくつか問題が出た。出たものは修正した。「問題を把握して、修正して、次に進む」というサイクルをここで初めてやった。
大げさなことは何もしていない。でもこれが最初の仕事だった。
「テックリードとは何か」をやりながら理解した
3ヶ月経って、少しずつわかってきたことがある。
テックリードの仕事は「一番コードが書ける人」じゃない。でも「チームのためにコードを書かない」でもない。少なくとも自分の環境では、コードを書きながら、チームが動ける状態を作る役割だった。
手引きがなかったのはしんどかったが、手引きがあっても同じようにはできなかったと思う。3人しかいない、ベンダーから引き継いだばかりのシステム、逆転した要件フロー——その組み合わせは自分だけのものだった。
答えは自分で出すしかなかった。今もそれは変わっていない。
関連記事: