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

発表スライド

チームと個人の可能性を最大化する - パフォーマンスを落とさない体制構築とセルフマネジメント方法
https://developer-productivity-engineering.connpass.com/event/315860/

Transcript

1. 自己改善からチームを動かす！ 「セルフエンジニアリングマネージャー」のすゝめ チームと個人の可能性を最大化する 2024/04/24 shoota
2. Web / iOS / Androidなどさまざまな開発に従事 フロントエンドリード、スクラムマスター、エンジニア リングマネージャーを経験後、Findy Team+に魅⼒を感 じ、2023年1⽉よりジョイン フルリモート in ⻘森 熊野 修太 [くまの しゅうた] @shoota ファインディ株式会社 プロダクト開発部 Team+開発 / フロントエンドリード #開発生産性_findy

3. Agenda ❏ 開発フローをはやくする ❏ なにがチームのパフォーマンスを妨害するか ❏ 「セルフエンジニアリングマネージャー」のすゝめ
4. 開発フローをはやくする
5. 開発フローをはやくする 開発者が普段やろうとしていることはとても単純 #開発生産性_findy

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

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

8. ❏ Nx (https://nx.dev/) によるCIの⾼速化 ❏ モノレポ内のモジュール依存関係を⾃動で解析 ❏ 変更が依存しないテストのスキップ、Cache利⽤ ❏ 依存関係が膨らんできたらモジュールを分割 開発フローをはやくする - Findyの場合 #開発生産性_findy
 💡無駄なCIを減らす
9. ❏ GitHub公式に加えて、独⾃のSlack通知 Appで運⽤ ❏ プルリクエストを作った時 ❏ プルリクエストレビューにアサインされた時 ❏ プルリクエストがApproveされた時 ❏ プルリクエストをマージ（クローズ）した時 開発フローをはやくする - Findyの場合 #開発生産性_findy
 💡コミュニケーションのトリガー⾃動化する
10. ❏ リリースブランチに含まれるPRからQA情報を⾃動収集 ❏ バックエンドで先⾏するプルリクエストがないか ❏ 開発者のみが確認できるQA項⽬がないか ❏ 機能リリースのためのQAが必要でないか 開発フローをはやくする - Findyの場合 #開発生産性_findy
 💡コミュニケーションのトリガー⾃動化する
11. ❏ フィーチャーフラグを使いましょう ❏ フィーチャーフラグを使いましょう ❏ フィーチャーフラグを使いましょう 開発フローをはやくする - Findyの場合 #開発生産性_findy
 フィーチャーフラグなしにデプロイ頻度は上がらない 💡デプロイとリリースを同⼀にしない
12. なにがチームの パフォーマンスを妨害するか
13. ❏ 個⼈の開発速度（コードのRead/Write）が急に成⻑することはない ❏ ⼈間が書くコード量を減らすことはできる ❏ Code generator ❏ GitHub Copilot ❏ リードタイムは「コードを書く時間」と「コードを書いたあとの時間」で わけて考えるべき なにがチームのパフォーマンスを妨害するか コードを書いたあとの時間 コードを書く時間 リードタイム #開発生産性_findy

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

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

16. なにがチームのパフォーマンスを妨害するか - Team+の成功事例 #開発生産性_findy
 Team+多⾔語化プロジェクト • 作業⾒積もり不可 • リリース⽬標の⽇程に対して、圧倒的なFE数が不⾜ • これまでの開発と違って、ゴールが⾒えにくい PR数 約2.5倍
17. ❏ 作業⼈員を確保するための仕組みを1ヶ⽉かけて構築 ❏ 誰でもできるレベルまで作業難易度を落とす ❏ 1PRでの変更ファイルはだいたい3ファイル ❏ 型による⾃動チェック、レビュー画⾯で完結する命名規則 ❏ PRが（ほぼ）衝突しないコード構造 なにがチームのパフォーマンスを妨害するか - Team+の成功事例 #開発生産性_findy

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

19. ❏ 作業⼈員を確保するための仕組みを1ヶ⽉かけて構築 なにがチームのパフォーマンスを妨害するか - Team+の成功事例 #開発生産性_findy
 作業の単純化とレビューの簡易化で 最終的にはPdMまでPRをだせるようになった PR数 22件
20. セルフエンジニアリングマネージャーのすゝめ
21. ❏ ここまでのおさらい ❏ 開発フローのプロセスを早くしたい ❏ コードを書いたあとのプロセスがボトルネックになりやすい ❏ 開発フローを意識した仕組みをつくることが⼤事 セルフエンジニアリングマネージャーのすゝめ #開発生産性_findy
 ⾃分のパフォーマンスをあげるにはチームの改善が必要
22. ⾃分で⾃分をマネージメントする セルフエンジニアリングマネージャーのすゝめ #開発生産性_findy
 ❏ PRをいくつ作りましたか？ ❏ PRをいくつレビューしましたか？ ❏ レビューアサインからレビュー開始までどれくらいかかっていましたか？
23. ⾃分で⾃分をマネージメントする セルフエンジニアリングマネージャーのすゝめ #開発生産性_findy
 ❏ 気持ちではなく、数字と向き合う ❏ 客観的な分析から⽬標とのギャップを逆算 ？
24. チームを良くする セルフエンジニアリングマネージャーのすゝめ #開発生産性_findy
 ❏ ⾃分の特性をチームに活かす⽅法を⾒つける ❏ チームのパフォーマンスで弱いところを補うとNo.1になれる Team+ フロントエンド / メンバーごとのリファクタリングのPR数 

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