前書き

これまで数社エンジニア組織を見てきて、うまく回っている組織には特徴があると思ったので、まとめました。
良い会社に勤めてらっしゃる方は、このぐらいのこと普通にされていると思うのでスルーしてくださいw

目次

問題1: バグが出る
解決策1: 単体テストと総合テスト
問題2: レビューがしづらい
解決策2: yardコメント
問題3: 課題に対する具体的な解決策がない
解決策3 KPT振り返りをする

問題1: バグが出る

どんな時にバグが発生する?

rebase
merge
抽象化されたメソッドの変更
ライブラリのバージョン変更
環境変数の欠損
機能追加によるソースコードの変更

悪い解決策

一人一人が注意する
※ このような解決策では属人的な解決策になってしまい、メンバーが抜けた時に、うまく回らなくなる。

解決策1: 単体テストと総合テスト

テストが大事だとはわかっているが、テストをしない理由は工数がかかるから。
ですが、それでバグ対応に追われたりする工数や、致命的なバグで顧客に迷惑をかけるくらいなら、テストに工数をかけた方が良い。

テストをどのくらいやるかチーム内で最低限ラインを決めてやった方が良い。

最低限ライン

最低限このぐらいはした方が良いと思う。

単体テスト
検索で起きうるパラメータ。
アクションからレスポンスがあるか?

総合テスト
モンキーテストだと漏れがあるので、
excelやspreadsheetなどで実装者が、テストケースを作成

問題2: レビューがしづらい

解決策2: yardコメント(Rails)

Railsを使っているのであれば、yardコメントをすることをお勧めする

yardコメントとは、メソッドに、
メソッドの概要、返り値の型と内容、引数の型と内容などを書くものです。

型を入れない言語では特に、このようなコメントアウトを入れるルールをチーム内で作った方が良いです。

# 日本語形式の日付に変換
# @param [Date] date 日付
# @return [String] 日付を YYYY年MM月DD日 の形式にしたもの
# @return [nil] 引数が Date 型以外の場合は nil
def convert_jp_date(date)
  (date.class == Date) ? date.strftime('%Y年%m月%d日') : nil
end

yardコメントのメリット

実装者は実装中はどの型なのか意識しているので、コメントを追加することへの、
負担は少なく、実装者以外のレビューへの負担は減ります。

新しく入ったエンジニアはメソッド名からはわからない概要を掴むことができます。

yardコメントのデメリット

実装者の負担が多少増える。

参考
Rails/Rubyドキュメントをキレイに生成するYARD、早見表付き！
https://morizyun.github.io/blog/yard-rails-ruby-gem-document-html/index.html

問題3:課題に対する具体的な解決策がない

「課題: バグが出ました」という課題に対して、
よくある事例として、「気をつけましょう」、「個人を問い詰める」などがありますが、
これでは、あまり解決策になってないです。

課題: バグが出ました

課題に対する対処
- 気をつけましょう
- 個人を問い詰める

解決策3: KPT振り返り

KPT振り返りとは、このような項目で、週次でチーム内で意見を出しあう

K：keep ＝良かったこと（今後も続けること）
P：problem＝悪かったこと（今後はやめること）
T：try ＝次に挑戦すること

KPTをするときの注意点

悪かったことが個人への攻撃にならないこと
チームとして改善できるか考えて、problemの改善案をtryにつなげる

参考

【徹底解説】正しい「KPT」が仕事の成果を生み出す！進め方のコツ、現場の事例を紹介
https://seleck.cc/kpt