2
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

More than 1 year has passed since last update.

開発のチーム力が弱いと感じたのでGithub Actionを書いてみた。

Last updated at Posted at 2022-07-24

この記事は、自社開発企業のエンジニア職として勤める私が、
開発陣のチーム力が非常に弱い事を感じ、
チーム力を引き上げるためにとあるコードを書きました。という内容になっています。

背景

私の所属する開発チームの体制は、CTOを含め5~10名(うち、フリーランス1名)となっています。
基本的には、CTOから降りてきた開発要件が各エンジニアにアサインされて開発を行い、
残るエンジニア・CTOがGithub上のプルリクエストをレビューする形になっています。

チーム力における課題

 普段から開発に携わっていて、チーム力が非常に弱いと感じていました。
その要因の1つとして、 機能開発が属人化している のではないかと感じていました。

具体的に言うと、

  • 開発経験の薄いエンジニアの割合が高い
  • 新規機能・基盤の開発が比較的経験者だけで解決してしまっている

そしてさらに、

  • コードレビューのレビュアーが、 上級者にしか振られない
    と言う問題がありました。

コードレビューが原因となる属人化

 実装を一段落終えた後にプルリクエストを作成するのですが、
ここでレビュアーを手動でアサインする際に、どうしても経験のあるエンジニアにレビュー依頼が集中してしまっていました。

このこと自体、特に問題にはされていなかったのですが

+ コア機能の仕様を一部のエンジニアしか知らない
+ コードレビューに特定の人しか関わらないため、仕様が共有されない
+ バグが起こったり仕様説明が必要となった際に、特定の人しか解決できない
+ そもそも、みんなの開発スキルが上がらない
+ フリーランスにレビュー依頼が集中し、開発が進まない

などといった問題を日々感じるようになり、
皆にコードレビューに関わってもらえるようにするため
1つのGithub Action Workflowを書きました。

Github Actionで、レビュアーを自動でアサインした

実際に書いたコードがこちら。

name: assign_review_request

on:
  pull_request:
    types: [opened, reopened]
    branches-ignore:
      - 'staging'

jobs:
  assign:
    runs-on: ubuntu-20.04
    steps:
      - name: Set reviewers
        run: |
          reviewer_count=$(cat ${{ github.event_path }} | jq '.pull_request.requested_reviewers | length')
          if [[ 0 == $reviewer_count ]]; then
            reviewers=()
                        # レビュアー対象者を羅列し、シャッフルする
            accounts=$(shuf -e user_1 user_2 user_3 user_4 user_5 ...)
            for i in $accounts
            do
              if [ $i == ${{ github.actor }} ]; then
                continue
              fi
              reviewers+=($i)
              if [ ${#reviewers[@]} ]; then
                break
              fi
            done
            curl -X POST \
                -H "Accept: application/vnd.github.v3+json" \
                -H "Content-Type: application/json" \
                -H "Authorization: token ${{ secrets.GITHUB_TOKEN }}" \
                -d "{ \"reviewers\": $(printf '%s\n' "${reviewers[@]}" | jq -R . | jq -s .) }" \
                https://api.github.com/repos/${{ github.repository }}/pulls/${{ github.event.pull_request.number }}/requested_reviewers
          fi

ちなみに、Github Actionとはどのような仕組みなのか触れておくと、
リモートレポジトリへのPushやPublishなどのイベントが発生した際に
特定のジョブを自動で実行する仕組みです。

今回は、プルリクエストが開かれた事をトリガーにしました。

(ちなみにbranches-ignoreの所ですが、
ステージング環境用のブランチに向けたプルリクエストでは、
特にコードレビューを必要としていないためジョブをスキップしています)

ジョブの中でやっている事はごく単純で、
レビュアー候補をランダムに選択して、レビューリクエストのAPIを実行しています。

shufコマンドには入力された内容をシャッフルして出力する機能がありますが、
-eオプションで並び替えられた内容を配列に変換する事ができます。

$accountsには、レビュアー対象者がランダムの順番で入っています。
それぞれの要素をfor文で回して、それがプルリク作成者でなければレビュアーに追加、
レビュアーの候補者数が一定になればループ処理を抜けてAPIをcurlで実行しています。

レビュアーアサインを自動化した事の成果

成果として実感しているのは、次のような感じです

+ これまで関わってなかった人も、(渋々ではあるが)レビューに加わってくれるようになりつつある
+ プルリクに関わる事で、機能に対する意識を持つようになっている(と、嬉しい)

ただ、中には
自分が振られても他者がレビューし終えるまで何もしなかったりする人もいて、
仕組みを作っても、プロダクト改善に関わってくれるかどうかは結局それぞれの意識の問題なのか、と思ったりもしていますが、こればかりは仕方ないですね。。

今回は、プルリクのレビューの仕組みを触ってチーム力改善にコミットしてみました。
久々に、シェルスクリプトを書けて楽しかったです。

2
0
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
2
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?