Upgrade to Pro — share decks privately, control downloads, hide ads and more …

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

t-mario-y
March 21, 2024
130

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

t-mario-y

March 21, 2024
Tweet

Transcript

  1.   2 2022.11~ freee⼈事労務 品質チーム - LeanとDevOpsの科学 - 単体テストの考え⽅/使い⽅ -

    Googleのソフトウェアエンジニアリング - Leading Quality - 情熱プログラマ を読んでがんばる⼈ t-mario-y Software Engineer Tomoi Yoshiaki プロフィール画像の トリミング⽅法
  2.   5 - 2015: クラウド給与計算ソフト freee サービスイン - 2017: ⼈事労務freee

    サービスイン(いずれも現: freee⼈事労務) - 2019: 機能追加だけでなく品質向上に投資 - 2020: 開発組織変更 - ドメイン機能開発T(給与‧勤怠‧⼈事マスタ)+ 内部品質T - ~now: 社内でも珍しい「アプリ開発組織だが機能開発しない」T 内部品質チーム
  3.   6 - 内部品質? - 外部品質(QA)とは別働 - ユーザにとってクリティカルな問題は外部品質として現れるが、 その原因を内部品質の課題と捉える -

    保守性(変更容易性)UP→機能開発の速度と安定性を向上 - 現在(2024)のミッション - 機能開発を安⼼して⾼速に⾏えるような基盤を作る - 社内標準を磨きながらプロダクトに反映する 内部品質チーム
  4.   9 - 標準のエディタ環境を提⽰するが制約しない - pre-commit hookはあえて設定しない - 最近hotなRuby LSP/Sorbetを使いやすい形で使う

    - Danger(PullReqレビュー⾃動化)の作り込み: 正規表現がんばる - custom Linterの⾃作: ASTがんばる - CIのダッシュボードやAPIを使って失敗率や実⾏時間を注視する - deploy pipeline改善 - CircleCIのダッシュボード、失敗傾向を眺める - productionへのhotfix反映は30分以内で 安⼼、⾼速
  5.   10 - 統合ERPを作っていく上で準拠する社内標準が存在する - build pipeline on self-hosted runner

    - 認証認可、課⾦機能 - マルチテナント、監視をうまく扱うmiddleware - プロダクト間でswitching costを下げるためのコード規約 - 標準化が⾃⼰⽬的化すると煙たがられる 標準化
  6.   11 - 品質チームが社内標準(ライブラリ‧仕様)の使い勝⼿に対して 敏感であり続ける - Rails の config dirで適切な存在感を放っているか?Rails

    updateの枷にな らないか? - 提供される機能は必要⼗分か? - トラシュー時に迷わないか? - CHANGELOGを読み切れるか?読み切れる頻度でbump upしているか? - 基盤チームにfeedback、時にはPullReqも出す - ボトムアップで社内標準を定める場には真っ先に⼿を挙げる - cf. Shopify/ruby-style-guide 標準化
  7.   12 - Slackをパブサして困りごとスレに参加する - ちょっとした開発困りから顧客問い合わせまで - git blameし続ける、過去PullReq読む(10年モノのmonorepo) -

    オンライン‧オフラインで「気軽に話しかけられる状態」を作る - slackのReacjiとキーワード検索でパブサを簡単にする - 気軽に話かけに⾏くと、相⼿からも話しかけてくれる - ⾃動化するよりも 所作の⼀つ⼀つを 息をするように - cf: 常にそこにいろ https://gihyo.jp/dev/serial/01/continue-power/0003 神対応:素早く丁寧に