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
110
開発者に感謝される品質チームになる
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
16k
MusicXMLを校正する
tmyrhystic
0
54
Featured
See All Featured
Ruby is Unlike a Banana
tanoku
96
10k
The Invisible Side of Design
smashingmag
294
49k
Practical Orchestrator
shlominoach
183
9.7k
GitHub's CSS Performance
jonrohan
1025
450k
For a Future-Friendly Web
brad_frost
172
9k
[RailsConf 2023] Rails as a piece of cake
palkan
28
4k
How to Ace a Technical Interview
jacobian
273
22k
XXLCSS - How to scale CSS and keep your sanity
sugarenia
242
1.2M
The World Runs on Bad Software
bkeepers
PRO
61
6.7k
Typedesign – Prime Four
hannesfritz
36
2.1k
"I'm Feeling Lucky" - Building Great Search Experiences for Today's Users (#IAC19)
danielanewman
221
21k
Visualization
eitanlees
137
14k
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!