LoginSignup
33
31

More than 5 years have passed since last update.

テストコードのレビューについて

Posted at

はじめに

TDDについて書いたところ、思ったよりも反響があり、様々なところでコメント書いていただきました。
ありがとうございます。

はてなブックマーク等に書かれている通りで、僕自身がTDDについて未熟なのは承知しております。
それを承知の上で僕が行った施策とTDDをやめた理由を文献に残そうとしたものがこちらの記事になってます。

さて、今回は頂いたコメントに関して僕の中で腑に落ちない内容であるテストコードのレビューについて書いていこうと思います。

成果物の管理について

TDDを実践している人の記事やコメントで幾つか見られるのがテストコードのレビューが不要という内容です。
僕はこの考えにはかなり否定的です。

テストコードに限らず、自分がマネジメントしているチームのメンバーが作成したものは全て成果物という扱いになるというのが僕の考えです。
その成果物に関してレビュー(チェック)を行わないというのは、作ってもらってないに等しいと僕は思ってます。

ビジネスの観点では成果物が全て

ビジネスの視点で見ると成果物に対してお金を払うことはごく一般的です。
自分が使いこなせない成果物はどんなに優れていても価値はありません。
システムを発注する人は、その発注した物に対して価値を見出すからお金を払ってます。

自分にとって価値のない物にお金を払う人は居ないでしょう。

マネジメントは例外なのか?

社内で働いている人にはこれが例外になるのでしょうか?
曖昧な価値のある物に対して良しとして仕事を進めるのでしょうか?
自分で依頼した物をチェックしないつもりで仕事を任せていくのでしょうか?

僕はメンバーに対しても、依頼した物が依頼した通りになっているかを確認すべきだと思ってます。
これはTDDで作ってもらったテストコードも例外ではないと思ってます。依頼して作ってもらっている立派な成果物です。
その成果物の価値をマネジャーは把握すべきだと思います。

自分が把握しているからこそコントロールができる状況ができて、マネジメントができる物だと思います。

テストコード等をレビューしない場合

僕が見てきた現場でもレビュー(確認)を疎かにしている現場は多々ありました。
そのような現場では属人性が強くでて、マネジメントを放棄している状況にみられました。
そして、そういう現場ではトラブルが発生しやすく発生すると個人に責任を押し付ける傾向がありました。

また、テストコードがあっても誰もチェックをしていないためメンバーは面倒臭そうにテストコードを書いているような状況で、テストコードの中身も正常系の一部しか書いていないという状況が多発してました。
(属人性によるため、しっかり書いている人ももちろんいました。)

人は見られているから頑張り成長する

人は誰かに見られていることを意識することで大きく成長します。
ペアプログラミングがいい例だと思います。

作った物が何かの役に立つからこそ人は頑張ります。
そして、そこで得られるフィードバックで成長していきます。

これはテストコードも例外ではありません。
下記に記載しているPDCAを回すからこそ、人は気づき成長し熟練していきます。
一人で成長できる天才を基準にしてマネジメントすることはできません。

品質担保用のテストコードとTDDのテストコードは別

このように書いている人が見られましたが、果たしてそうでしょうか?
上記にも書いているように、人に見てもらうことで成長します。
また、マネジャーが見ることで何を担保しているかがわかります。

そして、何を担保していないかがわかります。
僕はテストコードを書くならTDDのテストコードと品質向上のテストコードは同一視した方が生産性がいいと思います。
というか、そもそも別にする理由がわかりません。

開発プロセスの工程で、TDDのテストコードは簡易で後で肉付けをして品質担保用のテストコードにするというのなら分かりますがこれを別々に管理してしまったらTDDで作ったテストコードは何に使うのでしょうか?

僕なりの結論

僕はPDCAサイクルが仕事には不可欠だと思ってます。
何かの計画(Plan)を立ててから、実行(Do)して、評価(Check)をした後に改善(Act)するサイクルを回すことで生産性と品質、提供(QCD)を高めていけると思ってます。
成果物に関しては例外はないと思ってます。

なので、TDDのテストコードのレビューは必須だと思います。
レビューをすることで粒度を揃えるルールを作ることができる思います。
ルールがあれば人が変わってもチーム内の品質を担保しやすくなります。

とは言っても・・・

現実問題、全てをチェックすることはできないというのもあります。
マネジャーがチェックできる物には限界があります。(マネジャーのスキルによる問題と物量の問題等があります。)
そこはどうしてもトレードオフが発生すると思います。それについては現場内で調整するしかないと思っております。
その結果がテストコードのレビューは不要になるかもしません。
しかし、それを一般的として公言するには根拠が薄いと思います。せめてTDDのトレードオフとしてレビューを不要とした根拠も一緒に乗せてもらいたいです。

というのが僕の意見です。

また、僕は僕の考えを持ってますが僕が絶対正しいと言うつもりは毛頭ありません。(若い頃はありましたが・・・)
僕の考えについていろいろご指摘して頂けるのは大変嬉しいですし、そういう議論が出来る人は貴重な存在だと思ってます。

最後に

僕はTownSoftの屋号で活動してます。
よかったらお仕事ください。(苦笑

33
31
5

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
33
31