開発生産性・健全性を可視化する、ダッシュボードツールを開発しました

ブログメインビジュアル

こんにちは、フロントエンドエンジニアの峯です。

今回、開発生産性や健全性を可視化する目的で、ダッシュボードツールを開発して社内に導入しましたので紹介します。

開発に至った背景

アジケのエンジニアチームでは、品質や開発効率、スキルアップを目的とした様々な施策を日々行っています。


しかし、これらの効果を測る仕組みや環境が整っておらず、属人的な定性評価でしか効果を測れない状況でした。また、参画しているプロジェクトが異なっているため、自分が参画していないチームの開発状況を見る手段がありませんでした。


こうした課題に対し、プロジェクトを跨いだ生産性や健全性の可視化を行うため、ダッシュボードツールを開発しました。


今後、エンジニアチームをさらに強いチームに成長させ、クライアントに対して価値を提供していくためにも、定量的な計測指標の導入は意味があるとも感じました。

ツールで実現したいこと

エンジニアのパフォーマンス計測では、GoogleのDevOpsチームが実施ているという4つの指標を参考にしました。

  • デプロイの頻度
  • 変更のリードタイム
  • 変更障害率
  • サービス復元時間

上記の指標を計測のベースとしましたが、アジケのエンジニアの多くは、クライアントの事業開発を行うエンジニアとして働いてるため、プロジェクトのフェーズが開発中から、運用中まで様々です。プロジェクトのフェーズに依存なく活用できることを重視し、開発するダッシュボードでは以下を実現することにしました。

  • 生産性
    • マージされるまでの時間が計測できる(変更のリードタイム)
  • 健全性
    • m/d/dが計測できる
      • d/d/d(deploys / a day / a developer)を参考に、deployをmergeとして計算する(デプロイの頻度)

アジケでは、フロントエンドのみを対応することが多いので、変更障害率やサービスの復元時間に関しては、今回優先度を下げました。

計測の手段と仕組み

生産性と健全性の2つを軸計測するツールとして、以下を利用させていただきました。

https://github.com/shibayu36/merged-pr-stat

プルリクエストのマージ数や、行差分、マージ時間等をGitHub APIを利用して計測してくれるツールです!


こちらのツールをGitHub Actionsで週次で実行してデータを生成し、それをダッシュボードから参照できるようにしました。

計測仕様

  • 毎週月曜朝、先週の週次集計を行うGitHub Actionsが実行
  • 集計データはJSONファイルとしてs3に格納
  • ダッシュボードツールからs3に格納されたファイルを参照してグラフに描画

実際に開発したダッシュボードのキャプチャ

集計を自動化しているため、GitHub Actionsの導入を行うだけでコストはほぼかかりません。


ダッシュボードのフロントエンドはNext.jsを使って開発しました。UIライブラリには、個人的に興味があった、Tablerを利用し、グラフはApexChartsを利用して開発しました。


実際に開発したダッシュボードはこちらです!(※ サンプルデータを利用しています。) 実際に開発したダッシュボードのキャプチャ


今回作成したYAMLファイル(GitHub Actions)

name: Merged PullRequest stats metric

on:
  # UTC月曜10時に発火
  schedule:
    - cron: '0 1 * * 1'

jobs:
  stats_log:
    runs-on: ubuntu-latest

    steps:
      - uses: actions/checkout@v2

      - name: Set Up Node.js
        uses: actions/setup-node@v1
        with:
          node-version: 14

      - name: Install merged-pr-stat
        run:
          npm install -g shibayu36/merged-pr-stat

      - name: Check version
        run: merged-pr-stat -V

      - name: Set file name
        id: dir
        env:
          TZ: 'Asia/Tokyo'
        run:
          week=$(date -d '-7 day' '+%Y-%m-%d')
          echo "::set-output name=week::$week"

      - name: Merged_pr_stat metrics
        id: stat
        env:
          TZ: 'Asia/Tokyo'
          GITHUB_TOKEN: ${ { secrets.GITHUB_TOKEN } }
        run:
          # デフォルトのマージ対象はdevelop
          start_time=$(date -d '-7 day' '+%Y-%m-%dT00:00:00')
          end_time=$(date -d '-1 day' '+%Y-%m-%dT23:59:59')
          stats_log=$(GITHUB_TOKEN=${ { secrets.GITHUB_TOKEN } } merged-pr-stat --start=$start_time --end=$end_time --query="repo:$GITHUB_REPOSITORY base:develop")
          stats_log=${stats_log//$'\n'/\\n}
          echo "::set-output name=stats::$stats_log"

      - name: Create json file
        run:
          mkdir stat
          repo=${ { github.repository } }
          file=${repo//$'/'/'-'}
          echo -e '${ { steps.stat.outputs.stats } }' >> stat/${file}_stats_${ { steps.dir.outputs.week } }.json

      - name: Upload ftp
        uses: sebastianpopp/ftp-action@releases/v2
        with:
          host: ${ { secrets.ftphost } }
          user: ${ { secrets.ftpuser } }
          password: ${ { secrets.ftppassword } }
          localDir: './stat/'
          remoteDir: '/stats/'

開発したダッシュボードを導入してみて

計測をGitHub Actionsで行うことで、GitHubを利用したプロジェクトの計測が可能になりましたが、プロジェクトによっては、GitHubを使っていないプロジェクトもあり(GitHub以外のバージョン管理ツール)、すべてのプロジェクトで導入するには至りませんでした。


導入できたプロジェクトでは、実際に数字として開発状況を可視化することができ、課題が見えてきました。もちろん、数字だけで良し悪しを判断することはできませんが、そこから見えてくるものは多くありました。


ひとつは、今まで課題感としてなんとなくチームの一部のみが感じていた部分が、数字として現れたことで、チーム全体としてその課題をファクトとして認識することができました。また、定量的な目標を掲げることも可能になったことで、チーム全体で課題に対して取り組んでいけるようになったのではないかと感じています。


まだまだ、導入して日が浅く、改善していきたい点も多くあるので、日々アップデートしていきたいと思います。

今後の計画

定量計測を行うことで、プロジェクトを跨いだ、生産性、健全性の可視化が可能になり、エンジニアチーム全体で各プロジェクトの状況を見ながらサポートをし合う環境が整いました。


また、各プロジェクトの状況を見ながら、チームで行うべき施策の優先度づけや中長期で見た時の成果も定量的に測る準備もできました。


今後やっていきたいアップデートとしては、バージョン管理ツールに依存なく計測できるようにしたり、計測期間の自由度を上げて中長期の可視化をより詳細にできるようにしていきたいと思っています。それから、APIの開発やダッシュボードの改善を行い、ユーザービリティ向上などさらなる活用に向けた施策を行っていきたいと思います。


アップデートや新しい気づきがありましたら、また紹介したいと思います。

参考

この記事を書いた人 mine 2019年1月 中途入社のゴルフにはまっているフロントエンドエンジニア
COBOL開発経験がありますが平成生まれです。
TOP