今回は、5/15に開催されたTechlead Meetup ~技術リーダーシップとは何か~の参加レポです。
本イベントでは、
技術的リーダーシップを担う人々が、知見・悩みを共有できる場を提供する 今日では「テックリード」「テクニカルマネジメント」という言葉を見かけますが、その捉え方は会社によって様々です。 テックリードとエンジニアリングマネージャーでどう役割分担をすべきか。 テックリードとして技術的意思決定をどう行うべきか。 様々な悩みを抱える中で、みなさんそれぞれが自分なりの答えを探しているのではないでしょうか。 このイベントは、テックリードのような役割に就いている / 興味を持っている方々が、知見やマインドを共有し合うことで、より前進するきっかけとなることを期待します。
というテーマで開催されました。
個人的には、SWEの次のキャリアステップの一つ知見として、また、リードしていく立場となる際に他社の エンジニアは何を大事だと考え、どのような課題を感じているのかを学べればと思い、参加しました。
まずは、各社さんのテックリードの内容を下記にまとめます。
Loglass
課題
- 経営管理SaaSを開発していく中で、ユーザーから集まるデータ量の増大に伴うパフォーマンスが顕著な課題としてできてた
- 一方で、急成長中のSaaSサービスとして、機能開発は爆速で進めながら、パフォーマンスの課題をクリアする必要がある
解決策
分解-再統合パターンを行う（この言葉は一般用語なのでしょうか、、、誰か教えて、、、）。
分解フェーズ
- 課題の解像度を高める
- パフォーマンスの原因になるデータやクエリの調査
検証
再統合
- オーナーシップの醸成
- 新技術のキャッチアップに集中できるようにする
技術的リーダーシップのPoint
プロダクト開発チームが主体的に、新技術や技術的負債の解消に向かって動くが実際のプロダクトの取り込みは、開発チームに主体的に行ってもらい、技術チームは、それ以外の関連タスクの巻取り等、プロダクトのUpdateに集中してもらう環境を整備する。
LayerX
課題
- 事業上の目標達成のために、KPIの未達成リスクがあり、機能開発が急務
- 立ち上げメンバ等、主要メンバーが不在に
これにより、
- プロダクトやドメイン知識へのキャッチアップに苦戦
- コードベースの複雑化
- QA期間に、考慮漏れやバグ発生
解決策
- 技術負債を返済しない
- 短期的な開発速度を優先し、意図的に課題しない。ただし、セキュリティリスクや放置することで修正コストが指数関数的に広がるものは行う
- やる・やらないを明確に決める
- 重要機能の実装に集中。段階的リリースを行い、先行おためし機能とするなど
- 高速にフィードバックを得る
- 作り込み後の大規模な手戻りを回避する。ex. 仕様議論・夕会共有・おさわり会
- 臆せず見せる。相談する文化が大事
- QAチームと密に連携したテスト計画
- 仕様を説明し、テスト観点を共同で洗い出す
- 最低限の品質ラインを守る
結果
- 計画した機能を83％をリリース
- バグ修正件数を43％削減
- 新機能起因のバグを63％削減
この結果から、開発が早くでバグができにくい仕組みができている
技術でリードするとは、
不確実な状況でも技術の道筋を立て、プロダクトを成功へ導く。
意思決定に関与し、常に現在地を把握し、細かく軌道修正することが鍵
freee
freeeにおけるテックリードってなにしてる？
- PdL（Product Lead）
- プロダクト・基盤のチームリーダー
- チーム・個人としてプロダクト価値向上・事業貢献にこだわり、全方位でコミットする
- EM（Engineering Manager）
- 個とチームの能力を最大限に引き出し、成長を支援する
- 組織・カルチャー・仕組みを作り上げる
- TL（Technical Lead）
- 技術に対する深い知見を元に、チームの技術的な意思決定に責任を持ち、技術投資をリードする
- 必要なソリューションを立案・推進していく
- IC（Individual Contrivutor）
- 圧倒的な技術力を元に、個人でインパクトを出す
その中でテックリードは、 - 技術的な戦略やガイドラインの選定 - ドメインによるマイクロサービス構想。 - 依存関係とマイクロサービスの連携についてのガイドライン - ソフトウェアテストの戦略策定 - システム設計ガイドライン
テックリードらしい仕事をする上でで、Point
- 事業から目を背かない
- 事業ロードマップの策定に深く関わろう
- 技術投資や負債解消をロードマップに反映
- 事業ドメインの理解にどこまで割くか？
- ユーザー視点があれば、必要な知識はついてくる
- PDL、EMなどの背中を預ける
- 常に目的や価値を追求する
- 技術と組織
- ときにトップダウンな動きは必要
- ワクワクさせる
- チームも迷わせない
- より抽象的・中長期の課題に投資する
- 階層に応じて権限委譲する
- DB管理組合
- ソフトウェアテストの自動化
- ペアプロ
テックリードらしい仕事には、組織と向きあう
パネルディスカッション
テーマ１：いい技術的意思決定の秘訣
- 勇気を持って、ゴロゴリ進める
- 可逆な意思決定をする
- 今は意思決定しない意思決定
- 階層に応じた意思決定
テーマ２：TLをやってて大変なことは？どう向き合う？
- 中長期手な視点が抜ける
- 未来のことを考え、PoCを行う
- 責任が増えることをポジティブに捉える
- メンバーへの移譲
- 自責と他責を使い分ける
- 適切なトップダウンはある
感想
いずれの企業の人や、KPIの課題がある中でどのようにして機能開発を進めていくかという両輪の課題に対してのアプローチについてテーマだった。
技術力はもちろんのこと、チーム・組織と向きあって推進していく力、事業に貢献する力がテックリードのポイントだろうと感じました。
一つひとつの解決策は、急成長中の勢いあるSaaS企業でもウルトラC的な手法があるわけではなく、同じエンジニア・人間と同じで、組織上や役職上の差はあれど、あまり自社と比較しても変わるものではないなと思いました（とはいえ、コンウェイ・逆コンウェイのように組織と事業の関係性は周知の事実なので、それが大事だといればその通りかと思いますが、、、）。
個人的には、PdLやEMのような立場がキャリアプラン的には近いかなと思いました。
参加してよかったです。
今後もいい感じのイベントがあれば積極的に参加していければと思います。
