Upgrade to Pro
— share decks privately, control downloads, hide ads and more …
Speaker Deck
Features
Speaker Deck
PRO
Sign in
Sign up for free
Search
Search
開発者に感謝される品質チームになる
Search
t-mario-y
March 21, 2024
0
200
開発者に感謝される品質チームになる
t-mario-y
March 21, 2024
Tweet
Share
More Decks by t-mario-y
See All by t-mario-y
到達可能性チェッカーを品質改善に活用する/use-ReachableChecker-for-frequent-refactoring
tmyrhystic
0
23k
MusicXMLを校正する
tmyrhystic
0
67
Featured
See All Featured
Git: the NoSQL Database
bkeepers
PRO
430
65k
jQuery: Nuts, Bolts and Bling
dougneiner
63
7.8k
The Straight Up "How To Draw Better" Workshop
denniskardys
233
140k
GitHub's CSS Performance
jonrohan
1031
460k
Navigating Team Friction
lara
186
15k
Mobile First: as difficult as doing things right
swwweet
223
9.6k
Typedesign – Prime Four
hannesfritz
42
2.7k
[Rails World 2023 - Day 1 Closing Keynote] - The Magic of Rails
eileencodes
35
2.3k
Dealing with People You Can't Stand - Big Design 2015
cassininazir
367
26k
Templates, Plugins, & Blocks: Oh My! Creating the theme that thinks of everything
marktimemedia
31
2.4k
GraphQLとの向き合い方2022年版
quramy
46
14k
Building Applications with DynamoDB
mza
95
6.4k
Transcript
開発者に感謝される品質チームになる TechBrew in 東京 〜mtx2sさんと考えるコード品質とビジネスインパクト〜 2024.03.21
2 2022.11~ freee⼈事労務 品質チーム - LeanとDevOpsの科学 - 単体テストの考え⽅/使い⽅ -
Googleのソフトウェアエンジニアリング - Leading Quality - 情熱プログラマ を読んでがんばる⼈ t-mario-y Software Engineer Tomoi Yoshiaki プロフィール画像の トリミング⽅法
3 - not: ビジネスインパクト、定量的な話 - but: 品質チーム⾃体の振る舞い、レコグニション Disclaimer
4 01 内部品質チーム 02 安⼼、⾼速 03 標準化 04 神対応:素早く丁寧に 05 向き合い⽅ ⽬次
5 - 2015: クラウド給与計算ソフト freee サービスイン - 2017: ⼈事労務freee
サービスイン(いずれも現: freee⼈事労務) - 2019: 機能追加だけでなく品質向上に投資 - 2020: 開発組織変更 - ドメイン機能開発T(給与‧勤怠‧⼈事マスタ)+ 内部品質T - ~now: 社内でも珍しい「アプリ開発組織だが機能開発しない」T 内部品質チーム
6 - 内部品質? - 外部品質(QA)とは別働 - ユーザにとってクリティカルな問題は外部品質として現れるが、 その原因を内部品質の課題と捉える -
保守性(変更容易性)UP→機能開発の速度と安定性を向上 - 現在(2024)のミッション - 機能開発を安⼼して⾼速に⾏えるような基盤を作る - 社内標準を磨きながらプロダクトに反映する 内部品質チーム
7 - 普通にやると煙たがられる(⼊社前にはそう思っていた) - 新機能を早く書いてデプロイしたいのに - 「お作法」に押しつけがましさを感じてしまう - ⽇々の仕事のやりとりの上で感謝されるように振る舞う
- 具体的には? 品質向上と標準化
8 - 事業計画による注⼒領域は年度ごとに変わり、開発チームも拡⼤ する - 注⼒領域の妨げになる箇所を先んじてrefactoringする - monorepoゆえに勘所を要するライブラリや⾔語のアップデート -
merge必須条件に設定したCIの安定化‧⾼速化 - ややコツがいるRuby開発環境の構築 安⼼、⾼速
9 - 標準のエディタ環境を提⽰するが制約しない - pre-commit hookはあえて設定しない - 最近hotなRuby LSP/Sorbetを使いやすい形で使う
- Danger(PullReqレビュー⾃動化)の作り込み: 正規表現がんばる - custom Linterの⾃作: ASTがんばる - CIのダッシュボードやAPIを使って失敗率や実⾏時間を注視する - deploy pipeline改善 - CircleCIのダッシュボード、失敗傾向を眺める - productionへのhotfix反映は30分以内で 安⼼、⾼速
10 - 統合ERPを作っていく上で準拠する社内標準が存在する - build pipeline on self-hosted runner
- 認証認可、課⾦機能 - マルチテナント、監視をうまく扱うmiddleware - プロダクト間でswitching costを下げるためのコード規約 - 標準化が⾃⼰⽬的化すると煙たがられる 標準化
11 - 品質チームが社内標準(ライブラリ‧仕様)の使い勝⼿に対して 敏感であり続ける - Rails の config dirで適切な存在感を放っているか?Rails
updateの枷にな らないか? - 提供される機能は必要⼗分か? - トラシュー時に迷わないか? - CHANGELOGを読み切れるか?読み切れる頻度でbump upしているか? - 基盤チームにfeedback、時にはPullReqも出す - ボトムアップで社内標準を定める場には真っ先に⼿を挙げる - cf. Shopify/ruby-style-guide 標準化
12 - Slackをパブサして困りごとスレに参加する - ちょっとした開発困りから顧客問い合わせまで - git blameし続ける、過去PullReq読む(10年モノのmonorepo) -
オンライン‧オフラインで「気軽に話しかけられる状態」を作る - slackのReacjiとキーワード検索でパブサを簡単にする - 気軽に話かけに⾏くと、相⼿からも話しかけてくれる - ⾃動化するよりも 所作の⼀つ⼀つを 息をするように - cf: 常にそこにいろ https://gihyo.jp/dev/serial/01/continue-power/0003 神対応:素早く丁寧に
13 - Engineeringによる課題解決を歓迎し、ブレイクスルーを称える - 品質と速度はトレードオフではなく、両⽅追求できることを⽰す - 「技術的課題を解くことで開発速度を上げる」チームミッション に没頭している 向き合い⽅
Thank you!