BLAMではエンジニアの工数可視化に取り組んでいます!

こんにちは!テクノロジー本部でエンジニアをやっている三崎です。(三崎 秋人 / Shuto Misaki (BLAM) (@smish0000) | Twitter
普段は自社サービス「カイコク」の開発をメインに行なっています。

今回はテクノロジー本部で行っている工数可視化の取り組みに関してご紹介します!

なぜ可視化を行っているのか

弊社でエンジニアの工数可視化に取り組んでいる理由は下記の通りとなります。

  1. 開発フローにおけるボトルネックを可視化する
  2. 機能開発やリファクタリングなど、タスクの種類別に工数を可視化する

以下、項目ごとの詳細をまとめていきます。

開発フローにおけるボトルネックを可視化する

開発フローにおいて、仕様策定やコーディング、レビューなど複数のステップがありますが、 各ステップに要した時間を可視化し、ボトルネックになっているステップがあれば、テコ入れをできるようにしています。

タスクの種類別に工数を可視化する

バグや機能開発、差し込みなどの分類を行い、種類別に工数を把握できるようにしています。

  • バグの対応工数が多ければテストコードやレビューフローを見直す必要がある
  • 差し込みの対応工数が多ければ依頼フローや計画時に調整を行う必要がある

などの判断をできる状態を目指しています。

計測方法

ここからは実際の計測方法をご紹介します!

今回の計測に当たって、下記の要件を設定しました。

  • ソースコードの管理にGitHubを使用しているため、タスク管理にもGitHubを使い、タスクフローをシンプルにする
  • コミットの作成やPRの作成などのイベントを拾い、自動で集計できるようにする
  • タスクの種類を判別するために、ラベルなどをつける
  • 数値を視覚的に見られるようにし、定期的に確認できるようにする
  • 下記のイベントの集計を行う
    • イシューの作成
    • イシューにおける最初のコミットの作成 (=コーディング開始)
    • PRの作成
    • PRの承認
    • イシューのクローズ

これらの要件を満たすために、下図のような構成にしました。

要件のイベント発生時にGitHub Actionsを実行し、ペイロードで渡されるイシューの担当者やコミット時間などを整形、Big Queryのテーブルにインサートしています。

一部省略していますが、GitHub Actionsの設定ファイルは下記のようになっています。

name: Post Code Event to BigQuery
on:
  issues:
    types: [opened, closed]
  pull_request:
    types: [review_requested]
  pull_request_review:
    types: [submitted]
jobs:
  post-event:
    name: Post Code Event to BigQuery
    runs-on: ubuntu-latest
    steps:
    - name: 'get the related issue with the PR'
      ...
    - name: 'post big query API'
      run: |
          curl -X POST https://bigquery.googleapis.com/bigquery/v2/projects/our-project/datasets/internal/tables/code_activities/insertAll \
            -H "Authorization: Bearer ${{ steps.auth.outputs.access_token }}" \
            -H "Content-Type: application/json" \
            -d '{"rows": [{"json": {"issue_id": "${{ steps.issue.outputs.ISSUE_ID }}", "issue_label": ${{ steps.issue.outputs.ISSUE_LABEL_NAMES }}, "issue_assignee": ${{ steps.issue.outputs.ISSUE_ASIGNEE_NAME }}, "issue_milestone": ${{ steps.issue.outputs.ISSUE_MILESTONE_NAME }}, "event_type": "${{ steps.event-type.outputs.EVENT_TYPE }}", "datetime": "${{ steps.current-time.outputs.CURRENT_TIME }}" }}]}'

そして、Redash上で下記のようにデータをまとめ、タスクごとのタイムラインやチーム全体のリードタイムやコーディング時間などを数値ベースで算出しています。

現在の運用

このように自動的に計測できる体制を整えたことで、工数の集計・可視化を自動化しつつ、下記のようなGitHub上で完結するシンプルな運用を実現することができました。

  1. イシューの作成 => Big Queryにデータ送信
  2. スプリントプランニングでGitHubのカンバンを確認しながら、担当者をアサイ
  3. 作業を開始し、手元のPCからGitHubにプッシュする
  4. GitHub上でPRを作成し、レビュー依頼を行う => Big Queryにデータ送信
  5. レビューを行い、GitHub上でPRの承認を行う => Big Queryにデータ送信
  6. PRをマージし、イシューをクローズ => Big Queryにデータ送信

また、PRの作成時に特定のキーワードを用いて、イシューとの紐付けを行うと、
PRのマージ時に紐付けたイシューをクローズし、カンバン内の移動も自動的に行ってくれます。

紐付けに関しての詳細はこちらをご覧ください。

まとめ

BLAMのテクノロジー本部では、上記のようにGitHub Actionsなどの技術を用いて、生産性の分析やチケットの管理にかかるコストを減らすことで、エンジニアが集中すべき箇所に集中して業務を行えるようにしています。
今後もエンジニアにとって働きやすい環境、エンジニアのアウトプットを最大化するための取り組みを積極的に行っていきます。

さいごにBLAMでは一緒に開発を行ってくれる方を募集しております。ご興味のある方は下記リンクからぜひご応募ください!

www.wantedly.com

www.wantedly.com