開発生産性を高めるために 実践しているナレッジの紹介 株式会社ユニラボ リードエンジニア　末澤 夏の開発生産性LT Week 〜ベストプラクティスから学ぶ！Four Keys 向上へのトライ〜

join ・2020.9 in unilabo 業務 ・2020 〜 既存サービスインフラ IaC 化対応 ・2021 〜 新規サービスインフラ構築 ・2022 〜 既存サービスリプレイス対応 / 採用推進 / 技術広報 ・2023 〜 現在はプロダクト開発チームにてバックエンド開発を担当 登壇・イベント ・Laravel.shibuya#10 テスト実行時間を1/2 にしました＠Laravel ・AWS Startup Meetup#13 わたしたちにIaC はまだ早かったのかもしれない ・AWS GameDay 8 位 受賞 output ・https://note.com/deliku0306/ ・https://twitter.com/deliku0306 自己紹介 末澤尚也

テックブログ 　会社のテックブログの運営を行っており、毎月投稿を2 年以上継続しています。 　エンジニア組織全体で取り組んでいること、 　チームの雰囲気、文化などの情報を届けています。 　see https://note.unilabo.jp/m/mc84cf9468445 　仮説検証型アジャイル開発を行うアイミツ開発チームの技術的負債への向き合い方 　" 爆速開発" を実現するアイミツ開発チーム 　開発生産性を向上し続けたいユニラボの取り組み - 2022 年振り返り- 　アイミツ開発チームの開発生産性をFindyTeams-DevOps 分析してみた 　爆速で価値を提供したい！アイミツプロダクト開発フローを紹介します！ 　私が開発者体験（DX ：Developer eXperience ）を大切にしたい理由 自己紹介 末澤尚也

会社紹介 受発注を変革するインフラを創る をV I S I O N に掲げ、 国内最大級のB t o B 受発注プラットフォーム アイミツ を展開しています 発注先を探している発注者と仕事を請け負いたい受注者を 最適な形でマッチングさせることで、 世の中の無駄な「相見積もり」を省き、 あらゆる発注をスムーズにすることを目指しています 株式会社ユニラボ

2020 2021 2022 2023 2019 会社紹介 株式会社ユニラボ シリーズA 6.6 億円 シリーズB 14.4 億円 シリーズC 25.8 億円 社員数 50 人突破 社員数 100 人突破 日本サービス大賞 「優秀賞」受賞 FINDY TEAM+ AWARD 2022 受賞 職場環境最優良法人 受賞 累計資金調達金額 46.8 億円 突破！ 社員数 120 人 突破！ Findy Team+ Award 2022 受賞！

アジェンダ ・なぜ 開発生産性を向上させたいのか ・開発生産性を可視化するためにFindyTeam+ 導入 ・実践しているナレッジ ・FindyTeam+ チームレポート > リードタイムの可視化

なぜ開発生産性を向上させたいのか プロダクトとはそれ自体に価値はなく、 ユーザに価値を提供して初めて価値が付加されるものと考えています。 最初からユーザが求めているものを正しく開発できれば悩むことはないのですが、 確実な答えは誰ももっていません。 分からないことが多い状態から、分からないことを分かるように進めていき、 たくさんのユーザに価値を提供し続けたい。 仮説検証という打席に多く立ち続けるために、 開発生産性の向上をしたいと考えています。

開発生産性を可視化するためにF i n d y T e a m + 導入 「エンジニアの生産性」は、抽象的な概念です。 具体化し継続的に定量評価できる状態にしないと、 " 自分達のパフォーマンスは良いのか、良くないのかわからない状態" となってしまいます。 デプロイの頻度 - 組織による正常な本番環境へのリリースの頻度 変更のリードタイム - commit から本番環境稼働までの所要時間 変更障害率 - デプロイが原因で本番環境で障害が発生する割合（% ） サービス復元時間 - 組織が本番環境での障害から回復するのにかかる時間 そのため、ソフトウェア開発チームのパフォーマンスを示す 4 つの指標 "Four Keys" を可視化できるFindyTeam+ を導入しています。

アジェンダ ・なぜ 開発生産性を向上させたいのか ・開発生産性を可視化するためにFindyTeam+ 導入 ・実践しているナレッジ ・FindyTeam+ チームレポート > リードタイムの可視化

実践しているナレッジ : タスクは小さく！ タスクは小さく！プルリクエストは小さくをチームで実践！ 肥大化したプルリクエストが生むデメリット プルリクエスト作成者の負荷 実装方針が違っていた場合、作りきるまでかかった時間が無駄になる タスクが大きいと、進捗が見えづらい 差し戻し内容が多いと、修正にかかる時間が大きい レビュワーの負荷 全体像を掴むのに時間がかかる、結果レビューに時間がかかる とりかかりにくい / あとまわしにしがち 肥大化したプルリクエストは下記の記載通りデメリットがあると考えているので、 タスクを小さく分割し、実装範囲のスコープを小さくすることで、 1 プルリクエストあたりの修正量を削減します。

実践しているナレッジ : コードレビュー文化 P u l l R e q u e s t コメントにプレフィックス導入！ コードに対する指摘はテキスト表現なので、 レビュワーのニュアンスをより正確に伝える必要があります。 また、良い点は褒め合いたいという想いから、GOOD を導入したところ、 レビューにポジティブな雰囲気や活気が生まれる効果がありました。

プルリクエストレビュー段階で実装方法についての指摘をもらい、 実装のやり直し（手戻り）が発生した経験はありませんか？ どこにどのように実装するか（実装指針）の認識が揃っていれば、 設計観点のレビューはPR レビューでなくなり、レビュー修正範囲が小さくなります。 またプルリクエストのレビュー依頼を出す際に事前に設計のすり合わせをしているため、 前提知識があることでレビュワーの認知負荷が減る効果もありました。 実践しているナレッジ : 設計レビュー 設計レビュー導入！プルリクエストレビューよりも早いフィードバックを！ BEFORE AFTER PR レビュ ー 実装 設計 設計 レビュ ー 実装 PR レビュ ー

実践しているナレッジ : 良質な開発者体験を整える 生産性向上のために開発者体験は良い状態をキープする！ コードレビューに割く時間の削減 タスクを小さくすることでコード変更量を小さくレビュー負荷を軽減 設計レビュー導入による認識齟齬の解消 デプロイ方法簡素化、デプロイ時間の改善 ボタン1 つで誰でも簡単にdeploy 可能 デプロイにかかるトータル時間は10 分未満！ 1 日に1 回以上リリースを実現 本番マスキング（個人情報など）データを利用した開発環境整備 実データと同等状態で開発やテストを行える パフォーマンス問題や問い合わせがあった事象再現性が高い

実践しているナレッジ : 良質な開発者体験を整える CI/CD 環境整備 テスト並列実行 PHPStan / PHP_CodeSniffer による規約準拠チェック 心理的な不安/ 障害を取り除くチーム文化の醸成/ 浸透 悩んだらSlack ハドルでサクッとカジュアルにする文化を醸成/ 浸透 デイリースクラムにてタスク進捗の困りごとをシェアし、 困りごとはレトロスペクティブで振り返り、次週でTRY を実践する 　　　 スプリントゴールを達成できるかを全員で考える 自分たちで働きやすい/ 開発しやすい環境を作り続けることが大事。 その環境（土台）があることで、生産性が向上しユーザに早く価値を届けられる。 生産性向上のために開発者体験は良い状態をキープする！

F i n d y T e a m + チームレポート > リードタイムの可視化 1 日あたりのプルリク数が増加傾向（黄色矢印）、 平均プルリククローズ時間 / プルリクからレビューまでの時間 / レビュー後クローズまで平 均時間 が減少傾向（赤色矢印）となっていることがわかります

最後に 去年、開発生産性を向上させるためにいろいろな施策を行なった結果、 F I N D Y T E A M + A W A R D 2 0 2 2 を受賞できました。 引き続き、開発生産性をあげてユーザに価値を届けていきたいです！

最後に 弊社では、エンジニア絶賛採用中です！ もう少し話聞いてみたいと思った方は、 是非お話ししましょう！ Q R コード（カジュアル面談応募フォーム） からお申し込みいただけます！