はじめに
Eight Androidチームのチームリーダーの山本です。
私たちのチームでは2024年6月から新たにテックリードのポジションを設け、2024年4月入社のメンバーにその役割を担ってもらっています。
それまでEight Androidチームに明確なテックリードのポジションはなく、チームリーダーである自身が暗黙のうちにその役割を兼務している状態でした。今回、新たにテックリードのポジションを設けるに当たり、考えたことをまとめます。
背景
これまでチームでは2つの取り組みでアーキテクチャの検討と、新技術導入や技術的負債の改善を行ってきました。
技術基盤改善
- 新技術導入や技術的負債の改善を行う
- 週に1回2時間の時間をかける
- チーム全員が作業する
アーキテクチャ検討会
- レビューなどで発生した汎用的な技術的な論点や、大きなアーキテクチャ変更の話題を扱う
- 週に1回2時間の時間をかける
- チーム全員参加で意思決定は基本合議制で行う
それなりに有効に機能していたのですが、一方で次の課題がありました。
- 時間が分散しているかつ合議制のため時間がかかる
- チームリーダーの山本が長らくEightにしか携わっていない。そのため現在のEightのアーキテクチャ以外に変更するための技術的なリードが難しい
その中で他社でテックリードの立場で活躍していたメンバが4月にチームに加わることになりました。そのためEignt Androidでもテックリードのポジションを設けて任せられないかという方向になりました。
テックリードに何を任せるべきか?
テックリードのポジションを設けるにあたり、何をするかという職務を決める必要があります。
テックリードとは文字通り技術をリードする存在ですが、実際に何をやっているかは各チームの開発スタイルに依存すると思います。
このチームで何を任せるかを考える際に、他社や社内の他のチームのテックリードやアーキテクトの定義を参考に考えました。
「目的」は汎用的なものなので事例が参考になりました。一方でこのチームにおいて「具体的に何をするべき職務なのか」、「そのために何を明文化して決めるべきか」が自分の中でははっきりわかりませんでした。
目的だけでなく権限を定義する
その中であるチームが「アーキテクトの期待値に紐づく権限」という文書を作成しており、それが自分にとっての気づきになりました。重要なのは目的だけではなく、目的達成のために与えられる権限を決めることなのだと理解しました。
目的を達成する手段というのは、時には他者と衝突します。人的資源が最もわかりやすい例で、基盤改善のためにコストをかければ、一時的にはプロダクト開発は遅れます。
そのため目的だけを決めても、何ができるのかはわかりません。無理に行えば毎回調整が必要になります。事前に権限を明確にしておくことで、何が行えるかが明確になります。
テックリードの職務作成まで
ここまでが4月に考えたことで、5月にこの方針が決まり次第、まずはテックリード候補のメンバと、タイムラインの認識をすり合わせました。
4月に入社したばかりで、まだプロダクト開発に十分に関わっていない状況だったので、もう少しメンバーとしてプロダクト開発に取り組んでからテックリードを始めるべきか、それとも早めに始めるべきかを話し合いました。
本人の希望としてはなるべく早くテックリードの職務に取り組みたいとのことだったため、5月末までに以下の内容にまとめて、チームメンバーと合意を取り、その上でテックリードの職務を始めてもらうこととしました。
- 6月以降の半年間でやりたいこと
- 上記の簡単な計画
- 上記を行うために欲しい権限とリソース
テックリード職務開始後の体制の変化
結果として6月から以下の体制になりました。
基盤改善とプロダクト開発のチーム分離
これまであった週1回の技術基盤改善の時間を廃止し、基盤開発の専任のチームがフルタイムでこの作業を行うことにしました。テックリードをリーダーとして基盤改善の専任のチームを立ち上げ、合計2名を専任としました。
これにより細かい改善だけではなく、Dagger AndroidのHiltへ置き換えのような大規模で今まで手がつけられていなかった改善に着手できるようになりました。
アーキテクチャ検討会の主催をテックリードに委譲
アーキテクチャ検討会自体は変わらないのですが、その主催をテックリードに移管し、議題の選定や進め方はテックリードが決めるようにしました。
またアーキテクチャの最終決定権は今まで明確化されていませんでしたが、テックリードが持つことを明確化しました。これによりテックリードの知識や経験を反映しやすくなりました。
権限委譲の汎用化
テックリードに限らず、現在のチームリーダー業務をメンバに部分的に委譲していくに当たり、今回の仕組みをもう少し汎用化できないかと考えています。
これまでは個別の業務という単位でメンバに割り当てていたのですが、その場合割り当てられたメンバは言われたこと以外に何をやるべきなのかがわからず、主体的な行動には結びつきにくいという問題がありました。
これについて考えている時に、昔似たような話についての本を読んだことを思い出して再度読み直してみました。2018年頃に非階層型組織の具体的な実践例として有名になったホラクラシーです。
ホラクラシーについての詳細は割愛しますが、ホラクラシーはすべての職務がロールという単位に分解されます。ロールは次の3つで定義されます。
- パーパス: ロールの目的
- ドメイン: ロールが運用できる権限
- アカウンタビリティ: ロールが実行するべきこと
これは先ほど話した目的と権限、やることの3つとほぼ一致します。
ホラクラシー全体を組織に適用するかという話は別として、少なくとも権限移譲において考えは部分的に応用できそうだと感じました。現在試験的にチーム内の職務をすべてロールとして定義し、権限委譲をロールベースで行えるかどうかを試しています。
まとめ
Eight Androidチームではテックリードに適切に定義された権限移譲を行うことで、以前より効果的に技術基盤やアーキテクチャの改善を行えるようになりました。またそこからより汎用的な権限委譲の方法について考えられました。
共にSansan / Eightのモバイルアプリ開発していく仲間を募集中です！
選考評価なしで現場のエンジニアのリアルな声が聞けるカジュアル面談もあるので、ご興味ありましたらぜひ面談だけでもお越しいただけたら幸いです！
