Overview
4月から2年間の Tech Lead の役割を降りて 1 エンジニア（最近だと IC って言うのが正式名称なんですかね）に戻りました。
元々飽き性な人間なので、同じ役割をずっと担っていると慣れとダレが生じてしまってチームに悪影響があったので去年くらいから一旦1エンジニアに戻してもらうことはマネージャーと相談していた内容で、色々と状況が許したのでようやく accept されました。
Tech Lead やってみての振り返りも書こうと思いましたが、以下にまとめてありますので割愛して、一人のエンジニアに戻ってみての振り返りをします。
エンジニアに戻ってみて変わったこと
Tech Lead から 1 エンジニアに役割を移してみてに変わったなと思うことは以下の二点です。
- リソース(=兵站)を意識するようになったこと。
- アロケーションコストは高い。
- 事業のあらゆるところに優先順位が存在することを理解し、ものごとをものごとを進めるようになったこと。
- 優先順位に基づいた意思決定がされ、原則現場レベルで変更できる幅は非常に小さい。
- 変更も可能だが、優先順位の変更コストはめちゃくちゃ高く、変える場合は変えたい側に説明責任が存在する。
まず1つ目の兵站についてです。むしろこれが一番変わったと言っても過言ではないかもしれません。
Tech Lead になるまでにも小さな案件からそれなりに大きな機能まで設計してきたことはありましたが、Tech Lead を担うようになって、自分が関わるプロジェクトにどれくらいのリソースが割り当てられて、それが実際のプロジェクトの推進にどう影響するのか？ということを目の当たりにし、思い通りにコトが進まないことも多いなと感じる機会も多くありました。
特に事業全体から見て優先度の高い案件をこなしてるときは、比較的優先的に兵站が確保されますが、そうでない時のマネジメントには結構苦労しました。
iOS の開発をしたいときに別案件でリソースが確保されない、みたいなケースはあるあるだと思います。自分が iOS を書ければ話は早いのかもしれませんが、実際そうじゃないケースの方が多いと思うのでこればっかりはどうしようもありません。
2年前くらいまではリソースが優先的に配分されることが多かったのですが、ラスト半年くらいは本当にやりくりに頭を悩ませました。それもあってか、事前準備だったり、ステークホルダーを最小にしたり、進め方や開発スタイルでカバーする癖がきました。結局のところないものねだりしても状況は好転しない + リソースは常に不足するものなので仕組みや進め方で”なんとかする”しかないんですね。
余談ですが、兵站は単純なリソースだけではなく、補給線も含めたリソース確保のパイプラインの役割もあるので、自分の手をあけるためという名目のもと、採用回りも積極的に顔を出すようになりました。元々そんなに積極的な方ではなかったですが、ここ半年は今まで真面目に関わってこなかった領域として「現職に誘う」というムーブを取れるようになったことは自分の中では1つ変わったポイントでした。
次に2つ目ですが、この役割を通して何事にも「優先順位」があり、その優先順位にしたがって全ての判断されている、という言語化すると当たり前すぎることを理解した上で業務を進めるようになったことです。
上述したリソースの話に関連して、リソースは優先順位が高いものからアロケーションされていくものであるので、自分たちのプロジェクトに割り当てられたリソースの中でどう回すのか？言うなれば与えられた手札でどう戦うのか？という思考をベースに物事を考えるようになりましたが、都度事業全体のロードマップを俯瞰してどこにどれくらい配分されそうで、その配分を変えるように依頼するにもプロセスが必要で、その説得プロセスを選択するコストの妥当性に目が行くようになりました。
ざっくりいうと、「優先順位を変える説明コストはめちゃくちゃ高くつくので、むやみやらとリソース欲しがらない」と言うことです。
このような考えを持ちつつも、現場レベルでリソースの上限を決めてできることを狭めてしまうことはプロダクト開発全体として見ると悪手であり、良いプロダクトが開発できないことに繋がってしまうので、現場だけで視野を完結させてしまうのは考えものです。
一方で、繰り返し述べているようにリソースは常に有限・不足しており満ち足りてることなどなく、特に人的リソースのアロケーションのリードタイムは想像以上に長いし水物である、と言うことを理解をしないと、リソース不足でやりたいことが実現できないというだけでものごとは前進していないという状況が続いてしまいます。
結局さくさく進んでいた時期と全然進まなかった時期を両方を経験して学んだことは、あくまで現場レベルでできることは、実現したいことに対してギャップが存在することを説明し、どれくらいのリソースがあればできるのかは説明すること、そしてリソースが確保されない事情も あらかじめ 理解した上で説明責任を果たし、現場レベルでできることを進める、ということ以外にないんだなーと考えるに至りました。
できる幅を進んで狭くすべしというわけではないですが、スコープとマイルストーンがなぜ説明する時に必要なのか、今できることで達成したいアウトカム（の一部）は実現できないのか？など現場から逆算して事業について考える機会をもらったのは Lead ポジションをしてみてよかったポイントだと思います。
エンジニアに戻って変わらなかったこと
逆に変わらなかったことはなんなのか？というを振り返ってみると以下でした。
- コード結局そんなに書いてない。
- 全体の整理 & ボール拾い役になる。
結局自分の性分なのかな、と思うこともありますが、コードを書く時間よりもその前の全体の状況整理だったり、そもそも何がやりたいんだっけ？というところの割り出し、ドキュメント整備、スケジュールの見積もり、もし厳しい場合は締め切りに間に合う範囲でストーリーを実現できる最小スコープを考えることに時間を割くことが増えています（※現在進行形）
こぼれ落ちそうな要件だったり、作業を一旦引き受けて決めたり誰かに回したり、作業としては泥臭いことをひたすらやるということを続けています。
これを続けてるといわゆるアジャイル？と呼ばれてる手法を実践しようとすればするほど、そこからは離れていくような感覚すら味わいました。どの粒度が個人やチームに適した形なのかはそれこそケースバイケースなのではっきりとはわかりませんが、自分が抱えてる案件レベルで言うともはやガントチャートなしにスケジュール出すことも、スコープ決めることもできませんし、この情報をなしにそれこそリソースアロケーションの交渉はできないなと思ってます。 （逆にできる人はどうやって説明してるのか？その方法を教えてほしさすらあります）
チームの中で若干ウィークポイントになりそうなところ、ボールが宙に浮いているところを見つけてカバーし、また次のボールを拾って〜みたいな動きは相変わらずで、結局疲れるけどできるから仕方ないか、みたいな感じで続けていました。
正直こればっかりやってると疲れるので、僕よりもっとこのボール拾いをできる人を連れてきたい気持ちが日に日に強まっています笑
まとめ
長々と文章を書きましたが、結局 Tech Lead のポジションをやった前後で事業に対する解像度は変化したこと、一方で現場に戻ってもやってることは大して変わらず、結局のところ自分の得意な領域は「ボール拾い」であったことがわかった、ということが書きたかった内容です。
事業全体を見たり、数字を読み解いたり、そこから仮説を立てて意思決定していくことはまだまだ道半ばでできませんが、現場にかかる意思決定がどういうプロセスでされていて、その背景、コンテキストを理解しようと努めることができるようになったのは個人のキャリアを考えても、ポジティブなことが多かったので、このエントリを読んだ方で、もしチャンスがあるなら積極的にこういったポジションを受けてみてもいいのではないかな？と思います。
うまく行くにしろ行かないにしろ、前後で事業や会社に対する解像度は多少変化しますし、変化した結果、できることやわかることが増えると、様々なところを構造的に見ることができるようになって面白かったりします。この面白さばっかりはうまく説明はできませんが、やって損はないと思います。ちなみにしんどいことはめちゃくちゃ多いと思います笑
