PRでコメントが多いそんなとき

みなさんはレビュー時にあまりにコメントが多くなりすぎて困ったことがないでしょうか?

今回はそういうことにおちいった僕が考えたことをそこはかとなく書き残しておきます。

チームの状況や練度等に大きく左右されるので他のチームの知見を鵜呑みにするのではなく、その考えが出てきた理由などに着目すべきでしょう。

前提

  • 大量のコメントがつくような問題のあるPRを出した人は悪意を持ってそういったことをしているわけではありません
  • チームは悪意を持ってそのコメントしているわけではなく少しでも良くしようとしています

何が悪いんだろう

PRで大量にコメントがついたとしても、必ずしも作業者だけに問題があるわけではないと思います。

僕が思うに、様々な前提が共有されていないためにそのような状況に陥ってしまったのではないかと考えます。

チームはその前提の共有のために惜しみない協力を行ったのでしょうか?

多くのチームではそういったことをせず、なぜわからないのなら聞かないのか?というような指摘をして終わらせているのではないでしょうか?

それが本当に問題なのだとして、その人が質問できる適切な場を提供しているのでしょうか?

こういったような作業者だけではない問題を直さないと、今回はたまたま問題のあるPRを出した人とは違う人が同じような状況に陥ることはあるのではないかと思います

こういったときにはチームとして何が問題だったかを考え、みんなでより遠くに行く方法を検討したいと考えたいと思っています。

解決策案

PRのコメントを効率よく減らそうと思うと、PRが出てコメントがつけられるようになった段階ではおそすぎます。なので、その前のどの段階で何をするのかが重要です。

僕が考えたのはプランニングの段階である程度コンセンサスを取っておけば大きな問題はないのではなか?というものです。(我々はスクラムで開発しています。)

とはいえ、プランニングがいたずらに長くなるのはいただけません。PRのコメントが減り、かつできるだけ短くプランニングを終えるたいのです。

そこで僕が考えたのは、「事前にインターフェースをある程度決めておけばそんなに大きく間違えないのではないか?」という手です。

例として、RESTAPIを作成するタスクであればドメインサービス周辺のインターフェースを作業者のみに委ねるのではなく、全員で一緒に考えてメソッドの引数、戻り値やその周りで使いそうなものをある程度定義しておけばいいのではないか?といった感じです。

さらに、先にインターフェースを定義することで、別の作業者がそれを呼び出すコントローラーや、それが呼び出すであろうリポジトリの実装を行えるようになるので一人で手に負えなくなっても手助けしやすいという嬉しい副作用もあります。

解決した?

しませんでした。

インターフェース決めればうまくいくよねって思ってたんですが、インターフェースという言葉がお互い認識が違っていて決めたインターフェースが作業に入ってから変わった変わらなかったの不毛な話し合いが後で置きましたとさ。

人間が解り合うのは難しいですね。