※この記事は、2022 Speee Advent Calendar18日目の記事です。 昨日の記事はこちら
はじめまして、Housii（ハウシー）という完全会員制の家探しマッチングプラットフォームの開発チームで、テックリードとして働いている八木です。 Housiiの開発チームには約1年半前から携わらせていただいています。 前職では、3年半ほど保守をメインに担当していました。発生したトラブルと向き合っていく日々だったのですが、トラブルを最小限に抑え、価値を作ることにエンジニアが楽しく向き合っていくためにはどうしていくべきかを追求していきたかったので、プロダクトの初期フェーズから安全に価値を作っていく方法を模索しながら作っていくことにチャレンジすることができる環境を求めている中でSpeeeに約1年半前にJOINしました！ 転職して1年半ほど経ち、私自身はテックリードとしての役割を担わせていただけるようになりました。 現状、テックリードの役割は、プロダクトを事業目標に合わせて成長させるために、開発チームとしてのアウトカムを最大化させることだと考えています。 その役割を担っていく上で、振り返ってみるとエンジニアとして視座が上がったことで、役割を全うしていくために、チームとしてのアクションを設定でき、それをチームメンバーと一緒に進めていけるようになったなと感じています。 振り返ってみると、テックリード役割を担う上での最初の一歩目としては、プロダクト開発をするエンジニアとしての視座を上げることを意識するのが良いのではないかと思ったので、今回はそういった話をブログにしたいと思います。 これからエンジニアとしてチームをリードしていきたいと思っている方や、テックリードの人って結局何ができればいいんだろうという若手のエンジニアの方の参考に少しでもなれば幸いです。
エンジニアとして視座を上げるということ
自分の解釈では、プロダクト開発をしていく上で、エンジニアとして視座を上げるということは、事業を通して実現したいミッションをプロダクトを通してどう実現していくか？という問いに対して、長い時間軸で向き合うということだと考えています。 長い時間軸で向き合うことで、プロダクトのx年後の未来像に対しての仮説を立てることができ、x年後のプロダクトの理想状態が決定できます。 その理想状態に対して、プロダクトの現在地と比較して足りないものを考えることで、現状のアーキテクチャで実現できるのか、現状のチーム体制で実現できるのかを考えることができます。 ただ、ここで気をつけなければならないと考えているのは時間軸が伸びれば伸びるほど実行するかどうかが不確実なことが増えてくるということだと思います。当たり前のことを言ってはいるのですが、その不確実なものに対しての対処の仕方が重要だと思っています。 自分はやる、やらない、いつまではやらないに分類して考えております。 開発チームのアウトカムを最大化することに向き合っているので、最大化するためには必要な情報が出揃った状態で実行することで本当に価値提供できるのか?という問いに対して答えられる状態で意思決定をする必要があると思っています。状況によっては、意思決定をしにくいということもありえると思っていますが、それは、意思決定に必要な情報が足りず解決したい課題の本質的な部分が見えていない状態だと思っています。 要は、打ち手の成功確率、アウトカムを最大化できる可能性が低い状態だと言えます。 なので、プロダクトとして実行するアウトカムに対して、成功確率を常に高い状態で意思決定し、チームがそこに向き合うために、現時点ではいつまではやらないという意思決定を先延ばしにすることを決めるという選択肢も明確に持つことを大事にしています。 このように、テックリードとして開発チームのアウトカムを最大化させることに向き合うためには、事業のミッションや、プロダクトで実現したい未来像、から紐付けて現在地がどうなのか？考えることで、自信を持って技術的な意思決定を行うことができると思っています。 故に、まず最初の一歩目としてより長い時間軸でプロダクトを俯瞰してみることから始めると良いのかなと考えています。
時間軸を伸ばして考えるようになったきっかけ
自分の場合は、テックリードとしての役割を担っていく上で、何から手をつけて良いかわからない状態からスタートしました。 もう少し具体化すると、なんとなくリファクタは必要そうだなとか、今のアーキテクチャだとスケールできなそうだなという感覚がふわっと頭の中にある程度で課題を明確化できていませんでした。 また、個人としてもアーキテクチャの変更や触ったことのない技術を、仕事を通じてもっと挑戦していきたいという思いもありました。 上司との1on1でその月に注力することを壁打して決めていたのですが、より大きな技術的な意思決定をするにはどういう考え方を持つと良いかを話していき、より大きいとはどういうことかについて「時間軸」と「影響範囲」が広がるほど大きな意思決定と言えると明確に認識することができたので、テーマを「未来の時間を意識して技術的な意思決定ができるように」に決めたことがきっかけです。 未来の時間を意識した技術的な意思決定ができれば、より大きな技術課題に向き合う環境を自分から作り出せるというイメージも湧いたので、そこから時間軸を意識してアクションを起こすためにはどういうことかを考えるようになりました。 まとめると、より大きな技術課題に挑戦できる環境を生み出していくためには、事業状況を把握した上でのプロダクトの理想状態はなんなのか、その理想状態に対してなぜ必要なのかを一貫して言語化できる状態を作るために、不確実な未来を考慮した上での時間軸を伸ばして考える必要があることを学べたことがきっかけでした。
時間軸を伸ばして考えたことで取れたアクション
ここでは、そういったテックリードとしての役割を担う中で、こういう取り組みを進めることができた、という話をしたいと思います。 今後のプロダクトのロードマップを整備していくと、事業責任者との対話を通じて理想状態をキャッチアップしていく中で、事業としての3年後の理想状態やそこに行くための道筋がある程度明確になっていることがわかりました。 一方でプロダクトとしては、ミッションと半年後にプロダクトで実現したい世界観はあったものの、そこまでの過程や必要な技術的な調査などは明確になっていませんでした。また、3年といった時間軸や、1年後2年後はどうなっているべきかが決まっていない状態でした。 そこで、いきなり3年後というのは流石に難しいので、まずは半年後のプロダクトの理想状態を掲げ、そこに対して技術的観点で仕込んでおくべきことがないのか？という観点を考えて、理想状態に行き着くための道筋を明らかにすることにしました。 前述の通り、不確実性があるなかで、どういった可能性があるか？それらを、1つ1つやる、やらない、いつまではやらない という判断軸で整備していきました。 結果として、当初計画していた直近1~2ヶ月でやろうと思っていた、 「事業やサービスとしてリリースして行きたいプロダクトバックログ」に 「未来を見越したときに現時点でやっておきたい技術的な調査や、リファクタリング含めて対処しておきたいプロダクトバックログアイテム」 を合流させることができました。 その過程で、事業責任者やPdMとも「なぜこのタイミングでやる必要があると考えているのか」を対話することで、相互に目線があった自信をもって全力で向き合えるプロダクトバックログにしていくことができたと思っています。 また、現在はミッションに対してプロダクトがどういう状態であるべきかを事業責任者やPdMと議論し、1年後、2年後、、、と今より長い時間軸で理想状態を言語化していく活動をしはじめています。常に対話を行い、プロダクトバックログをフレッシュに保つというのが本当の意味で、できている体感があり非常に良い取り組みになっています。 今後は、プロダクトの理想状態を言語化した上で、現状のプロダクトとの差分を認識し実現方法を考えて、技術的な意思決定とその意思決定に対するアクションにどんどん挑戦していけたら良いなと考えています。
終わりに
テックリードは会社や事業状況によって役割が左右されるかなと思いますが、技術的な課題を自ら顕在化させ挑戦できる楽しい役割かなと思っています。
僕個人として技術負債を返済できずに突き進んでしまった経験もあり、自分も技術的な成長が頭打ちになった感覚になってしまったり、チームメンバーにより良い機会提供ができなかったということがあったので、もっとユーザーに価値を届けつつ、プロダクトを作っていく側が人が前向きに挑戦し続けられる環境をこれからも作っていくために頑張っていきたいなと思います。
Speeeでは一緒にサービス開発を推進してくれる仲間を大募集しています！
こちらのFormよりカジュアル面談も気軽にお申し込みいただけます！
Speeeでは様々なポジションで募集中なので「どんなポジションがあるの？」と気になってくれてた方は、こちらチェックしてみてください！もちろんオープンポジション的に上記に限らず積極採用中です！！！
