「来月からテックリードをお願いします」
そう言われた瞬間、頭に浮かぶのは肩書きの重さより「で、何から手をつけるのか」という素朴な問いではないでしょうか。
役割の定義を読んでも、月曜の朝に最初に開くべきものまでは書いてありません。
私自身もテックリードを目指して学んでいる立場なので、この空白がいちばん怖いところ。
そもそもテックリードがどこまでを担う役割なのかは、以前に整理したこちらをどうぞ。
そこで今回は、着任から最初の90日をどう設計するかを、公開されている一次情報をたどって整理しました。
最初の90日は「変えない期間」として使う
新任リーダーが最初にやりがちなのが、目についた問題をすぐ直しにいくこと。
Will Larson は CTO・VP Engineering の着任期を扱った記事で、「変えにいく前に、いま動いている組織とシステムを理解する」ことを繰り返し説いています。
The first 90 days as CTO or VP Engineering（Will Larson）
理解を飛ばして手を動かすと、短期的には成果が出たように見える。
けれど数か月後には信頼を失った状態で残りの任期を過ごすことになる、というのが同記事の指摘です。
役職はひとつ上の話ですが、「速く動く」より「正しく見立てる」が先という順番はテックリードでもそのまま通用します。
最初の90日は成果を出す期間ではなく、成果を出せる状態を作る期間。
そう割り切ってしまうほうが、結果的に早く走り出せるのです。
着任した状況を見立てる
「理解する」といっても、何を理解すればいいのか。
ここで役に立つのが、Michael D. Watkins が『The First 90 Days』で示したSTARSという見立ての枠組みです。
Picking the Right Transition Strategy（Michael D. Watkins・Harvard Business Review 2009年1月号）
STARS は start-up・turnaround・accelerated growth・realignment・sustaining success の頭文字を取ったもので、着任先がどの状況にあるかで打ち手が変わる、という考え方。
たとえば立ち上げ直後のチームなら、まず何もない土台を作る仕事が中心になります。
一方で成功が続いているチームに入ったなら、動いているものを壊さないことのほうが優先度は高い。
同じ「テックリード着任」でも、前者で慎重に振る舞いすぎれば遅く、後者で大胆に動けば事故になるわけです。
Watkins 自身も、担当ごとに STARS のレンズで評価し直すと良いと述べています。
チーム全体を一言で分類するのではなく、「この機能は立ち上げ、あの基盤は立て直し」と分けて見るほうが実態に近いのではないでしょうか。
30・60・90 で区切って置くもの
見立てができたら、次は時間の割り振り。
一般に語られる 30-60-90 の型を、テックリードの文脈に置き直すとこうなります。
最初の30日は「聞く」に振る
この期間の成果物は、コードでも設計書でもありません。
チームの誰が何を持っているか、どこが痛みになっているか、直近で何が燃えたかを、一人ずつ話を聞いて集めることが仕事になります。
このとき「前職ではこうしていました」を持ち込むのはまだ早い。
LeadDev の新任マネージャー向けガイドでも、新しい環境ではできるだけ聞く側に回りつつ、軽い議題だけ用意しておく進め方が勧められていました。
A new manager's guide to a 30-60-90-day plan（Franziska Hinkelmann・LeadDev）
あわせて、ビルドが通るまでの手順を自分で一度なぞっておくと効きます。
新入りの視点で詰まった箇所は、そのままチームの改善候補になるのです。
次の30日は「小さく決めて出す」
60日目までに欲しいのは、大きな成果ではなく「この人が決めると話が前に進む」という実績。
長く放置されている小さな技術判断をひとつ拾い、根拠を書いて決め切る。
決めた内容そのものより、決め方をチームに見せることのほうが資産になります。
判断の記録を残す習慣は、後から入る人の助けにもなりますね。
最後の30日で「仕組みに寄せる」
90日目が近づいたら、自分が手で回していたものを仕組みへ移していきます。
レビューの基準、リリースの手順、障害時の連絡先。
自分がいないと止まる状態を、90日かけて減らしていくのが、この期間の狙いになります。
ここまで来て初めて、着任時に気になっていた大きな課題へ手を伸ばせる段階。
障害時の連絡先を仕組みにするなら、誰が指揮を執るかまで決めておくと安心でしょう。
つまずきやすい3つの落とし穴
型が分かっていても、実際には同じところで転ぶと言われています。
ひとつ目が、技術的な正しさだけで押し切ろうとすること。
Patrick Kua は『Talking with Tech Leads』で、テックリードの責任は「ソフトウェアを届ける能力に長けていること」をはるかに超えると述べ、コミュニケーション・対立の解消・委譲といった土台の技能を挙げています。
Talking with Tech Leads（Patrick Kua・Thoughtworks）
ふたつ目は、コードを書く時間をゼロにしてしまうこと。
手を離しすぎると設計の勘所が鈍り、判断の質そのものが落ちていきます。
この匙加減については、シニアエンジニアとの境界線を扱った記事でも触れました。
そして三つ目が、期待値のすり合わせを後回しにすること。
自分が何を決めてよくて、何を上長へ上げるのか。
この線引きを最初の30日で言葉にしておかないと、90日目に「そこまで任せたつもりはなかった」という食い違いが出てくるのです。
最後に
新任テックリードの最初の90日は、見立て・小さな決断・仕組み化の3段構えで組むと迷いにくくなります。
まず STARS で状況を見立て、30日は聞くことに振り、60日で決め方を見せ、90日で自分依存を減らす。
どれも大きな武器は要らず、順番を守るだけで効くのが、この型の良いところ。
来月から任される立場になったなら、まずはカレンダーに1on1の枠を並べるところから始めてみてください。
以上です。
コメントを残す