開発生産性を計測し、開発組織の当たり前基準を上げる

2 どのような背景・経緯で開発生産性に着目したのか 背景: 1チームのScMをやっていた時期 ● チームの開発の流れが全て見える状態だった ○ 問題を早期に発見できた ● 特にデプロイフローも決まっていない状態だが、開発はスムーズに進められていた

3 どのような背景・経緯で開発生産性に着目したのか ● 不具合やhotfixが以前より増えるようになり、「QAせずにデプロイは危険なので、まとめてQAし て週1デプロイする」という運用になった ● 1チームのScM期と比べて開発の流れが見えなくなった ○ 問題の早期発見ができない ■ 問題を早期発見できないと、問題が育ってしまい対応コストがかかりがち 背景: 複数チームを見る役割になり、同じリポジトリをさわるチームも3チームになった時期

GLOBIS DIGITAL PLATFORM 4 どのような背景・経緯で開発生産性に着目したのか 背景: 当時の記事 https://qiita.com/technuma/items/eae37b75e3aa5530d319

5 ○ プロダクトは指標を使って改善している、開発組織も似たようなことできないか ○ 計測できれば改善できる ■ 2018-2019年あたりにt-wadaさんの質とスピードを見て、Four key metricsという指標を 知った ■ Google も Four key metricsを重視しているとのことで、信頼できそう ○ 2021年にCTO協会より DX Criteria /企業のデジタル化とソフトウェア活用のためのガイドラインが公開 される どのような背景・経緯で開発生産性に着目したのか 背景: 事業に関わっている開発チーム全体の開発ボトルネックを解消する役割になった時期

6 ● 今まで10人規模のベンチャーだったため、マネージャー経験がまったくなかった ○ 経験がないものの開発組織として、「正しい積み上げ」をするための仕組みづくりをしたい ■ 体感としては、「楽しく、快適かつ生産的になれているか」を気にしている ● 良いデフォルトを作りたい ○ 背景を知らずに入社した人からすると、グロービスではこれが普通なんだと思われてしまいがち ○ 例 ■ 10秒以内に切り戻せる状態でデプロイする ■ Pull Requestのサイズはできるだけ小さくする ■ プロジェクトは3ヶ月以内に収まるようにする ■ CIは10分以内に終わらせるようにする（並列化は問題なし） どのような背景・経緯で開発生産性に着目したのか 開発生産性に着目した理由

7 ● デプロイ頻度 ○ Deploy / a day / Developer を算出 ● リードタイム ○ 開発者がcommitしてから Pull Requestがマージされるまでの時間 ● MTTR ○ 障害発生時から解消までの時間 ● 変更失敗率 ○ Revertした Pull Request数 / 全体のPull Request数 * 100 どのように定義し、組織運営に組み込んでいるのか どう定義したか

8 ● リードタイム・デプロイ頻度は、多くのチームで取っている ● 健康指標として、週次でスクラムオブスクラムにて確認している ● チームによっては週次の振り返り時に数値を確認し、改善アクションにつなげている ○ 改善の例 ■ Feature Flagを導入してすぐに切り戻せる仕組みづくり ■ 自分の開発作業よりもレビューを優先する文化 ■ モブ設計やモブレビューを通じた認識合わせ時間の圧縮 ■ k8s化をして検証環境を増やしやすくした どのように定義し、組織運営に組み込んでいるのか 組織運営の組み込み方

GLOBIS DIGITAL PLATFORM 9 ご清聴ありがとうございました 開発ブログ 採用サイト https://note.com/globis_engineers/ Advent Calendar https://recruiting-tech-globis.wraptas.site/ https://qiita.com/technuma/items/df1424 5d75244b8f437d

ご清聴ありがとうございました