開発者に感謝される品質チームになる

Transcript

1. 　 開発者に感謝される品質チームになる TechBrew in 東京 〜mtx2sさんと考えるコード品質とビジネスインパクト〜 2024.03.21
2. 　 2 2022.11~ freee⼈事労務 品質チーム - LeanとDevOpsの科学 - 単体テストの考え⽅/使い⽅ - Googleのソフトウェアエンジニアリング - Leading Quality - 情熱プログラマ を読んでがんばる⼈ t-mario-y Software Engineer Tomoi Yoshiaki プロフィール画像の トリミング⽅法
3. 　 3 - not: ビジネスインパクト、定量的な話 - but: 品質チーム⾃体の振る舞い、レコグニション Disclaimer
4. 4 01 内部品質チーム 02 安⼼、⾼速 03 標準化 04 神対応：素早く丁寧に 05 向き合い⽅ ⽬次
5. 　 5 - 2015: クラウド給与計算ソフト freee サービスイン - 2017: ⼈事労務freee サービスイン（いずれも現: freee⼈事労務） - 2019: 機能追加だけでなく品質向上に投資 - 2020: 開発組織変更 - ドメイン機能開発T（給与‧勤怠‧⼈事マスタ）+ 内部品質T - ~now: 社内でも珍しい「アプリ開発組織だが機能開発しない」T 内部品質チーム
6. 　 6 - 内部品質？ - 外部品質（QA）とは別働 - ユーザにとってクリティカルな問題は外部品質として現れるが、 その原因を内部品質の課題と捉える - 保守性（変更容易性）UP→機能開発の速度と安定性を向上 - 現在（2024）のミッション - 機能開発を安⼼して⾼速に⾏えるような基盤を作る - 社内標準を磨きながらプロダクトに反映する 内部品質チーム
7. 　 7 - 普通にやると煙たがられる（⼊社前にはそう思っていた） - 新機能を早く書いてデプロイしたいのに - 「お作法」に押しつけがましさを感じてしまう - ⽇々の仕事のやりとりの上で感謝されるように振る舞う - 具体的には？ 品質向上と標準化
8. 　 8 - 事業計画による注⼒領域は年度ごとに変わり、開発チームも拡⼤ する - 注⼒領域の妨げになる箇所を先んじてrefactoringする - monorepoゆえに勘所を要するライブラリや⾔語のアップデート - merge必須条件に設定したCIの安定化‧⾼速化 - ややコツがいるRuby開発環境の構築 安⼼、⾼速
9. 　 9 - 標準のエディタ環境を提⽰するが制約しない - pre-commit hookはあえて設定しない - 最近hotなRuby LSP/Sorbetを使いやすい形で使う - Danger(PullReqレビュー⾃動化)の作り込み: 正規表現がんばる - custom Linterの⾃作: ASTがんばる - CIのダッシュボードやAPIを使って失敗率や実⾏時間を注視する - deploy pipeline改善 - CircleCIのダッシュボード、失敗傾向を眺める - productionへのhotfix反映は30分以内で 安⼼、⾼速
10. 　 10 - 統合ERPを作っていく上で準拠する社内標準が存在する - build pipeline on self-hosted runner - 認証認可、課⾦機能 - マルチテナント、監視をうまく扱うmiddleware - プロダクト間でswitching costを下げるためのコード規約 - 標準化が⾃⼰⽬的化すると煙たがられる 標準化
11. 　 11 - 品質チームが社内標準（ライブラリ‧仕様）の使い勝⼿に対して 敏感であり続ける - Rails の config dirで適切な存在感を放っているか？Rails updateの枷にな らないか？ - 提供される機能は必要⼗分か？ - トラシュー時に迷わないか？ - CHANGELOGを読み切れるか？読み切れる頻度でbump upしているか？ - 基盤チームにfeedback、時にはPullReqも出す - ボトムアップで社内標準を定める場には真っ先に⼿を挙げる - cf. Shopify/ruby-style-guide 標準化
12. 　 12 - Slackをパブサして困りごとスレに参加する - ちょっとした開発困りから顧客問い合わせまで - git blameし続ける、過去PullReq読む（10年モノのmonorepo） - オンライン‧オフラインで「気軽に話しかけられる状態」を作る - slackのReacjiとキーワード検索でパブサを簡単にする - 気軽に話かけに⾏くと、相⼿からも話しかけてくれる - ⾃動化するよりも 所作の⼀つ⼀つを 息をするように - cf: 常にそこにいろ https://gihyo.jp/dev/serial/01/continue-power/0003 神対応：素早く丁寧に
13. 　 13 - Engineeringによる課題解決を歓迎し、ブレイクスルーを称える - 品質と速度はトレードオフではなく、両⽅追求できることを⽰す - 「技術的課題を解くことで開発速度を上げる」チームミッション に没頭している 向き合い⽅
14. Thank you!