ベンダーが開発したシステムを引き継ぎ、テックリードを任された直後にやったことをまとめる。
やったことは地味で、コードを読む、依存パッケージを点検する、役割の線引きを決める、の3つだった。派手な改善より先に、現状を把握することに時間を使った。振り返って、やっておけばよかったことも最後に書く。
背景
自分は医療系の会社で、社内の業務システムを開発している。システムは外部のベンダーが開発したもので、ローンチの直後に、技術面の責任者を自分が引き継ぐことになった。
当時の自分は独学でプログラミングを学んだだけで、開発の実務経験はなかった。AWSも名前を知っている程度だった。チームは少人数で、テックリードの動き方を教えてくれる人も、手引きも社内にはなかった。
テックリードについて書かれた本や記事はある。ただ、それが自分のチームの状況に当てはまるかは別の話なので、やりながら決めていくことになった。
引き継ぎは段階的に進んだ
ベンダーからの引き継ぎは、一度に切り替わったのではなく段階を踏んでいた。
| 段階 | ベンダーの関わり方 | 自分たちの動き | |---|---|---| | 1年目 | 開発の主体。自分たちはそのチームの中に入る | 教育を受けながら、学ぶことに集中する | | 2年目 | 何かあれば口を出す見守り役 | 自分たちだけでミーティングを開き、自分たちで結論を出す | | 終了後 | 関わりなし | すべて自分たちで判断する |
2年目の「自分たちで結論を出すが、見てくれている人がいる」期間は、当時は普通のことに感じていた。今思えば、ここが判断を自分たちに移すための練習期間になっていた。
最初にやったこと
1. コードを読む
技術面で最初に着手したのはコードの読み込みで、この時期の仕事の大半はこれだった。
引き継いだシステムは自分たちが設計したものではない。何がどこで何をしているかを把握していないと、修正の影響範囲も、依頼された改修の難しさも判断できない。変えることより、把握することを先にした。
2. 依存パッケージと設定を点検する
コードの読み込みと並行して、依存パッケージに既知の脆弱性がないかを確認した。
npm auditnpm audit は、依存しているパッケージに報告済みの脆弱性があるかを照合するコマンドである。アプリケーション自体の脆弱性を調べる診断とは別物で、分かるのは依存関係の範囲に限られる。それでも、引き継いだ時点の状態を知る入口としては手軽だった。合わせて設定の確認も行った。
規制のある業界のシステムを扱う以上、セキュリティの状態を知らないまま運用を続けるのは避けたかった。点検ではいくつか問題が見つかり、見つかったものは修正した。
大がかりなことはしていない。ただ、「現状を把握する → 問題を直す → 次に進む」という一連の流れを自分たちだけで回したのは、これが最初だった。
3. 役割の線引きを決める
体制が固まってからの分担は次のとおりである。
| 領域 | 担当 | |---|---| | 要件定義、要望の整理、画面設計、資料作成 | 業務担当のメンバー | | 実装、技術的な判断 | テックリード（自分） |
技術面の責任者が、要件を受け取って実装する側にいる。要件を出す人が上流、実装する人が下流という見方をすると、責任の所在と仕事の流れの向きが逆に見える形だった。
もともと同じ立場で一緒に教育を受けていたメンバー同士でこの分担になったため、お互いに慣れるまでしばらくかかった。結果としては、運用面と技術面を別の人が持つことで、それぞれに集中できる形になった。
テックリードの役割について分かったこと
3ヶ月ほど経って分かってきたのは、テックリードは「一番コードが書ける人」という意味ではないが、「コードを書かない人」でもない、ということだった。少なくとも自分の環境では、コードを書きながら、チームが動ける状態を作る役割だった。
少人数で、引き継いだばかりのシステムを抱えている状況では、一般的なテックリード像をそのまま当てはめることはできなかった。
うまくいかなかった点・やっておけばよかったこと
ベンダーがいるうちに「なぜそうなっているか」を聞いておく。 最後の引き継ぎはあっさり終わり、その後は分からないことが出ても聞ける相手がいなくなった。コードは読めば分かるが、その設計や手順にした理由はコードに書かれていない。実際、引き継いだリリースフローの意味を理解したのは、後になってからだった。見守り役でいてくれた期間に、理由を聞いて記録しておけばよかった。
役割の線引きを最初に書き出して共有する。 上の表のような分担は、やりながら固まっていったもので、慣れるまでに時間がかかった。今から同じ状況に入るなら、最初に表にして合意する。
相談相手を早めに持つ。 引き継ぎ後は、技術的な判断を同じ前提で話せる相手がいなかった。これを変えたのはAIツールで、最初に使ったのは Cursor だった。コードを書いてくれることよりも、実装の相談ができること、自分の中にある断片的な知識を1本の流れに整理してくれることが助けになった。今は設計の壁打ち、資料作成、開発の相談に使っている。使い方はClaude Codeを設計の壁打ち相手として使うに書いた。
なお、コードレビューの持ち方はこの記事では扱わない。コードレビューの記事に別にまとめている。
まとめ
引き継ぎ直後の時期に、やってよかったこと・やっておけばよかったことをチェックリストにすると次のようになる。
- [ ] 変える前に、まずコードを読んで全体を把握する
- [ ]
npm auditなどで依存パッケージの既知の脆弱性を確認し、見つかったものを直す - [ ] 設定を確認する
- [ ] 要件定義と実装・技術判断の担当を表にして共有する
- [ ] 前任者やベンダーがいるうちに、設計や手順の理由を聞いて記録する
- [ ] 技術的な相談ができる相手（AIツールを含む）を確保する
関連記事: