自己改善からチームを動かす！「セルフエンジニアリングマネージャー」のすゝめ

by shoota

Slide 1

Slide 1 text

自己改善からチームを動かす！「セルフエンジニアリングマネージャー」のすゝめチームと個人の可能性を最大化する 2024/04/24 shoota

Slide 2

Slide 2 text

Web / iOS / Androidなどさまざまな開発に従事フロントエンドリード、スクラムマスター、エンジニアリングマネージャーを経験後、Findy Team+に魅⼒を感じ、2023年1⽉よりジョインフルリモート in ⻘森熊野修太 [くまのしゅうた] @shoota ファインディ株式会社プロダクト開発部 Team+開発 / フロントエンドリード #開発生産性_findy 

Slide 3

Slide 3 text

Agenda ❏ 開発フローをはやくする ❏ なにがチームのパフォーマンスを妨害するか ❏ 「セルフエンジニアリングマネージャー」のすゝめ

Slide 4

Slide 4 text

開発フローをはやくする

Slide 5

Slide 5 text

開発フローをはやくする開発者が普段やろうとしていることはとても単純 #開発生産性_findy 

Slide 6

Slide 6 text

開発フローをはやくする開発者が普段やろうとしていることはとても単純だが、段階的に複数のプロセスを進める必要がある #開発生産性_findy 

Slide 7

Slide 7 text

開発フローをはやくする ❏ プロセスを減らすことはできない ❏ プロセスにかかる時間（リードタイム）をいかに減らすかが鍵 ❏ プロセスに「無駄がないか」の感度が重要 #開発生産性_findy 

Slide 8

Slide 8 text

❏ Nx (https://nx.dev/) によるCIの⾼速化 ❏ モノレポ内のモジュール依存関係を⾃動で解析 ❏ 変更が依存しないテストのスキップ、Cache利⽤ ❏ 依存関係が膨らんできたらモジュールを分割開発フローをはやくする - Findyの場合 #開発生産性_findy  💡無駄なCIを減らす

Slide 9

Slide 9 text

❏ GitHub公式に加えて、独⾃のSlack通知 Appで運⽤ ❏ プルリクエストを作った時 ❏ プルリクエストレビューにアサインされた時 ❏ プルリクエストがApproveされた時 ❏ プルリクエストをマージ（クローズ）した時開発フローをはやくする - Findyの場合 #開発生産性_findy  💡コミュニケーションのトリガー⾃動化する

Slide 10

Slide 10 text

❏ リリースブランチに含まれるPRからQA情報を⾃動収集 ❏ バックエンドで先⾏するプルリクエストがないか ❏ 開発者のみが確認できるQA項⽬がないか ❏ 機能リリースのためのQAが必要でないか開発フローをはやくする - Findyの場合 #開発生産性_findy  💡コミュニケーションのトリガー⾃動化する

Slide 11

Slide 11 text

❏ フィーチャーフラグを使いましょう ❏ フィーチャーフラグを使いましょう ❏ フィーチャーフラグを使いましょう開発フローをはやくする - Findyの場合 #開発生産性_findy  フィーチャーフラグなしにデプロイ頻度は上がらない 💡デプロイとリリースを同⼀にしない

Slide 12

Slide 12 text

なにがチームのパフォーマンスを妨害するか

Slide 13

Slide 13 text

❏ 個⼈の開発速度（コードのRead/Write）が急に成⻑することはない ❏ ⼈間が書くコード量を減らすことはできる ❏ Code generator ❏ GitHub Copilot ❏ リードタイムは「コードを書く時間」と「コードを書いたあとの時間」でわけて考えるべきなにがチームのパフォーマンスを妨害するかコードを書いたあとの時間コードを書く時間リードタイム #開発生産性_findy 

Slide 14

Slide 14 text

なにがチームのパフォーマンスを妨害するか - コードを書く時間 ❏ 後続の作業を単純化することにコストを払う ❏ 複雑な部分を検証することから始める ❏ 不確実性に最初に向き合う ❏ リファクタリングから始まってリファクタリングで終わる ❏ 過度な抽象化‧共通化はしない ❏ 機能開発前にリファクタをする ❏ 機能開発後にもリファクタをする #開発生産性_findy 

Slide 15

Slide 15 text

変更の意図を伝えることに集中するなにがチームのパフォーマンスを妨害するか - コードを書いたあとの時間 ❏ リードタイムの変数の⼤部分はこちら ❏ いかにレビュアーの負荷を⼩さくできるか ❏ プルリクエスト（PR）は⼩さく ❏ CIが通っていればOKなPRだってある ❏ ⼀度にたくさん読ませない ❏ コメントで意図を伝える ❏ レビュー指摘のすべてをPR内で修正しなくていい ❏ 複雑なものをPRで説明するよりもペアプロを選択する #開発生産性_findy 

Slide 16

Slide 16 text

なにがチームのパフォーマンスを妨害するか - Team+の成功事例 #開発生産性_findy  Team+多⾔語化プロジェクト ● 作業⾒積もり不可 ● リリース⽬標の⽇程に対して、圧倒的なFE数が不⾜ ● これまでの開発と違って、ゴールが⾒えにくい PR数約2.5倍

Slide 17

Slide 17 text

❏ 作業⼈員を確保するための仕組みを1ヶ⽉かけて構築 ❏ 誰でもできるレベルまで作業難易度を落とす ❏ 1PRでの変更ファイルはだいたい3ファイル ❏ 型による⾃動チェック、レビュー画⾯で完結する命名規則 ❏ PRが（ほぼ）衝突しないコード構造なにがチームのパフォーマンスを妨害するか - Team+の成功事例 #開発生産性_findy 

Slide 18

Slide 18 text

❏ 作業者を⼊れ替えたり増減したりしやすい ❏ 新規参⼊する障壁が極⼩ですぐに着⼿できる ❏ 引き継ぎや申し送りがない ❏ 同時作業してもストレスが発⽣しない隙間時間で作業できる状況をつくった ❏ 作業⼈員を確保するための仕組みを1ヶ⽉かけて構築 ❏ 誰でもできるレベルまで作業難易度を落とす ❏ 1PRでの変更ファイルはだいたい3ファイル ❏ 型による⾃動チェック、レビュー画⾯で完結する命名規則 ❏ PRが（ほぼ）衝突しないコード構造なにがチームのパフォーマンスを妨害するか - Team+の成功事例 #開発生産性_findy 

Slide 19

Slide 19 text

❏ 作業⼈員を確保するための仕組みを1ヶ⽉かけて構築なにがチームのパフォーマンスを妨害するか - Team+の成功事例 #開発生産性_findy  作業の単純化とレビューの簡易化で最終的にはPdMまでPRをだせるようになった PR数 22件

Slide 20

Slide 20 text

セルフエンジニアリングマネージャーのすゝめ

Slide 21

Slide 21 text

❏ ここまでのおさらい ❏ 開発フローのプロセスを早くしたい ❏ コードを書いたあとのプロセスがボトルネックになりやすい ❏ 開発フローを意識した仕組みをつくることが⼤事セルフエンジニアリングマネージャーのすゝめ #開発生産性_findy  ⾃分のパフォーマンスをあげるにはチームの改善が必要

Slide 22

Slide 22 text

⾃分で⾃分をマネージメントするセルフエンジニアリングマネージャーのすゝめ #開発生産性_findy  ❏ PRをいくつ作りましたか？ ❏ PRをいくつレビューしましたか？ ❏ レビューアサインからレビュー開始までどれくらいかかっていましたか？

Slide 23

Slide 23 text

⾃分で⾃分をマネージメントするセルフエンジニアリングマネージャーのすゝめ #開発生産性_findy  ❏ 気持ちではなく、数字と向き合う ❏ 客観的な分析から⽬標とのギャップを逆算？

Slide 24

Slide 24 text

チームを良くするセルフエンジニアリングマネージャーのすゝめ #開発生産性_findy  ❏ ⾃分の特性をチームに活かす⽅法を⾒つける ❏ チームのパフォーマンスで弱いところを補うとNo.1になれる Team+ フロントエンド / メンバーごとのリファクタリングのPR数  

Slide 25

Slide 25 text

チームを良くするセルフエンジニアリングマネージャーのすゝめ #開発生産性_findy  ❏ チームの苦⼿が減ることでリードタイムは劇的に向上する ❏ チームを改善すると個⼈のパフォーマンスがあがる ❏ ⼯夫と改善の好循環をチーム内にもたらす ❏ 量は質へ転化する ❏ 技術⼒に依存しないチーム貢献 ❏ 特定ドメインに対しての信頼感 ❏ 貢献度が可視化されていく

Slide 26

Slide 26 text

セルフチェック＆マネージメントが、きっと、あなたとチームをよくします！