2022-10-24

開発生産性向上のための取り組み

k16

「開発生産性を半年で2倍にする」という目標を掲げてスタートした、当社の取り組みをご紹介します。

なぜ始めたのか？

開発生産性の可視化にはFindyTeamsさんを利用させて貰っています。 約1年ぐらい前のリリース時に導入のご案内は頂いていたのですが、その時は課題感がありませんでした。というか正確には計測さえもしていない状態だったので、何も判断指標が無い状態でした。

ただ夏に役員合宿をするにあたって、全社の生産性についてのアジェンダがある中で人数的に最大派閥であるエンジニアリング本部の”生産性”というのはどうなのか？という問いに自分は定量的に答えられずにいました。 また他の部署から見るとエンジニアの開発速度やクオリティが他社と比べてどうなのか？というのがわかり難いという点もありました。

時を同じくするように当社SREである@biosugar0もFour Keysの可視化をしたいと思っていると聞いて、様々な方向から意見があがっていたので、これは本部として開発生産性を可視化する事で、自分たちの現状を把握しより良い開発組織の構築をすべきだと強く認識した事から始めようと思いました。

どう始めたのか？

最初はFour Keysに沿った指標を自前で集めようと考えていました。 少し調べるとGitHubのアクションベースで集めている会社さんの記事が散見されたので、同じようにトライしようとしました。

const query = '{ \
   search(type: REPOSITORY, query: "org:SmartShoppingInc", last: 100) { \
     repositoryCount \
     nodes { \
       ... on Repository { \
         id \
         url \
         name \
       } \
     } \
   } \
 }';

 const options = {
   'method' : 'post',
   'contentType' : 'application/json',
   'headers' : {
     'Authorization' : 'Bearer ' +  ACCESS_TOKEN
    },
   'payload' : JSON.stringify({query:query})
 };
 const response = UrlFetchApp.fetch(ENDPOINT, options);
 const json = JSON.parse(response.getContentText());
 return ContentService.createTextOutput(JSON.stringify(json)).setMimeType(ContentService.MimeType.JSON);

こんな感じで、GitHub API v4を使えば簡単に取り出せそうだというところまでは辿りついたのですが、すぐに見せ方をどうしようかと悩みました。

グラフィカルツール系のSaaSなどを使ってもいいかなと思ったのですが、こねくりまわさないとダメだろうなというのが容易に想像できたので、もう少し調査したところFindyTeamsさんの記事が引っかかって、まさにやりたいと思っていた事がすでに実現されていたのですぐにコンタクトを取って9月からの導入に至りました。

現状の認識

スクリーンショット 2022-10-18 8.31.06 これは改善に取り組む前の2022年5月〜7月までのサイクルタイムの平均値です。 FindyさんとのMTGも経ての総評としては、中の中ぐらい。 スタッツによってはそれなりに良いところもありますが全体としてはまだまだ改善の余地があるところばかりでした。

問題の確認

  • 最初のコミットからプルリク作成までの平均時間が異常に長いのは明らか
    • そもそもゴミデータが残っているのではないか？
    • プルリクの粒度が大きすぎるのではないか？
  • プルリク作成からレビューまでの平均時間も長い
    • これもプルリクの粒度が大きすぎるのでは無いか？
    • それによって、レビュアーへの負荷が大きいからではないか？

目標の設定

Findyさんのアドバイスも含め、他社さんの動向を見ていると、まずは「1プルリクあたりの平均マージ・クローズ時間を24時間以内にする」という目標が目標に向けての最短ルートとなりそうなので、それを目標におきました。

各課題への対応策

手始めに以下の項目に取り組みました。

ゴミデータの整理

当たり前だが前段として。2021年プルリクが残っていたりしました。。。 これは各自すぐに対応してくれて、数日後には１週間より前のプルリクは残らなくなりました

プルリク作成からレビューまでの平均時間短縮のための取り組み

これは開発チーム内で完結しやすい点（PdMやQAなどが関わらないので）から取り組みました。 - 各開発チームで朝会を持っているので、そこでプルリクのレビューを強制的にやってもらう（後にすぐにルール化しなくても回るようになりました） - レビュー待ちがある場合、優先するようにそもそもの啓蒙 - 自チームのメンバーが作成したプルリクこそ早くレビューしてあげようよ！という思いやり - 外れ値になってしまいそうなプルリクの精査も合わせて行いました

これだけで少し改善の兆しが見えました。

Before スクリーンショット 2022-10-18 13.58.04

After スクリーンショット 2022-10-18 13.58.12

プルリクを小さくする取り組み

直近取り組んでいるのは巨大なプルリクへの対応です - シンプルにできそうな点だと1プルリクあたりの変更行数の目安で、こちらは200行を目安とするようにルール化しました。 - 1プルリク = 1タスクとなるようにタスク分解も行いはじめています

これらによって１月あまりの活動で全体感としては少しだけ進捗しているので、手応えを感じ始めています。 スクリーンショット 2022-10-17 18.07.28

まとめ

このようにまだまだスタートしたばかりではありますが、当社での開発組織全体のパフォーマンス向上に着手した取り組みをご紹介しました。

1つ1つは大きな施策ではないですが、まだまだ取り組める対策は多く、かつ銀の弾丸は無いと思っていますので、確実に1つ1つ施策を積み上げて「開発生産性を半年で2倍にする」という目標を達成したいと思っています。

そしてもちろん「開発生産性を半年で2倍にする」のはあくまで過程であり、真の目的は

  • チームのQCDの現状を常に認識できるようにするため

    • お客様にサービスを少しでも早く届け使ってもらい、少しでも早く改善をするため
    • 技術負債の解消を行いサービスの安定運行度合いを高めるため
    • QA/SETを通じてincidentの発生件数をおさえるため

  • 開発生産性を向上させ、成功責任を持ち常にストレッチできるチームになる事
  • 自他ともに認める素晴らしい開発組織を作りたい

です。

最後までご覧いただきありがとうございました。 また3月に（半年後に）成果をブログを通じてご紹介したいと思います。

スマートショッピングでは、このような開発組織で一緒にサービスを作り上げてくれるエンジニアを募集中です。 ご興味のある方はぜひご応募ください！

最新の記事