テックリードとして1年間取り組んできたこと
エウレカでAndroidチームのマネージャーをやっているyuyakaidoです。
エウレカ歴も8年目に突入した2023年は新機能開発を行うプロジェクトにて、Androidエンジニア兼テックリードとして働いていました。
そこで、この記事では私がテックリードとしてどのように働いているのかをまとめてみようと思います。
- この記事におけるテックリードは自社プロダクトのプロジェクトをリードするような立場を想定しています
- プロジェクトではプロダクトマネージャー、デザイナー、エンジニアなどが協働して機能開発を行うことを想定しています
- 社内では便宜上テックリードと呼称していますが、世の中の一般的なテックリードの定義とは乖離している側面もあります
社内には私以外にも何人かテックリードがおり、それぞれが所属するプロジェクトごとに状況や求められている役割が多少違っていますが、テックリードの役割を一言で表すと、プロジェクトをリードして物事を前に進めることです。
私は具体的に以下のような動きを意識的に行っていました。
- プロダクトマネージャーの壁打ち相手
- 要件定義のサポート
- キックオフミーティングのサポート
- 開発初期段階での全体設計
- スプリントにおけるマイルストーン管理
プロダクトマネージャーの壁打ち相手
エウレカではプロダクトマネージャーが中心となって新機能や機能改修の企画を行いますが、その過程で技術的な観点を中心とした壁打ち相手になることが多くあります。
具体的には以下のような観点で相談に乗ることが多いです。
- 技術的な観点での実現可能性の確認
- 技術的な観点でより良いアイデアがないかどうかの確認
- 企画を実現するために必要な工数の大まかな見積もり
企画段階でこのような観点を事前に話しておくことで技術的な観点で極端に難しいものが出来上がってしまうことを防止し、プロダクトマネージャーが地に足付いた企画を作れるようにサポートすることが目的です。
要件定義のサポート
企画の全体像が固まったタイミングでプロダクトマネージャーとテックリードが協力して要件定義を行います。プロダクトマネージャーだけで要件定義を行うケースもありますが、技術的に込み入った箇所などはテックリードがサポートに入ることが多いです。
プロダクトマネージャーは何を実現したいかを考える人であり、テックリードはどうやって実現するかを考える人なため、要件定義はプロダクトマネージャーとテックリードが連携して行うことが多いです。
具体的には以下のような観点でサポートを行います。
- 技術的な視点から既存仕様との整合性の担保
- 読み込み状態やエラー状態などのエッジケースへの考慮
- 技術的に複雑性の高い部分での要件の簡略化や変更の提案
キックオフミーティングのサポート
大まかな要件定義が完了したら各チームの担当者を交えてキックオフミーティングを行います。
キックオフミーティングは各チーム固有の懸念や疑問などテックリードだけではカバーしきれない観点をチェックすることも目的の1つなため、極力色々な視点からのチェックが入るようなファシリテーションを心がけています。
キックオフミーティングで新たな懸念が出てきた場合、プロダクトマネージャーとテックリードが中心となって必要に応じて要件の調整を行います。
開発初期段階での全体設計
キックオフミーティングやその後の調整を経て要件やスコープが確定した後はテックリードが一番忙しくなるタイミングです。このタイミングではテックリードが中心となって具体的な実現方法の検討を行います。
大まかには以下のような流れで検討を行います。
- 影響範囲の確認
- 開発内容の精査
- 中長期視点での提案
影響範囲の確認
まずは各種影響範囲を確認します。
具体的には、クライアントの対応のみで完結するのか、バックエンドの対応も必要かどうかを確認することで今後巻き込むべきチームを確定させます。また、Pairsはプラットフォーム毎に提供している機能が微妙に異なっているため、全プラットフォームが対象となるのか、特定のプラットフォームだけが対象になるのかも重要なポイントになります。
クライアントの修正のみで完結しない場合、既存APIの修正のみで完結するのか、新規APIの開発が必要になるかどうかも重要なポイントです。
開発内容の精査
影響範囲の確認後は各チームの担当者と協力して開発内容を精査します。
具体的には、以下のような観点を精査することが多いです。
- 既存APIに加える修正はどんなものか
- 新規APIはどのような仕様になるか
- APIの呼び出しシーケンスはどのようになるか
このタイミングにおけるテックリードの振る舞いとして、テックリードが全ての開発内容を決定する必要はなく、詳細な部分は各チームの担当者に任せ、全体としての情報集約をメインとし、最終的にPairsの全体像や中長期的な視点を踏まえた決定を行うことが多いです。
中長期的な視点での提案
Pairsのような自社プロダクトは「スピード感のある開発」を「継続的」に行うことが重要であり、テックリードは短期的な視点でのスケジュールと、中長期的な視点でのメンテナンス性のバランスを取ることも重要な仕事になります。
実際の開発現場において、全ての仕様を当初のスケジュール通りに一切の技術的な妥協なく完了できることは稀で、常に何かしらのトレードオフを考慮した判断が必要になります。
開発プロジェクトにおいて、変更可能な要素は主に以下の3つです。
- スコープ
- リソース
- スケジュール
プロダクト開発に関わっている人ならイメージが付くかと思いますが、スケジュールを短縮するにはスコープかリソースを変更する必要があり、スコープの削減は直接的にスケジュール短縮に寄与する可能性が高いが、リソースの追加はどこまでスケジュール短縮に寄与するかは未知数です。
よくあるケースをいくつか取り上げてみましょう。
大々的なリリースキャンペーンが開発前から決まっている
リリースキャンペーンは往々にして大きな予算が動くことも多く、そう簡単に時期をズラせないことも多いでしょう。こういった場合はスケジュールは基本的に動かせない要素として捉え、スコープの削減かリソースの追加で対処する必要があります。
開発内容を見積もってみたら想定よりも開発コストが大きい
これも非常によくあるケースだと思いますが、大々的なリリースキャンペーンが絡んでいない場合はスケジュールも変数として捉えることができるため、スコープとスケジュールのバランスを考慮して判断することになります。
既存機能のリファクタリング要望が出てくる
既存機能を修正する場合はこういった要望がエンジニアから出てくるケースもあると思います。ただ、こういった要望を無条件に取り込むとどんどんスコープが拡大してしまう可能性もあるため、どこまでをスコープに含めるべきかは慎重に判断します。
スコープに含めるべきもの
- リファクタリングを行うことでスケジュールやクオリティに大きく寄与する可能性が高いもの
- 短期的には追加のコストとなるが、中長期的には開発効率の向上に繋がる可能性が高いもの
スコープに含めないほうがよいもの
- 単純に修正範囲が近いだけで開発しようとしている施策と本質的には関係がないもの
開発のマイルストーン管理
開発内容の精査を終えた後は、大まかなマイルストーンを設定します。
単純に全タスクの見積もりを足し算するのではなく、タスク同士の依存関係を意識することが重要で、スケジュールのクリティカルパスを事前に把握することが目的です。
例えば、以下のようなマイルストーンを事前に設定することが多いです。
- モックAPIが完成してAPI連携処理に着手できるタイミング
- 正規のAPIが完成して最終的な結合テストが実施できるタイミング
- プロダクトマネージャーが成果物をチェックできるタイミング
- QAチームがQAを開始できるタイミング
まとめ
この記事では私がテックリードがどのように働いているのかをまとめてみました。
- プロダクトマネージャーの壁打ち相手
- 要件定義のサポート
- キックオフミーティングのサポート
- 開発初期段階での全体設計
- 開発のマイルストーン管理
おそらく多くの方が感じたかと思いますが、テックリードとして働くことでコードを書く時間は少なくなります。
ただ、自社プロダクトの開発においては、他職種とのコラボレーションを通して物事を前に進められる人の存在が重要なため、自分の動きによってプロジェクトや会社全体としてより大きなアウトプットがよりスピーディに出せている実感があり、自分個人としてコードを書く時間が減っていることはネガティブには感じていません。
1人のエンジニアがコードを書くことで出せるアウトプットには限界があり、より市場価値の高いエンジニアになるためには、チームやプロジェクトをリードして自分1人では出せないアウトプットを引き出せるというのが重要な要素の1つと考えており、テックリードとしての経験はエンジニアのキャリアの中で大きな意味を持ってくるだろうと思っています。
