事業と組織から目を逸らずに技術でリードする

事業と組織から目を逸らずに技術でリードする  ~ 広く複雑なドメインの事業部横断テックリード ~  2025.05.15

2 • 2018年ヤフー新卒入社  ◦ ヤフーショッピングのリアーキテクトに従事  • 2021年 freee
中途入社  ◦ → 人事労務開発  ◦ → SRE  ◦ → 法人クレジットカード開発  ◦ → 新規プロダクト開発 (EM兼TL)  ◦ → 現在に至る  小倉陸 (ogugu)  支出管理開発本部事業部横断テックリード   プロフィール画像の  トリミング方法  @ogugudayo 

3 過去の主な発信 

4 01　freeeにおけるテックリード  02　”テックリードらしい” 仕事  03　事業から目を逸らさない  04　組織から目を逸らさない  05　おまけ: 良い技術的意思決定とは？  06　おまけ: “リーダー”の苦労と向き合い方 
07　おまけ: どんな人がテックリード向き？  アジェンダ  

5 「freeeのテックリードって何してるの？」 

6 PdL (Product Lead) • OKRの達成に向けて⾃⾝およびチームの技術⼒‧開発⼒で実現に導く • プロダクト価値向上‧事業貢献に拘り、マジ価値を最速で届け切ることに全⽅位でコミットする期待されるインパクト
領域創出⽅法プロダクト or 基盤チームでスキル概要役割 EM (Engineering Manager) • エンジニアがマジ価値を最速で届けるために個とチームの能⼒を最⼤限に引き出し、成⻑を⽀援する • 単発ではなく、継続的にマジ価値を⽣み出すことができる組織やカルチャー、仕組みを作り上げる組織‧⼈材チームで TL (Technical Lead) • 技術に対する深い知⾒を元に、チームの技術的な意思決定に責任を持ち、必要な技術投資をリードする • 担当領域における技術⽅針を定め、技術課題の解決に必要なソリューションを⽴案、推進していく技術チームで IC (Individual Contributor) • 特定領域において圧倒的な技術⼒を持ち個⼈の能⼒でチームを凌ぐインパクトを創出する • freeeだけでなく社会的な影響に波及するような⼤きなインパクトを再現性を持って⽣み出す技術 ※特定の技術領域での卓越した専⾨性個⼈で freeeにおけるテックリード  多様なエンジニアが活躍して協調し合うことで “ドリームチーム” を作る

7 freeeにおけるテックリード  • TLの定義  ◦ チームの技術的意思決定に責任を持ち、技術投資をリード  ◦ 担当領域の技術方針を定め、技術課題の解決に必要なソリューションを立案・推進 
• TLの責務  ◦ Technology Lead  ▪ 技術的な課題探究、その解決策の立案、実行体制の構築と完遂  ◦ Technology Implement Management  ▪ QCDのトレードオフとバランスを踏まえた技術計画と推進  ◦ Member Growth Support  ▪ 後進となるエンジニアの成長支援 

8 「もうちょっと具体的に…」 

9 事業部横断TLとして取り組んできたこと  • 技術的な戦略やガイドラインの制定 ◦ プロダクト全体のアーキテクチャと技術選定 ◦ マイクロサービスの粒度‧依存関係に関するガイドライン ◦ ソフトウェアテストの戦略策定と推進
• ドメインを横断する開発のリード ◦ ドメインを横断したFEやBFFの基盤実装、内部統制に関する開発など • 事業ロードマップの策定 ◦ ロードマップに反映すべき技術投資‧負債解消の判断など • 各ドメインチームへのヘルプ ◦ 注⼒領域や⽴て直しが必要なチームに対する開発援助 ◦ 横断的なアーキテクチャレビューや壁打ち • 開発⽂化の醸成 ◦ DBの信頼性にオーナーシップを持つギルド体制の設⽴など • 開発組織の育成‧強化 ◦ EMと共にエンジニアのスキルマップを作成‧運⽤ Member Growth Support? Technology Implement Management?  Technology Lead? 

10 “テックリードらしい” 仕事 

11 “テックリードらしい” 仕事    • 技術的な戦略やガイドラインの制定 ◦ プロダクト全体のアーキテクチャと技術選定 ◦ マイクロサービスの粒度‧依存関係に関するガイドライン
◦ ソフトウェアテストの戦略策定と推進 • ドメインを横断する開発のリード ◦ ドメインを横断したFEやBFFの基盤実装、内部統制に関する開発など • 事業ロードマップの策定 ◦ ロードマップに反映すべき技術投資‧負債解消の判断など • 各ドメインチームへのヘルプ ◦ 注⼒領域や⽴て直しが必要なチームに対する開発援助 ◦ 横断的なアーキテクチャレビューや壁打ち • 開発⽂化の醸成 ◦ DBの信頼性にオーナーシップを持つギルド体制の設⽴など • 開発組織の育成‧強化 ◦ EMと共にエンジニアのスキルマップを作成‧運⽤ Member Growth Support? Technology Implement Management?  Technology Lead? 

12 “テックリードらしい” 仕事  • 技術的な戦略やガイドラインの制定 ◦ プロダクト全体のアーキテクチャと技術選定 ◦ マイクロサービスの粒度‧依存関係に関するガイドライン ◦
ソフトウェアテストの戦略策定と推進 • ドメインを横断する開発のリード ◦ ドメインを横断したFEやBFFの基盤実装、内部統制に関する開発など • 事業ロードマップの策定 ◦ ロードマップに反映すべき技術投資‧負債解消の判断など • 各ドメインチームへのヘルプ ◦ 注⼒領域や⽴て直しが必要なチームに対する開発援助 ◦ 横断的なアーキテクチャレビューや壁打ち • 開発⽂化の醸成 ◦ DBの信頼性にオーナーシップを持つギルド体制の設⽴など • 開発組織の育成‧強化 ◦ EMと共にエンジニアのスキルマップを作成‧運⽤ Member Growth Support? Technology Implement Management?  Technology Lead?  ↑ ここ? 

13 プロダクト全体のアーキテクチャと技術選定   ドメインが広くて深いので、チームがドメインに集中できるフロー状態を作りたい。  ドメイン間で独立した開発体験や進化性を得るため、プロダクト内でドメインによって分離されたマイクロサービスの構想を明確化。

14 プロダクト全体のアーキテクチャと技術選定   OpenAPI よりも human-friendly な IDL として TypeSpec
を導入。あくまでOpenAPI を中間生成物としてコード生成することで、TypeSpec への依存リスクを下げながら、既存の OpenAPI エコシステムに乗った技術スタックを構築。 

15 マイクロサービスの粒度・依存関係に関するガイドライン   統合型ERPを目指すfreeeでは、基盤や他プロダクトを含むマイクロサービス同士の複雑な連携が課題。依存関係と連携方法の as-is を可視化、 to-be を再定義して治安維持。

16 マイクロサービスの粒度・依存関係に関するガイドライン   マイクロサービスの粒度や連携方法について、アーキテクチャレビューなどを通して溜まったナレッジを明文化。

17 ソフトウェアテストの戦略策定   アプリケーションレイヤーの責務に応じて、テストの目的を言語化し、それにあったテスト手法の使い分けを示したテスト戦略を策定し、その実行を推進。

18 システム設計ガイドライン   「Design Docの書き方・レビュー方法がわからない」というメンバーの声に応えた。  また、「実現手段のトレードオフの考慮が十分にできずに大きな手戻りが発生する」という課題もあった。   
• 「Design Doc に書くべきことは何か」  • 「設計の手戻りリスクを最小化したい」  という悩みに答えるガイドラインを作成。 

19 おしまい  …というのは冗談 

20 “テックリードらしい” 仕事を  円滑にする上で、  必要な向き合い方がある… 

21 事業から目を逸らさない 

22 事業から目を逸らさない  • POはビジネス的優先度をもとにロードマップを描く   ◦ そこにエンジニア目線を入れないと、技術と組織に関する最適化の欠落が生じる  ◦ 実際に何度か痛い目を見て、エンジニアが深く入る体制に変わった 
◦ ロードマップは、事業優先度と対応づいた技術・組織の戦略を立てるツールと捉える  • TL・EM・PdLでブラッシュアップ   ◦ 開発アイテムの依存関係や工数肌感が適切か（開発計画ではないので精緻な見積もりはしない）  ◦ 開発体制や採用計画と噛み合っているか  • 技術投資・負債解消をロードマップに反映   ◦ 技術戦略をどのような体制で実行するか、 TLが強い意志で意見する   ◦ 短期的事業貢献と中長期の開発速度のトレードオフを加味できているか、気を配る  ◦ 例) ユーザー規模拡大に合わせて、パフォーマンス改善の体制を考える  ◦ 例) 開発並列数拡大のボトルネックとなるテスト自動化を、ロードマップとOKRに反映する  事業ロードマップの策定に深く関わろう  

23 事業から目を逸らさない  • あればあるほどいいが、時間は有限 …  ◦ ちゃんとユーザー視点を持って開発に向き合えば、必要なドメイン知識はおのずと身に付く  • 信頼できる仲間に、背中を預ける  
◦ より深いドメイン理解や PdM 要素は、PdL に背中を預ける  ◦ より深いメンバーの成長支援は、EM に背中を預ける  ◦ 自分は、より精度の高い技術戦略の策定・実行に時間を割く  • 無関心ではない   ◦ ロードマップ策定時は、海外のベンチマーク製品を調査して、事業理解に努める…  ◦ あくまで ”テックリード” である以上、技術をおざなりにしない「選択と集中」  • 常に目的や価値を追求する   ◦ 「頑張って作った・チームに動いてもらったけど、ユーザーにとって価値がなかった」はつらい  ◦ テックリードは性質上、How の局所最適に陥りがち  ◦ だからこそ、常に「何がユーザーにとっての価値なのか」「何を解決したいのか」を問い続けるべき  事業ドメインの理解にどこまで時間を割くか？  

24 組織から目を逸らさない 

25 組織から目を逸らさない  • コンウェイの法則   ◦ システム設計の際、人はそのコミュニケーション構造をまねた構造を生み出してしまう ”法則”  • 逆コンウェイ戦略
  ◦ それを逆手に取って、分割したいソフトウェアの単位でチームも分割する “戦略”  ◦ 技術戦略と組織戦略はセットで考えるべき  ◦ 技術戦略やアーキテクチャは組織に浸透して意味をなす   • 例) 支出管理の組織とシステム  ◦ 支出管理は広くて深いドメインなので、ドメインに専念できる “フロー状態” を作りたい  ◦ そのために、チームもシステムもドメインによって分割する構想へ  技術と組織は表裏一体である  

26 組織から目を逸らさない  • チームをワクワクさせるための戦略・ビジョンを示す   ◦ 「進んだ先にこういう世界がある」というビジョンがなければ “終わりのない長距離走 ” に… 
◦ ワクワクする景色を見せられれば、大きな困難にも立ち向かえる  ◦ 例) テストアーキテクチャの戦略策定によって、目指すべきテストの姿を示す  • チームが迷わないためのトップダウンは必要   ◦ “トップダウンにやることへの不安や抵抗感 ” はよくある話  ◦ 一方で、 ”チームが迷わないためのトップダウン ” ならメンバーも欲するという自信が必要  ◦ 例) e2eを実装する基準は？ → シナリオの重篤度 = major 以上のケースに絞る  • 独りよがりにならない、ベクトルはチームに向ける   ◦ 戦略・ルール等はメッセージ性が強く、表層的な「 TLの仕事をやっている感」が生じがち  ◦ トップダウンに何かすること自体が目的化することさえある  ◦ ルール・プロセスが乱立して、チームに混乱が生じたら本末転倒  ◦ 実効性がなければ畳む、重複していればマージする、そもそもルールではなく仕組みで解決する…  チームが同じ方向を向くためのトップダウンな動き  

27 組織から目を逸らさない  • より抽象的・中長期の課題に投資したい   ◦ 現場で個別具体に向き合って背中を見せるのも、立派な組織支援のひとつ  ◦ ただし、そればかりでは「本当にやるべきこと」に向き合う時間がなくなっていく…  ◦
それどころか、自分の意思決定が組織のボトルネックになっていく…  • 階層に応じて権限委譲する   ◦ シニアTLとして、“ドメイン横断 ” な技術戦略や意思決定に集中  ◦ “ドメインに閉じた ” 意思決定は、各ドメインチームに委譲し、支援やFBに留める  ◦ 影響度やリスクが低い領域は、失敗を恐れずどんどん委譲していくべし  • TL自身のために、 “自己組織化されたチーム ” を目指す  ◦ 自己組織化されたチームになれば、TLがより未来のことに時間を使える  ◦ そのために、ボトムアップな取り組みに対する支援や、組織全体のスキル向上に投資する  ◦ 例) EMと共に技術スキルマップを作成して、技術成長の方位磁針をつくる  ◦ 例) テスト戦略の実行にあたって必要な知識を得る勉強会を開催 (*)  “自己組織化されたチーム ” を目指すボトムアップな動き   (*) Thought Works の「Testing Strategies in a Microservice Architecture」の輪読会を実施した 

28 組織から目を逸らさない  • お気に入りの方法   ◦ 関心が強いメンバーをオーナーに指名して、そこから波及してもらう方法  ◦ 人はロールやラベルに引っ張られて行動変容する  •
DB管理組合  ◦ DBの信頼性にオーナーシップを持つ委員会・ギルド的制度  ▪ メンバーが隔週で集まり、事前・事後の改善  ▪ アラートやモニタリングを眺める (Performance Insight, Datadog APM…)   ▪ クエリの最適化課題やデータモデリングの悩み相談を持ち込んで、議論する  ◦ “早すぎる最適化 ” に囚われず、事前に組織の関心を高め、文化醸成する   ▪ 元々、事業拡大に向けて明らかな地雷がいくつか眠っていた状態  ▪ 例) 躊躇ないサブクエリのJOINや相関サブクエリ、Aurora Reader インスタンスの未活用…  ▪ クエリ設計・データモデリングの時点でデータベースの信頼性を強く意識する文化が芽生えた  開発文化を作り、戦略やアーキテクチャを浸透させる  

29 組織から目を逸らさない  開発文化を作り、戦略やアーキテクチャを浸透させる   パフォーマンス改善を讃えあう様子

30 組織から目を逸らさない  • ソフトウェアテスト自動化   ◦ QA手動実施のリグレッションテストを自動化する取り組み   ▪ テスト戦略に沿って、テストシナリオの分析→
再構築 → 自動化  ▪ まず自分自身で各テストレイヤーのモデルケースを作る  ▪ その後、オーナーとペアプロを通して伝授→オーナーからチームに伝授…  ◦ ペアプロを通したテクニカルなスキルトランスファー   ▪ Playwright を使ったモダンなブラウザテスト  ▪ Sociable Unit Test と Solitary Unit Test の意識的な使い分け  ◦ 実践を通してメンバーと考え方を同期する   ▪ 「HTMLのセマンティクスが、なぜe2eのテスタビリティに繋がるのか？」  ▪ 「実装はもちろん、設計・仕様策定の段階でテスタビリティを考えることがなぜ重要か？」  開発文化を作り、戦略やアーキテクチャを浸透させる  

31 テックリードとしての向き合い方 

32 “テックリードらしい” 仕事をするには  事業と組織に向き合わざるを得ない 

33 私のテックリードとしての向き合い方  • 事業・技術・組織は不可分であるという前提  • その上で、技術を最適化するためには、事業と組織から目を逸らさない   • ただし、
”テックリード” である以上、技術的専門性はおざなりにしないという「選択と集中」   • そのために、他ロールのメンバーを信頼して、お互いに背中を預ける  

34 さいごに  freee では、多様なエンジニアが活躍し、協調し合うことで、  “ドリームチーム” を実現しています。  ご興味あれば、ぜひカジュアルにお話しましょう。 

35 おまけ1: 良い技術的意思決定の秘訣とは？  • 意思決定の基本   ◦ ステークホルダーを適切に巻き込み、解決したい課題をしっかり掘り下げる  ◦ トレードオフを体系的に整理した上で、何に重きを置いて、リスクにどう対処するか意思決定する 
▪ 例) 短期的な機能実現 vs 中長期の開発速度  ▪ 例) 一般的なアーキテクチャ特性のトレードオフ (可用性、信頼性、耐障害性、変更容易性…)  • 迷ったら可逆的な意思決定   ◦ 迷った時は軌道修正が容易で可逆的な選択肢を選び、不確実性に対処する  ◦ A→Bの軌道修正は難しいが、B→Aは容易なのであれば、まずはBを選ぶ  • 今は意思決定しないという意思決定   ◦ 強い課題や重要度がない場合、あえて意思決定を遅らせて、より重要な意思決定に時間を割く  • 階層に応じた意思決定   ◦ ドメインに閉じた技術導入など、影響範囲の狭いものは積極的に委譲し、意思決定を迅速にする 

36 おまけ1: 良い技術的意思決定の秘訣とは？  • ロックインリスクを減らす技術導入   ◦ 例) OpenAPI の代替のIDLとして
TypeSpec を導入する  ▪ TypeSpec から直接コード生成をせず、OpenAPI を中間成果物とした  ▪ OpenAPI を介することで、既存の OpenAPI エコシステムに乗れる  ▪ TypeSpec を廃止したい場合、生成された OpenAPI をマスタにすれば、容易に廃止できる  • ときに攻めた意思決定も必要   ◦ 安定解を選び続けると、局所最適に陥り、進化が遅れてしまう   ◦ 意思決定内容をやり抜く意志とセットで、アーキテクチャの進化を促すべき  ◦ 例) 基盤マイクロサービス以外に、実プロダクトでも Go を初採用した事例  ▪ 当時、技術資産が Ruby に依存しており、ブラウザからコールされる HTTP サーバーは Ruby 以外で実装できず、Go は内部通信を前提にした基盤 gRPC サービスのみで利用されていた  ▪ 徐々に Ruby の技術資産への依存が解消されたため、フェローや基盤チームと掛け合い、しがらみの少ない支出管理の新規プロダクトで、Go の導入を始めた  ▪ この取り組みが波及したためか、現在多くのプロダクトで Go が採用されている 

37 おまけ2: “リーダー”の苦労と向き合い方  • メンバーを信頼して委譲する   ◦ リーダーはとにかく仕事を抱えがち、そんな自分に酔ってしまうケースも…  ◦ 抱えることで自分が逆にボトルネックになることを自覚し、適切に委譲する 
• 責任が増えることを、ポジティブに捉える   ◦ 責任が増えると共に裁量が増える  ◦ 自分が抱いていた理想を実現するための実行権限が与えられた、と捉えよう  • 自責と他責を使い分ける   ◦ 行きすぎると全ての課題に責任を感じ始めることも…  ◦ 市場変化などどうしようもない外部要因に責任を感じても仕方がない  ◦ 真面目な人は、潰れないように「自分を守るための他責」をコントロールしよう  • チームが迷わないためのトップダウンは必要と信じる   ◦ トップダウンに対する不安や抵抗は、リーダーもメンバーも感じることがある  ◦ ちゃんとチームが迷わないためのトップダウンであれば受け入れられるので、安心すべし 

38 おまけ3: どんな人がテックリード向き？  会社ごとのTLの役割定義にもよるが…  • 技術だけでなく組織にもベクトルを向けられるか   ◦ この資料で言及している通り  ◦
技術戦略の実行において、組織に働きかけ、人を動かすことは避けて通れない  • 物事を体系的に整理し、精緻に議論を積み上げられるか   ◦ 技術的意思決定には、トレードオフが常に付きまとう  ◦ 誰よりも緻密に体系的にトレードオフを整理しながら、物事を前に進める能力が必要  • 職人気質 (クラフトマンシップ ) があるか  ◦ TLは特に品質に対する意識をチーム内で人一倍持つ  ◦ 細部までこだわって突き詰められるか、という職人気質が重要  • 幅広く知的好奇心を持てるか   ◦ 技術投資の判断のためには、広い技術領域に関心を持ち、トレンドを追う必要がある  ◦ 新しいものに食いつくイノベーター気質があるか   

事業と組織から目を逸らずに技術でリードする

事業と組織から目を逸らずに技術でリードする

ogugu

More Decks by ogugu

Other Decks in Technology

Featured

Transcript