エンジニア、ソースレビュー会辞めるってよ

アバター画像 sakurai

8

エンジニアの櫻井です。 去年から始めていたソースレビュー会をやめることにしたのでその経緯をお話ししようと思います。

ソースレビュー会の問題点

SUPER MTGに書いてあったことを基にエンジニアで今定期開催しているMTGについての満足度や改善点、課題に感じていることのアンケートを実施しました。 その結果、ブリーフィングやDev会議(月1で開催しているエンジニアの抱えている課題について話し合う会)、ヒアリング(1on1)に比べてソースレビュー会が明らかに不満の多い会になっていることがわかりました。 主な不満は

・定期開催で1時間やる程レビューする内容、案件がない
・月1開催なので公開から時間が経ち過ぎて実装者もあまりなぜそうしたかなど覚えきれていない

などが上がりました。 これに加えて僕自身もレビューはするもののその内容は既に公開されている内容なので「次から気をつけよう!」で終わるのはどうなのか?と思っていたところでした。

これからどうするか

上記の問題からソースレビュー会を定期開催する必要がないと判断しました。 とはいえソースレビューは必要だというのは組織全体としてありました。

ソースレビューを行う主な目的は経験の共有と品質の向上です。そのためにKNAPではソースレビューで話した内容は気づき、改善点、よかった点、課題をスプレットシートにまとめています。

ソースレビューを引き続き行うにあたってまず誰が行うのかを考えました。担当したエンジニアとサポートで入ったエンジニアだけで行うのでは経験の共有という面で弱いです。なので基本的には今のエンジニア組織の人数ならエンジニア全員に参加してもらいたいと思いました。

次に考えたのがソースレビューを行うタイミングです。 定期開催をやめるので都度開催になりますがソースレビューをするのに一々日程調整するのは骨が折れます。そこでブリーフィングの後に行うことにしました。 また、今までは公開後のものをレビューしていましたが、原則テストアップの段階でレビューする形に変更しました。原則テストアップ後にレビューすることでレビューしたことをすぐに反映することができるようになるので品質も向上できます。

まとめ

ということでエンジニアは定期開催のソースレビュー会を辞めてブリーフィングの後に都度ソースレビューを行うようにしました。問題や課題があればまた違う形になるかもしれませんがその時々に合わせて形を変えて続けていければいいなと思っています。

アバター画像

ぽちっとおうえん!

シェア

  • Facebook
  • LINE
  • X
カスタム変数(プロパティ)を使ったらcss アニメーション・・・